QL Tetroid Super Gold Card Clone

First I bought the Tetroid Disk Interface when I should have had the Gold Card. Then I ordered the Gold Card and very soon noted that a Super Gold Card clone also existed. Sigh.

Well, after some waiting I now I finally have the ultimate (?) QL add-on, The Super Gold Card.

Back: The Super Gold Card. Front: The Gold Card

The Super Gold Card has a 68020 and 4 megabytes of memory. The board is somewhat physically larger than the Gold Card. Still, it is smaller than a 1980s version. Again, take care not to grab the computer from the card when carrying!

Looking at the card, it seems Tetroid has got rid of that old Gold Card INGOT chip. If a replacement has been found this promises there could be a supply of these cards as long as there are people to buy them.

Plugged in

This card is sometimes said to be 3 times faster than the Gold Card, which I felt was about 4 times faster than an unexpanded QL. In crude math the SGC would then be 12 times faster than a standard QL. Let's see...

Fiddling with SuperBASIC, the thought came to my mind: Is this really that much faster than the normal Gold Card? 

The experiential, qualitative leap from Gold to Super is not as huge as from the ordinary QL to the Gold Card was. Adding this new speed boost does not give the same feeling as when accelerating the QL the first time.

Having said that, it is clear that when booting up to my environment that copies the QED editor, assembler and source to RAM from the SD card, I can sense the improvement is substantial. Compiling time with QMAC assembler also appeared faster.

So, I did some stopwatch tests on a few BASIC line drawing loops and assembler compiling. I ran the same programs without a card, with GC and the SGC. All the time the QL-SD card reader is present and supplies the Minerva ROM.

A BASIC line drawing program that takes 30 seconds in the non-accelerated QL, took 8.25 seconds with the Gold Card. With Super Gold Card, this was reduced to ~4.5 seconds.

The assembler compilation+linking task that previously took about 5 seconds on GC was now 3 seconds on SGC. I couldn't test the compiling on the unexpanded QL in a comparable way. I guess I could use the Tetroid Disk Interface to get enough memory for that.

These times are not super-accurate, but I'd say in everyday practice the card might be closer to being twice as fast than the Gold Card rather than three. Compared to an unaccelerated QL it's 8 times fast. Possibly the 3x or faster speeds can be achieved in only certain contexts.

Below I have a comparison table between Tetroid Disk Interface, Gold Card clone, Super Gold Card Clone and the QL-SD.

                      TDI      GC       SGC       QL-SD
Card Reader:          YES(CF)  NO       NO        YES(SD)
68000/Acceleration:   NO       YES      020       NO
Memory:               800K     2MB      4MB       NO *)
Disk interface:       YES      YES      YES       NO
Battery-backed clock: NO       YES      YES       NO
Toolkit 2:            YES      YES      YES       NO
Minerva ROM:          NO       NO       NO        YES

*) The file allocation table requires memory

Bare Metal Revolution (?)

Some years ago I asked myself, "surely someone must have written emulators directly for Raspberry Pi hardware?". At that time there were a couple of promising but incomplete attempts at writing a C64 emulators for the Raspberry Pi.

Now it seems in the meantime these projects have become more mature, and I am clueless about these recent developments (as usual). Now even I can easily try two "bare metal" emulators on the Raspberry Pi.

Bare metal sounds like it ought to be a musical genre, but really it's intended to mean that the emulator does not reside on top of a conventional operating system, like having Fuse Spectrum Emulator on top of Linux.

This is not to say the emulators are coded bit by bit on the processor, but at least without a full OS I guess spurious memory, swap or disc accesses can be avoided altogether and it becomes possible to achieve very fast boot time and rock solid frame rates.

I was also attracted by the possibility of composite video output which I expected to make the experience more 'real'. More about that below.

I tried two emulators, the ZXBaremulator and the BMC64.

In both cases, the relevant files are copied on a FAT32 microSD card. The C64 needs the kernal, chargen, basic and d1541II files too.

Lines in config.txt can be used to adjust how Raspi sets up the video image. Which leads me to give you a...


Foreword & Warning:

I may have ruined my old Sony portable TV by changing the display resolutions, overscan modes and their parameters for the composite video. The TV started smelling a bit bad and the composite image begun wobbling, turned yellow with color components misaligned. Ouch.

I can't say my fiddling with these emulators is what caused the death of a 30-year old TV, could easily have been a coincidence. I wouldn't blame the emulators or the Raspberry Pi in any case.

However I did try varieties of video modes that might not have been too friendly to the TV.

Progressive scan. The camera is what makes the screen look distorted.

ZXBaremulator

First one is the ZXBaremulator, a ZX Spectrum emulator. It's not clear to me if this is based on some existing software. Just a hunch it is not Fuse, looking at which options are there and which are absent.

