Monday, 9 October 2017

Zoo 2017

The grandeur of ZOO (not my computers)
Last weekend I went to the Commodore 64 demoscene party ZOO, held in Akaa, Finland. I participated in 2013, very much intended to participate in 2015 but that plan fell through, so it was nice to "return" to the ZOO atmosphere.

I've never felt like a huge scener, but I've started to recognize and connect a bunch of faces and names, so I guess something is happening :) This is not a party report/review about who was there and what cool shit happened, I'll just ramble about my own participation and the presentations and compos there.

At the Competitions

The PETSCII competition
There were numerous categories: demo, basic demo, graphics, music, wild, party, PETSCII and party feature. A sort of specialty of ZOO is the heavy emphasis on the PETSCII text art competition and the BASIC compo as an added flavor. Both usually have a spate of joke entries so I was surprised to see everyone had taken both quite seriously.

Dr. TerrorZ: Paradrone, C64 PETSCII
Although the standard of the PETSCII stuff was very high overall, I felt a bit weary about it. I guess I'm projecting my feelings about my own competent-yet-a-bit-tired work for the compo here. One novelty was Marq's stereoscopic PETSCII image, I guess a proof of concept that it's possible!

For the graphics compo, I had prepared a multicolor bitmap, again made with Multipaint. I'm quite happy about the process, this time I avoided spending hours and hours on anti-aliasing and dithering. Compared to my Inside Job with same subject matter from a few years back, the figure is much more dynamic.
Dr. TerrorZ: Infestation, C64 multicolor
Against some of the best of Finnish (and some international!) C64 talent, the pictures were not enough to reach prize positions. I also made a BASIC demo entry, but less I say about that the better - I had hoped there would have been only 2-3 entries.

The 2013 victory kind of made us responsible to participate, so it felt a bit bad we did not have a demo for the main event. I guess the main demo compo was ok, but it was getting a bit late I could not pay so much attention to it.


Before the compos, there were presentations galore. Marq gave a presentation about PETSCII and the PETSCII editor, based partly on our academic work and partly on the development side of the editor. There was not that much news to me obviously. The creation of the editor was very much tied to the 2013 ZOO compo so it was nice to see it addressed here. But there can be such a thing as a PETSCII overdose :)

Juho Kuorikoski, the author of many Finnish gaming books, was pimping his new C64 book, which sadly was available only in very small numbers. The crowdsourcing campaign probably meant only the contributors receive the book first. Not obsessed with the C64, his relation to the computer could be defined as "normal", so perhaps he is the right guy to write a thorough popular book about the Commodore phenomenon in Finland.

Another enjoyable presentation was given by Pasi Hytönen, the guy who made the game Uuno Turhapuro Muuttaa Maalle back in 1986, pretty much the only Finnish film licence game in Finland in the 64 era. The batch was not too huge, so especially the disk version fetches high prices in net auctions nowadays. Pasi talked about his ORIC/BASIC days, and I was surprised to learn he had been quite involved in the game development scene ever since. (Including 1990s dead ends such as WAP/mobile/multimedia stuff)

It exists, it's real
Gideon, the Ultimate cart guy, gave a Q&A presentation about the new Ultimate 64. He had a functioning board with him, and although it's as good as finished the release is still some times off. He sold all the Ultimate cartridges he had with him, so I wasn't too tempted to buy one. Guess I'll save my money for that total machine, although the benefit of a cart version is that you can use it with any C64...

It would have been sweet if the new C64 and the new C64 book had been properly available at the party, but what's impossible is impossible. What with both the Uuno programmer and the musician ("Jori Olkkonen" back in the day) present I sort of half-expected some announcement of a new collaboration, but I guess that would have been too strange to happen.

Other stuff

The venue as a space is excellent, as the main hall is clearly designed for performative presentations. There's ample room for tables, there's a mezzanine, sauna and connected hotel rooms (for those quick enough to grab these).

The bar inside the main hall, next to the computer tables is a bit of a mixed blessing. Yes, sure it provides a constant atmosphere and is a very clear and professional way to access all merchandise/drinks. But the sound of bar chatter nearby can also be a bit distracting, especially when there are more "serious" presentations.

It's nice to have active lights, but truth be told I'd prefer if the display projection was a bit bigger.  I also sometimes wondered if the saturation from the C64 signal is a bit overblown with the projector. The C64 pics looked almost like ZX Spectrum sometimes. This seems quite common in parties, though. I guess an effort has been put to give a good quality image, and maybe the image is more "technically correct" in some ways, but does it correspond with a conventional monitor display?

Overall, amazing times. Maybe the 2013 event had more novelty and excitement for me, as it was the first time for me, but all the events, participants and programme kept it interesting.

The ZOO 2017 on the net:

Saturday, 30 September 2017

Blender notes

I use Blender so rarely I keep forgetting some of the commands, so I thought I'd create a small summary for myself. These are mostly relevant for low-poly stuff I sometimes work with.

The first thing I always forget: creating new panels is done with the weird triangle in the corner of an existing panel.

Play a sliding puzzle game while you model!

Removing panels
is done by pulling a panel from the triangle to the panel that shares the complete edge with that panel. I didn't find a way to remove the right-most panel in the image above, because this rule could not be fulfilled.

