SpritesMind.Net

I finally finished my Genesis devcart. Here are the specs:

- 1MB Flash (for boot program)
- 4MB SRAM (using eight 512x8 parts)
- 32K battery backed SRAM for save games
- High speed USB interface (~250k/sec via FTDI FT245 chip)
- IDE connector for mass storage

Some videos:
http://www.youtube.com/watch?v=ZjZi7p91kX4
http://www.youtube.com/watch?v=uL-TXOhWNKA
http://www.youtube.com/watch?v=IaT1Dn4IgVU (USB FMV streaming example)
http://www.youtube.com/watch?v=jYaSsuRDn-k (IDE+HDD test)
http://www.youtube.com/watch?v=CdpblswblmY (IDE+HDD FMV streaming, constant 20fps)



In this picture, the tabbed CR2032 battery hasn't been soldered in yet and the wire jumpers still need to be removed. I had the boot ROMs in ZIF sockets during development to make them easier to reprogram. On the right edge is the IDE connector. As you can see one goal was to have as many parts socketed as possible for easy repair and troubleshooting.

I think 4MB was too much, the majority of the Genesis library is 2MB and there are only a handful of good 3MB games and very few 4MB games worth playing IMO. I've also found .300" low-power SRAMs aren't easy to find any more, perhaps allocating enough space for regular .600" SRAMs would have been better as they seem more common. I think if I make more of these, I would reduce the memory capacity and use more widely-available chips.

In general it's very convenient for programming because you can load data into the SRAM almost instantly, unlike with Flash where you have to erase and reprogram. I'm not knocking the Flash carts, but I like to test my software frequently so being able to assemble, upload, and test without flipping the power switch or pressing 'reset' every time was an important design criteria.

For those of you making your own, here are some of the challenges I discovered:

Some games like Beyond Oasis write to the banking registers at $A130Fx even though they don't really use banking. Maybe leftover code from the development environment.

Most games check for a cold boot by testing the data direction registers of the I/O chip. If your devcart's startup program uses the joypads, reset these registers or else the cold boot check will fail and many games do not work.

I used MRES# to disable the SRAM to prevent corruption, however the 68000 can generate spurious memory accesses during a reset triggered by VRES# (the reset button). It would be a good idea to disable SRAM when either MRES# or VRES# is low. I don't know how some games avoid this which only use MRES# to gate the SRAM CS signal.

Printing a ROM checksum was helpful when trying to identify some data bus conflicts, and the PC utility software checksums all incoming and outgoing data sent over USB. This way you can be sure about the integrity of data you've loaded or saved when trying to isolate a problem.

I buffered the data bus, address bus, and most of the control bus using 74AHCT245 transceivers. I've had other projects with minimal buffering which led to hard to diagnose problems later on. Just remember that you need to enable the data bus buffers when either CE0# or TIME# are low so both the 000000-3FFFFF and A1300-A130FF ranges are accommodated.

It uses a startup memory map for the boot program, and then three selectable memory maps for gameplay: 4MB ROM, 2MB ROM + SRAM, 4MB ROM + banked SRAM (for PS4). This allows most games with different memory maps to be supported. I think I should have tried to support EEPROM too, but that's challenging.

Nice! Very good for a hand-made cart. 4MB is all you need for all but a couple games... SSF2, those MK hacks that range from 6 to 10 MB, that sort of thing. No biggy.

You might think of adding 4MB + SRAM. That's used by S&K + Sonic 3, and Wolf32X. There may be others, but those two I know use that mapping.

You might think of adding 4MB + SRAM. That's used by S&K + Sonic 3, and Wolf32X. There may be others, but those two I know use that mapping.

Oops I had a typo, 4MB ROM+SRAM is supported.

Based on the help I got from you and others I think 32X games should work, but I can't find my video cable to test. Also the CART# pin can be controlled so it shouldn't interfere with Sega CD either, but that's also untested.

I want to make lovely PCBs like that

Very cool stuff, though I would have went full surface mount way for the chips. Flashes get programmed in my programmer, all else is at the whim of your program on the flashes ^^

Charles MacDonald wrote:

You might think of adding 4MB + SRAM. That's used by S&K + Sonic 3, and Wolf32X. There may be others, but those two I know use that mapping.

Oops I had a typo, 4MB ROM+SRAM is supported.

Based on the help I got from you and others I think 32X games should work, but I can't find my video cable to test. Also the CART# pin can be controlled so it shouldn't interfere with Sega CD either, but that's also untested.

Even better!

Having control over the cart line should allow you to use the 4MB with CD software... the Holy Grail I've been after for years.

