wolfenstein demo for sega genesis

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

Post by Kabuto » Mon Aug 26, 2013 7:09 pm

On Pal MD with RF output 101010-like patterns are perfectly blurred as well, probably to avoid luma/chroma crosstalk.

You could also trade resolution for speed by halving vertical resolution:
* Either render at halved vertical resolution, then DMA that to the VDP, then reduce vscroll by 1 every 2nd row so the plane is stretched vertically by a factor of 2.
* Or DMA the gfx with a transparent line between each pair of lines, set both planes to the same tilemap, shift one of those vertically by 1 pixel so you'll get doubled pixels for free (except that the 3d view requires both planes now)

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Mon Aug 26, 2013 9:08 pm

I just discovered a bug in the code that could cause the 68000 remains in an infinite loop. See this piece of code (The 68000 code is runing During VBLANK):

Code: Select all

     z80 code:

        ld  (hl),$ff        ;$1ff0
        ld  (ix+0),$2a      ;$4000
        ld  (ix+1),a        ;$4001  => out
        ld  (hl),$00        ;$1ff0


   68000 code:

ym2612wr:
   ; a0 = $a04000

   move.w #$100,$a11100    ;busreq on
   nop
   nop
   nop
   tst.b $a01ff0          ;z80 = $1ff0
   beq.s wait1         ;0 = write to ym2612 regs
   clr.w  $a11100
   nop
   nop
   nop
   nop
   nop
   bra.s ym2612wr

wait1:
   tst.b  (a0)        ;waitstatus
   bmi.s wait1
   move.b d0,0(a0,d2)
wait2:
   tst.b  (a0)        ;waitstatus
   bmi.s wait2
   move.b d1,1(a0,d2)
   clr.w  $a11100      ;move.w #$0,$a11100      ;busreq off
   rts
If you look at the code for the z80, before sending a data to the output register, I write a $ff to $1ff0, write the value data and then set 0 to $1ff0. Then in the code of 68000, only when this value is 0, the 68000 can write to the YM2612 regs. This is just to prevent both processors simultaneously write the regs YM2612.

The error I mentioned before, would happen when you're loading a sample on the z80 ram.
This is what might happen: when you're loading a sample to the z80 ram, this is stopped and then the sample is loaded. But what if at the time of stopping the z80 this had written a $ff to $1ff0 then an interruption of VBLANK happens?. When the 68000 go to tfc player, it will remain in an infinite loop because it always would read $ff at $1ff0 causing the game to freeze.
Let me fix this and then I'll upload a new version of the rom that also will include some other things.

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Mon Aug 26, 2013 9:09 pm

I just discovered a bug in the code that could cause the 68000 remains in an infinite loop. See this piece of code (The 68000 code is runing During VBLANK):

Code: Select all

     z80 code:

        ld  (hl),$ff        ;$1ff0
        ld  (ix+0),$2a      ;$4000
        ld  (ix+1),a        ;$4001  => out
        ld  (hl),$00        ;$1ff0


   68000 code:

ym2612wr:
   ; a0 = $a04000

   move.w #$100,$a11100    ;busreq on
   nop
   nop
   nop
   tst.b $a01ff0          ;z80 = $1ff0
   beq.s wait1         ;0 = write to ym2612 regs
   clr.w  $a11100
   nop
   nop
   nop
   nop
   nop
   bra.s ym2612wr

wait1:
   tst.b  (a0)        ;waitstatus
   bmi.s wait1
   move.b d0,0(a0,d2)
wait2:
   tst.b  (a0)        ;waitstatus
   bmi.s wait2
   move.b d1,1(a0,d2)
   clr.w  $a11100      ;move.w #$0,$a11100      ;busreq off
   rts
If you look at the code for the z80, before sending a data to the output register, I write a $ff to $1ff0, write the value data and then set 0 to $1ff0. Then in the code of 68000, only when this value is 0, the 68000 can write to the YM2612 regs. This is just to prevent both processors simultaneously write the regs YM2612.

