Mode 7 demo for Genesis/MD

gasega68k · Post by **gasega68k** » Wed Dec 17, 2014 9:29 pm

Hi, this is a demo of rotation and scaling better known by the name of "Mode 7".

I'm using the external Ram 64Kb in Word mode, to use as a "virtual map" of 256 x 256 8bit (256 colors "simulated" as in Wolf3D), the idea is that when we move on the map, it will uploading new "tiles" (a size of 8 x 8 = 64 bytes), similar to what is done for normal scroll, but as "tiles" of 64 bytes.

Unfortunately, this will not work with flashcarts, since they do not support word-wide in Sram.

The rom currently only has about 45Kb, with a map of 128 x 128 tiles (or 1024 x 1024 pixels) which occupies about 16KB, and 11kB for tiles, I think there are 171 tiles (of 64 bytes). With this "engine" can make maps of almost any size. Although right now I'm doing the tilemap in bytes, ie it could handle a maximum of 256 tiles, but I can make the map in words, for a total of 65536 tiles!

This is a very preliminary version yet, is only implemented the "vertical scroll", and also unoptimized, but still sufficiently fast to make some games with him. The current resolution of the area of "Mode 7" is 256 x 96 (but the vertical resolution is Doubled), of course, you can increase the size (or make it every line, instead of 2), and even more if optimized using tables.

I also could use more ram size (256KB would be ideal), but I think 64kb are "sufficient", also would not work on emulators if I use more than 64KB.

Edit: works properly with MegaEverdrive.

Download link:
http://www.mediafire.com/download/th2un ... e7_tst.rar

Post by **KanedaFr** » Wed Dec 17, 2014 10:30 pm

wow !!

just HOW did you make this ?!
external ram ? word mode ?
It sounds MegaCD to me

Nemesis · Post by **Nemesis** » Thu Dec 18, 2014 12:28 am

Wow, really, really impressive! I'd never thought about using extra memory on the cartridge as a way to improve graphics.

Chilly Willy · Post by **Chilly Willy** » Thu Dec 18, 2014 4:49 am

Actually, it works just fine on the MegaEverdrive since what the MED does for save ram is just map the save ram area to part of the DRAM. It also "works" on the NeoFlash Myth, but it looks a bit odd because every other byte is missing.

On my Model 2 Genesis (with Model 2 CD and 32X), it stays relatively constant at 26 FPS, with the odd bobble to 25. Looks really good and fast!

If you need further tests on real hardware, I'd be happy to try it since I have the MED.

Also, it shouldn't be too hard to make a version that used word ram or program ram with the SCD in place of save ram. You wouldn't even need to actually start the CD, you just reset the sub-cpu, request the bus, and then you have access to the program ram at 0x420000 (four banks of 128KB). You could also switch the word ram to the Genesis side and use up to 256KB at 0x600000.

Stef · Post by **Stef** » Thu Dec 18, 2014 12:30 pm

It looks really nice and smooth ! It would be perfect to reach 30 FPS to synch on screen refresh then it would looks even smoother ! That is probably possible with some optimizations (and the help of some tables)

Also the idea of using the backup RAM to store the map is neat =)

ob1 · Post by **ob1** » Thu Dec 18, 2014 3:46 pm

Oh my god !!

Did you just developped Super Mario Kart on the Genesis !?!

Amazing !
Great work !!!

TapamN · Post by **TapamN** » Fri Dec 19, 2014 1:02 am

So you're using 64KB of external RAM when there's 64KB of internal RAM? Would it be possible to instead keep the Z80 stopped and store game state in Z80 RAM?

With few macros to replace stack operations/subroutine calls/returns with MOVEP-based emulations, it shouldn't be too much of a pain to program for if you treat the 68K like a load-store RISC accessing two separate 4KB spaces divided by the even/odd address bit.

