Vammala Party 2024

This was the thirtieth Vammala Party, and Thirty years of Vammala Party. It was also the tenth anniversary for me, and the eleventh visit overall. 

The location is the almost standard Kauppila farm, with good accommodation and suitable outdoors options. The weather was mixed, but not limiting in any way.

The event is not purely a demoparty, one could say the demoscene events only occupy one corner of the whole thing. This in some ways makes it more appealing than many demoparties, but it's also apparent the compos don't have many entries.

The Wild compo was strong as usual, there are even certain traditions and styles observed, which have grown (or in-grown) during the years.

I had nothing to contribute beforehand to the compos, except an idea for the Tuplain compo where existing youtube audio is combined with another video. I combined a slowed down C64 Delta footage with Koyaanisqatsi music. When I have little expectations about winning the compo, I submit something I'd personally like to see, or want to show to others.

The reverse also exists, of combining slowed down SID Delta music with a Koyaanisqatsi clip, but I spared the audience from this as the music sounded rather horrible.

The customary on-site Commodore 64 PETSCII was done, and it turned out ok.

Pals, Commodore 64 PETSCII

Then I began working on a Tic-80 fantasy console image. This I supposed would be small enough to do on location. Yet my ambition grew and I saw the idea would not really fit into that resolution. So, I switched over to Atari ST format and kept on pixeling.

I am working on adding a Tic-80 mode to Multipaint, but the more I understand about it the less interesting it seems. With 24-bit RGB colors, the mode is so flexible as to be almost pointless.

Also, using the two layers, 32 colors could be invoked, and with some tricks I believe even more is possible. So I could almost just as well enable a low resolution 24-bit RGB mode. Meh.

But enough of that.

Pixels in Space, Atari ST, 320x200, 16 colors out of 512

The Atari ST outcome is nice, and although I could see a few more evenings would help a little, the hands are a little lazy and the dithering could be more refined. But there's also a certain roughness I like.

Perhaps using the default Tic-80 palette as a starting point helped take the image in this direction, instead of doing the "one color slide and accents" approach. I'm also relatively unaware what peak Atari ST images look like, so I was not too much pressured by precedents.

https://demozoo.org/parties/5037/

Z-Saw guide "Best"

Saw, guide and clamped piece in place. Angle ruler just for scale.

Quick on the heels of the Z-saw guide "F" I also got this simpler guide, intended for 90-degree and 45-degree cuts. It also promises to help with parallel sawing.

This is smaller, but it's still quite heavy and the instant appearance is that of robustness and high definition.

It's not simple to claim 90-degree accuracy, and I'm not sure if I can ever expect perfection from something like this. For example, there are more expensive try squares that do little else than verify an angle.

Here the removable guide part is more clearly positioned to the the side of the tool than it was with the "F" guide. I feel more confident about that detail. 

Small but effective.

The guide part itself is smaller and thinner, and I'm not certain it wouldn't sway under the forces hand sawing can produce. It's only secured from the top with two adjustment screws.

Even the first time I could more easily do a 90-degree cut. But I also saw ever-so-slightly lopsided result with a 21x45 profile board – better results may require some experience and the right "touch". But at least while sawing 21x21mm profiled rods, I encountered no problems.

There are two blade thicknesses, and switching between the two means altering between two guide parts, which can be hand-screwed loose and re-inserted in desired order.

The other thickness is the same as with the "F" guide so I could use the saw supplied with that guide and attach the smaller blade with the grip that came with this guide.

The guide plate in place, the angle ruler just for scale.

From the manual it looks like I could just press the device against a wood piece and cut. Hence the rounded "handle". I much prefer to use clamps.

It's actually possible to remove the handle part, giving a more straight surface for clamping, but as it doesn't make a huge difference I left it on. Who knows, the pressure might be better distributed when it's on.

Again, doing repeats has to be figured out by other means.

I set a reference rod side by side with the work piece using a try square, while clamping them together. Then I inserted the dummy blade to the saw guide, pulled it down against the reference and clamped it to position. This needs to be done carefully as the dummy blade bends easily.

Pulling the guide dummy blade against the reference rod end.

This way I could get the length to the territory of less than 1/10th of a millimeter accuracy compared to the reference piece. This doesn't sound that bad but actually is rather annoying if you really need the pieces to be of the same length.

For my practical case this was ok, as gluing and clamping resulted in more inaccuracies than my sawing...

But I could do better by using a dedicated stopper. Also, it might be better to rely on something else than the dummy blade.

For the modest gate-like object I'm making, I needed to have 9 equally long rods with preferably no deviation from the 90 degrees. The method I used, this tolerance was bearable and I was pleased enough with the result. Especially the angles appeared to be smooth.

Another way might have been to clamp together multiple rods at once and attempt parallel sawing. Perhaps another time!

The Best saw guide is easier to use for this task than the "F" guide. I'll look into doing the 45 degree cuts later. Is it exaggeration to have both? Perhaps not, as I have no other silent options for making cuts.

Nice enough!

Tool Time: Z-saw precision saw guide F

Piece clamped into position, the saw in place.

Decades ago, as a naive young man, I bought the cheapest possible plastic mitre box and assumed I could easily create wooden frames for paintings. Didn't happen.

Decades passed.

Now, Facebook ads, of all things, pushed this device that might be the ultimate compact hand-sawing assist. It's not one of those space-eating mitre saw contraptions, here the saw blade passes through between aligned metal plates. It's fairly small and should also help in longer parallel cuts.

Apart from that the guide does any angle, compound angles, it's quite easy to apply and the cut is precise and even.

The dual adjustment for vertical angle.

