Digiloi: Action game with C64 default characters

Digiloi is a game I made for Commodore 64, using only the default character graphics (PETSCII) for visuals. For some time I've wanted to use this approach. Fort Django used PETSCII for the backgrounds, but all the gameplay worked with sprites.

There's nothing special about using PETSCII for games, it was done a lot back in the day. However, not many full screen action games were done using the technique, probably because sprites are far more useful and the clunky char-by-char movement was not that attractive.

This visual style is closer to ZX Spectrum game programming techniques, even if the Speccy does not have a character display. Many ZX games had movement restricted to the color grid, with big player "sprites" to compensate. Don Priestley used his unique techniques in Benny Hill, Popeye, Trap Door, Flunky etc.

Left: The old-style forest. Right: UFO attacks

Later, others made fast arcade type games with a more streamlined approach, for example Dan Dare III, Savage!, and Extreme. What I've done is a bit of a compromise between these, an arcade game following Priestley's non-scrolling style but ignoring the more complex aspects of his routines.

I could not achieve 50 frames per second for these big dudes. I wondered if I could stick to 1/2 or 1/4 framerate, knowing that each frame would add greatly to the amount of code that can be executed. I went for 1/3, which is something like 16.67 frames per second on a PAL machine.

I use 256-byte aligned buffers for holding the current screen background and building the screen for displaying. I discarded the idea of double-buffered page swapping routines as the color memory in this mode is fixed at $D800 anyway.

The visuals and game logic are orchestrated like this:

Frame 1:
The background screen & colors, which were built on entering the "room", are copied to the respective 256-byte aligned buffers using speedcode. Copying 2K of characters and colors takes nearly the entire frame.

+joystick poll, music/fx play

Frame 2:
The 8 x 8 character "sprites" are drawn over the 256-byte aligned buffers. Each large "sprite" graphic is stored in 143 reverse-ordered data bytes including color and line-padding zeroes. Some smaller graphic elements, like bullets, are drawn using hardcoded routines.

This uses something like third of a frame, depending on how many movable objects there are on screen.

+joystick poll, music/fx play

Frame 3:
The 256-byte aligned background buffer is copied to the visible screen using speedcode. Again, this is 2K and takes nearly the entire frame.

+joystick poll, music/fx play

During each frame the interrupt plays a GoatTracker SID tune and polls the joystick.

With this approach I balanced speed, memory and convenience. Especially I like convenience. The 256-aligned buffers are quite handy. When transfering the 8x8 character elements to the buffer, the writing address hi byte is INCed with self-modifying code to reach the next vertical line whereas X register handles the horizontal coordinate.

I already think I might have the graphic shapes erased with routines similar to drawing them, resulting in a faster screen clean-up. Also, I probably could use the X/Y registers without having to resort to the INC gimmick. But once I had my routines in place, I kind of prefer the 1/3 because it gives automatically a nice gameplay speed without having to slow things artificially. Convenience.

With the visuals, I took the easiest, black-background PETSCII approach. I noticed that PETSCII game visuals need a somewhat different approach than static screens: The overlaid "sprites" have to go well with the background without too large black outlines. I initially gave the main character a more rounded look as I would do in a picture, but this did not work with the background. I took most of the rounding off.

This not only influenced the character design but the backgrounds too, so there's more black empty space than would look good in a static picture.

2017? Well, um... I've been sitting on it for a while.

The game is pretty much 100% written in assembler, unlike Fort Django, which still had a fair amount of C code in it. There is still a short C scaffolding for initializing stuff, but after kicking off the main loop it's all asm.

I now feel it's not that much more difficult as the assembler can work quite easily with "variables" and tables, and the X and Y index registers make it easy to have array-like structures for game objects. Using the stack to store registers, it's possible to have hierarchical subroutines and sub-subroutines for various tasks and associated labeled memory locations as "local variables" if need arises.

Tools used:

• CC65 cross-development package. This has C and assembler together. C is nice for initializing and testing ideas, though it seems I'm relying less and less on it. The included assembler has some things lacking in the code alignment and positioning department (stuff promised in the manual does not seem to work).
• The text editor included with Linux Mint Mate, Xed or whatever it's called nowadays. Later in the project, I moved to Sublime Text with added 6502 asm highlighting.
• VICE emulator. Obviously.
• C64Debugger from Samar Productions. A neat tool for examining C64 memory content live as it is emulated. This was useful in getting the 256-byte aligned buffers working.
• Marq's PETSCII editor. Not only it is good for creating static PETSCII screens, it does a good job with tiles and animated graphics. I did add custom ordered exporting code, though.
• GoatTracker 2.73. Does the job well and has simple to understand sound fx routines (after understanding them, that is) and easy export.
• Tiled. A friendly enough map editor that outputs csv. It's nice to be able to grab larger entities from the map or the tilesheet and paint with them. The tiles are exported as PNGs from the PETSCII editor straight into a tile sheet for Tiled.
• Processing. For generating some of the tables and converting the Tiled csv directly into ordered room list in an assembler-friendly format. Also, the PETSCII editor modifications are made with Processing.

Commodore Plus/4 conversion note

As the game routine operates most heavily in an invisible back-buffer, there are not that many unique routines and addresses in use. So I could convert the game fairly fast to plus/4 simply by changing the speedcode to point to plus/4 character and color memory addresses.

