Kaide

This is a bit of a murky area once the DMCA gets involved. However, this particular argument you put forward was tried by Sony against Virtual Game Station and failed. In that case, VGS was doing a check for CD-Rs and rejecting them. While not the same thing as the anti-piracy check Sony did, it was hard to say that VGS encouraged piracy when it only played the pressed discs that made Sony money. Since the Pocket only plays carts out of the box, and it is no more susceptible to piracy than the hardware it emulates, this argument would play out before it ever goes to discovery due to the clear precedent available here. I really would be surprised if this argument led to discovery on other issues, because it’s such a simple argument that could be made to the judge based on similar precedent. I would call this scenario a fishing expedition, and any lawyer worth their salt would be pushing back on such a thing during the initial hearings. Precisely because it is the cheap/expedient thing to do.

As far as I know, they don’t have a shipping department. I think they use an external logistics company for warehousing and shipping. Don’t know if they use the same one they used when the Mega SG launched.

I don’t think the N64 really stood the test of time all that well. The number of games that are still in the public consciousness are few. I grabbed a GameCube for the retro collection already but still don’t have an N64. I had that article in my reading list but hadn’t read it yet. Interesting. I wonder what they are doing differently for 4K on the Cyclone V then.

As RobDangerous points out, the N64 Mister core is coming along surprisingly well. The DE10-Nano uses the same FPGA that Analogue has been using for a while now. The Pocket is a dual FPGA setup where the second FPGA is used for video output, which helps share the load without going for a much more expensive monolithic FPGA. In terms of hardware complexity, the differences between the N64 and PS1 don’t necessarily translate into more or less space on an FPGA. It’s a good rule of thumb, but is probably more useful when comparing between console generations. Newer processes meant higher transistor density, which means more complex circuits can be designed in the same area of silicon. I don’t know enough to really say much about the PS1 vs N64 in terms of transistor count + density across all the chips that you need to reimplement (it’s not just the CPU or GPU). I wouldn’t be surprised if this is a console version of the Pocket in terms of hardware. Maybe a beefier secondary FPGA for the 4K output and CRT simulation. So the cost really depends a lot on that secondary FPGA and how similar it is to the Pocket setup.

And this is for the reasons I've already covered. It's linked to the need to burn slower as well. Burning the disc slowly gives it more time to burn in more distinct pits and lands, which makes things easier for these older CD drives that aren't as sensitive. As for the 700MB CD-Rs not being "as good", that has more to do with the tolerances in older pickups. Since the 700MB discs are a bit more dense, a laser that is borderline to the CD spec might have issues reading it if it can't cleanly focus on the single track and picks up noise from the adjacent tracks. That said, if the drive reads it, the drive reads it, and the tolerances for that unit are fine. But I can see how the rule of thumb would come about as some folks could very well have units that don't read the 700MB discs reliably. The drive unit in the Analogue Duo is going to be a modern unit. Meaning it will have a modern, more sensitive optical pickup for the laser return. This will make it more tolerant of CD-Rs than the original hardware ever was. It will also mean 700MB discs shouldn't be a problem. That's assuming that Analogue doesn't lock out CD-Rs in firmware like Virtual Game Station did back in the day. You don't know, but you made the claim that they do with pretty high certainty earlier in the thread. While the hunting can add a bit more wear to the mechanism over time, it's not a direct harm. No more than driving faster in your car will damage it due to the extra wear. That's an old wives tale.

I think you need to clarify what you mean by this. The fact that it can read CD-Rs at all means the bits are encoded the same way on the physical disc. If you are talking about the format of the data directory (aka Filesystem) on the disc, that shouldn’t matter either as a clean rip is a byte-for-byte copy. The thing that pops into mind immediately is more that the laser in early drives tends to not like CD-Rs as the pits aren’t as cleanly defined as they are on pressed discs. This can lead to retries and the like, which leads to slow loading of data. Analogue today if they offer up a CD drive, it’s going to be a mostly off the shelf unit, possibly with custom firmware if needed. They aren’t going to be building a CD drive from scratch.

If the older firmware lacks bits for the hardware changes that were made, then it would make sense to block downgrading below 4.9 to avoid someone flashing an incompatible version and getting into a bad state.

