~ OPENSOURCE USB CARTRIGE DEVELOPMENT ~

[Chilly Willy]

I gave the lattice solution because most FPGAS are volatile, and the ones I said have flash memory to keep the configuration when it powers off...

The normal ones need a bootloader/external prom...

Well, that's a plus is its favor. I don't think the Altera FPGAs have that, but I might be mistaken. I haven't gone through the manual completely. Having embedded flash for the programming would simplify the design. However, is one, small, external flash for the initial state really a problem? Depends on what else needs to go on the board. If the board is already crowded for room with lots of parts, embedded flash might be necessary. If there's not many parts, an external flash may be fine.

[Jorge Nuno]

Allright so what is the first thing?

A functional block diagram to get started? Of course is to be upgraded and bug corrected but it's just to start, since this topic has 5 pages of bla-bla-bla and no cart...

I will try to draw one in the next moments...

EDIT: The very first approach:



Flame it!

[Chilly Willy]

Looks pretty good, but I don't think you need NVSRAM. Considering that you'll be loading the game and save ram from the SD-card, you'll almost certainly be saving the save ram to the SD-card when you're done playing. In that case, just make the "save ram" a block from the normal ram pointed to by a register in the FPGA. Then you can "load" and "save" this block using the GUI before starting the game and after finishing the game. When a game writes the "save ram" block, just set a flag in the FPGA, and on reset (how you exit the game), the GUI code checks the flag and enters the save "save ram" menu allowing the user to save the data or toss it if they don't care.

That would save needing extra RAM and a battery. I need to look at how the Cyclone loads the initial state... perhaps there's a way to combine the FPGA load EEPROM with the "boot" ROM in your diagram. Every part saved makes it that much cheaper. It would be nice to have some way to program that part so as to update both the GUI and the FPGA program.

[Jorge Nuno]

Looks pretty good, but I don't think you need NVSRAM. Considering that you'll be loading the game and save ram from the SD-card, you'll almost certainly be saving the save ram to the SD-card when you're done playing. In that case, just make the "save ram" a block from the normal ram pointed to by a register in the FPGA. Then you can "load" and "save" this block using the GUI before starting the game and after finishing the game. When a game writes the "save ram" block, just set a flag in the FPGA, and on reset (how you exit the game), the GUI code checks the flag and enters the save "save ram" menu allowing the user to save the data or toss it if they don't care.

I just put that way to avoid writing files to the SD card, but you can't save when you're done because the power is lost, the FPGA has to be monitoring any changes in the TIME signal and then update the save file when TIME goes inactive... Oh and that removes the Hot-Removal ability.

That would save needing extra RAM and a battery. I need to look at how the Cyclone loads the initial state... perhaps there's a way to combine the FPGA load EEPROM with the "boot" ROM in your diagram. Every part saved makes it that much cheaper. It would be nice to have some way to program that part so as to update both the GUI and the FPGA program.

Xilinx load it serially with a special 8-pin PROM, AFAIK.

[Chilly Willy]

I just put that way to avoid writing files to the SD card, but you can't save when you're done because the power is lost, the FPGA has to be monitoring any changes in the TIME signal and then update the save file when TIME goes inactive... Oh and that removes the Hot-Removal ability.

Power is lost only if you turn off the power. I was thinking of reset to quit, not power-off.

I remember when people were nuts over cart hot-removing... folks were trying it with all kinds of carts to see what would happen. But the Genesis isn't made for hot swapping the cart. It's risky. I really don't think we should make a cart with that in mind, unless it's simulated electronically on the cart: load up two games and have it "hot swap" at the press of a button. We could probably have a button or two on the cart that hook to the FPGA that could be used for different purposes, like swapping.

Xilinx load it serially with a special 8-pin PROM, AFAIK.

I've used Xilinx before. They're nice, but pricey. You don't get nearly as many gates for the price compared to the cyclone... unless they've had a big price drop recently.

[Jorge Nuno]

Power is lost only if you turn off the power. I was thinking of reset to quit, not power-off.