Adjusting the device is a little trickier. Although it's heavy and sturdy, there's no immediate "lock" for accurate 90 degree position. Sure, there are markers but these are far from the kind of definition you'd find in a vernier caliper, for example. For the vertical alignment, two adjustments are needed. 

Just eyeballing the markers isn't enough to ensure proper angle. Either you use the scribe-dummy plane-cut method as described in the manual, or you calibrate the angle against a smooth surface with a really good try square.

The device is somewhat lacking in surfaces for doing such a calibration. The vertical is easy to set, as there's a lot of surface to put a try square against. The sticker is somewhat in the way, and this is a good reason to remove it.

Calibrating the guide vertically. Here still trying to avoid the sticker.

The horizontal is harder to set, as there's even less surface to work with. But it's possible to lower the guide portion below the table surface level, and "pull" the backside of the guide against a corner of a piece that's known to be 90-degree accurate. (Easier said than found...)

All in all, I believe the guide is meant to support the scribing method described in the manual. So, everything needs to be checked before committing to a cut. The process can be either meditative and interesting, or just frustrating.

Calibrating horizontally against a corner.

Two additional items were included in the set, intended to help identify the correct angle. One is an angle protractor. It is a minimalist item, but testing it against a try square it does produce accurate angles.

The second item is a "dummy plane", a .6 millimeter thick bladeless plane for verifying the marked line and adjusting the guide into place.

The whole circular guide element can be moved vertically, by releasing the knob. This is more essential for the angled cuts, but even with a straight cut it can be useful to drop the guide against the piece as the sawing proceeds.

Some of the extras. The 90-degree guide is attached.

There are also a couple of attachments, a removable handle and two guides. One guide helps with parallel sawing, the other is for cuts. With long parallel cuts, it's expected the saw guide moves with the saw as the cut advances.

I'm not super confident about the guides, as their placement appears slightly less than absolute. I'd also recommend using two clamps rather than one, when attaching to a piece.

A variant of a kataba-type saw (backless, thick, general purpose) is included with the set, and as is with these Japanese saws, it operates by pulling rather than pushing. With the way the guide works, a backless saw is a necessity.

The grip is removable and can be attached upside down too.

Another angle, showing the adjustment key at its home.

A sore point here are repeats, which the device cannot really solve on its own. You'd need a fairly extensive jig/guide to be able to do both adjustable and repeated parallel cuts.

There are nice details, the T-shaped allen/hex type adjusting key has a home inside the guide, and it's best kept there when not needed.

Like I said the ground plane of the guide is sturdy, in addition it is easy to attach to tables and other pieces using clamps, especially after removing the handle (not pictured) out of the way. The plane also has enough holes to attach it semi-permanently to a jig.

Result.

A good try square is needed to test if the result is properly 90 degrees.

I won't pass a full verdict now, as the pieces I've worked with are not that precise to begin with. But it does seem some attention is needed to get best results. I could find some lopsidedness in one corner, but for most practical purposes, the wood end is as good as perpendicular.

All in all, I'm more positive about this device as I gain practice. For anyone who has access to electric saw, it might seem slow, but it's better and faster for the job than anything I've had before.

I likely wouldn't recommend this guide on very thick pieces, and some reviews seem to suggest as much. It's logical, the more the saw comes out from the guide, the more potential there is for drifting. 

For my purposes a guide with a rigid 90 degree angle might have been more useful... and I did actually get another, simpler guide. It's early days, but both seem to have pros and cons. More about that in another post.

Tool time: Incra rulers

The Incra set (they have many more models)

Marking/scribing rulers have come some way since I last checked. These are laser-cut, laser-engraved, with built-in templates accurate to sub-millimeters. Although not cheap, they are not dirty expensive.

The straight ruler is the most boring one, and I can imagine only very few necessary uses for it, so I won't focus on that as much. As a part of the set it has a purpose so I don't mind.

The bend ruler markings are only accurate to a millimeter, but the other rulers have a 1/4mm granularity, achieved with rows and rows of offset tiny holes. Here the bend ruler can be complemented with the straight ruler, should more precision be needed.

Bend ruler

The bend ruler, which could be called a saddle ruler, is useful for marking around the corner of a small piece. The end part also helps in scribing parallel to the piece, and finding the centre.

The bend is not in perfect 90-degree alignment, and you have to push it rather firmly against the piece to get results.

The T-square is the most interesting of the lot, and perhaps most versatile. Obviously a straight edge is needed to begin with.

T-Square with some blemishes from my sweaty fingers

The T-square had to be assembled, which made me worry it wouldn't be accurate. However, the parts connect firmly enough. 

Testing the angle wasn't as easy as with a normal try square, as this doesn't work when flipped around. A rudimentary test with marking lines from opposite edges of a machined chipboard looked it would be precise at least in these distances.

To find a centre, it's better to trace from both sides rather than trust a direct reading. This is very simple to do with the Incra T-Square.

Finding the centre from two directions, using the 10mm slot.

A suitable pencil was supplied with two of the rulers. It's worth noting that scribing and marks require some composure and practice, it's not entirely automatic. The pencil tip might be uneven and result in slight inaccuracies.

It may be helpful to decide which side of the hole you press the pencil against, to have more uniform results. I didn't get any problems really.

Some of the ruler positions have slightly diamond-shaped holes, which I guess would help in making the trace more accurately.

The macro lens adds some fish-eye here, the ruler is obviously straight as a rail.

Although these rulers are probably mostly intended for high-precision woodworking joinery. I make rather modest boxes, as can be witnessed from my blog. Even then the added accuracy can help, so they are not going to remain unused.

These rulers are metric, but for through-hole electronics related tasks an imperial set might make sense.