The error I mentioned before, would happen when you're loading a sample on the z80 ram.
This is what might happen: when you're loading a sample to the z80 ram, this is stopped and then the sample is loaded. But what if at the time of stopping the z80 this had written a $ff to $1ff0 then an interruption of VBLANK happens?. When the 68000 go to tfc player, it will remain in an infinite loop because it always would read $ff at $1ff0 causing the game to freeze.
Let me fix this and then I'll upload a new version of the rom that also will include some other things.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Aug 26, 2013 9:31 pm

You can disable vint the time you upload sample to Z80 by setting SR to $2700 and restore it as soon sample is uploaded. Quick workaround for that type of "int timing weird issue". Well done for discovered the bug, it would have be really difficult to trace it ;)

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Mon Aug 26, 2013 10:37 pm

Thanks stef is so easy, I'll do it that way, had thought of another way (not very good :oops: ).

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Tue Aug 27, 2013 2:19 am

About the bug mentioned earlier, I was wrong. The 68000 does not would remain in an infinite loop, but could cause an even greater problem. When the 68000 is in this loop trying to write to the YM2612, will be permanently activating and deactivating the z80, so eventually the value of $1ff0 will be 0, making it possible to write to the YM2612 regs, but when it returns from VBLANK, the z80 will be runing and the 68000 will continue loading the sample to z80. :shock:

 Anyway, setting SR to $2700 will fix the problem. :wink:

kool kitty89
Newbie
Posts: 6
Joined: Thu Aug 22, 2013 9:56 pm

Post by kool kitty89 » Tue Aug 27, 2013 5:28 am

Stef wrote: Yeah i know it is simplistic combinations but still sometime i really have hard time to figure them :p
Anyway thanks for the link, that would help me in future ;)
If you ever lose the link, just remember "permutations calculator" and it should come up in top search results. (there's a few other sites with similar calculators too . . . I just use that one most -it does tend to crash/hang once in a while though, at least it tends to after doing several comutations with multiple variables modified)
I agree, i don't know if it's the way gasega68k did his palette but i guess it the way to get a very strong one :)
BTW Tomaitheous is the one that put me onto that conversion method (12-bit dithered to 9-bit as well as the h-blur thing).
It was originally mentioned in the context of a Huvideo encoder he was working on (as a way to reasonably optimize images within the 9-bit color limitation), and in the specific context of using checkerboard dither in that case (so flipping the pixel pairs every other scanline), but the same thing obviously applies to a number of other cases where the method would be useful. (probably would have worked well for Sega CD FMV too . . . probably a better compromise than the much coarser dithering attempting to mimic higher color depths -ie 15 to 24 bits- and would probably compress better too)
Haha a doom port on Sega CD would be awesome, probably a bit laggy though :p But yeah having a good base palette is *very* important and actually does the difference, Duke 3D could look far better with a better base palette.
The context was kind of in line with what Super FX Doom did (ie totally custom ground up engine), though there was some speculation on whether it could actually be faster/better than Super FX Doom. (namely in the context of using the ASIC to accelerate rendering) Particularly considering the overhead of Super FX Doom using 8-bit planar tiles to render to and the trade-offs of having CD mass storage but limited RAM to use at a time vs the 2MB of ROM SNES Doom uses.
But don't you think that swapping pixels chunk at each frame would produce a better result that simple H pixel scroll ? This way you don't blend different "object" pixels together. Of course technically it is not as easy to do than the H scroll..
You're talking about using a checkerboard dither pattern right?
I agree that would look better for a static display (no h-blur at all), but wouldn't really look better than solid columns if blur was applied.

In fact, checkerboard dither actually tends to look worse than columns when blurring, since you end up with weird jagged fringes on the left/right end of objects. (and in NTSC composite, it also turns vertical rainbow chroma artifacts into much more annoying diagonal ones)
I'm pretty sure this is why checkerboard dither is used much more often in H32 (where pixels don't blend like that), and why a good deal of dither in H40 games tends to use vertical strips like that, especially for translucency effects. (there's some exceptions of checkerboard used in H40, but there's no examples of strippy/column dithering in H32 AFIK)

