FPGA Mac

[pcamen]

I came across this really interesting article recently:

https://www.thanassis.space/myowncpu.html

Here is the Hacker News discussion:

https://news.ycombinator.com/item?id=21303446

In short, there is a board that was developed in the earlier part of this decade for some failed business model, that has (very) large FPGA on it, as well as a bunch of peripherals.  They are plentiful (for now) on eBay for cheap. 

This guy took an open source SPARC on FPGA design and programmed a Sparc CPU in the FPGA.  He even found it relatively easy to add multiple cores.  There was also a comment I believe in the Hacker news discussion about someone doing the same thing for a CP/M machine.

I've always thought the ultimate way to carry on the vintage Apple legacy would be to develop completely new (and thus more reliable) hardware to run the various macOS versions.  Seems like programming the 68k CPU (and perhaps some of rest of the Mac bits) in the FPGA would be a really interesting way to accomplish this.  

If anyone had the chops to pull this off with a system like this, it would be awesome!

 

[Trash80toHP_Mini]

Looked interesting, especially the discussion, but now my brain hurts. :blink:

 

[Toni_]

It would be interesting to see this idea someday implemented by someone. A couple years ago I was reading about a project for creating a full Amiga similar way on FPGA, including a 68K which was also used in Macs. I think the project I was reading about was https://en.wikipedia.org/wiki/Minimig

There was also a project to create a full 68K cpu using FPGA: https://blog.adafruit.com/2018/12/10/fx68k-an-open-source-68000-cycle-accurate-fpga-core-vintagecomputing-fpga-gaming/

One challenge with Macs are the ROMs, which are (to my knowledge) tightly tied to the certain hardware configurations they were originally used in, and on other hand, the Mac System software has a lot of overrides & hacks to specific ROMs. Using certain existing ROMs would limit the hardware "simulated" in FPGA to certain specific configuration, but on other hand creating a custom ROM specifically for the FPGA Mac clone might require a new System 7-type Enabler to be written for it. But that would definitely be interesting approach.

 

[mattsoft]

While it's not a super capable Mac, the MiSTer (FPGA console) project does have a Mac Plus core available: https://github.com/MiSTer-devel/MacPlus_MiSTer

I've played around with it and it works OK. It needs someone who (a) knows VHDL and (b) loves the Mac to continue work on it.

 

[Gorgonops]

One challenge with Macs are the ROMs, which are (to my knowledge) tightly tied to the certain hardware configurations they were originally used in, and on other hand, the Mac System software has a lot of overrides & hacks to specific ROMs.

Actually this is about the easiest problem. The Mac ROM does a really amazing job (for the most part) abstracting the underlying hardware, to the point that most mainstream classic MacOS emulators *don't* strictly emulate any particular real Mac, they hack the loaded ROM image to reference simplified synthetic representations of things like disk devices, frame buffers, etc. (BasiliskII and Sheepshaver are the poster children of this approach.) Taking this approach would be the most *efficient* way to utilize an FPGA to emulate some kind of generic enhanced 68k Macintosh with the best possible speed. Downside of it is the resulting machine isn't going to be strictly compatible with any *particular* real Macintosh, and will definitely fail to run software for Macs that *does* directly drive the hardware. (Alternate OSes like A/UX is a biggie.)

Anyway, sure, that Pano Logic G2 board seems to be a really cheap way to lay hands on a great big Spartan6 FPGA that already has some RAM and UI ports soldered onto it. Digging through the articles the downside seems to be that no one has actually yet fully figured out how to use those pieces. Once they're figured out and the boards become a well-understood target for development... they're probably going to become less of a bargain, ironically enough.

But indeed, sure, why not, I'm sure you could probably make a fairly freakily-fast "psuedo-mac" out of one of these things, particularly if you weren't too concerned about absolute best compatibility. The CPU core used by the "Vampire" series of accelerators for Amigas substantially outruns any real 68k CPU (through the 68060, anyway) and fits in substantially smaller FPGAs. If you do the "rom-hacking" approach you don't need a whole lot more than a block of RAM, a dumb framebuffer, some kind of storage, and UI interfaces to turn a working CPU core into a "Mac".

 