For just doodling around the set would be somewhat expensive, but not as expensive as Woodpecker T-squares. Although I have my eye on some of them too.

Another macro shot, detailing the pencil head connecting with the ruler.

In woodworking it's often more desirable to use repeatable settings and jigs, rather than following markings one by one. Drawing the intended cut and then cutting it, can result in a poor procedure. With hand tools you might not have a choice, though.

Oh, and a ruler can be called a "rule", giving rise to the "Incra rules" pun on the rulers... but perhaps they do?

TIC-80 first notes

Or, the things I wish I'd known instantly when I experimented with the TIC-80 fantasy computer.

Some basics

The TIC-80 can be run locally on your computer, or it can be accessed from the tic80.com website. In any case, running the TIC-80, you will be greeted with a console, which resembles an OS shell. 

No worries, we won't spend much time in here.

EDIT from the console will open the editor.

CTRL+r will run the cart (anywhere). 

There should be a helloworld-style project by default. If not, it's worth looking at because the program shows a few basic things in a very concise way. NEW LUA should create the cart. TIC-80 supports other scripts, but at least if working with the internal editor Lua looks like the smartest choice. 

Pressing ESC exits the running cart, inside the editors ESC will return to the console/menu.

When exiting the cart, you will be greeted with a menu confirming the exit. Here it's a good idea to open options, turn "Dev mode" ON, otherwise the time-wasting menu will pop up each time you press ESC.

If you need to get to the menu and change these options, use MENU from the console.

SAVE mydemo.tic 

Will save the sketch. If you are using the online version, GET mydemo.tic will download it.

Locally, the cart will be saved on a specific folder, which can be viewed by using FOLDER.

Locally, QUIT exits the TIC-80 entirely.

I've had some keymap problems with the local TIC-80 running on Linux Mint, the + key doesn't work directly and had to press alt and plus to get it out. I had trouble with using | and < characters, good luck trying to use logical bitwise operators...!

The *.tic files are entire cartridges which contain all the graphics and sound and map elements you have created using the editors.

Or, the carts might be compared to the Soundtracker-style module format except instead of music data and samples the single file contains everything.

After EDIT you get to the code editor.

Top left corner has the tabs for different editors: Code, Sprite/Block, Map, Sound Effect, Music. Note that clicking Music editor more than once swaps between two kinds of views, the piano roll and tracker.

You can swap between the editors by clicking the tabs, or use keys F1-F5. F6 seemed to switch a scanline display style effect.

Anything you do, is in a way "saved", so if you change graphic tile or a sound effect, the change will already affect the outcome without a separate save command. Using CTRL-z, these moves can be undo'd.

You need to, of course, save the entire project to preserve your work.

Tiles and Map

The Tile editor makes it possible to edit sprites and background tiles. The division between sprites and tiles isn't final, but it is a good idea to respect the distinction at least in the beginning. The default hello-world program uses tiles as sprites.

The palette can be changed but it might make sense to stick initially to the default palette.

You can pick a tile from the grid at right and start drawing on the zoomed-in box at the left. The transparent color isn't decided here, the sprite commands in the code will decide it.

SPR (1,50,50,14,1,0,0,2,2)

Would draw a sprite 1 at the coordinates 50,50, using color 14 as the transparency. The later 1 indicates  1:1 scale, the following 0,0 values decide the mirroring of the sprites and the 2,2 say the sprites is made of 2 by 2 smaller elements. (The element being 8x8, so 2x2 is 16x16 pixels)

You can choose to edit larger entities, such as 16x16, by clicking that rail-selector at top right. This does not change code-wise how your sprites are displayed, it's just an editing assist.

The sprite number is according to the 8x8 scheme, so to draw the blue sphere in the list below I'd use sprite #3 whereas the red sphere is #1.

In the Map editor, you can draw a screen using the aforementioned tiles/sprites. The tile selector can be opened from the top right, and it's possible to grab larger entities and draw with them.

The tiles can be "pipette'd" from the map using middle mouse button, which can be more effective once you have some tiles on the map. Holding SHIFT temporarily displays the selection screen, which is also nice.

In the code, MAP displays the screen you have edited in the map editor. Using MAP (0,0) will display it from top left corner. If you have edited multiple screens, you can access them using e.g. MAP (30,0) or MAP (0,17) or MAP(30,17)

The parameters are also key to scrolling. Simple tile-based scrolling could be done with e.g. MAP (mx,my) and changing the values of mx and my.

To achieve smooth scrolling, you can use e.g.

MAP(mx/8,my/8,30,17,-(%mx)/8,-(%my)/8)

The % is the modulo of the division, meaning if I divide 10 with 8, the 8 fits there one time, and the remainder (modulo) is 2. The 2 will be the pixel offset. 

In the example one screen is 30*8 wide and 17*8 high.

CLS(color) usually clears the screen with a chosen color, but if MAP fills the entire screen and has no transparency, then the CLS might not be needed and is a waste of resources.

Sound FX and Music

By default, the sound FX 0 is a square wave, which can be played from the keys at the bottom of the screen. Pressing SPACE will repeat the last note you used.

The volume curve can be hand-drawn to the top right corner. From the selection of waves at bottom leaft, different waves can be chosen. These can also be redrawn in the green window, but again it might be good idea to stick with the default ones for a while.

Picking from the grid at top left, it's possible to edit different sound FX and play with them.

Using a very short white noise wave (the waves that look empty) can act as snares and hihats, when played at a suitable octave. 

A wave that pitches heavily downwards (using the x16 pitch table) can help create something that vaguely resembles a tom or a bassdrum.

Switching between VOL/WAV at the volume table, the sound can access different waves in quick succession, recreating a "wave table" style approach known from SID editors such as Goattracker. This can also help create more complex percussive sounds, but this requires experimenting.

