I've always wanted to explore bit-mapped graphics on the UK101, but it does not have such a facility. But many years ago, I saw a program (probably in one of the 1980s home computer magazines) that turned the Commodore PET's 40x25 text screen into 80x50 pixel graphics. I think it was called "PLOTSUB" and I wrote something similar for the UK101 in BASIC, although it didn't work as well as the PET version. Being in BASIC, it was slow. How about a better implementation in 6809 assembler?
So we now have two routines, 'setpixel' and 'clrpixel', that set and clear a pixel on a 48x32 bitmap on the UK101 screen. And some demo code to call those functions, and a simple random-number generator (RNG).
[As I write this in 2024, I realise that this update to the UK109 was on my 60th birthday, and I haven't touched it since then.]
Well, that didn't work very well! The hex loader was reading data from the keyboard, not from the 6850 ACIA. I think I originally wrote it for another 6809 dev board that used a serial port for all of its I/O. Oh well, it's fixed now by the simple expedient of duplicating all the hex input routines with versions that read from the ACIA. At 300 baud.
I have now completely switched over to using the new 'asm6809' assembler by Ciaran Anscomb. The source code is set up for that assembler, with a SETDP directive (which the old assembler didn't even support), the ENDIF keyword, and all HD6309 instructions coded as mnemonics instead of being built up from FCB and FDB directives. The Makefile now uses sed to switch the code over to the M6809-only form and to convert the directives to suit the Frankenstein Assembler. So I now get three output files in all: an Intel HEX file from the old assembler with M6809-only code, an Intel HEX file from 'asm6809' with HD6309 code, and a Motorola S-Record file also with HD6309 code.
I'm pressing on with adding HD6309 instructions for scrolling, clearing the screen and copying the screen buffer to/from RAM. I also want to load and save programs via the 6850 ACIA, so the first step is to test that with a simple message at 300 baud. The new 'T' command does that and I've successfully received the message on the Linux development machine in minicom. And I have a rudimentary S-Record output routine that has proved that I can generate correctly-formatted records with correct checksums. I've compared the generated records with the assembler output for the same region of the EPROM, and they match!
While updating links on my web-site, I spotted an interesting development on the 6809.org.uk page. There's a new 6809 assembler there, as source code in a Git repository. And this new assembler supports the HD6309 instructions too! Time for an upgrade...
Compiling the code required the installation of the Autoconf tools, but that was a straightforward apt-get command. The same goes for the lexical analyser and parser generator tools, Bison and Flex. Once configured and compiled, I had a working HD6309 assembler but with slightly different directives from the old Frankenstein Assembler (which is a very old K&R C program). With a few sed commands in the Makefile, I was able to convert on-the-fly from one form to the other and assemble the code with the new assembler. The two HEX files generated were identical, as verified with diff.
Having read the documentation for the Frankenstein Assembler more closely, I found that it has conditional assembly. There's an IF directive, as well as ELSE and ENDI. Which means I can use EQU to make a symbol called HD6309 and set it to 1 if I want to include the code for that chip, or 0 if I want to just run the standard 6809. Just to try it out, I used the directives to assemble-in the existing HD6309 code that I'd commented-out some time ago. That all worked as expected after I'd burned a new EPROM and installed it in the machine.
So after doing that and committing the code to the GitHub repository, I can see the new HD6309 registers in the 'R' command's output. I also fixed most of the compiler warnings in the Frankenstein Assembler, although it's all in K&R C from the late 1980s. I tried out a few HD6309 instructions, like TFR D,V and TFM U,X+. The latter will be useful for scrolling and clearing the screen. But testing those instructions revealed that I hadn't finished the hex entry routines in the machine-code monitor. Maybe I should do that, and maybe also add some way to load small test programs into RAM from the 6850 ACIA.
RetroChallenge 2021-10 is over and the UK109 is better for having taken part in it. I have the 6809 source code in a GitHub repository now. I have a few photos in this album on Flickr. I have a video of the machine running on my YouTube channel. And I've written about it in more detail on my blog.
Wow, that's a lot of social media! Follow me on Twitter.
Well, it wasn't a dud address line, it was a dud data line. The data bus going to the 2716 monitor EPROM just wasn't making contact at pin 13, data line D3. I suspect it's due to the original UK101 socket on the main PCB, underneath the ZIF socket that I'm using to hold the frequently-updated monitor EPROM. At the moment, if I press down on the pin 13 area of the chip, it makes contact and the machine runs.
I should really desolder the socket and replace it with a nice turned-pin one. But to do that, I must remove the big PCB from the wooden case, turn it upside-down and desolder the socket without damaging any tracks. That sounds like it could be tricky, and it's nearly the last day of RetroChallenge. Maybe I'll bypass pin 13 with a jumper wire, just for the time being.
As part of the 2021-10 RetroChallenge, I tried to run the 6809 machine again. It didn't work.
So I've got some diagnosis and repair to do. So far, I've verified that the contents of the 2716 EPROM is OK, and the 6809 clock is OK. I have also found that the machine is not accessing video memory at all, even though that's just about the first thing it does after reset. I suspect a dud address bus line somewhere, but where?
The big event of 2010 was the first UK Vintage Computer Festival at Bletchley Park. I took all three Compukit UK101 machines to the show, and they ran all weekend. Photos of the event are in this Flickr set. Earlier in the year, I also took them to Newcastle for the second Maker Faire UK. Again, photos are in a Flickr set. I had one failure at the Maker Faire, in the Philips CM8833 colour monitor (some info about the repair). But even with those two shows, the 6809 machine hasn't progressed very much. I've added some box-drawing routines to the VDU driver, so that I can make the display look a bit more fancy, but that's about all.
I had an idea to make a 48x32 pixel low-resolution bit-mapped graphics mode by drawing two pixels in each text character cell. The UK101's block graphics character set allows for that by providing blocks with the top and bottom half of the cell illuminated. By writing a routine to convert from a 48x32 pixel bit-map to the 48x16 character video screen, I could display low-res images. But the question arose: do I write that routine for the 6809 machine or for the original 6502 UK101? The right answer, I suppose, is to write it into the ROMs of both machines.
A lot has happened since my last update here. Firstly, I took the three UK101s to Tech Adventure in Bristol (28th February). All went well, and we even had another UK101, brought along by a member of the Bristol Linux User Group. Photos are in this Flickr set. But the really big event was the first UK Maker Faire, in Newcastle (14th-15th March 2009). For that event, all three UK101s (my original one, an unmodified one in original cardboard box, and the 6809 modified one) ran all day for two days. The two least modified machines worked flawlessly, but my own highly modified UK101 did crash a few times. Most disappointing was the failure of the cassette player, which prevented me from loading tapes and also began to scarily chew them up. At the very end of the weekend, the BBC came over to record a short interview about the machines, now on-line here (other BBC reports from the Faire are in video here and as a radio programme on the BBC World Service and on Radio Four). Once again, my photos of the event are in this Flickr set.
So now what? I have the UK101s back in their usual places at home and reconnected to their usual video monitors. I have an LCD monitor, designed for an Xbox, that I plan to connect up and use as a UK101 display (it's not quite working properly yet, though). I'm still messing about with the 6809 code now and then, but progress is not quick. I want to do something for the 30th anniversary of the UK101 in August this year, but I'm not sure what to do yet.
I now have two 2716 EPROMs with 6809 code in them, in two of the ROM sockets on the UK101 motherboard. The split seems to have gone OK, although I now realise that there are locations in RAM that are referred to by both "halves" of the ROM code. This means that I can't just modify the RAM addresses willy-nilly, because if I do, one EPROM will have the new version while the other EPROM will still have the old version. The EPROM at $A000, the old UK101 BASIC location, is in an ordinary 24-pin DIL socket, and I don't want to keep changing it. The other EPROM at $F800, the old UK101 monitor ROM address, is in a ZIF socket, and that's the one I change for each new version of the code.
Meanwhile, I've had an idea about replacing the 6850 UART chip with a 24-pin DIL header and wiring up a small circuit with a couple of 74LS244 buffer chips to emulate it. Then, I can supply data to the '244 chips from another source, such as an Arduino board, or a plain ATmega168 chip, or even a PC with a parallel printer port. The result: a very fast program loader to replace the 300 baud cassette tapes.
Today, I fixed the flaky hardware. I cut up and desoldered the old header pins on the bottom of the Six Adaptor, and fitted a new 40-pin header and resoldered it. The machine started up straight away after replacing the 6309 chip in the adaptor (and reconnecting the video lead after I'd been using it with a Sinclair Spectrum).
Now what? Well, the first thing to do is get the software back to the state it was in last time I worked on it. That is, with the 2k byte EPROM full. Ah, yes, I was trying to split the code into two 2k byte EPROMs when the trouble started. Right, back to the split version and two 2716 EPROMs.
So much for having more time and enthusiasm for the 6809 project. Eight months have passed with no real progress on the modified UK101. However, I have recently been given another UK101, complete with cardboard box and manual. That one is absolutely original, and will need little more than cleaning up to make it look just like it did in 1982, when it was built. The UK101 that I'm using with the Six Adaptor has had a few things soldered onto it over the years, but nowhere near as much as my own UK101.
But one of the frustrations with this project has been reliability of the hardware. The basic UK101 has been OK, but I've had trouble with the green screen video monitor, the EPROM programmer, my own PC and now the Six Adaptor itself. The other troubles have been fixed, so now it's time to concentrate on that little adaptor board that rewires the 6502 socket to accept a 6809 chip. I made it using parts that I had to hand, which worked fine for a while. The bottom of the adaptor is a 40-pin header that plugs into the 6502 socket, just like the original chip did. Now, I didn't have a 40-pin DIL header in stock when I built the Six Adaptor, so I used some cut-up and patched-together headers that I happened to have lots of. This may have been foolish, because I have now traced the source of the flakiness in the machine to the poor contact between header and socket. The patched-together headers are not quite accurately aligned, and the socket in the UK101 just doesn't quite make proper contact.
I've recently ordered a batch of parts from Farnell, and along with those, I ordered a 40-pin DIL header (176-366) to fix the problem. Those parts have now arrived, so the next step will be to solder it all together and test it. I also have a 24-pin DIL header (176-364), but that's a whole other story about character generators and video signals and the UK101's slightly bizarre timing chain.
Having been distracted by work for over a year, I'm now back at university, which means I have a little more time and enthusiasm to work on 6809 code. I've added a few things, like a visual bell function that responds to the CTRL-G character by flashing the video screen (no audio output hardware on this machine). There's also a VDU test function that displays the whole 256-character set so that I can fully test the character generator EPROM (it's fine). Looking at the character set, I remembered that I wanted to add a one-pixel border around the entire screen at start-up, to help with lining up the video monitor. The code to do that is a bit awkward, but it works. I've also had an idea to do 48x32 pixel block graphics using the UK101's character set. Then again, I might change the character generator EPROM from a 2716 to a 2732 so that I can get 16x8 pixel characters, which will make for much nicer lower-case.
On the hardware front, I've fixed the flaky brightness control pot on the BMC green-screen monitor that I use with the 6809 machine. This makes it a bit easier to just switch on and go, without having to mess about getting a good picture on the monitor. I've also fixed up the Stag PPZ EPROM programmer which I use for all my development work. It was built in 1984, and needed a bit of repair to the keyboard (photos here). Wish I knew why it won't accept hex files at 19200 baud, though. Maybe a few carefully-chosen delays will make it work properly.
One benefit of my previous job was that I learned about Subversion, an open source version control system. I've now got all the assembler, simulator and 6809 code sources under Subversion. This means I can easily work on them on any of the machines that I connect to the home network, and keep the master version up-to-date.
But now I've run out of room in the 2k byte EPROM (2716) that holds the machine-language start-up and monitor routines. No amount of byte-saving seems to have helped, and I'm now down to the last 64 bytes. That's 64 bytes with all the temporary test code removed from the machine-code monitor, which means that I've actually got fewer functions in there. And all the functions I want to add next are bigger than 64 bytes, most of them by a large margin. I think I'll have to split the code into stuff that works and I can leave alone (the Matrix display hack, the VDU scrolling code and keyboard polling code) and stuff that I want to change frequently (machine-code monitor functions and start-up self-tests). Then, I can put the two sections into two separate 2716 EPROMs and put one in the ZIF socket and the other in one of the non-ZIF sockets on the main board. But that'll mean messing about with the addresses of stuff so that it'll work in the other socket, which may get a bit messy.
As a first step towards implementing the frame flyback interrupt, I've installed a Hitachi HD63B09P chip in the socket on the Six Adaptor. This is a rare chip, originally built as an enhanced 6809 but sold as simply a clone of the 6809. Hitachi never fully documented the enhanced features of the chip, but most of the improvements have been deduced and written up by enthusiasts. The big feature that I need for the frame flyback interrupt is the 6309's block transfer instruction, known as TFM for TransFer Multiple. Without TFM, the original 6809 just isn't fast enough to copy the entire 768-byte screen buffer to video RAM during the frame blanking period.
Been reading Andy Hertzfield's "Revolution In the Valley -- How The Mac Was Made", which mentions the early 6809-based Mac prototype. It also talks about the regular frame flyback interrupt that the machine used to synchronise with the display refresh cycle. Now, I've never done any programming with a system like that, and I began wondering if there'd be any benefit to using a frame flyback interrupt on the 6809 machine. One of the flaws of the original 6502-based UK101 was that it produced video "snow" whenever the CPU accessed the video RAM. I started thinking about a scheme where the 6809 would copy the entire text screen from RAM into video memory on every frame flyback (during the 3.6ms blanking period). This would make all display updates synchronous with the display refresh, as well as eliminating "snow" by having all video RAM accesses happen during frame blanking. I'd need a source of interrupts, of course, as well as the software to handle them. Might be worth trying though, just to see how it looks.
Doing a bit more with the Frankenstein Assembler, to give it its full name. It was posted to the comp.sources newsgroup in 1990, in many separate 'shar' archives. I now have all those archives from an FTP site and I'm putting them together again. My plan is to put together a proper release of a new version, with bug fixes, removal of compiler/linker warnings and portability to NetBSD on both 32 and 64-bit hosts. I have an Alpha and an UltraSparc to test it on. Will probably do the same things with the 6809 simulator, too.
Ignore everything I said about 'printf' yesterday. The assembler doesn't even use 'printf' to generate hex digits in the object code and only uses it occasionally in the listing file. I'd already fixed the assembler by changing an array of ASCII codes in the source, but I have absolutely no recollection of doing that. I hadn't installed the fixed version on my development machine (but I have now). And I've fixed the 'Makefile' so that the options come before the filename arguments, as they should do.
Messing about with the 6809 assembler today. Decided to try compiling it on the 64-bit Alpha machine that I happen to have, running the NetBSD operating system. I get a few niggling differences from the Linux-compiled version of the assembler. First of all, I get a warning about the use of 'mktemp' to create a temporary file. Next, the command-line parsing doesn't work the same as it did on Linux (all the options must come before the filenames). And finally, the output files are different! Exactly the same size, but the NetBSD versions have the hex numbers in upper case (as they should be) instead of in lower case (which caused the problem I described in the original notes about the EPROM programmer).
So, I recompiled the assembler on Linux, just to make sure. And I get the same warning about 'mktemp'! Looks like I really do need to fix that. And now the Linux version has upper-case hex, too! Well, the Linux 'printf' was obviously the source of the trouble, and in between Slackware 8.0 and Slackware 10.1, they've fixed it. And I hadn't recompiled since I did the upgrade.
Ran the Matrix display hack again. Really must do more with the machine than this!
Over a year since the last log entry here and no real progress with the 6809 software. I run the machine occasionally to impress visitors with the Matrix display hack, though. I now have a few of the rare-as-hen's-teeth Hitachi 6309 chips, as well as a board to run them in. In principle, they'd work in the Six Adaptor, but I've not actually tried it yet.
Starting a new job today, with Linux on the ARM. May not have much time to work on 6809 code.
Playing tetris on the Game Boy is making me think about writing games for this machine. There's no way to connect a game controller, though, so I'd only have keyboard controls. And there's no sound and no colour apart from green.
Visitors most impressed with retro text-mode Matrix.
Plugged in a real green-screen monitor for the full effect. My usual UK101 monitor is a nice Philips amber one, but I have a couple of BMC monitors in the loft with green phosphor. The contrast control is a bit noisy, but it works.
More work on the Matrix display. Made the startup look right, with a random number (0-15) of blanks preceding the random symbols. This allows the faster-scrolling columns to reach the bottom of the screen before the slower ones have got started. But as yet, no fresh blanks are introduced to make gaps in the display. Nor do columns occasionally stop and restart.
The Matrix was shown on TV the other day, and inspired me to write a green-screen display hack. So, first of all I'll need a video memory save/restore routine -- not too hard in 6809 assembler with proper 16-bit index registers. Next, a random number generator (24 bit shift register with exclusive-OR feedback, as shown in Horowitz & Hill). Finally, some tricky timing code to allow each column of the video screen to trickle down at different speeds. Use the random number generator to produce new characters at the top, but limit the choice to 64 non-alphabetic characters. The UK101's tile graphics turn out to be quite good for this sort of display!
No progress.
Coded a new version of the UK101's '@' command to read a memory address and then display the contents of that address. Then, allow the user to edit the contents in hex and/or move on to the next (or previous) address.
Decided to implement a very simple machine-code monitor just so that I can get some software running on the 6809 without getting bogged down in the details of the design.
Linux User Group meeting. Back at the 6809, thinking about ways to improve the UK101 machine-code monitor to allow for such luxuries as a backspace key. There are quite a few ways of doing that, all with their good and bad points.
Deciphering the 6502 disassembler code seems to have done my head in.
No progress on the 6809 code today, because I've been distracted by looking at the original 6502 code on the UK101. I'll probably implement a 6809 machine-code monitor next, which will most likely be very similar to the 6502 monitor in the UK101. So, I'd better remind myself how that works. It's been 20 years since I last had a look at that code, and there are plenty of parts that I never understood in the first place. In particular, the 6502 disassembler was always a complete mystery to me. There are no ASCII codes in the EPROM for any of the 6502 mnemonics, nor are there visible ASCII codes for addressing mode syntax like ',X)' or '),Y'.
Decided to implement the cursor today, as well as fix the bug I introduced yesterday. The cursor on the original UK101 wasn't very exciting, just a blob (half as tall as a character cell). My improved UK101 monitor EPROM had two cursor styles, one for input from the keyboard and another for input from the cassette (both a full character cell in height). Might as well do the same thing for the 6809 version. No need for the cassette input yet, although I'll leave a place in the code to add it in later.
Having fixed the shift-key code, and made the keyboard polling routine into a proper subroutine with register save and restore, I quite rapidly fill the screen with text and have to reset. I can't keep going because there's no scrolling routine yet. But how hard can it be? This is a 6809, after all, with 16-bit index registers and a 16-bit accumulator. Ended up with VDU scrolling working after one duff version.
Went to the lecture at HP Labs about the Airbus A380. Got the keyboard and auto-repeat working. Messed up the shift-key code.
No progress today, due to an unprecedented amount of social life for a Tuesday evening.
First thing to do this evening is to write a reasonably accurate delay routine. I'll need delays for the keyboard polling, debouncing and auto-repeat code. Single keyboard poll, then timing loop with 100us delay on scope.
Initial RAM test. Keyboard self-test shows that at least I can read and write the keyboard port. Finally understood UK101's original keyboard poller. It's just three different delays, and a simple decision on which delay to use.
ROM checksum. Messing about with 6850 ACIA, but got initialisation code wrong. Finally able to send ASCII to ACIA at 300 baud, but still can't use the keyboard.
No progress.
Rudimentary code to send ASCII codes to the VDU as if it were a terminal. Simple cursor position and cursor motion code but no scrolling yet. No visible cursor, either. Simple Bash script to send hex files to the Stag PPZ EPROM programmer.
Initial version with very basic clear-screen followed by placing "Hello, World" message in VDU RAM, then hang. This works first time (once I get a working CPU clock) and proves that I've got the hardware wired up OK. It also proves that the EPROM programming is OK, and the 6809 assembler on the Linux machine is generating good code.
Return to the Computers page
Return to John Honniball's home page
Copyright © 2004-2021 by John Honniball. All rights reserved.