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)

I have a couple Waterfield bags that I've been using for many years, with the oldest getting close to 10 years, and the newest is about 3 (needed a bigger laptop bag). In terms of quality, no complaints at all. Price is another thing though. I would lean towards the sleeves for gear specific cases.

Anker is one of the brands I look at first when looking for USB power hubs like this. But unless it's totally out of spec, I wouldn't be super concerned. With electronics, so long as the power source is the right voltage, it's the load that determines current. But if you say, hook up something expecting 5V to 12V, then it will pull too much current and can lead to damage that way. I use one of their smaller 4-5 port power hubs for my Super NT and Mega SG (and charging controllers).

Ah, yeah. That’s foam padding, not a sponge. On one hand, foam padding like that shouldn’t be conductive. However, I’ve never seen it used on top of components and contacts like this before, and would even say it generally shouldn’t be used in this manner. Last thing you want is something getting trapped by the foam and creating a conductive path for a short. EDIT: I should have read more first. FirebrandX does point out that the foam in the repair is conductive, to ground the board to the chassis. That part would make sense (if not an ideal way to do it). So why was the original site over an IC that likely took Vcc and Ground? Or is it that there was no grounding at all before?

For early systems like the NES, it’s simpler to load the whole thing into the FPGA’s memory and access it directly. So yes, the SD card shouldn’t even be a factor once things get going, since the ROM file has already been fully loaded. Emulators would do the same, and the Mister uses a larger developer FPGA board, which should have even more memory onboard. That said, NES games did have slowdown issues on real hardware, including some Nintendo titles like Kirby’s Adventure. Bubble Bobble is another notorious one which I was a fan of but find it hard to play today vs the arcade ROM. Since I spend most of my time in the SNES catalog, I don’t really remember much about if SMB3 was one of those titles with slowdown issues or not. It would definitely be worth comparing to real carts though.

It’s clear you didn’t really read the content of what I was saying, or misunderstand the points I was trying to make. The core point is that there’s nothing specific about retro gaming that is any different than other uses of a modern TV. So there’s not a whole not of additional texture someone on this forum can add that you can’t find elsewhere. About the only thing that might matter is compatibility with non-standard refresh rates when using an OSSC or something like that. Sadly, nobody really reports on that, so it’s a bit of a lottery there, and wholly depends on the controller used, and has nothing to do with OLED vs LCD. If you use an AV receiver or processor, that’s another link in the chain that can break OSSC/etc, making it even more annoying. Note that I mentioned that an LG-based OLED will have better viewing angles, hands down has better contrast, and even commented on the faster response times of the panel itself in my comments on motion clarity. And in terms of motion clarity, I think it’s a trade off (and an annoying one to make). And I even mentioned that for things that are 60fps, the OLED pulls ahead IMO. But honestly, sample and hold has been a huge step back from CRTs that we still haven’t solved, and instead apply bandaids to. As for image retention & burn-in, I intentionally used the phrase “image retention”. My set is 3-4 years old, it gets retention. I haven’t had any burn-in. But since LCD-based tech like QLED can suffer DSE (as can OLED) and have a similar effect on the picture, it’s honestly a wash. The problem with pure measurements in this case is people tend to compare based on those measurements without context, or people wind up ignoring the context of those measurements to make mountains out of ant hills. Color accuracy on average is generally good enough with a few exceptions, and calibration will tend to drag dE low enough that it makes no visible difference. Both the Samsung Q80 and the LG CX both measured at a dE of under 2 out of the box. That’s ideal. Assuming you aren’t running around in a red pushed mode or some other nonsense, that’s a great place to be in. Color gamut/volume is another issue, but so far the differences in gamut between them have generally done a good job keeping pace with each other that I wouldn’t go chasing it in a buying decision (and Rtings reports better color volume on the Samsung Q80 QLED set BTW). So yes, different displays will measure differently, but keep in mind that samples of the same model will vary here, so there’s margins of error to account for when comparing. There used to be some places that measured motion resolution, but it’s gone away in favor of the easier to measure response time as places are trying to measure more models of TV with fewer resources. It’s an important factor, but it’s not the whole picture. Much like you need to model the human ear to get a better idea of how headphones and speakers work, you need to model the human optic system to get a better idea of how different displays actually present motion to a person, rather than a camera. To be blunt, motion handling of TVs is the place where reviews are honestly terrible. One of the reasons OLED has such a “wow” factor is because of contrast. Contrast is one of the things the human eye is the best at picking up. And OLED is a clear leader there (but so was Plasma and CRT and look what happened there). So long as the processor isn’t introducing black crush (a problem LG had a while back in early OLED TVs), shadow detail cannot be beat on an OLED. That said, retro games with small palettes aren’t really impacted by that, are they. :)