Some keys:

TAB = switch between object / edit mode

CTRL+hold left mouse = draw a freehand selection area

A graphic doohickey shows whether vertices, lines or faces are selected. The box with the highlighted corners adjusts whether back-face elements are selectable. The magnet thingy can be used for snapping the vertex movement to other vertices among other things.

Left: point, line, face selectors. Middle: transparent selection, Right: Snap to ...

a = select all / none

g = grab = move

e = extrude

shift+d = duplicate

r = rotate

s = scale

CTRL+r = loop cut X,Y,Z

alt+m = merge selected vertices

In "Cycles Render" mode, shift+z switches between cycles render view.

Direct texture painting

I bothered to learn the basics of painting directly on textures, so here are the notes:

-Drag two new windows into existence, the UV/image window and the Node Editor window (tick "use nodes").

-Use Cycles Render, otherwise the following material stuff won't work.

-Remove the existing material, create a new one, which will become visible in the Node Editor.

-Create new image in the UV/Image window.

-In edit mode, use 'u' to produce a smart UV map for the object. A tiny bit of island margin can help.

-Use shift+a in the Node editor to add texture image node, connect it to the material color and select the previously created texture map.

The mandatory first attempt weird-face
Texture mode should now allow painting directly into the chosen object.

Key 'f' works as a shortcut for resizing the brush, whereas 'shift+f' changes the effectiveness. The usual mix/color/blend/multiply options are available, as are some smearing tools.

The image has to be either stored separately, or using the Pack PNG option. I sometimes lost work because this was a bit ambiguous, so it might be better to store separately. In any case with Blender, save early, save often,

Once the setup is in place, painting directly to objects is strangely intuitive

Thursday, 21 September 2017

Opening the Mac Classic

Memory and half-removed motherboard
I got a bit worried about a possible battery leak inside my Mac Classic, so I opened it for the first time.

It turned out to be much easier than I thought. Remove four torx screws, pull out the back of the case. Remove the memory sub-board, then remove all the drive and power cables from the motherboard. Now the motherboard can be slid out quite easily. 

This is a pretty neat design for that era, or for any era for that matter.

The memory sub-board and the motherboard fully removed. Red spot marks the battery holder.
Two of the torxes were in deep holes, so I used an screwdriver with removable tip and an extension which gave the screwdriver some added flexibility. 

The board is very small, even when considering the memory sub-board.

Putting it together was just as simple. Push the board in gently, plug in the relevant cords as you go along.

The other half
After I put the case back together, I checked if the computer still functions. It only gave an empty desktop backdrop. As it's missing a keyboard, a mouse and a battery, this might be normal. Still, it's a bit uncharacteristically unfriendly response from a Mac, so I hope there is nothing wrong.

Alive or dead?
Supposing it works, what to do with it? The Classic Mac is one of the last iterations of the original design, so it's not that old really, 1989-1990 maybe. But this also means it still has the 8Mhz 68000.

Compared to 8-bits, it is a bit cumbersome to get anything running on it, as all the interfaces and connectors are a bit weird from today's perspective, and there's no "load from tape" option to fall back on. HxC floppy emulator apparently won't work with it, and the SCSI interface is not as common as the IDE.

Perhaps the best bet is to use the 1.44Mb floppies for file transfer, which at this stage ought to be PC compatible.

Uncomfortable perspective: the case from below, with the board removed.

Tuesday, 8 August 2017

TAC-2 fire button microswitched

A tiny project, but food for thought never the less.

The Suncom TAC-2 is very nearly the perfect joystick for 8-bit games. Tiny, crisp, with short travel. Yet I have to admit the fire buttons have a slightly vague response and are prone to dirt problems.

So I thought it could be interesting to replace the fire button contacts with a microswitch. I'm not a big fan of microswitches as they tend to be a bit noisy in the home environment (I'm looking at you Quickshot II Turbo) but I suppose one fire button would not result in a cacophony.

The bigger switch was chosen. This is the first with the overdone groove!
Then I opened the joystick, admired the insides and spent some time trying to find a good location for the switch box. I had two varieties of microswitch, the bigger comes with a metal lever actuator on top of the box and I saw this would be easier to set to place. I have no idea if these switches are well suited for video game controllers.

It appeared that the simplest route was to carve a slot in the thin vertical protrusions. I also made small grooves to both sides of the micro switch box, so it would not fall out of the slot.

The carved slot. The existing metal flaps & connectors are good for inserting cables.
My first attempt was a bit too hasty, and the slot ended up too far from the fire button metal plate. Fortunately TAC-2 has very neatly designed insides, so I could insert the original part back over the failed groove. Attempt 2 hit closer to the mark and the resulting hole was more accurate besides.

The above image shows a not-to-exact scale of the microswitch position in relation to the plastic protrusions under the fire button. The grooves made to the switch are exaggerated. With the cables I did not break any existing parts, I inserted the new cabling to the pieces holding the metal flaps.

TAC-2 insides, complete with the switch, un-wired.

Although a levered switch is quite lenient, it still needs careful vertical positioning. Strangely enough placing the metal contacts against the floor of the TAC the metal lever is in pretty much correct position.

