Sunday, 25 September 2016

The Crappificent Seven *)

Years ago I made a list of Top Westerns movies. Well, now here I have some of the less inspiring western films I've seen.

Some words of warning: There are worse films. These are at least watchable in some way. Yet I hasten to say that for the most part these are not "so bad it's funny good". What do I mean with "watchable?" For example, Blazing Stewardesses (1975) is much worse than anything on this list because I could not bring myself to watch it to the end.

Ok, that's enough, here's the list:

Captain Apache (1971)

A singing Lee Van Cleef in a crappy British faux-spaghetti western. Also, tiresomely brutal and corrupt Mexican revolutionaries etc. What is the mystery of "April Morning"? Ooh, aren't you just dying to know! (Hint: In the end it doesn't even matter)

White Comanche (1968)

As Clint Eastwood ascended from a TV career via European westerns, many were undoubtedly seeking to repeat this success. Here, William Shatner plays two roles in this stupid western made in the heels of better productions. I know what you're thinking, but no, although some laughs can be had here, for the most part it is a dull affair.

But WHICH of them died? Eh? Eh?
Consider two identical half-breed twins, one who lived with the white people and the one with the native Americans.  Does a thoughtful essay on nature and nurture ensue? Well, apparently nature does not so much abhor a vacuum, but redundancy, so a duel inevitably ensues between the two forces. This calls for an ancient Apache ritual... A joust on horseback, with revolvers.

(Trivia: Leonard Nimoy played a western villain in a slightly better film Catlow.)

Lucky Luke (1991 / 2009)

Lucky Luke is such a household name that for a certain generation of Europeans the whole idea of a western is tinted with the humor and caricatures of the Morris and Goscinny comic strip. It's a bit sad that the concept did not result in any good live action films.

The first tries to translate pick'n'mix elements from the comic book too directly to the screen, whereas the 2009 version attempts to cram every possible meta-reference about Lucky Luke and western cinema into one film. Luke is also given a totally unsuitable tragic "origin story" and the makers tried very hard to be post-modern. They succeeded.

I think it's pretty safe to say that Les Daltons from 2004 is not too good either, but I've not seen it (yet).

Trinity and Sartana (1972)

As a rule of thumb a prolonged "barfight scene" is a good indicator of a poor-mediocre western (as opposed to just some minor violent exchange in the saloon). Well, this film climaxes with a ten minute bar fight scene at the end, and man, isn't it comedic.

Trinity and Sartana were well established names in their own official and unofficial movies, here the names are exploited for something that has nothing to do with either. Trinity is really "Trinidad", while Sartana, who looks more like actual Trinity, does some acrobatic tricks.

Apache Blood (1975)

Frankly I can recollect almost nothing about this borefest with poor editing and disjointed scenes. On second thoughts, I might have been watching Andy Warhol's Lonesome Cowboys. 

Yes, it's bad to the point I was wondering if it was really supposed to be an art film.

Django's Cut Price Corpses (1971)

Aka. A Pistol for Django.

Well, it might be said that as a rule of thumb any unofficial "Django" movie that isn't the original Django, Django Kill! or Django Unchained, could compete for inclusion in a list of bad westerns. I wouldn't go so far, as some "Djangos" are quite reasonable. This one's pretty stupid, though.

