FPGA Based Videogame System

[Reaperman]

On 10/23/2022 at 6:17 PM, NE146 said:

Really? That's interesting.. What games for example?

 

I guess I'm kind of similar in that whenever I fire up my MiSTer, the majority of my time playing is 5200.

 

I suppose my three big ones are Beef Drop, Pac Man Collection, and Ballblazer. I can't sit in front of the thing without playing at least two of those three.

I think 7800 got the best version of ballblazer. Though I may have to refresh myself on the port buried inside the playstation reboot. 

 

More recently, Froggie, Time Salvo, and Popeye have been amazing. I haven't tried 1942 yet, but it's the current buzz, and the videos I've seen look great.

[Atariboy]

Quite a collection of cores has been released over the past 24 hours.

 

OpenFPGA core list

 

With a possible exception or two since I haven't actually checked, it looks like the firmware fairy going under the pseudonym Spiritualized1997 has now ported every Nt Mini Noir core to the Pocket (Joining the previous port of the NES and the OpenFPGA Game Boy cores). 

 

In practice this doesn't matter thanks to the Pocket port of the excellent MiSTer SNES core, but I wonder if the Kevtris collection will wrap up with a port of the Super Nt's SNES core one of these days.

Edited November 10, 2022 by Atariboy

[Ricdeau]

Just got a shipping notice for my Pocket. I suspect other Group B orders will also start receiving shipping notices if you have not already gotten one.

[roots.genoa]

8 hours ago, Ricdeau said:

Just got a shipping notice for my Pocket. I suspect other Group B orders will also start receiving shipping notices if you have not already gotten one.

People have been getting shipping notices for a month, now, but group B is quite big actually. My number is far away so I could get mine in December tbh.

[Atariboy]

It's about time.

 

"Your Analogue Pocket preorder is now being prepared to ship."

[Kaide]

56 minutes ago, Atariboy said:

It's about time.

 

"Your Analogue Pocket preorder is now being prepared to ship."

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. 

[roots.genoa]

2 hours ago, Atariboy said:

It's about time.

 

"Your Analogue Pocket preorder is now being prepared to ship."

Same here.

[Atariboy]

Now the road to preparing my SD card to take advantage of all the cores starts. Atari 2600 in particular will be fun thanks to quite a few roms needing their file extension changed in order for the FPGA core to know what bankswitching scheme the rom needs, but maybe someone out there has already done the busywork for 2600 if I go digging deep enough. 

 

The AtariVox files are still publicly unavailable, right? I recall that being the case when the Nt Mini received a 2600 core.

[Riptide]

On 11/14/2022 at 3:10 PM, Kaide said:

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. 

I’ve had no issues with save states on the GB/GBC/GBA cores over the past few days of playing, haven’t tried GG but I think those are the only ones that support them. 

[Kaide]

38 minutes ago, Riptide said:

I’ve had no issues with save states on the GB/GBC/GBA cores over the past few days of playing, haven’t tried GG but I think those are the only ones that support them. 

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. 

 

Edited November 20, 2022 by Kaide

[Riptide]

19 minutes ago, Kaide said:

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. 

 

Yes it might be ROM based, Oracle of Ages works saves/loads save states fine on the GBC core, but I just tested Pokémon Gold and the load failed.

[Riptide]

Loading also fails using a Pokémon Gold cart

[Riptide]

2 hours ago, Kaide said:

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. 

 

 

Maybe it was disabled for those games for a reason

[Kaide]

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. 

[Riptide]

On 11/21/2022 at 2:14 AM, Kaide said:

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. 

So I just did more testing with Gold. The save state fails to load in the early menus but works fine once you actually make a character with a name. Not sure about the validity of the Reddit post I linked earlier, but maybe you were testing before too early in the game?

[+sramirez2008]

Woo Hoo! Just received my "Your Analogue Pocket preorder is now being prepared to ship." email.  My order # is 130229.

[Kaide]

On 11/22/2022 at 4:20 AM, Riptide said:

So I just did more testing with Gold. The save state fails to load in the early menus but works fine once you actually make a character with a name. Not sure about the validity of the Reddit post I linked earlier, but maybe you were testing before too early in the game?

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. 