Changing the SPD/speed at top left determines how fast the FX goes through these tables.

Opening the tracker, the song can play melodies using these above sound effects/instruments. Click the position on the "piano roll" on the right, choose an octave, and your note should play.

On the right side you can check various commands that can be assigned to a note, for example using the chord and inserting values 3 and 7 will play the note as a sort of major chord by alternating the notes very quickly. Pitch, vibrato, etc are available.

At the left side, there is the song order list, which shows that track 0 will be played at song position 0. Four tracks can be played in parallel.

Pressing SPACE will run the pattern once. The length of the pattern is by default 64 slots, whereas the screen can only show 16 at a time. The TIC-80 music editor is not especially good at showing where you are at the track. 

Some might find it more comfortable to change the track length to 16, but then you will have a very short song, as the song editor to the left only has 16 positions.

Clicking the music editor icon again flips between the piano roll and a Soundtracker-style screen, where you can see multiple tracks in parallel.

Pressing 1 within a tracker editor position inserts an "empty" slot, which shuts any ongoing tones. You could also use the commands to turn volume to 0, but you need to change the volume back to 255 for that channel for the rest of the notes to play. So using the volume command for this would be uneconomic and perhaps confusing.

In the code, MUSIC(0) plays the tune. If you just want music rolling in the background of your simple looping demo, this instruction should be done before the function definitions.

Pro Version

I also compiled the "pro version" from sources, and got a working keymap as a result.

More importantly, it's possible to save projects as .lua files. The graphics, sound and music data are included in the lua script as metadata, although in some cases the ordering is rather silly (and different from how the TIC-80 machine stores them internally). But the tiles and maps are quite straightforward.

Getting it to compile was something of a hassle, but it's a little more comfortable to use a normal text editor for handling the source. The TIC-80 window can be kept open and the changes to the file are directly reflected in the opened file.

For some reason I didn't get the "bare metal" Raspberry version to work. I tried variants on 2B+ and 3. There aren't that many experiences and videos online, so I suspect not that many people have worked on it. It would have been fun to try it on a CRT display, and made the TIC-80 feel a little more like a real console.

My Joystick

I had a few arcade-style joystick parts lying around, cannibalized from the iCade gimmick for the early iPad. I felt it was time to finally build an Atari/C64/Kempston joystick.

As usual, every new project needs some more tools or parts I didn't have before.


First experiments

I took some hobby-shop 3mm chipboard and simply began fitting the parts together.

This board was mushy, and when drilling it felt closer to cardboard than chipboard or wood. Besides the messiness, it worked well enough.

Some of the parts

I drew a rough 8cm x 10cm area for the joystick as a sort of minimum estimated fit for the parts inside. At this point I'm not sure how big it is going to be.

Protip: Do the central hole for the joystick shaft first, it will be easier to do the holes for the screws afterwards. Or just be more careful with the pilot hole drilling.

The joystick part has a kind of extrusion at the root of the shaft, which would require a 21mm hole. This caused some woes at later stage.

Here I'm still searching for the fire button positions, not following any existing measures.

Drilling with the 24mm flat head (wrong size)

 Arcade buttons are like icebergs, there's a lot more of them under the surface. So I have to put healthy space between the joystick shaft and the button. This can also make the case very tall.

After drilling the hole for the fire button, I found out I could not fit the part!

It turned out I need a 28mm drill and not 24mm. Not sure why I thought I owned a correct size.

This was the time to throw away the first test piece, I won't even dignify it with the name "prototype". Tiny problems and mistakes accumulated and there's no way I'm going to re-drill an existing 24mm hole into a 28 one.

Second attempt

As I would almost definitely need the 28mm drill, I thought I should get a 21mm too for the joystick shaft fitting. After the purchases I of course found at I did really already had a 28mm drill...

A 21mm flat drill isn't really a common category. 21mm fluted drills are more common, but I somehow suspect I'd be better off with a flat drill here.

A hole saw is a possibility, but the set I used for making my chess pieces doesn't have the correct sizes and I suspect they aren't accurate enough. 

I have no experience of the more robust looking hole saws, but I tend to think these are for rougher work anyway, such as making holes into drywalls.

Adjustable flat drills look a little shoddy as a concept. I felt it might be enough for the few shallow cuts I need, so I ordered one.

The first impression was that it is a rather crude instrument.

A clunky but perhaps necessary tool

I didn't get how to use it at first, the bite was unnecessarily hard, and it is difficult to use the power drill to get anything done.

After breathing in and out a few times, I properly sandwiched the board with a piece of wood, clamped the whole thing and had another go. It's one of those tools that requires a little patience and just the tiniest amount of skill.

First I drilled a normal 6mm hole through the sandwich so the drill/screw part in the contraption itself doesn't get stuck. 

This worked, the only remaining problem was adjusting the blade to 20.5-21mm. The markings on the blade are not especially useful.

It shouldn't matter too much, if the extrusion doesn't fit 100% snugly, but through trial and error I reached a fairly accurate result, after which I don't need to change the adjustment.

It's worth checking the blade really goes through the board and cuts the underlying wood fully, otherwise there's the tedious task of removing and filing away remnants.

The blade and the drill hole need to be constantly cleaned of fluff and dust.

This material is crap for drilling

The result is clean enough, any inaccuracies and muddiness is probably due to the board material rather than any problem with the adjustable flat drill. Still, I suspect there might be better variable drills.

The problem with the arcade buttons is the height they give to the box. They were meant to be installed to the arcade cabinet, after all.

I already became a little tired with the project, and continued when I got better parts and materials.

Some time passes: 3rd attempt