Some games like Beyond Oasis write to the banking registers at $A130Fx even though they don't really use banking. Maybe leftover code from the development environment.

This game has SRAM and ROM mapped at the same place ($200000-$2FFFFF), so it uses !TIME banking signal to enable/disable SRAM.

Other known games doing this (they are quite limited though, do you remember what other games you found ?):

- Phantasy Star 4
- Sonic 3 (only useful when locked to Sonic & Knuckles where Sonic 3 is mapped to $200000-$3FFFFF as well as its backup memory)
- Sonic & Knuckles (same as above, this is also used to enable/disable the S2K additional chip in upper memory when locked to Sonic 2)

Very interesting cart, well done.

How does the USB interface work? Are you using a serial UART to USB or implementing some sort of 'HID' device?
Do you have any plans to release schematics and such?

Regards.

Chilly Willy wrote:Having control over the cart line should allow you to use the 4MB with CD software... the Holy Grail I've been after for years.

The way it is set up the CART# pin is grounded after a power-up reset, and then you can write to a register to set it to 1 (or back to 0). The entire $400000-$7FFFFF space would be occupied with 4MB RAM though, hopefully that isn't a problem.

Eke wrote: This game has SRAM and ROM mapped at the same place ($200000-$2FFFFF), so it uses !TIME banking signal to enable/disable SRAM.

I don't actually own this game, but I expected it just had some off-the-shelf chips instead of a real mapper chip. Do we know what's inside it?

I assumed it would have an identical circuit to what PSIV uses, so seeing the accesses to the ROM banking registers was surprising. Sadly I did not include a way to mask them during gameplay, so it trashes some of the card settings. I patched the ROM to remove these writes and it seems to work fine.

Eke wrote:Other known games doing this (they are quite limited though, do you remember what other games you found ?):

Those were the others I was looking at too.

Alan wrote:How does the USB interface work?

I'm using the FTDI FT245 chip. It makes USB look like a TX and RX FIFO with a data port, read/write strobes, and a TX full / RX empty flag. So you just poll the flags and read or write data as needed, and the PC software is on the other end of the FIFOs. They make a FT2232 chip which has two 8-bit channels (amongst other things).

The documentation has been consistently poor for all their products going back to 2004, so I'd strongly recommend prototyping with the parts first before committing to them for any certain project. I happen to like these chips but it really has taken forever to get the software 'just right'.

I will make the entire project available online eventually, and in the interim I wouldn't mind making and selling a few more of these once I work out what to change in the next version.

Charles MacDonald wrote:

Chilly Willy wrote:Having control over the cart line should allow you to use the 4MB with CD software... the Holy Grail I've been after for years.

The way it is set up the CART# pin is grounded after a power-up reset, and then you can write to a register to set it to 1 (or back to 0). The entire $400000-$7FFFFF space would be occupied with 4MB RAM though, hopefully that isn't a problem.

The idea would be to boot the CD while RAM occupied $400000 to $7FFFFF so that the CD software had 4MB of ram to load into (on the MD side). While you can fit most of the game logic into 512KB of ram, you can't fit all the level data and sprites/textures into 256KB/64KB (CD/MD sides). For example, Doom - have the CD run the game logic, while the MD side does sound/graphics from the 4MB of ram. The only thing the CD side would need is the level data and things. If you want to use the CD ASIC for sprite scaling/rotating, you could have the MD side transfer sprite data from the ram to the word ram.

Charles MacDonald wrote: I don't actually own this game, but I expected it just had some off-the-shelf chips instead of a real mapper chip. Do we know what's inside it?

I assumed it would have an identical circuit to what PSIV uses, so seeing the accesses to the ROM banking registers was surprising. Sadly I did not include a way to mask them during gameplay, so it trashes some of the card settings. I patched the ROM to remove these writes and it seems to work fine.

Chilly Willy wrote:The idea would be to boot the CD while RAM occupied $400000 to $7FFFFF so that the CD software had 4MB of ram to load into (on the MD side).

Ah, I think that would definitely work without problems then.
If I can find the time I'll try to confirm it.



Thanks ElBarto! ;D

So the game really only implements $A130F1 bit 0 and not bit 1 or the ROM banking registers at $A130F3-$A130FF.

Unless the US version is different, but I really doubt it -- this game was working in emulators before we even knew the banking hardware existed. So I think the extra writes are just left over from the development code. They don't do any harm other than confusing a devcart.

Charles MacDonald wrote:

