Thursday, 5 March 2020

Icing on the Cake

That's a very rare Commodore 64 model... one could even say, unique!

Yes, I've been working on this desktop C64 case idea for a while. It is loosely modeled after the C128D cover. The front panel was a bit unsatisfying so I finally went and made something that is more in the spirit of the computer.

I'm making these from chipboards that are maybe more commonly used in building dolls houses. It's easy to cut and sturdy enough for these computer cases, if some thought is put into the structure.

I'm not too keen to do truly wooden cases, partly because I don't like the look and partly because I don't have the equipment and environment to do them properly.

I'll need to repeat that what I'm doing here might be a fire hazard, and the dust these chipboards produce could be a bit bad for the computer too. So consider these as prototypes.

Some work-in-progress snaps:

It fits!
The new front panel is a separate "hat" that can be detached. I made it from the same materials as the cover. I'm again using the ready-made edges of the sheets to define the front upper edge of the hat so it would be as smooth and clean as possible.

Gluing the three long pieces together was not the easiest task as they are not easy to support.

It can be removed!
But why do the front panel as a separate piece?

I wanted to paint the entire case, which would have looked nice enough without the panel, BUT when the cover is opened it would have left a visible seam/crack. With this "hat" I can model and paint the case in the future with less problems.

Next up was the slice in front, which was a precision job with the saw. I used a ruler to drag two traces with the saw, then they were properly cut. Another route might have been to make them as two pieces in the first place. I felt better with this approach.

Talking of routes I have a hand router somewhere but did not think to use it here.

The SD2IEC is at the left because it is nearer at my desk.
The above image shows how the SD2IEC SD card would show if there was just a 3mm cover. There should be enough of the card visible to bounce it back.

I made a backpanel for the front panel (if that makes sense) so the cart is less visible than in the image above. It still bounces out but not as easily as I'd hope. I'll perhaps adjust the SD2IEC position a bit.

Also, the bolts at the bottom of the case were somewhat in the way of the "hat" so I had to do room for them. In hindsight, these could have been made through-holes, but maybe it would have been a bit too complicated.

This goes to show how earlier choices affect later ones, as I didn't plan on doing the hat at that stage. For purposes of design, it would make sense to rebuild the entire case now.

Making room for the bolts
Talking of hindsight, or perhaps the lack of foresight, I forgot I needed the hole for the Commodore 64 logo, which was more difficult now that the panel was 6mm thick. Urgh.

The Commodore 64 badge/nameplate was ordered via eBay from Poland.

By the way I used some wood putty to smooth the ends parts, because I glued them the smooth side inwards. I hoped the surfaces would stick better. This meant they had to be sanded and even then smoothed out with the putty.

Cutting the hole for the nameplate
Three millimeters for the groove is a bit too deep to look exactly like the groove on C128D would. Still it would be possible to "fake" the whole C128D look quite accurately using these same DIY techniques, but here I'm just giving a nod towards that original design.

For example I left out the floppy drive opening although I considered it for a long while. The SD2IEC is in different position anyway and this is a Commodore 64 after all.

The grey primer spray
Next up was painting. I sprayed the object first with a gray primer and then painted a white overcoat, giving a gentle sanding in-between. The paint seemed to react better to the wood-putty smoothed parts.

The first layer of spray white already reveals problems in my approach. The front side is as I expected but the paint mercilessly reveals all blemishes, seams and inaccuracies in the corners and sides. I was also too eager to paint it in one go, whereas gentle layers would have worked better.

Needs sanding and more paint.
Sanding and using more thin layers improved things. The more paint layers it has, the better it covers, but it also has a danger of becoming uneven and inaccurate even on the flat surface. I chose not to paint the whole box as yet, because I may need to do changes to it.

The groove does not get enough paint really, but as it's not very visible I don't care too much.

The rounded corners are always challenging. If they don't succeed in one go they are a bit difficult to fix. All looked fine after doing the initial 45 degree bevel and smoothing it out, but subsequent sanding broke things a bit. I managed to fix it somewhat for the end result.

Ground paint and three layers of white spray.
After a few layers of paint it is quite satisfactory. It's obvious it's not plastic and not industrial, but good enough for now. If I get to do something similar again I'll already know a bit better. If I think about the earliest "trash board" version of this case idea, I've come a long way!

There's still work to be done, especially on the backside which I've been too embarrassed to show. I now feel the design of the case should begin with solving the backside rather than the front, but it's too tempting to go straight for the more interesting workstages.

Wednesday, 12 February 2020

Fooling around some more with THEC64 Microcomputer

I already made some (premature) notes about THE C64 emulator machine. Here are some of the things I have been doing with it.

Before I go further, just to wrap up:
  • Just a teeny bit laggy, but the framerate seemed smooth
  • But be mindful of the 50hz - 60hz capability of your display (60hz PAL is unreal)
  • Can do VIC-20 mode too
  • The joystick is bit clunky but has those nice extra mappable buttons & the useful menu key
  • Does only HDMI, not even separate audio
  • ... but a HDMI-VGA adapter with audio split can help, but obviously a 50hz display is needed for smooth and correct speed.