There's a guy who does not look or behave like Django at all, the plotline is quite incompatible with anything we know about Django, and overall it doesn't make much sense. The twist ending makes the Django-premise even less credible. (It's of the "he planned it all beforehand" variety)

Left: From the bottom of the barrel, Right: Poetic justice.
There's a group of Mexican brothers and one sister (no great spoiler there, it's very apparent she's a woman) who all seem to be inadequate at accomplishing anything. Notably the film has quite many woman characters for a western, but this simply means a lot of women getting slapped on the face or otherwise mistreated.

Tex and the Lord of the Deep (1985)

The idea of western characters encountering an ancient pre-columbian mystery is not that bad, but nothing good comes out of it here.

I've always considered Tex Willer to be dry reading, but here the filmmakers have really been able to expand on that quality: there's a lot of time-wasting and all the sets are very lackluster. The same lethargic tune seems to play throughout, and any craftsmanship that made Italian westerns interesting seems to have been forgotten.

Only the guy dying from the super-poison is a relatively interesting special effect, and spaghetti-veteran William Berger makes a passable Kit Carson, not that the role involves much more than having a beard.

Dead Men Don't Make Shadows (1970)

Also known as The Stranger that Kneels Beside the Shadow of a Corpse.

Demofilo Fidani is sometimes regarded as the Ed Wood of Spaghetti Westerns, so I'm saying nothing new here. To be fair, there are some nice scenes and the consistently low-budget surroundings even helps lend an aura of originality. Yet with Fidani the general editing and cinematic storytelling is rather abysmal, and instead of having artistic merit they tend to evoke a feeling of "what the hell did I just watch?".

In some mysterious way person grows wiser through watching Fidani westerns, so perhaps they are not all bad.

Hey, it can look interesting occasionally. But the main character there, is almost as expressive as he gets.
Here, the first 10 minutes of initial happenings all look and sound like the title scene: some guy rides in the wilderness, and then arrives at a western town, accompanied with dull background music. Dramatic zooms into Wanted-posters abound.

Django and Sartana are coming... It's the End (1970)

(It's "Django Defies Sartana" in my box set, a whole different film holds that title.)

Another Fidani film. Let's cap this up in some more detail:

Fidani's trademark seems to be long, wandering sequences that clearly explicate how the hero travels through the landscape, riding on horseback. In a striking contrast to this meticulous attention to detail, it's nigh on impossible to get any clarity on who's actually travelling and where to.

A woman gets kidnapped. The ranch hands, almost a full minute into the attack, are still carrying barrels and baskets when they are cruelly shot down.

When the ransom note appears on the door, the voiceover reads it, including the signature followed with a laughter. "...Burt Kelly. Brahahaha!"

Well, moments after, both Sartana and Django seem to be after the kidnapper. After meeting a frog and an old shivering man in a ghost town.

Dramatic zooms into Wanted-posters abound.

The villain is clearly insane, as they tend to be in Italian westerns. (He lives in a kind of a tepee inside his house.) His shtick is playing cards in front of the mirror, and the joke is that the mirror image "cheats".

Also, the villains, although they have no reason at all to spare Django's or Sartana's life, never kill them when they might have the opportunity.

In the shootout at the end, for the most part the villains proactively make enormous leaps just before they are shot, in order to fall spectacularly for no particular reason.

One Damned Day at Dawn... Django meets Sartana from the same director is also a contender.

Terror of Tiny Town (1938)

You'd be forgiven for thinking that a Western film populated entirely with midgets would be hilariously non-PC and camp, but in fact it is endlessly boring. The camera scans the little people on eye-level anyway, and the sets are mostly built to scale, so the impression of their smallness diminishes and what the viewer is left with is - and I must apologize - some malformed cowboys.

White Fang and the Hunter (1975)

This is the sequel n to the White Fang films, which I suppose have some tenuous connection to Jack London books.

Just some Joseph looking for a manger... It's not there
The titular dog gets little screen time in this film. Mostly we are subjected to the antics of a venerated spaghetti sidekick Ignazio Spalla, who plays a drunken old fart. The joke is that he drinks a lot of booze, and that's the joke. He usually responds to everything with a "blaarh", or "arrr..?" with pouted lips and a surprised look on his face. Then he marries an indian old maid and they both get drunk, rolling around in a snowy dirt ditch. Then railroad something-something, forced marriage, fake priest, a bar fight, the end.

The Outlaw (1943)

Some seem to think this is a reasonable movie, so I may be in the wrong here. The film depicts an unlikely meeting between Doc Holliday, Billy the Kid and Pat Garrett. They are so removed from any historical (or legendary) depictions of them, sometimes I feel these are just three guys who happen to have those names by accident.

Some unintentional surrealism and absurd scenes here and there seem to portend more unconventional westerns to come, but I just can't care at all.

I guess the film was considered somewhat daring or even "naughty" in it's time, and echoes of this reputation may have made the film more well-known than it deserves to be. Jane Russell is hardly as "prominent" in the film as in the posters & promo stills.

It Can be Done Amigo (1972)

Somewhere in El Crapo, Texas... A cute idea: Jack Palance tries to force-wed his pregnant sister (or whatever, can't remember) to Bud Spencer, who does not fancy her at all. And when Bud Spencer does not get along with someone, you know what he can be like.

Two actors relying on heavy mannerisms can't quite carry it through. Spencer frowns and head-butts his way through the movie, whereas Palance mostly lies down, seemingly recovering from a hangover or something worse.

The pinnacle of jokes is the end where Spencer apparently finally beats up the woman. Ha, ha.

I have a pretty big soft spot for Bud Spencer movies, may he Rest in Peace, but here, no.

Bonus: Frisco Kid (1979)

It's one thing to point out failures in small productions, and perhaps not too fair either. But when a large cinematic production goes awry, it's a different order altogether. Using this metric, Frisco Kid might be the worst western film ever.

Again, it's not a bad idea, a Jewish Rabbi traveling through the old west. However, two hours are wasted in prolonged sketches and vignettes, possibly aiming at some kind of muted, subtle humor.

Sad to see Gene Wilder (Rest in Peace him too), who did a good job in Young Frankenstein and Sherlock Holmes' Smarter Brother, plod through this useless material.

*) Yes there are more than seven

Friday, 16 September 2016

Y NO Z80+editable chars?

Mode Z80 Non-Z80 (6502, 6800)
Memory Mapped
Character Display
Enterprise, Sharp MZ series, Aquarius, Laser 200 VIC-20, C64, Panasonic JR200, Atari 8-bit, Commodore Plus/4, Oric Atmos
Memory Mapped
Character Set
Enterprise, Sharp MZ-800(?) VIC-20, C64, Panasonic JR200, Atari 8-bit, Commodore Plus/4, Oric Atmos
Memory Mapped
Bitmap Mode
Enterprise, ZX Spectrum, Amstrad, ZX81, SAM Coupé, Sharp MZ VIC-20, C64, Panasonic JR200, Atari 8-bit,, Commodore Plus/4, Oric Atmos
VDP MSX 1/2, Sega SC-3000, Coleco Adam, Memotech MTX, Tatung Einstein

Character displays proved to be very effective for 8-bit computers. Intuitive to program, less wasteful of memory and with high potential for optimizing graphics for your chosen approach.
loop:INC $0400,X;INC $0500,X;INC $0600,X;INC $0700,X;INX;JMP loop
What the above table highlights is that there seem to be very few computers combining the Z80 processor with a memory mapped character display with editable character set. I've only heard that Enterprise, the swansong of the 8-bit era, might have such modes. Sharp MZ-800 has something called the Programmable Character Generator, which I think does the trick too. I'm pretty sure that another latecomer, SAM Coupé, does not have a true text mode. The point is that none of the popular Z80 computers had the feature.

Some websites list Sinclair-style pseudo-text bitmap modes as "text modes" too, so it can be confusing. The accurate distinction between pseudo-text, fixed character set modes and fully editable character set modes is not made often enough.

Why were there so few Z80-based memory mapped character graphics? Surely, if the 6502 can whizz user-defined characters around the screen, the Z80 could whizz considerably more?

I don't know. Maybe the engineers thought the Z80 was in any case powerful enough to handle bitmap graphics (a very marketable feature back then). Or, there may be some bus-architectural reason why combining Z80 with a sophisticated character display would be difficult or result in something that brings complications for the programmer or additional contentions with the other chips. I'm especially wondering this as there are Z80-computers with a char display (Aquarius, Sharp series, Laser) but without editable characters. A full 256-character set would have eaten 2K of RAM though.

In the table I've also included some VDP-based computers. It was close to being a standard solution and one can suppose at some point it was easier to design a Z80+VDP computer than start creating new video chips. There seem to be no 6502+VDP computers either, which might have been a poor combo.

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.

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:


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


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
     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.


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


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:

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.


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.