~ OPENSOURCE USB CARTRIGE DEVELOPMENT ~

For hardware talk only (please avoid ROM dumper stuff)
Chilly Willy
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jan 29, 2008 9:24 pm

Jorge Nuno wrote: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
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Wed Jan 30, 2008 9:02 pm

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... :lol:

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

EDIT: The very first approach:

Image

Flame it! :twisted:

Chilly Willy
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Jan 31, 2008 5:23 am

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
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Thu Jan 31, 2008 9:18 am

Chilly Willy wrote: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.
Chilly Willy wrote:
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
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Jan 31, 2008 7:05 pm

Jorge Nuno wrote: 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. :lol:

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
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Thu Jan 31, 2008 11:59 pm

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

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...
Chilly Willy wrote: 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
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Feb 01, 2008 4:20 am

Jorge Nuno wrote: 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
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Fri Feb 01, 2008 7:51 pm

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 :lol:

EDIT:

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

Image
:)

Chilly Willy
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Feb 01, 2008 11:49 pm

@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
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Feb 02, 2008 11:54 am

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

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... 8)

Come on people do something :cry:, 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. :D

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
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Feb 02, 2008 8:30 pm

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. :wink:

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Feb 02, 2008 8:32 pm

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) :D

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... :P

Chilly Willy
Very interested
Posts: 2762
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Feb 03, 2008 9:00 am

Wow, that's pretty ambitious. :D

LocalH
Very interested
Posts: 152
Joined: Tue Dec 19, 2006 5:04 pm

Post by LocalH » Sun Feb 03, 2008 1:10 pm

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
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Sun Feb 03, 2008 1:24 pm

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.

Post Reply