Much to my chagrin it did not work. Yes, the button gives a satisfying audible-tacticle response. But the C64 I tried this on seemed to miss button presses. The old fire button works so it's not a problem with the joystick plug.

Being a bit lazy I did not test the situation more closely. The switch itself appeared to work. Here's my thoughts:

  • The groove at the side of the microswitch was too deep & the side of the slots pressed the insides of the switch
  • The switch did not have enough room for a proper release, even though it sounded ok

Ends well

Well, I took another microswitch, took a care not to overdo the grooves, widened the slot a bit to compensate, adjusted the positioning a bit. As a result the switch box is not as tightly stuck to the slot, but it ought to stay in place.

Is it good? Well, I played the best game of Paradroid ever on my Commodore 64. I was surprised to find that after the ship "Paradroid" there is another ship, "Metahawk". Well, it's the same layout all over so I got tired and gave up. Guess I was a Paradroid noob after all.

The mod is well suited to this game where it's quite crucial how and when you use the fire button. The micro switch is not that much noisier either.

I modded only one of the buttons, to preserve some of the historical crappiness.

Wednesday, 26 July 2017

XORin' in the Free World

One day, I thought it might be possible to re-create my Fort Django on the ZX Spectrum. I abandoned this exact goal as there's not that much material that can be re-used and some of my findings discouraged me from this route.

Instead the code became an exercise in game sprite graphics. I wanted to have three huge-ish characters on screen with a smooth framerate, with a game that would again float somewhere near the Saboteur!, Bruce Lee and Dan Dare territory.

I decided on XORed sprites, so I don't have to do masks. XORing graphics means that the underlying pixels are inverted with the sprite pattern. It's a nice method in that with XOR the sprite drawing and erasing routines are exactly the same, because re-drawing on the same position leaves the screen as it was before drawing.

Granted, it can look a mess whenever the sprites overlap. Many complained about colour clash in ZX Spectrum games, but I guess XOR was partly to blame, too. Atic Atac is maybe the best game that uses the XOR approach, and it's very fast.

Early days. Using sprites adapted from Fort Django
I needed to plan the graphics and the game around the XORing artefacts, so it would not get too bothersome. This was the reason to move away from the Fort Django concept, as the ladders and furniture might create too many disturbances around the moving, overlapping graphics.

Another weird technique is to draw the sprites when entering the frame and erasing them on the way out. With a Commodore 64 you could simply check for the suitable scanline, but with a ZX Spectrum this is not possible. I'll simply have to ensure that each frame still does the same things even if there are no enemies on screen. This also means the game is fixed for the 3.5MHz timings. Such an approach is not very elegant nor portable, but it's justified to get a silky-smooth game in a closed environment that the 8-bit computer is.

The sprites, actually

Although XORing is a fast technique, I still had to revise my approach a bit. My initial target of 40x64 sprites with smooth framerate were clearly out, so I went for 40x48 instead, which is the size of the Saboteur human characters.

I can't even have true 40x48 sprites, but by doubling the vertical pixel size it is possible. Not only are the pixels doubled, but the underlying vertical screen resolution needs to be divided by two to make the XOR draw/redraw logic work. So I'm working with 256x96 screen with 1x2 proportioned pixels.
Drawing one "line" of the sprite data as 1x2 pixels.
This has the benefit that as I fetch the sprite graphics, I can assume the two subsequent screen line contents are the same, so the routine does not have to read them separately.

The sprite graphics are drawn from left to right, zig-zagging the two lines. The stack is pointed to a table that has the vertical screen addresses sorted out for every other pixel row coordinate, and these addresses are pop'ed for each sprite line. The horizontal component of the address needs to be added, too.
1x2 pixelled sprite data pictured in GIMP, with one data line highlighted.
The sprite Y-coordinates are also constrained to multiples of 2. This has the benefit that there is never a troublesome screen address boundary between the zig-zagged vertical pixel rows. Within the line, the zig-zagged pixel row can be changed with just incrementing or decrementing the address high register.

Other good things came out of the 1x2 pixels: Instead of needing 256 bytes for each sprite frame, I could fit a graphic frame inside 128 byte boundaries. The 40x64 sprites would not have fit in a 256-byte boundary anyway.

The pixel ratio is not that limiting, as the sprites can be drawn deal with it rather than stubbornly make something that does not fit. My current sprites are hardly the pinnacle of ZX graphics, but it looks promising. And of course the screen portions where the sprites are not drawn, can be in 1x1 pixel format.
Toying around with some gfx pretty much ripped from Dan Dare.
With this tweaking of the resolution I could draw apparent 40x48 pre-shifted pixel areas three times, after which the scanline is at the 16th line of the Display File. This would mean that a moving sprite at the top of the screen could become distorted.

I could use a portion of the screen for a dashboard, as in the image above, and these 16 lines might not matter. I am making a game after all, and not a generic sprite routine.

But then the silly me realized that if the sprites are drawn in a certain order, the scanline intrusion can be made nearly meaningless: If the first sprite to be drawn is at the top of the screen, the second at the middle of the screen and the third in the bottom of the screen, all happens smoothly by "racing the beam". I only have to take care that not all sprites move near the top or bottom at the same time.

