The Raspberry-based Z88-wannabe

After playing with the portable Cambridge Z88 computer and reading little more about devices such as Amstrad NC-100, Epson HC-20, Husky Hunter/Hawk and the Tandy TRS-80 Model 100 (Kyotronic KC-85), I began to wonder if anything exists currently in the same form factor.

There are a few keyboard-display hybrids. There's the Ficihp K2 keyboard with an integrated display.  Another is a BQAA RGB keyboard, which looks larger with keypad included, and something called Kwumsy, a very similar concept.

These hybrids do not contain a computer. Expensive, and apparently geared more as an add-on for gamers and such, I passed these opportunities as something that wouldn't work for me and not easy to hack into a full portable computer.

But it became clear that mass-produced screens must exist for such devices, and I started planning my own version.

*** Some of the details are left vague on purpose – for inspiration only! I'm not responsible for destroyed Raspberries, lost data and house fires other than my own. ***


Model 100 or Z88?

Exactly ten years after building a wooden prototype to house a Raspberry Pi, I felt I could hodge-podge something together without going too deep into electronics or software development.

And yes, many have hacked Tandy Model 100-inspired cases for Raspberry, or even used an original case. Model 100 was far more widespread and better known than the Z88, especially in the US.

Hobbyists and crowdfunders have built some Model-100 successors, such as the Clockwork DevTerm, and the Ready! Model 100. Just looking a these makes me feel I don't want all that clutter.

My concept:

A no-nonsense slab computer inspired by Cambridge Z88, mostly for writing.

-Large-font terminal for focused text editing etc.
-No GUI/Desktop/Browser
-No mouse, no trackpad, no nothing
-No connectors
-Flat rubber keyboard if possible!
-Wifi is still needed there to install software and easy transfer of files

I would not break my Z88, and my project is not about building a computer inside that case. I probably couldn't get the parts to fit there anyway.

Well, off to hacking.

The screen

I started by hunting for a suitable display. The Z88 original design depended greatly on the availability of a particular LCD display, and I have a very similar design constraint here.

I would have liked to use an e-Ink display just for the added weirdness, because I've seen videos of people connecting them to Rpi. But I couldn't find anything close in the aspect ratio and size range I'd need. It's either book page territory or tiny electronic price badges.

Some of the first tests with the display, running Raspberry OS

Eventually I decided on a Waveshare 10.9 inch HDMI display with 320x1480 resolution. Another option might have been an 8.8 inch screen with 480x1920 resolution, but the proportions didn't look that inviting. And yes, the 320 is the default horizontal resolution!

It's a touchscreen, but I'm not going to use that feature.

I ordered the Waveshare from berrybase on ebay and received it soon enough. The package included the screen, HDMI cable, USB power cable, and an assortment of screws, stands and USB adapters for different Raspberry models. There's also a cloth for wiping the display clean.

Just connecting the HDMI to any old output of a computer doesn't work, the computer needs to have drivers. And fortunately the Raspberry Pi OS has that, and the product is clearly intended to work together with a Pi. 

It is a good idea to do the initial tests with the basic OS without jumping into the Lite OS or some other build.

The configuration is clean, but a little tall for my purposes.

A fresh desktop is a little annoying as the initial dialogues do not fit the narrow screen. Remember, the screen is horizontal in the 320-dimension. But after getting through this, it's possible to use the OS screen/display functions to rotate the screen.

A better way to do this is to adjust the config.txt and the display parameters prior to booting up.

With some more fooling about, I had a correctly rotated terminal screen using a 16x32 font (sudo dpkg-reconfigure console-setup). This gave me a chunky-looking 93x10 character display, inspired by the 8-line Cambridge Z88 display. After that I began to think of installing the OS lite version without desktop on a separate card. More about that below.

I feel the shape of the screen is quite close to what I want, and the product connects and displays the Pi screen with no big hassle. All in all this stage was a lot easier than I thought.

Battery

I did the initial tests with PSUs, but I was eager to start planning and building the case itself.

A thin battery would be desirable. There are really small products that cater mostly for no-display, low power operations. The JuicePi hats look a little daunting, eating all that space would be a little counterproductive.

A battery should run the Raspberry for many hours and the screen is likely to eat up power. So I tried to look for something sturdy, such as a power bank.

I bought an Insmat Exclusive PD3.0 Super Mini 10000mAh power bank, because it happened to be on the shop shelf and had promising enough parameters. It's about 18mm thick with 2 USB-A output sockets. This made it possible to power both the screen and the Raspberry instantly without any modifications.

10000mAh sounded like a minimum, a ballpark estimate says I might be able to run the Pi and the screen for a couple of hours.

I wish there were more flexible backlight options on the Waveshare, I could live with a relatively dim screen in this context. A similar display with ISP technology seems to have more options in this regard. Here, even the lowest setting is quite bright. Only in a very bright office environment it begins to look dimmer in comparison to other displays.

The power switch

There are a lot of tutorials on how to build a safe power on/standby switch, but nothing very reassuring about cutting the power physically. I think it should be safe to cut the power after I've issued the shutdown command, just as I have to do anyway when I pull off the cable.

I tried powering the screen from the Raspberry 5V out, using only one USB out from the power bank. This should be the same as sharing the input of the MicroUSB. But although initially promising, this seemed to cause problems and undervoltage, so I reverted back to using the both USB power outs separately, as it appeared to work better. Fortunately I have a switch that controls two separate power lines.

