Still fresh, damnit!

Interesting, but I need to see more about it first of all. If it can only play gameboy carts without any docks (which haven't even been priced yet) I can't see the need for such a high resolution screen. Even if it can play Lynx or Neo Geo games with an adapter, neither of those need such a high resolution. But if it's designed to develop FPGA layouts on (or whatever the right term is) then maybe it could be useful for that.

DNF (Did Not Finish)

Well, seems GB/GBC/GBA carts out of the box, and it also lists microSD, so I'm guessing you're not restricted to physical carts. If somebody ports NeoGeo Pocket Colour, I'll especially be interested.
I like the fact they seem fairly open about letting people develop FPGA cores for it too, so the high resolution etc. could be put to use in other ways.

That all said, I'm assuming the Pyra will emulate NeoGeo Pocket Colour fine, as the Pandora can; I already have a Retroflag GPi and Odroid Go (though the GPi has issues, and Go can't emulate NGPC); and I've already two FPGA devices I've never really managed to make something out of...

I do like the look of it though

Edit: I must admit, this sort of thing makes me chuckle though. I remember ages ago FPGA was talked about as a potential CPU replacement board for the Pyra, but was dismissed. I suppose tech has changed a fair bit in those couple of years. So maybe a viable option in the future.

Still fresh, damnit!

Yes, although that's a matter of development I expect. It's described as having at least two FPGAs in it and presumably some kind of basic CPU to bring the system up from cold. Coding up a SD card reader and rom loader on FPGA silicon is a completely different thing to coding on linux, and a magnitude more difficult most likely. If the code that runs on the CPU is left open though, you could probably code it on that but I'm not sure they haven't made it basically an embedded binary blob; the kind of thing that runs on your white goods.

DNF (Did Not Finish)

My guess, with the dual FPGA, is that there'll be a primary FPGA, which has the core firmware for gaming, cart, screen, input etc. and will be able to load other cores from the SD to the second FPGA; so you can't really brick the system on a non-official core.

Forum Addict!

Yes, although that's a matter of development I expect. It's described as having at least two FPGAs in it and presumably some kind of basic CPU to bring the system up from cold. Coding up a SD card reader and rom loader on FPGA silicon is a completely different thing to coding on linux, and a magnitude more difficult most likely. If the code that runs on the CPU is left open though, you could probably code it on that but I'm not sure they haven't made it basically an embedded binary blob; the kind of thing that runs on your white goods.

You might be onto something there. The easy way to do this would be to have the basic CPU manage all of the hardware then have easy to use handles for interaction with the FPGAs. Similar to how a computer with a GPU compute cluster just passes to the GPU what it's good at, this could pass the 'program' to the FPGA for execution, then act as a hypervisor to pass control inputs to the FPGA and interpret/apply display outputs.

If so, then this basic CPU is probably a low end SoC with a small amount of eMMC - and could likely be booted somehow for updates...

DNF (Did Not Finish)

In addition, wiring up an SD card reader in FPGA is simpl, but don't think about the fpga accessing like Linux.

The most likely way this'll work is that whichever CPU they choose from the firmware and give that access to the SD pins, and they'll effectively write an sd card driver for that CPU, i guess like everdrive cartd

Hardcore Member

In addition, wiring up an SD card reader in FPGA is simpl, but don't think about the fpga accessing like Linux.

The most likely way this'll work is that whichever CPU they choose from the firmware and give that access to the SD pins, and they'll effectively write an sd card driver for that CPU, i guess like everdrive cartd

If it can read an FGPA spec from an SD card and flash it to the chip, you're describing something that's almost certainly implemented in some kind of CPU. The contstraints on that being user hackable to run any kind of user software on are more or less the same, although the CPU inside an FPGA is almost certainly locked down without the end manufacturer needing to do it.

Edit: Seems we're on the same page, judging by later posts. My fault for shooting from the hip I guess.

DNF (Did Not Finish)

If it can read an FGPA spec from an SD card and flash it to the chip, you're describing something that's almost certainly implemented in some kind of CPU. The contstraints on that being user hackable to run any kind of user software on are more or less the same, although the CPU inside an FPGA is almost certainly locked down without the end manufacturer needing to do it.

Edit: Seems we're on the same page, judging by later posts. My fault for shooting from the hip I guess.

Not sure I'm following you, sorry? Are you saying their FPGA hardware layout fully knows what SD card blocks to read? To me it'd seem more likely that they'd be accessing the SD card through some sort of software, by utilising some sort of embedded processor design.

Hardcore Member

Not sure I'm following you, sorry? Are you saying their FPGA hardware layout fully knows what SD card blocks to read? To me it'd seem more likely that they'd be accessing the SD card through some sort of software, by utilising some sort of embedded processor design.

DNF (Did Not Finish)

No, @levi and @Grench were talking about there being some sort of SoC in there to read the SD card. I was trying to explain (badly), that FPGA's can autoconfigure from firmware on a flash device (without the need of an external flashing unit, beit a SoC or CPU), and then that firmware will contain some CPU core and software, with an SD card driver, in order to access and read from the SD card.