PETSCII games

Here's some screenshots from older Commodore 64 games with visuals made mostly with PETSCII, the internal character set.

It seems that in the early days of 1982-1984, programmers took the character set pretty seriously. Well, there probably were not that many tools for producing bitmaps, so the character set provided an easy and memory-efficient entry to the world of visual games.

Many commercial games were even produced in BASIC, and in there text/PETSCII was pretty much the only choice, as the C64 sprite commands were so slow.


Back to Nature, 1982 Commodore

A simple but ingenious game where pressing keys 1-9 will direct the tongue of the frog to different parts of the screen. For such an old BASIC game it's pretty impressive and the use of PETSCII is already quite sophisticated.


Lemonade, 1982 Commodore Educational software

A bit of a cult game, this. At one time it seemed every type-in BASIC game for a computer was something to do with fiddling money and resources. At least there's something to see here. The PETSCII use is quite minimal, we're talking almost text art here, but as the game is so old I wanted to include it.

Commodore Educational published a huge amount of tiny math/physics/history etc. quiz and workbook type software, which have a nominal amount of character visuals in them.


The Attack of the Phantom Karate Devils, 1983 Phantom Software

Can't help but to mention this game. Me and some of my Karate-hungry friends would play this in absence of better games! It's not that bad and pretty much precedes the entire 1980s beat-em-up craze. Both the logo and the game background make use of simple PETSCII, the very definition of "old school" text graphics. Later sprite and bitmap-based efforts made this kind of game look very primitive.


Murder, 1983 Rabbit Software

Here I'm mostly impressed with the two-story building plan rendered in PETSCII and displayed in parts. The game is very slow but rather well done murder investigation game. The program builds a random murder case and you have to solve it by logically deducing the killer from the answers you get from people.


The Secret of Bastow Manor, 1983 Computer Classics Pty

