SpritesMind.Net

I am not PCB design fan.
I can not do anything with PCB design...
But I can do full 2d+3d case design for plastic cartrige case
/full mold form manufacturing documentation+3D models -> Opensource CAD/.

Plus one - two real protos...
Plus www webpage...

PS>I want do this special for TFM music...
So later maybe can be there TFM modules player with menu and some little visualisation /bars/ in firmware too...
Maybe graphic mixer software too - I mean software controlled
with gamepad /more songs mixed into one long music set/...

So here will be development topic:

I need good electronic geeks here...

So little brainstorming first ->

1./
- Name (contest)???

2./
- SD /standard,mini.../ or CF /compact flash/ or battery RAM???

3./
- All on USB cartrige design or USB writer + cartrige design...???

4./
PIC,ATMEL,FPGA???

5./
- transparent case / color case (which) / black case???

Why not FPGA + microcontroller based?

FPGA would handle the timing signals, and format the output tho the 68000 bus

microcontroler would handle the card file system (FAT/FAT32)

also a small built-in program to choose the rom to be played...

to write in the card a simple usb card R/W device... -> can be separate from the cart or not, the signals can just be routed to where they need to be.

If you go that route, it needs to fully support SSF2-style banking, and not just for that one ROM. The banking technically supports 64 pages of 512KB, thus the system would need a way to support up to 32MB of ROM loaded for such banking. Determining whether or not to enable the banking is easy - if the ROM is >4MB enable it, otherwise disable it. The only ROM I know of that would falsely trigger this mechanism is that massive UMK3 hack called "Ultimate Mortal Kombat Trilogy", and it wouldn't work on hardware anyway due to lack of address space (the ROM is something like 10MB, and I don't think there's any way to map that much ROM space at once without hardware modification to make the cart enable line work up through $9FFFFF, and it'd butt right up against $A00000 if the ROM is exactly 10MB). Perhaps this could be an option since it would undoubtedly raise the cost of the device (since outside of that you'd only need 5MB of ROM to be loaded at once to support SSF2). I think it would raise some interesting possibilities for homebrew if we could use up to 32MB of ROM for our code and assets.

One more I am not familiar with PCB... I am chipmusician...

I am doing this already 3 years. You can not use MMC / SD card program as a carrier at runtime, as these memory cards sequential access. You have to use either RAM or ROM as a buffer.

So need be there RAM+battery right...

Concept V2>

Is that Concept v2 better???

HardWareMan wrote:I am doing this already 3 years. You can not use MMC / SD card program as a carrier at runtime, as these memory cards sequential access. You have to use either RAM or ROM as a buffer.

You can't use it in place of flash, but you CAN use it in place of CD. A flash cart with SD card adapter would be an awesome thing for folks without a CD. Even with a CD, it would still be awesome - faster access, larger storage, easier rewriting (I've noticed my SEGA CD won't read CDRW... is there a particular brand that works, or does the SEGA CD simply not work with CDRWs? ), ability to have any size save file...

Okay, here's my idea: Make the cart with an FPGA, the SD card adapter, and a 4MB SRAM. Have the FPGA read the "boot sector" (however you wish to define that) into the start of the SRAM on powerup or reset. That code can then act as a loader for running programs from the SD card. It would also contain functions to open/close/read/write/etc files from the SD card so that programs can load stuff from the SD card, and write save files.

Something like that would be more useful than a plain flash cart. That would be particularly true if you added features to the FPGA, like a graphics coprocessor like in the CD (maybe a general purpose BLITTER), and maybe an audio pre-processor - have X number of DMA channels that read audio data from the 4MB RAM, mixed them together, then wrote the result to the DAC in the YM2612. Something like that would be easy to make with an FPGA. I made far harder circuits back in college from discrete components.

HardWareMan wrote:I am doing this already 3 years. You can not use MMC / SD card program as a carrier at runtime, as these memory cards sequential access. You have to use either RAM or ROM as a buffer.

What do you think about the MC itself as a buffer? Or a shift register?

tinctu wrote:I will not alow to run ROM images as on DEV Carts.

Er... And how do you plan to do that? Even if you allow load only .elf files, it'll be able to run ROM images using a simple "conversor".

Chilly Willy wrote:Okay, here's my idea: Make the cart with an FPGA, the SD card adapter, and a 4MB SRAM. Have the FPGA read the "boot sector" (however you wish to define that) into the start of the SRAM on powerup or reset. That code can then act as a loader for running programs from the SD card. It would also contain functions to open/close/read/write/etc files from the SD card so that programs can load stuff from the SD card, and write save files.

While you dreaming about it, I have gathered a prototype. Yes, there is a small flash memory with the loader, 4 Mbytes RAM (actually it's a PSRAM - Pseudo Static RAM, dynamic RAM have not compatible interface and need to be regenerated, pseudo SRAM do this internally at background and have SRAM bus interface) and port for the SD / MMC card.

rodolforg wrote: What do you think about the MC itself as a buffer? Or a shift register?

Do not work. To have full random access, on each access would have to read the whole sector, which contains the data you want. Speeds interface is not sufficient for this.

BTW: I have already connect a HDD to SegaCD port. I use this for some training and research.

I guess you're playing ROMs from that HDD... I'd like to make a simple IDE interface for MD too, but I have too many other things (like school) in my way

Idea>w
When it is IDE possible so it is possible to use IDE-CF reduction...



I found one opensource!!

http://www.abclinuxu.cz/data/ruzne/cfIDE_4c.zip

tinctu wrote:Idea>w
When it is IDE possible so it is possible to use IDE-CF reduction...

Yes, it is. CF has ATA interface and almost all storages (Compact Flashes and Microdrives) must handle the native True IDE Mode.

Quick question:

How long does reading a whole 512byte sector from a SD/MMC takes?
(Just 1 sector)