wolfenstein demo for sega genesis

[gasega68k]

Stef: The method I'm thinking of doing to use DMA and a single plan, is not so different from the method I did with two, I will continue using the Vram AutoInc at 32, but I must modify the code for filling polygons, and should be as fast as the current method (at least I hope) using "move.l dx, (ax) +", and also with the advantage that use half Vram space than needed in the other method (for a resolution 256 x 160, it uses 20KB as it should be). Although for now it's just an idea, I will give more details of this when I already have implemented.

I have seen the mini game in "mode 7" of Pier Solar, but only on video, is impressive, although the video quality is not very good, seems to have a good framerate and appears to have low vertical resolution (the same pixel every two lines) or at least that's what I see in the video.

And on the "Mode 7" I'm doing right now, do not use any tables, only code (I think it does not reach 10KB), then I will use tables to enhance the maximum possible (though I do not think it will be greater than 500KB). 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.

Although I'm not sure if this will work in Flash Carts (like (Mega)Everdrive), at least in emulators work correctly.

tomaitheous: So Hu-zero uses pre scaled graphics, that's what I had thought, thanks for clarifying.

[TmEE co.(TM)]

No flashcart I know of supports word-wide oncart RAM.

[Chilly Willy]

No flashcart I know of supports word-wide oncart RAM.

The extended SSF2 mode of the MegaEverdrive lets you use all the DRAM as ram, among other things. Note that it's only writable from the 68000. The SH2s in the 32X cannot write the cart space (as you determined so long ago).

[TmEE co.(TM)]

I need to send you the SRAM cart, so fun can be had

[Chilly Willy]

I need to send you the SRAM cart, so fun can be had

I almost forgot about that. How's the design on that working out? I know that writing from the SH2 isn't going to happen (made clear with the scanning of the 32X service manual the year before), but writing from the 68000 and being able to read with the SH2 is still useful. That's how the MED handles it.

[TmEE co.(TM)]

68K can do anything to the memory, and the design is final to say so. Just a nice slab of 4MBytes FAST SRAM. You could try to play with the ROM access speed registers of SH2 and squeeze extra out (in hope the rest of the hardware around SH2 can keep up ). Those chips on it are rated for 50MHz accesses ~~~

[Stef]

Stef: The method I'm thinking of doing to use DMA and a single plan, is not so different from the method I did with two, I will continue using the Vram AutoInc at 32, but I must modify the code for filling polygons, and should be as fast as the current method (at least I hope) using "move.l dx, (ax) +", and also with the advantage that use half Vram space than needed in the other method (for a resolution 256 x 160, it uses 20KB as it should be). Although for now it's just an idea, I will give more details of this when I already have implemented.

Actually i searched a solution for that : use DMA and require only a single plan with a single buffer, all these and still allow a fast software filling code (12 cycles per move.l instruction) but i did not found any solution :-/
If you got it then congrats ! It will be the ultimate bitmap software engine I sincerely wish you a great success with it !

I have seen the mini game in "mode 7" of Pier Solar, but only on video, is impressive, although the video quality is not very good, seems to have a good framerate and appears to have low vertical resolution (the same pixel every two lines) or at least that's what I see in the video.

Oh vertical resolution is doubled ? i never noticed it :p
And given the number of line used it means the vertical resolution is indeed very limited

And on the "Mode 7" I'm doing right now, do not use any tables, only code (I think it does not reach 10KB), then I will use tables to enhance the maximum possible (though I do not think it will be greater than 500KB).

It's nice to have code not using tables or keeping them low, even 500 KB of table is a bit big, but if that is generic tables which can be use to whatever is the map i guess it's ok. The problem with Pier Solar is that table was per map (sort of pre transformed map), so the more map you have, the more tables you need !

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.

I understand the idea but given how you update the map i think fast movement will be tricky to handle as you need to upload many new tiles (and so use many bandwidth). Still i think that is the fastest method to get fast mode7 rendering. Using real tiles + a tilemap would require much more computation to find the final pixel value (even by using LUT)

[Chilly Willy]

68K can do anything to the memory, and the design is final to say so. Just a nice slab of 4MBytes FAST SRAM. You could try to play with the ROM access speed registers of SH2 and squeeze extra out (in hope the rest of the hardware around SH2 can keep up ). Those chips on it are rated for 50MHz accesses ~~~

Neat. The SH2 has four address selects, and each region has its own timing control. The cart is the only thing its particular region, so anything messing with the timing of the cart for the SH2 shouldn't affect anything else.

The default timing for the cart area is 6 wait cycles, but conflicts with the 68000 or other SH2 could add 9 extra cycles. So the normal timing of cart reads is 2+6, or 8 clocks (assuming no extra waits). Since the 32X is clocked at three times the 68000, and the 68000 normally takes 4 clocks, the SH2 normally reads the rom in 8/12ths the time the 68000 does (50% faster).

I imagine that's probably close to the DMA read speed, and close to what normal roms of that time could handle. Remember that the DMA reads are faster than normal 68000 reads, and that old roms weren't fast enough, prompting Sega to tell devs in the manual to copy data from the rom to ram with the 68000, then DMA it from there. Devs only started DMAing directly from rom when rom speeds got faster.

[Kabuto]

