Sunday, 31 May 2020

recordmydesktop script

I've used recordmydesktop for grabbing the few desktop videos I need.

It's useful to record a specific window. This requires knowing the window ID beforehand, acquired by using xwininfo.

Remembering and executing this phase is sometimes a bit annoying, so I tried to shorten the process a bit by using the following script. I guess a front-end exists somewhere, though.

After running it, xwininfo is indeed launched but the info is directed through grep to a temporary file. I click on the window I want to record, the output is parsed so that the window ID is passed onto recordmydesktop.

It could be bit more elegant but what do I care.

echo Click on Window
echo using fps 30
xwininfo -display :0 | grep "id:" > temp.txt
more temp.txt | grep -Eo '0x[0-9]+' > temp2.txt
echo $fname
rm temp.txt
rm temp2.txt
recordmydesktop --windowid=$fname --fps 30

I noted that on occasions at least Chromium browser window refuses to work (unrelated to script I think). Recordmydesktop had trouble with the acquired window ID. First I thought it might have to do with detached tabs, but not really. Sooo... maybe just run another instance of it and try again or something.

Saturday, 23 May 2020

Horizontal and vertical dual setup on Linux Mint

I have never really been a two-screens guy, unless you count the inevitable retro computer monitor next to the modern PC.

Partly because there's never ever enough desk space to do that, partly because I've felt that having my eyes wander between two wide screens is too un-ergonomic, and so on and on.

On a whim I noted I could at least save some desk space by having the other screen as vertical. This would also reduce the horizontal eye and head movement.

Reading news sites or Facebook it might be a better layout, as many websites are now designed with a vertical screen in mind.

But it's still more of an excuse to get the second monitor fit.

To me it makes sense to have a vnc window to another computer on this second monitor. No, really, although it does sound a bit silly.

I've occasionally tried running two computers on two monitor side by side, and found that to be more confusing than the vnc. I have more than two computers and so the keyboard/mouse sharing options could get complicated. Plus the other computers might not be stacked physically close to the screen.

So, I could get used to this.

Connecting two screens and changing their orientation is not at all difficult in Linux Mint/Mate. Some challenges arise from trying to do specific things.

