- December 28, 10:25 (GMT+1)
Project defined and early preparations.
- Decemeber 31, 00:35 (GMT+1)
After a few hours of experimenting, my RT PC now has a
blank root password. The tasks I took was to boot the Virtual Resource Manager
Disk 1/2 (by holding down the key sequence
Ctrl-Left Alt-A). It allowed a very simple maintainance
mode which let me mount and view files on the hard disk, and possibly binary
patch them - a task which I never quite dared to try.
After a number of attempts, I finally got the AIX Install/Maintainance
floppy disk to boot. It seems it is easier to boot that after have run the VRM
install disk than from a cold boot or rebooting from hard disk AIX. This floppy
disk gave me a more standard UNIX shell but with a very limited toolset. I was
able to mount the hard disk, but not run binaries (e.g. passwd) from it due to
different shared libraries.
I was about to edit the /etc/passwd with ed when I found a static
linked binary of vi on the hard disk. Once there, it was quite easy to
clear the root password, save the file and reboot.
After reboot, I can now login as root. The first thing was to remove old
core dumps and move backup files to a different slice on the hard drive, so the
amount of free space on the root partition was increased from 0 kB to about
1.5 MB. It might not sound like a lot by modern standards, but it'll be enough
for the system to not complain about "no space left on device" upon boot.
Apparently this machine even has a C compiler installed, which means another
possible source of entertainment during January. Then again, exactly how fun is
an ancient version of gcc? We'll see...
- January 3, 01:05 (GMT+1)
Well, I promised some mixed stuff so tonight I got going at
my first programming attempt for the VTech Creativision, a somewhat obscure
console contemporary with the much more familiar ColecoVision. The two are much
similar, except VTech used the cool 6502 CPU (as in Apple, Atari, Commodore)
while Coleco stuck with the ... well, Z80 like in your average CP/M system,
MSX, ZX Spectrum and so on.
The Creativision has a library of about 16 cartridge games, a handfull
homebrews and a number of Basic games on tape, some commercial but most of them
user generated. However Basic imposes additional limits on an already somewhat
restricted system, so machine code programming and possibly burning your own
cartridge games would be the way to go.
As I've been programming e.g. the VIC-20 for some 10-15 years, I figure once
I learn how the Video Display Processor (TMS-9918/29 VDP, same as in TI-99/4A,
ColecoVision, MSX etc) and the Programmable Sound Generator (SN76489 PSG, same
as in TI-99/4A, ColecoVision, BBC Micro, IBM PCjr etc), I should have a good
chance at producing something at least half decent.
My first program was to set up the VDP and have a sprite move across the
screen. It took me about an hour to study existing source code examples and
VDP documentation to get a 16x16 sprite that is supposed to look like the
state of Texas, US to float across the screen. It was easier than I had
anticipated, so now I look forward to the next occasion I get to play with
this system.
And for that matter, this is NOT the Worst.Console.Ever. Far from it,
actually with a few design changes and some better marketing I think it
could've put up a good battle with e.g. ColecoVision and for that matter
Atari 5200 etc. VTech redesigned the system into an even more obscure home
computer version, the Laser 2001 (which I've also got) which is cartridge
compatible with the CreatiVision.
- January 4, 00:55 (GMT+1)
Those may be small steps for a man, and not very much to
brag about for the mankind neither, but to me it is a milestone that I got
to define a character generator and create a routine to plot characters to
given positions on the screen tonight. Indeed this was not what I had planned
to spend my time with in the Winter Warm-Up, but it is something I have
procrastinated to do for five years (!) and now when I'm finally are dipping
my toes into the Creativision machine code, most of it seems so natural that
I curse myself for not taking those first few steps several years ago.
Hopefully in the coming weekend, I'll spend some time with my other wishful
projects. I also have some retro stuff to pack and ship, but it has even less
to do with the challenge than daily discoveries in retro programming.
- January 6, 01:35 (GMT+1)
The programming challenge continues. In 2002, I implemented
Othello for the VIC-20 within 1 kB of RAM for the yearly Minigame Compo. The
computer player uses a simple min-max algorithm (it would be an insult to call
it artificial intelligence) originally published in a Basic listing by Graham
Charlton and Tim Hartnell. I got a fair number of thumbs up for this
implementation.
Since the VIC-20 and Creativision share the 6502 and have quite similar
limitations, I decided my very first game will be to port Othello to this
console. Due to how the TMS99xx VDP implements colours in up to 32 sets of
8 characters instead of a memory map where each character has its individual
colour, I will have to convert all changes to the colour map to change of
graphics that belong to the desired colour set. Currently I have defined the
sets white on black, black on green, white on green, light blue on green and
purple on black.
The next step will be to define a sprite (flashing square) to move between
each square and select one to make the move. We'll see how many changes I have
to do to the code, but I expect I'll have to think it through instruction by
instruction despite the CPU is the same.
I noticed that Earl Evans still is developing his Othello/Reversi for the
C64. However he is working in C and aims for a play-by-modem version, so I
don't know how much interchange we'd be able to have between the two versions.
- January 7, 21:00 (GMT+1)
After I got my IBM RT PC running (see the prologue post on
top), I was asked to make backups of some of the original floppy disks. Usually
this would not be much of a task if it wasn't for the fact that I don't have
any 1.2 MB floppy drive connected to a modern PC. (I do have a 5.25" 360K
one in my old AthlonXP PC, but it wouldn't be up for the task)
Thus my idea is to use dd on the RT running AIX 2.2 and then hook
up some serial connection and use kermit, xmodem etc to transfer the image.
Very classic approach I'm sure, but after I found a set of cables I came to
the conclusion they all end with male connectors! To add insult to injury, the
only DB25 gender changer I have is M-M. It is possible that somewhere in the
basement, I have a straight DB25 F-F cable, but it'll have to wait until some
other night before I locate it.
While I was hunting, I decided to check my CBM 710. Although I don't have a
keyboard and the electrolyte capacitors in the power supply let out smoke some
years ago, it used to work but last time I checked it was completely dead. This
time I took the precaution to open it, find that all connectors were loose (!)
and thus refitted most of them to expected locations. Lo and behold, but the
computer boots like it should, all in its green on black glory!
Its little brother, the CBM 610 however doesn't yet boot. I have a couple of
spare chips (both from the 710 and otherwise) and at least one EPROM adapter to
fix, plus that I've asked from help by some Internet friends. We'll see if I can
have it fixed within this month, it seems to be pretty close as it used to work,
still powers on and causes the floppy drive to spin infinitely.
- January 7, 23:30 (GMT+1)
I got a short session of programming done as well. There is
a pretty logotype on the right, actually generated in Adobe Photoshop from the
font Lucida Handwriting, 95% width and faux bold.
The other work was to write a routine to print a zero-terminated text
string and a routine to convert a binary number 0-63 to a decimal string.
The routine I used was proposed by Garth Wilson and is based on
an
algorithm by Don Aldridge published in a Motorola book.
There are some other routines that are simpler and perhaps a bit more
efficient (who's counting the cycles anyway?) but those tend to put the 6502
in decimal mode. While there is nothing wrong with SED/CLD, I don't know if
it'd affect the BIOS interrupt so for now I'll stick with this routine.
The scores in the screenshot obviously are just for testing purposes. The
grey circle equals the marker for current player and will be the one to move
around the playfield, but so far it doesn't move at all. :-)
- January 9, 00:50 (GMT+1)
Tonight I spent one hour (!) at soldering a DB9 - DB25 null
modem adapter. However I never got to test it, which means one more postponed
task for later this week. With a lot of luck, I might both get a serial
connection to the RT PC and eventually get the serial communcation on
the Basis 108 going, as honestly I don't know if the cable I used before was
correctly wired for expected functionality.
On the programming front, I added some title page texts and a brief routine
to read the joystick and move the cursor around. Not enough to post a new
screenshot, but by the weekend I hope to have converted the game engine to
actually make legal moves.
- January 10, 10:20 (GMT+1)
As a brief interlude in my programming, I made a study of
which other implementations of Othello or Reversi are available on VDP based
systems. The list is not meant to be complete, but I think I covered most of
them. Some of the systems for which I didn't find any implementations are
Spectravideo SVI-318/328 (there is an undumped SD-238T Othello tape game for
which I didn't even find any screenshots), Sord M5, Tomy Tutor and Tatung
Einstein (there is a hexagonal Boardello but I won't consider it).
I think the Casio PV-1000 also has a VDP but it got outperformed by Famicom
and SG-1000 (which techincally should be about the same) before anyone made an
Othello/Reversi game for the Casio. The Sega Master System has an improved VDP
so if there are any Othello games for that one they might look better than I'd
be able to reproduce anyway.
 |
Othello
TI-99/4A
(c) 1982 CBS Electronics |
 |
Kazuo Morita's Othello
MSX
(c) 1986 Toshiba-EMI |
 |
Othello
Multivision
(c) 1983 Tsukuda Original |
 |
Othello
SG-1000
(c) 1985 SEGA/Tsukuda |
 |
Othello
MSX
(c) 1985 Pony Canyon/Tsukuda |
 |
Computer Othello
MSX
(c) 1983 Sony |
 |
Reversi
ColecoVision
(c) 2001 Daniel Bienvenu |
 |
Reversi
Memotech MTX
(c) 1984 Continental Software |
As you can see, some of them are very much alike eachother. The fact that
Othello by Tsukuda Original (who holds the legal rights to the game name, so
for general purposes I might as well call it Reversi) was converted both to be run on a regular SEGA SG-1000 (or SC-3000 computer) and on MSX computers
perhaps isn't so strange.
The alternating background colours on squares are found both on Sony's MSX
game, Daniel Bienvenu's version for ColecoVision and on the Reversi game for
MTX. The TI-99/4A version, which might be the very first Othello game for a VDP
machine uses filled and hollow rings instead of black and white markers.
I will consider if there can be any graphics update on my implementation
above. I kind of like the alternating background colours, but it adds another
small layer of complexity on updating the board. To use 8x8 characters with
plenty of room to have the lines looks a bit basic compared to the fuller
16x16 graphics.
As a bonus information, there was an Othello game for the rare Bandai Super
Vision 8000 from 1979. While it has a Z80, AY-3-8910 sound and 16 colours, its
graphics seem to be powered by something earlier, more primitive than a TMS9918
VDP, or perhaps the system doesn't have enough RAM for the VDP to produce any
nice looking graphics. Click here for some screenshots to
make your own conclusion.
I also found the very obscure Nichibutsu My Vision (no, I didn't make that
up!) which has the desired VDP and a total of six games of which three seem to
be board games. I think the one with stones put onto the lines is Go, then
there might be a Chinese Chess and the last one would be Othello/Reversi.You can find blurry screenshots here.
- January 15, 00:25 (GMT+1)
After a mostly lazy weekend, I'm back to the game programming.
One of the changes was to rename my game from the trademarked Othello to
the more generic term Reversi. Not that I'm really afraid of lawyers hunting
me down, but I figured the change is very small. It'd be more difficult if I
made an implementation of Tetris, which is protected both to name and gameplay.
Of course I've made such implementations before and may in the future too, but
it will be a matter later on.
When it comes to functionality, I remade a few routines to use logic board
positions instead of screen positions and plugged in the CPU player routine.
For some reason, user input seems a bit buggy and right now it seems human and
computer players alter between white and black in a rather odd fashion.
It means more interesting code to debug later on, but at least I got the
score count, board update and hopefully computer algorithm to work. If I put
some effort into this, I might have a playable version by the end of the week
or even sooner.
- January 16, 00:50 (GMT+1)
Some more debugging done tonight. I figured one of my
problems seemed to be that X and Y got swapped somewhere, but I couldn't figure
out where.
Enter "debug print", the tool that every lecturer of computer science hate
but everyone who do practical programming love. I started with a routine that
would print the logic X and Y positions when the cursor was moved around. It
seemed to be correct, so I moved to the next step: make a debug print of the
board as it is stored in RAM. What you see on screen is how it is drawn by the
VDP, which is not what the program uses to calculate legal moves etc.
Apart from the fact that the board is printed upside-down, right to left
due to I'm lazy using DEX/BPL loops instead of INX/CPX/BNE loops, I could soon
see that the bug lied in the routine that plots the markers will get the
coordinates as row,col while I intended it to be col,row. A bit of extra code
solved that, and now things are drawn on screen in the same orientation as it
is stored in memory.
Oh well, one would almost claim victory now that both player input and the
computer routine mostly work? Yes, I was about to do that when suddenly the
computer decided to put a marker in the border instead of an empty board
position and thus claim a row of eight markers. Hm, the original VIC-20 version
never did that. It is known that sometimes the computer fails to place a marker
despite it has legal moves to do, a small bug that I might investigate later,
but this one may be more serious.
Also there is a small bit of random call that I still need to implement. On
the Commodore computers, I simply read the low byte of the TOD clock which
updates 60 times a second and for most purposes works as a pseudo-random
function. On the Creativision, supposedly the BIOS has a ROM call for some
random number generation, which I will investigate later.
- January 19, 00:15 (GMT+1)
The game still is unexpectedly buggy, but I made a few small
tweaks like making sure the white player always begins no matter if the human
decides to play like white or black. Also the cursor previously remained on
screen even when the computer made its move or the game had been reset.
I have also posted a buggy beta release on the CreativEmu forum and got a
lot of valuable feedback, as well as suggestions of an alternative graphic
design. I will make sure the game plays as intended first, and then move onto
visual improvements.
- January 19, 00:30 (GMT+1)
I took one more look at the code, and wrote down which
subroutines are used where. My idea was that those routines used both when the
human and the CPU make their respective moves, must be bug free and the issue
lies in the code only executed when the computer plays.
Wait a second, these two loops go from 1 to 15 while there only are
positions 1 to 8 on the board. Hm, the original VIC-20 version used an
extended board 14x14. What happens if I change 15 to 9?
Cool! It seems the CPU playing bugs went away! I need to play test a bit
more, but it really looks promising. Maybe I can sleep peacefully tonight.
- January 23, 23:30 (GMT+1)
The last couple of days have been spent with improving
graphics and game controls.
After studying the layout of the ROM character set, it has now been enabled
instead of the drop-in VIC-20 font.
Right now the computer kind of can play against itself, but I'd need some
kind of random element to prevent it to play exactly the same game over and
over.
On another horizon, I have looked into my CBM 610 that died upon me in
October. It only has a few of its chips socketed. So far I have verified EPROM,
6526 CIA and 6509 CPU to be good, which means the issue must be elsewhere and
a bit more complex. I'm getting advice elsewhere how to troubleshoot, but I
don't expect this one to be fixed by the end of January anyway.
- January 29, 00:45 (GMT+1)
For some reason, I get almost nothing done in the weekends,
and then in the weeknights I get busy with a handful of things at once.
There has only been moderate progress on the programming, but at least I
have learned how to differentiate between a cold start and the RESET button.
It turns out the Z flag on the 6502 is set when the RESET is pressed, which
means it needs to be captured and stored as soon as possible, before any other
instructions start messing with the flags.
Now that I have figured it out, I can have a demo mode CPU vs CPU playing
to begin with, and when RESET is pressed the player(s) get to choose mode and
start the actual game. This is common behavior on many old consoles, although
it might seem a bit backwards that you need to reset the machine before you can
start playing.
- January 30, 00:30 (GMT+1)
As the month draws to a close, time for some last minute
updates, see also above post to which an intermediate screenshot was added.
Another few fixes: either firebutton toggles between 1 player white,
1 player black or 2 human players. By moving the stick in any direction,
the game begins.
The improved border and marker graphics are designed by MADrigal. Still
hidden is a five or six frame animation for flipping markers, something I'll
probably not get done by the end of this month, but it will be done as soon
as I have the time.
Also I still haven't implemented any random number generator or sound
effects, and the game over routine is not yet properly done, but I save those
improvements for the last.