An early text adventure made in BASIC, with quite poor PETSCII visuals. At least it is somewhat atmospheric, though, from what little I played it. (Obviously it's very slow.) Combination of PETSCII with text adventure was quite common back in the time, and there are numerous examples in different languages.


Stroker, 1983 Magic Carpet software

An infamous yet iconic 'ma5turbati*n simulator'. Enough said.

(Well, ok, the PETSCII animation is actually pretty well done for something so old, I just won't show it here. Find the game at your peril...)


Snoopy, 1983 Commodore Educational software

Goddammit, I thought the wonky sprite-driven Radarsoft Snoopy (which BTW also has PETSCII backgrounds) was the first Commodore outing of that character. What sad state has Snoopy declined into, he seems to have more in common with Rudolf the Red-nosed Reindeer than a WWI ace.


Murder on the Waterfront, 1984 Softgold

Softgold made a few of these games with the same "engine". Here we have an inventive PETSCII logo (+ some ads in PETSCII before the game) and the game appears to be the same murder-fare as before, but in a more text-adventure vein. The character sports a Dick Tracy-style watch, rendered in glorious PETSCII. But I could not get into the game really. Could-a-been a contender, though.


Alien, 1984 Softgold

Here's Alien from the same. The initial scenario is pretty intriguing, you are driving a car in Arizona desert and spot an UFO (an animated sprite). Then you encounter an Area 51-esque compound but can't get in without any credentials. Hmm....

The environments seem better than in the 'Waterfront, there's even some attempts at one-point perspective as can be seen from the piccy.

Apparently Alien was also published for the Sega SC-3000, but with crappier line-based pictures.


Subsunk, 1985 Firebird

Subsunk is yet another plain old text adventure created with an adventure writing package. It's a bit better than the earlier BASIC efforts, and the pictures have been cleverly combined with the text box to form graphic layouts. In fact I suppose the pics+text are both contained in the same data. I don't know how common this was at the time, but clearly it's an easy way to integrate some neat visuals in an adventure. The Firebird logo is pretty decent!


The Toy Store, 1988 Loadstar/Softdisk

Just an example that even fairly late, commercial software could excuse having PETSCII visuals if the theme was "educational". The letters have been changed and there are sprites so it's not so pure PETSCII. The layout appears borrowed from Donald Duck's Playground, though.

Horizontal starfield in BASIC

Scrolly stuff is a bit hard in eight-bit BASIC, so of course it had to be tried.

Horizontal scrolling is an interesting case as the environment usually does not have special commands or ROM calls for that. Also, starfields are kind of easy/fake scrolling as there's no real bitmap or background to move.


Commodore 64

In the first version, I was silly enough to use dimensioned arrays and a FOR-NEXT loop for drawing the eight stars. POKE seemed slow in this context and I abandoned it for a while. The C64 BASIC does not have a LOCATE or PRINT AT command, so the horizontal/vertical coordinates had to be handled with the TAB function and/or character control codes. This means that for the speed of the program it is not trivial where the stars are vertically. I settled for 8 stars with one row between, filling about 2/3 of the screen.

I did know from experience that it is not necessary to test each star x coordinate every time the coordinate is reduced. After the eight stars are moved, only one of the star coordinates is checked. With stars it is acceptable if they disappear at a bit randomly near the left side of the screen.

For the second version, I unrolled the code and did away with the DIM at the same time. So each star has their own separate variable. Because of the single-star coordinate testing, the star printing is unrolled eight times, and after each printing only one horizontal coordinate is compared.

40 print chr$(19);tab(xx);"* ";chr$(17):xx=xx-1
41 print tab(xa);"* ";chr$(17):xa=xa-1
42 print tab(xb);"* ";chr$(17):xb=xb-1
43 print tab(xc);"* ";chr$(17):xc=xc-1
44 print tab(xd);"* ";chr$(17):xd=xd-1
45 print tab(xe);"* ";chr$(17):xe=xe-1
46 print tab(xf);"* ";chr$(17):xf=xf-1
47 print tab(xg);"* ";:xg=xg-1
65 if xx<9 then poke 1025+xx,32:xx=35

(repeated eight times, with the last line comparing a different variable)

I also tried to combine the character formatting codes and printed stars into one long line, but this was a bit slower.

By using POKE instead of PRINT "* "; statements, although previously unsuccessful, I could now get an extra bit of speed. The third starfield is faster, but it also flickers a bit. Possibly not so visibly on a tube TV.

20 poke ba,32:ba=ba-1:poke ba,42
21 poke bb,32:bb=bb-1:poke bb,42
22 poke bc,32:bc=bc-1:poke bc,42
23 poke bd,32:bd=bd-1:poke bd,42
24 poke be,32:be=be-1:poke be,42
25 poke bf,32:bf=bf-1:poke bf,42
26 poke bg,32:bg=bg-1:poke bg,42
27 poke bh,32:bh=bh-1:poke bh,42
29 if ba<1032 then poke ba,32:ba=1063

(repeated eight times, with the last line comparing a different variable)

One advantage is that the POKEd stars can be more freely located around the screen, but also their color is not specified and in principle the color memory could be pre-filled with interesting colors.

The alternative would be using a char display that is pre-filled with * and the POKEs would address the color memory.

A larger number of stars, or even a kind of parallax is also possible, but I want to keep the program version speeds easily comparable.

I used petcat (one of VICE package tools) to convert text files into a basic PRG.

All three starfield program versions are downloadable from here:

http://csdb.dk/release/?id=148877


ZX Spectrum

I could transfer the above insights into a finished result almost straightaway. The screen memory is filled with ****oooo---- type pattern and the attribute space is filled with black-on-black.

Then the POKEs adjust the attribute memory just as the Commodore 64 version used the character screen memory. This way it's possible to have some advantages of a character display on the Spectrum bitmap screen, as shown in many machine code demos and games.

I also tried a PRINT AT -based version that does not use POKEs. It might be just a tiny bit faster than the POKE-ing, but not enough to justify it.

Perhaps surprisingly, despite all the talk about Commodore Basic being slow, the ZX Spectrum version is not really faster. It's a bit difficult to compare through eye-ball judgment, but given that the Speccy screen is 32 characters wide and C64 is 40, one might even say the C64 BASIC is more effective here. Obviously this character-based starfield is not an indicative comparison of the two Basics overall, for example bitmap graphics is practically impossible on C64 Basic.

I used zmakebas to convert text files into a TAP.

Download the zip with the TAP and the text file from here.


MSX

I made a short attempt at replicating the approach with MSX basic, where I had to use a LOCATE/PRINT based approach as there's no real way to POKE directly to the screen.

I could not easily find an equivalent of petcat/zmakebas so I simply wrote the listing in an emulator. However I crashed my openmsx trying to save the machine state so the motivation for the project sort of dwindled. But what little I got did seem a little faster than the Spectrum and C64 versions. I could not really go into potential SCREEN 0/SCREEN 1 differences, though.

Round up: Commodore 64 Text editors and word processors

Some time back, I looked at my Commodore Plus/4 computer and the not that great built-in text editor. I began to wonder "what could be", and the result is a quick look at some Commodore 64 text editors. Well, for most part the programs are not that great either, but there are a couple of surprisingly good efforts.

I was surprised to see how old most of these programs are, and thus the problem is not so much the C64 but the fact the programmers had not yet learned much. So perhaps it can be forgiven that around 1983-1984, when the Plus/4 features were decided, there were no good examples around.

This is by no means an exhaustive list, but rather an illustrative one. I've deliberately excluded one well known program, GeoWrite, because it is so tied to the GEOS setup. The desktop publishing software (!) Pagefox also includes an editor. There are also "conversions" of Vi and Emacs I ignore for now.

I was mostly interested if the central "typing experience" was good quality or not. To use these programs at all in today's environment you'd need to be able to a) type quickly, b) insert effectively and c) scroll rapidly to view the document. I gave these features a poor-ok-good-excellent ratings. I thought about reviewing the functions such as copy/paste, but they are often just too difficult to find. And yes, I admit I did not use the real Commodore 64 to check these out.