The joystick reading needed a bit more investigating, but it's not that much more complex than on a C64. I added a keyboard key reading too to switch the music on and off. Sadly, there's only SID support on the sound side.

plus4 version

I re-painted the graphics using the PETSCII editor's plus/4 conversion as a starting point. Some coloring was hard-coded to the source (tut-tut!) but not at too many places. The result is not that different from the C64 original, but it has a bit more shine here and there.

It's more interesting to see that the code runs roughly 30% faster at places, even without trying any plus/4 specific tricks. More could be achieved with plus/4 on this type of game, than on a C64.

I can also see that despite having twice as fast processor, it does not mean a 2x speed. But, certainly the 1/2 framerate might be a more realistic goal even without modifying the routines too much.

*** 28.12.2018 plus/4 addition: The speed-up I'm talking about is not really present in the originally released Plus/4 conversion of the game. I have made a speeded up demo for plus/4 available at the download links below so you can see the game running at 25fps.

However this is a rough-at-the-edges implementation and I have no guarantee it works well all the time. Also, as the game runs faster it may be less playable. The plus/4 is quite a neat computer!


Some reflections

I've wondered why I don't finish more stuff. It's not really about available time.

My projects tend to follow this script:

1. Become enthusiastic about a visual/logical solution for graphics and animation routines, which are at first built with care and reason
2. Start building the game logic with fundamental routines, still maintaining neat hierarchy
3. Lose momentum. Become bored and make new additions without much thought, adding stuff outside the existing hierarchy, generating potential problems difficult to solve later
4. Hastily wrap up. Instead of creating more gameplay & narrative, be happy with finishing the thing

If something disturbs the game within phase 1-2, it's possible that the project never gets completed. If it gets past phase 2, I can at least stubbornly make a finished piece out of it.

One antidote is to try to make the start/game over/finishing logic fairly early on in the project, so it's basically "finished", although there might be a lot to do on the other parts. This is something I did here.

It might seem that more game content would be just incremental work. But again, creating and testing game content becomes increasingly painful as the game gains size. Add a level, it has to be tested. Add a monster type, all the rooms with it have to be tested. Add a weapon, all the areas have to be tested again.

No wonder games are sometimes pre-planned before coding anything. But I find it infinitely boring to try to design a whole game beforehand and then just code it, as lot of the fun arises from trying varieties and discovering things as I go along.

I'm also speculating that fatigue strikes because incremental work stages are boring. The first coding stages often bring an euphoria of seeing exponential results as a result of tiny amount of work or changes.

You'll need a Commodore 64 computer or a C64 emulator to play this game.

Direct download of D64 disk image with Commodore 64 and Plus/4 programs
Digiloi at csdb
At plus4world

Download the prg for the Commodore plus/4 speeded-up demo version here

Chessboard modification

I received a 30cm chessboard box that was in a slightly poor condition. I have a better box in better shape (pictured above) so this was an opportunity to modify the damaged one.

The set is nostalgic for me as I played with similar pieces a lot during my childhood and youth in the 1980s-1990s. I believe these sets and likely the design itself originated somewhere in what was then the Soviet Union, and come in numerous variants and varying build quality. I have no idea how typical these might have been over there.

I am especially fond of the bishops, with no distracting "mitre" or knobs on them.

Admittedly the board is a bit dense for playing, although it looks visually pleasing to me and given the history I'm hardwired to accept this as a normal chessboard.

A board with slightly larger squares could still come handy. The goal at first was to increase the size of the playing squares, but I also became quite interested in the surface treatment.

Half board removed. The amount of dust is spectacular.

The box is 300 x 300 sized, with the original borders it makes the effective play area about 280 x 280 with 35 x 35 mm squares.

To fit this more with my blog theme, I used a Commodore 64 BASIC loop to calculate the measures. So, without the borders the square size becomes 300/8=37.5

The box is slightly deeper than it is wide, so I used 151.5/4 to get the other square dimension for each half-board, which was 37.875. Although this kind of precision is somewhat pointless for my handiwork, it is important for adding up the cumulative measures.

Sanding away the existing squares was the most boring work stage, although the actual sanding likely didn't take much more than 30 minutes altogether. The staining and lacquer treatment requires the surface to be well finished, and I used 80, 120, 240 and 320 grit sanding paper to get there.


Woodstaining

The measure marks were made to all edges of the board, then I used a paper knife along a ruler to pull grooves across and along the plywood. This means that when I brush in the dye, it won't be absorbed over the square edges.

Carefully testing the board, the pieces don't touch the stained parts yet

Still, the brushwork needs to be careful. It was better to allow the liquid to flood towards the edge instead of trying to brush directly along the grooves. Firstly, the absorption effect is quite forceful, and secondly, the brush could also easily touch the other square which would be "goodbye, board" to me.

The cuts across need to be quite deep whereas the cuts along can be shallow.


Lacquer

After letting the staining dry overnight, I applied urethane alkyd lacquer on the surface. One layer of the lacquer was nearly enough to make the kind of smooth surface I looked for. After 24h drying I made a light in-between sanding with the 320 grit paper, wiped out the dust with a moist rag, waited a bit and added another layer.

