Elon Musks's Blastar (Unexpanded VIC-20 Conversion)

[Snial]

Back in 1984, the 12 year old Elon Musk wrote a rudimentary video game for his SpectraVideo SV-328 (a Z80 Microcomputer)

https://www.theverge.com/2015/6/9/87523 ... r-pc-game
Then about 5 years ago someone turned it into an HTML-5 version of the game which you can play here:

http://blastar-1984.appspot.com

And someone else found the screenshots of the listing:

https://archive.org/details/blastar-elo ... ectravideo

Since it's quite instructive to see what 12 year old geniuses can achieve, I thought I'd recreate it for the ZX-Spectrum and then port that to the unexpanded VIC-20 as the first two steps towards building my first $billion company !

Here's it is! And in my 'umble opinion, it's better than the original, because a VIC-20 is better than the SV-328!



Observations:


The SV-328 version uses Sprites and ON INTERVAL type commands to force periodic calls to the game code. In reality, that kind of functionality doesn't provide any advantages over the straightforward video game pattern: Render, Take Input, CalculateNextPositions and in fact probably made the game a bit more complex for Musk, because it means he could never be sure exactly which part of the program was running as one part could 'interrupt' another.

Secondly, the game really is super-simple. With a bit more programming experience, his version can be reduced to less than half the length (though some of this is because my UDGs were in decimal rather than binary). I fixed an issue in his code whereby the STATUS BEAM that will certainly kill your ship was, I think meant to track your ship as it fell, but in fact it didn't. In this Improved version, the status beam does track the ship!

The VIC-20 version is particularly challenging for several reasons. Firstly, it's possible, but really tricky, to set up a graphics mode so that you only allocate space for the graphics characters you need (in my case 5 characters) and are also able to access normal text characters.

The solution is to allocate one page of memory for the graphics chars starting at 7168 (28*256), and it turns out that inverse characters appear as normal upper case + some block graphic characters. Because I only wanted 5 graphical chars, I used video (not ASCII) characters 59 to 63. I then set the end of BASIC to point to the address 7640, which meant that BASIC in fact could encroach on the character set!

The second major problem for the VIC-20 version is that it's tricky to print at any location on the screen. I chose to poke the printing position to where I wanted it, which needed 3 pokes, but subsequent testing shows that using cursor controls is much neater and faster. This had the consequence that the VIC-20 version of the game is slower than the ZX Spectrum version, though ironically the sluggishness and keyboard buffering on the VICE emulator makes the game more fun and challenging to play.

And here's the listing if you want to type it in (tap file also attached)


The ZX Spectrum version can also be found here:

https://sites.google.com/site/libby8dev/zxblastar

[Noizer]

Nice Story. But to get the title of a genius today someone has to be the son of Jesus and having the mother of Einstein.

[orion70]

Wow, nice story and nice game indeed! Thank you for porting it to the VIC

[Kweepa]

Very interesting!
I think rather than using cursor controls or poking the cursor position it's quicker to just poke the graphics themselves directly to the screen. You have to poke the colour to the colour memory too though.

[Snial]

it's quicker to just poke the graphics themselves directly to the screen

That wouldn't surprise me, I wouldn't say I was the most expert VIC-20 programmer

It would mean a line such as line 150 becoming:

Code: Select all

150 A=G*22+H:POKE 7681
+A,63:POKE 7680+A,160:
POKE [Color RAM]+A,Color

Yes, that's probably quicker and a bit shorter.

[r.cade]

This is no different than the game that comes in the VIC manual.

[Snial]

This is no different than the game that comes in the VIC manual.

Really? Elon Musk started out with a VIC-20, so it would be quite ironic if he ported a VIC-20 manual's game to the Spectravideo, which eventually got ported back to the VIC-20

Can you point to the VIC-20 manual's version?

[Mike]

Can you point to the VIC-20 manual's version?

That would be Tank-v-UFO, by Duane Later. A copy of that game is contained in my Games Collection.

Greetings,

Michael

[pixel]

Am nothing short of wanting to knock you in the butt for bringing some unforgivable PR genius hype to the forum.

[r.cade]

Can you point to the VIC-20 manual's version?

That would be Tank-v-UFO, by Duane Later. A copy of that game is contained in my Games Collection.

