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.