68000 memory map and the significance of address 0x1FFFF

[BigEvilCorporation]

Hi all!

I'm gearing up for a public release of my framework and editor, but I've hit a snag assembling large tilesets and maps (i.e., a test export of Green Hill Zone I was hoping to show off as a demo). The MD reads garbage at any address past 0x0001FFFF.

On my Cross Products kit the memory viewer shows data past this address as garbage, in Regen and Exodus I can see the correct data, but none of them seem to be reading it correctly with a MOV.

Is this address significant? It was my understanding that CART space was 0x00000000 - 0x001FFFFF (another 2mb's worth before I should be running into trouble).

Obviously I could compress all of this and fit it in range, but I'd love to understand this problem first.

[Natsumi]

you can not DMA in multiple 128KB areas. In fact 0x20000 is another 128KB bank, therefore the DMA breaks and reads from 0 for bytes past 0x1FFFF, as far as I am aware. This can easily be fixed by making sure no DMA'd data is in 2 128KB areas in ROM.

[BigEvilCorporation]

I'm not using any DMA here (the EPROM in the Cross Products kit is too slow), just a manual loop copying longwords. I'll certainly bear it in mind when I switch to DMA for the final ROM though.

I've checked various docs for mentions of the address, looking for boundary problems and whatnot. I wonder if it's a limitation of the assembler itself (SNASM68K, 1995 version), perhaps it can't INCBIN across this boundary?

[Natsumi]

I am not sure about SNASM68K, all I know about it is, that I cant even run that assembler in my Win7 64-bit machine. As far as I know the assembler is known for being... bad, at least on Sonic hacking scene. I may be biased, but I'd suggest to use ASM68K (Nemesis version, it fixes lots of issues and makes it easier to run in general).

As far as manual loops, it should work pretty much always, considering you have correct amount of repeats. However, have you made sure you have correctly decompressed the art file? I can confirm that loading data manually on 128KB boundaries should have no issues, as I do that more or less often with my Sonic hacks, especially as of late since I shuffled a lot of data around.

Its quite hard to say off the top of head, if it isn't DMA, would have to really see some code or be able to debug the ROM to say for sure.

[BigEvilCorporation]

As much as I'd love to change assembler, nothing else is compatible with the Cross Products kit and its debugger's format.

There's no compression happening, that's next on my TODO list. Just raw bytes at the moment.

I'll do some more experimenting when I get home.

[Sik]

I am not sure about SNASM68K, all I know about it is, that I cant even run that assembler in my Win7 64-bit machine. As far as I know the assembler is known for being... bad, at least on Sonic hacking scene. I may be biased, but I'd suggest to use ASM68K (Nemesis version, it fixes lots of issues and makes it easier to run in general).

It isn't bad, it's just that it's a DOS program. Switching to asm68k shouldn't be an issue since it's pretty much a later Windows version.

[BigEvilCorporation]

I am not sure about SNASM68K, all I know about it is, that I cant even run that assembler in my Win7 64-bit machine. As far as I know the assembler is known for being... bad, at least on Sonic hacking scene. I may be biased, but I'd suggest to use ASM68K (Nemesis version, it fixes lots of issues and makes it easier to run in general).

It isn't bad, it's just that it's a DOS program. Switching to asm68k shouldn't be an issue since it's pretty much a later Windows version.

I'd need the correct SNBUG68K.EXE to go with it, which wasn't on the Psy-Q disks this version was rescued from (I suspect they only wrote a matching debugger for their own Psy-Q interface cards). The COFF format is different. I'm afraid I'm stuck with the 1993 or 1995 versions from SN.

In any case, I'm not 100% sure the assembler is the real cause here. I'm using the complete SNASM2 kit and toolchain on an MSDOS machine built for the job, so I'm not seeing the kind of problems others are having with it.

[BigEvilCorporation]

Ok, I've found a few references. This page:

http://www.angelfire.com/ny/dezmoowu/Sega/progscd.txt

says the area 0x00000000 - 0x0001FFFF is the MegaCD BIOS, and the manual says there's a jumper to use this area as RAM:



This jumper has been ON far, which means my ROM fits in that space and nothing after 0x1FFFF gets read. Unfortunately setting that to OFF means the MegaCD BIOS now resides here and the debugger fails to upload the binary.

Trying to get this kit to function as a pure Genesis has been a headache so far, it doesn't surprise me that I've hit another problem! I've seen mention of ROM space being mirrored to another address space, I'll see if I can dig that out and try putting my data there.

I'll keep researching.

[BigEvilCorporation]

Right, I think this is because there's no way to force the machine into thinking the /CART pin is down, so it's giving me the MegaCD memory map and no room for Genesis ROM space.

Unfortunately inserting any old cart causes the thing to lock up

[Sik]

Because then cartridges will try to impose their ROM =P (you need to make only /CART_IN get asserted, nothing else)

Idea if you can live with not treating any addresses in a special way (i.e. you can afford to move everything to $400000-$7FFFFF, even if just for testing): try to get the program bootable as a mode 1 program so the Sega CD firmware decides to boot that. I don't remember exactly the details though (but this may be useful).

...what are you using though, because if the kit doesn't provide more than 128KB of RAM then you're screwed either way.

[BigEvilCorporation]

Mode 1 was the first route I went down until I discovered the magic DIP switch combo to give me this 0x00000000 - 0x0001FFFF range, I guess I could pick up where I left off and see if I can get it working. It's massively complicated getting both CPUs to show up in the debugger though, which would be a right pain for regular development. I'll see what I can do.

Perhaps knocking up a cart which asserts just that pin might do it. I have some spare boards somewhere, I could just scratch off all the other tracks.

Worst case scenario; I continue development with small test levels, and only build the complete game ROM for emulator/burning to carts. I guess it's not the end of the world.