blzmarcel

I have been using computers and consoles since the 1980s and used CD-ROM drives of all sorts since they first came out, and I cannot recall any such problem with CD-Rs damaging CD-ROMS, nor CD-Audio players. CD technology was designed in a way that this could not be the case barring something defective with the laser or or mechanisms or control circuits. However, in case I am missing something, can you cite some examples which might shed some useful info on some specific cases?

This is why projects where an entire community can contribute code, testing time, and insights has proven to be infinitely more effective than a small closed off team of people who don't seem to be able to partition their focuses very well or don't have enough people to really focus on fixes and improvements of existing products while also developing new ones, which is why it can feel like like more beneficial work has come out of the open communities (including also SmokeMonster and Open FPGA) in a single month or few months than Analogue itself has done in five years.

This is the behavior I would expect, as saving the SRAM (especially for 8 and 16 bit era systems like (S)NES, Genesis, SMS, etc), EEPROM, and FLASH should be unnecessary, as savestates already save the current state of the game, the point of which is to be able to continue as if you were playing on a real system without turning it off. The point of the SRAM/EEPROM/FLASH saving was to have a native way of continuing a game without having to leave the system on (or be able to continue from the last save after a power interruption.) If you're using an emulator's savestates feature, then those native game saving schemes are redundant and needless, since you're effectively playing without ever turning off the console, as far as it and the game are concerned. I submit that while there may be a bug, it is one that should be avoidable if one does not use the native save/load feature of the game and instead just relies on savestates to put the game back where it left off.

It is surprising as usually CV, SG-1000, and MSX tend to be developed and bundled together due to how similar the hardware was between them.

Actually there have been a lot of cases where they just used ROMs obtained from the Internet (that are usually 1:1 copies of the original ROM data) and use a nicely packaged emulator. A much better indicator of the preservation of the original code might be a good "remastered" version.

Agreed that this is counter to logic, as you might as well sue every computer OEM and OS maker for selling something that can run games and software downloaded from the Internet or bought from a shady bazaar.

Having a collection of ROMs does not equal piracy. For example, there are many straight forward ways to dump your own cartridges available these days.

I don't see why this should be an issue at all when there exists the likes of EverDrive, Retro USB's PowerPak, and other flash carts, as well as the MiSTer FPGA and other FPGA systems, and hardware that is based around RetroArch/libretro and other emulators, all of which allow one to use ROMs, some as the only or primary method for loading titles, and I've yet to see any sort of trouble there. I'm genuinely curious: why should Analogue need to worry about that when it doesn't appear to be a problem for others? These days, ROM support should be consider essential. The ability to use carts is nice, indeed, though it also makes sense to preserve original carts which (especially ones from the '70s and '80s) can start having issues due to age and wear. And especially for the Pocket, it makes so much more sense to have a large library on single flash media than to carry around carts and adapters, especially for cores for non-portable systems like the NES that had carts that were quite large, or NeoGeo (toting a few of those around is like carrying a sack of bricks.) Also, is it not reasonable to expect such an expensive device to be able to more than RetroArch + an M30 on my phone can do, as far as being able to carry around a complete library of games for systems from the late 70s to the early 90s (aka, the golden age of video gaming) ?

Not sure if that is a good comparison, as the 3DS does not advertise any capability to play games of other consoles (outside of any virtual console stuff at least, if TG16/PC-Engine games were on it), while the Pocket does advertise being able to play Gameboy games, IIRC, so it stands to reason that it should work, or am I misunderstanding something?

I was referring to this: Which isn't a jailbreak issue, since that doesn't exist yet for the Pocket, but something at the stock firmware level.

I'm not yet very keen on these .pocket files, but it'll be far nicer to have a rom loader to load regular rom images proper. I really do not believe that the world needs yet another proprietary / device specific rom format.

It's these crashing and other issues that keep coming up that kind of bothers me. These are systems that have been advertised as being 100% compatibility, due to using FPGA to recreate the original hardware, yet some games are not acting like they would on original hardware. And while I don't want to bring up other systems, I have not observed these sort of compatibility issues on the likes of the Mister, including Metroid II on Gameboy, as well as those SMS games like Desert Strike, and other examples I had previous checked on, after seeing posts here, when I was able to use my friend's Mister. Do not misunderstand. Analogue makes some great systems, but it's hard to feel complete confidence that all of the original behavior of these classic systems is being properly replicated here. And a lot of that stems from the closed source nature, which I understand the reason for, but at the same time it is hard to deny the benefits of have cores open to the community, as there is a very clear difference in how fast issues get resolved with Analogue's cores vs. something like the Mister's or even libretro cores and mame as well. Again, I'm not knocking Analogue here, just saying that the difference is pretty clear and perhaps that they should consider opening the cores themselves, while keeping everything closed, so that they themselves don't have to keep struggle to find time to address every little issue for a given core (whether built-in or "jailbreak".)