Vizawrite

Looks more professional than most, with indentation and typewriter-style tabs and formatting characters. The cursor behaves pretty much as it ought to, but I could not find any proper insert mode to see if it delivers. At least there is the insert key and a means to "insert" typed text as a special command. The delete/move/replace/find functions are quite easy to find and operate.

Typing speed: Good
Insert: Ok
Scrolling speed: Ok


Speedscript

Speedscript looks like one of those desirable minimalist editors that might really work very well, but the basic program functionality is a bit erratic for today's typist. It's fast enough, though.

Typing speed: Good
Insert: Good
Scrolling speed: Good


Easy Script

Screen colors change from Control+1,2 and 3. Insert works pretty quickly, after setting the insert mode it works almost as you'd expect a modern text editor to work. It's slow at times, at least when inserting carriage returns inside paragraphs.

Typing speed: Good
Insert: Good
Scrolling speed: Good


Paperclip

Not bad at all, but hampered by slow inserting of whole lines. Otherwise the insert works well. Control+keys bring out features almost from every key, so I guess it's comprehensive. There's find and copy range type functions. F2, F4 and F6 change screen colors, a welcome addition.

Typing speed: Good
Insert: Ok
Scrolling speed: Good


Tekstinkasittely 80-400

An early Finnish effort with 80-column display. Don't be fooled though, the text has to be typed in line-numbered entities and even then it's slow. I'd rather work my text in Basic REM statements.

Typing speed: Poor
Insert: Poor
Scrolling speed: Poor


TasWord

I think this originated from the ZX Spectrum, where a 64-column mode was very welcome compared to the standard 32. Here we have 80-column mode and it's surprisingly smooth. However text insertion does not work as one would nowadays expect, and inserting carriage returns inside paragraphs results in a long pause. There are different versions of this software, so perhaps some of them work better.

Typing speed: Good
Insert: Ok
Scrolling speed: Ok


Paperback Writer

An overall good show, I'm just wondering about that large help/options bar at the top. I suppose there would be an option to reduce it. But hey, the "on-line" help is very comprehensive compared to many others on this list. Inserting works semi-ok.

Typing speed: Good
Insert: Ok/Good
Scrolling speed: Good


Kwik Write

From Fairlight, a standard text editor, but boy is it fast for both typing and inserting text in-between. The basic text typing, removing and cursor motion is what one would expect these days, with no hiccups. The program also keeps track of how many characters of memory are left. I could even consider using it for some real text editing.

Typing speed: Excellent
Insert: Excellent
Scrolling speed: Excellent

Apple Museum Prague

Somewhere in the most touristic arteries of Prague, there's the Apple Museum. How could I resist?
They have "all" Apple computers on display (expect that other Lisa).