Oh, side note, the extra blurry Samsung KA2195D video encoder (common to NTSC model 2 Genesis) doesn't have noticeable chroma rainbow artifacts and also tends to blend both strips and checkerboard (in H40) very, very solidly. (so much so that I thought some games were using shadow sprites until I checked in an emulator or S-Video/RGB on another Genesis)
You obviously can't rely on this though. ;)



And Tiido voiced concerns over wiggle/jiggle being noticeable if you use Hscroll to blur things. But, honestly, I doubt it would be noticeable, or at very least not bothersome (any more so than interlaced displays are).
In H32 it might be more annoying (especially in 50 Hz), but for H40 it should be OK. (best in 60 Hz though)
It should really be no worse than any other 50/60 Hz flicker/shimmer effects. (either for translucency effects or faking more colors for a static image)
I could indeed make my polygon fill faster if i do byte alignment for filling operation but that reduce the X resolution and look really... "low resolution" compared to X full res.
I can make that optional to improve the performance if needed... actually you have only to take care of 4 bit pixel on polygon edge, i use byte fill for the inside, faster and allow color dithering :)
I'm pretty sure you told me this before in the Star Fox demo thread on Sega-16.

The different context here was that, if you were doing a column renderer, it would be considerably more of a pain since you'd have to manage individual pixels for every pixel drawn. (with horizontal line fill, you can do 4-bit stuff just on the edges and fill the middle with bytes, but column rendering won't allow that)
The point is moot in any case, since you already confirmed that column rendering wouldn't make drawing pixels in cell order any easier. (I thought that maybe you could organize tiles in 68k RAM such that you could render columns of pixels directly to that array of cells in a linear manner, and avoid the overhead of tile conversion)

I wasn't sure about how pixels are ordered in tiles (can't remember if I ever actually read about that actually), but it seemed implied that rows of pixels in a tile are not organized in a linear bitmap manner, so I thought the columns might still fit together in a linear manner with adjacent tiles. (ie you could write a column of bytes straight through tiles alligned vertically)

You are right, that is totally possible :) V int occurs at the start of V blank... so we can set the YM timer so it expire when blank area is about to start. We could image the Z80 code to check the YM2612 status at regular interval (each 500 Z80 cycles for instance) so the YM2612 tmer should be set accordling.

Then as soon the timer expire Z80 enter in a new code block where it does not access anymore the 68k bus for sometime. Depending PAL or NTSC mode, this period is longer.
Couldn't you also set the timer again (after it expires) for the duration of vblank (or rather the specific chunk of vblank that DMA is alotted -since PAL will have extra vblank lines) and when that expires the Z80 will know it can access the 68k bus again (and then set the timer to acount for the duration of the 68k bus being DMA-free, etc).

If you knew you weren't going to DMA every frame (which is the case here), you could have the renderer set up so that when a frame is complete and ready to be DMA'd to VRAM, you then signal the Z80 (maybe write to a designated status byte in Z80 RAM) that it's time to look out for vblank. So on many frames where DMA is unused, the Z80 won't have to do any watching.
You could do this in some other ways (like a frame counter on the Z80) if you used a framerate cap on the 68k end.


Also, the current set-up (with Z80 doing just sample playback), leaves a lot of Z80 RAM free for buffering, so you can use some long mixing buffers there).

kool kitty89
Newbie
Posts: 6
Joined: Thu Aug 22, 2013 9:56 pm

Post by kool kitty89 » Tue Aug 27, 2013 6:07 am

Kabuto wrote: You could also trade resolution for speed by halving vertical resolution:
* Either render at halved vertical resolution, then DMA that to the VDP, then reduce vscroll by 1 every 2nd row so the plane is stretched vertically by a factor of 2.
* Or DMA the gfx with a transparent line between each pair of lines, set both planes to the same tilemap, shift one of those vertically by 1 pixel so you'll get doubled pixels for free (except that the 3d view requires both planes now)
Yes, you could do that, but you'd end up looking much more like SNES Wolf 3D . . . though not QUITE as chunky. (smaller horizontal pixels)