By the way I have not opened my THE C64 yet, I've seen the pictures and it's unlikely I will do any mods in the near future so I'll let it be.

CJM file-specific parameter text files

Just saying what the manual says. If you insert a memory stick into THE C64, you can load disk images (.d64) and program files (.prg) directly from the stick.

If you put rambo.d64 disk image on your memory stick, and have a rambo.cjm text file at the same folder, you can create a joystick configuration that maps the weapon change key (space) with the extra joystick buttons.


Games such as Mercenary, Elite and any flight simulators can be obviously enhanced by this feature, even if these games often have far more buttons than the joystick has.

My palette is a bit iffy today, can't care to fix it
But certainly speed controls in Elite, missile target, launch & unarm keys could be configured this way. (It's just that C64 Elite is a bit crap.)

I also found the joystick a bit physically clumsy for these extra buttons, so it wasn't so enjoyable with Rambo. But there's no stopping using a proper 2000s USB gamepad with four-button cluster and shoulder buttons. How authentic is that... well, there were gamepads back in the day too.

For Twin Tornado, I tried this:


I put throttle controls to triangle buttons and wing adjust to the two leftmost of the tiny buttons. Third tiny button turns on the combat sights. Note that for "comma" I used CO, as obviously a real comma might mess the syntax.

Twin Tornado has serial head-to-head mode but this can't be done with THEC64
The simulator boasts surprisingly fast wireframe 3D. To fly the Tornado, Increase throttle to max, release wheel brake with SPACE. Pull up when appropriate. Once in air, switch gear and flaps with T and R respectively.

As a variable-sweep wing fighter, the Panavia Tornado can pull its wings back. Switch them to a position of 68 degrees and then you can reach Mach 1.0+ speeds. The wings can't be switched back unless you drop speed.

To get Digital Integration's Tomahawk to respond, I tried this:


The throttle and collective controls are mapped to the triangle buttons and the two first tiny buttons. The third tiny button swaps between weapon systems, once they have been activated with key C on the keyboard.

To get that Apache up in the air, increase both collective and throttle until the copter starts to rise. Then you can turn the nose down a bit so it begins to move forward. Then re-adjust the throttle/collective to maintain level flight.

It's a bit hard to tell 8-bit flight simulators apart.
I noticed that trying to use the mapped keys and joystick in very complex motions, it may inadvertently activate a key that's not involved at all. Such as Pause in the case of Tomahawk. This might have happened with the real keyboard too, it's just that back in the day the keys did not receive these combinations so easily.

I have also felt the joystick gets a bit stuck once in a while. Perhaps it will loosen up a bit over time.

They really added some weight to it! Should have weighted the shaft, though.

Cartridge & Disk images

I was interested in whether THE C64 can accept cartridges, not just games but things like Action Replay VI or Final Cartridge III.

Long story short, AVI did not seem to work whereas FCIII did. It's one way to access a machine code monitor. I'd prefer the AVI monitor, though.

I encountered some hiccups with more complex disk loaders. I was a bit saddened that the Ultima IV remaster D81 image (a large-capacity disk image) would not run further than the intro screen.

So, the utility cart support in THE C64 is a bit more haphazard and might not behave entirely as one would wish, but it's not all a loss.

On the plus side, "easyflash" carts work and many important multi-disk games have been modded to work on these images, so welcome Project Firestart and Ultima IV remastered after all!

I felt that the savestates are unlikely to work on anything that sounds a bit non-standard, such as these cart image games.

The few demoscene intros I tried appeared fine, though borders were cropped at times. There is another display mode in THE C64 that shows more of the borders, but may result in a smaller mid-screen area for games.

I perhaps wouldn't use THE C64 for running demoscene demos anyway, as there is no support for CRT display and the SID emulation is what it is.

Disk image file handling

You can have C64-compatible .PRG files directly on the memory stick, but many games come in the .D64 disk image format, which can be a container for multiple C64 files.

THE C64 facilitates loading these disk contents directly from the menus (the first file will be loaded), but to have more sophisticated handling of these virtual floppies you need to use BASIC.

As THE C64 by default mounts an empty C64 floppy image in the .D64 format, it's easy to save BASIC code snippets to the disk using


and load them back with


It may make sense to backup that disk image once in a while.

You can check the contents of a disk image with

LOAD "$",8

followed with


Remember that reading the directory with LOAD "$",8 will destroy the current BASIC program in memory!

Removing files is a bit trickier, and you can't simply overwrite a file by saving it with the same filename. Three commands are required (each followed with return):

OPEN 15,8,15

S0 stands for SCRATCH0.


Transferring code from PC over to THE C64 is not a very exciting prospect, you have to use the USB stick and that kind of slows things down a bit.

Once in a while it is fun to play around with the BASIC, although I rarely have patience to do anything large with it.

The trade-off with the 8-bit interpreted BASIC is that it's very easy to start a program and get things going, but as the program gets larger it becomes slow and difficult to organize.

So it might be good to have some kind of rough paper plan for the program as it grows. Experience with other languages is also a good teacher.

There are also ways to embed forethought into your program. Although you can always clear the screen and set the colors with a PRINT statement...

a subroutine could be called instead.

10 GOSUB 9000
100 REM main loop
200 GOTO 100
9000 REM clear screen subroutine
9010 PRINT "[clrhome][white]"; : REM use the real characters
9020 POKE 53280,0 : REM border black
9030 POKE 53281,0 : REM background black

So, every time you want to clear the screen and reset the colors, use GOSUB 9000.

The downside here is that you might not remember what GOSUB 9000 stands for, and the program becomes less readable. Unlike ZX Spectrum, C64 BASIC does not allow the use of variables as label names (which might slow down the calls besides).

So, use discretion!

Remember that editor screen codes can be inserted in the BASIC " quotes.
So, if normally pressing SHIFT+CLR/HOME clears the screen immediately, typing it after a " will enter the character code instead. Again closing the quote with " will again make the key work directly. Cursor keys, home/clr cursor and reverse on/off can be used this way.

So it's one way of positioning the cursor:

PRINT "[clrhome][down][down][down][down][right][right][right]HELLO"

[clrhome] implies pressing the key clr/home and so on. This would position the text down 4 rows and right 3 columns from the top left corner.

Then, later you can consider whether the screen-clearing has some kind of effect in it or not. Only changing the contents of that one subroutine you can change all screen clears in your program. Or replace it with a machine code call, etc.

There might be subroutine for "press any key", so it could always be called the same way and display that message too.

The subroutine call overhead is significant in BASIC, so it might be better avoided inside the main loop of an action game.

For displaying characters more directly, sometimes POKEing the display may be better than PRINTING character codes.

10 X=20
20 Y=12
30 POKE 1024+X+Y*40,1

This should display an 'A' at roughly at the middle of the screen. Bear in mind that generally PRINTing is faster than trying to combine many characters through POKEs.

Reading the joystick from BASIC is not hard. You have to decipher all the directions one at a time in case there are multiple directions and buttons pressed at once.

10 J=PEEK(56320)
70 GOTO 10

In case you only need two opposite directions and no fire button, direct values can be used:

10 J=PEEK(56320)
40 GOTO 10

This would spare the interpreter from making more calculations than needed.

The additional keys (and keyboard altogether) of THE C64 Joystick can be read like this:

10 GET A$
50 GOTO 10

This assumes a THEC64 joystick with the default config of Y, N and RETURN. Of course the keys can be used too. I'm unsure if the RETURN key could be done with some other means, but at least that works.

Unless the joystick has been configured to other keys, the triangular buttons do nothing.

Wednesday, 5 February 2020

Orion Millennium chess computer 6 in 1

From 2004, the box has a still young-ish Karpov's face on it. I'm wondering if he is recommending the product or the game of chess in general!

As far as actual chess-playing goes, this kind of cheap chess computer is now mostly superseded by mobile phones at the low end, and digital boards towards the higher end. As a design object, a more vintage device would have been prettier, but it's not the ugliest I've seen.

It's not just a chess computer, the featured six games are Chess, Checkers, Othello/Reversi, 4-in-a-row, Halma and Nim. Incidentally, Nim was probably one of the first electronically implemented "digital" games. I'm only looking at the chess variant here.

The machine operates with 4 AA batteries, and there is no connector for a power supply.

First a small disappointment: The chessmen were missing from the box, only the generic button-like pieces for the other games were left. As this cost me only 4 euros I don't mind that much. The instructions were in place. Even in good complete condition, I'm not seeing people asking more than 20 euros for this.

I used my magnetic pieces from a tiny travel set. They are a bit too small and a bit hard to tell apart, but at least I could test the board.

The board feel is sturdy and weighty enough, the footprint is less than A4, squares are 21mm giving about 168mm board size. Given the chessmen are not large to begin with, it's a pity there is no storage for them in the case itself, it wouldn't have made the computer much larger.

After inserting the batteries, the computer gave a friendly beep. It works!

The moves are activated by pushing the board at the starting position and then the ending position. This can be done with the pieces. It's not highly convenient but at least simple to understand. I felt I had to press the squares quite hard. Typing in the moves might have been more effective, but there's no option for that.

At the start it felt needlessly complicated that I had to perform the pushing of opponent's moves too. But it is understandable, as it prevents mistakes from happening.

In castling, you need to perform both the king and the rook moves.

As the computer is initially in a tutor mode, some moves were greeted with 'bad move' sounds. The step has to be passed with 'next move' key. I felt sometimes pressing this also switched the player sides. Hmm. Well, the tutor can be turned off by pressing first what looks like the "Cancer" horoscope symbol, and then the tutor key.


I played one game from start to finish against the computer, at the default level, which must be really easy. In this opening (Ruy Lopez), it seems the opening library ended after 4 moves (4 white, 4 black pieces moved) as then the computer started using time for thinking. Thinking took about 10 seconds on this default level.

Me vs. Millennium Orion 1-0:

1. e4 e5 2. Nf3 Nc6 3. Bb5 Nf6 4. O-O Nxe4
5. Bxc6 dxc6 6. Nxe5 Be6 7. h3 Bc5 8. d3 Nf6
9. Bg5 O-O 10. Nd2 Qd4 11. Bxf6 gxf6 12. Nef3 Qxb2
13. Nh4 Bxa2 14. Qg4+ Kh8 15. Rfc1 a5 16. Ne4 Bd4
17. Nf5 Qxa1 18. Qg7#

My move 15. Rfc1 was made by the computer too, as I had managed to mess the turn order because of the tutor mode. After that, I turned off the tutor.

Looking at the game in Stockfish, I made a mess out of it at the very start but the computer did not follow through in this level. (That 15. Rfc1 move was a mistake, too).

It does look like two noobs playing. The game ended with the computer allowing me to checkmate even though it could have been prevented.

The manual indicates there are many combinations of difficulty/time options to make the computer play a harder game. It's just not easy to figure out what the levels are and what level of human play they might correspond to. But I suspect the thinking time will increase drastically on the higher levels.

It's also possible to adjust the play style between passive and aggressive (5 levels, normal giving the best play). Perhaps I'll try to challenge a more difficult level some time.

The computer includes a library of "classic" chess games, including Fischer, Karpov, Kasparov and the Kasparov/Deep Blue games, a total of 320 games. These are listed in the manual but they are not dated. It is unclear if the AI is able to draw any wisdom out of these games, probably not.

(This also means there are more Kasparov than Karpov games stored inside!)

Saturday, 18 January 2020

The C64 Microcomputer (revised post)

The C64 Microcomputer! I didn't get it for Christmas, but it's close enough...

The first physical impressions are good: it weighs more than you'd expect for something that is basically an empty box. The keyboard has a nice enough feel although it is a bit clunky and gives a somewhat "hollow" sound. I wouldn't know how pristine C64 keyboard might have felt straight out of factory gates, though.

Connect it to the wall with Micro-USB style power connector, connect to TV via HDMI. Insert the included joystick using one of the four USB connectors and you can go. The cables are all included.

(The box I think will be used for storing a real C64. A plastic dust cover is included.)

A few seconds after turning the power on, the computer boots into the games carousel mode. So it should be very easy to use. Select a game and play your emulated C64 classics.

Your own software? Simply insert a USB memory stick and if it has d64 files in it, it will be listed in the media menu. Then run the first file on the disk by using one button, or do the LOAD "*",8,1 manually from BASIC in the "Classic" mode. So it couldn't really be much easier.

All the menus are accessible from the one special button on the joystick, which is a surprisingly handy addition to the emulation environment. Whether this means you need to have the joystick connected all the time I'm not yet sure. (Edit: No, you don't)

