PETSCII PETSCII PETSCII

Lately I have used more reference images and/or nostalgia in my PETSCII graphics. Perhaps it's easier to judge the success of the image as it is based on something.

But I've also found there's a kind of "digital history consciousness" theme going on. Let's see.

Although Neuromancer came out in 1984, it's unlikely most "kids" heard about cyberpunk until very late 1980s. So in a sense, Max Headroom was way ahead of its time, an "avatar living inside the television set", an image that I knew was cool without knowing really why. The faked computer graphics enabled this 1980s figure to false start the 1990s.

This PETSCII of Max Headroom (AKA Catch the Wave) is the closest I've ever come to simply translating a photograph, although I did use multiple images for reference and not just one. Even then it's quite challenging to fit it into character graphics. The likeness is not 100% spot-on but I did not want to use sunglasses to cover the eyes.

The two-part "comic strip" below was done for the physical Kuti magazine #57. (Go check it here) Apart from my dabblings, the issue features other PETSCII works too. Below is the original export from Marq's PETSCII editor, with a height of two C64 screens. The print/digi-version has slightly different appearance.

Maher's book about Amiga reminded me of the Warhol/Debbie Harry promotional event. I was surprised to learn that Warhol actually dabbled in Amiga graphics even after this promotion. And why not, there was scarcely anything else he could have used at the time.

I initially hoped to do a full spread, with 4 or more panels, with a vague notion of connecting different themes in a 'surreal' or diagrammatic way to this event. But I focused on two images and threw away any surrealism, simply relating the 'historical' event in a somewhat comical way. Did Warhol do a PETSCII after all?

PETSCII Non Stop. This is another recreation, but not from a fake CGI head but a real one. I mean, not from an actor posing as a 3D head. It gets confusing. I occasionally take up on "technical" challenges, such as wireframe graphics with a character set. A still from the famous music video Musique Non Stop served as a starting point for this head.

The result does not probably resemble any one Kraftwerk member but approximates the idea.