Yeah, you can't use Memories to move between different cores (and the cartridge cores are "one" core in this scenario). But there are other options here since the save memory is on the SD card. So: - Cart <-> Everdrive: Save state, swap, load the save state. - Cart -> openFPGA Core: Save state. Using a PC, copy the .sav file from the save state to the save location for the ROM and rename it. (I have done this, it works) - openFPGA -> Cart: Move to an Everdrive, change the file extension to match what the Everdrive needs, then do that trick. Or just get a GBxCart RW. That last one is the one that I consider risky to do. At least if you don't have an Everdrive or GBxCart RW. Because if you take an existing save state and swap out the .sav file (the approach you'd need to try if you just have the Pocket), then you run the risk of corrupting the save memory. Depends a lot on the game and how it handles it's save memory. The annoying part is that the Everdrive and others use different file formats depending on what type of memory the cart used, while Pocket always uses .sav, so have to rename when moving these files between Everdrive and the Pocket using a PC.

Aha, I was thinking from openFPGA to cart since I don’t have a GB or GBA Everdrive yet. But getting a save state from an Everdrive would be more reliable, yes.

I think you picked up on a different train of thought here and went down a different direction. I’m well aware of what the save memory is used for, and I don’t need a refresher of my EE courses, thanks. There’s the discussion about why the cores might not be loading save states from certain games, but there’s also my own meandering through the Pocket’s behaviors as I started to poke around a bit. And I did find the cores and carts behaving differently interesting and decided to share. The Pocket does dump the save memory when making save states from carts. Until I saw it, I wouldn’t have expected it. However, if the goal is reliability, then ignoring the save memory is not a great approach the more I think about it. Reason being corruption. And games of the GBA era are more likely to be doing things that make it easier to corrupt the save memory if the state of the system and the state of save memory get de-sync’d. These things would be true for the openFPGA cores as well, but less likely to happen. I wouldn’t call the native game saving schemes redundant or needless in the presence of save states, to be honest. I used both on my recent playthrough of Link’s Awakening. It’s not even clear if the Pocket happens to include all of memory in the sta file or not. Need to dig in more to understand better how save states work. I half expect they probably use something similar to a format already used by emulators, but haven’t had time to do adequate research. That said, none of this adequately explains why save states for some games don’t load properly in the openFPGA version of the core, which also happens to break sleep/wake for those games. I will say this though, the more I do dig into the Pocket, the more interesting I find their custom BIOS. Since both the cartridge and spiritialized1997 cores use raw save memory files like emulators and Everdrives, it should all be pretty easy to move stuff around. I’ve just not tried using the Pocket to write save memory back to a cartridge, as it seems a bit riskier. I should maybe try with something I can stand to lose sometime?

Looks like it. I was able to load save states for Silver/Gold later in the game when I tried today. But I think I may have answered part of my own question about save states causing corruption. Save states include a dump of the save memory for carts, in what looks like raw form. So the question is: what does the {ocket do with the copy of save memory when loading the save state? Clearly one step is loading the RAM and register states, and another step is doing something with the save memory file which may include writing it back out to SRAM/EEPROM/FLASH. So sounds a bit like there could be bugs with that second part. It also suggests that carts that use EEPROM and FLASH might be getting extra wear from save state use? Hmm... Save states for the spiritualized1997 cores for the couple of ROMs I've tried don't contain the save memory, just the system state. So corruption shouldn't be an issue there in the same sense if this is intentional. So far it looks like it is, as I've been able to load save states for games that use SRAM but don't include the save memory file. This makes sense since it is a lot easier to get the save memory into an unexpected state with an original cart (take the game to original hardware, play for a bit, and then try to load the save state on the Pocket). Either way, I think it's safe to assume the Pocket expects a save state to include the current state of the save memory, if any. Upside is that the save files can be moved back and forth between carts and the spiritualized openFPGA cores since they both use raw save memory like an emulator or flash cart does. So it should be safe to make a save state from a cart and import the save memory into an openFPGA core at least. It could also represent a way to potentially recover a corrupted cart's save memory if the save state wasn't itself corrupted when the dump was made (and the save memory dump isn't a new feature added in 1.1 or something). So at least I'll feel less bad about starting a save file on a ROM while I hunt down some of my missing game carts, knowing I can move between the two easily.

If it was disabled intentionally, I would expect the save state to fail, rather than the load failing. And something in the readme for the cores about it. But yes, I have seen the behavior with carts where the clock gets reset to the point when a save state was made. This isn’t surprising because it is saving out the RAM state of the system, which includes the current clock state. The RTC in the MBC3 is used to track time elapsed since the last reset of the clock (which needs to be done every so often), rather than any absolute time. The issue with sleep and saves is more interesting, and I’m not seeing enough detail in the reports from 8mo ago to draw specific conclusions there. It’s interesting that the GBA titles are also affected, as Nintendo moved to using flash and EEPROMs for save data with the GBA. Since these types of memory are less volatile than SRAM, I am curious how just loading a save state (on wake) could corrupt it, as the data should not be in an unexpected state. But the OpenFPGA cores generally should be able to define their own save state routines differently, and could very well have different or fewer bugs than the Analogue cores attempting to work with real carts.

Talking about the Spiritualized cores, correct? Makes me wonder if there might be game-specific issues, or if it’s even a bug in the Pocket firmware beta (1.1b6)? GB seems to work okay, but GBC/GBA won’t load save states for the ROMs I have tried (Link’s Awakening DX, Pokemon Gold, Pokemon Sapphire, Pokemon Leaf Green), but they will happily save them. —— Forgot to bring this up, but I have had d-pad issues. The cardinal directions are fine, and I don’t get false inputs on those, but getting diagonal inputs is difficult (left diagonals) to borderline impossible (right diagonals). Using a button testing ROM, the behavior is quite clear (rolling from up -> right -> down shows each of those directions, but no diagonal inputs at all unless it’s in a tiny spot). I started noticing later on in Link’s Awakening when more diagonal movement gets to be useful/important, but it’s also made special moves really difficult on fighting games like Killer Instinct. Move the cart to my SP, and everything is golden. Odd, since those who got theirs earlier this year more had issues with false diagonal inputs. But I’ll be reaching out to Analogue to see what can be done here, as this too far in the opposite direction.

Nice. I just got mine yesterday. I'm kinda glad I wound up in group B. It was a long wait, but watching the cores roll out convinced me not to cancel the order. Saves states on openFPGA cores are not great (even the cores that support them don't seem to work right?), but I'm hoping that gets sorted. The only complaint I have on the hardware itself is that the d-pad is a little too faithful to the original, so fighting games are still a bit wonky like the original DMG. That said, I guess it's time to get serious about the gaps in my GB/GBC/GBA collection. Metal Slug on the Pocket is a thing of beauty though.

There are tools for doing the updates: https://github.com/mattpannella/pocket_core_autoupdate_net (CLI, works on Win/Mac/Linux) There’s also a Windows GUI tool that I’d have to track down to find. But I think RetroRGB has some links here? (EDIT: Found it https://github.com/RetroDriven/Pocket_Updater)