The menus are clear and have pretty much all the options you'd expect from a consumer-oriented box, but not much more.

The computer can be made to boot directly to BASIC ("Classic Mode"). From the power on it takes roughly 15-20 seconds. But the subsequent resetting & loading new games etc. does not need this time at all. Games when launched from the carousel take only seconds.

The games and music run too fast, and this was NOT fixed by just changing the PAL/NTSC mode. I am guessing that the television goes to 60Hz mode and it is not for some reason able to use 50Hz, as The C64 gave no boot option for it, as stated in the manual.

Edit: Turns out The C64 decides this for itself, if the TV video mode has not been yet initialized. I did a factory reset, turned the TV on properly before The C64, and I got the 50hz/60hz question after boot.

This is a pity as the very same TV is able to show a real C64 image via SVideo! I tried to fiddle the crappy menus of this fairly old Philips flatscreen TV but to no avail. Although the image appears to be 720p video format and the TV should be able to handle in 50hz, it doesn't do it.

So I am still somewhat willing to blame the TV instead of The C64 here.

Which brings me to the slight real omissions. There's no Composite connection so I'm stuck with the HDMI. Also no separate audio jack. For someone else these might not be a problem at all, but the composite video would have been a really, really good feature.

Scrolling seemed to be smooth and tearless whenever needed, but I'd have to make some more definite tests before giving my final verdict on that. I had no problems with the games included. Edit: I tried the Giana Sisters attract mode scroll and it seemed to give no tear or hiccups.

