FPGA Based Videogame System

[roland p]

Since your list contains some obscure systems, have you considered writing a core for the Epoch Pocket Computer?

 

Edited October 1, 2015 by roland p

[Keatah]

Harmony loads 2600 ROMs without a CRC check. Maybe you could use a similar algorithm.

 

I believe Stella does also, without a database. It's been only the rare occasion when I've had to manually change the banking scheme.

[Pixelboy]

I was probably going to let the FPGA do most of the remapping work. I'll just send over a "cooked" packet and let it figure it out. There's probably going to be some kind of standard interface for all the cores though, to make life easier and so I don't have to reinvent the wheel each time a new core is made. Ideally I want it easy enough so other people can make cores for it.

 

More ramblings on how it will probably work...

 

File handling will work similar to what I already have done on my last chiptune player. The file extension determines what core is loaded, basically. I have a text file list that sits on the card, which maps file extension to core filename. This way, multiple extensions can map to a single core if need be. It also contains an int that is sent to the core so if say Coleco and SMS share a core (which they do) the core can properly set itself up for the proper system.

 

This might not be good enough in the end but this will be a good "first pass". For some systems like Atari 2600, I was thinking of using subdirs to select mapper number, and then the menu system will collapse them into a single list, so you can do something like this...

 

/2600/F8/file1.bin

/2600/F8/file2.bin

/2600/F6/file3.bin

 

Then the menu collapses it down into this:

 

Contents of /2600/

file1.bin

file2.bin

file3.bin

 

 

If subdirs by letter is desired, it'd still work OK.

 

/2600/A-D/F8/file1.bin

/2600/A-D/F8/file2.bin

 

etc.

 

There's not much of an other way except using a CRC style database which I really really really do not want. CRC databases are kind of a copout and it makes it a pain in the ass to add new ROMs. It miiight be possible to do heuristics but I don't really like the sound of that one either.

 

Fortunately, most things have headers on them so it's not a problem.

How would the system handle different types of controllers? For example, you could want to support trackball-dependent games with a standard USB mouse, or perhaps with a real USB trackball (if you're ready to spend money on that) or in a "simulated" way with an analog controller, or perhaps even with a digital D-pad (which would be slow but would provide minimal support for trackball games through a digital USB controller). Depending on the controller used, some adjustment may be required towards the sensitivity of trackball movements (i.e. slow it down if the "cursor" movement is a little too loose, or speed it up if it's too slow). And then there's the issue of button mapping, which is a must for such systems as the ColecoVision, Intellivision and Atari 5200, with their respective 12-key keypads.

 

I'm also wondering how much people will want to fiddle with the screen output settings. Someone with a CRT screen may want to adjust certain output parameters (like the horizontal/vertical offset), while someone else may want to fool around with the stretch settings on the Game Boy core for their particular HDMI TV.

 

I'd say it would make sense to save controller settings and output display settings for each core, probably in dedicated directories on a SD card.

[Phaax]

More ramblings on how it will probably work...

 

File handling will work similar to what I already have done on my last chiptune player. The file extension determines what core is loaded, basically. I have a text file list that sits on the card, which maps file extension to core filename. This way, multiple extensions can map to a single core if need be. It also contains an int that is sent to the core so if say Coleco and SMS share a core (which they do) the core can properly set itself up for the proper system.

 

This might not be good enough in the end but this will be a good "first pass". For some systems like Atari 2600, I was thinking of using subdirs to select mapper number, and then the menu system will collapse them into a single list, so you can do something like this...

 

/2600/F8/file1.bin

/2600/F8/file2.bin

/2600/F6/file3.bin

Will this work with long filenames too?

[Asbrandt]

For some systems like Atari 2600, I was thinking of using subdirs ...

There's not much of an other way except using a CRC style database which I really really really do not want. CRC databases are kind of a copout and it makes it a pain in the ass to add new ROMs. It miiight be possible to do heuristics but I don't really like the sound of that one either.

I would go with the subdirs, personally. It's the lesser of the evils here; added user effort.

 

It's been quite a few years since I worked on USB, but IIRC HID operates via Interrupt transfers and unless you can strong-arm the USB host controller the polling is scheduled by the controller at the frequency requested in the endpoint descriptor in the HID device. For low/full speed devices that's minimum 1ms, for high speed it's 125us. I don't know what typical HID devices set as their polling frequency, but the spec allows it to be up to 255 times longer. So as far as I know, you can't synchronise a host interrupt transfer poll to an external event, nor mandate a particular polling frequency, without having some control over the host stack (and possibly breaking the standard in the process).

