With Orwell updated and the new video working I started looking at adding graphics commands. I started with plot, easy enough, to draw a pixel at a given location on screen. Since it is hard to add new functions that take parameters in MS Basic I did it the way I have done previous commands such as move. I use a few memory locations that you poke to then you call the command. This works fairly well and is well in keeping with how they did things in the 80s.
Plot worked fine so I went onto drawing lines. Now it turns out drawing a line that isn’t at 0, 45 or 90 degrees isn’t trivial. It gets a bit tricky! But luckily this problem has already been solved. Turns out there is an algorithm to do it called Bresenham’s line algorithm. Searching about in the 6502.org archives to see if anyone has implemented it already I found some code by Daryl Rictor to do the line drawing. I took a copy of that and got it working on Orwell.
With lines working drawing rectangle should have been easy (they are just four lines after all). But I hit a snag. As soon as I added in a new command into MS Basic Orwell stopped working. It would start up but as soon as it tried to parse the first line it would simply stop. It took me a few days to work out by by elimination and experimentation I worked out it was the extra command that was added that broke something. Commenting out the command in the token table made everything work again.
I finally figured out that I must be overflowing some byte or page boundary. By looking at the lst output from the assembler I could see the that the token table was now larger than 256 bytes. I checked the line parsing code in MS Basic where it searches through the TOKEN_NAME_TABLE and yes, it is using absolute indexed addressing with the Y register:
lda TOKEN_NAME_TABLE, y
Of course Y is an 8 bit register so that means you can only index 256 bytes. My extra commands made the table bigger. I puzzled over how to solve this and posted asking about it on the forum. My thought was you must have to use 2 bytes for the address and handle rolling over from one to the other.
Then I had a thought. I was pretty sure Applesoft Basic supported a lot more commands than my OSI based version. But it’s still based on the same code. So I looked in the Applesoft Basic disassembly online and saw how they were doing it. They do use two bytes for the table indexing. And they make use of the FAC which already exists in MS Basic.
D590- 84 AD 1640 .4 STY STRNG2 SAVE INDEX TO OUTPUT LINE D592- A9 D0 1650 LDA #TOKEN.NAME.TABLE-$100 D594- 85 9D 1660 STA FAC MAKE PNTR FOR SEARCH D596- A9 CF 1670 LDA /TOKEN.NAME.TABLE-$100
In the end I more or less do what Apple did and use 2 bytes of the FAC to do the indexing. There are a couple of tricks though. In Applesoft the input buffer is in a different location than in OSI Basic. So there is an extra command they do I don’t need to. Also the way their loop indexing works it increments before it starts working through the table. Note the address-$100 above. That is 100 hex which is 256 decimal. Since these are 8 bit bytes when it increments it will roll over back to 0 which is the start of the table. What I did was load the two bytes of the address then subtracted 1 from the high byte so when it increments at the start it is then correct. That seems to work.
With that all done (actually I just found another place in the code I need to do the same fix) I was able then to add my extra commands. Rectangles were easy. Then I looked at circles. Again this isn’t trivial but it is a well known issue and solved before. I first tried a simple circle drawing routine by Stephen Judd from Commodore Hacking issue #9 (from 1995)!
That did work but it drew some wobbly looking circles! I then looked about some more and found Daryl, of the line drawing routine, also had a circle drawing routine based on the Midpoint Circle Algorithm. His routines use 16 bit numbers but since Orwell only has a graphics resolution of 160 by 100 I can get away with 8 bits. I had already written my PLOT8 routine to work with the first algorithm so I just took Daryl’s code and modified it to run with 8 bit values.
And that is now working very well. So Orwell can do simple plot/unplot, draw lines, draw rectangles and also draw circles. I don’t do any real bounds checking on the shapes. The plot routine simply doesn’t plot any points outside the screen.
I wrote a few little BASIC programs to test this out and it’s probably easier to just make a little film to show how this stuff works.
One other thing I have done is change my INKEY$ function. It previously returned NULL if no key was pressed. I now return an empty string. You can check the string length and see that it is 0 but for some reason in OSI basic I can’t do a comparison to an empty string (IF A$ = “”) since that always seems to return false. Something else to look into!
Update: OK, I played with that empty string stuff. It’s broken if I try to do it as an immediate command. If I do it inside a program with a line number it works fine. I downloaded a Compukit UK101 simulator which runs the same Basic and it also behaves this way so it’s not something I have broken. I think perhaps when you declare a variable such as A$ to be empty as an immediate command it treats it as temporary so it doesn’t exist after the command is run?