Jump to content
IGNORED

FPGA Based Videogame System


kevtris

Interest in an FPGA Videogame System  

682 members have voted

  1. 1. I would pay....

  2. 2. I Would Like Support for...

  3. 3. Games Should Run From...

    • SD Card / USB Memory Sticks
    • Original Cartridges
    • Hopes and Dreams
  4. 4. The Video Inteface Should be...


  • Please sign in to vote in this poll.

Recommended Posts

On 12/17/2020 at 4:46 AM, schnuth said:


For what it’s worth I prefer to use my Everdrive with my jailbroken Noir too.

Well, the literal reason that I bought it was for FDS, but that got added to the Noir and my Everdrive is still in the mail, so... maybe I can just sell it or something, as I don't have a Famicom or anything else. I was thinking of getting a Famicom for some time before I bought the Nt mini, but seeing as the Nt mini can do analog output (although I do not have or know where to get a cable for that), there really isn't much of a point unless there are some compatibility issues or something, but I'm not sure how to set up the audio on the Nt mini (I left it in its stock configuration for audio since I have no idea what the system is "supposed" to sound like) and I don't have to bother with that on a real Famicom.

Link to comment
Share on other sites

On 12/16/2020 at 3:59 PM, blzmarcel said:

I know Analogue products are closed, but assumed the jail-break itself was open, especially given that a github link was given. I know the kevtris made the original jail-breaks for the older NT minis, but seeing as the link given was for a Smoke Monster repo, I thought that had changed.

Nope it's the same as before. Github is just a more convenient way to distribute it because it allows outstanding issues to be reported and tracked.

Link to comment
Share on other sites

11 hours ago, blzmarcel said:

Forgive me, but what is the point of using a flash cart, which loads ROM files, when you have a jail-break, which can load the same files more directly? Does the Everdrive (N8 I presume) have some advantage, like better extended audio or other custom chip support that some real games might have used? If that is the reason I can understand that, otherwise it seems redundant.

 

The biggest factor for me is the newer N8 Pro has multiple save states, which the jailbreak doesn't have.  

Link to comment
Share on other sites

Only thing that rubbed me wrong is the Nt Noir pretty much subsumes the MegaSg as it runs Genesis, SMS, SG1000 and CV roms.
Only "advantage" of MegaSg is that it can use proper wired controllers and can connect MegaCD (if you really have to) and of course proper cart adapters.

 

I really wish that for Xmas as a gift to customers Analogue would allow Kevtris (or the firmware fairy) to release some of "teh cores" on the MegaSg and SuperNt:

for both I would say it is fitting to get A2600 and A7800, for the SuperNt Intellivision fits (NTT controller) [and CV as well to be fair]

 

The MegaSg with Genesis + SMS + SG1000 + GG [+ CV in JB] is arguably a better package than the SuperNt .... the SuperNt should get GB/GBC cores just for parity (with cart adapters to stay legit, Super Game Boy per se does not really support GBC).

 

I believe the various units now to be pretty much the same under the hood one way or another and some of the 8bit cores should be easy to port around with proper cart adapters for official consumption and let the Nt Mini Noir be the king of the hill for NES and all other 8 bits.

 

So my Xmas wish list is:

 

MegaSg enhanced JB:

A2600 and A7800

Intellivision

 

SuperNt enhanced JB:

A2600 and A7800

Intellivision (NTT controller)

ColecoVision (NTT controller)

GB/GBC cores + cart adapters

 

 

Anyway one can always dream.

 

I know some people swear by the Channel F or the Arcadia 2001 .... eventually we will get the Analogue Super8 (or whatever that would be) but until then some small concession to MegaSg and Supernt customer is welcome.

Link to comment
Share on other sites

6 hours ago, schnuth said:


Thanks so much for this, it’s very much appreciated!

Btw, I see there is a quite exhaustive font pack on Archive as well. I found one I like but I’ll have to try some of these out too.

I now added the right 012.bin file too. The old one was wrong as I forgot to reverse the bits.

  • Like 2
Link to comment
Share on other sites

I now added the right 012.bin file too. The old one was wrong as I forgot to reverse the bits.

 

Excellent, thanks a lot. I tried an Intellivoice game and wondered what was going on. atariage_icon_mrgreen.gif

 

What do I search to find the NT Mini files on Internet Archive?  I have tried NT Mini of course..

 

If you search NT Mini Noir both eewoke’s Intellivision pack and the font pack come up. Sorry for not mentioning that before.

 

I also haven’t been able to find the Odyssey2 Voice files with the proper working checksums yet. Has anyone found these?

Link to comment
Share on other sites

On 12/20/2020 at 3:35 AM, eewoke said:

I now added the right 012.bin file too. The old one was wrong as I forgot to reverse the bits.

Could someone please explain why all these issues exist for Intellivision roms? I don't believe I've seen anything like this for emulation, etc of classic consoles from the 70s/80s/early-90s. ROM files are typically images of ROM chips (PRG, CHK, which often combined/concatenated, though sometimes separated, like in MAME) that have been dumped. Binary image should be just that, a binary image, so what is the deal with Intellivision here?