Here I switched to 3mm MDF board, which results in far more accurate cuts and less "fluff".

The 21mm hole was still a dirty process with the clumsy device.

Ahh, nice and smooth MDF

The 28mm blade was excellent, the bite was just perfect and it didn't take long to push through the 3mm thickness, using a 6mm pilot hole.

It's easy to overestimate how things fit in a small space, so I headed for a larger rather than smaller box. I can make a new box some other time, if necessary.

I ordered shorter arcade buttons, so these no longer determine the height of the box. The stick mechanism is now the tallest piece inside.

I ended up making a 151 x 115 x 42 box.

Putting the box together is a little tricky at first

The 4 screws next to the joystick are 3mm machine screws, there are also two more connection points that can be used.

I glued the outer walls together carefully, without applying too much clamp pressure. This is a precarious moment in this method, but it's also easy to move the parts as the glue isn't too quick to dry.

I don't favor superglue/glue gun approaches as I feel the results are either brittle or messy.

Another layer is added, at the same time giving a sort of rebate for positioning the case bottom. I used some more clamp pressure here.

The project is moving forward

Small slices were added to the corners, giving some substance for screw holes. Again, these slices are clamped together using glue, so the overall package should be quite sturdy. I still suspect the box might give up if it fell from a table at a vicious angle.

The 9-pin cable is from a dead Tac-2 (and believe me it is dead). I'd prefer to create the cable from new parts but this will have to wait for another time. At least the joystick cable has the nooks to keep it firmly attached.

I added a tiny protoboard piece with the necessary soldering for a "ground rail" and a pin strip for continuing the U-D-L-R cabling.

This way I can still alter the configuration.

No matter how simple the project, all elements ought to be have some planning beforehand. The cabling is a little messy but with some luck everything fell into place well enough. 

The box is then shut with the cover, using four small countersunk screws. This solution doesn't use machine screws and bolts, I don't expect to open and shut it many times.

After some minimal sanding and filing of the sharpest corners, it's off to testing.

Some of the tools used.

First games

I took the stick over to my Arduino USB adapter and played a few games on the C64 emulator and Mame. At first I held the joystick on my lap, as the box didn't have rubber feet.

Instantly I can feel the iCade-sourced joystick isn't that great (it wasn't back then). Despite the microswitches there is something ambiguous about it, and it occasionally feels like gears grinding each other. (Edit: Some WD-40 improved it a little.)

In addition, at least to me proper arcade sticks don't work as well with Commodore 64 games, where I'm used to the Tac-2. I'm again looking at games with crisp controls, The Great Giana Sisters and Buck Rogers. After playing some more I can get used to it.

Things felt better with ZX Spectrum evergreens Bruce Lee and Saboteur. Many Spectrum games are a little sluggish and more lenient to begin with. Simulator-type games, such as Elite, are even slower, but for other reasons these are often better played on a keyboard.

Moving over to arcades, Mr Do's Castle and Commando (mind you no grenades) on Mame already felt a little better. It's closer to how it's supposed to feel, if only the joystick part was better.

The final touch for now.

The box makes the microswitches sound quite loud, but that might be another failing of the stick part type. The buttons are more silent.

It remains to be seen whether I need to make another, "final" prototype, or if this is enough after adjustments. I can look at making it more gentle on the hands, and maybe damp the sound somewhat.

Electro Boy clock/automatic timer

A fleamarket find, I had a hunch it would work even without any promises.

Grime made it looked worse, as if the plastic had melted at places but all wiped off nicely. 

It's not any kind of collectors item, I paid 2 euros and I'm seeing them going for similar prices in eBay. Boxed and with manuals it might fetch some more.

I didn't think much about the weird clock face and the fact it has an outlet for plugging in another device. I thought it was a cool-looking clock from 1960s/1970s. 

But it's not just a clock but a timing mechanism with on-off switches around the face.

From what I've seen, electric timers are usually sold separately as add-ons to the electric outlet, without any actual clock dials.

I've now learned the Electro Boy brand from Muller is quite old and there may be devices with similar function already from the 1950s. The one I have is most likely from 1970s, and from what I could find there are at least white, yellow and black varieties of this same model.

There are 96 separate switches, giving a quarter-hour resolution to the timer.

The knob in the middle adjusts the entire time. You can't separately turn hour and minute hands. Also, you can't lazily assume AM or PM, as the timer hand is in 24h format. The adjustment is pleasantly tactile and audible.

The clock in action is very silent. I'm generally annoyed if I can hear the tic-toc of a mechanical clock, but here it's really subtle.

In contrast to this the relay inside is quite noisy, I wouldn't want to be sleeping nearby when it switches on. There's a single button on top of the clock to override the switches.

The timer switches caused a few moments of head scratching. I've understood you usually create "zones" for on and off time ranges, but here each switch acts as a flip-flop. So you only change two switches to create a time range. This may also pose some limits to how the timer can be used, but I didn't go out of my way to test different configurations.

Turning switches on very near the 24h hand doesn't often work well, and trying to push the hand past a set switch (for testing purposes) feels a little suspect too. The device works best when the time is set knowingly well beforehand.

The clock invites romantic notions of an electro-mechanical "smart home" before the internet era, as it looks like more of a household item rather than something for the workplace/garage.

You know, in times past, people would wake up and move physically to their workplaces, as if parts of a huge clockwork. As your alarm rings, the porridge and coffee would already be heating up.

It's unlikely you could use this for activating an oven, but perhaps a separate cooktop, toaster or a water heater may be turned on before the alarm clock (separate) would ring.

Or, turn on a separate radio and also make it turn off as you've left. This is already something many later alarm clocks would do anyway.