Note that for ray casting, cutting vertical res doesn't help nearly as much as horizontal res. (vertical res cuts down on columns and thus rays to cast)
With that in mind, dropping to H32 and using a 208x128 window would probably be a better compromise if need be.

For a polygon renderer, cutting vertical resolution helps a bit more than horizontal, since that means fewer lines to draw (though doesn't cut on vertex computation, so not as helpful as cutting H-res in ray-casting).



Chilly Willy wrote:While the colors look great here for being dithered colors, it's a little easier than Doom would be because of the lack of shading. Doom maintains 32 shades of many of the colors used (look at a picture of Doom's palette and you'll see multiple runs of shades of the same colors). Doing Doom on a stock MD graphics might be possible, but you'd probably have to eliminate shading (or maybe cut it back drastically). Doom would be more a SCD project than a Genesis one. The SCD 68000 is more than capable of running the game logic - that's what the Jaguar version does, and its 68000 is just barely faster. You'd have to do most of the rendering on the Genesis side. You'd REALLY need to cut down the textures a lot - basically, someone would need to edit the Doom wad file and redo all the level and things graphics. It's a lot of work... much more than W3D.
Posterizing Doom's palette to 12-bit RGB should give you a good idea of how look-up based shading would work in dithered 9-bit color. (since you can approximate any 12-bit RGB color by blending 2 9-bit RGB colors)
I'll bet the actual color count of that palette will drop quite a bit from that truncation/posterization alone, quite possible low enough to fit into the 120 (or 136) psuedo color limit a 16 color palette allows. (so no further optimization required)

Of course, the shading itself would look worse than Doom's 18-bit color, and it would probably be better to cut the light levels to more like 3 or 4 (maybe 3 plus solid black) instead of 8 (SNES does 4, I think), but it should be workable. Besides that, it would also largely be the really far off objects that will be super poserized/desaturated from shading, so not that much detail loss as such.
You'd also probably want to make up completely new shading LUTs rather than just downconverting the PC originals directly.

Doing fewer shades would cut down on overhead too, more so if you opted for per-sector lighting like the 32x version. (which also avoids the super heavy posterization issue of gradient lighting in general -and you could modify light levels to stay within a reasonable color threshold too)
Also, the color is more complex than just considering two pixels... look at this

AB CD EF GH etc

That's how people are considering the pixels to calculate the colors. But that's rather arbitrary... it could just as easily be

A BC DE FG H etc
Yes, which is why you get little fringes on the left/right edges of objects. Which, in the case of composite video, is something you always get anyway to some extent. :p (and to lesser extent in S-video -and in chroma only)

In the Apple II, it's also not just blending, but actual color artifacting, so the order of the pixels matters as well. (why you get 4 unique colors from blending 2 colors, rather than the 3 unique possibilities from actual blending -and why you get 16 colors in high-res mode from blending 4 adjacent 2-color pixels)
Same as artifact colors in CGA or A8. (except CTIA and GTIA have different color artifacts, so it couldn't be used consistently -plus the A8 palette is big enough that using lower res 2-bit pixels is usually better anyway)


Chilly Willy wrote: So was I. On Doom, to draw at a particular shade, they merely pick 1 of 32 colormaps, each one presenting a particular shade. The colormap takes the texture pixel value as an index, and gives the new value that points to the same color at the proper shade in the same palette (assuming there is one). At really low light levels, many of the colors are pointed to the same values, giving the unsaturated look to dim parts of the level.
I thought Doom used 8 light levels, and 8 colormaps corresponding to that. (Quake used 32 though)
Of course, if you are outputting in 15bit color mode, you could make much more accurate colors at all the levels since you aren't limited to the 256 color palette. That's basically what the Jaguar version does, and many PC source ports when set for 15 or 24 bit mode.
The Jaguar does more than that, it uses the full 256 light levels possible in CRY. CRY uses 1 byte for lighting, so no colormaps to deal with at all,

As far as 15-bit color goes, you've got some limits there too compared to PC Doom, which I assume is why 32x Doom uses vertical line (strip) dithering. (though TBH, posterizing the palette to 15-bit probably wouldn't have looked much different at all)
Actually if they WERE going to do dithering like that, it would have been better to convert all the textures themselves to undithered 15-bit values, and then optimize any left over (redundant) color values around making a palette optimzied for smoother lighting via dithered pixels. (except if you're just doing per-sector lighting, that doesn't matter either)

Yetti 3D on 32x would be a good example of LUT based shading in 15-bit direct color though. (more so for the non-interpolated version, since the interpolation makes dither colors)



Stef wrote:Yeah doom use shade level, we cannot reproduce it the same way but Toy Story is actually using 3 shade levels for his 3D level and that does look great :) Palette is really heavily turned around gray, purple and green colors though.
Zero Tolerance is an example of doing gradient lighting with more colors. I'm not sure that's LUT based either. (it looks pretty decent too, especially when blended, and it looks like they manage at least 6 light levels that way -might be 7, probably not 8, but I could easily count 6)