For interrupts, there'd have to be some place in main RAM to store the saved PSW and PC, which would overwrite a small part of the ground texture, but if you emulate the RTE instruction with MOVE SR and JMP from registers, it should be possible to restore the overwritten area before returning. You'd have to be careful with the timing to make sure no interrupt occurs between restoring SR (re-enabling interrupts) and returning.

(Does MOVEP actually work with Z80 RAM? It really should, since the whole point of MOVEP is to do 16/32 bit accesses to 8 bit areas, but I don't know if MOVEP does the accesses too fast for the bus or something...)

gasega68k · Post by **gasega68k** » Fri Dec 19, 2014 2:00 am

So it works with MED, great !

, then I have to modify the first post, thanks Chilly Willy.

Stef wrote:It looks really nice and smooth ! It would be perfect to reach 30 FPS to synch on screen refresh then it would looks even smoother ! That is probably possible with some optimizations (and the help of some tables)
Also the idea of using the backup RAM to store the map is neat =)

Yes, I think it's entirely possible to get 30fps, with some optimizations.
Although at first I was thinking of using 16KB main Ram (for a "map" of 128 x 128) but I realized that was too little, ie pixels (pixel textures) would have to be very large (the double of the current demo) and so thought of using external ram (which is usually used to save the game), but with 64KB, although it could be more, but I think it is "enough".

ob1 wrote:Oh my god !!

Did you just developped Super Mario Kart on the Genesis !?!

Amazing !
Great work !!!

Or Super Sonic Kart?

So you're using 64KB of external RAM when there's 64KB of internal RAM? Would it be possible to instead keep the Z80 stopped and store game state in Z80 RAM?

With few macros to replace stack operations/subroutine calls/returns with MOVEP-based emulations, it shouldn't be too much of a pain to program for if you treat the 68K like a load-store RISC accessing two separate 4KB spaces divided by the even/odd address bit.

For interrupts, there'd have to be some place in main RAM to store the saved PSW and PC, which would overwrite a small part of the ground texture, but if you emulate the RTE instruction with MOVE SR and JMP from registers, it should be possible to restore the overwritten area before returning. You'd have to be careful with the timing to make sure no interrupt occurs between restoring SR (re-enabling interrupts) and returning.

(Does MOVEP actually work with Z80 RAM? It really should, since the whole point of MOVEP is to do 16/32 bit accesses to 8 bit areas, but I don't know if MOVEP does the accesses too fast for the bus or something...)

I think it can indeed work, I actually think it is a good idea, but the problem of having the Z80 stopped is that there would be no possibility of reproducing samples, also can complicate a bit more with more variables, objects, enemies etc, but anyway I'll see if I can do it, thanks.

There is also the possibility of using external standard 8KB SRAM instead of Z80 Ram.

In a moment I will post a new version with the "scroll" working properly.

Edit :Actually this will not work with the main ram, since I use a 12KB for the render buffer (double buffer, 6KB x 2), which then is transferred to the Vram with DMA, I forgot that little detail.

bobthebuilder · Post by **bobthebuilder** » Fri Dec 19, 2014 2:10 am

This has been my week of seeing amazing scaling on old hardware. Here is an example on the NES. http://forums.nesdev.com/viewtopic.php?f=22&t=12055

gasega68k · Post by **gasega68k** » Fri Dec 19, 2014 4:05 am

Hi, I made a video and also a new version with the "scroll" working well (towards any direction), but still has some minor errors.
http://www.youtube.com/watch?v=Yt_He0Ep02o

Download new version:
http://www.mediafire.com/download/7iyeq ... e7_wsc.rar

twosixonetwo · Post by **twosixonetwo** » Fri Dec 19, 2014 12:29 pm

Wow, this indeed looks great. I wonder how much performance penalty it would take to make this work without the word reads from SRAM?

TapamN · Post by **TapamN** » Fri Dec 19, 2014 6:52 pm

Maybe some kind of mipmapping-like technique could be used to reduce the memory usage?

Instead of having the large range, full detail 256*256 map, you can have one small range, full detail 128*128 texture for the area near the camera, and one large range, reduced detail 128*128 texture for the area near the horizon? This would halve the memory requirements of the ground texture, and shouldn't add extra overhead to any of the per-pixel drawing operations.

Chilly Willy · Post by **Chilly Willy** » Fri Dec 19, 2014 6:58 pm

Using MOVEP would allow running on flash carts (or homemade dev carts) that used byte-wide save ram. It would be interesting to see what the speed drop would be since you're doing twice the bus operations compared to a normal move. The Z80 only has 8KB of ram, so I'd advise against using it other than for sound purposes.

Now, lemme go try this new version... damn! This is awesome! It's a full track now instead of just a stretch of track. The speed is good for a racer, especially a kart racer, but I could see other types being done with it.

Chilly Willy · Post by **Chilly Willy** » Fri Dec 19, 2014 7:05 pm

TapamN wrote:Maybe some kind of mipmapping-like technique could be used to reduce the memory usage?

Instead of having the large range, full detail 256*256 map, you can have one small range, full detail 128*128 texture for the area near the camera, and one large range, reduced detail 128*128 texture for the area near the horizon? This would halve the memory requirements of the ground texture, and shouldn't add extra overhead to any of the per-pixel drawing operations.

You misunderstand MIPMAPPING. Mip maps don't decrease memory usage, they INCREASE memory usage to improve the quality of the rendered image. MIPMAPs generally double the memory usage.

What you describe is called LOD (level of detail). It's how games deal with pop-up - instead of not drawing the background (because you don't have the power), you make the background a lower detail. Most games use multiple levels of detail.