I'll discuss the undervoltage problems further below, it's not certain that powering the screen from Pi was to blame.

Keyboard

The first keyboard connected was a quality Apple Mac mini keyboard. This was all well until I noticed I had trouble getting <|> keys from where I'd expect. Changing the settings from raspi-config seemed to do nothing. Oh well.

I'm not going to mutilate the Apple keyboard for this project anyway, so I went for my old Deltaco TB-5V. Which, incidentally, mapped correctly.

This mediocre mini keyboard was cannibalized already before and it'll live again for this prototype. It's not quite as wide as the screen, which is fine. The keyboard model is rather good for repurposing, as the controller is still a simple separate through-hole board and the connections are easy to understand. I de-soldered the LED lights as I have no room for them.

I did look into the idea of using a laptop-specific keyboards, but getting them to work on a Raspberry is not as simple as plugging in.

First attempt, will everything fit?

For a more Z88-like experience, I wanted to use rubber keyboards.

Aliexpress does sell the aptly named 85Keys Foldable Soft Silicone Mute USB Wired Mini Keyboard Computer folding keyboard Accessory, but this has an annoying lump at the left side so it's a no-no.

Having that lump appears to be a common feature in rubber keyboards. Wetkeys sells soft-comfort rubber keyboards without a lump, but they also have a numeric keypad which makes them far too wide.

I'll forget about this angle at least for now.

Raspberry Pi : Putting it all together

From my loose assortment of Raspberries, I have a choice of 1/2/3. As I'm going to run a Linux terminal there with no graphics, I could even use some of my older Pis.

Explosion. The screen is still "upside down" compared to the final arrangement.

I settled with 3B+ for the moment as the Waveshare promises to work with it. I need to mod the Pi so I'd prefer not to alter the earlier models which might become museum items.

Admittedly, the 3B+ uses more power than many other models, and in the future it might be wise to consider Pi Zero W model for such a modest purpose.

The logic of getting the screen to work and rotate correctly may be a little different depending on the Pi model.

The Waveshare product included the screws and stands to fit the Raspberry below the screen, and at first I did just that. The HDMI-HDMI connector dongle is a neat addition which removes the need for a bulky, inflexible cable. The power cables however stick out from an unfortunate angle, which can't be helped now.

The HDMI-to-HDMI is neat, but the power cables are still in the way. Keyboard controller at right.

The Waveshare concept pointed to overall device thickness in the 40mm territory, which was a little too tall for me. I looked into how to either reposition the Raspberry or remove the tall USB connectors and the ethernet connector, and using lower stands.

Trying out various loose configurations, I kept coming back to the way Waveshare intended: Raspberry screwed together under the display. To get at 30mm thick device, I changed the 25mm stands to 15mm and removed the bulkier elements from the Raspberry board.

It might have been better to get a Raspberry 3A+, which is thinner, but I was a little impatient and some Raspberrys can still be a little hard to find.

Smashing away the USB connectors.

Removing the Ethernet connector with heated pump and soldering iron was almost possible to do cleanly. But for the USB it was far easier to just peel it open with pliers, cut and crush the parts inside. Then cut the wires and solder wires on the remaining "pins".

Sadly this means breaking and throwing away perfectly good parts. But now at least I could fit the display on 15mm stands, bringing the overall thickness to 32mm (The MDF board is 3mm thick).

Ultimately the battery height of 18mm under the keyboard decides the height of the computer, so there's no benefit in getting the screen any lower.

So, it's rather bulky compared to the Cambridge Z88. As a minor consolation, at 292x190x32mm the depth of the computer is at least less than the Z88. The chunky chipboard appearance is rather nice.

Figuring out dimensions in a LibreCAD section.

As mentioned, I eventually got electrical problems, at least the Raspberry was eager to show the "undervoltage" warning occasionally.

I really started to get these only after packaging the whole thing and connecting the power switch. So, this might be due to bad cables, connectors, soldering, or whatever.

But it might also be that this particular power bank doesn't give power evenly, and the display is such a power hog the intake will easily drop below the minimum. I don't have very clear specifications about how many amperes the display would like, Waveshare site suggests 3A and that's also the power bank nominal output.

The power bank specs are unclear about whether the separate outputs supply 3A at the same time, so I assume it the value is for the total.

The 3B+ Pi model is apparently a little finicky about the power input, whereas an earlier model might complain less. However the 2B doesn't have wifi, which would be a little too limiting. And besides, it might be a good idea to actually have these warnings so I know it is an area to be improved.

After I fiddled with the connectors and the wires, and gave the power bank a good recharge, I stopped seeing the undervoltage warnings. But the wiring inside is still a problem area and I'm not going to show that mess now.

The below image sketches out the basic case shape and especially the keyboard holder, but it's not a precise indication of how it was built and what kind of parts were used. I used clamps and wood glue to pile together 3mm cardboard and MDF pieces.

This Blender model was made after building.

OS and Software

Although the Cambridge Z88 served as a point of departure for this computer collage, I'm not looking for actual Z88 simulation here.

But just for fun I looked at software that could create a somewhat comparable experience, using the 93x10 character terminal as a tribute to the 8-line display of the Z88.

So, goodbye mouse and x, I use terminal-based Linux to boot into the command line, and launch Nano the text editor for productivity.

