Back to the Future...

What a surprise it was when, upon returning from a few days of vacation, I found signs in front of every newsstand displaying the year 1976 in large print. All over the city where I live—1976, everywhere!

It was a call for testimonies about THE 1976 heatwave :

Indeed, at the age I was back then, I was a good five years too young to realize that the major event wasn’t that fleeting wave of high temperatures, but the tsunami that had just begun in the U.S. with the release of the Apple II.

So, out of curiosity, I stepped into one of those newsstands and absentmindedly glanced at the electronics section—which, by the way, hasn’t existed for years now—and the computer section, still as dull as ever, rehashing the same stories for over two decades. I was about to leave the shop, as disheartened as usual, when my eye caught a rather unusual cover: Retro Bit!

So?

Well, I immediately remembered that I’d been interested in this Italian publication and had tried to order the first issue. But when I saw the exorbitant shipping costs, I gave up. The magazine itself is still very expensive—too expensive for what it offers, really. But does a dream have a price?

Reading this issue of RetroBit (number 6, currently) is enjoyable and effectively immerses the reader in the era it covers—though with some digressions about today’s happenings.

Despite the magazine being written in French, it’s clearly a translation, likely done by AI, as some phrases are downright absurd. But hey, that’s part of its charm…

I remember with deep sadness the early ’90s, when the microcomputing magazines I’d discovered and read for nearly a decade began gradually disappearing.

So it’s with great pleasure that I discovered this new magazine on newsstands. Because let’s face it, things have been heating up lately in the world of retro computing. I already mentioned Commodore’s ‘rebirth’ in my previous post, but we should also highlight the incredible success of the Kickstarter campaign for the ZX Spectrum Next Issue 3!

 And the new version of the Commodore 64 : 

 

Will there be a new 8-bit war?

That would be a grave mistake. Everyone knows what would happen to this budding 'true' revival of the 8-bit micro era.

As my industrial computing professor told me back in 1993: 'You're an 80s guy at heart.' I arrived too late to fully enjoy that golden age - and I certainly don't intend to miss out on the new one coming!

Other sugject :  

I’ve decided to dust off my old FPGA card to experiment with video interface design. As mentioned in a previous post, I developed a small add-on board providing a few megabytes of static RAM. I’d attempted similar projects before but never achieved the desired results. This time, I redesigned the board with more modern components.

Admittedly, I won’t reach blazing speeds due to signal path length, parasitic capacitance, and other inherent challenges—but it should still handle basic 1024×768 resolution just fine.
 

 

Commodore is....

 REBORN!!!

Christian ‘Peri Fractic’ Simpson is the new CEO

08/01/2025
 

 
Back to basics...

Over a decade ago, I invested time in learning FPGAs. At the time, I thought it was a good idea—and I was probably right. Back then, microcontrollers didn’t have the performance they do today, and replacing all or part of legacy hardware could really only be done this way.

I had bought an Altera DE2-70 development board. FPGAs were all the rage, and although prices had become affordable, they started rising again. Even that wasn’t enough for Altera to survive on its own, as it was acquired by Intel a few years ago. Now, Intel itself isn’t in great shape either. The swan song of American tech?
I considered using FPGAs until 2019...

when I discovered GoWin FPGAs, which were much more affordable than Intel's. But then came 2020 and COVID—and boom, GoWin FPGA prices skyrocketed as well. Once again, I was stuck.

Then came Efinix chips. However, while I found GoWin’s development software somewhat clunky, Efinix’s tools are, in my opinion, a complete disaster—unintuitive, slow, and prone to crashing. Whether it's GoWin’s IDE or Efinix’s, neither is a good tool for development. But then again, that’s just my opinion, and I’m not a professional in the field.

My Big Mistake:

Whether using GoWin or Efinix software, I stubbornly tried to develop entirely within their ecosystems. And, true to my habit of persisting in error, I spent months wrestling with these tools. While I managed to get decent results with GoWin’s IDE—though with far more effort than I’d have liked—my attempts with Efinix’s IDE ended in outright failure.

My approach was simply foolish, and here’s why. The learning curve and overall usability of Quartus (Altera/Intel’s development software) had been, by far, the smoothest for me. I’d built solid experience with it and gained a strong command of VHDL. And here’s the kicker: VHDL works flawlessly with both GoWin and Efinix FPGAs. See where I’m going with this?

Yep—the much less stupid strategy would have been to develop on Altera’s platform first, validate the project there, and then port it to GoWin or Efinix. At worst, I’d only have needed minor adjustments for the target platform’s IP blocks.

Better Late Than Never

That’s exactly what I’ve decided to do: go back to an "easy" development environment to build my projects, then port them to my final platform of choice.

Luckily, Intel still provides the necessary software for the DE2-70 board—version 13SP1—so I’ve reinstalled it on my PC. And compared to my decade-old machine, my current computer should compile much faster, making this "old" board even more practical to use.

Tackling Video Signal Generation Again

This time, I’m revisiting video signal generation. While the DE2-70 has multiple types of RAM, it unfortunately lacks SRAM. And since I want my FPGA projects to be as portable as possible, I need to avoid platform-specific IP blocks—especially those handling dynamic RAM (DRAM).

Luck Is on My Side

Because over the past ten years, static RAM (SRAM) has improved significantly in capacity, price, and access time, interfacing SRAM with an FPGA is straightforward—aside from the high number of electrical connections, but that’s manageable.

Since I only need a modest video interface (limited pixel depth and color range), I can now get by with just a few SRAM chips while still achieving good resolution and enough colors.

And here's the small expansion board I plan to build to provide the DE2-70 with enough SRAM for video interface purposes. I've attempted similar expansions before, but the results weren't satisfactory in terms of access time. I believe I now understand why - this time, I'm taking a different approach. 

Here's what the physical implementation should look like:

The GPIO connectors obviously won't be implemented on this side since the board needs to be plugged into the DE2-70's connectors. I've also added a small connector to enable SRAM loading from an external processor board - I remember not including this feature last time and struggling immensely when trying to use a Z80 processor embedded in the FPGA itself.

That approach made real-time debugging impossible, preventing me from running code step-by-step to verify the VHDL video interface behavior. Essentially, I had two potentially buggy systems in the same FPGA code - how could I possibly determine which one was causing issues? This time, I'm not repeating that mistake.