SNASM2 Debugger vs. Cross Products MegaCD kit

Wow! You have made tons of progress! I know I keep threatening to set mine up but everytime you post brings me that much closer. Just need to clean off the table which has other projects that need to be finished...

 

I'll type up the entire setup process (with a demo video) in a blog post, hopefully you can follow it and correct any of my mistakes

 

Ok, the alignment headache is now over, it was a dumb user error (memmap.asm had a rogue "CNOP 0,16" back from when I was trying all sorts of desperate things to solve the problem, this was months ago!). I still don't quite get how CNOP calculates the boundary, I'd have thought a 16 byte alignment would be good enough for anything, but it just seems to generate odd offsets.

In any case, my code and data is now well organised, and the only help is from an EVEN after any data which includes some single bytes (strings, character map, etc).

Next problem: VDP locks up on first VInt. So far I've been stepping one line at a time to load palettes and tiles and blat some text on screen, as soon as I let it run on its own it finally hits what I assume to be the first V interrupt and hangs. I've tried with IRQs off, trimmed down my interrupt routines to just RTE, reviewed each bit of every VDP register in detail (took all evening!) with the help of this wonderful tool: http://www.pascalorama.com/article.php?news=28&cat=21, but so far no luck.

Also, this is without any VDP interaction at all, my main loop just does 68k stuff. All I've done is init the VDP regs and cleared VRAM with a DMA fill, so the whole thing should be blank.

 

Wow, ok, this is a weird one: if I bring up the memory view and look at the vector table, the HINT is 0x0000FFFF! Just that one, all the others have sane addresses. I've tried replacing with a blank one, setting it the same as the VINT, but it's always FFFF!



Go home, SNASM68K.EXE, you're drunk!

 

Damn, this might be bad memory I can't live edit it in the memory window. I can edit all other values, but this one refuses to change.

Hardware guys, what do I do?

 

Ask Nemesis how to setup that properly...

There's some sort of "masking" hardware on the MEGA-CD gate array chip which allows for patching that particular interrupt vector (It exists so games can set different kinds of interrupt handlers for that particular interrupt vector, I believe).

 

I've dropped him a message asking him to chime in. Thank you!

 

Ok I've had a thorough read around, and it seems to be the MegaCD interfering even though that part of the hardware is switched off, and the DIP switches have it disabled.

I've experimented with trying to put the unit in a "Genesis + MegaCD" mode that allows me to load up my ROM into the Genesis area (see memory map below) but allow the MegaCD BIOS to run, figure out there's a Genesis ROM ready and let it run, but I can't get it to load in the correct place (I still see a mirror of the MegaCD startup code at 0x40000, even though it seems to have copied from the PC successfully).

I am making some assumptions here about what happens if you have the MegaCD installed and turned on, but have a cart in the Genesis. On my retail unit this runs the cart, I'm trying to figure out the process.

There's a few DIP switches of interest: "Enable startup from debugging ROM" and "Enable mapping of RAM into 0000-FFFF", both of which have been enable so far, I've tried all combinations of them to see the results.

Explanation from the manual:

"The main CPU normally boots from a ROM in the MegaCD. If DIP 8 is enabled, then this ROM is mapped to 40000 and RAM is mapped to 0. This allows different BIOS ROMs to be sent to the unit without changing the ROM."

I've also tried unhooking the Genesis-to-MegaCD connector on the side to see if I can force it to just be a Genesis, but I lose SCSI connectivity

Some refs I've found so far:

https://code.google.com/p/genplus-gx/source/browse/trunk/source/mem68k.c?spec=svn706&r=706
http://www.angelfire.com/ny/dezmoowu/Sega/progscd.txt
http://www.assemblergames.com/forum...OS-1-10-US-from-Cross-Systems-Mega-CD-Dev-Kit
http://www.assemblergames.com/forum...Multimegas-CDX-s-Wondermegas-and-X-eyes-are-w
http://forums.sonicretro.org/index.php?showtopic=15793&st=45
http://forums.darkmystics.com/showthread.php?t=1785&page=2
http://www.assemblergames.com/forum...SM-CD-Installation-Manual-05-1993-Version-1-0


Memory map - I presume I should be seeing my ROM at 0x00FF0000:

Memory map of the MAIN CPU
--------------------------

000000-01ffff : BIOS ROM
020000-03ffff : SUB CPU Program RAM - bankswitched in 4 * 128K blocks.
(see later)
200000-21ffff : SUB CPU 'WORD RAM' - 128K (when in 1M mode)
200000-23ffff : SUB CPU 'WORD RAM' - 256K (when in 2M mode)
a12000-a120xx : GATE ARRAY.
ff0000-ff???? : MAIN CPU Program/Data RAM.

 

Few things I know which I can say:

When /CART is low, whatever is connected to the chip enable from the expansion port is mapped to 0x0400000. That's normal and it's a behavior defined by the bus arbiter chip on the Mega Drive itself. The games and programs which use the MEGA CD by themselves use that behavior to be able to load the sub CPU program from the MEGA-CD BIOS.