I installed the Raspi OS Lite on a new card, and adjusted the config.txt to accommodate the display format before even booting it the first time.

sc-im on

There's less hand-holding than with the full OS, but it's not difficult because almost everything can be handled using the raspi-config. (sudo raspi-config) I am glad I am somewhat more experienced with Linux and Raspberries than ten years ago.

First it's necessary to set the wifi country, the wifi SSID and passphrase itself. Again, using raspi-config. Only after that the network is accessible. Or use ethernet, unless someone has pried it off(!)

It's also useful to set the timezone.

There are some tricks to whittle away boot time, such as removing boot delay and the splash screen. Some services, such as the network, could be shut down – if the intention is to lose the internet. 

Reducing processor speed could also decrease power need, but perhaps not in total as the tasks will take more time to achieve.

The font and font size are best handled through sudo nano /etc/default/console-setup

Some initial software ideas:

Nano ought to be launched without the space-eating shortcut display. I would also show line numbers, as there's no other simple way to show where I currently am in the document.

nano -x --linenumbers --softwrap testnano.txt

-x disables the list of shortcuts at the bottom of the screen.

The --softwrap in the command line activates soft line wrapping, so the text contents of a line are always seen on screen, which depending on preference might be desirable or not.

Nano reconfigured. (Linux Mint screencapture)

I could try to add some of the Z88-feel by running the PipeDream hybrid spreadsheet/text editor software that was central to the Cambridge computer. After all it was available for multiple platforms, including DOS and Windows.

DosBox could run Pipedream DOS version and Rakewell offers a download for free.

Using emu2 I can run DOS text-based apps via terminal, which sounds interesting. After installing git, I could clone the repository and compile it.

https://github.com/dmsc/emu2

PipeDream on emu2. (Linux Mint screencapture)

PipeDream is far too troublesome to run in the limited terminal screen I prefer, as in the DOS way the screen is assumed to be of a fixed size. Troubles begin when you have to scroll the screen. From the little time I used that software on the Z88, I found it fine for that computer but have no great desire to see it running here. So I'll pass.

For a terminal-friendly spreadsheet, I installed sc-im the terminal-based spreadsheet. This requires some more compiling and fiddling with git repos, but it was do-able. The software isn't very simple, though.

https://github.com/andmarti1424/sc-im/wiki/Ubuntu-with-XLSX-import-&-export

sc-im (Linux Mint screencapture)

From apt I could directly install calc for calculator, or just use bc. These aren't particularly visual, though.

Calc is not to be confused with cal, which simply shows the month calendar. Which is, logically enough, installed through sudo apt install ncal

Again, hexcurse for hex editor, or hexyl for just viewing hex.

I tried Ranger for file listing. It can actually work as a kind of launcher for other apps, but I also found it to be bit slow to init on the Raspberry and maybe not that useful at this point.

Tmux the terminal multiplexer can enable complex task switching, splitting of the terminal screen and generally toying around. Obviously using ALT-F1, F2 ... etc it's possible to switch between logins and it might be enough, but with tmux I could have a text editor running on the left side of the screen and a terminal prompt on the other side.

The OS Lite has Python already installed for programming tasks, and the Raspberry GPIO pins can be controlled from there. Obviously the GPIO pins are not very accessible here.

Browsing could be a possibility, by using lynx or w3m.

For games, I installed Gnuchess. In my preferred 10-line terminal, the program doesn't display the game well. If it wasn't for the pesky "Thinking..." text, the board would fit. Using "show board" after each computer move works, though.

With the smaller font I could play roguelikes and...

But this wasn't supposed to be a web-browsing and gaming platform. I've installed so much junk already, the idea of a very focused computer is beginning to get muddled!

Some notes

What about emulating Z88 itself?

I would have liked to try this, but I couldn't get ozvm to compile easily even on a full desktop Linux Mint, and I have my doubts about getting it to work on a Raspberry OS. I gave up on that angle at least for now. Using the Circle environment, it might be possible to create a comparatively "bare metal" Raspberry Pi emulation of the Z88 computer, as people have done with ZX Spectrum. Someone would need to do that hard work first.

If the aim is to create something that fits inside the original Z88 case, this is not the solution as the screen itself is already too large.

I'm already somewhat through my "Z88 phase", and having a Linux terminal is really just more powerful and flexible. In the future I could look into reducing the boot time, which is still something where the Z88 really excels at. Oh, and also the Z88 battery life is much longer, but at least I can recharge the power bank.

Boot time is more than 20 seconds

If I have ever learned something about building stuff is that a detail not taken seriously during the design process is likely to end up haunting in the build. For this box, things like how to recharge the power bank, or how to change the SD card, were not really thought about that well. Therefore they ended up relatively unresolved. To recharge, I currently remove the keyboard and pull out the bank. For the SD card, fortunately I might not even need to change it.

As far as casing projects go, this was in some ways one of the simpler ones, as the display and keyboard are dropped in and there are no ports to consider. Perhaps I should have made 25mm thickness into a hard constraint in the beginning, but 32mm isn't really that bad.

Like I mentioned, the problems are more in the electronics side of things, and I haven't yet reached a conclusion. I have already seen the power bank last for the 2 hours I hoped for, although it looks that the undervoltage issues increase in proportion as the bank depletes. I may report back once the power bank has seen a few more recharge cycles.

Raspberry Pi 400

Raspberry Pi 400