With the Competition Prof-esque joystick I could not really experience much lag with the games, until I really focused on the issue.

Oh, by the way the software offers a variety of aspect ratio/display blur modes so you can get the screen look correct on a widescreen TV.

The keyboard was good enough for typing the above small code snippet, even in the somewhat cramped conditions I had. The shift lock key does not lock physically, but the state is visually indicated in the screen corner. The run/stop + restore combo works.

The keyboard and the PETSCII markings on it are things that clearly elevate this product above a common emulator. The keyboard responsiveness is maybe not as immediate as one could hope, in terms of time between keypresses and the characters appearing on the screen. But at least no typing got lost in the process.

There are two extra fire buttons on the joystick and the 4 extra control buttons. As mentioned, one of them accesses the emulator menu. Funnily, two of them map to Y and N keys and the third to return. Possibly these can be remapped.

My immediate verdict is on the positive side, even if I had some hiccups here. Unlike with some retro products, I don't get the impression this is a cash-grab. It's within a reasonable price and tries to cater to the slightly more advanced users and not just games players.

Yes, for the price you could get a second-hand real C64, but getting all the needed peripherals would likely make it more expensive.

I might get back later with more detailed examination of the features, such as the VIC-20 mode, cartridge files, different displays and the more advanced file-naming and setting options.

