An FPGA implementation of a Microbee | Hacker News Reader

An FPGA implementation of a Microbee

toptensoftware.com

44 pointsredbluething24 comments

The Microbee was my first computer, bought by my mother from the school she taught at when the school was replacing them with Apples.

I came home one day and there it was on a little desk just high enough for me to sit at, and I was so excited that we finally had a computer of our own. Mum knelt before it typing incantations on its clicky-clacky keyboard, and suddenly it began to play "When The Saints Go Marching In", and I don't need to describe the sense of wonder I felt because everybody here has had that same wonder at some point in their lives.

I asked her to tell me how she'd done it, and she just smiled and handed me the BASIC programming guide and gave me a hug, and from that moment onward I was hooked. I read that manual back to front a dozen times over, got my hands dirty poking around CP/M, and wrote hundreds of little games and tools and silly programs in the years that I owned my little 'bee.

I'm not exaggerating when I say that the Microbee (and my mum's ability to engage my sense of wonder) literally decided the course my life would take.

Thanks, Microbee, and I love you, mum.

Nice. For me it was my grandfather. I clearly remember taking the train trip with him over to Waitara to pick up our Microbee.

Soft cores, processors (gpu/cpu/etc) that you put onto an FPGA, are quite an interesting beast. The way it is now is that you can flash whatever physical hardware that can fit - if you had access to Intel Pentium 1 source code, you could theoretically flash on, and it would work.

This is kind of off-topic, but what's more interesting to me, conceptually, is the potential for real-time re-flashing. For example, you've got space for 10 CPU cores and 10 GPU cores. When, say, running a web server, you can erase the GPU cores, and use 20 CPU cores instead. When running a game, you could drop down to 5 CPU cores and 15 GPU cores. Or, when doing single-threaded apps, you could opt for a beefy single or dual core.

Also, you could have CPUs that re-wire themselves as part of their workflow. Or, if, for example, a new CPU design comes out - you could upgrade to it without buying new silicon. Hybrid FPGA approaches even exist today - some high-end FPGAs actually come with a hard-wired CPU inside them.

The FPGA Microbee project is only scratching the surface of "FPGA=cool" factor, I think.

While I await the days that doing that is possible, my understanding is that FPGAs have a limited number of flashings that are possible. Similar to how Flash-ram has a limit on the write cycles.

I personally would love to have one for doing just this kind of thing for dealing with old software. Think of running old MAC OS stuff on one of these, or even like he's doing right now with the microbee. If done correctly it'd be hardware "accelerated" virtualization of some of the really old hardware.

Most FPGAs store their configuration in SRAM so they don't have any limitations in the number of programmings.

There also exists flash based FPGAs which have the normal flash wearout problem. One time programmable FPGAs also exist but I don't think they are interesting in this application :-)

Awesome I wasn't aware that that was the case these days. Really makes me wish I had something to play with to try to design a "standard" communications layer for handling emulated cpus.

Interesting idea! Though as I understand it, the limiting factor atm would be that FPGA cores are considerably slower than real silicon. So even if you had a huge FPGA, loading an identical circuit to a modern processor would not be anywhere near as fast.

This is true, the flexibility you get form being able to reconfigure things does result in less efficiency (speed, size, power) than some dedicated hardware. An FPGA can be more efficient than general processor if it can be tailored to the specific computational task, but it will still be slower than if you made an IC with the specially tailored hardware.

This is true, and as far as I see - this is an inherent limitation. Dedicated, static ASICs will always be faster or more efficient. However - I think there's some interesting work to be done in hybrid approaches. For example, besides FPGA cells, you can include fast on-board cache, arithmetic units, etc. So, this way, if you're switching between GPU and CPU cores, a subset of that can be reused.

For reference, a typical FPGA cell includes a 1-bit flip-flop and an LUT (look-up table). Flip-flops are memory, LUTs simulate the logic.

The biggest problem with FPGA dynamic reconfiguration of today is that it is slow and not fine grained.

The vendors haven't really seen this as an area which their customers are interested in. Maybe this has been changing in the recent years with the military's interest in software defined radio, but they probably don't need very rapid reconfigurations so maybe not ..

That's actually why I brought that up. I'm quite interested in ideas that have never been done before. (Hardware examples are non-typical FPGA use, modern trinary processors, using PID-like "overdrive" to speed up digital transistor switching)

IIRC state-of-the-art reconfiguration times can get below 10ms when using partial reconfiguration.

In the field of sotfware-defined radio, the USRP hardware from the GNU Radio project has an onboard FPGA. It's a great project, lets you deploy most radio stacks with only a few clicks: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio....

Good stuff! Reimplementing old hardware on an FPGA is a really fun and enlightening exercise that I would highly recommend to any CS people with some extra time and patience. I've been working on an FPGA based GameBoy implementation in my spare time (with no prior FPGA experience) and it's been a blast.

https://github.com/trun/fpgaboy

I couldn't agree more.

As a software developer I've always had a vague understanding of how computer hardware works, but after building fpgabee I have much deeper understanding. eg 1: I always knew what a VGA controller did, but had know idea how. Now that I've actually built one (albeit in code) it's pretty clear to me now. eg 2: I never really understood why hardware can't be just clocked to higher and higher frequencies... but now I totally get it.

How did you teach yourself?

Read -> Experiment -> Fail.

Repeat until Read -> Experiment -> Success.

They say experience is what you get when the unexpected happens... so I guess it's the Fail step that's important.

* I never really understood why hardware can't be just clocked to higher and higher frequencies*

Can you provide more detail on this?

For anyone feel nostalgic about Microbee, check out:

1. The brand new Microbee Premium Plus Kit (sold out but very cool) http://www.microbeetechnology.com.au/premiumpluskit.htm and 2. The Microbee Software Preservation Project (MSPP) http://www.microbee-mspp.org.au/

Is the source code available for download somewhere?

(20 years ago or so, the computer lab in the Swedish jr high school I was attending was filled with Microbees for some odd reason. The memories...)

Not at the moment, I want to finish off/clean up a few things first. Yes, there was a Swedish version of the Microbee and they were popular with schools here in Australia so I'm not surprised to hear you had them in Swedish schools too.

This just gave me a big blast of nostalgia. Great work! Does it also support colour?

Not at the moment, but I'll probably add it at some point.

Awesome work, I wrote my first ever program in Microbee basic, in 1985.

Thanks!

Reply on news.ycombinator.com