By the way, while using -exec rm {} \; work fine, this can be done more directly (and more efficiently if there are a lot of hits) with -delete instead, as it's a built-in feature. So you can just use: find / -name ".DS_Store" -depth -delete Further, according to the documentation [1] for find(1), the use of -delete implies -depth, so this can be reduced to just find / -name ".DS_Store" -delete [1] https://www.man7.org/linux/man-pages/man1/find.1.html This should apply to any version of findutils from at least the past decade, if not further back.

Last post was on the 7th of this month. Not what I'd call dead. From what I've been hearing, both the Noir and higher end Everdrives can handle that. For the former, there are some menu options to adjust when using running from an SD card for cartridge audio.

From what I've tested for a good three months on a friend's Mister setup, systems like NES, Genesis, SNES, TG16, 2600, AO486, don't have any slow down that wasn't present in the original system. NES and Genesis especially were known for slow downs with too many enemies on the screen. NES SMB3 on 1-2 where ones does the gumba 1-up trick. On a real NES (which I tested on my original on a CRT tv) it gets bogged down after several gumbas have spawned in from the pipe and the Mister matches this behavior exactly with default options.

I noticed this thread when I was browsing No-Intro's forums, and it looks like the general conclusion made there is that the No-Intro S&K + Sonic 2 rom is just the two individual roms directly combined one after the other, without any modifications. The author hypothesized that the reason is that resulting rom layout should be as it would be with real carts, and the responsibility for reading and acting accordingly should be on the system running the game, which sets the correct values and such, like a real Genesis/MD would when it detects something in the address space after the main S&K rom. This makes a lot of sense to me and would indicate that the MegaSG isn't behaving exactly like a real Genesis/MD for S&K lockons.

Assuming you're referring to vanfanel, he did state several facts. I have seen and heard the tearing and audio issues that he mentioned first hand, so he is right, and so far no one has addressed that, neither by you nor Mattlelot, who described the MiSTer implementionations as "garbage", which from what I have also witnessed first hand as a friend of mine has one set up, every core we have tried works really well and does not have those issues mentioned before. There was also a very recent update adding 5x crop capability to most of the main cores which also works really well.

Even if it were possible to use NES cartridges with a Pocket, NES cartridges were fairly large, about twice as tall as a Famicom or Genesis/Mega Drive game and wider too. You would need some kind of adapter that either holds the game under the Pocket, or have it stick way out in the air, both of which likely wouldn't be very comfortable, practical, or be able to fit in any but the largest cargo pockets. Sega was able to make the Nomad that used Genesis cartridges due to their rather compact size for a home console cartridge and NEC was able to make a portable that could run PC-Engine/TG-16 HuCards, which again was feasible mainly due to being relatively compact, though neither of those were pocket-able systems, as they both had a bit of bulk to them. Famicom (and maybe SNES/SFC) games might be more workable, as they are short like a Genesis cartridge, but still a bit wider, so it would still be a rather bulky set up. But NA/EU style NES cartridges? It's hard to see a practical way to implement that. They were simply never meant to be used in a portable system.

IIRC, the NES 2 (top loader) didn't do any lockout checks, which is why unlicensed games like Little Red Hood can be played directly without a licensed cart attached S&K/GameGenie style on the pass-thru slot, so it seems very unlikely that there would be a kill switch based only on the CIC lockout.

@Kaide That may be true about MAME, but what about this (as I mentioned in one of my previous posts) ? I have cloned the repo to my hard drive and searched through it and couldn't find any sort of list of games or checksums/hashes/etc. I even searched the binary release in a hex editor and couldn't find anything there either. Over at that friend's place where he has it set up, we threw every home brew, prototype, and demo we could find at it and it just ran them, so it seems the author of that core found a more abstract/generalized approach, which leads me to believe that there is some way of determining what a game needs (what mappers, etc) from the main ROM data itself, which might be worth more study.