I did test an USB mini-fan, but then preferred to operate it with a more current timing mechanism.

I'm thinking of a scenario where the clock turns on an Arduino or a Raspberry Pi, it does something for 15 minutes, and is shut off. From a power consumption standpoint it might be better to use a low-power Pi directly and have it on 24h...

So, ultimately, it might be best to use the old Electro Boy as a cool-looking clock.

Industrial electronic timers and timing computers are still produced under the (Hugo) Muller brand. Based on their website this became their main product in the 1980s.

Star Wars prequel Novelizations

Here is something I never thought I'd ever read, yet here we are.

The stories aren't that amazing, but I wouldn't blame the novel authors for that. My understanding is the books were written prior the films' releases, so the authors had access to visual material but certainly not the entire films.

Then again the scripts might have events and dialogue that were omitted from the films at the last moment, giving rise to the idea that known deleted scenes would have higher "canonical" status due to their inclusion in the films' novelizations.

Oh, and it's been a while already, but Disney decreed these as no longer "canon". B-b-but these are official film novelizations? It should teach people not to trust any such labeling, or preferably, forget the whole idea of canon.

Terry Brooks: Star Wars: The Phantom Menace

The story doesn't start with the Trade Federation ships in vicinity of Naboo. Instead we're with Anakin the wunderkind on Tatooine. We get to see what he was up to before he appears in the film, and what kind of life he lived.

Whether these pre-prequel materials are based on something Lucas left out of his film, or were invented by the book author, I don't know.

In any case it's a good choice to have the story from Anakin's viewpoint, fleshing out the character a little more.

With the huge entourage moving around, the storytelling occasionally needs lists like "Anakin, Artoo detoo, See-threepio, Jar Jar and Padmé went this and that way", something that works more economically on film. Book-to-film transitions often reduce the amount of characters, but here I'm wondering if leaving a few out would have done good. 

Characters such as Watto and Sebulba, despite having descriptions of sorts, also remain unclear. Well, the films didn't flesh them out much either, but their appearance spoke volumes.

Star Wars might be considered "visual sci-fi" rather than science fiction proper, and stripped of this quality the story is lacking in science fiction of any kind.

After seeing the film, the book may feel like an improvement, especially where the text can include more helpful explanations and character inner motives, giving a little more clarity and purpose to the plot. 

Qui-Gon is more explicitly made to sound like a rebel Jedi, with by-the-book Obi-Wan having no clue as to why Qui-Gon would ruin his career so. Kenobi's a little like a PhD candidate just about to finish, thinking his supervisor isn't all that.

It's more apparent that Anakin continuously pines after his mother. Future events are in some ways better prepared, with Anakin saying he will eventually marry Padmé. You can also try to imagine Anakin just a little bit older.

What about some of the things that stuck out like a sore thumb in the film?

Jar Jar Binks in literary form isn't as annoying as his cinematic counterpart. Still, a lot of effort has been taken to reproduce his antics faithfully in text.

The droid army is more sinister as they don't go bumbling around shouting "roger roger!" In fact the regular droid troops say nothing all, possibly the literary form does away the need to personalize them in any way. 

Anakin's seemingly accidental assault on the Trade Federation ship has some more explanation behind it, and made to tie in more explicitly as evidence of him being the Chosen One. Tonally, it's still a kid destroying a battleship while yelling "whoopee!" while doing it.

The book doesn't offer a radically different interpretation to the events described in the film, but then again who'd expect that from a novelization.

Brooks famously wrote the Shannara series of fantasy novels. I once tried reading the first one but circumstances prevented me from finishing it.

R.A. Salvatore: Star Wars: Attack of the Clones

Padmé Amidala is to represent Naboo at the Galactic Senate, to vote against the Republic founding an army to counter the growing separatist faction. Continued assassination attempts force her to return to Naboo, but not without the Jedi Knight Anakin Skywalker as her guard.

Again, the beginning of the book describes events prior to the film.

In this case, it's Shmi Skywalker, Anakin's mother, and the book gives details about her life with Cliegg Lars on Tatooine. Owen and Beru are also involved. We get more insight on how Shmi gets kidnapped by the Tusken raiders, how Cliegg lost his leg and why the farmer community could not be of more help.

Anakin's inner life is again described more, which actually doesn't make the romance portions much better. What does work are the parts with Padmé's sister and family on Naboo. This was quite interesting and added a further dimension to the relationship.

It was also amusing to read more about the interactions between the kid Boba and his father Jango Fett on Kamino. Jango is nothing but a proud father of the future best bounty hunter in the galaxy.

No less than five planets are featured: Coruscant, Naboo, Tatooine, Kamino and Geonosis. I never gave this much thought, but no wonder the story seems a little incoherent.

When the narrative turns to the finale on Geonosis, the prose becomes more minimal, almost to the point of being curt, with only little added detail. I'm wondering if anyone who hasn't seen the film gets what kind of world Geonosis is, what the war equipment and the clone troopers really look like.

I found this interesting:

[Count Dooku:] "And let me remind you of our absolute commitment to capitalism... to the lower taxes, the reduced tariffs, and the eventual abolition of all trade barriers. Signing this treaty will bring you profits beyond your wildest imagination. What we are proposing is a complete free trade." He looked at Nute Gunray, who nodded.

The separatists are not a veiled allegory, they are explicitly stated to be free-trade capitalists. Although the name "Nute Gunray" is known to be a composite of Newt Gingrich and Ronald Reagan, the scene perhaps also echoes Hitler's promises to the German industry.

There's a central mystery to all of this, but as nothing is really revealed in this installment, the threads are just left hanging around. Obi-Wan even comments on occasions how nothing makes sense, and I'm not sure if it's a meta-observation or not.

