This page is to record my build of a simple 6809 board, "6809 Max", created by Michael Cvetanovski. I have some notes to add on the subject of building the board, but for now here are a few comments on the software, for which I'm creating a custom emulator. The board info is at: https://oldmicros.net/product/6809-max-pcb/ https://sites.google.com/site/gogleoops/mc6809-min-board The system once assembled consists of 64K of SRAM, a 6521 ACIA (at E0xx) and a 6850 PIO (at E1xx). There is no disk controller; file I/O will have to be done over the ACIA or PIO and probably will require some new software to be written. The ACIA is at E0xx with shadow copies repeating every 2 bytes. The ACIA input port status address used by SBUG is $e004; bit 2 is tested for data ready: $e004 ACIA control register / status register $e005 ACIA transmit register / receive register It's important to build this board using a 7.3728 MHz clock instead of a round 8MHz. This ACIA chip uses the system clock divided by 64 for serial comms, so 115200bd is compatible with other systems but 125000bd would not be! Unfortunately this ancient ACIA chip doesn't support the other more common baud rates that other serial chips do. So be sure to set your serial link on the other end to match the 6809 settings: 115200 Baud, 8 data bits, no parity, 2 stop bits Output RTS active low, Tx Interrupts disabled Rx Interrupts Disabled Note that the 6850 only has a 1-byte buffer, so although it is OK for receiving typing, it suffers if data is sent in blocks and the software is not ready to accept every character. Unfortunately some of the FTDI TTL<->USB adapters are prone to sending up to 3 more characters after being asked to stop sending. Read more about the problem at: https://hackaday.io/project/167418-ftdi-usb-cable-problems-with-6850-acia (There are some more notes on the ACIA at https://robin-6502-project.blogspot.com/2020/07/adding-serial-interface-mc6850-acia.html - not sure if they'll be helpful, yet. Likewise using the ACIA with a 6502 board: https://web.archive.org/web/20080603044448/http://chidesters.org/scott/meadow/Meadow_6502_SBC_User_Doc.html ) The 6850 PIO (two 8-bit data ports plus a couple of single bit control pins) is at $E1xx with shadow copies repeating every 4 bytes. The 6809 Max comes with a 64K image file that contains XBasic and S-BUG pre-loaded. S-BUG communicates with the user over the ACIA, but does not use the PIO at all. The PIO may be testable from the default image by writing a Basic program to access it directly although I have not yet done so myself. The 6809 Max PCB does have a place for a LED, but the LED is tied directly to power by default. It may be worth hooking a PIO output to the LED instead and using it as a status indicator when first bringing the board up. The emulator code being used here was extracted from "vecx", so includes support for the peripheral chips used by the Vectrex. This code is in the process of being removed, and support for the two 'new' I/O chips (6821 and 6850) is being added. Note that the I/O support emulation will be very basic - just enough to get SBUG and XBASIC to talk to the console - not enough to develop software for the system that does anything clever with those chips. For simplicity in testing (both the hardware and the emulator), the memory contents are loaded from 0000 upwards from the file "memory.bin". This file *should* be exactly 64K, however due to the actual chips in use being DS1245AB or DS1249AB SRAMs, which are 128KB or 256KB respectively, the memory.bin file *may* be 128K or 256K, in which case only the first 64K will be read. To ensure that what you emulate is the same as what you run in the hardware, make sure the A16 and A17 jumpers are both in the 'L' position. Users of the Willem GQ4x4 eprom writer may need to add this (as one line) to their devices.txt in order to support the DS1249AB: Name="DS1249AB",ID="XXXX",Class="BQ4015",Category="SRAM", MFG="Dallas",VCC="5.5V",PINVCC="ZIF32_PIN32",CodeSize="262144", Package="DIP32"; Note that files shorter than 64K _should_ fail because the initial entry point is determined by the reset vectors! (Though fortuitously if a memory.bin file *were* too short, the vectors would all be set to 0000 and so the program would actually start at 0000 as expected! At least in this emulator, where memory is initialised to 00 - this may not be the case in the hardware...) Input to the ACIA and output from the ACIA in the emulator will be to stdin & stdout and will be unbuffered single-character I/O with no echo from the operating system. (Echo will be done by the 6809 from xbasic or S-BUG) Using the emulator from linux *should* look exactly like using the real hardware from a linux terminal program such as 'tip'. Normal linux terminal settings are restored if the emulator is exited by pressing ^C from within S-BUG but *not* if the process is "kill"ed. Input to the PIA will come from an accompanying text file which will contain on each line a delta-time to wait in uSec since the last read or write from that device, and the data to be returned on the PIO pins. Output will be written to a similar file containing a timestamp of when the data was written followed by the data on the PIO output pins. This has not yet been implemented or even specified in detail. The emulator sleeps so that execution matches real time - sleeping is done once every 1/100 sec for microsecond durations. So the timing is not cycle exact on a per-cycle basis, but overall should match the real hardware. This may affect serial I/O buffering, so the emulator attempts to buffer serial I/O itself transparently to the 6809 code. This hack is not done for the parallel I/O. A disassembly of S-BUG has been made and can be compared to a similar but not identical copy of S-BUG found online. The disassembly and original .asm source can be found in the 'docs' subdirectory as sbug.disasm and sbug_src.txt respectively - the disassembly was made using my modified '6809dasm' which can be found at https://gtoal.com/SBTPROJECT/6809sbt/ Although not yet done, a modified copy of the original SBUG, modified to produce the same binary as supplied by Mike Cvet, will be in sbug.asm You have to contact Mike to get a copy of his software, from his download area at Google Docs. XBasic (TSC Extended Basic) is pre-loaded in the 64K image file. I have not located a source for this version of Basic although the 'docs' directory contains sources for a related version of basic by TSC. The 'future' directory contains disk images of XBASIC which seem to match some of the embedded strings, but disassembly of these files fails, leading me to think that perhaps they are 6800 code - or are in a loader format that is not just a simple memory image. I am not particularly bothered by not being able to recreate the entire memory image from source as I plan to write my own compiler and runtime environment anyway. ----------- Hardware build comments: The CPU is the 68B09, *not* the 68B09E - the chip in the photos is an EF68B09 and the fact that it had an 'E' in the name (by coincidence) and that the design used an external crystal confused me. Luckily I had bought the same EF68B09 as in the photo so it worked it OK for me - only because two wrongs did make a right in this case! There's a RTS' pin on the power connector. I think it's a typo for RST' - it's an external reset input and can be left unattached. The SRAM chip is oriented the opposite way from all the other chips - be careful when putting the chip in the ZIF, especially since those packages are not marked with a clear Pin 1. Refer to the photo of the assembled board. The full-can crystal package is also oriented strangely. Make a note of the pin 1 location from the square on the hole on the PCB before soldering a socket over it. Socket *everything*. Solder the single resistor and small caps first, then the resistor pack followed by the sockets and pin wafers. I skipped the LED and associated resistor as all it indicates is power applied to the board. Buying all the components and sockets can be extremely expensive if bought in multiple orders. Even if the part cost is slightly higher, get as many parts from a single reputable source as possible to cut down on shipping overheads. I was unable to find a wide 24-pin socket in a kit of assorted socket sizes, so I cut a narrow 24-pin socket down the middle, stacked a 28-pin on top of it to get the spacing correct, and soldered it in for the ACIA. Once in place I removed the stacked 28-pin. A 24-pin ZIF would have done at a pinch but it would have been tight up against the 6821. ZIFs won't fit on the board for the other chips. It's worth laying everything out on the PCB before soldering as a gross error check, preferably on a sheet of anti-static foam. The SRAM used can be either a 128K DS1245AB or a 256K DS1249AB. Only 64K is used, and accessing the other 64K banks requires manually setting the A16 and A17 jumpers. Set both to "L" initially. I suspect the DS1225AB (64Kx8) would work out of the box. There may be other 64K (or more) x 8 non-volatile SRAMs but you need to check the pinout and timing if you are considering using them. The PIO and ACIA parts should also be the faster 'B' parts to match the 2MHz-capable 68B09 CPU.