[blzmarcel]

On 11/25/2022 at 3:51 PM, Kaide said:

Save states for the spiritualized1997 cores for the couple of ROMs I've tried don't contain the save memory, just the system state.

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.

[NE146]

I don't know but in the games I've played I typically always use the in-game saves AND save states (in the cores that support it obviously). I use the save states more often of course, but I make sure to do a regular in-game save now and then.

 

This has saved me a few times especially back when you could only have one save state on the Pocket... where I lost the save state for whatever reason (e.g. save stating another game) so loading up the saved game brought me not too far back.

 

And Pokemon may be an exception, but I've had a lot of success transferring save files using save states (e.g. from an Everdrive to an actual cart, or more useful, taking my old game saves from my regular carts to the everdrive). I haven't tried it on the OpenFPGA stuff yet though.. but maybe I'll try it now. For example I unlocked everything in GBA G&W Gallery 4 (which takes forever) and was able to put it on the Everdrive using this technique. Now I'd want to see if it will work on the Rom on the OpenFPGA GBA core. 

Edited November 28, 2022 by NE146

[Kaide]

1 hour ago, blzmarcel said:

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.

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. 

 

10 minutes ago, NE146 said:

Now I'd want to see if it will work on the Rom on the OpenFPGA GBA core. 

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?

Edited November 28, 2022 by Kaide

[NE146]

2 hours ago, Kaide said:

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?

Oh it can.. and I know because I accidentally wiped my decades-old save on Zelda: Oracle of Ages (or was it Seasons?) and replaced it with the one I had been playing on the Everdrive.   

 

Long story short I was playing through them on the GB Everdrive using save states. One day I decided to check out my original Ages/Seasons carts to see what the differences were (what animal I got back then, what rings, etc.).. then completely forgot I had done that, and later started the pocket with the original cart inserted, loaded my save-state, which worked great! But of course it wiped out the old save on the cart and replaced it with my current game. 

Edited November 28, 2022 by NE146

[Kaide]

1 hour ago, NE146 said:

Oh it can.. and I know because I accidentally wiped my decades-old save on Zelda: Oracle of Ages (or was it Seasons?) and replaced it with the one I had been playing on the Everdrive.   

 

Long story short I was playing through them on the GB Everdrive using save states. One day I decided to check out my original Ages/Seasons carts to see what the differences were (what animal I got back then, what rings, etc.).. then completely forgot I had done that, and later started the pocket with the original cart inserted, loaded my save-state, which worked great! But of course it wiped out the old save on the cart and replaced it with my current game. 

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.

[NE146]

Welp.. just tried it, and so much for that. It appears that the GB/GBC/GBA cores used when you launch from the cart slot, and the GB/GBC/GBA cores when using OpenFPGA, use separate locations for their save states/'memories'.  So one doesn't see the other's library of them, at least that I can figure out.

 

I didn't have an issue swapping saves states between original carts and ROMS launched via the Everdrives since I guess they both ran from the cart slot.  Anyway.. pretty interesting! Maybe someone else smarter than me can figure out more.

 

 

 

[Kaide]

1 hour ago, NE146 said:

Welp.. just tried it, and so much for that. It appears that the GB/GBC/GBA cores used when you launch from the cart slot, and the GB/GBC/GBA cores when using OpenFPGA, use separate locations for their save states/'memories'.  So one doesn't see the other's library of them, at least that I can figure out.

 

I didn't have an issue swapping saves states between original carts and ROMS launched via the Everdrives since I guess they both ran from the cart slot.  Anyway.. pretty interesting! Maybe someone else smarter than me can figure out more.

 

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. 

 

 

[AtariNerd]

There's apparently an Amiga 500 core.  Wonder how well that works. Some of the most common keyboard short-cuts could be mapped to b-b-buttons, but are there any solutions for computer use, such as proper key-board mapping, maybe with external dongles?

 

https://joshcampbell191.github.io/openfpga-cores-inventory/analogue-pocket.html

 

Edited December 12, 2022 by AtariNerd