Boot time is near-instant. Pressing F1 brings up the file menu, Alt-K gives keyboard help. 128K and +2 are also emulated, so enjoy those AY sounds. Tapes can be loaded by selecting them on the menu then using the LOAD "" or the 128 Tape Loader. A reset+auto-load would have been nice.

Thankfully the tape (TAP/TZX) loading has been speeded up. It's not instant like on big-computer emulators, but a lot better than no turbo at all.

With composite, Raspberry Pi outputs something like 480-pixel height screen through interlacing. This is somewhat helped by doubling the lines, so the Spectrum 256 x 192 screen area is really a 384 pixels tall, add borders to that and the vertical space is filled.

However doubling the lines doesn't quite get rid of the 'flickering' quality of the graphics, which becomes more obvious when white and black horizontal lines are repeated.

On my Pi2B+ and Pi3B+, the composite can output progressive scan, so I could get remove the flickering by changing a line in the config:

Instead of sdtv_mode=2

I can use

sdtv_mode=18    # progressive PAL

This is not without problems as the result can be blurry and/or has interference patterns from scaling.

Using disable_overscan removed the interference type pattern but the blurry scaled result is not perfect either. The screen is solid and this at least proves to me the interference is not an inavoidable TV artefact but a result of the raspi scaling. Looking at checkerboard and horizontal line dithering patterns, these become overtly mixed, as if the dither really formed a new color.

When playing games, the slight blurriness does not matter as much as the flickering did, but fonts can look a bit garish and the end result is not especially authentic.

+128K modes and AY sounds too
+SD directory structure supported
+Helpful key overlay & menu screen

-Can't load snapshots (z80, sna)
-No support for 9-pin joysticks

Watching that Gianna Sisters smooth scrolling

BMC64

Emulating Commodore 64 is no small feat, and here the results are also admirable. The frame rate is smooth, as can be proven by looking at the Great Gian(n)a Sisters intro screen for minutes and minutes. The emulation is based on Vice, so it ought to be pretty good.

The overlay menu is nice but apparently there are no key shortcuts?

The C64 palette is not as harsh as the ZX, so the flickering on composite is not as immediately apparent. However, it's there and using black/white line patterns shows it.

Using sdtv_mode=18 in the config.txt again kills the flickering, but no amount of fiddling with the disable_overscan and overscan values can remove the interference pattern like could be done with the ZXBaremulator.

Thinking of a real case, the large texts made from thin horizontal lines in Wizard of Wor become affected by the scaling.

I'm unsure if this is a result of the emulator author making a choice or not. The supposedly 'real' aspect ratio is not in my opinion as important as getting a resolution that scales well.

So the results are not as promising as with the Spectrum in this area. So here I'd say endure the default 480i flickering if you want to use the composite. The interference pattern is there too but it's maybe less conspicuous.

Scaling artefacts.

The Raspberry Pi GPIO pins can be connected to real Atari/Kempston 9-pin joysticks. This was easy to do without soldering, using a suitable connector and jumper cables. Just remember the GPIO numbers are not the pin numbers, check the GPIO-numbered pins within the connector of the particular make of Pi. They ought to be similar though.

Using a 9-pin joystick such as TAC-2, it became easier to judge whether there is a lag or not in the emulation. Using the composite connector with a CRT and the GPIO-connected TAC-2 joystick, I felt the lag was negligible or non-existent, I really couldn't complain at all.

Using the HDMI television, I felt the presence of a noticeable lag in games with very crisp controls, such as Buck Rogers. Whether the particular TV is to blame (most likely) or if the HDMI connection always produces some delay, I can't say. Still I'd think even this lag is acceptable for many games.

Maybe more about this later...

The disk loading is real time, so get used to waiting. Ok, it's possible to use an Epyx Fastload cart image to get a faster loading speed (for me a 25 second waiting time was reduced to 11) but that's an extra stage too.

An Action Replay VI cart image did not work as I would have hoped. Carts obviously run instantly but I only tried some 8K and 16K cart images for now. (It's not an accident the test games mentioned here are cart images, they load instantly.)


+Nice overlaid menus
+Selection of palettes
+Support of 9-pin joysticks via GPIO

-SID emulation could be better? No 6581/8580 selection?
-No SD directory structure support
-No PRG loading support?

Edit 19.12.2020: I had a second look at a later version of BMC64 and it's become a lot better!


But why?

These emulators are a fantastic job overall. But do *I* need something that lies somewhere in-between real hardware and an emulator running inside normal OS, especially as I have both options already?

Well, it's another interesting project to mess with, and it would be fun to build a case for a new ZX or C64 as the Pi is so tiny. It might be handy to carry and show 8-bit games and demos to people without having to lug all that old hardware, yet having something more than just an emulator on a laptop.

The composite image modes turned out to be a bit of a mixed bag, so perhaps I'd go with HDMI here after all.

Again, I have to warn about the dangers of fiddling with the video modes too much on an silly old TV. I'm not sure if framebuffer_width affects the composite image at all but I had that included on my BMC config when I fried my TV.