By my understanding, Kevtris -is- scratch-building the USB Host controller and has full control over it here, and the poll rate set by the Device is only a request and/or informative of maximum capabilities, not a strict rule the Host has to obey, or else many low-speed devices wouldn't be able to have a USB Host. So he should be able to exert control over when polling occurs and do so at a slow rate.

[Newsdee]

A folder per system is fine, but per mapper? That's going to be a pain for the NES. I guess it can all be upgraded later on though.

[Asbrandt]

A folder per system is fine, but per mapper? That's going to be a pain for the NES. I guess it can all be upgraded later on though.

If I interpreted the post correctly, this is only needed for systems where ROMs have no headers to work with, such as the 2600. Something like NES has headers with all the needed information.

[Newsdee]

Makes sense. I suppose by default it could prompt for a mapper choice, so the user can try it without a specific folder structure.

[Pixelboy]

If I interpreted the post correctly, this is only needed for systems where ROMs have no headers to work with, such as the 2600. Something like NES has headers with all the needed information.

I'm thinking a "Zimba header system" of sorts could even be devised to add recognizable headers to ROMs that don't have any, thus ensuring that the proper core is used, possibly with extra parameters to cover minute details that the FPGA core can take into account, like the preferred input method (if it's something else than the stock joystick/joypad controllers). Making an application (that runs in Windows, Linux or Mac) which would let the user add a "Zimba header" manually wouldn't be all that complicated to do. Such an application could even do batch jobs to add headers to a bunch of ROMs inside a selected directory.

[kevtris]

So far, 2600 is about the only system that needs the directory structure for mappers. Most others have headers on them so they aren't a problem (NES, etc). SNES and Gameboy have 'built in' headers in the ROM itself so I use that currently. There's a few odd men out like on SMS, everything uses a standard mapper except for Codemasters games which have their own. Those would also need a special /CM/ directory or something. But for the most part, it's just drop on the SD card and go.

 

I have full long file name support right now so those aren't a problem.

 

There's probably going to be some kind of way to select a specific mapper though, right now I have a "play as" function so for i.e. NES games I can select an arbitrary mapper number.

 

Not to worry, I will come up with a "skeleton" file directory in a zip file that contains all the Zimba files in the proper place and the suggested directory structure, along with instructions for how to set it up if you want it to work some other different way.

 

I want to make it as easy as possible to use, so I don't want to have to make people use converters or anything if possible. INTV is the single case so far where I had to have a converter because of the absolute mess.

[Pixelboy]

So far, 2600 is about the only system that needs the directory structure for mappers. Most others have headers on them so they aren't a problem (NES, etc). SNES and Gameboy have 'built in' headers in the ROM itself so I use that currently. There's a few odd men out like on SMS, everything uses a standard mapper except for Codemasters games which have their own. Those would also need a special /CM/ directory or something. But for the most part, it's just drop on the SD card and go.

You'll probably need a directory structure for ColecoVision ROMs: Standard, MegaCart and Activision PCB (the last two are homebrew bankswitched cartridges created recently to break the 32K barrier).

 

EDIT: Thanks for the details, kevtris.

[+Tarzilla]

 

I want to make it as easy as possible to use, so I don't want to have to make people use converters or anything if possible. INTV is the single case so far where I had to have a converter because of the absolute mess.

What are you referring to by mess? The ROM format contains the memory map data and was designed to replace the Bin/CFG pair. The jzintv/as1600 package from Joe Z contains rom2bin and bin2rom convertors already...

[Andromeda Stardust]

Kevtris, on the topic of 2600 game emulation, DSP+ homebrews use the ARM coprocessor on Harmony/Melody boards. Due to the scope of the ARM, this would be essentially designing an entirely new "Melody" core as opposed to say 74xx series logic for simple bankswitching. I imagine emulating the melody board would potentially be as complex as the entire VCS console.

 

Also, separating ROMs into subdirectories or editing the file extensions would be a crux. On my harmony, I have a folder for homebrew, hacks, and WIP games, and a folder for commercial ROMs. The commercial ROMs directory is subdivided by alphabet. Letters like S or M that contain more than ~250 files get split, whereas groups of two or three letters with few ROMs may be combined, ie UVW or XYZ. I do all my Everdrives the same way. I've basically got the ROM collections down pat, and a full No Intro set for each classic system, excluding large sets like Neo Geo, GBA, N64, and MAME, will fit nicely uncompressed on a 32Gbyte SD card with room to spare. Just saying, it would be nice to just drag & drop my preexisting ROM collections into a directory for each core system without a fuss.

 

Maybe you should speak with Batari to see how he did the heuristics of detecting the mapper on the Harmony cart. You may find it useful with your FPGA implementation. The Atari mappers are pretty basic compared to NES, so you may be able to cram most of them into your A2600 core. I think the DSP+ ARM homebrew mapper (Melody board) is the only one that's overly sophisticated.

Edited October 2, 2015 by stardust4ever

[kevtris]

Kevtris, on the topic of 2600 game emulation, DSP+ homebrews use the ARM coprocessor on Harmony/Melody boards. Due to the scope of the ARM, this would be essentially designing an entirely new "Melody" core as opposed to say 74xx series logic for simple bankswitching. I imagine emulating the melody board would potentially be as complex as the entire VCS console.

 

Also, separating ROMs into subdirectories or editing the file extensions would be a crux. On my harmony, I have a folder for homebrew, hacks, and WIP games, and a folder for commercial ROMs. The commercial ROMs directory is subdivided by alphabet. Letters like S or M that contain more than ~250 files get split, whereas groups of two or three letters with few ROMs may be combined, ie UVW or XYZ. I do all my Everdrives the same way. I've basically got the ROM collections down pat, and a full No Intro set for each classic system, excluding large sets like Neo Geo, GBA, N64, and MAME, will fit nicely uncompressed on a 32Gbyte SD card with room to spare. Just saying, it would be nice to just drag & drop my preexisting ROM collections into a directory for each core system without a fuss.

 

Maybe you should speak with Batari to see how he did the heuristics of detecting the mapper on the Harmony cart. You may find it useful with your FPGA implementation. The Atari mappers are pretty basic compared to NES, so you may be able to cram most of them into your A2600 core. I think the DSP+ ARM homebrew mapper (Melody board) is the only one that's overly sophisticated.

Yeah I don't like the idea of having the user do a bunch of work either but I am not sure how to get around it in a few cases. 2600 is probably the worst one with regards to figuring out mapper.

 

One way I figured was maybe checking ROM size then using some heuristics looking for accesses to i.e. 1FF8/9 for F8, etc. This is probably how the harmony does it. The ROMs are small enough that the chance of a mis-hit are fairly low. Maybe that's how I do it and if there's some games that fail the check, do the /F8/ etc. hack? There will always be at least ONE thing that slips through :-)

 