The issue with using LOD in a game is loading the higher level details as you move closer to them. In Skyrim, you get a noticeable jolt in the frame rate when you cross a cell boundary that requires loading more detail for the cells you are approaching. Similarly in this game, if he kept half the track in a low detail to save ram, he'd still have to reload that part kept in low detail as you drove around the track. So all you're doing is substituting less ram for more frequent reloads from rom

TapamN · Post by **TapamN** » Fri Dec 19, 2014 11:20 pm

Mipmapping is a LOD system for textures. It's primary use is to increase rendering speed (by reducing page breaks in improving cache coherency) and reduces aliasing (by prefiltering the downsamples) on minified texture samples. (This wouldn't help speed up the 68K since it doesn't have a cache, but on systems that do, like the Dreamcast, mipmapped texture are significantly faster on minified textures, IIRC around 1.5x is not unusual.)

Normally, full mipmaps increase the memory usage of a texture by about 33%. This is the result of the infinite series of the downsampled texture sizes (1 + 1/4 + 1/16 + 1/64 + ... = 4/3) (But no one would keep textures smaller than 1 pixel, and hardware mipmap implementations might need some padding between small mipmap levels (like on the DC), so full mipmaps are never exactly 33% larger than their highest resolution level.)

I called it mipmapping-like since it keeps two mipmap levels of the ground texture and renders from one based on scaling/distance, like normal mipmapping, but with the modification of only keeping 1/4th of the highest resolution level in RAM at once.

I don't think this would significantly increase the amount of time to update the ground texture. I don't know how smart the scrolling algorithm gasega68k is using to update the ground, but on a dumb scrolling algorithm that updates two borders of texture (and not just visible areas), the current 256*256 texture ground would need 63 8*8 tiles (4032 texels) updated. With the two-level idea, the far mipmap would need 63 4*4 tiles updated, and the near mipmap would need 31 8*8 tiles updated, with 2992 texels total. However, this dumb update algorithm would require more tilemap reads (94 vs 63), so it's not a clear win, and a more advanced algorithm might have more overhead working on both levels.

Edit: Actually, this probably would have overhead, but it would probably be caused by the address generation requiring extra shifts, while the 256*256 map would just need swaps and byte moves.