Deltaco HDMI -> VGA with audio split (22.1.2020)

The HDMI turned out to be a bit limiting, so I wondered if a conversion could help here.

I bought a cheap Deltaco brand HDMI->VGA converter with separate 3.5mm audio out. I used the VGA to connect it to a Dell display and the audio to a small JBL chargeable loudspeaker.

The Deltaco thing is the black box connected to the blue VGA connector.
I am somehow suspicious of HDMI and especially HDMI conversions, but I was initially pleased that this worked at all.

I also got the speed to 50hz, judging from music playback speed. However, testing the scroll with Giana Sisters it is no longer smooth but a bit jittery and tearing. Sad but perhaps I should not have expected that much from this.

EDIT 24.1.2020:Another edit! So of course the jitteriness is because the display does not handle 50hz, but it attempts to conform to it anyways. However, if I again do the factory reset, connect THEC64 to the VGA display with the Deltaco cable, I get to choose 60hz. Yes, this is "wrong" speed for C64 but at least it was again smooth. Some games might even benefit from it a bit :)

So, it goes to reason if another similar display could handle 50hz the adapter might work fine, so perhaps I should not blame the Deltaco adapter.

*end of edit (goes to show I should have waited a bit before writing the whole post)

Scaling is not that bad, but I had to turn off the CRT scanline emulation as it produced a kind of mild screening artefacts when scrolling vertically.

The picture was not initially centred but this could be adjusted from the monitor settings.

It only now occurred to me to ask, where is the SID selection?

Now with bunch of cables, added visual artefacts and jitteriness, I'm not sure if this setup is so handy after all, compared to the HDMI TV. But, it has to do in a situation where nothing else is available.

Deltaco HDMI -> DVI adapter

This 4€ adapter did not result in an image at all. Firstly, it barely fits with the power cable and the memory stick at the back, and secondly... well, as I said no picture. So I guess even though THE C64 might be based on a 'reduced PC' it can't handle this. The adapter does not have the sound splitter so even if it did work here it would not be that useful to me.

Wednesday, 1 January 2020


Recapping the year 2019 for me, concentrating on the blog angle but as usual some other observations too.

Programming, developing

Again, Multipaint was revised into 2019 version and the inclusion of pull-down menus and file safety makes it much more robust program.

The new ULAplus mode took a lot of time to make, fortunately it was also quite an interesting task to work with. It's not even finished, as it's not obvious how it ought to work.

An entry to the competition celebrating the original compopic
I've come to a point where I get some sort of message about Multipaint nearly every other week. Mostly these are good pointers towards bugs and bad program behavior. Sometimes I get feature and platform requests that I simply don't feel are within the scope of Multipaint, or don't fit to what I intended the software to be.

It's not likely I can or want to make Multipaint fit everybody's workflow, nor will it cover every possible platform. After all I made it for myself to make some ZX Spectrum pictures, everything else sort of grew out of it.

Problems with certain Mac/Java versions still persist, and in the future I can hopefully address these a bit more.

It's now one year after the Commodore 64 Digiloi game release!

The web accolades include "9.9 after 63 votes on CSDb" and "mentioned in an 8-bit Guy video", but I also noted there were print reviews of the game.

As an author of the game, a part of me says "wow, my game is reviewed in a magazine!" Another part of me says that we're really living a weird LARP of 1980s conditions, with different people playing the role of game developers, software houses, magazine publishers, reviewers and it's not always clear whether this all really serves the same purpose as back in the day.

Computer magazines, they still exist
Retro Gamer magazine from Future Publishing was the most "real" magazine (200+ issues, found from newsstands) to feature the game and they had about 2/3 page review, with the pleasant score of 86.

The English version of the K&A magazine not only featured the game on a tape but gave a full spread for the review. Acknowledging some of the problems the reviewer is still mostly positive about it and figures some of the deficiencies could be seen as virtues too.

The Zzap!! annual came later, and although the text is rather positive, they dissected it pretty thoroughly and dealt the rather rough score of 44%.

Jukka O. Kauppinen, a Finnish game journalist legend made a review for the Retro Rewind magazine in his inimitable gonzo style. The Digiloi review goes back and forth from an overview of PETSCII games, reviewing a couple of other PETSCII games in the meantime, and even includes a short comment on the actual game, finally landing on "thumbs up".

