I finally got around to successfully updating Orwell’s video to Grant Searle’s video board. So Orwell now supports 80 characters as well as 40 character, bold and double size outputs. It also now has simple pixel plotting graphics!
Once my 74HCT166s did finally arrive I was able to just plop one into the breadboard I had all set up, turn it on and it immediately worked! I tried each of the little sample programs on the Arduino and they all worked. Since I knew then the video output was working I set about making the changes needed to Orwell to drive the video board. I also built up the video circuit on a small piece of strip board. I was able to test that using the Arduino of course.
The video board needs 6 lines to control it, 4 data lines and 2 control lines. I had four unused lines on port B of the VIA. I am using 3 outputs on Port B for the keyboard scanning already and using pin 7 as a sound output pin as that can be independently driven off the VIA timer. It provides a very simple way of making sounds.
So I did have port B pins 6..3 free for use already. As well as CB1 and CB2 as the control lines. The hardware changes were just some simple wiring changes on Orwell. I removed the wires that went from the serial port to the header the Batsocks connected to and rewired that header to connect to port B on the VIA. I also added in a separate power header.
It was a bit fiddly but I managed to get there although I did have to order a new soldering iron tip and wait for that to arrive before I could start!
Delicate but doable work. I made all the loops of wire long enough to be easily moved aside when needed (luckily I only run at 1Mhz with all that wire all over the place).
I then had to write some software to control the board. This meant a new video output routine. Controlling the board is pretty simple as explained on Grant’s site. I am using CB2 as the AVAIL line and CB1 as the ACK line. AVAIL is controlled by Orwell, being set high or low directly in code. ACK is controlled by the video processor and I have it configured as an interrupt on CB1.
To send data to the video board I first get the top four bits of the byte to send then shift them right 1 bit (since bit 7 goes out on port B pin 6 and so on down). I then set up CB1 to interrupt on a positive transition and set CB2 high. That tells the video processor data is available. I then go into a busy loop waiting for CB1 to change.
Once it has processed it it sets the ACK signal which is the positive change on CB1 we are waiting for. The interrupt handler sets a flag which is what the busy loop is waiting for to break out.
I then get the next four bits and shift them 3 places to the left (again to line the data up on pins 6..3 on port B) and this time set up CB1 to interrupt on a negative change and then set CB2 low. Again we loop waiting and when the video board makes ACK low again we break from the loop and finish.
Fiddling with the bits here on PORT B doesn’t upset the keyboard routines since we are only doing it when sending characters. And similarly when we change Port B to scan the keyboard we’re not telling the video board any data is available so it ignores it.
The only issue I had was when I tried it out I was getting video output fine but I was getting odd carriage returns. My code still echos everything to the serial port (save mode) since before the video was driven by serial and that was also showing the odd carriage returns. It was enough to see the video processor was working though. If I commented out the code to the video processor and just left the serial code it all worked fine.
It took me ages to work it out (as some posts to 6502.0rg which helped enormously). One of the problems with only working on this now and again is I forget things (one of the reasons I gave up being a coder, my memory for code is terrible – “Ademo, what’s that?”).
The issue was my video routine was using the accumulator and so it was changing A as it did it’s thing. The serial outputting code, by chance, wasn’t modifying A.
My video routines are called from the MS Basic routine MONCOUT which is in turn called from OUTDO. That routine assumes that A is the same once you return from MONCOUT.
So, with that fixed it all now works great! Taking pictures is tricky since my camera can’t focus on the screen well. The output looks MUCH better on the real tellie than you see here.
That shows some of the different modes. Note the syntax error in the last (un-run) line! The CHR$() just means send the actual value not the ASCII of the value. So PRINT CHR$(24) means to the video board change mode with the next byte being the mode setting.
I have updated a few of the commands. CLS now works correctly. I may update the MOVE function (added for one of the Osborne book games) although you can do any commands using the PRINT CHR$(X) to send the commands. Graphics I need to work out the best way to do. I can plot pixels now using the commands as above but that’s clunky so I think I will add in some actual graphics functions. I will see how it is done in Dave Curran’s Arduino libraries I used for testing it perhaps.
So next I think I need to look at making a case for Orwell. I was looking at laying out an getting a circuit board made for him but that’s a lot of work (and MUCH swearing at Eagle PCB) for not a lot of reward. And if I had done that I wouldn’t have been so easily able to change the video board.
I now have my serial port freed up for just doing serial. I have more VIAs here and will add another to use as general IO ports. I would also like to add a couple of 8 bit analogue to digital converters. Probably using one port on a VIA as data pins and use the control lines to select which ADC to read. The other VIA port can be general purpose digital in/out. That way I could hook on an analogue joystick. And one of the Usborne books I need to review is all about interfacing to computers so it will be handy for that.
The final book I was missing did arrive finally so now I am pretty sure I have a full set!
This post is to start documenting how my Orwell machine works. I’ll update it as things change.
Orwell is a home made 6502 based machine. It has 16K of RAM, 32K of ROM and a 6522 VIA and a 6551 ACIA for IO as well as an additional 8 bit writable latch with debugging LEDs attached. Video output is via Grant Searle’s ATMega based video board.
RAM is provided by a HM62256 32K SRAM with only the first 16K addressable. ROM is a 27C256 EPROM. The additional IO port is a 74HC573 octal transparent latch.
The keyboard is an old surplus Ti99/4 keyboard which is scanned using the 6522 VIA. The same via also drives the video board.
Simple sounds can produced by the VIA using the timer on PB7. Values are poked into the Timer 1 low and high latches directly.
The 6551 ACIA is used for serial communications running at 19200:8,N,1 with RTS/CTS hardware flow control.
RAM is addressed from $0000 $3FFF, IO is from $4000 to $7FFF and ROM from $8000 to $FFFF.
The detailed memory map is as follows:
$FFFF – $FFFE: ROM (IRQ)
$FFFD – $FFFC: ROM (Reset vector)
$FFFB – $FFFA: ROM (NMI)
$FFF0 – $8000: ROM (32K)
$6000: 8 bit latchable IO port (with LEDs)
$5003 – $5000: 5622 VIA
$4803 – $4800: 6551 ACIA
$3FFF – $0000: RAM (16K)
Orwell is running a custom built version of Microsoft BASIC from 1978. I started with the Ohio Scientific code and have modified it to suit the Orwell hardware, adding commands as necessary.
CLS: Clear the screen and position cursor home.
inkey$(x): Returns the currently pressed key or null (not empty string).
E.g. to test for a keypress use: if ASC(INKEY$(0) <> 0 then …key is pressed…
LOAD: Silent load from serial port.
ECHOLOAD: Load from serial port and echo to screen.
The IO port with the 8 LEDS can be poked at: 24576 ($6000)
Sound can be produced by poking values into: 20484 ($5004) and 20485 ($5005)
It’s been a while since I worked on Orwell. I need to get back into doing my Usborne book reviews, especially since I finally found the last book I was missing on eBay and that should be on it’s way.
A recent off topic post on 6502.org mentioned the upcoming Star Wars films. Personally I don’t hold up much hope for them to be honest (if the last ‘new’ Star Wars films were anything to go by) and mentioned that the original is still the best, especially my own special version of course.
I started thinking it would be very nice to be able to play that on Orwell. Unfortunately, with it’s 38 character wide display, that wasn’t going to work too well since my Asciimation is 67 characters wide. To make it work I would need to update the display.
It turns out that a chap called Grant Searle has built, on top of existing work around AVR video output, a video unit and a serial/keyboard controller that will output 80 column text as well as provide a simple graphics mode using an ATmega 328 chip. This is the same microcontroller used in the Arduino.
Theoretically I can take this and just use the video part as a new display module for Orwell. It wouldn’t take much of a hardware change and then I just need to add new software routines to replace the existing ones and finally add support for graphics.
Currently, you will remember, I am using the Batsocks Telemate as my video output device. This also uses an ATmega microcontroller. That is being driven via the serial port (which on Orwell does double duty as a serial port and display driver.
Grant’s video module supports multiple ways to drive it, 8 bit, 4 bit or 2 bit (I2C) interfacing. On Orwell I should have enough bits free on the VIA I am using to do the keyboard scanning and beeper to drive the 4 bit interface. First though I need to get the interface built and working. That turned out to be a bit of a mission!
First up the hardware. This is very simple. I don’t have on hand any 74HCT166 chips though so those are now ordered from RS and should arrive tomorrow I hope. In the meantime I looked at getting the software working.
Grant has provided the source code and the assembled hex file for his interface which is very handy. All you need to do is burn the hex code into the ATmega328 and burn the appropriate fuses. Now burning the microcontroller is easy if you have a programmer. I don’t. You can however use an Arduino to act as one. The code to do this is even included in the IDE as a sample.
First you install the ArduinoISP sketch to the Arduino board you are going to use as your programmer. You then use another tool, called avrdude.exe, to use that Arduino to burn another ATmega chip with the code for the video display. The Arduino IDE already includes the tool in the \hardware\tools\avr\bin folder.
To be able to use the tool I added \hardware\tools\avr\bin and \hardware\tools\avr\etc to my PATH environment variable so I could call it from the command line. The \etc directory is needed since that contains a file called avrdude.conf that the tool requires.
The Arduino with the ArduinoISP sketch running is connected to a breadboard with the device that needs to be programmed. That device needs minimal external components, mainly the clock crystal and capacitors. It helps to wire in the three indicator LEDs to the ArduinoISP board too so you can see that it’s alive, downloading or has an error. I also had to use the 10uF capacitor reset hack to make things work.
Ratehr than just downloading the hex file Grant supplies I wanted to see how the code works and assemble it myself. To do that you can install the free AVRStudio6 software from Atmel. With that installed I was able assemble Grant’s source code to produce the hex files myself.
Now to get the file on the ATmega328 you need to connect up the ArduinoISP as described on this page and then use avrdude.exe to download it to the chip. Avrdude has a fair few command line parameters you need to use but when you look at them one by one isn’t not too difficult. The documentation for the arguments is here. You can do it all from the command line but I found it easier to configure an external tool in the AVRStudio IDE. This IDE is using the Microsoft Visual Studio IDE isolated shell which means if you know Visual Studio AVRStudio should be quite familiar.
I added an external tool for calling avrdude.exe to download the main code and set the fuses on the microcontroller. You should note on Grant’s page that the fuse setup is particular for his video controller.
The arguments I used for the tool are:
-p m328p -P com3 -c arduino -b 19200 -U flash:w:”$(ProjectDir)Debug\$(ItemFileName).hex”:i -U lfuse:w:0xe6:m -U hfuse:w:0xd9:m -U efuse:w:0×07:m -u
- -p m328P sets the device type.
- -P com3 sets the serial port the Arduino is connected to.
- -c arduino sets the programmer type.
- -b sets the baud rate.
- -U means a memory operation.
- flash means burn to the main flash ROM memory.
- w means read the specified file and write it to the specified device memory.
- “$(ProjectDir)Debug\$(ItemFileName).hex” is the path and directory to the hex file.
- i means the file is in Intel hex format.
The further -U commands are to write the fuses, lfuse, hfuse and efuse.
One little quirk I found was the fuse generator tool was give me back a value of 0xff for the efuse. If you try using that value you will get an error in AVRStudio when you run the avrdude tool:
avrdude.exe: reading input file "0xff" avrdude.exe: writing efuse (1 bytes):
Writing | ***failed; ################################################## | 100% 0.16s
avrdude.exe: 1 bytes of efuse written avrdude.exe: verifying efuse memory against 0xff: avrdude.exe: load data efuse data from input file 0xff: avrdude.exe: input file 0xff contains 1 bytes avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.02s
avrdude.exe: verifying ... avrdude.exe: verification error, first mismatch at byte 0x0000 0xff != 0x07
It took me awhile of looking to work that one out. It turns out that on the 328P chip only the bottom three bits of the efuse flag can be used. You can write to it fine but when you read it back the top 5 bits will always read back as 0. So we try to write 0xff and we get back 0×07 since only the bottom three bits have been changed. The bits have been changed, it’s just the avrdude tool complaining since the verify failed. But if you want to get rid of the error the solution is to write 0×07 to the fuse.
Once all that is done I was able to modify, assemble then burn the code to the ATmega chip. Phew!
To test that everything works you need to then control the chip. On Grant’s page he used yet another ATmega as a keyboard/serial port controller. However another chap called Dave Curran has written some code that uses an Arduino to drive the video board. That is all described on his blog here.
He provides the Arduino library code and several example of driving the video board. It is a simple matter to upload the appropriate sketch to the Arduino then use that to control the video board.
Now, at this point you’re probably totally confused. I was. It’s bloody ATmegas all over the place! But this should help:
Right, what we have here as my bench test setup is as follows. The top Arduino is my ArduinoISP acting as a programmer. Beneath that on the breadboard is where you plug in the ATmega328 chip to program with the video driver code.
Once programmed that then moves to the left of the breadboard which is the video board hardware section. Missing to the far left is the shift register chip. The yellow and black wires go to the video-in on the tiny LCD monitor I am using as a display.
The bottom Arduino is being used to drive the video hardware via a four bit interface (with two control lines) via the rainbow ribbon cable. That Arduino has one of Dave’s example sketches loaded on it.
Once my 74HCT166s arrive I should be able to finish breadboarding the video board then just fire it up to see if it works. Assuming it all works I can then take just the video section, build it up on Veroboard and connect it to Orwell to see if I can drive it that way. That will require a minimal hardware mod, basically adding a new header to break out the appropriate pins on the existing VIA. I have just enough data lines free on Port B, B3..B6, and should be able to use CB1 and CB2 as the control lines I hope. I already have a 6 pin header going to the Batsocks. I can rewire that and add another 2 pin header for power. As it is now the video processor will be on it’s own, small board so it can be easily changed at a later date.
That will free up the serial port for just serial use (loading and saving). Theoretically, apart from some configuration changes, I only need to change one routine in the Orwell code to work with the new video display. Graphics can be added later.
I will see if anything works when the final missing chip arrives!
Some time ago I did some posts on receiving weather satellite images from the NOAA satellites using a receiver and a home made antenna. Part One, Part Two, Part Three. This is the kind of image I want:
I had my receiver working and was going to build a circuit to automate the tuning of the satellites. I did actually achieve that. In the end I had breadboard and had working a receiver run by an Arduino. The Arduino was used to switch in different tuning resistors in sequence. Each resistor tuned the receiver for a different satellite. It would listen to each channel for 30 seconds or so. A tone detector on the audio output would then listen for the tone from a passing NOAA satellite and if it detected one it would signal the Arduino which would stop changing the frequency of the receiver until 30 seconds or so after the tone had passed. That way when a satellite passed overhead the circuit would detect it’s tone and the receiver would listen to it for the full pass. Once the tone passed the receiver would start scanning through the frequencies again. This worked very well but I never got past the breadboard stage. Eventually I needed to get a new roof on my house and the antenna, which was sitting on the guttering, was taken down and I never got around to putting it up again. The breadboard got buried under piles of other projects and was forgotten. In a recent clean up I found the breadboard again. It would still work and I could have made a permanent home for it but in the passing years (it was in 2010 I made that) a much better way has appeared – SDR or Software Defined Radio. A search on this will find many interesting pages. It turns out that it is extremely cheap and easy to do SDR on a normal PC using USB digital television dongles. All you need is a dongle, some software to run it (and the right drivers) and a suitable antenna. The dongle I got off TradeMe for NZ$30. That included a tiny antenna and three antenna adapters. This dongle is an RTL2832 based one which a bit of reading will tell you is a great one to use for SDR. The dongle needs special drivers as well as some software to drive it. The drivers allow the receiver to be used for SDR rather than just as digital TV receivers. They’ll receive in the range from about 25MHz right up to about 1700MHz. So one of the signals you can receive is the 137Mhz or so signals from the NOAA weather satellites. My plan was to recreate my weather satellite receiving station using SDR. The best place to start is here on RTL-SDR. Once you have the basics installed you can follow this excellent guide for receiving weather satellite pictures. That guide is what I used but it doesn’t quite get you all the way to a fully automatic setup that you can just leave running all the time. This is how I did that. My instructions are similar to those in the guide with a couple of extra steps. I am running on Windows 8 and it is best to run each application as an administrator so everything works. Basically, as per the guide, we will use Orbitron to track the satellites and, via the Orbitron DDE plugin, set SDR# to the correct satellite frequency when the satellite is overhead. We’ll use WXT0Img, the software I originally used a few years ago, to decode the audio SDR# receives from the satellite and to build and upload an image. The instructions for how to install the Orbitron plugin into SDR# are in the Orbitron download. As the guide mentions the instructions are a bit odd in places. I did get them to work though. I found I did need to install the DDE driver (in the drivers section on the Orbitron download page) and that when I click the button next to the SDR Sharp drop down on the Rotor/Radio tab in Orbitron a little window called “My DDE Client 1.05″ would pop up. This window needs to be there on my setup for the DDE link between Orbitron and SDR# to work. The audio piping also needs a little explanation. Basically WXToImg needs the audio signal from the satellite. You need to get the audio from SDR# into WXToImg. Initially I was using Windows Stereo Mix (I had to install the latest Realtek drivers to get it) and that works but the issue was all the sound was still going through the PC speakers. Very annoying when most of the time it is just static! To get around that I downloaded and installed VB-Audio virtual cable. This is again free and what it does is install new virtual audio devices on your machine. Then it is a simple matter of selecting ‘CABLE Input’ as your audio output device in SDR# and “CABLE Output” as the default audio device in WXToImg. That links the two together and the sound doesn’t play though your normal speakers. Now the tutorial gets you as far as having all this setup and running and you are able to manually select which satellite to receive. Selecting each satellite passes the correct tuning information to SDR# via DDE. WXtoImg is set to automatically record and it will start recording when it thinks a satellite is overhead (both Orbitron and WXToImage make use of downloaded Kepler data to do this). I found however that there is one extra step needed to make it fully automatic. That is Orbitron automatically tracking several satellites and sending the right frequency to SDR# when each comes into range without having to manually change which satellite is active. The trick is two settings on the setup page in Orbitron. The first is on the ‘Miscellaneous’ tab. In there there is a section for ‘AOS Notification’. Basically what this does is plays a sound and notifies the user when a tracked satellite becomes visible. You can set the elevation angle there but I left it set to the default 0 degrees.
The second setting is on the ‘Extra’ tab and it’s the very last setting called “AOS Notification: Make satellite active”. This is the important one. Make sure that is ticked!
All this does is makes each of your selected satellites the active one when it comes into view. Setting a satellite to active is what sends the correct data, via DDE, to SDR#. One final trick I had to do was to ensure that selected satellite downlink frequencies on the Rotor/Radio tab for each satellite were correct. I found that they were wrong by default for some reason so I needed to manually change them there. I just track NOAA 15, 18 and 19. Basically I have Orbitron, WXtoImg and SDR# running all the time as well as the little DDE client. When Orbitron sees a satellite is visible it will update SDR# to change to that frequency. WXToImg, using it’s own satellite data, will start recording at the appropriate time and I have it set to automatically upload the images to my web page here. And finally I got around to mounting my antenna up on the roof properly using a pole. This really makes a difference to the quality of my received images.
And here are some images I received from passes today (a nice, fine day!):
One thing that may be interesting is what happens when two satellites pass at the same time or close to each other. I think Orbitron will switch to the second one as soon as it is in site which will cause SDR# to change frequency. WXToImg will continue recording the first one though. I am not entirely certain what will happen in that case. You can tweak the recording setting in WXToIMG so it won’t record unless the satellite is above a certain number of degrees and reaching a certain minimum angle above. And you can tweak the AOS degree angle in Orbitron. I might need to fiddle with the values a little to avoid changing frequencies to satellites WXToImg isn’t going to record anyway. Funny, as I am writing this NOAA 15 is doing a very low pass off to the West of me. Orbitron made it active as it is visible above 0 degrees elevation. WXToImg would normally ignore it as the pass is too low in elevation. I tweaked it’s settings to see if I can get a signal from such a low pass. Something is coming through but it is very noisy. I think the thing to do will be set WXToImg back to the default settings (only record when elevation is more than 8 degrees and the satellite will reach more than 20 degrees) and change the AOS setting in Orbitron to only change the active satellite when it goes over 7 degrees. That should give me good clean recordings. Of course the best images are obtained when the satellite passes directly overhead. That also gives you the biggest image (well, biggest area view). OK, that satellite passed and I did get some kind of image:
The satellite was so far over to the west that’s basically the arse end of Australia. Also notice how the image is not as tall as the others. Because the satellites are orbiting and basically making the picture by scanning a line at a time (like a fax machine) as they orbit the higher overhead it is the bigger the picture you’ll get. It is over head longer so you get more scan lines. If the satellite is passing far to the East or West of my position then it won’t be high up in the sky and so won’t be as visible for long. I’ll set things up to only record those satellites that will give a good image. All the images are being uploaded automatically to http://www.asciimation.co.nz/weathersat. I am not sure how long I will keep this all running but it seems to be working well at the moment so I will leave it going for a while. Eventually I might want to do more experiments with my $30 SDR though.
Update: I have found that the DDE link between Oribtron and SDR# has stopped working on at least one occasion. If that happens the frequency doesn’t get automatically changed so I stop getting images from two of the satellites. The third keeps working of course since the frequency is stuck on it. It is something I need to keep an eye on.
OK, another review. This one is interesting for a number of reasons. I did most of the work away from home on holiday between Christmas and New Year. This proved Orwell makes a good travel computer (although he needs some help for now). It also bought up a new command for me to support. And finally I found an odd quirk in the original MS Basic. I am not sure it’s a bug or not but it’s definitely odd. But, lets start at the beginning.
- Title: Creepy Computer Games
- Subtitle: For SPECTRUM, ZX81, BBC, ORIC, VIC20, TRS-80, APPLE, DRAGON
- Authors: Several! (program editor Chris Oxlade)
- Editor: Jenny Tyler
- Pages: 16
- Published: 1983
- ISBN 10: 0860207803
- ISBN 13: 978-0860207801
This book is quite a thin one and it has 8 programs to enter, all with a ‘creepy’ theme. It jumps straight into things and there is little intro and none of the descriptions of BASIC or lists of keywords some of the other books have.
As always to avoid having large chunks of listings in these reviews I have instead made the listings available as a ZIP file here: http://www.asciimation.co.nz/UsborneBookReviews/
You will notice the beachy background behind the cover photo. This is at Ahipara, the base of (incorrectly named) Ninety Mile Beach in upper New Zealand. I was on holiday, roughing it away from garage and computer, but I was able to take Orwell with me and get him working.
The netbook is basically being used as storage. Orwell can send and receive serial commands via a USB to serial converter and a terminal emulator on the netbook. I was able to enter the programs on the netbook, store them then LOAD them into Orwell. I could then make changes and send them back to the netbook for re-saving if needed. Output was to the tellie (which works great). Unfortunately with only my phone as a camera I wasn’t able to get clear pictures of that screen so I retook the photos on my own tellie once I got home. It wasn’t until I was home I got all the programs to work anyway as you well read below.
Lets start with the first program. Computer nightmare.
This is a simple game. It’s just a random number matching one. The computer generates random numbers and you have to type them in. Nothing difficult at all. It also prints up (not very insulting) insults at you.
This wasn’t a particularly exciting start to the book. Not even worth a screenshot.
Next up we have Number Wizard. Again this is a simple random number type game but this one is a little more interesting.
The computer generates two random numbers between 1 – 9 and prints them on screen. It also prints out a list of number from 1 – 9 across the screen. You have to enter two numbers that are in that list and also that add up to the same total as the two number the computer generated. So if those numbers were 3 and 5 you need to choose two number that add up to 8 and are in the list on screen. Once you use a number it disappears from the list.
You are able to use 0 as one of your numbers which I originally thought was a bug but it is actually coded that way (and commented in the book as such).
A little more satisfying than the first game but nothing special.
Next we have Ghost Guzzler. This one proved interesting, not for the game itself which is another number matching one, but for a quirk it showed up in MS Basic.
This game generates a random number that moves across the screen towards your ghost guzzler, a ‘:’ and a number. You change this number so it matches the moving one and when that hits your guzzler it is eaten. If the numbers don’t match you lose a life.
There is nothing special in the code. But it didn’t behave correctly. Instead of the random number starting off at the left most column of the screen it started in the third one. It wasn’t till I got home I could debug why.
The line of interest is this:
120 PRINT TAB(I);N;TAB(18);”:”;Y
Where I is the position of the number. N is the number and Y is your changing number. I starts at 1.
It turns out there are two quirks in the version of MS Basic I am using. I am not sure yet if they are bugs though.
The first is the TAB command starts indexing at 0 not 1. So TAB(0) is the left most column. TAB(1) is the second column and so on.
The second is when printing a numeric value (such as N or Y above) an extra space is printed before the number.
The combination of these two quirks meant that lines of Basic starts printing in the third column across. I tested this out on a VIC20 online emulator and an online Applesoft Basic emulator, both of which use their own variation of MS Basic. The Vic emulator shows both quirks whereas the Apple one doesn’t.
Investigating the assembly code for each version does show there are differences in the code so it might be something Apple ‘fixed’ in their version of Basic. I am not sure if I will change Orwell or not yet but I think so as the printing of the space before the number seems wrong to me. The two quirks are related as it is the code that handles the printing of TABs and spaces where the differences are. I am still studying the code but I believe the issue is in how it is checking how many spaces to print and where and when it decrements the count.
Next up we have Spiderwoman.
Yet another guessing game. In this one the computer chooses a random letter then you have to guess what it is. you enter in words are are told if the letter is in your work. You can then narrow it down until you are ready to guess the letter. You only get to enter 15 words though.
The next game, Gravedigger, is a big one compared to the others but it is quite satisfying and actually quite a challenge to play.
The game draws a graveyard filled with random gravestones. You (*) move from the start to the exit in the opposite corner by specifying an N, S, E or W direction. You can’t move though walls (:) or gravestones (+) as they block your way. To make things harder three skeletons (X) are following you but you can block their way by digging holes (O). Don’t fall into your own holes though!
Visually this is an interesting game. And I haven’t actually beaten it yet!
Next up is Mad House.
This game prints three lines representing walls which have a moving door each (represented by > <). You can move the top and bottom doors left and right. The middle one moves randomly. You have to get all three to align so you can escape (indicated by a line of ‘M’ footsteps!) before a counter on the screen reaches zero.
This game threw up a command I didn’t have – PRINT AT. The lines in question are:
180 PRINT AT I,0;L$
190 PRINT AT I,P(I/5);”> <”
Different computers do this in different ways but basically it’s a command to move the cursor to a different part of the screen then print there. Orwell didn’t support this and I couldn’t add that functionality until I got home as it meant modifying the original MS Basic code and burning a new ROM.
To actually add the command I needed a new command and two values, the X and Y co-ordinates to move to. I knew the Batsocks video board supported a move command. The command you use is: <ESC>Y xy
That is actually a VT52 terminal command.
Basic didn’t have any existing command where it took two number values as input for me to copy so instead I created a new command, MOVE, that takes no parameters. Instead I created two memory locations at 0X30F and 0×310 into which you can POKE the X and Y values. The command then just reads from those locations.
So in Orwell code the lines above become:
180 POKE 783,I: POKE 784,0: MOVE: PRINT L$
190 POKE 783,I: POKE 784,P(I/5): MOVE: PRINT “> <”
Memory locations are POKEed using their decimal value hence the 783, 784.
This works very well and it is used again in a later game.
Next up is Ghost Maze.
This game creates a maze and you have to escape (and not get caught by a ghost). You can how ever only see a little of the maze in front of you and you can only move forwards or rotate left and right.
This game is OK but a little hard to play as it loops slowly and it’s a bit fiddly getting it to accept your input as it is using inkey which continuously scans for a key. So sometimes it doesn’t see your key press and other times it will see it multiple times.
The final game is called Seance.
This game also uses the PRINT AT function so I didn’t get it working until I was home and added in my MOVE command.
The game prints the letters of the alphabet arranged in a rectangle (as if the edges of a table). An asterix (*) then appears next to a letter and then and randomly moves about to be next to another letter. The number of letters and sequence is random. You have to remember the letters in the correct sequence then type them in correctly when asked.
It keeps a score and once you get enough right you win or, if you get too many wrong, you lose.
All in all this was a very good book. Some of the games are a little lame. More of the usual guess the random number/letter type but in this book they are presented in an interesting way. And it threw up some interesting problems for Orwell.
One other small thing I found was a bug in my keyboard handling code. To handle the ALPHA key (basically a caps lock key) I was checking if it was a letter key that was pressed and if so making it upper case. Only I was off by one when checking if it were the ‘z’ key. I was only checking between a-y not a-z. So the ‘z’ key wasn’t being capitalised if ALPHA was down. Not a show stopping bug as you could always SHIFT it to uppercase it but good to find and fix.
Finally on the back cover of the book it lists some others in the Usborne computer series:
- Usborne Guide to Computers
- Understanding the Micro
- Computer Programming
- Computer and Video Games
- Computer Spacegames
- Computer Battlegames
- Practical Things to do with a Microcomputer
- Computer Jargon
- Computer Graphics
- Write Your Own Adventure Programs
- Machine Code for Beginners
- Better BASIC
- Inside the Chip
All of these book I now have and I have linked to the ones I have already reviewed. There are lots more to come. And I only have one more book (Computer Spy Games) to get to complete my collection!
One final little interesting bit of information. That beach I was on is actually a public highway. So it is perfectly legal to drive on the beach!