And again, given the color loss you'd get from conversion down to 12-bit colors anyway, I doubt lighting would be much worse than what you could get from a proper 256 color 12-bit palette. (as it is, the limited number of pseudo colors generated might not be the limit so much as the 9/12-bit RGB limits in general)

Zero Tolerance also "cheats" like SNES Doom with untextured floors with a static shading gradient using lots of complex dithering (nor ordered, let alone 1x2 pixel pair).

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Aug 27, 2013 6:41 pm

Doom uses 34 colormaps: Colormaps 0 to 31 handle shading, with 0 being full light, and 31 being full dark. Colormap 32 is used for invincibility (rather than a different palette). Colormap 33 is no longer used, but was originally used by the light amp goggles.

And yes, I knew Jag Doom used CRY mode. It great for games that need lighting effects as it uses the same kind of palette entry as the old 8-bit Atari computers: a color field, and a luminance field. Most of the Jaguar lighting effects require CRY mode. Having 256 luminance levels means your lighting is very smooth - you don't tend to have the banding that you see in regular 15/16 bit RGB.

inu
Very interested
Posts: 50
Joined: Thu May 09, 2013 10:12 am

Post by inu » Thu Aug 29, 2013 6:15 am

Quite an amazing job so far indeed. Got to admit I never imagined such nice quality could be squeezed out of the stock Mega Drive\Genesis. Especially feeling so fluid. And even the music sounds pretty good already.

Duke Nukem 3D wasn't too bad, apart from the awful color pallet choice and the visible "tearing" but... what was with all the menus and different fonts, and that "planet background" and stuff?! Felt like quite a waste of resources.