To have RAM in place of the ROM all it takes is swap the enables (considering the RAM has all of the required supporting circuitry in place). Considering the fact that the enable signal for it is generated at the MEGA-CD gate array, the fact that you have mapped the ROM BIOS or a RAM bank doesn't matter. The interrupt vector masking hardware is inside the gate array and it will be placed in front of whatever you have mapped on the devkit (as per dipswitch settings).

Find a rom for the FLUX music player cartridge and disassembly it. You will see how it checks for the MEGA-CD BIOS at 0x0400000, send it to the sub CPU and then turn the CD drive on.

All /CART do is swap around the top and side slots on the bus. When a cartridge with a program in it is connected to the cart slot but does not drive the /CART signal low, it will show at 0x0400000 on the 68000 BUS.

 

OK, that makes some sense. I'll take a look at the FLUX disassembly then.

One thing to note: if I send my ROM to the SUB CPU instead of MAIN CPU, everything seems to show up in the right place - my vectors are correct (including VINT), the PC is on the correct initial address and the debugger knows how to map my source, but letting it run just locks up (I've implemented the SUB CPU debugger setup code as shown in the manual).

I wish I could just put this thing into a pure Genesis mode

 

Well you know you have to make code that run on the TWO CPUs, right ? What I was talking about pertains to the CPU in the Mega Drive, not the SUB CPU. The SUB CPU is aways running in full RAM. It has no ROM of it's own and it has no direct access to the Mega Drive BUS so it can't read the cartridge directly.

 

As far as the SUB CPU is concerned, does it see 0x00000000 as 0x00400000? If I load the ROM onto the SUB CPU, my vectors show up correctly when I bring up the memory window and look at 0x0.

 

The SUB CPU do not see the MEGA DRIVE memory at all. They communicate through a couple of registers on the gate array chip and they transfer chunks of data through the WORD RAM buffer.

 

Yes! Found the holy grail of documentation, right here: http://koti.kapsi.fi/~antime/sega/md.html

...and this is of significance:



So I guess I could shove my HINT address into 0x00A12006. I'll give it a try today

 

Sounds about right ! Glad to see you're getting somewhere now !

 

Woooo! Found an example here: http://pastebin.com/hmZqUwv9 - it looks like some sort of MegaCD-to-Genesis bootloader, possibly similar to what FLUX does on startup.

I've narrowed it down to:

move.l #SubCPUInt, (0xFFFFFD08).w
move.w #HBlankInterrupt, (0x00A12006).l
move.l #SubCPURet, (0xFFFFFD0E).w

SubCPUInt:
bset #0x0, (0x00A12000).l


SubCPURet:
rte


which results in the HINT showing correctly in the memory window



Unfortunately it still hangs, but now I have loads more resources to sit and read so hopefully I'll figure it out one microstep at a time

 

Dumping my references, I'll continue during the week:

http://gendev.spritesmind.net/forum/viewtopic.php?t=420&sid=95bf2f3d66504a8a38d1e82d67de7f27
https://code.google.com/p/genplus-gx/issues/detail?id=287
http://pastebin.com/hmZqUwv9
http://forums.sonicretro.org/index.php?showtopic=30588
http://www.retrodev.com/segacd.html

I've a feeling there's no real way to make the Genesis/MegaCD combo behave in a pure Genesis way I think I'll need to get the MegaCD up and running properly and make a bootloader, something I was hoping to avoid since I'm only interested in Genesis development for the moment.

EDIT: Just discovered "System Mode 1"...



This looks just the ticket! The "Begin interrupt processing" bit is probably the missing link, causing my lockup.

I can do all of that from cart, and not need a CD image. I'll look at making a bootloader which does all of this.

More refs:

http://www.sega-16.com/forum/showthread.php?19657-SEGA-CD-Mode-1/page5
http://gendev.spritesmind.net/forum/viewtopic.php?p=14320#14320

 

System mode1 is what FLUX is using.

 

Aaaaaaand we are done here!

Turns out correcting the HINT is all I needed, the hangup was down to my VDP registers being incorrect (for the eighth time...) plus my power adapter not having enough juice. I found from the Cross Products manual that it needs one 9v 3a (connected to the top socket only), two standard Genesis bricks (850ma, I think) won't cut it.

Here's everything I've learned to get this kit working, and for my code to be "real hardware compatible":

Problem 1: BIOS

- Turn off anything mentioning 'shadowing'
- Set Bus Speed to 7.19mhz or 7.16mhz - this is the biggie, it fixes incompatibilities with old ISA cards, found here:http://www.oldskool.org/guides/oldonnew/cripple
- Enable ISA Line Buffer

Problem 2: Debugger setup code in subroutine

I tried being neat and tidy by shoving the debugger init code (see post #8 above) into a subroutine in another file. I think messing with the vector table in this way fudges something and the return address for the PC gets lost. Inserting it inline with my code worked. I might experiment with an inline 'include' to keep this block out of my nice clean init code.

Problem 3: The TMSS

Although polling the machine version returns >1, writing the 'SEGA' TMSS crashes the machine and I lose SCSI connectivity. All other exceptions I've seen handle correctly and just halt the CPU, but this one seems to be a special case. I'll revisit a better way to detect machine version/write TMSS when I get my UMDK (I'll need it running on a retail machine to figure it out).

Problem 4: Status register

In my framework init code I set the status register to 0x2700, which disables the trace bit (required for the debugger to poll states). It turns out changing this, even to what I consider the correct value, causes the system to lock up. It's ALWAYS initialised to 0x2700 when starting the machine so I'm just going to leave it be, and hope that's not just a nicety of the devkit/SNASM. Again, I'll waiting for my UMDK to figure out this one.

Problem 5: Resetting the kit

There were many resets, since I made many mistakes, but it was only after a while I realised that hitting the OFF switch didn't reset the machine as I'd expect - when turning back on the registers would hold their old values (the Status register was the main problem), some recognisable patterns would still be in RAM, and occasionally it would refuse to accept my binary and shut down the SCSI link. Using the debugger's "Reset Processor" option after turning the machine back on became a worthwhile habit.

Problem 6: You can't single step over the TMSS write

My educated guess is this: Writing the TMSS string prompts the hardware to load a new ROM to display the "Produced by or under license from SEGA Enterprises..." screen before returning to user code. The process is probably something like:

• Backup regs
• Jump PC and run
• Restore regs
• Return PC

This more than likely cuts the trace bit on the status register, so the debugger instructs the machine to "run instruction then halt" then sits and waits for the trace after the op has completed, which will never arrive, causing a deadlock.

Problem 7: Alignment

I was getting increasingly worried that after making very subtle changes (adding/removing a palette, putting a new variable in my memory map) I'd end up with spurious results - previously working code would crash with no indication of what's wrong, freezes and lockups all over the show, and I was terrified that it may be the old hardware (temperature of the caps, power issues, dry solder joints, etc). After some messing around I think my problem is alignment, something which has tripped me up in the past but I've managed to solve with a few NOPs, but now's probably the time to educate myself. I have no idea what I'm doing here, my only experience with alignment is from a C side (vector/matrix alignment for hardware float ops, audio data buffers, etc) but I have no idea about PC alignment, why it matters, or what I'm doing wrong to break it. To the internet!

Problem 8: My initial VDP registers were ass

"Master System" mode was set for some reason (not picked up by emuators?), CRAM address didn't match what I was writing to, DMA settings were all kinds of wrong. I'll go through every single bit with a fine tooth comb this evening and make sure each one is correct, but for now I've copied them from the Sonic 1 disassembly.

Problem 9: VRAM needed clearing

Again, I've been spoiled by emulators and their clean initial state. The CRAM, VRAM and VSRAM were full of junk on startup, I've written some routines to clear them (I'll share in my next blog post).

Problem 10: The HINT vector gets hijacked by the MegaCD BIOS

The Cross Products kit is a MegaCD, and I'm trying to use it as a pure Genesis development kit, which means I need to jump through a few hoops. The HINT vector gets set to 0xFFFF on startup by the MegaCD part of the hardware (assuming BIOS) and needs putting back via an MCD register:

move.l #SubCPU_int, (0xFFFFFD08).w
move.w #HBlankInterrupt, (0x00A12006).l
move.l #SubCPU_rte, (0xFFFFFD0E).w

SubCPU_int:
bset #0x0, (0x00A12000).l


SubCPU_rte:
rte


Problem 11: My initial VDP registers were ass (again)

I had the Window Plane and Sprite Attribute Data memory area overlapping, so when trying to copy a sprite the VDP hung. I've taken a working set from Nemesis' Sprite Masking test ROM at: http://segaretro.org/Sprite_Masking_and_Overflow_Test_ROM

Problem 12: The wrong power brick

I had wrongly assumed the unit required two standard Genesis power adapters (9v @ 850ma) like my retail machine, but the Cross Products manual states it needs just one in the top socket, which needs to be 9v @ 3a.


All working now! I knocked up a quick and dirty Pong clone to check everything is working (H/VINTs, my timer code, gamepad input):



Full source here: http://www.mediafire.com/download/h4qmqf65eoki7yb/MD_PongTest.zip

To assemble for the SNASM2 debugger:

snasm68k.exe /i /sdb /z pong.asm,pong.cof

To assemble a normal ROM:

snasm68k.exe /p pong.asm,pong.bin

Thank you so much to everyone who helped out, I finally have everything I need to start writing my game!

 

The MEGA-CD BIOS hijacks the WHOLE CPU vectors. That remapped word you're talking about is done by the MEGA-CD ASIC. Be glad it exists otherwise you would only be able to use software hooks.

Also if you're talking about the plain text only TMSS screen which shows up when you boot cartridges, I am sure it replaces the CPU vectors through memory remapping (address lines and control line toggling). I bet that takes the control away from the debugging hardware.