[trag]

I would be hesitant to try to develop on a discontinued FPGA.  Is the Spartan 6 still in production?    The reason being that tool support disappears.   Reading about the gymnastics the blogger went through to get the tools working sounds like a pain.  On the other hand, much of that effort could probably have been avoided, if he weren't committed to avoiding running Windows.

It can be hard enough to get the development environment working for supported FPGAs.   Obsolete ones may be a bargain, but they can make development problematical.

On the other hand, I'm more of a hardware guy than a software guy, so all that Unix'y manipulation he did doesn't come naturally to me.

Anyone know if the Pano Logic G2 has available I/O pins on that Spartan 6 that aren't being used?   If one wanted to add things like serial ports, ADB ports, floppy port, or SCSI, there's no way to do that on that system short of USB adapters, unless there are unused I/O pins on the FPGA that can be accessed.

I'm surprised someone hasn't sussed out the connections to auxiliary chips.   Should just be a matter of killing a board by removing the chips and then tracing the pin connections, unless the auxiliary chips are not marked and are unidentifiable.

 

[Gorgonops]

Is the Spartan 6 still in production?

Yep. It's a "legacy" product but the company's website promises they're going to keep making it until at least 2027. The toolchain issues the guy was moaning about were basically entirely self-inflicted.

(I mean, yes, I get it, it's pretty absurd that you can have a "free thing" that only runs on a non-free OS despite the deeply ironic fact that it's actually in a VM wrapper containing a free OS, with mickey-mouse copy protection/DRM locking it up for seemingly stupid reasons... but that's how hardware vendors roll, sorry.)

Given that the Spartan six is a bigbigfat BGA package if it *does* have unusued I/O it's a fair guess that they're lost to you on the Pano board unless it brings them out to hidden solder points. It doesn't appear looking at a picture of the board that it has any kind of GPIO header on it so, yeah, implementing legacy connectors probably isn't going to happen.

I'm surprised someone hasn't sussed out the connections to auxiliary chips.   Should just be a matter of killing a board by removing the chips and then tracing the pin connections, unless the auxiliary chips are not marked and are unidentifiable.

Here's a Github specifically dedicated to documenting the reverse engineering of the board:

https://github.com/tomverbeure/panologic-g2

It looks at least like they've got the basics laid out, but there are holes in what they know about driving some of the chips. They also don't appear to have the source code for any of what Pano did with it, so they're stuck with reverse engineering their own FPGA code for things like the DDR and USB controllers (it has a chip that has the USB PHYs in it, but the controller itself was implemented in the FPGA). In *theory* they can modify stuff off the shelf to do it, but since it's not a well documented reference platform it's understandable that it's taking them some time to sort it out.

I guess the question is if there really are enough of these things in circulation to make it worth coming up with the needful to turn them into little Amigas or whatever.

 

[trag]

, so they're stuck with reverse engineering their own FPGA code for things like the DDR and USB controllers (it has a chip that has the USB PHYs in it, but the controller itself was implemented in the FPGA). In *theory* they can modify stuff off the shelf to do it, but since it's not a well documented reference platform it's understandable that it's taking them some time to sort it out.

They may have pulled it, but Xilinx used to have a configurable DDR2 controller cell included with their free stuff, IIRC.   There definitely was such IP, my only hesitation is regarding the memory that it was available in the free distribution.   It's been years since I looked at it.  

Their new line of "budget" chips have dedicated DDR2 controllers built-in which are limited to 16 bit width and there are pre-written cells for those available.   I don't know if they pulled the old configurable IP when they added the dedicated stuff.

The nice thing about the configurable version was you could set it up for anything from a single X4 DDR2 chip up to a 64 bit wide DIMM.

Anyway, it would take a little HDL to add in such an auto-generated cell, but if you're already laying out a ocmputer of some type, adding an auto-generated DDR2 controller should be trivial.

I guess I should take a look at the documentation you linked and see what's going on.  But commenting from this armchair is so much more comfortable. 

I appreciate the info in your other comments.  

 

[Gorgonops]

They may have pulled it, but Xilinx used to have a configurable DDR2 controller cell included with their free stuff, IIRC.   There definitely was such IP, my only hesitation is regarding the memory that it was available in the free distribution.   It's been years since I looked at it. 

I remember seeing a comment in that thread of doom in the OP where the claim was thrown out that Pano hadn't implemented their interface to the DDR2 chips in the "standard way" and that was somehow making it hard, but I have *no idea* what the qualifications behind that claim were. (Frankly the actual implementation details for something like this are way above my head, I'm *just now* building up to thinking about buying a GAL programmer.) I'm sure they'd appreciate it if you could point out that they're boneheads and it's JUST THAT EASY!

 