I felt the urge to get a Raspberry Pi 400 now that it has the scandinavian keys. Here are some of my first impressions.

Box contents

Holding the computer in my hand made me smile. It does have something in common with those small ZX Spectrum and Oric computers. Also, when was the last time there was a computer with a row of pins sticking out from the back?

Apart from the 400, the box contained a PSU and a Micro-HDMI to HDMI cable and a mouse. As a tiny bonus there's a MicroSD/SD adapter with the Raspberry logo.

The pins are wisely covered with a soft rubbery cover.

The box also has a hefty manual, another nod to the days of yore. But I was surprised to find it was in Swedish. As a Finn I wanted the Swedish-keyboard model, but not necessarily the Swedish manual! However I don't see myself as needing the manual that much (and of course I can read Swedish a bit).

The 400 is small enough to stick into a carry bag, but I'd cover it somehow before doing that. The cardboard box was rather huge and can't be used as a protective container in a small bag.

Not that anyone promised, but the box had no stickers :(

Booting up and using Raspbian

The tiny 16GB MicroSD card is already in, and after booting the first time the 400 will take few rounds to compose itself.

After setting the screen size and network, I'm in the Raspbian environment. I needed to adjust the keyboard layout to swedish before it accepted those ä's and ö's.

The keyboard is nice, maybe not as good as the comparable Apple Mini keyboard, which has nearly identical size and layout. But it's much better than some cheap alternatives I've tried in the past. This has a separate Delete key, but no separate Page Up/Down/Home/End/Ins keys.

The mouse, although with nice colours, is quite a lightweight. I'd prefer the wheel material had some more friction, it feels squicky and "wet". Even if the mouse connector has a logo, the mouse itself does not have a Raspberry logo on top. Ok, it might have looked a little silly.

There's a handy "soft-power" key combination, holding down the raspi-key and F10 switches the computer on and off, so I don't have to pull the plug. 

Not 100% certain but apparently displays cannot be hot-plugged, which I guess is the usual Raspberry boot thing.

Ahhh... the good old uncluttered desktop.

On the Raspbian desktop, the Raspi key opens the start menu, and with combinations of tab, shift-tab and cursor keys most things can be done without a mouse.

To have ssh access from another computer, it has to be first enabled from the Preferences.

Chromium browser is surprisingly bearable with the more plain sites. Youtube felt quite clunky and modern ads can also be a pain in the ass.

I edited some portions of this blogger blog post using the 400, and it felt possible, although not entirely fast. Google Docs felt a tad too slow to use really productively, but small text documents could be worked on. So, the browser-based cloud possibilities are somewhat limited, but obviously there might be some more lightweight sites too.

The 400 is quite capable of running the offline Libre Office suite, with word processing and spreadsheet. This could already be valuable for some.

I downloaded the Processing projects Multipaint and Petscii editor, and found these to be quite useable, although a better mouse is recommended! I didn't have to install a separate Java runtime environment either.

The Whining part

The integrated form-factor comes with some trade-offs. After connecting the PSU, Ethernet, HDMI and Mouse, there's an array of cables sticking out from the back and given how stiff these cables are these don't all fold as smoothly as 8-bit computer cables did.

To minimize this problem one can use wi-fi and even a Bluetooth mouse, although I'm personally through with battery-powered mice.

I'd probably want to put this computer away once in a while alongside with the peripherals. But unless the cables are separated and put away carefully, the computer is an uncomfortable mess of wires that doesn't really fit anywhere. It's worth saving that cardboard box.

What a compact computer!

I have to repeat that these issues are almost inevitable with a computer-in-a-keyboard, and it's still a more ordered package than a loose Raspberry.

The microHDMI connector is problematic to me, as I still don't have a HDMI-connector equipped display. I had to test it first with a TV but all the displays I've dedicated for computer use are slightly old and DVI-equipped. 

Also, looking around it appears a microHDMI->DVI cable isn't really a thing, I couldn't simply go to a store and buy one. What I did was get a 10€ adapter that makes the HDMI end into a DVI, and this is a good enough solution for now. This doesn't have sound, and since there is no separate audio out so all in all that microHDMI connector is a small minus for me, especially as the composite output is no longer available either.

What next?

I'm not sure what to use the Raspberry 400 for. It's smaller than a laptop, so it might be carried around easily, but this assumes there's a useable display at that other location. Also, now that the Pi is in a definitive case, I'm deprived of the never-finished process of creating my own cases for the Pi.

For now I've not tested any of my other Raspberry environments. How well does it work as Amibian or something else? After I get the 400 better positioned with a dedicated display, I can look at these other environments.

What I didn't think through beforehand is that of course every card I've created for Raspi 3 won't work directly here and I have to find the 400-compatible versions.

Raspberry Pi Case for Amibian

This looks like a year for the Raspberry. Or the Amiga. Or both.

I already told of my experiences in using Pi/Amibian with a new-found cheap TV (see last post). Although the picture is not the most satisfying, I'm going forward with it. 

First, a look at the Raspberry Pi case. Another time I will make a few notes about the Amiga Workbench/Amibian install itself, which is already up and running.

Obviously I can use the case as a Raspbian computer too by just switching the SD card, but the Amiga emulation was strongly behind this idea.

The Case

Already a couple of years ago I salvaged a very cheap digi-TV tuner, because the case looked like it could be used in a project. I now thought it would pair nicely with the TV, so I finally drilled and cut holes to make the Raspberry Pi fit.

The Raspberry is annoying in how the connectors all point to different directions. This was slightly improved with Pi 2 but there are still three important directions: Power/Display, SD card and the USB/Ethernet.

With an ancient Targus USB-hub, which I also used with this old wooden casing project, at least the USB ports can be redirected elsewhere.

So I only need address two sides and the Raspberry can be placed in the corner.

I had considered putting the memory stick inside the case as an "internal hard drive". However I use the same stick in the real Amiga 500 Gotek drive, so I need to be able to move it quickly. 

Although the USB hub has four outputs, one of them points in the opposite direction. After a mouse, keyboard and a memory stick, there's no room for a joystick. I found a very short extension cable which helped me get the fourth port out. It's perhaps good one of the ports is not part of the hub.

The single USB cable was more difficult to attach than the hub. The USB connector has those flaps which means it can't be simply pushed through the hole it is meant to occupy. The flaps also help keep it in place so they should not be removed either.

I made a rough test with two chipboard pieces in a wide "U" shape. The "U" shapes interlock and keep the connector from being pushed in.  I was afterwards happy enough with the solution so I didn't try to improve it for now.

Three layers would be better as two can't keep the connector from wobbling. 

The small existing rounded opening marked "12V" could be a better place for this connector, but I wanted to try this in the most spacious location. 

Looking from the outside, it also gives an idea how the other ports might be cleaned up.

The material of the backside was pleasant and clean to drill and cut, which shouldn't be a surprise as it is clearly meant to be cut into different configurations. It looks as if the "decoder" hole wasn't very accurately cut to begin with.

A nice change after all those wood and chipboard projects.

One more woe is the minimal micro-SD card, and even now it's not protruding more than 1mm. I don't have a clear picture to show here, but the Raspberry is positioned so that the card comes out just below the metal cover edge.

I don't really need to remove the card that often as the emulator files are on the removable USB stick. I can use tweezers to pull the card out if I want to.

To have a better access to the network connector I used a short extension. Again something I did with that old wooden case.

The RJ45 "gender changer" is plastic so I made a groove around it and inserted it without any additional fasteners or screws.

I recently learned the Raspberry Pi 3 does have an internal wireless network adapter, but this felt more secure than trying to build an antenna.

Time to put it all together. What's nice about this box is the metal cover can be fit into place without screws really, but I can also use two hand-rotatable computer case screws.

So, that's it. The front side of the case is not very impressive, as it is a TV tuner box after all, but at least this time I didn't start the project with designing a front panel. Perhaps badges and stickers here...

The buttons at the front do nothing and could be hidden.

As I said, different types of Raspberry installs could be used here, and not just the Amibian, so I may need to consider this angle too.

Finlux TV

Again, supporting the local fleamarket, a television for the glorious price of 8,50€

The model is a Finlux 24" 24FLK274SVDN, it doesn't appear to have any simpler marketing name. 

It's possible the same tech appears under various different brand names. ("Finlux" has little to do with Finland nowadays.)

The feel is plasticky and it doesn't weigh much. I could easily carry it in a bag.

Last time, I whined about the lack of 50hz displays for my Raspberry Pi Amibian Amiga setup, so I figured this would do at least something to amend it, and if it didn't then the price wouldn't be high.

As a bonus it might even do composite for a real C64 and work as a computer display too?

It has two HDMI connectors, a SCART, a tiny AV and a VGA. Two USBs and an internal DVD player. The internal info-sheet shows a plethora of different modes, video file formats and inputs the TV can supposedly handle.

And that's not nearly all

I punched it in to the Amibian Raspberry using HDMI->VGA adapter, and got some kind of ugly picture to begin with.

Then I took a step back and started experimenting with the options.

Bad news

The TV fares rather poorly as a computer display. I'm not sure if I expected it to do 1080p, the specs (provided in the internal documentation) says it can but in reality the native vertical resolution is 768 pixels. (Or 720, actually)

So the TV can camouflage itself into a 1080p and 1920x1200 resolution, but the scaled picture quality is not impressive on a HDMI. I'm not fully convinced with the framerate either.

Using a Displayport->HDMI adapter a laptop refused to recognize it as a second display, which wasn't nice either.

The VGA produced quite a bad image but this is something I'm now forced to use if want it as a display for the 2nd computer, as they don't have HDMI. (It might not be too horrible as I have only very specific purposes for the 2nd comp).

Removing all kinds of automation (not that there's much) and sharpening, the image can be improved a little.

Good news

After teaching the Raspberry Pi Amibian to do 50hz, scrolling was smooth. For this, I uncommented the 50hz HDMI portion of the Amibian boot/config.txt

This wasn't initially very satisfying as the display scaling would produce artefacts for scrolling games. For this purpose I adjusted the hdmi_cvt line (for custom HDMI resolution).

hdmi_cvt=768 768 50 1

The 1 gives aspect of 4:3, 4 would give 5:4 (Amibian recommended) but does it matter as the TV sets does what it wants anyway?

In the Amibian GUI config display panel, I selected 768 x 256, unticked "correct aspect ratio" and also gave -16 v.offset (maximum), but this depends a bit on the Amiga software. Sadly there's not more offset as some modes won't fit the screen even though the height is unlikely to be more than 256.

Of course, it's worth checking if the TV is in the 4:3 state, and not for example zoom 14:9!

This way, there's at least 1:1 correspondence between display pixels and scrolling doesn't "scale" and games like Battle Squadron, scrolling in multiple directions, now scroll smoothly with no jittering and "living" lines.

Edit: I think the vertical height of the display is 720, which gives a 240*3 as a 256-height screen will be cropped a bit. I don't get how the Raspberry setting of 768 works, maybe it reverts to 720.

Ugly news

Checking the composite and RGB options, I noticed the TV can't handle these signals really, but sort of combines two frames instead of having a proper progressive display. For example if the computer flashes a black and a white frame repeatedly, the result will be a solid gray. Apparently anything that is a non-HDMI mode behaves this way.

With a "life gives you lemons" attitude I could start seeing this as some sort of extra colour mode for ZX Spectrum, but to be honest the idea of building something on a poor display doesn't appeal to me.

Edit: I tried a real Amiga RGB output too, just in case it would produce something different. The picture was actually surprisingly bearable and the frame conflation is not immediately apparent when watching games and demos. Sadly, there was a tiny hiccup all the time in the frame rate. Also, flashing black/white screens finally reveals the same result as with all the RGB and composite modes.

BMC64 and THEC64

It gets a bit weird, trying to get a "fake" C64 to work with a "fake" display. But why would it be more fake than the Amibian+HDMI? Perhaps I find the idea of connecting an Amiga to a modern display more acceptable as it has a history of pretending to be a serious computer.

Also, the THEC64 is by definition mean to interact with a HDMI so it makes sense to see if the BMC64 really functions as a complete alternative to that product.

For the BMC64 c64 emulator I had to at first activate hdmi_safe=1 to verify a HDMI image at all. This produced a 640x480 image.

I then removed the safe mode and advanced towards a custom resolution. I found it's easy to come up with a mode that looks ok at first but again "blurs" two frames together as in the aforementioned RGB and composite modes.

So I copied the parameters from the Amibian config.txt and found the BMC can live with the same 768 x 768 setup. (The config.txt scheme is common to all Raspberry installs) 

With this the 50hz flickering test is passed. Then the display border sizes and stretch factors are adjusted from within BMC. There's still something a bit un-perfect about the horizontal size but at least it matches the pixel resolution somehow.

So I ripped these lines from the Amibian config.txt:

hdmi_cvt=768 768 50 1
hdmi_group=2
hdmi_mode=87
hdmi_drive=2
scaling_kernel=8

I have this Commodore 64 videotest software exactly for this kind of purposes. (1=horizontal scroll, 2=flickering screen (the 50hz test), 3=horizontal alternating lines, 4=vertical alternating lines, 5=checkerboard)

The text is part of the BMC overlay, C64 produces the test image.

I don't see how I'm no longer allowed to "Apply scaling parameters at boot", though. 

Admittedly the "screen ratio" test would be nice to have.

With THEC64, the TV is obviously recognized by the computer and the picture is nice and clean. The 50hz test is passed, horizontal lines are ok but vertical lines have some scaling trouble. This is probably because the device insists on a correct aspect ratio. 

It is more revealing in horizontal scrolling, such as the Giana Sisters intro scroll. Playing Giana Sisters, it doesn't really bother that much.

It's pointless to try to photograph how good the display is

A more thorough head-to-head between BMC64 and THEC64 will have to wait, but I'm now thinking both have benefits. But at least with this particular TV, the BMC64 again comes up with the goods.

The verdict

Had the TV been even slightly more costly, it might have been a disappointment.

But it suits well for the originally intended purpose, connecting the Raspberry/Amibian to a 50hz TV. It even exceeds my initial expectations in that area. For these lower resolutions, HDMI mode colors are good, crisp enough and the black is extremely, deeply, black.

There's soul-searching to do, as it is now the TV would cater both as a semi-retro display and a poor man's computer display, winning more space on the desk. But it's a clear step down for some uses, as it is not CRT and not a real computer display either.

Amibian

Let's have a look at the Amibian Amiga emulator on Raspberry Pi 3.

First I used Etcher to write the .img to the Micro SD card.

First time boot, exit the emulator config screen ("Quit"), use raspiconfig and find the option for extending the SD card filesystem. (It might not be on the first page of menu items). Then Finish and prepare to reboot.

It takes a few seconds to get to the config screen. F12 switches between the config and the emulation.

It's also possible to again Quit to the linux command line and examine the folders and change the various settings. There you can update the system, too. The command line parts have simple assistive menus so I'd think less advanced users might find what they want.

In the graphical config menu again, if the Amiga files are on a separate USB stick, navigate to /media/usb0 to get there.

You can select ROMs (e.g. kick13.rom) from anywhere, but at amibian/amiga_files/kickstarts they will be convenient. 

To get your system to boot as directly as possible to the Amiga Kickstart, quit the config, use "Emulators setup", "emulator config" and "uaeconf1" to select for example config 1 as the one that starts automatically. You can also use the uaeconf1 directly without resorting to the menus. From the graphic config untick "show GUI on startup" at Miscellaneous tab. 

To change or creatively remove the Amibian logo from boot, change the contents at amibian/boot_pictures/

As the linux shell background has been set as blue, it will flash in sight during the boot sequence. This was mildly annoying.

This can be changed by editing the file called .profile (e.g. nano .profile) at the home directory (the one you land at after Quitting the config). Change the "background blue" into "background black", so the boot process looks less aggressive. In theory you could set the font to black too but this isn't very practical as the shell is needed!

Composite video

I was curious about how well the Amibian would show composite video.

This is not an entirely minor point as many modern computer monitors won't do 50hz, but the 1084S does and it's also a period-authentic display.

Using the Raspberry Pi video splitter cable, the tiny audio/video connector can be divided into RCA Composite video and stereo audio.

Changing the config.txt on the Raspberry partition enables composite video output. 

sdtv=2 gives interlace and sdtv=18 enables progressive scan. 

There's an option that enforces HDMI even if no HDMI cable is connected, so this has to be commented out too.

I have to say Amibian appears not to be as sophisticated with video options as the recent BMC64. I will easily get pattern artefacts at least with 1084S. Adjusting the overscan settings in config.txt did not help. 

This may not be a big deal in many games, but it is obvious when making horizontal lines in Deluxe Paint.

How about screen refresh? Trying some games (Battle Squadron, Rodland, Giana Sisters) the screen sync was fine, but the demo Enigma by Phenomena started revealing hiccups in the screen update and there were some graphics glitches too.

This has nothing to do with the composite, as HDMI showed the same effects. But the glitches might also result from incorrect Amiga settings rather than the Amibian as such. 

It's also possible the Raspberry just can't emulate it all fast enough when it comes to more Amiga-specific bitmap and screen handling.

But, arguably the refresh rate was generally more stable than the 50 adapted to 60 on UAE on my Linux+computer monitor. The demo didn't have the glitches on Linux emulation so the adf is unlikely to be corrupt.

HDMI

Less of a purist can go with HDMI and it might be easier on the eyes.

You can't get audio from the composite/audio connector while the HDMI is connected, so you need to depend on your HDMI to deliver that, too. I had a HDMI->VGA/Audio splitter which separated the audio output to a mixer as my display doesn't have speakers (or HDMI for that matter).

A television does better than a computer display, as it is more likely to do 50hz and playback the audio through the HDMI.

My poor ears could not notice any particular audio problems. Of course with headphones the Amiga stereo separation can be unbearable, but as I had the sound go through a mixer anyway I could adjust the situation.

Other considerations

Trying Frontier: Elite II with an anomalous setting of an A500 with "Fastest" speed (I guess the maximum) the game plays quite smoothly. It can still choke on very high detail. The speed can be changed on the fly, and making an eyeball judgment here the "fastest" speed looks like at least twice as fast as the 25mhz setting and the launch from Ross 154 with high detail is quite smooth.

So from this I'd judge there is enough raw power in the Raspberry 3 to run an Amiga, it's just that there are some features it can't pull off that easily, and these can be more apparent in scenedemos. I didn't test a lot of software though.

I experienced keyboard problems when typing, but this meant I had to remove the keyboard from the joystick emulation. After that the keyboard worked ok for AMOS Professional :)

The Logitech Gamepad F310 was recognized easily and worked fine. The config menus can be operated with the gamepad. Putting "Enter GUI" to the start button enabled me to reach the config from the joypad, however the function actually went to the left shoulder button. So a lot can be done without a keyboard if you have set things up cleverly enough.

I would have liked to connect a real Amiga keyboard to the GPIO or at least a joystick. The keyboard would probably require far more work than the Commodore 64 solution.

Edit: I could use the USB wanna-be Competition Pro joystick that came with THE C64 to give some more "authenticity". With Stunt Car Racer it felt better than a modern gamepad.

When connected to HDMI, it's hard to see an advantage or difference compared to having UAE on your main computer, for example running on a second screen. It's of course nice to see the Raspberry is so capable.

With composite video, the nostalgia factor is higher but the video options couldn't get rid of the horizontal line artefacts and it's possible a proper Amiga screen just can't be achieved in all situations.

The best use situation is with a HDMI 50hz television.

Amibian from here:

https://gunkrist79.wixsite.com/amibian

Some more BMC64

Just a small update on putting the Raspberry Pi BMC64 Commodore emulator inside a Commodore 64C case, as described in the previous post.

The starting point:

I chose a suitably sized prototyping board with unconnected holes, sawed off the corners to make the Rpi screws fit. Then I soldered a 2-wide female pin header for the Raspberry GPIO and a 1-wide pin header for the C64 keyboard connector.

Then I soldered all the connections, trying to keep track of the mess. I lost the track once but fortunately it was not too difficult to re-solder a few wires. Soldering wires into pins isn't ideal, but tinning the wire ends prior to soldering helped a lot.

In hindsight I should have used a bit lighter, more bendy wire as now I had to push them down to make the C64C cover fit.

The end point (for now):

That horrible hole is the trapdoor for getting the SD card out. Sorry.

It's now quite compact.

I didn't do the joystick connections at the same time which was silly as they will be more difficult to solder now that the keyboard wires are in place.

Instead, I soldered a joystick connector in from the underside, aiming for the GPIO Bank 2 pins.

After a few mistaken solders, I found out I need to be careful which GPIO configuration I am aiming at, and also understand that I'm looking at the GPIOs from below the board. 

Now, it's getting crowded in here.

When using both the Keyboard and Joystick from GPIO, the pins are different than when using a joystick-only configuration.

So, in this case I used GPIO U=20, D=19, L=16, R=13, F=26 and Ground to get my joystick connected.

The joystick port is made from a PC COM-port as it had the correct sized header for the pins. Nothing has been properly fixed to the case but this shouldn't take too much work.

In use

If there's a Commodore 64 lying around, I sometimes write nonsensical little BASIC programs. Multiplication table tutors, tiny games, graphics effects, PETSCII scrollers, whatever.

This time my excuse was that I needed to test the keyboard more extensively.

And it works, I had really no trouble in getting to that BASIC programming mood with the BMC64 and the C64C keyboard.

A word of warning with the BMC64 emulator: Any changes to the attached D64 disk image will not be preserved if you don't detach the image first! So if you save your BASIC program to the attached D64, always remember to detach it before shutting down.

I also tried my go-to game for testing joystick lagginess, Buck Rogers (catridge image). Playing with a TAC-2 joystick I can feel a tiny amount of lag if I really concentrate on it. The BMC site says the joystick is only read alongside the screen sync, considering that it's not bad at all. Most games would probably poll joystick once a frame anyway, then depending on how it's done I guess the lag could vary.

BMC64 the sequel

Time flies. About a year and a half ago, I had an all too brief look at the BMC64 Commodore 64 emulator for the Raspberry Pi (and the corresponding ZX emulator).

Although the emulator was already impressive by then, I had some minor gripes with it. Now it's a time for another look.

On my Raspberry Pi 3B+, the system boots in a few seconds, comparable to a sluggish real C64. Nothing to complain here! Hit F12 to enter the menu.

The video options are now extensive, and I could get a good picture out of the 1084S monitor. It's worth mentioning the Y offset may need to be changed to 1, otherwise the scanlines are "between" the actual monitor lines and will look blurry and incorrect.

The picture is obviously a bit too perfect :) as it doesn't have the black bleeding and other C64-style artefacts. But it certainly doesn't have any moiré effects. (Any such in the images are result of the photo processing.)