Some good points, though my point is that there was some kind of header early to help emulators do the right thing, but afaict nothing of the sort existed at all for Intellivision ROMs at all until recently.

What I'm wondering is if the mappers as similarly important for the Intellivision as they were on the NES, why wasn't there an equivalent of the iNES header prepended to the ROMs early on? This was recognized as a necessity for NES ROMs going at least as far back as ye olde NESticle emulator. I've seen people mention there were cfg files, but packs like the Everdrive and MAME sets don't seem to have any. I tested in both MAME and on my friend's Mister again, both of which ran every homebrew, demo, and prototype from the Everdrive set that was thrown at either without any issue. In the Mister case, we browsed from a computer and couldn't find any cfg or similar files that were generated (since it's a third party core (github/source code) that didn't come with the system.) This makes me wonder if there isn't already something in the ROMs that lets newer emulators and cores know how to treat them, especially if homebrews and such run just fine.

I'm all for adding extra information similar to iNES headers, and agree that it's nicer to have everything together in one file, though that extra information still needs to be read upon loading, so in the end it really shouldn't make much of a different where that needed info is read from (from a header/footer, or accompanying file.) Is it really known which order actually matches the original ROM? Even if it was read directly from the chips, from what I know, that should be the same data that would be read through the edge connector (by an Intellivision or a proper dumping tool.) Aside from the NT Mini (and I assume also other Analogue systems), emulators and FPGAs that that support Intellivision all assume the byte order of the long established ROM set that's been out there for decades. So why was this necessary for just this one system and not all of the others? I did a test with the int2intv tool, using Frog Bog, and found that it is adding to both the beginning and the end, and not just the end of the file: Frog Bog (1982) (Mattel).int (Matching: <rom name="frog bog.50" size="0x2000" crc="37222762" sha1="58842e4425ad5a8f6ec65528c4b485039057f289"/> from the MAME intv.xml hash file.) 00 66 00 56 00 1C 00 50 00 91 00 59 00 71 00 50 .... 02 90 00 80 02 0C 00 03 00 12 01 C9 02 51 02 B7 Frog Bog (1982) (Mattel).intv (Using int2intv -m 0, with a -m value of 0 going by the spreadsheet linked from the int2intv github page.) # Added header section. 00 50 00 00 00 10 00 00 # Same bytes as original, with every pair of bytes swapped (16-bit dword endian flip.) 66 00 56 00 1C 00 50 00 91 00 59 00 71 00 50 00 .... 90 02 80 00 0C 02 03 00 12 00 C9 01 51 02 B7 02 # Added footer section. 00 00 00 00 00 00 00 00 Due to the added information to the start, in addition to the byte endian flipping, I don't see how INTV2 (.intv) files could be used with all the other emulators out there. If the header wasn't added (but rather just the footer) and the bytes weren't flipped, then yeah, it would probably work in most emulators, but from what I can see, people will need to have two (three when counting MAME, due to the zipping and different file naming) separate sets of files, wasn't granted, isn't a huge deal, as the full Everdrive set for Intellivision, including home brews, prototypes, demos, and all the regular games, is less than 4 MB total.

I'm honestly a little confused. What do you mean by "core's native architecture" ? It is my understanding that with FPGA, the architecture of an original system is being replicated, all the chips, processors, circuits, et al, and thus all of the original behavior of said system. I assum what would happen (and what appears to be the case with other FPGA systems) is that the data from a ROM file is handled the same way an original system would read the ROM data from a cart, as AFAICT, the .int/.bin ROMs that have been around for quite a while are the original binary 1:1 dumps of cart ROM which any other FPGA and emulator expects. But the NT Mini (is this also true of the Super NT and Mega SG?) needs a change of endianness which still strikes me strange that no other FPGA system or emulator requires this.

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. What I do find interesting is that the NT Mini seems to be the only platform to need the INTV2/.intv format. I noticed, when I was looking through a recent Everdrive pack that I found, that the included Intellivision roms all matched the checksums of the ones that I've had since somewhere around 1999, which also match the ones from both older MESS and newer MAME sets (within the .zip files), as well as the ones used for standalone emulators and Retroarch cores, and even the Mister core (which I recently tested at a colleague's home, using the Everdrive set), which are all .int/.bin and in the format that int2intv.exe expects on the input side. I know people here have explained that the issue is one of endianess, and I understand what that means, but what is strange to me is that nothing else that I can find uses the INTV2/.intv versions of those roms, so why is the NT Mini so different than all the rest?