I remember when people were nuts over cart hot-removing... folks were trying it with all kinds of carts to see what would happen. But the Genesis isn't made for hot swapping the cart. It's risky. I really don't think we should make a cart with that in mind, unless it's simulated electronically on the cart: load up two games and have it "hot swap" at the press of a button. We could probably have a button or two on the cart that hook to the FPGA that could be used for different purposes, like swapping.

I was talking about Hot-removing the SD card from its socket, not the cart itself But yeah that reset button to reload the boot rom seems a reasonable solution to play another one...

I've used Xilinx before. They're nice, but pricey. You don't get nearly as many gates for the price compared to the cyclone... unless they've had a big price drop recently.

I talked about the xilinx because I know they sell proms for storing their FPGAs "fusemap", the others I don't know...

[Chilly Willy]

I was talking about Hot-removing the SD card from its socket, not the cart itself But yeah that reset button to reload the boot rom seems a reasonable solution to play another one...

Ah. Well, seems to me that the save ram save code would check for an SD card and bug you to insert one if there isn't one currently plugged in.

Normally, resets just go right back into the cart, but with this card, you'd have the FPGA map the GUI back into the cart position on reset. It can then ask if you want to go into the GUI proper, rerun the current loaded game (if one loaded), or save the save ram (if it's been written to). You can have the user set a preference as to which is the default action, and how long the time out is before doing the default.

[Jorge Nuno]

I'm trying to design a SDRAM state machine + interfacing... But I can't understand the Precharge command... I don't know what it does... grrrr.

I'm designing with SDRAM because I have some chips around, and probably porting the design to DDR won't be much different (the operating states)

BTW: What about the automatic refresh? Is it any good, or will I have to use refresh counters? And those different banks... Can a bank be auto refreshing as I read/write another one?

Im just a noob in SDRAM LOL

EDIT:

My SDRAM state machine prototype, though no microcodes yet...:

[Chilly Willy]

@Jorge - Try looking over the stuff at http://www.opencores.org/. You'll find everything from CPUs to DMA to USB to RAM interfaces of all types there.

[Jorge Nuno]

Ummm they don't have schematics (at least I don't see them) and I don't understand HDL, yet

So I started the microcoding:

bit order is in the schemaic, but I put it here too:

BA0, BA1, CKE, A10, /CE, /RAS, /CAS, /WE, Next0~3
/CS,/RAS,/CAS,/WE are active at low logic level.
Next(0:3) is the next address (for auto command sequencing)

0x0: 111101110001 ; NOP command, then jumps to 1, if not interrupted
0x1: 110100010010 ; Enter Self-refresh, jumps to 2, terminating refresh
0x2: 111101110000 ; Refresh terminate command, equal to the NOP command but this one isn't to be interrupted
0x3: 001000000000 ; Mode Register Configuration, jumps to NOP (A0~A9 should be a valid setting)
0x4: 111111110100 ; Device not enabled, jumps to itself
0x5: 001000100000 ; Precharge Bank 0
0x6: 101000100000 ; Precharge Bank 1
0x7: 011000100000 ; Precharge Bank 2
0x8: 111000100000 ; Precharge Bank 3 (all precharges jump to 0)
0x9: 001000111001 ; Activate Row/Bank (logical OR BA0, BA1 and A10 with this mask), stays while not interrupted by R/W/P
0xA: 001001011001 ; Reads from activated Row/Bank (logical OR BA0, BA1), goes back to 9
0xB: 001001001001 ; Write. BA0 and BA1 needs to be ORed, like read

I think I've covered all the SDRAM needed commands, but there is space left for 4 additional commands...
Also row activations will only interrupt the NOP command only... And my SDRAM will be operating @ 2*Mclk (106.5 MHz) with a CAS latency of 2.


If anyones interested the SDRAM chip is a Winbond W986432DH-6, though I think the commands will be valid for any SDRAM and DDR but I'm not sure...

Come on people do something , Or will I be designing the ultimate cart alone? Shheeeshh...


EDIT: coming up next is the uber-sdram-state-machine, the one that will translate standart Reads/Writes (CE, OE, WE) into those SDRAM commands, with hidden refresh.

I still don't understand the purpose of the precharge, but I know that I have to issue a precharge command, to change a row or put the sdram in the idle state...

