Devcart wishlist?

[Charles MacDonald]

I've been working on a devcart to replace my Super Magic Drive. The specs are:

- 4MB RAM (I wanted socketed memory, so eight 512Kx8 SRAMs)
- 1MB Flash (to boot the cart, 2x Am29F040)
- USB interface for quick "assemble-then-test" cycles.
- IDE interface for a Compact Flash to IDE adapter, to load games^H^H^Hhomebrew programs into RAM.
- Banked SRAM support for PSIV and others. I won't support SSF2 banking or the SRAM write-enable bit though, just A130F1 bit 0 is implemented currently.

Ramtron is discontinuing their 5V parallel FRAM products and NVRAMs are really expensive, so I think I'll just have to use battery backed SRAM for savegames. The battery part isn't done yet, but after that the cartridge will be finished. I haven't had the time to play RPGs for some years now, maybe it's not important to add this.

I've found that I have a lot of room left on the board and want to add some perhaps crazy things. The board is already huge so why not make it even bigger?

Currently I'd like to put a 68EC000 @ 20 MHz with 512K or 1MB of local RAM on the board as a coprocessor. I bought a lot of 16K dual port RAMs for cheap that would greatly simplify communication between the Genesis 68000 and the coprocessor. I suppose it could do things like sprite collision processing or other tasks, maybe mix some audio channels together into a buffer in the dual port RAM for the Z80 to send to the DAC.

But I wonder, are there any really useful things for a coprocessor to do? I never felt the Sega CD 68000 improved anything, other than freeing up the Genesis from having to poll the CD and PCM chip. There aren't any CPUs available that could have SVP-like performance, so I'm not planning on polygons -- but I'd love to see what kind of wireframe graphics could be done instead.

Assuming the 68K would edit bitmaps (scaling, software sprites, etc.) in local memory before transferring to dual port RAM to be DMA'd to VRAM, I designed circuits for packing/unpacking nibbles into bytes and a 32X-like overwrite feature. But after crunching some numbers I don't think the 68K could really push around enough data to be useful at 20 MHz. So it seems less likely that the coprocessor could generate a whole 256x192 frame of data at 30FPS. Maybe a second CPU isn't really useful?

Anyway, I'm not decided on what to add, if anything. What would people dream of having? What would you add if you were a Sega developer in the 90's? (no PowerVR or FPGA or MP3 player, please)

[TmEE co.(TM)]

On the other aspect, if you add CPU there, and somebody uses it, then the 'brew is tied with that dev board, and maybe an emulator capable of emulating it.... but if its something serious that can end up in production it won't be too cost effective anymore.

I do quite like the ASM-then-test part, as that's how I generally work, and it sucks to wait for your flash chips to erase and then program
(luckily my old plain flashcart erases in 12 seconds)

[Charles MacDonald]

On the other aspect, if you add CPU there, and somebody uses it, then the 'brew is tied with that dev board, and maybe an emulator capable of emulating it.... but if its something serious that can end up in production it won't be too cost effective anymore.

That's a very good point. I am definitely not competing with Everdrive or any of the other commercial flashcarts out there, so these crazy features are just for fun. All the project data will be on my website so people can make their own, or modify the existing board layout to add/remove features. But I bet maybe 1 or 2 people other than myself will really build one.

I do quite like the ASM-then-test part, as that's how I generally work, and it sucks to wait for your flash chips to erase and then program
(luckily my old plain flashcart erases in 12 seconds)

Speaking of more effective development I had been thinking of using the FT2232 USB chip instead of FT245 as it has extra I/Os that could be used to do a remote 'hard' reset using MRES or a soft reset via VRES. Then even if the Genesis locks up you just hit a few keys and you are running again. What do you think?

[Pascal]

can the second cpu be used for debug features ? I'd love to be able to link my debugger with the hardware instead of emulator

[Charles MacDonald]

can the second cpu be used for debug features ? I'd love to be able to link my debugger with the hardware instead of emulator