Trying Buck Rogers again made me feel as if the lag had been further minimized. I could not really detect any significant amount of delay here.

Based on vice, the emulator now supports the other Commodore computers too, such as VIC-20, PET and Plus/4. I didn't try these yet, but it is possible these are not as perfected as the vice C64 emulation (Plus/4 people keep saying this) but it's a good bonus.

Although I don't remember this either, the sound may have been improved and there are likely more sound options than when I last looked, as seen from the above menu.

Still, SID emulation is tricky to perfect and this is an area where differences are easier to spot.

Real C64 keyboard

The overall impression was so good I was motivated to test a real Commodore keyboard. It can be wired to the Raspberry Pi GPIO connector with no additional electronics. Last time I only tried the 9-pin joystick.

A PCB design exists for just dropping in the keyboard connector and the joysticks (also a power switch), but now I could test it with breadboard wires.

Without such a PCB, it's not that obvious how to place the Raspberry in the case, but it's a start.

A tip for mounting a Raspberry on some surface. First drill through one hole, then screw the Rpi in place. Then drill another hole through the Rpi circuit board hole. Put that screw in place too and then drill the two remaining holes, again through the circuit board. 

This way the holes will be more accurate than trying to mark positions for drill holes using the Rpi holes or with a ruler.

I got a bit sidetracked at first as although I had a loose C64C case and keyboard, I didn't find my keyboard mounting brackets. 