[Chilly Willy]

I used to do hardware (designed an entire card for the Amiga), but you have to give people a little time if you want them to help. Some of us are a little busy with other things, but can spare a little time now and then. While responding to this thread everyday is easy and quick, looking over your circuit diagram and/or making my own takes a bit more time.

[Jorge Nuno]

You're right but it seems that I'm the only one pushing this project... Its not very motivating, you know, though I want it really badly, so even if nobody does, I will do (But I dont guarantee the USB part)

BTW I'm trying to design a Meagdrive addon which will feature all of this cart would have except the USB port;
It is fixed to the MD and has a cartslot;
Runs the "OS" if no cart is present 0%;
Will pick up the digital VDP pixel output to do line doubling (VGA-like output) 10%;
Extended pallete (128)/color selection(4096) (Requires Cram DMA auto-capture) 90%;
Fast (than the CPU) hardware divider: captures the DIVS/DIVU opcodes from the ROM right before the CPU, and transform them into moves to 0xAA000X if the operands are registers, the FPGA does the arithmetic, and then moves 0xAA0000X(result) to the specified location, branches next to theese instructions. 5%;
Send dgital RGB serially to the controller to attach a LCD (MD portable with the hardware in the bag, LOL) (wire re-mapping done)

Example:

The FPGA captures:
DIVU.w d2, d3 (140 cycles)

The CPU sees:
MOVE.l d2, $AA0000 (20 cycles)
MOVE.w d3, $AA0004 (16 cycles)
MOVE.l $AA0000, d3 (20 cycles)
BRA.s -10 (10 cycles) (total: 66 cycles)


If any operand is an immediate, the difference will be bigger, because a move won't be required...

WO0T! Of course this will need some uber work, and I will post the entire project/common cart parts when i think they are somewhat good.

**Jorge goes back to the hole where he came and continues drawing the state machine...

[Chilly Willy]

Wow, that's pretty ambitious.

[LocalH]

To go back to what I was talking about previously for just a little bit (not to detract from the current discussion or anything), I was at work the other day and I got to ruminating on a really good use for full SSF2 banking.

The MD scene should get a team together and develop a Guitar Hero clone for the Genesis. I'll make a thread later after I've been to bed detailing my ruminations, but for the most part, if we had access to 32MB of ROM, we could create a GH clone with more songs available than any other GH-style game, even including Frets on Fire. Basically, my idea was to fit the game engine itself into 3MB, leaving 512KB for song metadata (track titles and artists, pointers into the upper 512KB for the music itself and the note charts) and 512KB that's banked to support a large number of songs. With 3.5MB of base ROM for engine and metadata, that leaves 57 pages available for song data, which is 28.5MB. If my approximations are accurate, depending on song length we could support upwards of 400 or more songs in a single ROM, which combined with the capability of this cart to load ROMs from a memory card, could potentially give you thousands of songs to play simply by choosing different ROMs. The songs would of course be 2612-based, there's no way we could use actual digital audio and still gt the same functionality, but I think it would still be fun. Like I said, I'll elaborate more on this later, but I think we'd have the potential to have one of the greatest homebrew projects ever created on the Genesis, and I think it could garner a large following. As far as control schemes go, I was thinking of three possibilities:

1) Using a 6-button Genesis controller in the same way that the GH games support the Dualshock2
2) Hacking any random GH controller to a 6-button Genesis controller (due to the way a 6-button is implemented this would only give limited whammy support)
3) Developing an external PSX interface that serves two functions - generic Dualshock support (for other games) and specific guitar support (which would allow full whammy support)

I really think this project has potential, but it's not a one-man project, so I'd need people to help with graphic assets, code, and external PC tools to help generate the data needed for the note charts. Once I elaborate you'll get an idea as to what would be required, and I'll create a separate thread for it when I do. I think it's completely doable and would probably garner a lot of attention to the homebrew scene (especially with Pier Solar already on the radar).

[Shiru]

I'm highly doubt that whole SMD composers scene can produce enough music to fill 32 MB. For example, music which are made in my editor and compiled with tfmcom utility usually less 10KB, in worst cases about 20KB.