Analogue Pocket FPGA Gameboy/Color/Advance announced

[FelixNemis]

Analogue is making a FPGA handheld! I'm pretty excited for this thing

Analogue Pocket

A tribute to portable gaming.

www.analogue.co

This is looking like exactly what I want from a gameboy clone
Well I like the original gba form factor more but this is good too

It has a high resolution screen for nice scaling of the various other handhelds it can support with adapters too
There's an optional dock for hdmi output
I just hope the battery life is good

It's going to be $200 (without the dock) which I'm absolutely ready to shell out unless it doesn't live up to their reputation for quality

 

[levi]

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.

 

[pmprog]

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.

 

[FelixNemis]

It does mention it doesn't support ROMs (with the default firmware since you could no doubt make it work with ROMs off the sdcard)

 

[pmprog]

Fair point... In fact, that page even has this quote

1Analogue Pocket does not play rom files, it plays legacy game cartridges via the cartridge slot

 

[levi]

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.

 

[pmprog]

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.

 

[fusion_power]

Neat design, I like the clean, modern look.

Fair point... In fact, that page even has this quote

But why should I spent 200 bucks then?

 

[Grench]

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...

Just my theory in how to make this 'easier'.

 

[pmprog]

I doubt it'll have any low end CPU/soc. Most FPGA chips can auto configure from an onboard flash device. My NexysDDR certainly can, and the TurboChameleon had only fpga chips

 

[pmprog]

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

 

[pmprog]

But why should I spent 200 bucks then?

Seems quite the sentiment on EtaPrime's YouTube post. I'm kind of in agreement too. Though it's tempting from the handheld fpga point of view alone

 

[Linux-SWAT]

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

They have a "SD" block that they can insert in any design they do.
A Vivado (one of the Xilinx IDE) block diagram looks like this:

 

[pmprog]

Aye, probably very similar to this one:

fpga4fun.com - SD card 1 - FPGA connection

But they'll need something to drive the protocol, and that'll probably run on some sort of CPU within their FPGA design

Sorry for my mashy posts, I was on my mobile and doing other things at the same time

 

[levi]

I doubt it'll have any low end CPU/soc. Most FPGA chips can auto configure from an onboard flash device. My NexysDDR certainly can, and the TurboChameleon had only fpga chips

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.

 

[Linux-SWAT]

But they'll need something to drive the protocol, and that'll probably run on some sort of CPU within their FPGA design

It's called a controller.

 

[pmprog]

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.

Yes, probably just my bad typing. Like I said, I was trying to do multiple things at the same time, so it probably was only half-english

It's called a controller.

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.

 

[Linux-SWAT]

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.

Maybe it's I who didn't get your question...
Are you asking how the device can read SD cards ?

 

[pmprog]

Maybe it's I who didn't get your question...
Are you asking how the device can read SD cards ?

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.

 

[Linux-SWAT]

You are right.