Thursday, 21 January 2021

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.

Thursday, 7 January 2021

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

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.

Sunday, 3 January 2021


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.


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:

Thursday, 31 December 2020


The customary look-back into the year.

Retro stuff = C64 stuff

Apparently I'm concentrating on fewer and fewer platforms. The year was quite Commodore 64-centric, such as toying around with THE 64, 1541 Ultimate II and casemods. More recently, I've worked with the BMC64 Raspberry Pi C64 emulator again.

I did a bunch of 6502 code but only a little of it has seen the light of day. I did release a small videotester for C64, though. PETSCII graphics is small enough to do occasionally. Also I made a couple of tiny demos based on PETSCII, such as the Petmanbatman and Advanced Pet Dragons.

I also got a PETSCII piece out in a paper publication, Kuti #57.

I've done less pixel graphics. I prefer to draw fast and that's hard to reconcile with the pixel aesthetic. Compared to PETSCII it feels time consuming and the results are not that different.

Multipaint got the inevitable 2020 update with transition to Processing 3 and resizable windows. Possibly it finally works reliably on a Macintosh. I'm perhaps hoping to put less time into this project and the 2020 version could be one of the last big overhauls. Many tiny improvements are on the to-do list, though.

On less retro front, I've been playing with a server, more and different Linux installations, a "new" mac and with some help I'm getting to know my way around these systems. Even Raspberry Pi looks more attractive now that I understand more about Linux than 5 years ago, and maybe it's a platform to look at more closely in the future.


Mostly thanks to Proton, I could enjoy new games in 2020. The biggest game I completed was Just Cause 3 which worked nicely on Linux. A very enjoyable and not too long open world destruction romp.

I couldn't finish Nier:Automata, but maybe will return to it eventually as it had some quite impressive parts. It also glitched more on Proton than Just Cause, but was playable. 

Some of the smaller games were Lonely Mountain Downhill and Saboteur Sio

Lonely Mountain was incredibly addictive at first, but when I got bored I got totally bored with it. Perhaps less routes and bikes might have been better so I would have had more genuine motivation to optimize the courses, like with Stunt Car Racer.

It amuses me now how I initially dismissed, a game I first tried at the end of 2019. Then I played it for most part of the year and still play it. The overhauls to the login system and various outages almost put me off it, though. I'm now better at it but even now the results seem more to do with whether the really good players happen to be on-line or not, rather than my inherent skill. Outright cheating/hacking may have diminished somewhat at least.

Chess is still on the playlist but I've been concentrating on it a bit less. I make this complaint every year, and I'll make it again: I feel I could improve if I put even 30 minutes into it every day, but that measly amount would feel too much to dedicate. I did manage to play about 1000 games this year, although mostly blitz on Lichess. Slower chess would be nice but the time use is even harder to justify.

TV, Films, Books, Scifi

For films, the year 2020 was more about re-watching rather than covering much new terrain. Tenet was a memorable film but perhaps not the bullseye everyone was hoping. Well, amidst the worst Covid-19 stupor, this film had begun to gain a messianic promise which it really could not fully deliver.

Doctor Who continued, the episode ideas were good but the writing overall had some problems. No reason to stop watching, though, it's still solid TV sci-fi. In some ways I'd compare it to the first season of the new Who, an attempt to keep the episodes self-contained and finding ways to renew the mystery of the character.

Westworld season 3 started with a bang, what the season 2 ought to have been. But it begun to veer away from the Westworld concept and overall was a puzzling addition to the series. I guess it was meant to deliver the idea that we all live, or are about to live very soon, in a sort of "westworld". As a detail, a lot of people got shot from a close distance in a random and nonchalant way, something that got boring very quickly. 

The 100 came finally to an end, a not so high-profile series that over the years has had its ups and downs. I often felt it built upon watered-down themes from bigger series (Game of Thrones, Hunger Games) but it had its own voice too. The confused last season perhaps took some story-telling elements from Westworld.