Chilly Willy wrote:The idea would be to boot the CD while RAM occupied $400000 to $7FFFFF so that the CD software had 4MB of ram to load into (on the MD side).

Ah, I think that would definitely work without problems then.
If I can find the time I'll try to confirm it.

No rush. Whenever is fine.

So the game really only implements $A130F1 bit 0 and not bit 1 or the ROM banking registers at $A130F3-$A130FF.

Actually, most don't bother looking at the address at all, they just trigger off /TIME, so they respond to $A130XX bit 0.

The addresses were set by SEGA for their DevCart, and may or may not be fully decoded depending on what they use. Clearly, if they use the bank regs, they need to decode at least a LITTLE more.

Charles MacDonald wrote:I wouldn't mind making and selling a few more of these once I work out what to change in the next version.

Estimated price with shipping to UK?

Chilly Willy wrote:No rush. Whenever is fine.

The Sega CD results were quite exciting.

I wrote a memory map viewing program that runs out of work RAM, and used the devcart to toggle the /CART pin under software control. Both the cart RAM and Sega CD RAM/ROM/registers were at the right places, with no conflicts, in either state.

I then tried jumping to the BIOS reset vector and it worked. I tested several games which all ran fine (including special graphics effects) while the cart RAM was at $400000-$7FFFFF and cart registers at $A13001-$A130FF were enabled. Two possibilities spring to mind:

1. You could load ROMs off a CD-R into RAM. Sure it's slower than loading from USB, but why not.

2. Since you can boot from a cartridge you could do Sega CD development without ever burning a disc, and the USB connection could be used to load files from the host PC. This could simplify development until it was time to switch over to CD access and the data files were more finalized and ready to go on a CD. Granted the files are coming in at the wrong side (Genesis 68K instead of Sega CD 68K) and you'd probably need to either make a boot disc so the BIOS could load, or determine the BIOS state and preset the system to match for a pure cart-only boot.

The bad news is that the 32X does not work. There is some graphics corruption and the machine hangs shortly. I feel certain it is having trouble reading ROM data and is loading corrupt data and program code into memory. When acting as a pass-through device for Genesis games loaded onto the devcart, everything works perfectly.

I looked at some 32X cartridges and they use CE0 and CAS0 exclusively for ROM access, and I use those signals too. But I now realize the 32X adapter may use the other signals (ASEL, CAS2, etc.) which I did not account for. Oops. It could also be a speed issue but I deliberately used the fastest RAMs and buffers I could find.

The memory map viewer (when $A15100=$0001) shows the vector ROM, fixed ROM, banked ROM, and MARS ID, but hangs when I do word reads from the frame buffer, overwrite image, or palette RAM. I didn't initialize any other registers in case that is necessary.

It may be possible to fix the design to support the 32X, but right now I don't know enough about what part is failing to work and/or which signals are needed to determine what to do. Has anyone done research into which signals the 32X relies on?

EDIT:

ADEN seems to control the /TIME signal on the 32X cartridge port.

When ADEN=0 I can see my other hardware at $A130xx along with the MARS ID. I have pull-up resistors on VD0-VD7 so all unused locations are $00FF. When ADEN=1 every byte is zero except for the four MARS ID bytes.

This would imply having to toggle ADEN every time you want to access extra hardware in the $A130xx range. Does that do anything bad like reset the SH-2s or clear register settings, etc?

The addresses were set by SEGA for their DevCart, and may or may not be fully decoded depending on what they use. Clearly, if they use the bank regs, they need to decode at least a LITTLE more.

You got me curious about this, and it turns out somebody at Sega wrote some very clever code!

They do all the ROM bank register writes first, and the $A130F1 write last. After that point the game only ever writes to $A130F1. So even though the SRAM banking value is modified during the ROM bank writes, the final SRAM control write sets the correct value. This way the same code sequence has the desired effect both with and without the ROM banking hardware present.

Off-topic: Do we know how the Sega CD import-enabling cartridges work? If it's just a software thing I wonder if I could implement that functionality into my devcart.

Alan wrote:

Charles MacDonald wrote:I wouldn't mind making and selling a few more of these once I work out what to change in the next version.

Estimated price with shipping to UK?

Sorry to say it's quite expensive. $57 for the PCB, $36 for the 4M RAM, $35 for the other parts for $128 total. Doing a larger run (more boards ordered at once) would cut the per-board cost down, and having less RAM would also help. I'd probably ask about $20 more so I could make profit instead of breaking even, and I'm not even sure how shipping factors in on top of that.

Those Genesis flashcarts are cheaper since they are ordering parts in units of 1000 or more and getting steep discounts based on volume.