SpritesMind.Net

When gasega68k said 64KB external ram.... Which Ram? In cartridge?

danibus wrote: ↑

Sat Mar 30, 2019 9:35 am

When gasega68k said 64KB external ram.... Which Ram? In cartridge?

He uses the save ram on the cartridge (64 KB, words) to store the virtual map. Most emus give you that by default.

Miquel wrote: ↑

Sat Mar 30, 2019 11:49 am

danibus wrote: ↑

Sat Mar 30, 2019 9:35 am

When gasega68k said 64KB external ram.... Which Ram? In cartridge?

He uses the save ram on the cartridge (64 KB, words) to store the virtual map. Most emus give you that by default.

Thanks
Hmmmm very interesting

Most emus, and the Mega EverDrive and MD Pro flash carts. The rest have only byte-wide save ram. You could fetch byte-wide save ram via movep to avoid the issue, but that would slow the routines a bit.

Probably worth noting that there's nothing requiring the RAM to be non-volatile (i.e. it can be just plain RAM that isn't saved on power off, without battery). The ROM header even accounts for this possibility, just that no official game ever used such a setup.

MisterDave wrote: ↑

Thu Mar 28, 2019 7:54 pm

Hi, this is a little demo that I recently put together that handles scaling and rotation. There is a lot of precalculation in the ROM, however, any bitmap can be scaled without requiring each image to be pre-scaled and rotated.

https://m.youtube.com/watch?v=8yS6xhLGJGk

Is it all precalculated or is also scalling on real time going on?

"Rock n' Roll Racing Hack v16beta" rotation:
Software: https://youtu.be/9SdOBw-8VQU
Hardware(with sega-cd): https://www.youtube.com/watch?v=AxFOkC1cCLg

Miquel wrote: ↑

Sat Mar 30, 2019 8:52 am

[...]
Done. You have mode7 an probably not much more cpu time to waste.

I forgot to say that both gasega68k and Stef change the resolution from 320 to 256 in horizontal.

The thing is H32 mode runs at slower clock, that means less throughput, so my supposition is they only go to that mode on display time, but that is a guess.

In terms of DMA transfer, you end up using the same time yeah (transferring a 256px wide buffer in H32 mode will take as long as transferring a 320px wide buffer in H40 during vblank). What you reduce is CPU usage when doing software rendering — in particular, you only need to render 80% as many pixels, which can be significant.

EDIT: I should probably make it clear that DMA transfers are slower in H32, but the 68000 speed remains the same, hence why H32 can still help. That, and a smaller buffer means it may become more feasible to double buffer if needed.

I agree with what you say.
My point is if you switch modes, H40 on extended vertical exception and H32 on reduced display time, you get the best of both worlds, that is more cpu time since DMA goes faster for the same amount of data.

Something like this:
1. Horizontal exception on line 192, disable display, switch to H40 mode
2. DMA bitmap from buffer to VDP
3. Begin rendering bitmap to buffer…
4. Horizontal exception on line 32, switch to H32 mode, enable display
5. … end rendering bitmap to buffer.
6. goto 1

But I haven’t tested it, hope it works.

This has been done and it doesn't work really well since the line where the switch happens will have different timings from the rest and that does upset some TVs etc. by making them do weird noises or other oddities. You can reduce the problem by doing the switch during horizontal sync pulse but the timing needs to be quite exact, then that line will differ in length from others minimally.

What about moving to H32 lines before enabling display?, something like this:

1. Horizontal exception on line 192, disable display, switch to H40 mode
2. DMA bitmap from buffer to VDP
3. Begin rendering bitmap to buffer…
4. Horizontal exception on line 30, switch to H32 mode
5. Horizontal exception on line 32, enable display
6. … end rendering bitmap to buffer.
7. goto 1

Another option is just having a bezel of 32px all around the image, displaying "very useful information", while always on H40 mode.

Enabling/disabling display isn't gonna do anything with that, video line generation is an autonomous process that runs always and depends on if internal dot clock or EDCLK is used (bit7 or VDP register $07).
in H256 (256 pixels + internal dot clock) all pixels are 10 MCLKs long, while in H320 (320 pixels + external dot clock) they're 8 MCLKS in everywhere but HSYNC period where they're toggling between 8, 9 and 10 MCLKs so that line length can be exactly 3240 MCLKs, same as H256. H320F (320 pixels and internal dot clock) has only 8 MCLK pixels and thus has correspondingly shorter lines that not everything will appreciate.

Anyway when you switch to H256 from H320 during the line, suddenly the line will get much longer since there will be lot of pixels drawn with long timings. There's also HVcounter issue, I'm not totally sure how the VDP will behave internally with such a mode switch, sprites will probably get messed up too on that line.
When switch is done during HSYNC the line will shorten very slightly, most pixels take 10 MCLKs there while every once in a while there's 9 and 8 MCLK ones, which now disappear, but the change in line length will be minimal compared to switch happening elsewhere during the line. Unfortunately there's no good way to know when HSYNC happens, best bet is to poll the line blanking bit in VDP status and then count fixed amount of cycles afterwards to know that you're in the sync period rather than still in the border. There's 14+9 pixels (68K cycles : (14+9)*8) / 7)) from right edge of active area to sync in H320 and 14+7 pixels in H256 (68K cycles : (14+7)*10) / 7)).

I see, the perfect timing of the line is altered if the change becomes during display time, and it works if it is during horizontal blank.

Then another way to do it is going with H40 while in vertical blank, and H32 on the rest, but it certainly complicates things.

Switch must happen not just in horizontal blank, it must be in horizontal sync position of the line. You do your switch at any line you desire during the frame, but the switch itself must happen in sync portion of the line you do it on.