But after half an hour I dared to test the whole set. (This is still without the lacquer)

Afterwards I'm quite happy with the surface. I did get those tiniest bubbles for both layers. This might be unacceptable in a continuous table surface, but with this kind of checkered board it is not too visible. If you look for them they are there.

Can the bubbles be avoided? It turns out I had not heeded the instructions: the first layer ought to be thinned by 20% and multiple thin layers would be better than 1-2 thick layers. Also, a proper brush might have helped reduce the "bubbles".

Comparing the new width squares with the old.

The paper knife technique has the weakness that the grooves will remain visible. More often than not paints and lacquers tend to highlight scratches, dirt and unevenness, than smooth them out. Still, I don't think these grooves are ugly.

An alternative approach might have been to make a new board layer entirely from plywood and glue it on top of the existing one, this way I could have avoided the sanding. But it would have been a different project.

Panasonic JR-200 emulation

Feeling a bit nostalgic, not only because it's an old computer, but because the early days of this blog was very much about Panasonic JR-200UP.

At that time I had hoped I could code something on the platform, especially as Marq went through the trouble of finding about most of the hardware and I spent time figuring out the tape format.

The lack of an emulator discouraged me, as I tend to code with extremely short build cycles, compiling the code every few seconds almost. The fun and nostalgia of tape loaded binaries fades quite rapidly.

Panyansonic by FIT.

At one point the solution could have been a device that helps transfer the data rapidly to the real computer. Although it showed promise it begun to feel fiddly altogether, and somewhat slow to set up compared to an emulator.

There has been James the Animal Tamer's JR200 emulation that I have never seen running, as it only runs on some Windows version. Also, the scanline/vblank emulation is apparently non-existent. The JR200 quite probably does not have a software-accessible, simple way to track the screen refresh accurately.

The trick is to rig the interrupt to work with the internal timer in that capacity, using an address to catch the currently written attribute, as in the Panyansonic and SR-200 intros made by FIT. I felt the emulator ought to be able to somehow work with this trick.


The Emulator

My emulation project had a few false starts over the years. I had to learn 8-bit assembly more in the meantime and something about how chips work before I begun to have the mindset necessary for building an emulation. Again, I work on Processing/Java.

I did some limited C64 emulation for myself in the recent past, which was a simpler task in the sense that I didn't set the bar very high and there are existing emulators to compare it to. (More about this, maybe, one day).

Left: Incomplete handling of Carry flag at one opcode caused glitching in the SR-200 scrollers. Right: opcode fixed

Here I had to enter the realm of the 6800 processor which is not as familiar to me as the 6502, and hardware that only has been properly documented by Marq, and even that documentation is not entirely complete.

The experience with 6502 was of course very helpful. One early issue was that in 6800, the C flag is treated differently in Subtract with Carry, i.e. the opposite of how it works in 6502. But all in all, the stack commands and how the stack works with JSR, RTS, is quite similar. 6800 stores 16-bit values in HI-LO format instead of LO-HI, which can make things more intuitive.

Over the years I've thought you need to be a genius to write an emulator, but it's not rocket science in the end. To me the key was to make the emulator do something visible in the first hours. So I wrote a few opcodes like INC addr16 and JMP opcode, after which I could already start looking at video emulation.

No joystick yet...

After a preliminary video mode was complete, I made a 256-entry switch-case list that treats each and every opcode as a separate entity. Non-implemented opcodes freeze the emulation and print out the address together with a list of opcodes that have so far been executed. This list can be used to track problems.

As the 6800 is very orthogonal the emulation code could be made much smaller. But it might have resulted in code that either doesn't work at all or works completely, which can be a very frustrating situation. So I guess I'm using an "agile" approach. The downside can be that early errors may be left hanging in some opcodes while rest of the similar instructions work, and these can be difficult to track.

Mind you, the emulation is far, far from complete, which is where the real difficulty lies. For my current purposes it doesn't really have to be complete, as I only wanted to ease the development of JR-200 code, if I ever get interested in that again. So, at least for now, it won't be a public project. I thought if it could run the tiny Nyansonic demo, then all would be well. And it sort of does.

C64 modding on

(Part IV of an ongoing series)

A couple of things have been done to the boxed C64.


Arduino programmer port

The PS/2 keyboard adapter is Arduino-based, which still needs updating. I moved the Arduino USB connector, and added a switch for turning off the power line to the C64, so the Arduino can be programmed with the cover on using the normal USB-B cable.

However I still wouldn't dare hot-plug the thing, but at least I don't have to pull the cable out of the motherboard every time.

Left: The cartridge button, Right: The programmer port

This setup helped me in repairing the keyboard adapter code a bit faster. The keymap corresponds better with my "Deltaco" PS/2 mini keyboard, and it's less prone to freezing. It works fine with many kinds of applications.

I also tried to use one of the alternative keymaps to route the arrow keys to correspond with the joystick 1 directions. You know, if you turn the stick in C64 BASIC you get 1,2, <-, space ... This would be nice as then I could keep a joystick only in port 2 and play those rare 1-port games with the keyboard. And the approach does work, for example, in my copy of Cosmic Causeway and Falcon Patrol 2 the adapter gives excellent control.