Absolutely. The USB communication is always available so you could have a PC-hosted debugger control the Genesis, as long as the game periodically called code to respond to incoming debugger commands from the PC.

So if you wanted to set a breakpoint at a certain address in the debugger, it would tell the debug software on the Genesis which address to patch with an illegal opcode, and the exception handler that gets triggered could send register data, or a VRAM dump, etc. to the PC for display. I guess that would be a software breakpoint. And you could just 'unpatch' the location when you remove the breakpoint -- I guess if the PC debugger kept track of these things, you'd have unlimited breakpoints.

Once per Vblank your game would call a function that checks if there's incoming commands from the debugger. It's just a flag check, so there's be no real difference between it and the non-debug builds.

The cartridge port doesn't have the kind of necessary signals for the coprocessor to assist with debugging unfortunately. Otherwise you could do some very cool things. But I think you can still accomplish a lot this way.

[Chilly Willy]

A way to use the cart as 4MB of RAM on the MD side of a SCD/32X game would be awesome. One reason more ports of things weren't made to the SCD or 32X was a lack of RAM.

[Stef]

...
Anyway, I'm not decided on what to add, if anything. What would people dream of having? What would you add if you were a Sega developer in the 90's? (no PowerVR or FPGA or MP3 player, please)

Nice project imo one of the most wanted stuff i would love to see in megadrive is a 8 bpp bitmap to 4 bpp 8x8 tile memory wrapper, maybe with an extra mask feature (ignore 0x00 data write) =)
Of course megadrive isn't designed to do bitmap drawing but this is so cool =)

[Charles MacDonald]

Nice project imo one of the most wanted stuff i would love to see in megadrive is a 8 bpp bitmap to 4 bpp 8x8 tile memory wrapper, maybe with an extra mask feature (ignore 0x00 data write) =)
Of course megadrive isn't designed to do bitmap drawing but this is so cool =)

This is what I have implemented, I'll explain how it works:

When you do a byte read from an even address, both RAMs are enabled so 16 bits of data are presented. Some logic routes D11-D8 and D3-D0 of the word to bits D7-D0 of the byte the 68000 will latch. This packs the nibbles of two bytes into one byte.

Likewise when you do a byte write to an even address, both RAMs are enabled, the same nibbles are routed, and the upper nibbles are cleared. This unpacks the nibbles of one byte into two bytes.

It is intended to work with MOVEP, because it does two or four sequential byte reads/writes to addresses that are a word apart. E.g.

; Unpack
move.l (a0)+, d0 ; get 8 nibbles of pixels (D0=$01234567)
movep.l d0, 0(a1) ; write 8 bytes (mem=$0001 $0203 $0405 $0607)

; Pack
movep.l 0(a1), d0 ; read mem=$B0B1 $C2C3 $C4C5 $C6C7 into D0=$01234567

For the write mask feature, I just disable the RAM write strobe depending if the lower nibble in either byte of a word are nonzero or not. So writing $0C00 to RAM would result in $0Cxx being written and xx is unmodified.
Also the unpack and overwrite functions can work together.

I use some upper address bits to select which functions are enabled, so there are mirrors into the same RAM that treat reads and writes differently.

I've looked into how to tweak the address for linear writes -> tile format conversion, but not actually made any schematic for the circuit. But it seems straightforward too. This would let you pack the 8bpp bitmap into 4bpp tiles quickly.

Chilly Willy:

If the 32X can read and write to the Genesis ROM area, I guess it should work? I'm only using the standard signals on the cartridge edge connector that commercial games use, none of the funkier strobes. I really want it to work with 32X games too which is why I was asking about that MARS ID register earlier.

As for Sega CD, I wanted to use $400000 to map the dual port RAM instead of banking it with the ROM space. I could map it to B00000 or something but I don't feel 100% sure about how well that would work.

I wish there was an address below $A00000 that we knew for certain would not conflict with the 32X or Sega CD. Even though the addresses are documented, in reality there are usually more mirrored locations than they specify.

