blzmarcel

Thank you, this really helped, as I'm aware of other systems, like the C64, that also used bank switching techniques. Cheers and Merry Christmas if applicable :)

Thanks. Might I ask why the mapper chips aren't dumped along with the CHR and PRG ROMs? I'm not too keen on what mapper data looks like, I was mostly just aware of the two mentioned ROMs.

I've sometimes wondered why an original NES or Famicom would know what to do without any such header, yet emulators always seemed to need it. Conventional thinking would be if an emulator is doing what an original system was doing in reading and parsing the data on the cart, though there is likely something more to it otherwise this would have been solved a lot more easily.

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.

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.

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

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.

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?

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.

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.

Is there source code available for the jailbreaks? All I see there are binaries, which is fine and all but I was hoping to look at some of the code too.

A couple of things that should be mentioned. While RGB was available, it was fairly uncommon in NA and JP markets. A lot of the developers, especially the bigger ones, were mainly targeting the Japanese and North American (read: US and Canada) markets (many of them were also based in those regions), so RF/composite was the display type that was targeted by most of them since they knew that's what most people at the time were using. Europe had SCART at that time, yes, though most televisions also had RF and that was also used by a lot of people. I recall that not all televisions had a SCART connector, so it wasn't something that even European developers at the time would have been able to fully rely on (especially in the 80s still), though from what I've seen, many games developed in Europe didn't rely as much on composite and RF blending tricks as those made for Japanese and American markets.

That's not entirely true. There are many Genesis/MegaDrive games that were made with analog RF/Composite display technology and it's characteristics in mind, especially (but not limited to) transparency effects, with the water falls in Sonic 1 being a common example, but there are dozens of others that also used such effects that simply aren't going to be visible when viewed in a more raw digital form. So yes, while appearance can be subjective, it can also be said that many of these games were meant to be viewed a certain way by design and the intent of the developers that made them, which is why these blending/dithering effects are often seen as being a more canonical appearance instead of what is directly coming out of the video processor.

I find this scenario especially disturbing, as many other vendors and sites tend to handle customs so customers don't need to. I've ordered many things from the UK and other parts of Europe and never had any issue. So either Analogue is dropping the ball with shipping (an area which generally has appeared to be an issue for some time) or the UK is doing something dodgy with the importing, as half the cost of the product really is fishy and reeks of corruption.

I think the issue might be that the Sg and Super Nt are based around 16-bit consoles (vs the Nt being based around an 8-bit console), so many might believe they would be more powerful systems and hence be able to do more, which doesn't feel like an unreasonable general expectation. It certainly came as a surprise to me to find out that the Nt Mini is more capable than it's 16-bit bigger brothers.

Thank you, I'm more than happy to be corrected when I've put down something that's factually wrong. What I don't quite understand is why Nintendo would go through the trouble to add an iNES (or another other) header to raw dumps, instead of just using a check-sum, which, iirc, is what the likes of RetroArch uses to identify particular roms (like for matching a thumbnail to a game.) It just strikes me as odd, which is likely what makes it easy to believe they just used readily available ROM sets (e.g., the No-Intro set from archive.org) even if that that could easily not be the case.

I would argue when they bring it back a decade-plus after it was fully superseded is more of a novelty at that point. The main product (Switch, XB1, PS4) is what they're really selling. Things like the "Virtual Console", XBL Arcade, etc, and even the likes of the "NES Classic Edition" are largely emulators, rather than a reproduction of the original hardware. The VC was even found to be using NES roms that could be found on most rom sites over the years, completely with the extra iNES header which was a dead giveaway. So while it might matter to a degree, it's not the same as when the system was in it's prime.

Another important difference is that Bleed and VGS came out when the PS1 was still being sold, so it was an issue of competition, which Sony argued was unfair. Regardless of who won, it's a very different matter when it comes to consoles and games decades after they ceased being sold in the primary market.

Huh, strange that they would do that. I can't think of any other console that came to NA from Japan in the 80s or 90s, that didn't originally have hard-wired controllers (ahem, Famicom), that used a different port when it was brought over. The closest I can think of was the model 2 Genesis and Mega Drives using a smaller DIN for A/V over the model 1.

PC-Engine and TG-16 are the same console. The former was renamed to the latter for the NA market, and I could swear they used the same controller ports (I can remember a friend back in the 90s using a white PC-E controller on his North American TG-16 console.)

I get that, but at the same time there are many of third party consoles, FPGA or just regular emulation, that support ROMs just fine, and some also allow dumping, yet have not been shutdown, as far as I'm aware.

I honestly feel that Analogue has places an overemphasis on using game cartridges. It's great to have that option, but they seem to be missing a very important reason to have ROM file support, which is preservation. It's (near the end of) 2020, a lot of game cartridges from the 90s, 80s, and 70s are quite old now, and putting them back into constant use can wear them out. For example, a lot of NES/Famicom, and SMS/SG-1000 games are approaching 40 years old. This is why I have dumped all the games I originally owned and have held onto over the years, and generally play their ROM counter parts while keeping the originals in a safe, cool, and dry place. This is very similar to how people have ripped DVD and CD libraries over the past couple decades. Preservation should not be under estimated. It is my humble opinion that any modern retro gaming system that has cartridge slots, should have the ability to dump the cartridges to ROM files that can then be loaded instead of the cartridges, out of the box, without any need to "jail break." This feels especially true for something like the Pocket. While I don't mind using real cartridges, it's much nicer to be able to choose from a menu containing my whole library, while keeping my original cartridges safe.

That seems really strange and contrary to how carts work on many other shopping sites out there, where if the item is successfully added to your cart, than that item is claimed / allocated to you for a certain time frame, one of the main reasons being to give the user time to sort through billing and shipping without feeling rushed. Maybe it's different for pre-orders, since the item isn't available yet, though that should still be made clear on the site.

Quick question: From what I've read and understand thus far, the Analogue Pocket is designed to play carts rather than ROM files, but are we able to assume that the "jail broken" firmware will allow ROM files to be played under the various cores? I ask many out the desire to play the ROM-hacks that I've been collecting for sometime, such as the plethora of SMB1/2/2J/3 ROM-hacks, that offer new challenges to old favorites. I am assuming there wouldn't be cart adapters for NES, SNES, Genesis/MD and such since the carts would be a bit too big, especially NES carts, so it seems logically that were would need to be a way to load ROM files, and if I'm not mistaken, the Analogue's full size consoles have this capability. I also find it fair to surmise that many people aren't going to want to carry lots of carts with them on the go, especially carts for full size classic consoles.

Does the screen really need to be an exact multiple of the original GB screen? I recall that most hand-helds from around time didn't perfectly fill their screens, leaving a minimal border around. This was true of the GB, GG, and others that I remember seeing back then. Another thing is that different hand-held consoles ran at different resolutions, so what is a perfect multiple of one platform might not be for another (e.g., GB vs GB vs Lynx vs TurbleExpress vs NGCP, etc) so at least of these aren't going to have a 100% perfect fit, so one way or another there will be a border, unless some stretching and filtering is being done Who knows, maybe they have some clever solution for that, though in general, I don't see having an image that's slightly smaller than the screen itself as an issue, as that's how it was many of those original systems. Heck, I've seen many smart phones and tablets that don't go completely to the very edges of the panel.