During "Overdrive" development we ran across a strange DMA related bug which later went away after a rewrite of that code section, but nonetheless I did some digging to find it, following an IRC chat.

The code in question initiated CRAM DMA with pre-loaded registers as in "move.l d7, (a6)" (d7 = $C0020080, a6 = VDP control port) - one of the tested MDs didn't like that and one out of every maybe 5000 DMAs failed and seemed to just write $FFFF instead of the ROM contents it was supposed to read. But since we were using a simple flash cartridge which has for sure much faster access timings than what any MD developer back in the days could dream of, this specific bug must be unrelated to ROM access timings and is probably only related to the 2 control port writes (each half of the long) happening so shortly one after another.

Furthermore, Sik points out that the bugs only occurred on lines where the DMAs (during temporary blanking for their duration) happen to occur late, due to timing issues (IRQ waiting for the interrupted instruction to finish -> jitter, z80 stealing bus cycles -> even more jitter). Maybe the VDP's refresh cycles play a role, too, if they occur just inbetween those 2 word writes.

[Chilly Willy]

During "Overdrive" development we ran across a strange DMA related bug which later went away after a rewrite of that code section, but nonetheless I did some digging to find it, following an IRC chat.

The code in question initiated CRAM DMA with pre-loaded registers as in "move.l d7, (a6)" (d7 = $C0020080, a6 = VDP control port) - one of the tested MDs didn't like that and one out of every maybe 5000 DMAs failed and seemed to just write $FFFF instead of the ROM contents it was supposed to read. But since we were using a simple flash cartridge which has for sure much faster access timings than what any MD developer back in the days could dream of, this specific bug must be unrelated to ROM access timings and is probably only related to the 2 control port writes (each half of the long) happening so shortly one after another.

Furthermore, Sik points out that the bugs only occurred on lines where the DMAs (during temporary blanking for their duration) happen to occur late, due to timing issues (IRQ waiting for the interrupted instruction to finish -> jitter, z80 stealing bus cycles -> even more jitter). Maybe the VDP's refresh cycles play a role, too, if they occur just inbetween those 2 word writes.

Isn't that just the "last bus cycle must be from ram" bug the VDP has that everybody knows about? That's why the that last opcode you give above is usually "move.l (sp)+,(a6)" instead.

[Stef]

Isn't that just the "last bus cycle must be from ram" bug the VDP has that everybody knows about? That's why the that last opcode you give above is usually "move.l (sp)+,(a6)" instead.

Yeah but that problem was related to ROM access speed so if you have a ROM with blazing fast access timing you should never need it... Anyway, that may indeed fix the issue but it means that not only related to the ROM access speed in this case.

[Chilly Willy]

Isn't that just the "last bus cycle must be from ram" bug the VDP has that everybody knows about? That's why the that last opcode you give above is usually "move.l (sp)+,(a6)" instead.

Yeah but that problem was related to ROM access speed so if you have a ROM with blazing fast access timing you should never need it... Anyway, that may indeed fix the issue but it means that not only related to the ROM access speed in this case.

I'm sure that bug probably has quite a few conditions that affect it, with rom speed only being the major issue, but not the only one.

[gasega68k]

Actually i searched a solution for that : use DMA and require only a single plan with a single buffer, all these and still allow a fast software filling code (12 cycles per move.l instruction) but i did not found any solution :-/

I can give you a hint: you need two address registers.

About the mode 7, I had forgotten to mention that currently am using double vertical resolution (the same pixel every 2 lines) with a size of 256 x 96 (48 in vertical) and am getting 26-27 fps. I am already implementing the "scroll mode 7" (already working the vertical scroll and is still with 26-27fps).

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 !

Although I'm not using tables right now (to improve performance), I think it is fast enough to do some games with this, and although it has double vertical resolution, not really notice it so much when moving, of course you can do more resolution (or each line), and even more if improved performance 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.

Maybe I'm showing this demo tomorrow or Wednesday.

Meanwhile here are some screen shots:
http://www.mediafire.com/view/iyj69376a ... e7_000.png

http://www.mediafire.com/view/ofopoo0kr ... e7_001.png

http://www.mediafire.com/view/a6h1c0d41 ... e7_002.png

[Chilly Willy]

A mode 7 style racer? Slick. We might cart a decent cart game on the Genesis finally.

Be sure to start another thread for this.

[Stef]

Actually i searched a solution for that : use DMA and require only a single plan with a single buffer, all these and still allow a fast software filling code (12 cycles per move.l instruction) but i did not found any solution :-/

I can give you a hint: you need two address registers.

Haha, ok i see the idea, you use 2 different address registers for destination with the filling code ? i will think about it

About the mode 7, I had forgotten to mention that currently am using double vertical resolution (the same pixel every 2 lines) with a size of 256 x 96 (48 in vertical) and am getting 26-27 fps. I am already implementing the "scroll mode 7" (already working the vertical scroll and is still with 26-27fps).

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 !
...

That is really impressive thinking that you are not even using any precomputed tables ! The thing is that, unlike the SNES mode 7 which use 8bpp pixels (for obvious speed reason), here the display is done with 4bpp pixels and so the horizontal resolution is doubled as you still require to compute pixel per byte as well (again for speed reason).