The Mandalorian was probably the best Star Wars related thing in ages, but it also reminded me of how bloated the whole SW phenomenon has become. There's a lot of verbal/visual in-jokes and meta-gags, which the series can now afford as there are so many layers to the SW verse. 

The Queen's Gambit mini-series was a fascinating story about chess and a nostalgic look at 1960s US. As a TV series it was able to give more detail to the games and the chess player's practice than films usually do. Given how popular it has been perhaps there will be more chess-themed shows.

As for books, I also kept revisiting the old rather than reading much new things. Well, when I was somewhat ill I did go through Suzanne Collins' Hunger Games trilogy and Stig Larson's Millennium trilogy, pieces of past zeitgeist I had previously ignored. I made a point of reading the Asimov Foundation/Empire/Robot novels in a chronological order and a blog post about it is still in the works.

Onwards to 2021

I'm hoping to continue with business as usual. This blog will have its tenth anniversary in June!

Monday, 28 December 2020

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 a bit 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 a bit 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 solderings, 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 a bit 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 bit 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.

Saturday, 19 December 2020

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 ( 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:

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

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

Sunday, 22 November 2020

Multipaint 2020

I've tried to have a major Multipaint version out each year, at least as long as it makes some kind of sense. Now Multipaint 2020 is out, somewhat later than I hoped. 

The fix-list of every tiny thing is too numerous to put anywhere, the website details the more important ones ( I'll just open up a few points too large to fit there.

The largest step was to move over to Processing 3. This itself doesn't really change the program appearance in almost any way. Hopefully as a newer version it would be more stable and the prefs.txt problems becomes a thing in the past. 

Sadly the transition to P3 means the application is likely slower, something that shows itself on less powerful computers. I compared the Processing 2-based version on Raspberry Pi 3, and found that version to be useable, whereas the new executable made with Processing 3 is quite slow.

This could be due to the way the screen renderer works, but I didn't dare to meddle too much with a thing that worked well in the past.

Application window resizing

(Edit: The feature doesn't work in all Linux desktops. Hang on.)

Edit 2: It does work, too! (24.11.2020)

A major visible change is that I made the application window resizable. Although the program had been already written with a flexible interface in mind, and it could be set from the prefs, the app could not be resized while running. 

However, despite the old code there was still bring a bunch of boring upheavals to the interface drawing and scaling routines.

Dark theme, resized window, SET GRID and a 100% C64->ULAplus conversion caught at the same time.

There are various reasons for making this. One is that there may be low-resolution screens which didn't just about fit the display, so you have a chance to adjust the situation a bit. It's also easier to make larger if it's too tiny for your display, without fiddling with the ZOOM parameter in prefs. Also, if your screen size allows it, it may be nicer to have some more of that good old border visible.

Just to be clear the target platform resolutions are not alterable. I did some behind-the-scenes work to enable non-standard screen sizes, important for Amiga, but this will be a future feature.

I long wondered why Processing 3 does not allow the direct use of size() no longer, or the use of variables as parameters to it. Well, in P3 it's now simply surface.setSize() and works just as well or even better so no worries really.

If the chosen viewport doesn't fit the current scale, Multipaint will re-scale the interface. Also, if you make the application window substantially larger, the scale will follow. Scaling was a feature that was previously only accessible from the prefs.txt ZOOM variable.

The least I now want is to make Multipaint more complex. So, it should still work as before and you might not even notice the resizable window feature if you don't need it.

Resizable window is also a base for future developments, as more flexible target platform resolutions could be made to fit better in the application window.

A very large window will unfortunately slow down a computer, or make your computer choke and start the fans, even if you do nothing with Multipaint. This is something that relates to the way Processing updates the window and apparently can't be helped much.

So, it's somewhat ironic that if you have a huge 4K/8K resolution display specifically for graphic work, then Multipaint might not work ideally on it. Resolutions like 1920 x 1080/1200 should not be too huge. I'd recommend not working on lower display resolutions than 1024 x 768, but it shouldn't be impossible.

Still, the window resizing is less than complete. You can't yet change the actual viewport position, for example.

Dark theme and Set Grid

I added an option to switch between light and dark theme. This did not require much work, as the interface fonts and icons are based on custom routines anyway and not on real fonts or image files.

Set Grid dialogue is something I wanted to add. The already existing grid commands and presets should work as before. This is again a "funny" thing in that the facility for making arbitrary grids has been there for a while, but there was no dialogue to make it happen.

I can only note that when working with 8x8 attribute modes, if the grid does not align with the attribute grid it can be really confusing.

What with the new drawing routines and all, the grid color is again a bit silly. It's like a recurring nightmare. I added a brightness setting as a hasty fix, but as some have commented the grid might have been too dark in their monitors anyway so it is good to have it adjustable. But this is a topic I'll have to look at in the future, again.

Border analysis

When loading png/jpg images, Multipaint will make an attempt to deduce if the image has a border and takes the "real" image from the middle, if it has the correct resolution (or a duplicate/triplicate of the resolution).

For ZX Spectrum and C64 modes this might be helpful when using Multipaint with plain jpg/png files.  It also makes it a bit easier to load existing images from the internet.

I'd still recommend using the BIN file format for project work.

Multipaint loading a 3x PNG file saved from Fuse. (In this case, use SCR, really)

However, if Multipaint can't explicitly determine a border, it will simply load and scale the image, borders and all. For example you might have a small logo in the centre of the screen and a black background and border. In the future there might be a "crop anyway" dialogue.

One problem was whether to include this feature in modes that don't really have a border. But I felt that there might still be quite a lot of images with a "border" in them, such as Atari ST screenshots. So I enabled this for every mode.

Amstrad CPC Overscan 384 x 270 x 16

The original Multipaint interface was very fixed to the idea of having a 320 x 200 resolution at tops. This was also reflected in many, but fortunately not all, internal structural choices of the program.

But now it might be the time to expand these horizons a bit.

To cut a long explanation shorter, instead of resizing buffers I'm using the same room more efficiently to manage the 384 x 272 x 16 resolution.

Just as with all the Amstrad modes, the export template is taken from Marq's Pixel Polizei (thanks!), so you should be able to get the exported images up and running on a real Amstrad. I also followed the export code quite strictly.

The CPC overscan, I'm told, is not really a very standard graphics mode, so I'm now sort of opened the gate for software-enhanced modes(!)

Amstrad CPC mode 1 320 x 200 x 4

This was already in the later 2019 version I think. The mode was a fairly simple addition, but I don't expect many to use it. It is somewhat nostalgic to me as I used to see screenshots of Amstrad games in magazines and they often looked like Spectrum games except with one or two more colors and I wondered how this could be. 

There is an overscan variant but I have not implemented it yet.

C64 unlimited 320 x 200 mode, and other C64 goodies

I added the C64 hires unlimited mode that was previously experimental. It behaves like a C64 320 x 200 mode, with the fixed palette of 16 colors. Howver you can draw the colors freely without any color clash.

So you could basically draw a C64 hires image without Multipaint imposing anything on you, and then move over to the C64 hires mode, and have Multipaint "validate" your image.

The reason for this mode in the first place was I wanted to work on composite sprites, i.e. overlaying different-colored sprites to make hires sprites with many colors. (Or superimpose hires on multicolor sprites). However, it is your responsibility to convert the output png into valid sprite data.

Adding this mode is a bigger change in the Multipaint "philosophy" than might seem and I've felt a bit troubled about it every now and then. However, perhaps better simply make it available and face the outcome.

Why don't all the modes have this option? I haven't still quite decided if this should be a unique mode or rather a switch inside the modes proper.

The transition between different C64 modes is now smoother in that your chosen palette will be preserved and so is the border color. The image is still transferred via "bitmap conversion", but I have not seen any problems coming out of this.

Multipaint at