Monday, 1 August 2016

The great MSX aspect ratio swindle


Edit: The whole text is a bit silly because I did not use Screenmode 2 on the MSX, which makes the screen wider. I still think the "method" may be of interest, hoping I can some day do this better.

I photographed the screen of Commodore 64, MSX (Toshiba HX-109, Commodore 64 (Beige, not sure of exact issue) and ZX Spectrum (Issue 2) from the same position, using the same display, a Sony from late 1980s (or early 1990s). All outputs are composite. The C64 has a clear border from the boot-up, on the MSX I inserted some characters in crucial positions. With the Spectrum I used a routine for filling the attribute memory, as the BASIC does not easily allow setting the true border color.

The inspiration came from this blog post. There's a tendency to portray MSX pictures and videos on the web with a ratio that is not very true to life. But are then MSX screens radically different in shape compared to Spectrum screens?

In the following I simply overlay the photographs using GIMP layering and opacity. The pics are of horrible quality, but at least they are from the same position. What I like about this "visual method" is that I'm not asking what is the "real" specified aspect ratio of the computer output, but how the C64, Spectrum and MSX aspect ratios relate to each other on a real hardware.

Of course this leaves out the possibility that different displays react differently to the video output, which might result in exaggerated or diminished difference, who knows. Some monitors had easy access to adjusting the horizontal and vertical stretching, muddling the issue a bit further.

Well, off to the comparisons.

Overlaying the Spectrum and MSX images reveals a difference. Though the images are obviously of the same height (the spectrum image starting and ending a bit before the MSX one), the Spectrum is clearly narrower.

Overlaying Spectrum and MSX screen on GIMP. (Spectrum is the light rectangle)
Comparing the C64 and MSX is a bit trickier as they do not have the same pixel resolution. So whereas the screen shape is pretty similar between the two, C64 has 320x200 whereas MSX and Spectrum have a 256x192 resolution. From the screenshot it's quite clear the C64 has 8 pixel lines "above" where the MSX screen starts.

Commodore 64 and MSX screen overlayed. C64 screen is indicated by the dark blue area.

Here's the C64/Spectrum overlay. There's 64 pixels more horizontal resolution to c64, which shows roughly as a four-character width difference between the screens. Edit: Previously I thought the 4 characters corresponded with the 64 pixels, but this was a thought error. (8 characters would do.) So the pixel aspect ratios are a bit different.

Spectrum and C64 screens overlayed. Spectrum is again the light rectangle.

Ok, and then, all together. Red is Spectrum, Green is MSX, Yellow is C64.
Edit: in MSX Screenmode 2 (basically all the games) the green box would extend very near to the right border and slightly over the left border.


I also used GIMP rectangles to approximately calculate the screen proportions from the images, but this is less valuable because the photographs are distorted.

Spectrum: 1,45 (256 x 192)
MSX: 1,67 (256 x 192)
C64: 1,58 (320 x 200)

What follows is not true in any absolute sense, but if the Spectrum screen is like the black box above, then in comparison to that, the MSX screen (mode 0, 240x192) appears as the one below:


Saturday, 23 July 2016

Fort Django

A little reflection on the making of a Commodore 64 game. It's the first C64 machine-code game project I've really finished. All right, it was made with cc65 C with inline assembler but what I mean it's not made in BASIC. Significantly, it's the first 8-bit game I've made public in some way.

I guess making an 8-bit game is something I would have liked to do for a long time. Fort Django was started in 2014, and after a long pause I found the energy to make it into a release.

Djangooooooooohh....!
The game

You guide the character with a joystick in port 2. You can run, climb, crouch, jump and shoot. Shoot down the baddies, collect money bags and find the exit. The descending bonus timer means the faster you can collect the next bag the more $ you can get.

The game is very short and not at all hard. The only challenge comes from trying to be faster, for example it's possible to break the $10000 barrier on completion.

Get that bag, shoot that baddie
Inspired by Saboteur! from Durell, I at first thought about making a beat 'em up oriented game. As I needed to scale down the project I found it would be simpler to turn the game into a shooter with a western theme. The map is very small, but then again I like short games such as Saboteur! and Bruce Lee, as they have a strange kind of replay value. Much like with Saboteur!, I wanted to ensure there was a definite ending to the game and score could not be milked forever.

Making of

I created the game with cc65 C compiler, using inline-assembler for speed critical parts such as the sprite routines. The C64 has eight sprites, eight 8-bit addresses for the horizontal coordinate (0-255) and one address that holds the highest bits for all the X coordinates, so the sprites can also reach the right hand part of the screen. (256-320)

For a beginner it can be a bit tricky to decode these 9-bit sprite coordinates, especially in pure assembler. I have eight separate 16-bit memory locations for storing the X coordinates. These are then broken down into the hardware sprite coordinate values. This approach is a compromise between ease of use and speed.

The figure below shows how the 16-bit X coordinates are stored in $C000/$C001, $C008/$C009, $C010/$C018 byte pairs (the grey stuff in the middle). The less significant byte of these 16-bit values can be copied directly to the $D000, $D002, $D004... but the high bit is taken from the lowest bit of the most significant byte of the 16-bit values and combined into a value that is stored in $D010.


This is done once in a frame, so the high-bit issue can be forgotten in other parts of the code. The handiness of this is only really apparent in C, where you can then move the sprite x coordinate around with:

*(unsigned*)0xc000=*(unsigned*)0xc000+1;

Comparisons between coordinates become easier, too.  This checks if sprite 7 is right of the sprite 0:

if(*(unsigned*)0xc038>*(unsigned*)0xc000){do_stuff();}

Basically all the "collision detection" is built from this type of statements instead of the hardware sprite collision address, and as such is not pixel perfect. In these box-collision cases it's better to be lenient toward the player and a bit biased against the enemies.

The "16-bit" coordinate ought not to exceed 511, because only one bit is taken from the more significant byte.

The sprite Y coordinates are 8-bit values anyway and can be handled directly with the $D001, $D003, $D005... hardware addresses.

The whole X coordinate copying is achieved with the code below, starting from the less significant byte copying and ending with the high-bit construction. Obviously other locations than $C000- can be used for the coordinate storage.

     lda $C038
     sta $D00E
     lda $C030
     sta $D00C
     lda $C028
     sta $D00A
     lda $C020
     sta $D008
     lda $C018
     sta $D006
     lda $C010
     sta $D004
     lda $C008
     sta $D002
     lda $C000
     sta $D000

     lda $C039
     clc
     rol a
     ora $C031
     rol a
     ora $C029
     rol a
     ora $C021
     rol a
     ora $C019
     rol a
     ora $C011
     rol a
     ora $C009
     rol a
     ora $C001
     sta $D010

This is a starting point for a fairly generic solution, but of course it can be adapted for any particular needs. For example, the top sprite coordinates of the dudes in the game are copied and transformed from the bottom part coordinates, which changes the above routine a bit. Also, if less sprites are used why bother going through all the eight?

About the graphics

The graphics are made with PETSCII editor. Not only the background tiles, but the game map and even the sprites have been edited there. It goes to show that the PETSCII editor multiframe-editing is surprisingly powerful way for controlling this type of game "assets".
The game map tiles.
Another PETSCII screen was wasted for defining the movement rules for the above tiles. These are used for building a movement table every time the player enters a room, just as the room is drawn from tiles. How all these sprite, tile and movement table elements exactly relate to each other is a bit too intense to explain here, especially as they are not that well thought out.
The tile movement rules. @=space, A=block, B=platform, C=ladder
The map was also edited in the PETSCII editor. The 40x25 area is divided into 5x3 tile elements, giving 64 simple screens. Coloring indicates enemies and money bags. Not everything is absolutely visible in the picture below, as some spaces can be "colored" too. The game engine allows only certain combinations and positions for the enemies and objects.
The game map.
The map memory area is also used for indicating whether objects or enemies are removed, from the 1 (white=enemy) and 2(red=bag) status into 255 and 254. After the game is over these are changed back into 1 and 2.

Editing a multicolor sprite in PETSCII editor. The sprite export is not a standard feature!

What next?

I dropped many game elements I toyed with at some point. For instance, the chests could have contained items, and the doors could have potentially led to other areas in the fort.

The gold bags were a fairly late addition when I felt that only shooting bad guys would be far too minimal. From adding the bags it was a small leap to increase the jumping elements in the game. The bags also inspired the time-based "bonus dollars" mechanic. Still there might have been a bit more to do.

Code-wise, a music routine would have been nice but in the beginning I was a bit scared to sync the animation with a music interrupt. The sound effects are also sparse due to my inexperience with SID.

Yet, all additions would have also expanded the complexity of the game and the testing time exponentially. I'm glad I could finish it as it is. With this experience I already have some ideas about how to approach this type of project better.

Links

You'll need a Commodore 64 or an emulator to play the game.

Direct download
Page at CSDb
A cracked version in a T64 format

Monday, 18 July 2016

New 8-bit pictures

Here's some pictures I made with Multipaint and the PETSCII editor. I participated in the Vammala Party 22 graphics competition held at Ikaalinen, Finland in 16th of July, 2016.

#1. Star Kerk

The first one is an MSX picture. I worked with the wrong aspect ratio (because Multipaint) and here I have approximated how it might look on a real screen.

Apart from the obvious Star Trek connection the image was inspired by the bridge of USS Pisces from a game I played long time ago on MSX, Knight Tyme by David Jones. (Spectrum screenshot below).


#2. Imjärvi UFO Incident

This is a C64 multicolor image. It is loosely based on the artist impressions made of an alleged UFO encounter at Imjärvi, Finland in 1970. However, I focused more on the colors and atmosphere than trying to include all the "facts".

#5. Botbot

I finished a PETSCII image that has been lying around for a while. I think it turned out ok, but I could have worked on the background a bit more.

#11. Fompo Killer

Another C64 multicolor, but with much less effort. It turned out the compo did need no fillers really :) I think it's nice for something that was done so quickly.

The graphics competition results in full. (in Finnish)

Thursday, 7 July 2016

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.

Wednesday, 22 June 2016

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.

Saturday, 18 June 2016

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, 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 great 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 effectively. I gave these features a poor-ok-good-excellent ratings. I thought about reviewing the functions such as copy/paste, but they are sometimes a bit 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 a bit 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 pretty 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 pretty 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


Monday, 13 June 2016

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.