Link to comment
Share on other sites

Could someone please explain why all these issues exist for Intellivision roms? I don't believe I've seen anything like this for emulation, etc of classic consoles from the 70s/80s/early-90s. ROM files are typically images of ROM chips (PRG, CHK, which often combined/concatenated, though sometimes separated, like in MAME) that have been dumped. Binary image should be just that, a binary image, so what is the deal with Intellivision here?
Don't know, but I recall when the byte order of N64 ROMs was a deal because your backup unit used Big or Little Endian. Considering that the Jailbreak is going to run them like a backup unit might then they need to be mapped to memory correctly. Still, I expect it should recognize something like that and flip the byte order if needed.
Link to comment
Share on other sites

10 hours ago, CZroe said:
11 hours ago, blzmarcel said:
Could someone please explain why all these issues exist for Intellivision roms? I don't believe I've seen anything like this for emulation, etc of classic consoles from the 70s/80s/early-90s. ROM files are typically images of ROM chips (PRG, CHK, which often combined/concatenated, though sometimes separated, like in MAME) that have been dumped. Binary image should be just that, a binary image, so what is the deal with Intellivision here?

Don't know, but I recall when the byte order of N64 ROMs was a deal because your backup unit used Big or Little Endian. Considering that the Jailbreak is going to run them like a backup unit might then they need to be mapped to memory correctly. Still, I expect it should recognize something like that and flip the byte order if needed.

Yeah that's the job of the core. And if the core is doing what the original system is doing (which is one of the main points of FPGA) then I'd expect it to just read the image like it would a cart, as an image is should be the same 1s and 0s as the cart's ROM. The same should be true of N64, though I've never heard of that backup unit, so maybe it's doing something different rather than just dumping/imaging as it was on the cart. Seems in either case, some people have ended up over complicating matters.

Link to comment
Share on other sites



Yeah that's the job of the core. And if the core is doing what the original system is doing (which is one of the main points of FPGA) then I'd expect it to just read the image like it would a cart, as an image is should be the same 1s and 0s as the cart's ROM. The same should be true of N64, though I've never heard of that backup unit, so maybe it's doing something different rather than just dumping/imaging as it was on the cart. Seems in either case, some people have ended up over complicating matters.


If the core is doing what the original system is doing but the byte order is wrong then it won't work. A dump is the same 1s and 0s regardless of the byte order, it just has a different order of bytes. ;) Byte order is a thing when programming ROMs too and it'll be an option right there when you select your files to program, since the 1s and 0s in the ROM file don't contain anything extra to tell the programmer what byte order to use and, indeed, could already have a different byte order for the programmer to use sequentially.

I didn't actually mention the backup unit but I owned the Bung Doctor V64 and V64jr. Bung used a different byte order from Mr. Backup Z64 and every other backup unit, presumably because it was easier to map to cartridge memory with less logic or something. Big Endian and Little Endian are byte orders that ROM dumps can use. This was from a time when. N64 ROMs weren't useful outside of backup units because UltraHLE or any other commercial emulators capable of playing N64 ROMs didn't exist.
Link to comment
Share on other sites

2 hours ago, CZroe said:

If the core is doing what the original system is doing but the byte order is wrong then it won't work.

Byte order shouldn't be an issue if the core is handling the image the same way it would the ROM data on a cart, reading the same information.

 

Quote

A dump is the same 1s and 0s regardless of the byte order, it just has a different order of bytes.

;)

Byte order doesn't come into it, or at least shouldn't. A binary image is just the same 1s and 0s as the source, a 1:1 copy. Sometimes it can be compressed, like .smd vs .md/.bin for Genesis. Anything else is not a real image. Anything ending in .bin should be a direct 1:1 (uncompressed) copy of the original source.

Edited by blzmarcel
Sorry, accidentally hit enter while holding ctrl or shift and it submitted the post prematurely...
Link to comment
Share on other sites

2 hours ago, CZroe said:

the 1s and 0s in the ROM file don't contain anything extra to tell the programmer what byte order to use

This is why a lot of binary images have an extra file, like .bin and .cue for images from optical media, which describes the layout, tracks, etc, but for something like a game ROM, a .cue type file isn't normally needed since the original game system already knows how to read the data. A core, especially in an FPGA system, should handle that original data like it would from a cart; same binary data, regardless if it came from a ROM chip or a .bin file.

Link to comment
Share on other sites

24 minutes ago, bikerspade said:

It's not that simple; ROM dumps don't necessarily contain information about supplemental circuitry and other hardware. Which is why NES headers are required to provide information about this hardware (mappers). I believe Intellivision falls into this category.

Good point. The headers are information tacked onto the beginning (hence the 'head' in 'header') of the image file but the rest after that is the binary data from the cart. Such headers serve a similar purpose as a .cue file for a cd/dvd/bd .bin, to give additional information about a binary image.

Link to comment
Share on other sites

2 hours ago, blzmarcel said:

Byte order doesn't come into it, or at least shouldn't. A binary image is just the same 1s and 0s as the source, a 1:1 copy. Sometimes it can be compressed, like .smd vs .md/.bin for Genesis. Anything else is not a real image. Anything ending in .bin should be a direct 1:1 (uncompressed) copy of the original source.

I'd agree it shouldn't come into play, but it does. For simpler systems with an 8-bit data bus, it certainly shouldn't be an issue since you are reading data in small enough chunks that it is effectively a 1:1 of the EEPROM contents. NES, Master System, and SNES for example.

 

Things get more complicated as you start dealing with 16-bit data buses present on the Megadrive, or the N64. A backup tool will generally dump the cartridge a word at a time using the cartridge bus, where a word is 2 bytes in these two examples. So when I write it out to storage, should it be LSByte first, or MSByte first? If I just record these values into a buffer and flush the buffer as a series of bytes to storage, then endianness of the system affects how the data is recorded. The 68k is big-endian, while the MIPS chip the N64 has is configurable (although I don't know which mode Nintendo used, or if it was switchable while running). So if I don't standardize on what byte order is in the ROM file itself, then it can't be read properly on the other end without some sort of detection looking for something that can be treated similar to a UTF BOM.

 

And there's an argument to be be made for both LSB and MSB when it comes to consoles like the Megadrive. LSB is more common for EEPROM programmers being used on x86 (DOS generally) at the time. MSB is how the console itself sees it. So which is "real"? At least in the case of Megadrive, the light reading I've done so far seems to suggest that big-endian is the convention, because the original dumps were done on-system. They could have used LSB by byte-swapping things before writing them out in those dumpers to more closely approximate what the raw files written to the ROMs would look like, but they didn't.

 

It should be pointed out that smd is interleaved when compared to md/bin, due to the dumper that produced them operating in Z80 mode (and likely some addressing issues in Z80 mode), so to load those, you have to know that the high and low bytes for each word are 8K apart from each other in the dump, sliced up into 16K blocks. And which ones are the high byte, and which are the low byte. Fun. 

Edited by Kaide
  • Like 1
  • Thanks 1
Link to comment
Share on other sites



Byte order doesn't come into it, or at least shouldn't. A binary image is just the same 1s and 0s as the source, a 1:1 copy. Sometimes it can be compressed, like .smd vs .md/.bin for Genesis. Anything else is not a real image. Anything ending in .bin should be a direct 1:1 (uncompressed) copy of the original source.

Not quite.

Byte order shouldn't come into it because the core should be able to recognize and adapt but, then again, so should the backup units of yore. Indeed, many PC-side transfer apps did this automatically for your target cartridge emulator/backup unit. Some stand-alone units eventually did get built-in byteswap features through firmware updates.

Again, it's the same 1s and 0s in a different byte order. There is no intrinsic byte order that the ROMs have to be read but the physical layout, number of ROMs, and addressing limits may dictate one.

Byte order often has more to do with bus addressing. For example, a N64 cartridge does not have all the address and data lines on the physical cartridge to read a 64bit data bus. Indeed, even the ROM chips are not standard ROM chips and they include some built-in addressing logic. Bytes are read in a sequence and the resulting sequence can define a preferred byte order for the ROM file or for any hardware attempting to replicate that addressing logic.

Not saying there's anything like that going on here. Just spitballing about what kinds of things can cause one set of ROMs to work and another that doesn't with the same 1s and 0s.

This is why a lot of binary images have an extra file, like .bin and .cue for images from optical media, which describes the layout, tracks, etc, but for something like a game ROM, a .cue type file isn't normally needed since the original game system already knows how to read the data. A core, especially in an FPGA system, should handle that original data like it would from a cart; same binary data, regardless if it came from a ROM chip or a .bin file.


The reason you don't need extra files with ROMs for more systems is because they are in a format with a header that includes that information. IOW, they are not just a straight dump of 1s and 0s. NES ROMs, for example, are largely useless without the iNES header that proceeds them. Doesn't matter that they are the exact 1s and 0s if you don't know what to do with them to replicate the rest of the addressing behavior (mappers, banks, SRAM, and such). Byte order is much the same. As I recall, neither N64 ROM format had their own header because Nintendo themselves had a header built-in to the ROM data complete with CRC, protection chip, and game name.

I believe emulators and automatic utilities that supported both agnostically of the filename extension would look to that header for something known, like the word "Nintendo," and then determine byte order from that. This is not something the original console would do and not something a replicated core would do unless it was written specifically to do more than the original console. If Analogue wants to pretend this functionality was not there for playing downloaded ROMs and only there for playing ROMs in the format it might create when you use their cartridge adapter or whatever and, this, existed to be "unlocked" with a jailbreak, well, that's one reason it might deliberately support only one format.

It's not that simple; ROM dumps don't necessarily contain information about supplemental circuitry and other hardware. Which is why NES headers are required to provide information about this hardware (mappers). I believe Intellivision falls into this category.


Exactly.
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...