The diagram below shows what happens during one frame. These are not based on actual values, the picture is exaggerated for clarity. In this example only the second sprite is truly both a: drawn before the scanline enters the pixel drawing area, and b: erased after the scanline leaves the pixel drawing area.

This brings certain limitations to what can be performed with the sprites in the game. For example, only the player character has full freedom to move all around the screen, whereas the other sprites would stay within invisible "cages". Yet these cages are so lax that by switching sprite positions these cages do not matter much.

Technically, it would even be possible to draw more sprites than the three, if the sprite drawing order is well managed. This is somewhat equivalent of multiplexing sprites on computers that have real sprites and good scanline routines. But I felt this might become a bit too complex programming exercise or limit the "cages" a bit too much.

So, there are now three "big sprites" and the player sprite is always the second sprite to be drawn. The game, whatever it might be like, has to be designed around the small limitation that the enemies can't go everywhere.

Animation frames were another source of trouble. I wanted to save frames by "baking in" the leg motion inside the shifted frames. But this produced too fast animation. So instead of four shifted frames there would be eight sprite frames for simply making the guy walk on screen. The eight frames make a total of 1K graphics laid out in 128-byte address boundaries.

What else? I didn't make a clipping routine, even if it's not too slow to check the coordinates and divert to another sprite drawing routine. I wanted to negotiate some programming time out of this project.

Dude, where's my game?

So, after making the to-hell-with-portability sprite engine, I could concentrate on the game. All I've made since the sprite routines is a tile-drawing/collision routine, a bit more joystick stuff and experimenting with ways to draw unobtrusive objects. It looks nice, but currently a bit limited for a proper game. I'll get back to this in some form, but it doesn't seem to happen anytime soon.

Wednesday, 5 July 2017

The summer holidays Ultima IV bash-through

Much like returning to some books and films time and time again, I feel occasionally compelled to complete Ultima IV. This is not as time-consuming as it sounds, as DOSBox makes the game very fast. I also use any help available on-line, such as the dungeon maps. The last few times I've played the 256-color modded game, but now I chose the more vanilla version. I know there's the luscious Commodore 64 update, but I can't bring myself to play a slow version any more.

It's always wise to keep the party small in the beginning, but this time I tested a theory that I would be better off without recruiting anyone until absolutely necessary (i.e. the very end). This makes the solution even faster, as the combat sequences and dungeon rooms are more simple to navigate with just the one guy. The battles are generally so easy in this game a fully maxed party is not really needed even in the final Abyss dungeon.

I picked a class that can use magic and can wield the magic wands (Mage, Druid, Bard). This time I chose a Druid, although I usually go with a Mage. I upped the character XP and gold by repeatedly exploiting dungeon rooms with a good monster/treasure ratio. The first room in Dungeon Despise is a pretty good starting point for this, it's near the British Castle and you don't need to waste torches to find the room.

When I had the ship and enough gold I went to Buccaneer's Den and bought that Magic Wand plus some of those oh-so-necessary lock picks.

After I had the 8th level character with 800 HP, I simply collected all the runes, all the stones, all keys, all special items (book, bell, candle), all "bonus" items (horn, wheel, skull) and gained Avatarhood in all virtues.

Rune locations I could still remember, but I had forgotten some of the mantras, this wasn't the case last time...

For the end, the party has to have eight characters, and levelling them up is a very tedious business. The game doesn't care if the characters are dead, though. So maybe having three persons with good-ish stats would be enough for the Abyss?

When my party had two members, I tried to educate Iolo by having my main player killed, so as to have an one-member party again. However with my (dead) character at 8th level I could easily encounter Balrons and stuff so it was a bit dangerous. I was happy with Iolo at 6th level and Mariah at 5th level. Then I recruited everyone else, mixed a huge amount of useful spells and headed to the Abyss.

When approaching the Abyss Isle pirate hideout, I came across a bug, shown above. I'm not sure if it is in the original code or a DOSBox (speed) artefact, but amidst proper ship-to-ship buccaneer battles I had to fight a bunch of miniature ships! The game resolved them as "phantoms", which is OK, but they could not move in the water. This means the south-easternmost ship could not be killed as it is out of reach for the players. However, I was lucky to have a couple of Tremor spells which destroyed the phantom shiplet.

And yes, the party was good enough to get through the eight levels of the Stygian Abyss, with on-line help to guide me of course. A couple of dudes died, but this only served to make the combat a bit more bearable. My party began starving inside the dungeon, but that's not a big deal as it's mostly combat rooms anyway.

Then I thought, perhaps the Abyss could be beat with just one character. I reloaded the game, killed off the party except my main character and entered the volcano of Abyss again. I kept my guy in good health and M.P, and also poisoned to avoid the enemy sleep spells. Quickness spells come in handy in certain situations, as having a bunch of Daemons around you can still be dangerous. But yes, it's silly how much easier and faster it is with just one character!

The Poison status preventing Sleep status can be considered a bit of a bug, but it's also a clever counter-move in an otherwise simplistic game engine. Why would there be the poison fountains in the Abyss, if not to offer a chance to gain immunity to the Sleep spells? There are versions that "fix" this feature, and I can understand the Abyss becomes reasonably difficult if this feature is removed, and the one-character approach probably would no longer work.