Is it interesting? In some ways it's nice to see all the products lined up on tables, giving an overview on how the stylings have developed. The original iPhone/iPod, for example, seems quite clunky and not that different to other stuff on the market at that time. Also for a retro-head like me it's sobering to see how few late 1970s and early 1980s models there really were compared to the later flood of products. There's a few NeXT boxes too though they are not Apple products. Goes to show how Steve Jobs-oriented the display really is.

And that's about it. There's not much else to see except the casings of the products, little attention is given to how they work and what could be done with them. Yes there are videos and texts but it gets a little boring very quickly: speeches praising Steve Jobs' genius are blaring out of the speakers constantly. Granted, effort has gone in making the environment stylish. If there had been a museum shop (promised in the future) there at least might have been some books or gadgets.

It does make me think, how and why this place exists. It's a tiny step towards historicising Apple and Steve Jobs and attempting to codify Apple's success as the evolutionary survival of the fittest of home computing. On the other hand it's just another tourist trap "museum" in a city of "museums." (Beer/Torture/Sex Machine/KGB/Communism whatever) I'd give it a miss unless you already have a zillion other reasons to go to the neighbourhood.

c1541

Just so that I remember.

To create a d64 image from a command line (e.g. Linux terminal) with the c1541 tool, part of the VICE package.

c1541 -format floppyname,0 d64 mydisk.d64 -attach mydisk.d64 -write myfile.prg filename

The floppyname is the disk name in the c64 filesystem. mydisk.d64 is the name of the disk image file on your pc filesystem. The myfile.prg is the file you want to write. The last name, filename how the filename will appear in the c64 filesystem. Use lowercase for both diskname and filename or else.

Format a new disk image:

c1541 -format myfloppy,0 d64 diskette.d64

Format a new disk image and write a file inside it:

c1541 -format myfloppy,0 d64 diskette.d64 -attach diskette.d64 -write idiotprog.prg idiotprog

Write a file into an existing d64 image:

c1541 -attach diskette.d64 -write idiotprog.prg idiotprog

Read a file out from an existing d64 image:

c1541 -attach diskette.d64 -read idiotprog

Commodore Plus/4

Thought I'd say a little about Commodore Plus/4 now that I'm a bit more familiar with it. When I got this computer I expected to feel the kind of enjoyment when exploring Panasonic JR-200. I can't explain why. Neither can I explain why it didn't turn out that way. It's still an interesting computer, though.

Compared to how well-known C64 and VIC-20 are, Plus/4 can be called fairly obscure. At least I never saw a physical Plus/4 in Finland back in the day.

Instead of going upward from C64, Commodore decided to go a bit sideways and somewhat back with this computer. From a manufacture perspective, the C64 was perhaps a bit troubled with having so many of those glorious chips, so creating simpler hardware seemed attractive.  Goodbye VIC and SID, the TED chip takes care of it all.

The Plus/4 has more than 60k available for BASIC programming, accessible graphics modes and built-in software packages. Outwardly there is something of the 'spectrum' in it, what with the black plastic case and polygonal shapings. Even the boot-up screen seems like a concession towards Sinclair sensibilities: a grayish white background.

Left: The BASIC listing. Right: the output. Note the split graphic/text mode.

The BASIC has more features than before, though I'd say in user-friendliness it's not equal to Sinclair BASIC or the MSX implementation of Microsoft basic. Neither is it as versatile as the QL SuperBASIC or Amstrad BASIC.

GRAPHIC 2 gives the bitmap mode and GRAPHIC 0 gives back the text mode. Cleverly, using commands like INPUT in middle of GRAPHIC 2 gives a split-screen bitmap/text mode. Lines, rectangles, circles, flood fills etc., all of course are very slow. For once, there is a command for clearing the screen: SCNCLR.

Fortunately the computer has a typewriter keyboard, even though the uniquely styled cursor keys have been only half-thought out.  Surprisingly, my keyboard does not work as well as thirty-year old C64 keyboards, even if I suspect it has not been used that much.

The built-in text editor.

Commodore floppy drives and SD2IEC work with Plus/4, so it's possible to access the software catalog or do at least something meaningful with the computer. The new type joystick connector is simply silly.