But in Boulder Dash and IK+, the approach did not work. This is likely because although the joystick port reading has been (unofficially) mapped to various addresses, the keyboard does not come in with the deal. If the game uses those other addresses, it won't work. Well, a nice idea anyway.


Front Panel Cartridge button

I added a cartridge function button to the front panel. The downside of this boxed model is the cart buttons tend to be too far to operate, so this became a necessity.

The contact wires are pulled back below the motherboard, to the vicinity of the cartridge port, from where they are connected to the cart. This requires a small wiring mod to the cartridge too. The IRQHack64 cartridge has a programmer port with GND, but the other pin needed to be brought out with a separate wire.

Crudeness at the backside. The pins connect the cartridge wires brought from under the motherboard.

As an aside, I transferred a fair amount of one-file game prgs to the IRQHack, and more than 80% of them run. This gives me a more positive impression of this cart than my unlucky first experiences indicated. Even in the cases where the game doesn't run, more often than not I can find an image that works.

I'd like to bring the IRQHack SD-card reader to the front, and possibly change it to normal size SD, but this would be a huge commitment to that cartridge, and extending all sorts of cables might not be such a good idea. Updating the IRQHack menu could be on the schedule too, but that requires some more effort.


In hindsight

All in all, I'm starting to see certain weaknesses in this box layout. Mostly the problems could be overcome with the above additions. It could have been smarter to make the additions to a proper breadbox model, like others have done, but this project apparently isn't entirely about smartness.

At least Chessmaster 2100 can be played with the keyboard...

I now have the more finished product C-keys adapter, but whether I will use it in this project or not, remains to be seen. Having the Arduino here gives more freedom and flexibility, but likely the finished adapter simply works better.

The needed changes point towards a further iteration of the box. I might have been on the right track when I thought about more unconventional board positioning, the cartridge at rear isn't exactly the best place for it now.

Again, more pre-planning might have helped in this matter. For example, a pre-emptive "network" of wires and connectors somewhere below the board could have been useful too, as now each new function needs improvised wiring and holes within the box.

Part I

Part II

Part III

More Scifi bestsellers

Again, a mixture of science fiction books I've read recently.

Frederik Pohl: Gateway (1977)

I played the Gateway computer game way back, but had never read the book until now. Which was a mistake, as the book is rather good.

Humanity has spread to the solar system and discovered the ancient Heechee artefacts, a vast number of starships that travel faster than light. But as the Heechee are not around, nothing is understood about the ships. The destinations are random and guesswork at best. Journeys may take long enough to cause death by starvation, and some launches never return for other reasons.

Which is indeed like a synopsis for a game

High prices are paid to "prospectors", people willing to take up this cosmic lottery, as some of the destinations are huge payoffs, as are any discoveries about how the ships work. A nice outline for a game, indeed!

Pohl describes a kind of ridiculous market ecosystem that has arisen from this exploitation, vaguely reminiscent of the satire in The Merchants of Space. The book cleverly interweaves the cosmic dimension with the protagonists' retrospective reflection in the hands of an artificial psychiatrist.


Robert Heinlein: Starship Troopers (1959)

The intro is rather chilling; the heroes' jet-packed exoskeleton mobile infantry platoon terrorizes an alien city with nukes, incinerating anybody that comes across, presumably civilian or not. Mind you, these aliens are not yet the bugs, but a humanoid culture with technology and language of their own. There appears to be no critical reflection on this act.

The alien "bugs" we meet later, are not just stand-ins for "commies", they are explicitly stated to be an example of communism in the extreme.

One of those books that can justifiably be translated to an FPS

Heinlein also puts anti-Marxist and anti-communists sentiments in the mouths of the mentors. Marx's theory of work is stated to be wrong, as an amount of work does not guarantee a valuable outcome. Instead Heinlein seems to support the idea that all worthwhile things have to be earned. To simplify, the value morality here is that nothing that is easy to learn is worthy. Both individual and the society are tempered through hardships. The pinnacle of this seems to be the kind of camaraderie that arises from military training and bonding.

That's all interesting, but the moral tracts begin to sound like an extremist wishlist though, death penalty for "incurables", tempering our appreciation of freedom through war, and strict military discipline as a road towards enlightened citizenship.

Numerous games and film are influenced by Starship Troopers, there's a Starship Troopers OVA, and obviously there is a game-of-the-film too, one I never played.


Larry Niven: Ringworld (1970)

The story really laces mysteries on each other: Firstly, the reader discovers the human race has developed to the point they live centuries, and are able to transport instantaneously anywhere on Earth. Then we discover that an alien race, the Puppeteers, who have not been seen for centuries, have now appeared with news that have long-term repercussions for the whole galaxy. The reputedly cowardly Puppeteers, for one, are going to leave the galaxy altogether. In the midst of this all, a mysterious massive artefact is discovered in a star system somewhat outside the human known space...

Some passages made me think of Elite (the computer game), can't pinpoint exactly why. At least the Wing Commander Kilrathi are supposedly based on the Kzinti. There are also Ringworld PC games, but I've not touched them.

I also felt that He-Man the original animated series is partly inspired by this setting too, and not only because there's a Teela in both. The easygoing mixture of fantasy and sci-fi, flying cycles and swords makes it feel a bit like an adventure in Eternia.