[mattsoft]

If anyone is seriously interested in developing an FPGA Mac, I would recommend the MiSTer project which uses a pretty cheap ($110) off-the-shelf Terasic DE-10 nano that has a Cyclone V FPGA and dual core ARM with shared SDRAM and plenty of GPIO. The MiSTer community provides additional SRAM modules, RTC clock, and other expansions (similar to the RPi) for the DE-10, and a general framework for implementing a computer core with some of the lifting done like including an HDMI scaler and device/controller binding. The project already has several well-baked cores including Commodore 64, Amiga, Atari 8-bit, NES, SNES, Apple II, Genesis, TG-16, Neo Geo, etc...

 

[techknight]

It's been done in a way. Steve chamberlain started it as a proof of concept with Emulating a macintosh plus on an FPGA. 

Might want to check out that project. 

 

[pcamen]

https://www.bigmessowires.com/plus-too/

 

[trag]

I remember seeing a comment in that thread of doom in the OP where the claim was thrown out that Pano hadn't implemented their interface to the DDR2 chips in the "standard way" and that was somehow making it hard, but I have *no idea* what the qualifications behind that claim were. (Frankly the actual implementation details for something like this are way above my head, I'm *just now* building up to thinking about buying a GAL programmer.) I'm sure they'd appreciate it if you could point out that they're boneheads and it's JUST THAT EASY!

I started looking at some of the old documentation I collected back when and at the Pano Github page you referenced for the reverse engineering work..  I was looking at Spartan 3 family back when.   More recently I took a brief look at what I think they're replacing Spartan 3 with, as hte affordable less powerful but still pretty powerful line.

Anyway, it's a rabbit hole.     I'm not going in there.

I did find that the Memory Interface Generator is the Xilinx tool to use.   One gives it parameters and it generates the required memory controller, at least, according to "InterfacingXilinxFPGAwithMicronDDR.pdf".   Not sure where I downloaded it.

Also, that may be for FPGAs without a built-in dedicated hardware.   It sounds like the Spartan 6 has four dedicated DDR2 controllers built in and two of them are used by the Pano.    IIRC, some chips only pin out two of them.

So, the MIG might be the thing to use.  But with the on-chip dedicated controller, it might not.

I guess when I wrote my earlier post, I was thinking in terms of someone who programmed a custom DDR2 interface at the assembly language level for 8 years and debugged it on new development boards.   I was just kind of assuming the folks working on the Pano would have someone with that level of experience.  Then you mentioned that you were just starting to look at it, and that put things in perspective.

It's not trivial to get DDR2 working.  I shouldn't have called it that.   The interface from the DDR2 controller cell to whatever larger computer they're building should be relatively trivial (compared to designing a computer) but even when one has a pre-built IP package for the controller, there can still be a dizzying array of timing parameters and such to configure in registers to actually make the interface work in practice.

One of the programs I wrote for our custom chip walked through the settings for the timing parameters to the DDR2 chips and tested where they worked and where they didn't to find the "window" of parameters where the DDR2 actually functioned.   Then it reported back the parameters for the center of the window and set the internal registers to those center values.