Count Dooku is a stand-in for the main villain, but as he features very little his characterization and motives remain unclear. The added material does little to remedy this problem, although it is fun to read about his lightsaber technique.

The overall plotting is something like this:

–The Sith Lord, who is not yet revealed, is pulling the strings at every possible stage.

–The Sith Lord is out to discredit the Jedi order entirely, and like a parasite picks up the Republic as the platform for power. The separatists are a bogeyman concocted to create disarray, bypass normal laws and to advance to a power position through technically legitimate means.

–It is the Sith Lord who ensured both the droid army and the clone army would be created.

–The Sith Lord is behind the assassination attempts, yet also ensured that Anakin and Obi-Wan would guard Padmé.

In absence of any other explanation, it's possible the Sith Lord made sure that Anakin alone would spend quality time with Padmé and had Obi Wan follow a breadcrumb trail to the discovery of the clone army, leading to its adoption.

Just to draw a line somewhere, I find it less credible that the Sith Lord fomented the Anakin-mother relationship, arranged Shmi's torture and the ensuing nightmares (such theories float around).

Rather these events were useful raw material for directing Anakin, and generally I find it more likely the Sith improvised and used emerging situations rather than planned everything beforehand.

A villain having a complex plot isn't always a great recipe for a movie plot, and despite the brave attempt it doesn't become much more compelling in literary form.

Salvatore is also an experienced fantasy author, with Star Wars novels in his resume.

Matthew Stover: Star Wars: Revenge of the Sith

This novel is held in high regard (see here and here) so I also had high hopes for it. In fact this was one motive for reading the whole trilogy.

Stover takes far more liberties with the dialogue and detail, that's for sure. You feel you've almost read an entirely new interpretation, and not just something that retells the film with extras.

I was surprised that on the whole I didn't really like it more than the other two. I felt the author takes perhaps too many of those liberties, reinterpreting events using prose thick with bombast and references to other Star Wars media.

There are certainly some fun storytelling devices. Unlike the film, much of the rescue operation at the beginning is told from Count Dooku's perspective. He then doesn't mention silly things like R2-D2 setting droids on fire, and the hijinks in the lift are mentioned in passing, as something not worthy of note.

It can get little dense. There's a page (63 in this version) that makes no less than five references to Star Wars lore not actually mentioned in the prequel films, beginning from the worlds of Aargonar and Jabiim, name-dropping mynocks and Asajj Ventress, ending with a Krayt Dragon simile. Instead of pulling me into the world, it makes me wince like a Jawa trading a Bantha to a Wampa.

Dialogue and scenes are often greatly extended and modified from what must have been available even in the script. At the crucial moment Palpatine offers Anakin whatever his heart desires, there's a weird escalation as Anakin plays along and says first he wants a speeder.

Ok, I would have wanted to have this scene.

But it's not only about writing style. I disagree with the very idea that Kenobi's and Skywalker's heroic deeds are distributed to large masses via some supposed interstellar Holonet, leaving an impression on an entire generation.

If there's a space internet, I have to ask how are Jedi relegated to an "ancient religion" and barely known after 20 years? If anything, novel writers ought to have found ways to explain how the fame of Jedi diminished.

The novel must be the main distribution point for the theory where Emperor's deformed face is supposed to be his original Sith face. Any other appearance would be a mask or an elaborate disguise. The idea is presented vaguely here, but many take it seriously. No, just no. It's a stupid idea. Forget about it.

The author makes references to Tao Te Ching, as phrases such as "hope is as hollow as fear", "darkness within darkness" and "what is a good man but a bad man's teacher?" pop up here and there. It might even be the Stephen Mitchell translation specifically. Also, some of the scenes describing how Force "feels" to its user seems derived from Taoism, through western eyes at least.

This is another interesting idea. The Star Wars films are famously inspired by Samurai films and probably Wuxia too. Now this is a book, so why not take some eastern literature and philosophy in the mix? But it's one more of the liberties taken with the source material.

Revenge of the Sith is certainly a wild ride, brimming with ideas, ups and downs, hits and misses, and I can't help but think it would have been better had it been toned down a notch.

Multipaint 2024

Another year, another version. Making the cut between the "annual" Multipaint version is a little arbitrary, but I think this year there's some cause for this.

For once, the new Multipaint should be a little faster than the old one. This is largely due to using a more Processing-friendly way of rendering the target platform screen as an 1:1 bitmap first and then scaling that using Processing's own image() capability. (Processing is the Java-based environment in which Multipaint is programmed in).

Pan and preview window

For panning the screen around, no new redrawing is needed on the target platform level, making the pan and internal pseudo-window handling (palette, settings) easier.

Previously I felt the non-magnified viewport should be fixed, connecting Multipaint with old programs such as Deluxe Paint, Degas Elite or Art Studio. But it did cause some clunkiness when zooming in and out near the screen edges with mousewheel.

Now I think it's possible to have my cake and eat it too. So, even if the 0-level screen can be panned by middle button drag, if you use the old fashioned magnify tools you might not even see it happen.

The overhaul also streamlined the viewport drawing routines and refreshing the screen. This may open up some new possibilities for handling the screen in the future. The border is no longer "infinite" and there's empty UI area outside the border.

Huge preview window, and free panning demonstrated

Having mentioned the pseudo-windows, the Preview window is now a properly detached, separate window, which displays the target screen contents in either 1x or 2x pixels, and in a more correct aspect ratio. This was a solution that has worked well without problems in Marq's PETSCII editor, so I finally dared to use a similar approach here.

There's very little to prevent me from enabling the more accurate aspect ratios in the main screen, but I still have a hunch it's better to keep pixels in integer proportions, as scaling can produce ugly artefacts.