Quality in terms of what? Color? Contrast? Viewing Angles? Motion? Image-Retention? But really there’s nothing between different panel technology that to me says someone should go OLED vs LCD when discussing retro gaming. Color accuracy is close enough that both are equally good (assuming we are talking about Samsung QLED/MVA panels, and LG OLED panels). Contrast and viewing angles go to OLED. MVA panels that Samsung is fond of using in TVs bloom when using zone dimming, and can still leak considerable light leading to elevated black without zone dimming. Mostly an issue in darker rooms. MVA panels also aren’t great at wide viewing angles, while OLED is more in line with IPS LCD panels. Image Retention goes to QLED or any other LCD-based tech. It doesn’t bother me since my use keeps it minor enough I only notice with single color backgrounds (similar to dirty screen effect), but it is something I’ve had to deal with using OLED. Motion depends a lot on the controller driving the panel, although the tech can affect what you can do. QLED/LCD and OLED are both sample-and-hold tech, which will mess with how your brain interprets what it sees, causing visual artifacts that way. My old Sony 1080p LCD had a feature to strobe the LED backlight at 480Hz. This was great for film and other stuff in the 24-30fps range, since it got incredibly close to the look of CRT when it came to motion clarity. LCD/QLED needs time to transition between frames, which tends to “smear” the frames and blur them. Strobing the backlight helps “reset” the brain’s visual processing between frames, much like projectors and CRTs do. OLED has no backlight, so you can’t do this strobing trick the same way. Sony recently started offering a sort of “rolling blackout” on their OLED panels at 120Hz which helps, but because of the pandemic I haven’t seen one in person yet with the feature enabled. But I’m watching this particular addition closely. With both OLED and LCD/QLED, the effects of sample and hold can be lessened by higher frame rates. So 60 FPS gaming will look fine on both sets. I’d give the edge slightly to OLED since you get a slightly crisper motion, thanks to the faster response times, but I honestly kinda prefer the “blur” of 24-30fps LCD than the “double-image” I get from 24-30fps OLED. So newer consoles that have games running at 30fps to me at least, don’t look as good in motion on OLED as they do a good LCD-based panel with a strobing backlight. But really my ranking for TVs in motion clarity tends to be: LCD w/Strobing Backlight > OLED > LCD w/o Strobing Backlight. When it comes to my next TV, it’s going to be about trying to find a “good enough” balance between contrast and motion clarity for me. It might mean going back to a full-array backlit LCD of some kind.

I guess what is your specific question? I’ve been using an OLED TV for retro consoles since before the Super NT came out.

Mappers are transparent to the cartridge bus. Even with bank switching, the game would just write to a couple specific address locations to tell the mapping chip to update what banks were accessible. So you really just need to figure out the cartridge bus and you should be in good shape. I see what you are getting at with the idea, but it has some trade offs that aren’t necessarily ones that make a lot of sense to me. Unless you are thinking of the Pocket itself as the target architecture, versus say, a game meant for a retro console running on the Pocket. That said, if we are talking about retro consoles on the Pocket, then it seems like home brew as ROM files make more sense to me. Either done via a specialized flash cart with the “adapter” embedded into it, or through direct support of the SD card (like it apparently has for GB Studio). Physical carts for games are nice collectibles, but I’d at least personally tend to prefer those be in the format of the original system so it’s compatible with original hardware.

1) Including the core into the cart itself creates more problems than it solves, IMO. The cart adapters do seem to get detected by the MegaSG to kick it into the appropriate modes, so to me it seems possible, but I’m not certain how it’s implemented. 2) Possible, but you’d need a bridge to accomplish it. One reason there’s so many pins is because you’ve got two address buses and two data buses. So your adapter needs to effectively change how data is passed along the 32-pin connector, and then present the expected buses to the cartridge. There’s a few ways to do it, but I think my naive concern would be over getting the timings right.

You are asking the wrong person to explain someone else’s design, TBH. That said, the behavior is there, on the line starting with: ”CONSTANT MAPS : arr_jmap := (” Best I can figure from a closed issue on the GitHub, and from the VHD files (it’s been nearly two decades since I last used VHDL, mind you) is that it defaults to mapper 0, unless the CRC matches one of the CRCs in this array. If it matches one of those CRCs, it uses the mapper index specified. This trick really only works if the dump is a known one. If it isn’t known, then it assumes mapper 0. Since the vast majority of Intellivision games use mapper zero, based on the spreadsheet the author references, this effectively works. Still not ideal from an engineering perspective, but “good enough” so long as you aren’t dumping your own ROMs.