Some IP has that initialization routine  included in the hardware.   Most that I've seen don't and expect the end user to have some kind of initialization on boot routine to find the data eye.   In practice, once you've found it for a particular piece of hardware, it seems to stay put.    So one could probably get away with just finding the working timing parameters once.

But all that said:

If the FPGA is wired to the DDR2 chip properly, it should be relatively easy for someone familiar with DDR2 to get it working.  The controller doesn't even need to be instantiated, because it's built into the FPGA as an immutable cell.

Ah, read a bit of the "Hacker News" link from the OP and someone did get the DDR working with about 9 hours of work, they reported.

Dug in a little deeper.    Most of the quantity on Ebay seems to be the G1 with Spartan 3 rather than the G2 with Spartan 6.   Spartan 6 on Digikey, if it was available would be $30 - $60.   They have one model available right now for $85.    I didn't check any other sources.

I've been wrestling with the age old question, "Should I stock  up because I might want some, someday."   Which, for me, is a foolish bet.  I should just say no.   

The FPGA on those systems is nice, but it's not a $400 Virtex.   It's a $50 - $100 (tops) Spartan.   It does have the advantage  of already being soldered to a board and including a DDR2 chip and video output chip.    But it's not such a wondrous deal that I can't pass it up.

 

[trag]

Having thought it over last night, I think the Pano is a good option if you want a Spartan 6 (G2) or Spartan 3 (G1) development board.   Much cheaper than paying Xilinx or a third party the hundreds of dollars a development board costs.  Also, much less well documented, though.

I doubt development could be done fast enough to make basing a new product on surplus Panos a good idea.

Anyone looking for one, note that there's a G2 model and a G1 model, but Rev. C of both models.  The G2 has a Spartan 6.  Externally (according to the documentation linked to here) it has a DVI connector.   The G1 has a Spartan 3.   Externally, it has a VGA connector.

The Spartan 6, in addition to being a larger FPGA, has built-in DDR2 controllers.   The Spartan 3 does not have built-in DDR2 controllers.   They must be instantiated out of available logic (thus shrinking available FPGA space) using the MIG tool from Xilinx (or roll your own, heh).

Looking at Ebay,  most of the largish lots right now seem to be made of G1s.

 

[Gorgonops]

If I'm reading the specs correctly it looks like even the G1 has an FPGA larger than the original MiniMig or the MiST platforms, so if someone were to get a bug in their bonnet to post an Amiga or ST core to them you could *potentially* come up with some kind of business plan based around buying in bulk and turning them into little retro game consoles. But the lack of open I/O really is the bummer; you're basically stuck with USB unless you want to start cutting traces on the board.

 

[trag]

I must not looked at specific models of Spartan 6 in my post a while back.   The LX100 or LX150 cost between $120 and $200 at Digikey, just for the chip.  I had to be looking at the smaller versions when I saw prices between $30 and $80.

 

[trag]

Was looking at Pano Logics on Ebay again this week.  Seem to be in the mood to spend money on things I won't get around to using, ever.

One seller has lots of ten of the Rev. C G2, the Spartan 6 LX100 for $89 with free shipping.   It's on sale for another day or to from the regular price of $180.

https://www.ebay.com/itm/184116926527

Another seller has lots of ten of the Rev. B G2, the Spartan 6 LX150 (more logic) for $180 with free shipping.

https://www.ebay.com/itm/223963831002

While the LX100 and LX150 each have four DDR2 controllers on board, according to Xilinx's documentation, the 484 pin package used on these only connects two of the DDR2 controllers to pins.  In other words, there are four controllers on the silicon wafer, but the little bumps on the wafer fro two of the controllers don't go out to balls on the BGA package.

Disclaimer:  I'm basing my identification on information/photos from the internet and such.   I could be wrong about which specific models they're selling.  Pretty sure I'm right, at least if their product matches their photos, but no way to be certain.