For the people wondering just how different exactly do the different versions of the game look, here's an easy comparison between
(top) SNES edition running on higan (couldn't capture the same area as the levels are different),
(mid) this demo running on Kega Fusion,
and (bottom) the official free 3-chapter browser version available at the Wolfenstein webpage.

Image
Last edited by inu on Fri Aug 30, 2013 12:50 am, edited 1 time in total.

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Thu Aug 29, 2013 11:24 pm

Finally I'm here again with an update of my demo. Now the hud is working, even the animation of the face, and also did the player/hands weapon.

In the file I included some pictures: "player_weapon_original.bmp" is the original image (with size 2x), "player_weapon2x_.bmp" is the picture I made with 16 colors and "player_weapon2x_f.bmp" (is the image I use) I did it with a program to make it look better. What do you think, so leave it like this or use the other image that has no filter?. Or maybe I could use another (like the SNES)?

Download here:
http://www.mediafire.com/download/3xni8 ... soundb.rar

inu
Very interested
Posts: 50
Joined: Thu May 09, 2013 10:12 am

Post by inu » Fri Aug 30, 2013 12:19 am

Hi gasega68k, and thanks for the progress update.
Now with the game hud working, the game feels quite a bit more complete already!

I find the both the "player_weapon_original.bmp" and the "player_weapon2x_.bmp" look VERY good.
The "player_weapon_original" obviously has more faithful colors, but unless the "player_weapon2x_.bmp" was right next to it, no one would likely notice the small color and minor detail difference. Heck, at a first glance before reading what was what, I even liked the "player_weapon2x_.bmp" the most. So any of those 2 is a good choice.
The "player_weapon2x_f.bmp" is not so good as it blurs out the weapon details far too much. Plus since the levels look nice and sharp, the "blurry" weapon sprite feels a bit out of place.

And the SNES version is far too bad in almost every way to take anything at all from it, as it suffered from extreme censoring imposed by Nintendo, unlike any other release. The levels were also different I believe, they are the same as the 3DO and Macintosh edition. So, different sprites = different levels.
The DOS version sprites are the ones most people recognize, and associate with Wolfenstein 3D. They're on the official browser edition available for free at the Wolfenstein's webpage, and are used in the modern home consoles (PS3 and XB360) releases. Using any other sprites would likely make the whole experience feel quite awkward and weird, or even unrecognizable for a lot of people.

Of course, if your project goes really well and everyone loves the original Wolfenstein 3D for the Mega Drive, you can always make a 3DO\Macintosh\Jaguar edition and even a Spear of Destiny edition. It's pretty much the same game with different levels and sprites anyway.
Or jump into CD territory and simply have everything. So many options, so little time. :P

There is one "small problem" with this new version however. It no longer runs on Exodus 1.0.0! So I wonder how will it do on real hardware.

Edit: Feel free to correct me if I'm wrong. I'm not exactly super well informed about all the Wolfenstein 3D editions. That's just what I gathered from a little search.
Last edited by inu on Fri Aug 30, 2013 7:27 pm, edited 3 times in total.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Fri Aug 30, 2013 6:27 am

It urns on real hardware but I always need to do a reset first or it is stuck with black screen.

Sound is still messed up, and seems because you don't wait long enough between YM writes. EDIT: Which makes little sense as you wait for the busy flag...

You need to wait at least 8 Z80 cycles after Index write and at least 40 after data writes to $21...$9E or 25 to $A0...B6.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Fri Aug 30, 2013 10:49 pm

There is one "small problem" with this new version however. It no longer runs on Exodus 1.0.0! So I wonder how will it do on real hardware.
It urns on real hardware but I always need to do a reset first or it is stuck with black screen.
I can not test it on real hardware, nor I can use the emulator Exodus (I use 32bit windows), so I need your help to find where is the error, here I leave this file with previous versions to tell me which did not work well. See readme.txt.

http://www.mediafire.com/download/s5fbp ... o_prev.rar

About sound I will review the code to see if I find out that's what happens.

inu
Very interested
Posts: 50
Joined: Thu May 09, 2013 10:12 am

Post by inu » Sat Aug 31, 2013 12:45 am

wolfdemo_wsoundb.bin - it loads stuff on screen and as soon as the music starts it just suddenly goes to that "blank" screen. It works just fine on Kega Fusion (but think you already know that :P). The "FPS=" counter it's set to "00", but doesn't get to go up before the screen goes blank. During the blank screen fps drop to 26-30 from the usual 42 to 47 it runs at in the working versions (without any overclocking).

wolfdemo_wsound.bin - runs fine on Exodus
wolfdemo_wsound_FONT_PAL_.bin - runs fine on Exodus
wolfdemo_wsound_FONT_PAL_HUD.bin - runs fine on Exodus
TmEE co.(TM) wrote:It runs on real hardware but I always need to do a reset first or it is stuck with black screen.

Sound is still messed up, and seems because you don't wait long enough between YM writes. EDIT: Which makes little sense as you wait for the busy flag...

You need to wait at least 8 Z80 cycles after Index write and at least 40 after data writes to $21...$9E or 25 to $A0...B6.
Using RESET on the Exodus emulator doesn't seem to help like TmEE co.(TM) did to get it working on real hardware. Which is not very surprising.

Can also re-confirm the little sound issue TmEE found on real hardware is also present on the emulator.

EDIT: Image removed.
Last edited by inu on Wed Sep 04, 2013 2:54 pm, edited 1 time in total.

Post Reply