The primary monitor is connected with DVI, whereas the other is on a Displayport->VGA adapter. (I don't have a displayport-equipped monitor) The primary monitor is 1920 x 1200 and the secondary as 1680 x 1050 (1050 x 1680)

It may not be obvious that by moving the pink and cyan rectangles changes the way the mouse pointer crosses over to the other screen.

I did encounter some hiccups in the way the icons are arranged on the primary screen. When trying to match the screen positions with the physical reality, some icons went over the top of the desktop and would not "arrange" correctly either.

Drawing with a Wacom tablet on screen 2

Using GIMP window in one screen and tools in another, is not something that works well for me. The mouse pointer transitions between monitors are not ideal and shifting my focus is even less so.

But, drawing on a vertical format on a single screen might make sense in Krita or Mypaint.

Generally I've found my cheap-end Wacom tablet to behave well in Linux.

The first instinct of the tablet device is to map the entirety of the display range to the tablet. Just like if you take a screenshot it will mosaic both screens. This makes sense if you thing the tablet as a substitute for a mouse, but it's not good for drawing.

xrandr can tell the names of the screens (or the ports?) such as DVI-D-0 and DP-2 in my case.

xsetwacom --list devices will tell the names of the tablet devices:

Wacom Intuos S 2 Pen stylus      id: 12 type: STYLUS    
Wacom Intuos S 2 Pad pad        id: 13 type: PAD  

But, instead of using the screen names from xrandr, I found that using HEAD-0 and HEAD-1 work instead. (I've understood this is due to Nvidia drivers. Just in case the above works better I've included the info).

xsetwacom set "Wacom Intuos S 2 Pen stylus" MapToOutput HEAD-1

What still remains is that the scaling is all wrong because the tablet is horizontal and the screen is vertical!

xsetwacom set "Wacom Intuos S 2 Pen stylus" rotate ccw

This rotates the orientation counter-clockwise. "none" and "half" are also possible values. Obviously the physical tablet will have to be rotated too.

After removing the window toolbars it's quite nice to draw on Krita vertically.

After these settings, everything works as I'd expect: the mouse still works across both monitor boundaries, whereas the Wacom tablet is limited to that one screen with Krita.

There is a discrepancy between the color and intensity and gamma of the two monitors, which can be annoying in some situations but I may even need that in some visual tasks, looking at how a graphic might show in different environments.

Launching applications

I recall this has always been a bit off-putting with the Mint Mate dual monitor set up. The thing is, programs don't launch in the correct monitor in a logical way.

Part of the confusion may be that it is all treated as a single display after all.

Some programs, like Krita and GIMP, remember the previous configuration, which is great.

I don't expect to play Steam games etc. in this vertical monitor so that can be forgotten. I already recall this required some fiddling and is partly to blame for my negativism towards two-monitor setups.
Half-Life 2:Lost Coast behaves rather nicely, but the mouse is mapped wrong

But there's really no need to force games, or films, to play on that vertical monitor.

I created a panel to the second monitor with application launchers. This might help with obvious ones such as the terminal window.

Even this information I had to dig up somewhere: The new panel can be only created on a monitor with an existing panel. Drag the new panel to the correct monitor with ALT pressed down.

Using compiz and and changing compizconfig settings does not help, although some of the options sound like they might address this issue.

Looking around, this launching problem seems like a fairly persistent issue with Mint.

I could make this somewhat kludgy script, make a launcher icon run it and technically have my application run on the other monitor:

x64 &
sleep 2; wmctrl -r "VICE: C64 emulator" -e 0,1920,0,1200,1500

But it's not especially ideal either, here the "sleep" period is used so that wmctrl can catch hold of the window.

Should I want to run Vice full screen then it will again switch to the primary monitor. Ok, if I add the -fullscreen argument to x64, the script will miraculously run it full screen on the other monitor, but the pointer will be confined to that screen. Vice seems to do that in any case, so that's the end of that really.

It does not matter to me if Vice runs full screen on a wrong shaped monitor, I'm simply using this as an example of the kind of problems that may arise from this setup if you insist on getting something to run on the 2nd screen.

Going through a lot of software and finding out they don't behave in the best possible way gives a negative feeling, even if I wouldn't really even use those apps on the second screen.

So, the "wrong" monitor launch is not an enormously big deal, more like an annoyance that comes from testing multiple apps. 

Wednesday, 6 May 2020

1541 Ultimate II

Finally I got the Ultimate cartridge for the C64.

Not the II+ mind you, but a second hand version of the II, with the tape emulation add-on and the Ethernet-USB dongle thrown in.

The adapter has the label "NO:usb 2.0 LAN JP208 MADE IN CHINA" and that's all I know of the brand and make of it. It's good to have an already proven solution included.

Firmware upgrade

I didn't really buy the cartridge for the Ethernet functions, but I was curious enough to want it to work. It happened the u1541 firmware was 2.6 and needed upgrading before this would work well. In any case it must be a good idea to update the firmware.

At this moment I realized the Ultimate cartridge, despite being highly rated and professional-looking hardware, has a rather scattered and a bit confusing documentation. Well, it's quite common for any of these hobbyist add-ons. As I got this second hand the docs may have been lacking.

So, an upgrade 2.6 version to 3.07beta needs an update.bin file in the root folder of the SD card (Usb stick is not enough). When booting, the update will run.

Afterwards, I could upgrade using u2u files. (I guess u2p files are for the plus) When I had my 3.4c version going, I could finally see the IP address on screen.

Remote control and file transfers

Now it's possible to telnet to that IP from another computer, using port 23.

PuTTy is fine, but correct settings are needed for display and cursor keys and backspace.

Initially arrow keys or function keys did not work without pressing Control at the same time. Changing PuTTy keyboard settings to VT100+ helped. "Initial state of cursor keys" is "normal".

Local echo and local line editing are both "force off". Backspace is set to "Control-H"

Also, the font did not display correctly despite changing it from UTF-8 to ISO-8859-1:

I fiddled with various settings, but apparently I needed to untick the box that says "override with UTF-8 if locale says so".

After this it started working properly:

The telnet connection is quite impressive and it's nice to have the remote for viewing files in quick succession. The software inside the cartridge does not care what state the C64 is in, so the menu can be operated all the time the power is on.

ftp is also possible, but any attempts to integrate it to caja (the Linux mint file browser) were not especially successful. I could see the folder but file transfers failed. The same with filezilla, a file manager, which seemed so convoluted I wouldn't probably use it even if I found the correct settings.

Instead, I got it to work using command line ftp to the IP address. First use 'binary' to set all further file transfers to binary, otherwise files will be sent with incorrect file lengths. (despite the system saying its switching to binary for the files.)

'ls' gives the remote folder contents. 'cd SD' is likely the first move, to get to the root folder of the drive. Then 'put' puts a file on the local current folder to the current remote folder, and 'get' does the reverse. 'bye' exits the ftp command line.

Apparently the telnet and ftp functions don't mesh together, so you can't upload a file using ftp while "in" with telnet.

Edit: Apparently they could work together, but it's just that messing back and forth multiple times with either ftp or telnet tends to lock the cartridge. A script that sends a file on ftp and launches it via telnet, may work one or two times. This could be related to a bug/oversight in the cartridge.

Some fooling around

One of the main functions of u1541 is the utility cartridge collection. For the purposes of using the cart for running files and general compatibility, the Retro Replay cartridge seems to be the standard.

But there are others, such as Final Cartridge III and my old friend Action Replay VI.

For fun, I did a code snippet on the monitor. (Invoked by MON).

Well, the monitor is in the Retro Replay version of the cart too.

AVI was the original environment where I learned the first steps of assembler in the early 1990s.

For a long time these were the last steps too, because I didn't understand how to structure these programs at all.

Now I see that it would be possible to write long programs using the monitor, giving enough room for subroutines and using a meticulous paper documentation/mapping.

There is another interesting cart, the Turbo Action ROM by Soundemon/Dekadence. This contains Turbo Assembler:

So the same code snippet can be written this way. The source can be assembled by pressing arrow left (the "esc" key, not the cursor key) followed by 3.

After assembling the source, the cart can be reset, and after activating the Tasm again the source is still in place. (If it's not overwritten I guess).

Perhaps this would have been helpful back in the day. However I must say that it would be really painful to write long sources with this one and writing code directly in machine code monitor might even have some advantages compared to an assembler. There were of course various techniques for splitting the code, and in the end it might require the kind of forethought and paper mapping as with the monitor.


The core functions of the cart are supreme and I probably won't look too much back at SD2IEC and IRQHack.

Yet, it seems the cart is trying to be a bit too many things, yet some obvious things are missing (if I'm not wrong). Effort has been put into areas that are not that interesting to me, like printing or some weird audio extensions.

For example, from what I've read and experienced, the cartridge does not seem to allow straight-up transfer+execution of the transferred file. You have to manually launch the ftp-transferred file from the menu. This doesn't sound a lot, but it's an unnecessary step and a more direct result would been better for building and executing code.

This is something the IRQhack could do (although again in a limited way) and I don't see a reason why the Ultimate would not if the software was put into place. Maybe I am wrong and the function is there somewhere.

Wednesday, 29 April 2020

More and more sci-fi

Again, a round-up of science fiction I read in recent times.

Moon is a Harsh Mistress by Robert A. Heinlein (1966)

Heinlein attempts to mix elements from famous revolutions in this story about the Moon colony uprising against Earth governance.

Despite compositing elements from various historical contexts, the views are strongly on favor of a free-market economy, no taxation, individual rights to the point no one is an appointed judge or a lawyer by trade. If you don't anything useful, you die, that's harsh. Well, it might be a true observation about a moon colony.

It is an enjoyable story, but in my opinion suffers from Heinlein's basic mistake of overloading all the discussions with tidbits and ideas on how to govern and rule, what is a good society or not, who is a worthy individual and so on and on.

How can Moon threaten Earth? The catapults are used to deliver cargo, but they also act as deadly weapons.

One of the more interesting parts of the story is the sentient computer Mike, residing on the moon. One day he simply becomes aware and the main character, a troubleshooter called to fix the computer, is the only one who knows this. He gets to benefit from this greatly. In fact the computer is bit of a constantly presiding deus ex machina (literally) without which the revolution would have no chance at succeeding at all.

The role-playing game Paranoia is likely influenced a lot by this scenario. The game setting was a dystopian future with all-pervasive computer who is your friend. The players were "troubleshooters" much as Man is, and all belong to a secret society (e.g. the discussion on optimal "cell" structure of a conspiracy).

2300AD RPG also refers to Tanstaafl, the setting with realistic planetside-interplanetary politics and corporations plays in it too, although it is more diverse and generic sci-fi, with Clarke and Asimov in its genes.

Invincible by Stanislaw Lem (1964)

Invincible lands on a harsh, unremarkable planet with a mission to discover what happened to the lost sister ship, Condor. The ship's not that hard to find but what the hell happened to the crew?

The atmosphere is that of horror without intent on being in the horror genre, and the beginning is already reminiscent of later films like Alien. As the mystery unfolds, the Invincible crew seeks to address the ominous, vague threat, while performing under the somewhat unbalanced command.

The characterizations may seem thin but I also felt the people were quite successfully painted in with minimal strokes. Having the spaceship discipline work much like an old-timey naval operation, works. It also makes this minimalism more relatable.

This book is willing to explain and open up the mystery and the psychological doors a bit more than, say, Solaris, a more complex work. The suspense and dread are distributed in addictive doses.

Hyperion cantos by Dan Simmons (1989-1997)

What I felt was one of the more recent works here... yet it's already 30 years old! I never felt that 1990s was a particularly great time for sci-fi, but looking at this I may have been wrong.

The first book, Hyperion is somewhat muddy, what with the constant bombardment of post-modern references and the lack of an actual story progression. Perhaps somewhat in spite of these intentions, I've found the structure to be more admirable than the surface. Hyperion's and Earth's history, and the galactic political situation becomes peeled through the stories. The later stories bring in explanations to earlier details and give further interpretations to the pilgrims' identities within the earlier stories.

The greatest mystery of course is what are the Time Tombs and what is the Shrike?

I picked the Fall of Hyperion and the Endymion/Rise of Endymion sequels at one go, so I had a rare opportunity to read a series in its entirety. Whereas Fall of Hyperion concludes the story, it also rehashes and repeats a lot of the first novel.

I may have even preferred the Endymion sequels to some extent, as it goes on with a more rollicking road-trip story format. Admittedly Simmons clears away any mystery that was present after concluding the Hyperion.

Concentrating on the single main character instead of the ensemble cast, although refreshing, is not without problems either. Simmons seems to have tried to make a hero that is less scholarly and worldly than the Hyperion pilgrims, but as the story progresses he turns out to be quite the know-it-all.

Canticle for Leibowitz by Walter M. Miller Jr. (1959)

An early post-holocaust novel. After a nuclear war, a community of catholic monks have the only handle on technology and electronics after a wave of anti-intellectual and anti-technical sentiment has bashed everything to non-existence. Not that this handle is much to speak of, as they merely preserve and copy extant documents about technology, with no understanding of how to produce anything new.

A discovery of a fallout shelter with interesting materials seems to point towards a sainthood for Leibowitz, and events start to roll forward to a re-instated future.

I kind of enjoyed the muted humor in this one, despite the over-abundance of monk latin. Amusingly the monks concentrate on making hand-made copies of rather mundane artefacts such as circuit diagram blueprints, the contents of which are no longer understood by anyone.

The book advances in time, and we get to see if the technically civilized people are the wiser the next time round.

Shikasta by Doris Lessing (1979)

(Or let's say, "The Invasion of the Space Eugenists")

Sorry to be a bit wordy about this. This is one of those book I bravely went through in my teenager years. Despite not liking it all much back then it may have made some kind of impression on me. Now, reading it as an adult it was much easier and compelling read, but I'm more able to articulate my reservations about this.

This is hardly science fiction at all (which is not the problem) but a spiritual/inner space fiction novel about cosmic empires taking hold and colonizing planets. There will be no gadgets, tech-wizardry or space battles... okay, there are space battles but they are waved away in a couple of sentences and it's not even clear if they happen in a physical plane at all.

The book initially starts out as a series of reports, written by the agents of the Canopus empire. It's not a huge secret that the planet Shikasta is early on revealed to be Earth (in some sense) and soon, instead of the cosmic journeys in the planet's early past, we are treated to a testimony of Earth's colonialist and racist past through extremely realistic and not to say non-science-fictional vignettes taking place in the present day (of early 1980s).

Lessing's own biography apparently serves as a starting point. The report-format enables the novel to treat long time spans and formative events in a quicker pace, shifting viewpoint as necessary. This is very effective and makes for a sort of prismatic reading. As the pace eventually slows down to support the more mundane events, this enhancement is also stripped off.

Emissaries of the spiritual planes choose to be born into this planet as human beings to manipulate it to their ends. Whereas the evil empire of Shammat brings all the devil into it, seeking to disrupt the connection to the better worlds, Canopus (and to some extent Sirius) bring all the goodness and harmony. Perhaps influenced by the ancient astronaut hypothesis, artefacts such as Stonehenge are remnants of the harmonically built structures of the bygone eons. Early biblical events have their roots in the Canopus-Shammat interferences, and so on.

The problem to me seems to be that although the loosening of Canopus' grip appears to result from breaking the Edenic beginnings, this event is not treated as the breaking of an umbilical but as an absolute malfeasance that needs to be corrected, and corrected it will be. Also, as the breakup results in a horrific catastrophe for the humanity, it appears to me a sign of a bit poor planning from the good fellows of Canopus.

But worry not, the human race will be joined to the Canopian paradise, read: devoid of any interesting culture and perhaps even of free will. Possibly, just possibly, the novel is meant to be read in a critical tone, the reader is meant to ponder about evils of Earth's colonial history and then ask whether Canopus is correct in adding Earth to their blissful Empire.

At some times it feels close to that nauseating idea that the evils of Earth are not a result of human stupidity but an outcome of supernatural meddling. However this is sort of avoided as the "human stupidity" is explored in meticulous detail as the white race is put on trial at the end. Also, the spiritual emissaries are not omnipotent, they are instead straining to keep focused on their intended mission.

But it's still the kind of world-view where youth delinquency and perhaps Punk subculture would work as a sign of corruption if not plain stand-in for evilness. The less eloquent and more crude language the character uses, the more evil they are likely to be. Not that this happens a lot, as the only strong swearword is contained in a Shammatian lackey's message, but it's somehow telling.

I was unaware of the Sufist connection before reading the Wikipedia article on this book, at least the SAWF/Sufi wordplay is lost on the Finnish translation I used. To me the religious undertones made the book seem less timeless. The science-fictional precedents are likely the Olaf Stapledon novels mentioned in the introduction.

Voices of Time by J. Ballard (1962)

Ballard is a big name in new wave sci-fi, but I've not read his works. This collection of short stories is written better than sci-fi on average, but there is also something a bit dull about it.

The stories dwell on desolate environments, with the emphasis more on fantastic or magical realism than science fiction proper. This is bit like Twilight Zone but with less twist endings and more about the tone and poetic sentiments.

Despite having been written before moon landings, there's surprisingly little space optimism in these stories. Astronauts rarely leave earth and if they do, it hardly results in anything good.

Philip K. Dick does come to mind, but although drugs, fractured realities, dysfunctional relationships and insanity weigh heavy in Ballard's text, it is more matter-of-fact and lacks the kind of mental streak that Dick's novels have.

Triplanetary by E.E. 'Doc' Smith (1948, serial from 1930s)

An atomic explosion, sexy agents, nuclear holocaust, a billion-year plot, all in the 20 first pages.

A Lovecraft-induced idea of beings beyond time and space who battle their cosmic war and poor Earth is in the middle of it.

This is an intriguing starting point, but it turns to rather mundane pulp sci-fi. The series, I'm told, is instrumental in introducing the now standard ideas about spacewar with energy weapons and shields, battle formations and such. Star Trek further codified these ideas and gave them a stronger visual form, but it's basically all here already.

If I'm not wrong the early computer game Spacewar! was inspired by Doc's space battles. Also, there's a space battle simulating board game that carries the name Triplanetary. So, the cultural repercussions of Smith's worlds are not to be underestimated.

However the cosmic setting tends to descend into uninteresting spacey fights with damsels saved left and right. Possibly the later sequels redeem this, but with this book I didn't get the appeal of Smith's universe. Perhaps it was more important in inspiring Asimov.

Speaking of Asimov... well, I'll save it for later.

Tuesday, 14 April 2020

Old Machinery Phone

  • RS-232 for all connectivity needs!
  • RCA composite, should you need external display!
  • Ear, Mic, Rem for external tape storage or headphones/microphone!
  • Atari 9-pin joystick/mouse/paddle port!
  • PS/2 keyboard connector!
  • 9V PSU connector!
  • 320 x 200 display + borders!
  • Menu operation / game buttons!
Feel free to build one yourself.

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.