So I had to improvise something. Luckily as the C64 board doesn't have to be there the shapes aren't that specific, as long as they hold the keyboard in the correct place.

I took the basic dimensions and some inspiration from crashmeplease's Ultimate64 Keyboard Mounting Brackets (https://www.thingiverse.com/thing:3051450) STL models, but of course my mounts are not 3D printed.

So what if the case is full of wires, what else I'd put there? 

I took the wire order from here:

https://makerhacks.com/raspberrypi-bmc64-c64/

...and of course the GPIO numbering is not the same as pin order:

https://www.raspberrypi.org/documentation/usage/gpio/

Later I might solder a proper connector between the Rpi and the keyboard connector, and also adjust the positioning a bit. The SD card isn't particularly accessible at the moment, I carved a crude trapdoor for changing it, though. No, I don't think every C64 case needs to be preserved in pristine condition. Damn those micro-SDs.

Starting the Pi, the C64 keyboard didn't work! But no worries, it needs to be activated first from the keyboard sub-menu, using the USB keyboard. 

After this the C= and F7 key together activates the menu and it can be operated with the C64 cursor keys. Obviously it's a good idea to save the settings at this point.

I left the joysticks unconnected and this might need some additional figuring out.

I noticed that as the C64 keyboard is active, I seem to lose the possibility of using arrow keys as a joystick. In fact, if try to use the option Left Control/Arrow keys as joystick, I can no longer access the menu using C= and F7 and have to restart the Pi.

I had to test the one major advantage a real keyboard has over emulators, the PETSCII characters! I didn't have the patience to do anything larger, though... Shift Lock doesn't seem to work.

Without joystick, I was not that eager to test so many games, but Thrust (keyboard-based arcade game) worked rather well.

Trying the composite video with 1084S monitor and using this real keyboard, the feel is pretty good. 

Unlike with THE 64 Maxi, there is no feel of delay from my keypresses to the on-screen characters in BASIC.

So, yeah

So, a definite multi-thumbs up from me and I'd say this looks like it is preferable over C64 Maxi, at least if you are prepared to do a bit of tinkering.

Keyboard project continued here

BMC64 website

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.