[ElBarto]

Two thing I want (the most) about a devcart is the possibility to upload and run the rom without :
- Unplugging the cart.
- Plugging in the computer interface
- Upload the rom
- Unplugging the cart from the computer interface
- Plugging in the MD

(With the everdrive or other SD compatible cart it's even worst, as I have to mount/unmount the SD).

And that the protocol to talk to the cart is open-source (don't care about writing myself the tools, just don't want to get a headache will writing it).

Here is the process while dev I want to do :

$ emacs blah.c &
$ make
$ make upload
$ make run

and voila, the homebrew is running on the megadrive

Thing that could be cool :

- Co-proc for other thing (but as TmEE stated, homebrew will be cart-dependant ...)
- Even if I don't care running commercial games, eeprom/battery sram/whatever for saving can be cool
- SFII mapper for >4MB games (SFII compatible cause you could play the game too and the mapper-chip isn't limited to 5MB)

[Charles MacDonald]

Two thing I want (the most) about a devcart is the possibility to upload and run the rom without :
- Unplugging the cart.
- Plugging in the computer interface
- Upload the rom
- Unplugging the cart from the computer interface
- Plugging in the MD

Haha, I know the feeling. You can definitely do all this. I made an earlier devcart for the PC Engine that works in the same way, and I never have to touch or unplug anything other than toggling the power if I crash the system. For my projects I run the makefile and type 'run' and it's running, no other steps. ;D

And that the protocol to talk to the cart is open-source (don't care about writing myself the tools, just don't want to get a headache will writing it).

I use the FTDI USB library (free for Mac, Linux, Windows) for the host utility and the protocol is handled by the Genesis 68000, so you can customize anything you want. For example my PC Engine devcart has functions like:

- Upload/download memory
- Upload & execute a program
- Download special memory (VRAM and other port-mapped things)
- Listen for incoming commands from the PC-Engine (to access files on the PC side)

It's very flexible, you can add any features you want. I've been using this same system for a few years now on SMS, Saturn, and arcade games too, so I think it's mostly debugged now.

- Even if I don't care running commercial games, eeprom/battery sram/whatever for saving can be cool

I had thought about EEPROMs, nobody makes the Xicor X24C01 anymore and I don't know what is compatible. I think some games use the 93C46 which has a different protocol. I wonder if a small PIC running fast enough could respond to EEPROM commands and store/save data to a serial FRAM or something transparently, and you'd just tell it what type of EPROM interface to simulate.

Adding the battery backed RAM for saves isn't a problem, but probably EEPROM support won't happen.

- SFII mapper for >4MB games (SFII compatible cause you could play the game too and the mapper-chip isn't limited to 5MB)

I don't know how to do this cheaply. It's not a very complex circuit but it lends itself to be 'big' and waste room. I can see why the game used an ASIC instead of discrete parts.

I won't support it but somebody could modify the design to do so. I'm sure some expert could fit everything in a CPLD or something, but I haven't worked with those parts yet.

[Chilly Willy]

As for Sega CD, I wanted to use $400000 to map the dual port RAM instead of banking it with the ROM space. I could map it to B00000 or something but I don't feel 100% sure about how well that would work.

Yeah, probably 32X is more important than SCD as allowing USB and CF would take care of the "storage" someone would use a CD for.

You know, instead of an extra CPU on the thing, maybe a nice blitter in the FPGA would be more handy. It would help with polygons and 2D stuff more than a CPU would... unless you switched from another 68000 to a RISC processor.

If you really want the "68000", why not go with a ColdFire MPU instead - 200 MHz with 68000 compatibility, DMA, timers, memory interfaces, even USB and ethernet all in a single package.

Just tossing out a few ideas... the only thing I really WANT is to use the 4MB as ram. The Neo Myth is a little less flexible in that regard... the 8MB of PSRAM is usable as 1MB of fixed ram and 1MB of bank-selected ram. That allows you to use all 8MB of the PSRAM, but most stuff is written towards one block of ram, not banks of ram.

[Charles MacDonald]

You know, instead of an extra CPU on the thing, maybe a nice blitter in the FPGA would be more handy. It would help with polygons and 2D stuff more than a CPU would... unless you switched from another 68000 to a RISC processor.

My goal was to use as few surface mount chips as possible to keep it easy to assemble even for amateurs (that includes myself . FPGAs and ColdFire parts are great but 3.3V and only available in QFP or BGA packages with a fine lead pitch and hundreds of pins.

If I was getting these ordered in a large batch and professionally assembled then this would be an attractive option, but in reality I plan on just building/selling a few if the prototype works.

Just tossing out a few ideas... the only thing I really WANT is to use the 4MB as ram.

No problem, and the RAMs I'm looking at are 55ns so you could execute code from them at full speed if you adjusted the SH-2 memory wait states I believe?

[Chilly Willy]

The default for the ROM space on the 32X is 8 cycles, 6 of which are wait cycles set for the rom space. You could adjust those with the bus control registers. Each clock cycle on the 32X (NTSC) is 43 ns, so given the minimum bus cycle of 2 clock cycles, you could set the wait to 0 for 55 ns ram.

I can see where you don't want hard to assemble parts, so that does preclude the use of things like FPGAs. That also means using a CPLD with maybe only the ability to do things like you mentioned - packing/unpacking nibbles, and cell addressing.

[Stef]

This is what I have implemented, I'll explain how it works:

When you do a byte read from an even address, both RAMs are enabled so 16 bits of data are presented. Some logic routes D11-D8 and D3-D0 of the word to bits D7-D0 of the byte the 68000 will latch. This packs the nibbles of two bytes into one byte.

Likewise when you do a byte write to an even address, both RAMs are enabled, the same nibbles are routed, and the upper nibbles are cleared. This unpacks the nibbles of one byte into two bytes.

It is intended to work with MOVEP, because it does two or four sequential byte reads/writes to addresses that are a word apart. E.g.

; Unpack
move.l (a0)+, d0 ; get 8 nibbles of pixels (D0=$01234567)
movep.l d0, 0(a1) ; write 8 bytes (mem=$0001 $0203 $0405 $0607)

; Pack
movep.l 0(a1), d0 ; read mem=$B0B1 $C2C3 $C4C5 $C6C7 into D0=$01234567

For the write mask feature, I just disable the RAM write strobe depending if the lower nibble in either byte of a word are nonzero or not. So writing $0C00 to RAM would result in $0Cxx being written and xx is unmodified.
Also the unpack and overwrite functions can work together.

I use some upper address bits to select which functions are enabled, so there are mirrors into the same RAM that treat reads and writes differently.

I've looked into how to tweak the address for linear writes -> tile format conversion, but not actually made any schematic for the circuit. But it seems straightforward too. This would let you pack the 8bpp bitmap into 4bpp tiles quickly.

Ah yeah sorry it seems i missed that part of your first post :

I designed circuits for packing/unpacking nibbles into bytes and a 32X-like overwrite feature.

That sounds really cool packing / unpacking nibbles and overwrite feature are really time consuming in software and just requires few hardware logic to be hardwired.
The tile to bitmap conversion also eat sometime, the SegaCD includes a similar feature to convert Vector Chip tiles (32x32 as far i remember) in VDP tiles (8x8 tile). But for a bitmap mode, you have to fix the bitmap size, i guess this is not that easy to do :-/

[Chilly Willy]

One suggestion - instead of hard coding the address where packing/unpacking/cell-conversion takes place, make that something that can be changed via a register. So instead of having extra spaces in the cart that are hard-coded to do something, you instead of windows into the single 4MB space. A window would have attributes like enabled, overwrite, underwrite, pack, unpack, cell addressing, base pointer, and length. A CPLD should be able to handle that much. Depending on the gates available, you might have more than one window... two windows would be handy for copying images, and three would be good for hardware assisted blits by the CPU.