Own softwareScanned itemsRetroChallenge

RetroChallenge Winter Warm-Up 2013

Although I don't really have any particular project going on, I'll enter the RetroChallenge Winter Warm-Up with a bit of mixed stuff and see where it takes me.

Planned tasks

  • Boot my IBM 6151 RT from floppy disk in hope to set a new root password. If that is not possible, I might find myself trying to reinstall AIX from disk images, although it also will require me to obtain and setup a 1.2 MB 5.25" floppy drive on the PC side.
  • Develop a game for the VTech Creativision, possibly also some programming for other systems (e.g. VIC-20).
  • Troubleshoot my CBM 610 that gave up the ghost this fall. I have a vague hope it is just a bad EPROM adapter, but time will tell.
  • The Corvus hard drive still isn't backed up, much due to I never found a setup that works for me - the 610 was planned to be used as a middleman but it died on me before the setup was completed.
  • I've got an additional number of more or less broken computers and consoles to diagnose and fix. I doubt I'll get very far on that front, but never say never.

Process log - Latest progress

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.

(c) 1982 CBS Electronics
Kazuo Morita's Othello
(c) 1986 Toshiba-EMI
(c) 1983 Tsukuda Original
(c) 1985 SEGA/Tsukuda
(c) 1985 Pony Canyon/Tsukuda
Computer Othello
(c) 1983 Sony
(c) 2001 Daniel Bienvenu
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.