Friday, 16 June 2017

WiderScreen: Text Art

A frame from our VIC-20 reconstruction of an early Finnish computer comic strip, made originally by Riitta Uusitalo and Reima Mäkinen in 1983.
I recently co-edited an issue of WiderScreen journal with Markku Reunanen. As the topic is Text Art, this well fits to the theme of "old machinery" too. This new issue features typewriter poetry, teletext-art, ASCII pr0n, PETSCII and numerous other explorations at the intersection of text, technology and image.

What I am pleased about is the number of galleries and creative works that nicely complement the written articles. Somewhat sadly for international audiences, some of the articles are only in Finnish.

The link:

Tuesday, 6 June 2017

Amiga Workbench icons on Linux desktop

It started with setting my Linux Mint/Mate desktop background to what supposedly was the original Workbench blue background color (#0050A0)...

Fast forward a year or so. Then I got around to thinking whether there is an Amiga Topaz truetype font, and of course there is. I also grabbed some Workbench icon graphics for the folders and such.

However, the normally scaled Topaz 8x8 font did not give the kind of 640 x 256 feel I was after. The 8x8 font is not inauthentic as such, of course the font would look like that in a high resolution desk.

But I kept looking and I found one version that had the Topaz font stretched to 8x16 proportions.

I found the icons from various sources on the net. Google image search yielded surprisingly few images of the old WB. I have so far combined elements from 1.2 and 1.3, as the latter has some more interesting icons but overall I prefer the 1.2 approach with the flat drawers and clean trashcan.

I could have taken a hard drive icon too, but it looked a bit ugly so I stuck with the disks.

Yes, to me every later WB looks worse. Got to appreciate those bold color choices in the 1980s interfaces...

I grabbed the icons using GIMP, and gave them a transparent background. The blue color is also transparency, so the desktop background would affect the icon colors as it would in the original Amiga.

Here's a snippet of my Linux Mint/Mate desktop:

I've been a bit "creative" about where to use whatever kind of icon. Obviously CLI takes me to the terminal and Notepad to the default text editor, but the telephone icon was originally for "Serial". Here it has been appropriated for the Internet browser.

With the legendary "Say" icon, I hesitated to assign it to the Screenreader, even though it would be appropriate. But as it is not something I would ever use, I assigned it to Skype. It would have made more sense to use the Telephone icon for Skype, but then what would I used the Say icon for?

It's a bit sad the icons have to be manually resized, for example copy-pasting a folder does not replicate the size. Apparently it's not easy (read:there's no tickbox for it in the prefs) to get rid of the font shadow on the desktop, so I left it as it is.

I only let this craziness take over the desktop. Changing the folder interiors, menu bars, terminal fonts, the pointer and the windows overall might be possible, but it could hamper the overall experience a bit too much.

Wednesday, 31 May 2017

ATARI Portfolio

Atari Portfolio is from a time when Atari was beginning an expansion towards new fields (transputer computers, CD-ROM drives, STacy, 32-bit consoles and other near-vapourware), innovating with this portable "MS-DOS compatible" hand-held computer. Luggables had been seen before, laptops were nearing acceptable sizes and Sinclair's Z88 packed some nice functionality. But here was something, that for a brief period of time, seemed like the future.

The physical design is neat, a bit confused around the hinge when it's open and a bit thick when closed, but very cool styling altogether, a bit cyberpunk even. A slightly smaller footprint than I expected, a bit thicker than I expected, a bit smaller screen than I expected. Atari compares the size to a VHS-tape (a size comparison that's bound to become extinct) and that's a pretty adequate description.

The hinge gave a fright-inducing squeak when opening and the lid refused to close fully. Perhaps I broke the guard switch, or it was broken to begin with. On the positive side the hinge has not become loose at all over the years.

Silliest thing is the area around the screen which has no other purpose than to declare "16 bit personal computer", "Portfolio" and ATARI at various places. I can imagine that in concept stage the screen might have filled a bit more of the lid space.

Initial impressions

The keyboard is good for the size. The keyboard is buried, the keys are profiled to slant forward and they have that characteristic 45-degree sci-fi cut in them. These features altogether improve the typing sensitivity a bit, further enhanced by the subtle electric beeper sound. No fast typing, though, I was using maybe six fingers tops. I needed to change the keyboard layout to Swedish, this from the Applications/Set up/Keyboard.

Editing, well, the EDIT.BAT, to run the APP /e command
The apps are quite well thought out. The Address book does not make too many assumptions and the editor is low-key enough to be relatively quick. The Diary I suppose is more of a calendar, but I did not look into it too much. The calculator I found to be clear but a bit limited, no hex mode or even SIN/COS as far as I could learn from the manual.

The spreadsheet can calculate more complex things, and I suppose the calculator is more of an afterthought for simple immediate calculations. No hex though in the spreadsheet and sadly no string manipulation either.

I was a bit horrified with the DOS-style frame window space waster in these apps. Thankfully this can be switched on/off with F5.

Eight-bit pixel calculator in worksheet, without screen frames.

DIPping into DOS

The Portfolio boots up to a stripped-down MS-DOS called DIP DOS, with a plethora of familiar commands such as DIR, CD, COPY, PATH, PROMPT etc. HELP brings a shortlist of generic commands. Batch files such as AUTOEXEC.BAT are valid too. Thankfully the OS is in ROM.

The display shows eight text lines, and the active part of the display is even slightly smaller than the physical dimensions which are small to begin with. Old MS-DOS programs should in principle work with the Portfolio, but I doubt there are many that accommodate with the 40 x 8 character display and the limited 128K memory. Part of that memory is a RAM disk, too.

Form factor: sci-fi
It's possible to use a virtual 80x25 mode, and then scroll around that space, using the viewport as a window into that larger screenspace. The internal apps don't respond to this, but maybe it's wiser that way. In my understanding the screen is strictly text-mode, so no plotting of graphs or sprite graphics.

Given this is an MS-DOS environment, some omissions are a bit frustrating. I can't use EDIT to run the internal text editor, for example. There's a clunky APP /e construct, and although I can create an EDIT.BAT that runs the command, APP does not take a filename as an argument. At least the applications remember the last open file.

A whole Spectrum's worth of memory! The battery sled is a bit tight.
It's a pity the RAM cards need their own battery. It's also suggested the battery be changed every six months. The battery type is CR2016 type and should be only replaced when the card is inside a powered-up Portfolio, in case you're interested in retaining your data. I didn't try my 128K card yet as I don't have the battery. When the 4 AA batteries inside the Portfolio die, I guess it's goodbye to the internal RAMdisk files if they are not backed up.

I beam myself into the future

Strangely enough, for the 2010s, in some ways the Atari Portfolio from 1989 is a worse deal than the Canon X-07 handheld from 1983 I once wrote about. This has perhaps more to do with computing trends than actual hardware specs. The Canon had an integrated BASIC language and graphics commands, enhancing it's role as a calculator zillion-fold, whereas the PowerBASIC for Atari was sold separately. Given the esoteric nature of Portfolio's memory cards and connectors I have less chances of getting anything transferred to the Portfolio than with the Canon tape/serial interface.

BTW: Photographing the screen is annoying.
Obviously the MS-DOS connection gives Portfolio great generic potential, but this potential is difficult to put to use with an out-of-the-box device. There's no DEBUG, no file editor, of course no assembler. It's possible to hack up an executable file by ECHOing character codes directly to a file, though. A tiny program is created for slightly more handy file writing, then that file writer is in turn used for creating an even more complex program. This sounds intriguing and I'll be looking at this approach some time.

Although the Portfolio manages to cram in some nice software, this set is also very "office" oriented, showing that computing had begun to atrophy into imagined "tasks", paving way to boring PDAs. Later, high-end calculators like TI Voyage 200 better filled the niche that a Portfolio-type device might have been aiming at. (Note to self: write something about the Voyage)

Just like with all ye olde hardware, there are small existing communities, either for all things Atari or for the Portfolio itself. What I see there is no massive Portfolio cult, though, and modern additions are quite sparse. There apparently have been PCMCIA adapters for slightly more recent memory cards, and Wikipedia mentions a Compact Flash mod. If I've understood correctly neither work as a PC file transfer method as the cards will become Portfolio-specific. An SD-card adapter would be neat but I think there's none and might not be happening.

I thought I would refrain from mentioning it, as it's always brought up to the point it seems to be the only reference for this computer... But, of course Atari Portfolio is the device the young John Connor uses to hack an ATM in Terminator 2: The Judgment Day. There's some vague basis in reality for this, as the Portfolio can generate telephone dialtones from the Address book, something that might theoretically have found use in a phreaker's toolbox decades ago. However, the film clearly shows a ribbon connector.

Monday, 22 May 2017

Multipaint Metal Edition

Notice: The Multipaint site should be now ok.

Notice 2: Mac users, if you can't get Multipaint to work, check the website (link below) and check the comments too.


It's time I gave this 8-bit paint program (works on PC, Linux, Mac) a public update.

Largest change is the new color model, which is perhaps now a bit more sensible. If there is no "room" for a new color inside a color resolution area (say 8x8 pixels), the color under the pointer will be changed to the current color.

The old mode, which prevented color changes if there was no "room" inside color area, is still retained as the 'b' mode, as it can be useful when painting fast or using the geometry tools. (it's the huge B icon at the bottom of the tool box)

Demoing the new preset dither patterns and adjustable offset:

Multipaint supported custom dithers ("rasters") before, but having these presets might come in handy. The offset can only be changed by using the bracket [ ] keys, for horizontal and vertical.

Using a loose dither and changing the offset as you go along can produce nice results quickly, as in the image above.

However I believe that almost all mechanical approaches to dithering are bound to be more or less exploratory tools, and the real work is nearly always about making pixel-level decisions.

The keysheet, highlighting the key shortcuts I think could be most useful to learn first:

u/U for undo/redo
g for grid on/off, G for grid size switch
c for grid constraint on/off.
j for spare page (alternative page for holding brushes, fragments etc.)
m for magnify=zoom
, for pick color (also middle mouse button)
ctrl for force color (change underlying 8x8 area)

A couple of tips I forgot to mention in the manual:

-This type of drawing can benefit from having a slow mouse setting. Personally, I can't draw with very fast mouse.
-I often use VICE for previewing C64 images every now and then, because it's able to predict the color blurring of a monitor. This is also why I'm not too keen to add a preview window, because it wouldn't do it's job properly. However, it may arrive one day.
-If you draw a circle with a loose dither, then grab it as a brush and draw with the dither off, you can get a kind of "airbrush".

In the future

There still remains many items and known issues on my to-do list. Preview window, aspect ratio (That MSX!), better CPC output, more flexible UI, etc., but they'll have to wait for some time yet.

Overall changes for this version:

-Changed the color behavior to a more straightforward model. Old behavior retained as ‘b’ mode.
-Overall color behavior is more uniform between formats, multicolor and otherwise
-Changes to mouse event handling should make the program a bit more useable across platforms and computer speeds
-Added preset dither (raster) patterns and offset adjustment
-A bit more visible grid (not in plus4 and CPC modes)
-Metal User Interface. Why? I wanted some program changes to be visual. Tiny adjustments to icon graphics and visual behavior. Visible dither on icon, visible spare page on icon.
-Bug fix: UI elements overlapped in CPC mode when using ZOOM=3
-Bug fix: Machine selection through prefs.txt did not really work
-Bug fix: In CPC mode palette changes could not be undoed (in loading pngs for example)

The website:

Monday, 15 May 2017

Raising the Dead 2: The Overclockening

Nah, this is not really about hardcore overclocking, just continuing with this PC upgrade project from 2015. I never believed there would be a processor upgrade, but here it is: Intel Core 2 Q9550 Quad core (2.83GHz)

Although it is not much of an upgrade. The tricky thing is that although this is a Quad, the previous processor, Intel Core 2 Duo E8400, is faster in a single thread, so it's a trade-off between some tasks faster with the new processor and some faster with the old. Video encoding with Handbrake is certainly faster with the quad core, reducing a 28-minute encoding nearer to 20.

But, mildly overclocking the Q9550 it does not even have to be much of a trade-off.

I nowadays have two brands of memory on the motherboard: The G.Skill (2X2GB) and Corsair (2X1GB) totaling to 6GB. They ought to play together, and for the RAM parameters I found someone with the Corsair:

I suppose I could trust the SPD parameters, too. The 1GB memory gap had to be fixed from the BIOS settings, otherwise the total memory visible to the system remains at 5GB. (Edit: Wow, I keep on writing about MegaBytes. Fixed)

BIOS parameter experimentation may result in a non-booting computer. Then I have to use the ASUS P5B Deluxe board's CLRTC jumper to reset the BIOS entirely. Take off all power from the computer, including the hard switch. Then the jumper is changed from 1-2 position to 2-3 position for a period of 10-15 seconds. After this, the jumper is returned to the original position. Boot again and Bob's your uncle, the BIOS has been reset. (The BIOS settings menu is accessed with the DEL key)

ASUS P5B Deluxe board: The CLRTC jumper in the normal position.
I changed the FSB from 333 to 350 then to 360. I also reduced the chip voltage to a lower setting (1.2V) so the stressed cores keep around 65C (max 71.4C from the specs). Taking the voltage  above 1.2 very quickly changed the situation to 74+, at which point I closed the burnP6 running in four terminal tabs. With the voltage in the default auto-setting the result was 80 degrees Celsius when strained.

I generally use roughly the same video encoding task (~20min task duration) for Handbrake to test the stability. The burnP6 software can show how much heat the cores can generate under stress, but it does not seem to reveal all stability problems. With FSB at 370 the system became unstable, for example the Handbrake video encoding task would not be finished.

Increasing voltage in turn tended to bring back the heating problem at least with this fan configuration so I could not test the stability with great confidence. So far I have never been able to get the fan to change RPM, Windows or Linux. Pwmconfig does recognize if the Q-fan control from BIOS is on or off, so there is some connection, but it does nothing to the fans during the tests.

So I'm keeping the clocking modest for a moment.

Q9550 at Intel's website

Sunday, 30 April 2017

Icon driven

When Apple Macintosh made a splash on the computer scene with it's mouse/icon desktop interface in 1984, the occasion had a curious side effect. Software on humble 8-bit computers such as ZX Spectrum and C64 started to feature icons too. Not only utility programs but games were suddenly adorned with an interpretation of the WIMP (Windows, Icons, Mouse, Pointer) approach.

Of course, graphical interface elements had been hanging around for a while in different forms, but the Xerox Parc/Apple approach was the one that became, er, iconic.

It was exciting to have a peep into an icon-driven windowed environment on your cheapo Speccy or C64, as a Mac would be a very expensive ride. It makes me think that early 1980s home computer games were not only entertainment but demonstrative showcases of computer tech you could not otherwise have.

Here I've tried to include some of the more important, curious or representative icon-controlled games from this early period. Sometimes it's hard to distinguish the boundary between "icon-driven" games and point-and-click adventures, and I've only tried to include the most interesting borderline cases.


Arguably, Alien might not have been that much influenced by the Mac phenomenon. It is more reminiscent of earlier graphic CAD workstation displays, with a schematic plan main screen and text-based menus at the side. You don't have a floating cursor but menu items are highlighted. So, in effect the game can be played with two keys.

You are in control of multiple characters, and actions are afforded depending on whether there are exits or objects present. This is pretty much a semi-real time adventure game with rooms, items and locations. On occasions you may be presented with a graphic depiction of the Alien or Jones the cat scuttling across the screen. These incidents can be pretty startling, despite the primitive graphics.

As the scenario plays in real-time, icons serve better than text-based commands. It would be rather unfair to punish the player for slow typing speeds... Also, the relevant commands need not be remembered as they are displayed on screen.


On the heels of Alien, Shadowfire was one of the earliest successful icon-driven 8-bit games, where the graphical environment was used as a selling point. Here, as in many games, the icons largely replace text adventure-style commands, for example using a combination of "pick up" and afterwards the icon for the object to be picked up.

The icon screens work pretty smoothly, but the arrangement is where the age shows. You need to click "computer" screens to get to the movement, battle and inventory screens and these computer icons are only differentiated with color. Some icons are a bit puzzling initially, with added detail where a simpler graphic might have served better.

In hindsight it would seem obvious that a half-formed action could be cancelled by clicking the already clicked icon, but instead you have to go and select the "back" icon.

Even though the icon system is very slick, moving and managing six characters around a large map becomes a daunting task, constantly switching between screens and character selection. It's mind-numbing, and I start to wish there was at least a short-cut key to each character.

Enigma Force

This sequel to Shadowfire used the same icon system, but the main game plays in a real-time arcade adventure type screen. The complexity of Shadowfire is reduced, with only 4 main characters with 4-direction movement. The icon layout now scrolls when the cursor is pushed left or right, giving a more streamlined set of actions than in Shadowfire.

The characters can be given pre-programmed motion instructions, should you know before-hand how the map lays out, that is. There's also a "mind control" icon that allows direct control of a character via joystick.

The icons themselves don't look that much clearer, and in addition to the "back" icon there is also an "oops" icon to remove actions from the queue.


Aliens from Electric Dreams took game elements from Alien/Shadowfire/Enigma Force, transforming the influences into an intense semi-first person action adventure.

Not an icon controlled game, though, which is just as well. The lineage and a game screen layout that is suggestive of multi-window environment makes the game worth including here. Perhaps it started to dawn on the designers that certain things were better done with keyboard.

Fourth Protocol

A Frederik Forsyth tie-in, the game is visually very reminiscent of the Apple Mac environment, but in motion it is a quite simplistic interpretation. The pointer does not move freely but is switched between icons, much like in Alien, opening up iterations for your decision tree.

The game is in reality quite text-heavy and at points you have to type in names and numbers. As the game opens you find yourself reading files and memos, assigning watchers to potential cases and getting reports out of them. Later on you go on a physical-world adventure which is extremely minimal in its descriptions. (i.e. "Victoria, Tube Station, Ticket Office")

Mission Omega

A very complete implementation of a windowed environment with drop down menus, the game could even be played with a mouse. The Commodore 64 version is especially nice-looking, but it's also imitating the Mac interface very heavily. The section where you build your droids is impressive.

After this section, I have to say the game content is rather minimal. You move around in a boring maze, giving orders to each of the robots.

Star Trek: The Rebel Universe

Admittedly, this is a 16-bit game, but it also appeared on the Commodore 64.

This is a complete icon-controlled game, without any drop-down menus or much text for that matter. One interesting idea is that multiple roles of the Enterprise crew are shown as mini-screens around the main screen, again a bit like something you might have seen in a CAD program.

Something similar was on the drawing board of the Electric Dreams' Aliens game. Sadly the Star Trek screens don't update in any real time, but that might have been the goal at one time.

There's something left of this idea in how further option screens come available as character screens are opened. Bringing these out (solar system, engineering, star chart) re-customizes the surrounding screens, but arguably these are just big icons.

Stifflip & co.

A very bog-standard example of an icon-driven adventure game, showing some elements of a nascent "point'n'click" adventure: the characters are shown on-screen. The humorous and big graphics makes Stifflip a bit more memorable. The aesthetic has more to do with comic strips and silent movies than with Apple Mac.

Much like with Fourth Protocol, it's more of a graphic multiple-choice game with windowed sub-selections, and you'll be picking actions from text-based menus a lot.

Icon Jon

An obscure Amstrad CPC game that plays a bit like the Magic Knight games but the icons are more visually defined (and Apple style).

The game is controlled using a set of icons but also has computers, computer architecture and programming as the topic of the game. Bit like in TRON, the game depicts life inside computer circuitry. You can pick up and manipulate items and 'chat' with the cast of characters.

The title and game idea goes to show how intense the whole icon phenomenon was at the time.


Four command icons placed around the main radar screen. As activities take place, new windows "pop up" around the screen with live sequences and further information. The windows "multitask" to some extent, so not all action stops just because you choose an icon.

You control a smoothly moving cursor, much like in Shadowfire. On occasion the Commodore 64 goes full on with the window overload, as every action seems to bring up multitudes of windows for iterating your action. The ZX Spectrum version is less impressive.