He was a hero. You could tell. You didn't need to see him fighting dragons. You need only see the muscles, the height, the black metal sword.  [...] He was clean shaven. [...] His hair was long and ash blond and not too clean, and the hairline shaped a noble brow. Around his waist was a kind of kirtle, the skin of some animal.

Ok, so that could be nearly any generic barbarian, but I still think I'm on to something.

The universe of the book is very colorful, with near-nonsensical and comical events juxtaposed with hard science lessons. It perhaps takes a physicist to speculate on the impossible and the improbable in a captivating way.


John Christopher: The Tripods (1967-1968)

Here's a nostalgic childhood favorite, oriented more towards younger readers. The trilogy(!) describes an invaded Earth, where whole generations of people are accustomed to submitting themselves to high-rise sized machines in the shape of, well, tripods.

There's a nostalgic TV series of the Book

The tripods perform a "capping" ritual on people on the verge of adulthood, the cap is a technology that stunts the creative growth of the person's mind for life. As a consequence, people have no knowledge of humanity's past, electricity or even steam power. Past artefacts and whole ruined cities exist, but people are not encouraged to be too curious of these.

The story initially works as an allegory for the fear of growing up (well, it's also explicitly about it). The aliens could again be seen as us, as they behave unto as as we do unto "lesser" beings.

There's an interesting but flawed ZX Spectrum Game of the TV series of the Book

The story hasn't aged too badly, but the position of girls in this boyish adventure, and in the depicted world, is somewhat weird. I could suppose the aliens wanted to enforce gender roles for some reason or other, but why would they subscribe to a human idea of the "fairer sex"?

The broader political message might be about the weight of our freedoms. It appears to the reader the capping affects humanity quite little, whereas it also rids people of wars and perhaps pollution too, given the medieval lifestyle. Most people are not directly subjected to heavy slavery and appear to be able to play a range of emotions after all. This is a point made in the book, too, as the main character is tempted to live a better position than at home, risking the mission at hand.

PS/2 keyboard on the C64

(Or, the Pizza Box C64 part III)

After building a desktop case for the C64, I wanted an external keyboard.

Browsing the web I get the impression that people want to convert their existing C64 keyboard to work on a PC rather than the other way round, but still I was sure I had seen a PS/2 adapter for C64. And yes, there is the C=key Keyboard Interface, but it's quite expensive and not always available.

Then I came across Robert VanHazinga's solution at GitHub, which uses Arduino Uno/Due, MT8816 chip and a minimal amount of parts. Although it seemed confusing at first, after getting to know the chip a bit it is really quite clearly documented and can be compiled easily.


MT8816

As far as I understand it's not really possible or healthy to connect an Arduino directly to the keyboard header pins (the CIA chip in fact). An intermediary chip is recommended.

The MT8816 switch array chip comes in handy, as it can specifically produce a connection matrix (X0-15) out of X-Y coordinates (AX0-AX3 and AY0-AY2). The output is built through setting connections between the "coordinates" and setting the matrix using a combination of DATA and SWITCH. RESET clears the whole array.


Breadboarding

First I built everything on a breadboard at one go but it failed to produce other than random characters on screen and no visible reaction from the keyboard. This was still somewhat encouraging.

I slept over it, had a deep breath and put the C64 aside. I connected the PS/2 keyboard alone to the Arduino and powered it from the PC USB. I saw that on power-up the keyboard actually flashed its LEDs, something that had not happened before. So perhaps the problem had been some kind of oversight with the cables I guess.

I added a routine for blinking the internal LED to see if it receives the PS/2 keys, and sure it did. Sadly I had to remove this internal blinker as it shares the PIN13 which is needed by the software.

Then I rebuilt the setup on that and it worked!

It became quickly apparent not everything was perfect. Testing the keys, I saw that the 1st keypress after any reset always somehow fails. Left and up cursor are simulated and don't work that well with key repeat. Some keys such as pause/brk and prtscr/sysrq messed things up, and also result in a freeze.

Generally,  fast typing with shift, such as typing the " can result in a keyboard freeze. Actually, if I press shift, press the key to get the ", and if the shift is released before the other key, it freezes.

In this implementation F12/reset clears the freeze, which is a relief.

I also noted that with Final Cartridge III, the bypassing of the GUI by pressing run/stop while booting won't work - I suppose the Arduino software and/or the keyboard can't be yet online at that point.

On the positive side, typing with normal keys works and there were no random hiccups or system crashes. I started to warm to the idea that this could work well enough and most of the problems might be software-based.


Building the board

Satisfied at this, for the next stage I soldered the connections on a prototyping board, with a kind of Arduino "shield". The main connection between the C64 motherboard is with a hard drive ribbon cable, which has 20 pins wide connectors. With some more thought, the board could have been planted on top of the keyboard header but I felt more comfortable with the ribbon.

I thought about having the Arduino USB connector accessible from outside, but after aligning the chip, keyboard header and the Arduino on the board, I couldn't get it to where I wanted it so I gave up the idea for now.

Some day I will have some of that glow visible outside.

Soldering the headers and sockets was easy, but making about 50 connections with wire was boring. The composition was a bit too tight after all, which made the work more stressful. The learning from here was that when making a board by hand, I should make generous space for easier soldering rather than try to optimize prematurely.

Even then the board was not compact enough to fit inside the corner compartment of my case, but the middle suits just as well.

The first boot with the soldered board was a disappointment, but after carefully cleaning the spaces between connections and checking the cables I started to get characters out again.


Case fitting and cleaning up

There still remained the task of attaching the PS/2 connector to the case. This was done with a round screw-in PS/2 connector shown below.

I attached it to the right side, near the joystick ports. Behind the computer would have been perhaps more appropriate, but there's very little space there and I didn't want to pull any more cables across the motherboard.

Just about ok for the 3mm thickness

Inside the box, I also needed to cut the center wall a bit to make a passage for the ribbon cable.

For now I did not attach the keyboard adapter board, as I may still need to change it a bit.

For once, a part that behaved nicely.

More to do:

-Check if the software could be improved a bit and fix the keymap to suit my needs
-Paint the case, put a logo on it or something

Pizza Box C64 part II

A followup for my rough C64 case prototype. I came across ready-made 3mm thick, 400 x 300 mm smooth chipboards, and I got an urge to re-make the box already.

(For any DIY-ist out there, I'd remind this kind of case might be considered an added fire hazard!)

This time I put more attention to thinking how the cover would work. I would want to dismantle and assemble the box as often I want, without damaging or wearing out the actual connecting parts. So, although wooden screws would work for a while, they might loosen up eventually.

For this I revived an idea of using flanged, threaded insert nuts for connecting the cover. The major difficulty in obtaining these is remembering what they are called, and not every shop sells the flanged variety. So: flanged insert nut. (In Finnish: kaulusmuhvi)

These are made from zamac, apparently a material similar to what was used in those "metal" toy cars of my childhood. Live and learn.

After sketching the parts on paper I actually bothered to plan this in LibreCAD to study the detail in the millimeter scale. The 40mm interior height was decided on the availability of material in 20mm thickness.

The wooden blocks attached to the top and bottom parts are multi-purpose. Firstly, they keep the top positioned snugly by themselves, but they also hold the insert nuts, which help keep the top and bottom together and well aligned.

Also, the wooden blocks give strength to the corners. The parts are glued together, and with these chipboards the adhesion is not very strong - I could simply pull a part and off it comes with a layer of chipboard. But I'm hoping to get away with it as the box is meant to withstand weight, not tearing apart.


The weight

The thin material brought some challenges I didn't have with the previous box. The enormous weight of the 1084S monitor (in relation to the flimsiness of the material I use) caused some worry.

It's no problem at the front but as the C64 board is near the back I can't put large blocks there without obstructing the connectors. So I kept the space for the board rather small.

Looking at the results of a very complex weight simulation (see above) I also ditched the idea of using rubber legs and added a rigid structure below the box.

These are yet another set of parts that are simply glued together, but if I add enough stuff and wooden corner blocks they'll stick.

The weight ought to be held in check by the vertical "walls". At the same time this structure helps keep the circuit board from bending, as it has been screwed in with 3M machine screws to the bottom cardboard.

Not-to-scale sketch of the section from the side (circuit board in green)

My first test with the monitor resulted ok, the cover does not seem to bend, not even at the backside where the support is not so consistent. Nice!


About making stuff

It's not that easy to make really accurate objects at home, with limited tools and no workshop facilities. But it's not impossible with at least some ready-made parts and some organizing.

These boards are kind of fluffy, not very ideal for drilling. On the plus side sawing with this saw was quite easy:

Razorsaw S-290

The blade is well suited for cutting thin boards and mdf. The front has been rounded so it becomes easier to make the first trace, then start deepening it. Using different blocks and rulers as guides, it's possible to cut very accurate slices.

Start pulling along the ruler

It may seem an obvious point to labor, but if I have a ready-made board with guaranteed straightedges, it follows at least two corners remain 90 degrees after a cut.

I cut the box sides out of separate 400 x 300 chipboards, so all outer walls are already mostly machine-cut.

Perhaps surprisingly, positioning the SD2IEC took more effort the second time round. I cut the SD card reader opening with a paper knife as I was afraid of using a drill, and this took time. I tried to be more clever with positioning the device but ended up making mistakes I had to repair. It stays put anyhow.

The separate keyboard is still a bit of a fantasy. I now have the chip (MT8816 switch array) that would make an Arduino PS/2 keyboard adapter possible. It's not the only option, though. Until next time!

Recent sci-fi reads and re-reads

Out of the blue, some sci-fi books I've read during the past year or so. It turns out I've missed quite a many classic works.


Fred Hoyle & John Elliot: A is for Andromeda (1962)

An adaptation of a now-extinct TV-series. Aliens send a coded message on how to build a supercomputer, which in turn helps build a biological entity, which in turn helps build a more complex, human-looking entity. Possibly an early example of this concept. No crossing the light speed barrier here!

Written at a time when sci-fi writers could fantasize about telepathic powers, transhumanist themes and super alien beings, but didn't know what it would mean to have a really powerful computer. Still, Hoyle is quite clever in proposing a vast 3D-matrix of connections that begins to resemble the neural activity of a brain.

There's also TV-like suspense and silly gender roles. The idea of a beautiful woman as an alien emissary does not quite scan the same way in a book as it does in a visual medium, it's an old-fashioned trope too.


Orson Scott Card: Ender's Game (1985)

After Dune, this was perhaps the most major and widely known sci-fi I still hadn't read. (Currently, this distinction is perhaps held by Larry Niven's Ringworld or Frederik Pohl's Gateway)

Children are reared and conscripted for a hypothetical war fought somewhere in faraway space, against an alien race that has only ever appeared once before. Most of the book-time is occupied with the kids' training, as they engage with zero-gravity sports with ever intensifying and more unfair rules, with some computer hacking and VR-like video games on the side.

As the novel was written in the 1980s the tech is fairly well projected. The turf wars and underlying brutality (and humanity) of children let loose at each other is rather nicely written. The twist ending was a bit guessable, which by no means takes away the impact of it.


Orson Scott Card: The Speaker for the Dead (1986)

The sequel to the Ender's Game continues with pacifist themes. Although a good read, somehow it's not quite as satisfying. The mystery of the ever-so-alien aliens serves as an allegory for the engagement with "other" cultures, a common theme in more anthropological sci-fi.


Joanna Russ: Picnic on Paradise (1968)

One of my re-reads, a short novel I recall I didn't particularly like when I read it as a teenager. Due to an outbreak of war, the tourist planet of Paradise suddenly becomes a very dangerous place. A time-agent is tasked with escorting a traveling rag-tag group to safety, a diverse bunch of tourists mostly unsuited for roughing it.

Here the main story is in the discord between the time-agent, who originates from ancient Earth times, and the people with future social mores, an extrapolation of our own times. Although surely a step forward for feminist sci-fi/fantasy, the heroine is perhaps no longer so unconventional. Yet what remains is still a sense of real physicality of the journey and the "dread from above".


Alfred Bester: The Demolished Man (1952)

Alfred Bester was quite unknown to me, despite being one of sci-fi cornerstones. All the ESP/Psi-themes ever written owe something to Bester (The TV Series Babylon 5 named a character after him). Notably Philip K. Dick's scenario of a future ESP squad in UBIK is very close to Bester's world.

Here the plot revolves around whether and how one could get away with murder in a telepathically equipped society. Turns out you need at least an earworm.


Alfred Bester: The Stars My Destination (1957)

Humankind finds out teleportation is a possibility through willpower alone, but not everyone can do it and not everyone can do it extremely well. The repercussions of this for society are explored in somewhat same vein as the telepathy in the Demolished Man. The gap between haves and not-haves has risen, and corporations run rampant. Nascent cyberpunk themes. Also, drug and body implant-induced bullet time, anyone?

Although I perhaps liked the telepath-society of the Demolished Man better, the narrative drive is stronger here. I'm not a fan of "experimental writing" in sci-fi, it feels like an experiment on experiment, but I'll give it a pass here.


John Brunner: The Shockwave Rider (1975)

Supposedly a proto-cyberpunk novel that influenced Gibson and the like. Phone-hacking and the word "worm" for a computer virus is famously found here.

Some of the themes were interesting and indeed before their time, but the writing quality was not that appealing to me, filled with puns and telegraphed short chapters. There's a lot of pondering about an ideal society, voiced by the main characters, handily with no one around to critique them. At the end we meet a kind of hippie community which further dates the views presented in the book. There's a trace of the hacker ethos here too.

This book is hugely influenced by Alvin Toffler's almost-fiction The Future Shock (1970). One of Toffler's scenarios was that as the pace of life increases, we might go through various "lives" inside one lifetime. Here the main character goes through various different personas and identities given flesh and bone, by the telephone. Lift up the receiver and I'll make you a believer.


John Haldeman: The Forever War (1974)

Comparable to Ender's Game, but perhaps less grand scale sci-fi. The grunts are taken to faraway planets to fight twitch-and-die battles, but time dilation is no joke so the vets will find their home changed a bit after a campaign. Maybe better re-enlist. Before you even get to say "Vietnam-allegory!", I'd say the story works as a stand-in for any war, and this if anything helps make the book enduring.

The term "laser squad" comes up, and indeed while reading I felt this might have influenced the Rebelstar Raiders, Laser Squad and UFO/X-Com games.

Another book influenced by The Future Shock, Toffler even gets a name-drop. The sequence where the soldiers get back to Earth to see how everything has changed, has maybe not aged that well, but it's a necessary part of the story and the point gets across. The military sequences and the grand scale of time dilation become far more inspiring.


Ursula LeGuin: The Dispossessed: An Ambiguous Utopia (1974)

One of the books I read when much younger. The neat thing about sci-fi was I could be entertained with fantastic concepts while introduced to themes like philosophy, alternative social mores, gender equality and political systems, something that I might not have done otherwise. I guess LeGuin's grand achievement was in being able to smuggle in feminist themes to a genre read by young men :)

Two planets, Anarres and Urras, two clearly different political systems and cultures. The other is highly propertarian and capital-oriented, whereas the other has abolished property. Gee, what could it be an allegory of? LeGuin fleshes out the problems of the systems, although also siding with the more gender-equal, socialist Anarres.

For the younger me this was quite a difficult book. I'd like to now say it is a masterpiece, which it kind of is, but it isn't as light entertainment. Which is to say I admit I'm currently looking for sci-fi that has both high concept ideas but also works as stress relief and escapist literature. Or, to put it in another way, I'm currently not too keen to read about a scientist facing problems with publishing papers.

Pizza Box C64

I became curious about what would be the best way to put the Commodore 64 inside a pizza box shape, to save a bit of table room and to have some fun.


Board orientations

Common sense says the circuit board should be tucked away at the backside of the box, but I wanted to explore other logical possibilities too, and bloat the blog post for what is essentially a very simple case project.

1. Board at front, backside to front

The cartridge port and devices would be very accessible, but the front would look messy. I'd have to take a lot of care to make the openings neat and still it would likely look quite bad.

Joysticks and power would be quite accessible at left side. Different connectors and the cables would  eat up table space which is not very desirable.

2. Board at front, backside inwards

Clean front, but the cartridge port would be hidden and unaccessible. Joysticks and power would be highly accessible at right side, near the computer front. Not that bad really, if I am sure I rarely remove the cart. Perhaps the cart buttons could be wired to the side or front.

In a situation like this the SD2IEC could be pulled to the front panel.

3. Board at back, backside inwards

Seems clean all round, but the wires would have to come out somewhere, most likely the back, which would somewhat defeat the purpose of this position.

Pulling some of the cables & connectors to the front would be neat & easy. The cables could compromise the creative uses for the empty space, though.

Again, the cartridge would be quite unaccessible.

4. Board at back, backside outwards

Like the normal Commodore 64 setup, the joysticks and power are at the right. Unlike the C64 they are quite far away from the computer front.

This is perhaps the most preferable orientation, cables are tucked away at the back like they should be, and the cartridge can be accessed even if a bit far away.

Sideways

I also considered some sideways orientations, although I did not expect them to be useful they are in fact not all that bad:

5. Right side, backside inwards

Again, less accessible cartridge port, joystick ports would be awkward at the back. The cables could be pulled out from the backside, which is a plus of this position. 

Also, there would be nothing at the front of the computer, perhaps SD2IEC access.

6. Right side, backside out

Would give the joysticks and power to the front, and extra access to the cart. The cables would fall out from the side which would take room on the table. Depending on the position on the table this would not be that bad, but the power cord and joystick obviously are a bit bluntly at the front.

7. Left side, backside out

The same problems as with 6, but almost none of the advantages. Cables would pour out from the side and yet the cartridge and joysticks would be quite far.

8. Left side, backside in

How about no? Well, ok the cables can again be pulled out from the back but the power cord would come out from a fairly ridiculous point, something that was about bearable in 6.

So, the verdict is there's not that much to improve on the initial idea, represented by the orientation 4. But positions 2 and to some extent 6, did give some food for thought so it's not the only viable solution.

Although 4 gives the idea that the port configuration resembles the c64 mostly, actually 2 has the joystick/power positioning closer to the breadbox original in relation to the front side of the computer.

Did not explore: Upside down circuit board. Diagonal circuit board. Circuit board at the centre of the box (and all 4 variants)

I'm also not considering a tower now although I was a bit attracted by the upright position as inspired by Sinclair Janus(Pandora?)/Atari Microbox/Sony PlayStation2.

Going for size

By the way, what are real Pizza Box sizes? Google says 16" is for extra-large which translates to 40.64cm. This would be enough to house the 390 x 136 board.

I figured dimensions 410 x 350 x 50 would be a good starting point, it's the real C64 width, the monitor (1084) base depth, about the height of the C64C at the highest point.

The above image collects some of the initial ideas about how the box would be sized in relation to the monitor and the things inside. Top image is front and the bottom image is a sort of "section" from the side.

Based on this image I already found some reason to position the board a bit further away from the backside, the legs might get in way of the board.


Building the box

At first, I placed the circuit board over the bottom, to have an idea what of the real size. Then I drew the screw positions with a pencil, drilled the holes and put the board into place.

There are a couple of bolts on each screw so the circuit board doesn't touch the chipboard, and a few of the screws are capped with bolts so the board won't fall out if upside down.

The legs had so short screws I could not fasten them, I'm just hoping they stay put in the drill-holes.

Then I'm just adding the junk chip board all around, using wood glue although it won't have the proper effect as the boards are already painted.

The four-player adapter fits rather nicely here although I did not think about it at the beginning. The board is kept slightly inwards, not because of the rubber feet I was talking about previously. (The feet were much tinier than I remembered)

The SD2IEC is taken out of its previous cover. I would have rather ordered a new SD2IEC, but I was impatient so the cover will have to find later use.

There's a lot of room inside the box, which is one benefit of moving the computer to a larger case. I'm toying around with the idea of housing a Raspberry there, with no connection to the C64 whatsoever.

I'm not going to lie, the material looks awful ugly at the moment:

Some prettification is in order, but it'll have to wait until next time. This was already one session's worth of work for me.

The size ended up as 405 x 300 x 55, so all around slightly different than what I envisioned. It turns out the 1084S base is really less than 300, and not 350 at all. I could still use a less thick top get to the 50 height though. The SD2IEC went to the left side instead of right.

Oh, where's the keyboard? I have already an idea or two, but again, some other day. The SD2IEC interface and Final Cartridge menus can be operated with a joystick, so for the time being this is a limited C64 "game console".

-> Story continues here