I have all the 2600 mappers (Except harmony) implemented already so that's no issue. I did look into emulating the harmony on the FPGA and yeah it looked to be a fairly large job, so if I do that it will be after I work on 16 bit stuff probably. Right now, my 2600 core plays everything pretty much except harmony things. It plays Pitfall 2 for example and Atarivox, and Supercharger demo unit. All the baseline mappers work too (F6, F8, etc). Right now, all the mappers are integrated and there's a selection mechanism that determines which mapper will be used. This is how it works on NES as well, though there the verilog itself reads the header and sets all the hardware up itself.

[+5-11under]

Just some brainstorm ideas...

Assume a bankswitch method based on size, heuristics, whatever.

Have the ability to change the bankswitch method by hitting a hot-key and then being able to select via menu.

Have the user be able to add a -F8 or something like that to the end of the file name (or extension) to force a bankswitch method (unless the hot-key is pressed, of course). Examples: Asteroids-F8.bin, Asteroids.binF8 (I'm not sure I like that one, but maybe it would be good, as you could just put "Asteroids" in the menu, without the extension), Asteroids.F8.

[StarPath]

Don't know if this has been brought up before, but I used to own a MCC-216 and it's FPGA could do up to at least the Amiga (although buggy, probably just an underdeveloped core). They sold the system on ebay for $149 which I thought was a pretty good price. I don't know much on the subject, but just thought maybe you'd want to take a look at the chip they used since it must have been a cost effective one.

[Newsdee]

The chip Kevtris mentioned is at least twice as big as the one in the MCC-216 (i.e. you can put more stuff inside). Should be fine.

[Mr SQL]

 

I have all the 2600 mappers (Except harmony) implemented already so that's no issue. I did look into emulating the harmony on the FPGA and yeah it looked to be a fairly large job, so if I do that it will be after I work on 16 bit stuff probably. Right now, my 2600 core plays everything pretty much except harmony things. It plays Pitfall 2 for example and Atarivox, and Supercharger demo unit. All the baseline mappers work too (F6, F8, etc). Right now, all the mappers are integrated and there's a selection mechanism that determines which mapper will be used. This is how it works on NES as well, though there the verilog itself reads the header and sets all the hardware up itself.

 

Agree matching the classic hardware is more important than emulating the ARM chip - can your core play this game? It's classic SuperCharger architecture, but it broke some emulators when it was released. Breaks on the real hardware if you plug in a Sega-pad.

[kevtris]

Don't know if this has been brought up before, but I used to own a MCC-216 and it's FPGA could do up to at least the Amiga (although buggy, probably just an underdeveloped core). They sold the system on ebay for $149 which I thought was a pretty good price. I don't know much on the subject, but just thought maybe you'd want to take a look at the chip they used since it must have been a cost effective one.

Yeah those guys approached me awhile back about porting my cores to that system. I had a bunch of problems with it though; specifically it was fairly limiting (only s-vid or RGB out from what I recall) and it can only fit 8 cores. I have over double that. It just seemed the hardware was stripped down TOO much and was missing features and things I needed/wanted like HDMI and more RAM busses.

 

When I told him I was thinking of making my own hardware, he got pissed off at me and stopped replying to my emails.

[StarPath]

Yeah those guys approached me awhile back about porting my cores to that system. I had a bunch of problems with it though; specifically it was fairly limiting (only s-vid or RGB out from what I recall) and it can only fit 8 cores. I have over double that. It just seemed the hardware was stripped down TOO much and was missing features and things I needed/wanted like HDMI and more RAM busses.

 

When I told him I was thinking of making my own hardware, he got pissed off at me and stopped replying to my emails.

 

Yeah, it seemed like the cores that they did release the system with weren't very good and I think that's why nobody bought it and the people that did buy one sold them back on ebay probably to be scrapped for the FPGA. You seem to be the only one proposing a really good FPGA system that I know of, so I will definitely be supporting your project and will be the first in line to buy a Zimba 3000. I was so bummed that the MCC-216 didn't deliver what I was hoping, so it's up to you to create the one worth owning.

[Newsdee]

According to forums posts (so take it with a grain of salt) the MCC-216 took open source cores, did some adaptations without releasing the sources back, then never updated them once they became obsolete. I don't know about the open source part, but I can tell you there are much better Amiga (AGA) and C64 cores out there; both the MiST and Arcade Replay have Amiga AGA cores, and the TC64 has a much newer Amiga 500 core (plus an excellent C64 core with SID reimplementation).

 

I love my MiST, but I'll still get a Zimba 3000 if it improves upon its design (say cartridge connectors, mature cores, HDMI out...). As long as the systems are open for development, I see them as complementary rather than competing products...

Edited October 3, 2015 by Newsdee

[Andromeda Stardust]

Bah. All this talk of crappy cores (by people other than Kevtris) reminds me of how buggy the current generation of NOAC clones are. They've come a long way since 2004 and at least FPGA cores can be updated, but inaccurate cores are still inaccurate cores, whether updateable or not.

[Newsdee]

There's excellent open source cores out there. Unfortunately HDL is hard for most people (there seem to be much less developers than emulators) so we only get projects people are interested working on their own time (basically nobody's making money here except the FPGA manufacturers). Check out foft's Atari800 / Atari 5200 for a nice mature core that runs on many boards already.

[Keatah]

Thing with FPGA emulation is the core & software combination together required to play a game or system always seems to be hardware specific. And just above the general layperson's understanding getting it running. Whereas with emulators you can run them on just about any ol' PC.

[bozo55]

Hi all,

 

Been lurking these forums off and on for a while and decided to sign up to participate in this awesome poll!

 

Would love to see the Zimba come to fruition, and if it is as good as I think it will be, it will be an awesome way to save shelf space.

 

I'm hoping it will stay under 200, but... if it has perfect support for... SegaCD, 32X, Supergrafx, PCE/TG Super/Arcade CD, and Neo-Geo I'd be willing to fork out even more (300ish).

 

Cheers to Kevtris. Nothing against the RVGS, but like thousands have already said, there is no market for a new cartridge-based console, given all the costs/limitations. They have no one to blame but themselves but they don't want to accept the truth. I'm just glad all this transpired because it proved the retro market is alive and well to support a practical product like the Zimba. People want to play games on systems that are too impractical to own (AES/MVS, SuperGrafx), but don't want to mess around with the pitfalls of PC emulation (i.e. screen tearing, incorrect audio pitch for frame syncing, and poor input lag).

Edited October 3, 2015 by bozo55