Greetings,

Michael

No, it's not that. It much simpler. Just an "up arrow" in the middle on the bottom, and a greater than/less than sign that went across the top. You timed the firing of it and hit it, or not.

[Snial]

No, it's not that. It much simpler. Just an "up arrow" in the middle on the bottom, and a greater than/less than sign that went across the top. You timed the firing of it and hit it, or not.

Thanks, I feel vindicated

And motivated enough to write another Blitz program in BASIC for the unexpanded VIC-20 (surely the original was in BASIC too?).

[Mike]

No, it's not that. It much simpler. Just an "up arrow" in the middle on the bottom, and a greater than/less than sign that went across the top. You timed the firing of it and hit it, or not.

You then mean Rocket Command.

In Tank-v-UFO, the UFOs throw aimed bombs, very similar to the "scanning beam" in Blastar. Also, in Blastar and Tank-v-UFO, you can move the base/Tank to the left and right. In Rocket Command, you just have a limited supply of rockets with a given launch position. Tank-v-UFO builds Tank and UFO each from several PETSCII chars, whereas both Rocket Command and Blastar just use a single char for each object.

The third program by Duane Later, Killer Comet, is too dissimilar to be taken into account.

My Games Collection also contains these other two programs, Rocket Command and Killer Comet, so you can do the comparison by yourself.

Earlier this year, I did a conversion of Killer Comet to machine language and also improved it with user defined graphics.

Firstly, it's possible, but really tricky, to set up a graphics mode so that you only allocate space for the graphics characters you need (in my case 5 characters) and are also able to access normal text characters.

The solution is to allocate one page of memory for the graphics chars starting at 7168 (28*256), and it turns out that inverse characters appear as normal upper case + some block graphic characters.

That technique (accessing the non-inverse chars via RVS ON with activated UDGs) was commonplace then, and you will find lots of examples in the type-in listings in contemporary magazines.

Often, the programs/games allocated the "full" 64 UDG chars by setting the end of BASIC to 7168 (those are two pages, BTW!) but - again in my Games Collection - my implementation of Moon Patrol for example allocates only 32 chars. This allows to still define the definition of the blank character (screen code 32) to be empty as well, so there wouldn't show up any 'debris' if the colour RAM value of spaces on screen didn't match the background colour. In TRON, I even only allocated 6 UDGs (light cycles in 4 directions, a filled block, and the explosion) - there the 'normal' blank character, if it appears, is always white ... same as the background colour.

When allocating the area for UDGs to protect them from the string heap, setting only 55/56 followed by CLR is entirely sufficient. 51/52 are then correctly set by CLR according to the values in 55/56. More details are found here.

[...] it's tricky to print at any location on the screen.

Actually, there's a call to the KERNAL (PLOT, JSR $FFF0), which exactly provides that function, without the necessity to 'throw wrenches into the gearbox' with POKEs into the zeropage. You're right however in that BASIC V2 doesn't feature a dedicated PRINT AT statement.

As the other posters already have pointed out, a combination of cursor control characters and PRINT, or direct POKEs into screen (and colour) RAM do the job for most BASIC programs on the VIC-20.

[...] ironically the sluggishness and keyboard buffering on the VICE emulator makes the game more fun and challenging to play.

That has nothing to do with emulation, VICE in particular. The keyboard buffering also happens on real hardware and is a function of the KERNAL.

Greetings,

Michael

[Snial]

Rocket Command.. Tank-v-UFO .. Killer Comet.

So, Blastar isn't quite the same as any of these, but there are some similarities with the first two.

My Games Collection also contains these other two programs, Rocket Command and Killer Comet, so you can do the comparison by yourself. Earlier this year, I did a conversion of Killer Comet to machine language and also improved it with user defined graphics.

Cool, I'll check it out.

setting only 55/56 followed by CLR is entirely sufficient.. Actually, there's a call to the KERNAL (PLOT, JSR $FFF0), which exactly provides that function.. The keyboard buffering also happens on real hardware and is a function of the KERNAL

Interesting, thanks!

[r.cade]

Rocket Command is very close, and may be what I am thinking of, but it seems even simpler in my mind.

Up arrow at the bottom, immobile. Greater/less-than symbols go back and forth, you can fire once. Not even any sound- that was it!