Graphics are nominally better than in the Commodore 64, but the resolutions and text modes are pretty same as in the C64. The usual PETSCII text graphics are in effect, which is a good thing. An 80-column mode might have been welcome but nothing outside of a monitor would have displayed it in a satisfactory manner anyway. 121 colors sounds a lot but the palette is dominated with pastels.

The color palette appears a bit suspect when shown in its totality, but people have made some amazing pictures with it. The trick I suppose is not to try to modulate the colors with the luminosities directly (like below) but find smooth gradients by using different parts around the whole palette.

The built-in software is a waste of potential. One would imagine that a character display-based text editor would be fast and responsive, but here the implementation is slow. The rest of the package is more like extended support features for the text editor rather than proper software.

One good feature is the built-in machine code monitor, accessed by typing MONITOR in Basic. A monitor is very helpful for at least educating the programmer. Perhaps a full-blown assembler instead of the 3-in-1 package might have made the computer even more interesting. Sadly, without the added boost of the C64 chips the processor is left to do everything and compared to the Z80 the 6502 is not quite up to the task.

Cross-developing for the Plus/4 is pretty similar to C64, simply use cl65 and -t plus4 as parameters.

The following activates the hi-res bitmap mode and sets it to start from $4000 onwards.

LDA #$20
STA $83
LDA $FF12
ORA #$10
STA $FF12
RTS

Colormap starts at $1C00 and luminosity from $1800, both $400 long. Border is at $FF19.

With the Plus/4, Commodore introduced a new line of computers that were not meant to be any more compatible with the C64 than the C64 was compatible with the VIC-20. It was maybe hampered by a public perception that whatever Commodore made ought to be a continuation of the C64 thinking. Later days have shown the Plus/4 to be a quite capable and robust little 8-bitter.

Plus/4 World

Plus/4 at Wikipedia

iCade to Atari 9-pin

iCade arcade style stick on the C64, not unpossible!

Like many retro-heads, I was wowed for a while by the Apple iPad. It seemed that most interesting retro game stuff happened on that platform. But in the end I realized that the device has a major flaw: the touchscreen.  So I went and bought the iCade bluetooth arcade stick. This turned out not to be that great an addition, so it mostly gathered dust in some corner. (Well, mostly I was disappointed with the increasingly degenerating iPad)

When I needed an extra joystick for the C64, I opened the iCade to see what could be done to convert it into a good old-fashioned 9-pin Atari/Kempston joystick. I am aware that this must have been done dozens of times by different people, but I just refused to google it.

I used a breadboard to connect all the ground wires, but this is a bit extravagant.

Funnily, I did not need to solder anything. All the buttons and stick directions are very neatly connected to the tiny circuit board with such headers that easily connect to "jumper/dupont" style wires common in breadboarding. Also, all the ground wires from each button and direction switches are clearly marked black. I guess this all might be part of the intended design and greatly increases the value of the iCade in my eyes.

Example of the iCade header (left) almost connected to a jumper/dupont wire (right). 

Admittedly, what made life easier was that I already owned a couple of very useful pieces. The 9-pin doohickey shown below is a cannibalized COM-port header/connector from a tiny Linux computer I bought from a fleamarket (now destroyed). It's very robust as the connector solder points have been drowned in epoxy. Similarly the 9-pin extender cable is something I have had around for who knows how long. The gender changer was needed in between.

The COM-port thingamajig taken from a linux box, plus a gender changer. The jumper cables don't fit too neatly into the COM-header, though.

It took the longest time to figure out the correct pins, because I was tired. I won't include the diagram now as I'm prone to get it wrong. The Atari 9-pin schematics are lying around the net, but it's not always clear whether it's the jack or the port side. Once the ground has been figured out the directions can be checked one at a time. Wrongly connected pins can mess the C64, especially the CIA chip so take care.

Frankly, the iCade is not ideal for home 8-bit games, as the joystick travels a bit too much compared to, say, TAC-2. The fire buttons are delightful though. For Decathlon-type games, one might even consider connecting the buttons to directions. The neat thing about iCade is that there are numerous buttons, so perhaps in the future I could be motivated to do something a bit more ambitious, like one of the buttons as space bar or other keys.

The backside. Batteries not required!