Processing 3 and Processing 4

Another issue concerned moving over to the newer Processing 4. This shouldn't be a huge deal, as the same source now appears to work in both without changes.

Some reports have been trickling in of Multipaint again not working in some Windows or Mac configurations, whereas it appears a Processing 4-built application might work in these situations.

However, the Processing 4 -build requires OpenJDK 17 or higher. At least the creators of Processing have now made this very clear. In the past I felt it was slightly uncertain if OpenJDK is even fine and if so, which version to use. Or I simply couldn't be bothered to find that info.

Because it might be a chore to get OpenJDK 17 working, and your old Multipaint works fine, I still offer the main download as a zip with Processing *3* builds. The Processing *4* builds are in a separate zip available on the website, in case you feel the old Java/Processing is the problem.

Edit: In Linux Mint you can simply open the Software Manager, search for "openjdk" and choose to install for example Openjdk-21-jre. After this, the P4 version of Multipaint should work.

Sadly, as progress moves on, older computers might no longer have meaningful way to update Java or OpenJDK. Acquiring a cheap/free recent enough Linux laptop shouldn't be too hard, though?

Processing might eventually have an end-of-life too, but at least they still bother to chase the recent developments.

Big screens, small screens

With the improvements above, I was quite happy to use even a maximized app window on a 2560x1440 display. But as usual, it may be your xxxtreme graphics workstation with super-high resolution doesn't provide the best environment for Multipaint. I would still suggest not maximizing the window.

At another end, after freeing the panning, coupled with better GUI scaling and the preview window separation means that on a small-resolution screen (~1440x768) you might be able to find more helpful window positions. For example, the Multipaint main window could mostly serve as a magnify window, while looking at the Preview window for overview.

Main window and preview window side by side

I did fiddle around a little with Raspberry Pi 400, Multipaint does work on Raspbian OS and it is reasonably possible to draw using it. I wouldn't use a large desktop resolution, as a huge Multipaint window slows things disproportionally. Conversion tasks, both from files and in between modes, are also quite slow.

On Raspbian, the file selector may look horrible, the worse the higher the desktop resolution, and I may eventually adopt Marq's choice from his PETSCII Editor. It is generally better and seems to work on Raspbian.

Unique Character count, "UQ"

Unique Character count was added to the C64 multicolor mode, just to test see how Multipaint could help in creating character graphics. The feature request and testing was done by Shine.

At the infobox, UQ: displays the number of unique characters in use. Multipaint checks whether the screen would work as a multicolor character screen, but doesn't understand the mixing of hires and multicolor modes. If there's a problem the infobox will just bluntly say "UQ:???" and you have to figure it out. 

The multicolor character mode has three separate global colors, and each character area can have one more color, just as long as this color is from the range 0-7.

It might make intuitive sense to use global colors from the 8-15 range, as you cannot reach them from the per-char color. However, many images and games still use 0 (black) as global color to have more freedom to combine the 1-7 colors with black.

This screen uses 75 unique characters, the three greys form the global colors (screen bottom)

Although the multicolor screen background is always selected manually, UQ estimates what the two extra global colors might legally be (shown below the selected colors, among the global color) and understands the use of 0-7 colors in character-by-character basis.

This is also partly the reason the feature can't (yet) be more specific in showing where the "mistakes" are, as it's a little tricky to make a difference between "you messed a global color" and "one of these characters doesn't work".

The character idea might not fit that well with the Multipaint philosophy of drawing single standard bitmap screens in simple way, but there it is. I felt the routines might serve more generally as a rudimentary packer, or for creating modes that have character limitations built-in. The long-coming Panasonic JR200 mode springs into mind.

UQ may be improved in the future, and exporting as a character mode screen should be a possibility.

Other enhancements

At the tail end of Multipaint 2023, I added the ZX Spectrum Next modes. The bugs and even the occasional crashes this addition created, should be fixed for 2024 version.

I added some Commodore 64 goodies, mostly things that work under the hood. Loading in a PNG file that contains standard C64 graphics in 320x200 resolution should now work better.

Multipaint can have a hunch of what kind of palette has been used, and make a good guess of what the background color should be in multicolor mode. This is simply achieved by converting the same image 16 times(!), to see which of the background colors produces the least "lossy" conversion.

As before, a really non-ambiguous border around the 320x200 area will be cropped, and this has not been improved in any way.

Still, the conversion engine is not that great and I have no big intention to develop Multipaint into a generic conversion tool. But as I said, it should load C64 images more accurately from PNGs.

This also affects the internal conversions, switching from other modes towards C64 may produce better color identification and a more useful background color in multicolor. This is especially important if using the C64 multicolor "free" mode to create something that works in another background than black.

Opportunities for some tiny UI fixes always arise. Just a couple of examples: If the magnifying glass tool is currently on, the mousewheel zoom would behave erratically, now it's cleaner. You can pipette the border area and get its color that way.

The Future

It's already more than ten years since I started Multipaint, although the first public release was at 2016!

This version shortened my to-do list somewhat, but there are also long-standing issues and omissions I could not yet cram into this release. Usually the major Multipaint release gets advertised a little more and I will find out the changes broke something or didn't quite work as intended, and this will take some of my time.

Despite the messy and sprawling nature of the code, I still have a pretty good grasp of how it works and how to do changes to it. I have a good idea of what can be fixed quickly and what needs a more dedicated effort, and what probably isn't worth trying to change anymore.

I had mused about the viewport overhaul in my mind for a long time, and then it was surprisingly quick to do. Trimming it around the edges (almost literally) took more effort.

http://multipaint.kameli.net/

At CSDb

https://csdb.dk/release/?id=240697