Apart from the reviews, I've also read many comments and discussions about the game. It seems more strongly to me now that many are prepared to champion a game they have not really tried that much, or at all.

I tried my best to make it work as a game, but again, as with Multipaint, I made something I'd prefer to play myself. I'm not that keen to play a new C64 game for more than a few minutes at a time or am just happy to see a video about it.

I couldn't find it in me to make another game yet, only the tiny Nine Rings demo showcases some improvements over the Digiloi routines. A scrolling game could be made with the same approach, but that might not be wise from a game design standpoint. At least I have slowly upgraded my 8-bit developing techniques, and perhaps something comes out of this eventually.

The Fall of Rome
The beginning of the year was a bit slow for Commodore 64 graphics, but I made it up in the end with releasing a bunch of new PETSCII images and the bitmap at the top.

My renewed interest into PETSCII was mostly thanks to the new Facebook group PETSCII World, check it out!

Back in Videoland
The major retro hardware acquisition of the year was the Atari Falcon. Updating the hard disk to an SD card reader and transferring software over to the computer was more interesting than doing anything with it really.

So, as a side-effect I got to learn more about Unix and Unix/Linux shells and writing shell scripts. It goes to show that if one gets intensely involved with retro platforms, apart from the intrinsic fun they can also result in learning that may be useful for today.