Winampscii. Now, the recreation of the Winamp basic theme on C64 is old in itself (there's a few on C64 that actually play something), but I haven't come across one that is full PETSCII.

Thanks for Marq for pointing out the nostalgic winamp skin website and suggesting the Winampscii theme. I did try to make it somewhat more SID-specific. Supposing you have two sound chips (a real possibility), the Dual mode might make sense and in theory a pan-slider could be used.

This was done rather quickly and in hindsight I might have changed a few characters here and there.

And the rest

There's a couple of recent works that do not really fit into the above "digi-conscious" theme.

Advanced Pet Dragons. Although this looks like an "animation" it actually has a couple of code effects, significantly a primitive ray-caster. The material could have been crammed into an animation, too.

Since I made Digiloi, I have sometimes toyed around with other PETSCII game ideas. These days they tend to result in small-ish demos rather than full games, but that's better than nothing I guess.

The history with the Advanced Pet Dragons is that I had a somewhat ambitious game in the works, that in the end could not be reasonably completed. So I simply picked up and modified the ray-caster routine to draw dungeon animations.

PETSCII Gunship, to put it simply, is a recreation of the intro screen of Microprose game Gunship (1986).

I saw the screen could be turned into a PETSCII with very little loss. Seeing this opportunity pushed me to do a rendition. 

Although the Commodore 64 version was the starting point I also had a glance at the Amiga and PC versions. For example for the nose I deviated from the C64 source as it didn't look nice.

Hard Eagle, Floppy Disc is a quick and jokey re-imagining.

Ok, it tends towards the digi-consciousness theme, as it is yet another version of the Eagle Soft Inc. crack intro picture, burned into the retinas of a generation of Commodore 64 users. 

This relates to a small scene drama not worth discussing here, suffice to say PETSCII art was under attack too. I felt a need to do a something humorous and have the ever so serious Sam the Eagle to play the part.

Post script

In the past I've been a bit negative about recreating already existing images on PETSCII or pixels. But now I've found it quite educational and become a bit more accepting about using references for building images. 

Still, I've not followed images very slavishly. But even converting an image is a way to learn and discover, as the source image pushes you to try character combinations you might not otherwise use.

The task is also bit like translating. I could try to copy the bitmap image and then ignore positions that cannot be done. But it is more to important to get the sense of the original and even add detail that's not really there.

I didn't bother to build individual links to csdb, but these works and others can be found from under

 

https://csdb.dk/scener/?id=25645

PETSCII processes

Looking at my stash of unfinished and experimental PETSCII character art files, I found some Digiloi work-in-progress materials I had forgotten.

Here's a screen where the main character was fleshed out:

The nice thing about this image is that I've collected the versions in a chronological order, from left to right.

As can be seen, the first attempt is ridiculously stupid and a 1980s BASIC game might have been forgiven for having such a crude shape in it.

I guess the solitary guy is the one where I felt I'd "got it", although as can be seen it's still some way off. Note also the sketching of background graphics.

This is a frame from an animation where I drew the running frames over a scrolling floor. Using Marq's PETSCII editor it's quite easy to do animation.

Not sure if I ever planned to do a scrolling game, it may simply be the animation loop was easier to test this way.

I also can't remember if the one in the middle is an alternative design based on the one on the left, or the other way round.

That laser shape was on for quite a while before I saw it would not work over a background.

I think the huge gun finishes the character, it's part of the character really. Parts of the previous designs went into the bad guy graphics.

Here are the original "sprites" for the main character, which I thought were finished. In the end I never used a "stand-still" frame in the game.

However, testing the player character over a background, it did not quite work. I changed the colour to green which stands out better against a dark-ish background. Then the tiny details and rounding had to go too, because they would generate ugly black outlines.

This snapshot from an early build shows the problem. Even the finished game has some black outlines.

I also found some extra background tiles, most of which did not find their place in the game:

Another background-related image shows the "running in a dark forest" idea that sort of defines the first moments of the game.

As this is an early build, the graphics routines are tested over a static PETSCII drawing. When I moved over to tile-based rooms, I had to compromise with the trees and the style became quite different.

Although this is just a test, I also toyed with the idea of beginning the game with a bunch of these guys running alongside the player, then disappearing "somewhere." I guess it would have been simply confusing.

So there it is, everything I could find!

Zoo 2019

Some recollections from my participation at the Commodore 64-only demoparty, Zoo, held at Akaa during 4th-6th of October. Again, not really a party report, I'm mostly talking about my own works.

Not the general theme of the weekend.

My pre-party mood was a bit pessimistic, after not catching a hotel room. Another thing I worried about a bit was not having any prods for the compos by the time I arrived. But I managed, as usual, do something on the spot.

It turned out the common accommodation at the nearby building was much better than I expected. The airbeds are cozy and the space was not jam-packed. It actually has a few pros compared to the hotel room, mainly it is very silent (the party noise won't reach there) but it's also cheap. If only I hadn't forgotten to pack the roll-up bed...

The unsuspecting Viiala neighbourhood, somewhere in Finland.

SID

SID was a general theme of the event. Grue gave an overall 'mythbusting' session about the SID and played concrete examples of playing the same songs on different SIDs. The differences were quite drastic, in some cases the wrong SID can even hide the lead instrument.

The bottom line is there is no overall 'best SID', some songs sound better on the 6581 and some better on 8580 - not even always the one the author intended! Your ears be the judge.

Flex gave a workshop on Goattracker. It's a complex piece of software, and SID is complex, so I doubt anyone could have started up Goattracker there and then and gotten finished results, but as I had at least some previous experience I could pick up one or two new things.

I mused that to be able to do SID music on C64, you have to have an understanding of many things, not just one thing:

• About SID features, behaviour and constraints
• The convention of "a SID" as a tracked format on Commodore 64
• How Goattracker (or some other editor) works

And maybe some musical knowledge too. Well, anyway, these SID presentations encouraged me to think that it does not matter so much if I don't achieve the perfect iconic SID sound, so I started tinkering on a crappy tune following some of Flex's tips.


VIC-II

Dr. TerrorZ: Light

I had a Multipaint presentation, but I found I couldn't really 'teach' anything at this point so I simply told what the program is for and showed the main features of the new version. This led me to have chit-chats with various sceners which was maybe the best outcome of the presentation.

The software is now already quite known in the scene but not everyone will adopt it. But I don't think I'm bragging if I say it is a good introductory-level software for making C64 graphics!

First time i saw the zoo from this angle.

My graphics entries were even less successful at the compos than last time.

Normally parties tend to go so that I pick a half-decent half-completed image from the archives and finish it, but this time my folder was rather empty. I also spent a lot of time getting a demo production working (see further below), time taken away from drawing.

The bitmap work was a quick experiment with drawing using wacom tablet with Multipaint.

Dr. TerrorZ: Spacesplash

I preferred the initial quick lines and was even afraid to lose them with too much detailing. So I actually like this image quite a lot (perhaps because I did not have time to grow tired of it) but it didn't go down that well in the compo.

Admittedly, a further session would have helped it a bit. (That's a damn long arm!)


CPU

I was greatly impressed with the amount of quality demos at Zoo. I recall the dry year 2013 when even a crappy PETSCII demo written in c by some idiots could win.

The Finnish Gold 'returning' with a full-size demo should/could have been a bit more grandiose. Although it was presented at the show-stealer last position, it was a bit on the short size and petered out in the end. Artline Designs demo Out of Contex delivered better overall and was the clear deserved winner. The Void Mind was still incomplete at the party but is clearly a memorable demo. PWP's Metadimension was an atmospheric generative-algorithmic work.

In the drunken tired atmosphere there was a tangible mood of having passed a turning point and a feeling of living amidst a new rise of the Finnish C64 demoscene. In a more sober hindsight, it's perhaps not all there yet... X'2020 will mark the spot.

I submitted my modest Nine Rings one-filer, based largely on re-writing Digiloi game routines. Digiloi object drawing system is naive in that it draws characters and colours separately to two buffers, and only combines them at the screen. Now I have the graphics stored in a reverse interleaved order for the drawing, and the buffer is also interleaved. So I could have 9 Digiloi-style 'sprites' on screen.

From Dr. TerrorZ: Nine Rings

The PETSCII mode is forgiving in that I can go with 1/3 framerate and it still looks kind of acceptable. The routine was in place before Friday but I did the scripting, music and some additional graphics at the partyplace.

After hitting the ring theme, my goal was to visualize the One Ring to Rule them all... poem, giving an outline to the demo script. But as time ran out I could not add more graphics and it was left more abstract. It was well enough received.


I/O

Apart from the above presentation, Kasettilamerit made an appearance, and the bid for making demoscene a part of UNESCO World Heritage was also presented here.

At the location I bought an external kernal replacement cartridge, a REX 9628 clone. Equipped with JiffyDOS and JaffyDOS and other jibba-jabba, I'm hoping it will make an interesting companion to SD2IEC or that Raspberry floppy emulator. More about these later.

Also I got a K&A paper magazine English edition with a Digiloi review :)

zooparty.org

Zoo 2019 at CSDb
..at Demozoo
..at pouët

(At the time of writing the listings were incomplete)

Some C64 stuff at Vammala Party 2019

I've not released anything for the Commodore 64 during this year, and I got to rectify this situation by making a couple of works for the Vammala Party demoparty:


A Small PET for Man (C64 PETSCII)

I don't usually base my images on photographs,  but in this case I did use more or less three different photographs as some kind of reference for the different picture elements. Especially the landing module.

I resisted the temptation of adding any 'moon hoax conspiracy' elements, that is getting really stale.


Fixertron (C64 Hires)

A sorts of sequel to Remote from last year, I heavily reworked an old work-in-progress image. During the process it got a character-graphics vibe, it could almost be done as a PETSCII.

This somewhat benefited from a new feature in (yet to be released) Multipaint, the quick mirroring of the whole page. As is well known, mirroring a drawing/painting/image can reveal mistakes that were not apparent from overt familiarity.


PET McKracken (C64 "demo" using PETSCII)

I discussed this triple-wide PETSCII already a while ago, but now it's available as a C64-running version. The landscape simply scrolls left and right, playing an atrocious rendition of the first few bars of the Zak theme.

Admittedly more could have been made to work it into a proper demo, however I was already struggling to get the pixel scrolling working.

That's it, nothing else, no hidden parts, no interactivity and no, I'm certainly not going to remake Zak as a PETSCII game. There might be a tiny chance I could work the technique into some other type of a game, though.

Other C64 Vammala party 2019 stuff at CSDb

Zak McKracken and the Alien Mindbenders

Games that begin from your apartment are of a special category.

I have a vague recollection of 1988 or 1989, when I was torn between whether to have Zak McKracken or Neuromancer for the Commodore 64. I was greatly attracted to Zak, but bought Neuromancer instead.

In hindsight, perhaps this was a good choice. I shudder to think how Zak might have worked on a C64 and the 1541. Not to say Neuromancer fit into 8-bit so well, and I never finished that either. These two games have some similarities too: both allow travelling between distant locations through different transports, and money is an important element of the game play.

To get both to the airport, just enter at the same time! There's another way, too...

Although I've played through a handful of Sierra adventure games, this is the first Lucasfilm game I have ever completed. This was recently, with the ScummVM engine on my Linux. I doubt if I would ever had the patience to do this without the flexible saving/loading options.

I tried to avoid using online help and maps. Yet on two points, outside clues were needed:

1. It never occurred to me that when Zak says he needs to draw the map he saw in the dream, it doesn't mean I should draw it but that Zak should draw it. Turns out this is quite crucial for the game!

2. Never figured out what to do on the ocean. I did think an animal might be helpful but no idea how to reach one. I supposed it would be under the water, and I spent futile energy in trying to equip Zak with the diving gear.

If you don't get it right, this sequence will annoy you every time you fly.

The game is excellent when it presents complete complex milieus, such as the beginning location, San Francisco and the Mars areas. I just love that spaceship buggy and manipulating the dashboard.

Some individual sections, such as causing havoc in the airplane, also deserve praise.

It gets more frustrating when navigating dark mazes and look-a-like rooms designed to add some sense of space and playtime to a game that is not much larger than Maniac Mansion. Yet I also appreciate the game is not pure storyboard but also involves mazes, time, co-ordination and checking money and oxygen limits. The Mars and Earth are two different adventures that run parallel, feeding clues into each other.

You can leave with the ship but it's bit of a red herring.

This approach also means that despite the mazes, walking distances have been kept fairly short, as the world is a sprawling network of point-to-point connections between distant locations. It's already a bit of a chore to move Melissa and Leslie in and around the Mars landing site at a time when you don't exactly know what needs to be done, so I'm actually glad there's not more of that.

I even prefer this game over The Secret of the Monkey Island. This is mostly because I am not a big fan of dialogue trees and Monkey had them in spades. Although the jokes and writing quality is better in Monkey, there's no end to the constant blabbering and in some ways the selection-tree reverts to a more primitive form of gaming.

Traveling salesman, anyone?

In Zak and Maniac, we are closer to the earlier idea of a 'text adventure' transplanted into a graphic environment. Even after playing it through, Zak still feels more like a game than a spoon-fed interactive story.

One thing graphic adventures could do well was the use of multiple player characters. Zak gives almost a bit more than can be handled, but the clever split between Earth-Mars activities helps keep it manageable.

A vital clue has been delivered.

Travelling around Zak's world, I have to note that the environments might be seen as somewhat culturally insensitive! Africa is two locations, the pyramids at Cairo and a primitive hut village at Zaire. There we meet a doctor with pedigrees of Master of Cranial Diminishment from the Watsamatta University and Witch Doctor First Class from Kinshasa University.

I also could have hoped for more countries and locations. Visiting the Tunguska site might have been fitting and hilarious and surely something could have been made out of Australia, China or Japan.

Not sexist? Who gets to do all the cleaning in this game?

The plot and comedic style reminds me of The Adventures of Buckaroo Banzai Across the 8th Dimension, a film I am not a huge fan of, but it has its moments. Also, add some nods to Douglas Adams' works and a heavy dose of Erich Von Däniken's ancient astronaut theories and we pretty much have the feel of Zak McKracken.

The notion of lowly alien race invading earth, and earth receiving protection from an esoteric "higher" race, was at the heart of the Buckaroo Banzai story too. The aliens' disguises and inability to fit in were similarly laughable.

Of course the idea of invading species and high protector alien race goes way back, and I recently encountered it in Have Spacesuit - Will Travel by Robert A. Heinlein. Come to think of it, the detail given to building the space suit and the constant monitoring of oxygen levels also reminds me of this Heinlein story.


Notes on the graphics

I did a Commodore 64 PETSCII 'text art' version of the iconic street vista, beginning from the observation that the SFO 42 bus is quite PETSCII-like in appearance.

Click to see it biggenated

While doing this, I didn't look at the C64 version, but used the Amiga/DOS graphics as the reference for for redrawing the graphics.

I made many compromises with Zak himself, to keep him in the correct height, so forgive me if he doesn't look quite himself.

Fits the grid alright.

Indeed I tried to follow the Amiga/DOS capture exactly. I noted that the graphics at this location are especially well fitted for a character grid, with 8x8 pixel elements.

I'd even argue character graphics may have been a starting point for designing this location, or there's some kind of tile compression scheme that benefits from the 8x8 approach.

I mispositioned the mirror!

With PETSCII, the 120x16 character area, together with symbols and colors, takes 3840 bytes, less than 4K!

Funnily enough, the outcome is in some ways richer than the C64 location, although I'm quite sure the game players would not have accepted the PETSCII look back then.

Digiloi: Action game with C64 default characters

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

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

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

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

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

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

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

The visuals and game logic are orchestrated like this:

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

+joystick poll, music/fx play

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

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

+joystick poll, music/fx play

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

+joystick poll, music/fx play

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

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

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

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

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

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

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

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

Tools used:

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

Commodore Plus/4 conversion note

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

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

plus4 version

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

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

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

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

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


Some reflections

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

My projects tend to follow this script:

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

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

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

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

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

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

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

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

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

More 8-bit pictures

Again, I'll have a look at some of my recent 8-bit pictures.

Queen, a multicolour Commodore 64 picture,for the Vammala Party scene compos. What started as an Alice in Wonderland-esque image, was finished quickly with fantasy chesspieces. Made with Multipaint.

Wolverine, a PETSCII work, also for Vammala Party. Fun to do and using the triangle chars for the costume was no-brainer, but maybe a more active pose would have been impressive. Made with Marq's PETSCII editor.

Remote, a, well, remote entry for Gubbdata 2018 graphics compo. Again, made with Multipaint. This turned out simple/nice and has a multicolour vibe to it even though it is a Commodore 64 hires.

Cartoon outlines are not that easy to do on hires and the approach falters at places, but I feel I managed to make it look like it's intentional.

The image started out from trying to recreate a C64 picture I saw in a dream (roll eyes here if you want to) but the end result became something very different. The robot is reminiscent of the robot in Short Circuit, which I watched recently.

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:

http://widerscreen.fi/numerot/2017-1-2/

8-bit journeys into pop culture

Again, some recent 8-bit images, added with musings and reflections. Funny how it all tends to go back to TV/Sci-fi/film themes...


Dallas (128x192 Texas Instruments 99/4A bitmap)

The first image is for the mega-demo Don't Mess with Texas by Desire, for the Texas Instruments 99/4A computer. The coders have done an amazing work in demonstrating the hidden capabilities of this very limited and idiosyncratic old computer. I had a small piece in the demo, a half-screen image which is shown for a couple of seconds of the eight-minute runtime.

I went with "Dallas", as it was one of the first things that came into my mind with that Texas-theme. It also fits nicely as Desire and Dallas have both a D and the same amount of letters.

I never really watched Dallas but in no way could the phenomenon be avoided

As the TI99/4A has the VDP chip, the graphics capabilities are nearly the same as in MSX. The TI community claims that the palette is at least somewhat different, so although I worked the image mostly in the MSX colors the end result is in an interpretation of the TI99 values.

I don't like to use references, but here I needed to use photographs of the actors. Even then these are not very directly worked from any one photograph, and the 8x1 colorspace really makes you reinvent the images anyway. Ok, the MAD Magazine parody "Dullus" opening shot probably influenced me more than I'd like to admit.

The aim was to showcase the color capabilities of the VDP/TI. So, superfluous horizontal color bars and candy-like coloring here and there. The pic is a bit rough in the details but I supposed that as the authentic target is a television tube, it would not matter so much.


Alien (160x200 Commodore 64 multicolor bitmap)

The second image was made to enhance a cracked C64 version of the game Alien (1984), based on the film. The Hokuto Force crack (Alien +6DG) enhances the original and I was asked for a xenomorph pic to accompany the release.

Somehow it reminds me of the Mortal Kombat logo?

I now examined some images of the Alien, going back to the original film props when possible. The more I looked at images of the actual suit that was used in the filming, the less impressive it became. Don't get me wrong, Giger's work is obviously a classic. It's simply that the way the prop/suit is used in the film does not reveal how humanoid-like the costume really was.

So, the mystique of the Alien is not only about showing it in very few scenes, but also revealing very little of the actual shape, the guy-in-a-suit nature of it. I wonder which then is the "correct" alien, the impression left by the film or the actual prop used?

However, these thoughts did not really impact the result that much. This is more a graphic emblem of the Alien than an impression. I changed the proportions a bit, exaggerating the tail size and shape to create a circular composition that is partly reinforced by semi-circular elements in the centre.

The game is pretty neat, I've played it on a ZX Spectrum a few times. It's a bit similar to the later Shadowfire in having multiple characters that are real-time icon controlled. According to World of Spectrum, John Heap has worked on both of them, so that maybe explains the similarity!

Info about the release at CSDb


Beam Us Up (16x23 characters PETSCII directory art)

The third image is my first attempt to make "dir art" for the Commodore 64. Directory Art refers to graphics made inside the directory portion of the disc filesystem. So instead of seeing the ordinary list of files via LOAD "$",8 there are logos and visuals instead. Crackers and demo groups used to embellish their releases with such graphics, and still do.

Screenshot of the directory, but LOAD "$",8 is the real way to experience them.

I made a very old-school PETSCII that fits the screen. My main motive was to include the " characters into the image, as these normally frame the filenames. I came up with this Star Trek themed pic, a little bit related to the non-standard PETSCII of Mr. Spock that I once made for the print magazine Skrolli (see below).

In my dir art the " characters work as edges for the transporter beam. Also, there is always some motion inherent to a directory listing so Spock and Kirk are sort of being "beamed". This could have been enhanced by having a longer dir list.

Once again I used Marq's PETSCII editor to create the image. The c1541 tool was used to generate a D64 disk image with a bunch of files with dummy names. With a hex editor I collected the offsets for the file names. I then modified the PETSCII editor to overwrite the D64 file using the offsets. The character encoding also needed to be changed for the directory environment. Afterwards the file identifiers were trashed in such a way that the first file could not be loaded, again with the hex editor.

The file at CSDb

The CSDb dir art compo

A "non-standard" PETSCII, for Skrolli magazine

Fort Django v1.1

I made a small update to my Commodore 64 game Fort Django. The most important changes are:

-A choice of a whole new map with new background graphics
-New enemy behavior (in the new map)
-Music and Sound FX and a choice between them

The old game mode (map1) should play almost identically as before.

Use joystick in port 2. Turn up and down in the title screen to select the map. Turn left and right to switch between sound fx and music. Fire starts the game.

As before, you shoot enemies and try to find the exit. Collecting bags gives extra bonus depending on how quickly you have moved from the last bag. (The bonus keeps decreasing from $900)

Internally, I changed a few things to make the new map fit. The memory use was extremely lazy in the old version. Many c variables and arrays are now changed to direct memory read/writes. I relocated these higher up, so the compiled code and data area have more room to breath.

I added a scanline interrupt for the music routine, which plays out the in-game music I created with Goattracker 2, using subtunes for different program sections. The main game tune can be turned off. The sound effects make use of the Goattracker sound fx routines which are simple but suitable for this type of game. If the music is off, there are more sounds, but one channel is always reserved for sound fx. I'd say overall the sounds are better than the old ones, even though I sort of miss the sharp gunshot sound. The tunes try hard to sound something between Rambo/Platoon but a Galway or Dunn I ain't.

The sprite updates are more rigorously done during the vblank so I have more time during the frame for doing other calculations, should they be needed. However the game pretty much runs during the vblank anyway.

The new map takes the player to a vaguely central american temple, giving the game some more of that Pitfall/Rick Dangerous vibe. The new map has a bit different play style too. The rooms are more open and there's more opportunities for platform game elements.

There's new enemy behavior in this new map. For example, the enemies only shoot when facing the player. The enemies can also crouch like the player, so the player can't use always the same trick when entering the screen. Some of the enemy behavior and timing is adjusted on a room-by-room basis, so the rooms can contain a small pre-defined "action puzzle".

Internally, the two enemies are switched occasionally. Inside the program logic only one of them does the shooting and crouching. But the switching gives an impression of both having the same freedom. This is not especially elegant but given how the two enemies have been programmed it's a nice fix.

The splash screen and ending have been adjusted, but I felt a weird respect toward the old map and did not alter the graphics there at all.

It was nice to revisit the program, but in the future, I'd probably prefer making something new than try to continue adding to Fort Django.

About the first version

Fort Django v1.1 at CSDb