Work has been busy and I haven’t had as much time (even on the weekends) as I had hoped to work on this. I did spent most of yesterday on it and made some significant progress.
The initial assembly language coding of the reverse scroll routine went pretty smoothly. While I find the 6809 assembly syntax a bit different than what I’m used to (on the 6502 and Z80 mainly), it is actually fairly powerful. With things like pre or post increment or decrement of the register you are using to hold the address when you load or store, what would be a few lines of code on the 8-bit 6502 becomes a single line on the “16-bit” 6809. (I use quotes because the 6809 has a 16 bit internal architecture but works with an 8 bit external bus. Some don’t consider it a true 16-bit processor. Personally, I think it is absolutely fair to call it a vintage 16-bit processor that tried to keep a degree of 8-bit compatability.)
But almost immediately the issues began…
Let me start by saying I’m running Ubuntu Linux and doing “cross-development” (where a lot of the work is done on a machine other than the target system) for all of the assembly code and portions of the BASIC code. It will turn out that which operating system you are using will be relevant. I am also using Drivewire so the “disk” is a file on the server.
I was using LWASM to assemble the code and it has a handy option to generate a BASIC file that includes data statements and a routine to poke the program into memory.
So my assembly code initially looked like this:
; Downward Scroll Routine
; by James McClanahan W4JBM
; Rev 1.0 for Retro Challenge, April 2018
;***** Define Constants
; starting addresses have "+2" to compensate for pre-decrement
; of the X and Y registers.
sfrom equ $5de+2 ; where do we start copying from?
sto equ $5fe+2 ; where do we start copying to?
done equ $400 ; where do we stop copying?
;***** Start of Program
;***** Load Constants into X and Y
start: LDX #sfrom
;*** Main Loop (copies from address in X to address in Y)
loop: LDD ,--X
That is pretty straight forward with it starting at the top of video memory (or the bottom of the screen), loading a 16 bit word, then moving it down 32 bytes. We auto decrement the X and Y registers by 2 (the two negative signs) prior to the load and store and do a simple address to find if we’ve reached the top of the screen.
Like I mentioned, LWASM has a nice feature to create the object code and put it into a basic program. So we assemble it using this:
lwasm -f basic -o scroll.bas scroll.asm
And, in this case, the scroll.bas file looks like this:
10 READ A,B
20 IF A=-1 THEN 70
30 FOR C = A TO B
40 READ D:POKE C,D
50 NEXT C
60 GOTO 10
80 DATA 16000,16016,142,5,224,16,142,6,0,236,131,237,163,140,4,0,34,247,57,-1,-1
NOTE: If you want to play with this yourself, you will need to start the program with something like:
5 CLEAR 10,15999
This will protect the memory at 16,000 and above for our machine language routines.
Anyway, the logical next step is getting this simple BASIC program onto the CoCo itself.
I have also installed MAME and eventually want to do emulation for troubleshooting and debugging, but haven’t made it to that point yet. But MAME also includes a utility call imgtool which lets you create a disk image file, store files to it, retrieve files from it, and do a number of other cool things.
I created a test disk and it worked fine. I added some files and it seemed to be working to an extent, but I was getting error messages and not able to read the files on the CoCo even when I could see them in the directory.
In theory, I can create a blank disk image using this command:
imgtool create coco_jvc_rsdos test.dsk
I was able to use imgtool’s “dir” option or open this with Drivewire and things seemed good. So the next step was to add my BASIC program. It is in ASCII format, so I need to do this:
imgtool put coco_jvc_rsdos test.dsk scroll.bas SCROLL.BAS -ascii=ascii -ftype=basic
This should take the scroll.bas file on the Linux box and put it into the disk image file as SCROLL.BAS as an ASCII BASIC file–except every time I would get the error message:
scroll.bas: Bad file name
I could load test.dsk using Drivewire. With some combinations I could even get SCROLL.BAS on the image, but it was in ASCII format (without the ASCII flag) and the CoCo was expecting a tokenized file, so on the CoCo I would get the expected.
I tried different combinations of flags and options. Since the message was “bad file name” that led to a lot of searching for things that had nothing to do with what ultimately turned out to be the real problem.
I’ll save you the painful details, but eventually I figured out that the issue was the end-of-line marker in the BASIC file.
This is one of those things that seems simple, but is different on different systems. In ASCII, a carriage return (or CR) is character number 13 and a line feed (or LF) is character number 10.
With normal ASCII text files, DOS and Windows uses a CR+LF at the end of a line. Linux and later Apple systems just use just a LF character. Older Apple systems used just a CR character. (I think the only combination not used is LF+CR, but it wouldn’t surprise me to find some system, some where even uses that.)
There is a utility call unix2dos that will convert the LF’s to CR+LF’s. So all I ended up having to do to make things work was take the BASIC file from LWASM and do the conversion:
It took me about two hours to figure that out.
With that moved over, I started coding a basic race track game. I use the command:
to do a “downward scroll”.
With a simple working framework, I found more issues…
I was poking 3 lines of 4 characters onto the bottom of the screen as the car. With the scroll, there was very noticeable and distracting flicker. I ended up having to rewrite most of the scroll routine. Now it goes character by character (instead of pairs of characters) and only “scrolls” characters that do not have the high bit (bit 7). (Bit 7 is zero for most normal characters. It is the semigraphics that has Bit 7 set. Loading them from the screen also sets the N bit in the condition code when Bit 7 of the character is set because they could be a negative number if you were using two’s-complement math.)
This helped, but there was still some flicker as the car moved side to side. To overcome this, I wrote an assembly language routine to draw the car. Now I just have to do a single poke (to let the routine know where on the bottom of the screen to place the car) and call it with an EXEC command to have it quickly draw the car.
But in that process, I found yet another issue. I wrote the second routine in assembler and had the output in BASIC. By now I had figured out how to get and put ASCII BASIC files on the image file. I added the new DATA statements using a more powerful editor (Geany) and it didn’t work…
It would draw the first two lines of the car, but not the third. Again, I struggled for a bit. Eventually I broke the DATA statements into several smaller lines. I think (but have not verified) that there must be a line length limitation on ASCII BASIC lines. The line would probably have worked fine if it was line 70 or 80, but because I needed to make it something like 470 or 480, I think the end of the DATA statement was being truncated as I pulled it in.
As an aside, the old laptop I am using to do the development and as the Drivewire server has decided that certain keys should no longer work. I don’t have E or I or about a half dozen other characters. Unfortunately some of those are used in the system password. I did have a USB keyboard setting around and things work fine with it connected.
With that done, I now have the downward scrolling working, the car drawn, and the ability to move the car left or right using the keyboard. Here is a screen from the JS Mocha online emulator by Brad Grier:
Horizontal movement of the car is limited, so you can’t “crash” into the sides. I will be adding obstacles (probably just simple characters such as “X”). There will also be some element of “speeding up” as the game progresses.
This is different than the original Foo Raceway. That original program had a track that would move from side to side and vary in width. That would not be that hard to implement, but the original also used the 32 character display mode of the Ohio Scientific (OSI) C4P-MF and the character graphic car was only 1 character wide and two characters high.
On the CoCo, the car is much bigger as related to the track: four characters wide and three characters high. So for the OSI, the car width was something like 3% of the track width while on the CoCo the car is something like 13% of the track width. Too much weaving or narrowing of the track would make the game unplayable.
A few other things…
The code runs on both my CoCo 3 and the CoCo 2 emulator, so it seems reasonably portable. That was one of my unwritten goals. (I do have a CoCo 1 that I might try it on at some point.)
Also this week a very special package arrived. Several years ago Briel Computers offered what they called the Superboard III. This was a “clone” of the OSI Superboard II. That was the computer I first had decided to buy back in the summer of 1980. With my parents helping out, I was able to get the OSI C1P instead which included 8K of memory (as compared to the Superboard’s 4K), a case, and a power supply.
I was not particularly active in the retro computing community at the time and I did not hear about the Superboard III until about a year after they had sold out. They were available built for around $250 or as a kit for $200. I have tried to buy one several times over the past few years. They either had already sold or the seller was asking (and usually eventually receiving) a significantly higher price than they originally sold for.
I had decided that if I could one day get one for a somewhat reasonable price I would be happy. I happened to look on eBay for some components one evening and came across a Superboard III that had been listed a few hours earlier for $250 plus shipping.
Several people were already watching it, so I immediately snapped it up. I was out of town all week so I couldn’t pick it up from the post office until Friday. Unboxing it and firing it up for the first time brought back memories of buying the C1P almost 38 years ago now.
If thing had been a bit different, I would probably be doing Foo Raceway on it… but for now I’m setting it to the side and working to finish up Foo Raceway and the Retro Challenge!
DISCLAIMER: I’ll admit that after three decades, some of my memories of events may be a bit fuzzy or blurred together. Certain things I (think I) remember clearly, while others are kind of vague. I’ll do my best to stick to the facts and try not to ramble too much. (I know, it’s already too late for that…)