(I recall that figuring out Panasonic JR200 tape format in 2011 and the QL disk format in 2017 resulted in some practical "computer science" knowledge. Perhaps I'll save these reflections for the 10th anniversary blogpost.)

Speaking of QL, although I also bought the Sinclair QL Super Gold Card clone, it didn't result in that much new QL tinkering. I'm starting to suspect the 16/32 bit generation is just not worth the effort for me.

On another note, Unix-descendants seem to have taken over about everything in the roughly 50 years of their existence, so in the long run learning something about it may be a good investment into the future. I am also slowly building some more server, web scripting, programming and network expertise.

On the more physical side, I've continued building cases and boxes for devices, sometimes out of some perceived "need" but also simply for enjoyment. I also often need new tools for the next work stage, and the collection is growing. This is also going to some direction that I'm not yet quite aware of, possibly instead of casing old computers I'll try to build some Arduino thingy.

Games, Films, Books, TV

I have persisted with chess, with 1000 online games behind me at Lichess, not to speak some over the board games in beginner tournaments and even one park tournament, all in which I performed rather poorly. No obvious breakthrough in play skill has arrived. Although my online rating has improved overall, it seems my play quality suffers nearer the darker season and from other stresses a bit too randomly. A blog post about these experiences is in gestation...

As usual, I read a bunch of science fiction books which I also hope to review in a blog post in near future. The most important might be the Hyperion series by Dan Simmons, a 1990s kind of sci-fi rife with ideas that found re-use in Matrix and even as late as Insterstellar.

To me 2019 was not too memorable in terms of new films and TV. But at least we got to the end of the Star Wars saga, at least from a certain point of view. The technical oomph of Star Wars is somewhat diminished as it has become the movie standard these days, but at least the promise of nine films was fulfilled and I enjoyed this final ride. The new trilogy had perhaps less solid story trajectory in it, as they were rather isolated stories with a fragmented plot.

We had a full year without Doctor Who, but she's coming back real soon.

I hardly ever play the latest games. I finally saw myself through Portal 2, and completing Half Life 2 every few years appears to have become a ritual. But it seems I'm getting closer to the zero moment, especially now that my computer has processor, GPU and SSD updates. It almost feels I've spent more time tuning the thing than actually doing anything with it. Well, can't always be "productive." Completing Everspace took a chunk out of summer, Inside was a short but pleasant spiritual successor to Limbo and Broforce was a nice piece of 2D action candy.

And that's about the most kills I can achieve!
The Long Dark, Virginia and Firewatch introduced me to the 'walking simulator' genre, something that I thought wouldn't care much about but as the games are short they can be rather pleasant. in the browser was nice end-of-the-year snack but after the addictive 50v50 mode was removed (a temporary event) I found going back to the solo mode less appealing.

In 2019, Proton was the key to making Linux a proper gaming platform. I could launch complex games like Elite Dangerous and Prey, but did not really find the time and energy to get into these.

Thursday, 26 December 2019

VNC, ssh, remote, Android, n00b

For the most part I've found ssh enough for connecting over home network, for file transfer purposes. But sometimes it's just helpful to share the screen, keyboard and mouse remotely.

Not every resource is on the same computer, and in the case of physical drives it might not even be desirable. I need to use Processing on the Mac, but it does not properly compile applications over the command line in the way I'd want to, and making Handbrake crunch a video from a drive that only exists on that other computer is a bit handier when you can see what's going on.

Of course on occasions I could just switch the display to show the other computer but then I'd still need to switch between two mice and keyboards.

So, VNC (Virtual Network Computing) screen sharing to the rescue. This needs the viewer software to view the other computer screen, and a server on that other computer that 'feeds' the screen to the viewer.

I used RealVNC's viewer to get the easiest results. With the Mini Mac, the VNC server was built-in and could be activated by ticking one box in the settings.

With Linux computers I found some hurdles, which on one hand might seem surprising, but perhaps really not. Whereas VNC viewer from RealVNC can be recommended, I did not go for the server, as it requires a subscription.

Being a newbie in this, I guess some protocols don't quite fit each other so it's not always obvious which server works with which viewer. Messing with TigerVNC did not produce the results I wanted, although it probably should do the work. Some Linux Mint versions have vino, but it is no longer part of the Mint install since 19, and I'm not sure I ever got that working either.

So, x11vnc as the server. Not sure if all the above solutions actually rely on it in the end somehow, but at least by using this simplest advice I could also connect the Linux Mints together. I rebooted the computer to get the server properly working.

It gets meta as I edit the blog post locally and have an eye on Handbrake converting video on the other computer. VNC viewer interface in the middle keeps track of past connections.
After this the computers can co-operate within the home network without additional hassle.

The Mac may whine a bit about a missing keyboard, but as you input something this will go away.

The keyboard mapping is one thing I've not yet figured out well, as even rather simple characters like _ and @ can be difficult to achieve straightaway, at least when using a Linux to get over to the Mac.

Predictably, video over VNC is not such a bright idea but is kind of doable, at least for the purposes of checking the contents. I encountered a hiccup when using VLC video player, trying to bring up the context menu with right mouse button shut down the screen sharing server. Hmm...

Playing 3D games is even less useful, but I just had to have a go at Tomb Raider from 2013. It was obviously very choppy even in a resized window, but what made it finally unplayable was that the relative mouse motion was not correctly interpreted.

For a while the silly me thought I need to use the IP address for the connections, but the computer hostnames do just as well and better, as the address can change.

Out of curiosity I also checked the situation for the Android Galaxy phone, as the VNC viewer is also available there as an app and works ok. Doing this the other way might be interesting but at first glance at least it seems to be a bit trickier to get the server running on the Galaxy. Arguably the VNC viewer over Android could work as an elaborate remote controller for another computer.

Other Android stuff

Speaking of remotes, the Android app remote Unified Remote (and the download for the corresponding server on Linux) DOES act as a remote way for moving the mouse pointer. I paid a little fee to get rid of the ads and it does seem to work as promised. This might reasonably work as a remote control for that laptop sitting next to the TV.

These softwares don't look very appealing, but you're not supposed to look at them, really.
After somewhat clunkily enabling the server as a browser app (!?) the movement on the Android touchscreen are transported to mouse movements on the target computer. There are also other functionalities such as launching software etc, but I'm not going over that stuff now.

As a hilarious experiment I could use the remote to hover the mouse pointer over to the VNC viewer window, to control the computer where the unified remote server is NOT running.

Somewhat against my expectations, the Unified Remote could not work reliably by having the server directly over the computer where the VNC server is also running. The pointer would fidget somewhat but would not move. Oh, well.

When it comes to having ssh over the Android phone, there is apparently a solution for accessing the Android system directly via cable and the developer mode. But for my purposes I have found it enough to be able to access the phone through wifi and ready-made Android helper apps.

Left: SSHelper server running on Android. Right: Termius, using tiv on another machine to display a png over the command line.
Termius acts as a simple terminal on the Android so you could access your computer with it (after enabling the ssh server obviously), whereas SSHelper is more comprehensive. I suppose it is a minimal linux-within-linux, as it sets up a small server on the Android, complete with a set of useful command line tools such as busybox.

Both have a kind of 'virtual' mapping of the Android filesystem so you can copy photos etc using scp  from the command line, and I had some success with remotely opening the folders through caja too. Nano on SSHelper together with Apple Bluetooth keyboard might be the closest to having a reasonable text editor on the phone.

Just something more

On another remotely related note, the Terminal Image Viewer tiv (from here) is quite good at displaying bitmaps over the command line terminal itself, using unicode blocks and colours to best effect.

A Big Fat ANSI Deal
Sadly it's not able to accommodate for a terminal wider than 80 characters. That might have helped reproduce 8-bit graphics and PETSCII jpgs rather faithfully... again, it's ok for checking a bitmap over the terminal.

Friday, 29 November 2019

Crafting chesspieces

Barleycorn is a common name for a highly ornamented, tall red and white chessmen, elevated on an urn-like pedestal.

One might think the name 'barleycorn' has something to do with the tallness or shape of the pieces, but apparently it refers to the decorative barleycorn leaf motif found on them. So whether a set without the decoration is truly a barleycorn chess set I can't say. But it's a handy keyword for searching a certain type and I'll use the word here loosely to describe mine.

I've longed for something like this, but barleycorns are quite expensive (200 EUR easily for a modest, complete set) so I started thinking whether I somehow could build my own, even if it wouldn't be as decorative.

I don't have a lathe. The main idea was that the pieces could be created by fitting ready-made parts around a central stick, like beads in a string. Visiting a few hobby shops, I looked for ready-made wooden parts that could help in this.

First phase

After I discovered a part that would work as the base for all pieces, I was already more optimistic. I felt a larger set would be more forgiving for inaccuracies, so I chose a 35mm base. As barleycorns tend to be placed much more tightly than any FIDE regulations now say,  a 50mm squared board should be good for these.

I didn't give much consideration to finding larger bases for the King and the Queen although it is clearly a feature of the barleycorns and most chess sets.

Is it a chesspiece or a sci-fi rocket? Here the barrel is cut and filed out of a cube.
I bought a bunch of the ready-made wooden parts I could find from hobby shops, trying to figure out how they might be used together.

After having a pool of parts, it was time to scavenge more definite images of barleycorn-type chessmen from the internet. I did not seek to replicate any one set in particular, instead I picked features from different sets that I liked.

Of course it was important that the details could be recreated with my parts pool. It was a relief to find out not all barleycorns are especially decorative and I could take that as a guideline.

I needed to ensure the 16 pawns would not require much manual work. I'm happy to note this stage was quite successful, as the pawns are the simplest part of a barleycorn set in any case.

Left: a nearly complete queen, Right: demonstrating the stick-system 
Each pawn and piece has a narrow stick as a central axis. This meant drilling parts that didn't yet have holes in them. Especially the pedestal part required some care as it's not easy to drill into a convex end.

All the collars needed drilling too, finding the dead center was a bit tricky. The small brittle pieces break easily when drilling. For the tiniest collars I just had to patiently drill 1-millimeter pilot holes before making the 2,5 mm holes.

Sample of the parts pool. Note the absence of holes in many of the parts.
In the beginning I made many mistakes, often compounding so that some pawns were unacceptable and had to be remade. Poorly supported parts may move as a result of the glue drying process, which I also forgot to check.

I built a drilling jig out of a wooden block which helped in getting the holes more accurate. This became necessary as I noted I really have only so many bases and 32 perfectly drilled bases are needed.

One trouble I had that there really were no parts for inverted curves (e.g. the "scotia" in antique pillars). I emulated these by using a combination of different collar pieces.

With all the easy labor behind me, I begun work on the knight horse-heads. Here wood putty was somewhat useful as the shapes could not be cut very precisely. I was not overtly happy with the knights, but I needed to make progress on this most difficult part before my enthusiasm runs out.

And run out it did. After I finished the four knights and whittled one bishop head, it took a better part of a year before I could find it in me to continue with the set.

Carving the bishop-heads. The white colour is from gesso primer.

Second phase

With renewed zeal, I sat down and whittled the 3 missing bishop heads and started planning the rooks. Here I drew more accurate sketches, because I had lost the sense of the project and the proportions. The rook designs had been previously unsolved, but I had decided they ought to be elevated. (Less common in barleycorn sets but it has been done).

The drawings were useful in finding the proportions for the rook although in the end I improvised some choices.

The tall rooks ought to go without pedestal really.
Instead of forming the rooks out of solid wooden blocks (my first plan) it struck me that with a proper cutting tool I could create the rooks out of 4mm plywood circular plates.

I had seen such a tool a while ago and now I bought it. It's meant for cutting holes into drywalls and the like, so the cut-out is not really the intended product. But it worked well enough with the power drill and the 4mm plywood. The resulting edges were somewhat torn, but filing and sanding them together I got them quite smooth in the end.

I tested each plate size to find out what my options are and then redrew a rook design on a millimeter paper using this knowledge. Only the center part would be cut out of the solid blocks. Cutting dozens of plates was a bit boring, but likeable procedure.

Measuring plates. The leaflet only supplies the hole inside dimensions!
With this tool the central drill was 6mm fixed diameter. This was helpful for gluing the plates together around a 6mm drill bit, but as the 6mm hole was not suitable for the narrow central stick, I also needed "converter" parts. I won't explain this in more detail.

I used the plate-approach for creating the royal pieces too. I was unhappy with my earliest ideas (see the first picture) and chose to do a simple straight barrel that probably looks better.

The outcome

There is something cartoonish about the designs, especially the rooks are very huge, much larger than the base they are standing on. This is not something I've seen in any set, as the rooks usually are not elevated, and when they are they certainly do not exceed the base dimensions.

So I could also make some original choices. Possibly I also felt this cartoon approach gives the set more character than a failed attempt at copying some existing design.

I did not plan the whole set before looking at it all together so it was fortunate the pieces work together as well as they do. But even during the process I could match certain pieces to work together, so it was not all done blindly.

The set is not especially heavy. The king and queen are sufficiently weighty, but the pawns and other pieces are somewhat light and unbalanced. I could help that little with leveling the base bottoms a bit.

Board supplied by Marq, a nice fit.
Small amounts of pieces in plastic bags turned out to be quite expensive in total, so it's very likely I could have instead bought a somewhat battered antique barleycorn set off eBay with the sums! Well, it's more interesting to try to make your own.

There is still some painting to do, and I'll do more close-ups when the finishing has been done.