Showing posts with label retrocomputing. Show all posts
Showing posts with label retrocomputing. Show all posts

Wednesday, November 24, 2021

Retrocomputing Basic Implementations

Here is a summary of a number of Basic implementations that I have come across and worked with as part of my retrocomputing hobby. Many of these were ported by me or others to different platforms from the ones they were originally written for (for example, single board computers based on the 6502, 6809, Z80, and 68000 microprocessors). These are all found on my github  account.

Name Developer Platform Code size Comments
Enhanced Basic (68000) Lee Davison 68000 14K Full-featured Basic for 68K platform
Tiny Basic for the 68000 Gordon Brandly 68000 4K Derived from and similar to Palo Alto Tiny Basic.
Enhanced Basic (6502) Lee Davison 6502 11K Full-featured Basic for 6502 platform.
Microsoft Basic for 6502 Microsoft Apple 2, Commodore, KIM-1, OSI, and others 8K Basic used on several early 6502-based microcomputers.
Tiny Basic for 6502 Tom Pitman 6502 3K Originally published in Dr. Dobbs Journal.
Apple 1 Basic Steve Wozniak 6502 (Apple 1) 4K Basic for the Apple 1, later expanded into Apple 2 Integer Basic.
BBC Basic 2 for Acorn Atom/BBC Computer Roger Wilson (Acorn Computer) 6502-based Acorn Atom and BBC Computers 16K Basic for the Acorn Atom and BBC Computers.
Tiny Basic for 6800 Tom Pitman 6800 2K My version runs on the Heathkit ETA-3400.
Tiny Basic for 6809 Tom Pitman 6809 2K 6809 port of 6800 version.
TSC Micro BASIC PLUS Technical Systems Consultants 6809 4K Similar to Tiny Basic.
Sinclair ZX81 Basic John Grant and Steve Vickers, Nine Tiles Networks and Sinclair Research Sinclair ZX80/ZX81, Timex 1000 8K Basic for the Sinclair ZX81 computer.

A List of Cross-Assemblers for Retrocomputing

 In my retrocomputing projects with various processors I have used a number of cross-assemblers to build code. I've had to use several in order to support different processors as well as for compatibility with different software packages. For the most part they are similar, but have their own unique features and quirks.

I put this table together, mostly for my own reference, that others may also find useful. It is by no means a complete list -- just those that I have used.

Name Author Source Supported Processors Key Features Comments
as9 Motorola, with changes by Albert van der Horst and others https://home.hccnet.nl/a.w.m.van.der.horst/m6809.html 6809 macros 100% compatible with Motorola assembler
asl Alfred Arnold and others http://john.ccac.rwth-aachen.de:8000/as/ many (over 50) Macros I have used with several processors
asm6809 Ciaran Anscomb https://www.6809.org.uk/asm6809/ 6809, 6309 macros Good choice if 6309 support needed.
cc65 John R. Dunning, Ullrich von Bassewitz, and others https://www.cc65.org/ 6502, 65C02 C compiler, assembler, linker, librarian Supports several 8-bit computer platforms.
crasm Leon Bottou https://github.com/colinbourassa/crasm 6800, 6801, 6803, 6502, 65C02, Z80 macros Included in most Linux distributions.
gcc Richard Stallman and others https://gcc.gnu.org/git/ Many Compilers and assemblers I used for 68000. Included in most Linux distributions.
lwasm William Astle and others http://lwtools.projects.l-w.ca/ 6809, 6309 Cross-assembler and linker. macros
vasmm68k_mot Volker Barthelmann http://sun.hasenbraten.de/vasm/ Many Cross-assembler I used for 68000.
z80asm Bas Wijnen http://savannah.nongnu.org/projects/z80asm Z80 Z80 cross-assembler Included in most Linux distributions.

Tuesday, November 19, 2019

A 68000 Disassembler


I have found that a good way to really understand a microprocessor's instruction set is to write a disassembler for it. I have done this for a number of processors including the 6502, 6800, 6809, and Z80. My udis disassembler was implemented on Python and supports a number of processors.

Having recently worked on my 68000 single-board computer, I decided to write a disassembler for the Motorola 68000. This is more challenging than for 8-bit processors due to it's complex instruction set and many addressing modes. I decided to again use Python as it is fast to develop, readable, and cross-platform.

I wanted the design to be at least partially table based. I started with the table on the Motorola MC68000 Programmers Reference Card, but it did not adapt will to a software-based table. I found a very nice and succinct table  written by someone in France under the name of GoldenCrystal that was a better fit. It organized all of the 68000 instructions and decoding of fields in a logical manner. I made a spreadsheet based on the table data.

The 68000 uses 16-bit opcodes, but they are not unique. Various bits in the opcode control the addressing modes and operands, so I needed to use an approach where each instruction has a bit pattern and a mask indicating which bits to examine when looking for a match to a specific opcode. For example, a NOP is $4E71 and all bits are valid but a MOVE instruction has thw two most significant bits as zeroes but the rest vary with the address mode.

I exported the spreadsheet into CSV format, which can easily be read into a data structure from Python. I then use this data for determining what instruction is read. Then I handle the encoding of the instruction and any extension words or operands. Many instructions follow similar encoding and can use the same logic, while others are unique.

It was somewhat tedious and time consuming to work my way through all of the possible instructions. As I proceeded, I wrote a test program with the instructions I was implementing and examples of each addressing mode. An additional good "stress test" of the code is to use random data (such as /dev/urandom on Linux) as input and make sure that it does not crash or produce errors.

After few weeks of occasional evenings (interrupted by a trip to Europe) I had finished support for all instructions. The most complex was the MOVE instruction as it supports almost every addressing mode for both source and destination operands. The final program is just over 1000 lines of Python code including comments and blank lines.

Here is some sample output:

00000000  4E 71                          NOP
00000004  A2 34                          UNIMPLEMENTED
00000006  4A FC                          ILLEGAL
00000008  4E 70                          RESET
00000012  4E 40                          TRAP      #$00
0000001A  00 7C AA 55                    ORI       #$AA55,SR
0000002A  02 7C AA 55                    ANDI      #$AA55,SR
00000032  60 5E                          BRA       $00000092
000000BA  48 C2                          EXT.l     D2
000000BE  4E 69                          MOVE      USP,A1
000000DE  57 CF 00 22                    DBEQ      D7,$00000102
00000112  72 01                          MOVEQ     #$01,D1
00000146  EF 82                          ASL.l     #7,D2
000006E4  08 78 00 08 12 34              BCHG      #$08,$1234
00000C9E  4C FB 55 AA 90 12              MOVEM.l   $12(PC,A1),D1/D3/D5/D7/A0/A2/A4/A6
00000CF4  2C 6D 12 34                    MOVEA.l   $1234(A5),A6
00000D3A  18 3A 12 34                    MOVE.b    $1234(PC),D4
00000F24  55 91                          SUBQ.l    #2,(A1)
00001334  DF B8 12 34                    ADD.l     D7,$1234

With the -n or --nolist option, it only disassembles the instructions. This could be used to feed the output back into an assembler, if you were reverse engineering some code for example. Here is some sample output in this mode:

 NOP
 UNIMPLEMENTED
 ILLEGAL
 RESET
 TRAP      #$00
 ORI       #$AA55,SR
 ANDI      #$AA55,SR
 BRA       $00000092
 EXT.l     D2
 MOVE      USP,A1
 DBEQ      D7,$00000102
 MOVEQ     #$01,D1
 ASL.l     #7,D2
 BCHG      #$08,$1234
 MOVEM.l   $12(PC,A1),D1/D3/D5/D7/A0/A2/A4/A6
 MOVEA.l   $1234(A5),A6
 MOVE.b    $1234(PC),D4
 SUBQ.l    #2,(A1)
 ADD.l     D7,$1234

The source code and test program can be found here.

This process gave me an appreciation for the effort that the Motorola engineers must have gone through to implement the native 68000 dissasembler in the TUTOR firmware which was written in assembly language.

I can also appreciate that significant more work would be needed to extend this to support the 68020 or later processors which have more instructions and addressing modes.

While it was not meant to be a production program, it was fun to write and I now have a much better understanding of the 68000 instruction set and its complexity, quirks and limitations.

Saturday, April 13, 2019

A 6809 Single Board Computer: The MC6839 Floating Point ROM



Implementing floating point math was a challenge with 8-bit microprocessors. The early version of BASIC for the 6502-based Apple 1 and Apple 2 series written by Steve Wozniak only supported 16-bit integer variables in order to keep the size down and achieve acceptable performance. Later, Applesoft BASIC was licensed from Microsoft which supported floating point variables. A significant amount of the code for Microsoft BASIC for 8-bit microprocessors was dedicated to floating point math. Some versions, loaded from tape, gave the user the option to leave out the sin/cos/tan trig functions to save space and free up some memory.

The 6809 supports instructions for 8-bit addition, subtraction, and division and some 16-bit math instructions. While more powerful than earlier processors like the 6502 and 6800, implementing floating point math was still a significant undertaking. Motorola saw an opportunity to offer a floating point math library as a standard product for the 6809. This was made more viable for two reasons:

  • An IEEE standard for floating point math formats appeared to be poised to become an industry standard.
  • The 6809 allowed writing position independent code, so a floating point library could be offered in binary form that would be independent of the memory map of the system it needed to run on.

Out of this came a product: the MC6839 Floating Point ROM. While essentially a software product, it was sold as hardware: an 8K ROM programmed with the floating point code. As well as the ROM, it included a programming manual almost 100 pages in length, describing how to use it.

The basic features of the library were:

  • An 8KB ROM which would run at any contiguous range of addresses.
  • All RAM used was relative to the stack pointer.
  • A well documented API that allowed operands to be passed in registers or via the stack.
  • Fully implemented the IEEE Standard for floating point math (at the time, still in draft form).
  • Support for the following operations: add, subtract, multiply, divide, remainder, square root, integer part, absolute value, negate, condition code compares, conversion between integer and floating point, and conversion between binary floating point and BCD.
  • Supported three precisions (4, 8, and 10 bytes) defined by the IEEE standard.
  • Supported the rounding modes, closure modes, and normalize modes defined by the standard.
  • Supported handling of exceptions (e.g. division by zero).

According to the source code it was written around 1980, with revisions up to at least 1982. The author names in the source code were Greg Stevens, Joel Boney, and G. Walker. In 1988 the source code was put in the public domain by Motorola, and can be found on the Internet as well as the binary for the ROM.

I came across the code and decided to try it out on my 6809 single board computer. There is a programming example in the manual that finds the roots to quadratic equations of the form ax^2 + bx +c = 0 using the classic formula -b +/- sqrt(b^2 - 4ac) / 2a

I typed in the example and adapted it to the lwasm assembler. The program uses a standard set of macro instructions to set up the parameters in the correct calling sequences for the ROM. These macros make the code much more readable and were easily ported to the lwasm assembler. I needed to make a few changes in order to make the example a complete runnable program. When run, and with the S record file for the MC6839 ROM also loaded into memory, I was able to get the example to run and produce the correct results. The code is on my github account.

Since I had the source, I took a look at whether I could assemble it. It would take some effort because the original source required a special Motorola "structured assembler" that I have not been able t find any information about. It has a number of structured programming macros for things like looping and conditionals. Given some time this could be reversed engineering by looking at the binary file.

I also found that the source does not quite match the binary (the former has a 1980 copyright date and the latter 1982). Without having a known good binary that corresponds to the source code, porting would be a challenge, so I set any further work on this aside for now.

The MC6839 Floating Point ROM was Motorola's first foray into this type of binary ROM product. The data sheet lists the product as "preliminary" and according to one source it was never actually offered as a product.

Later processors, like the 68000 series, would support floating point math in hardware using either a separate dedicated chip or on-board floating point unit (FPU). These still use (as do modern computers, including your smart phone) the IEEE standard for floating point math.

References

  1. https://github.com/jefftranter/6809/tree/master/sbc/mc6839
  2. http://github.com/brouhaha/fp09
  3. http://www.colorcomputerarchive.com/updates/2017
  4. http://www.classiccmp.org/pipermail/cctalk/2017-March/033678.html
  5. http://www.classiccmp.org/pipermail/cctech/2016-June/019519.html
  6. http://www.colorcomputerarchive.com/coco/Documents/Manuals/Hardware/MC6839%20Floating-point%20ROM%20Manual.pdf

Tuesday, February 5, 2019

A 6809 Single Board Computer: Disassembler and Thoughts on the 6809


As a project to use my 6809 SBC and learn more about 6809 assembly language programming, I wrote a disassembler that can run on the board. The design was loosely based on the one I did for the 6502.

While straightforward in principle, a disassembler for the 6809 is a little more challenging that for the 6502 for a number of reasons:
  • It supports many instructions.
  • Some instructions have unique operand formats (e.g. TFR/EXG, PSH/PULS).
  • There are many (24) different indexed addressing modes.
  • The instruction length can change based on the indexed addressing mode being used.
  • Some instructions are two bytes long, prefixed by $10 or $11 (the so-called page 2 and page 3 op codes).
Implementation was pretty straightforward. I used lookup tables for a number of things including op codes, instruction types, addressing modes, and mnemonics. I strove to make the code readable and avoided any tricks that might increase efficiency slightly at the expense of clarity.

It is mostly portable. It uses ASSIST09 monitor routines for i/o, but other than that could be used on other systems with minor changes.

I implemented over a few evenings, building it up in pieces. It took some time (but less than I expected) to handle all the index addressing modes and to correctly handle the differing instruction lengths and page 2/3 instructions.

My basic approaches for testing and debug were:
  1. Test low level functions, like PrintString, on their own with some test code.
  2. "Desk check" complex code on paper to try to verify the logic, use of registers, etc.
  3. Build it up in stages and confirm them working before adding on (e.g. initially just display hex bytes)
When I ran into bugs I used the "desk check" method as well as making use of breakpoints when running the code to see what it was doing at various steps. Having a working monitor to run, display and change memory and registers, etc. was a requirement and ASSIST09 worked well for that. Downloading new versions of code over the serial port only took a few seconds.

I initially ran it standalone, but at the end I was able to also support installing it as an external command in the ASSSIST09 monitor, so you can run it by typing U (for unassemble). ASSIST09 has calls to add new commands, so it can be done without changing the code in ROM.

Here is some sample output (disassembling the start of the ASSIST09 ROM code):

>U F800
F800  30 8D 68 BE  LEAX  $68BE ,PCR
F804  1F 10        TFR   X,D
F806  1F 8B        TFR   A,DP
F808  97 9D        STA   $9D 
F80A  33 84        LEAU  ,X
F80C  31 8C 35     LEAY  $35 ,PCR
F80F  EF 81        STU   ,X++
F811  C6 16        LDB   #$16 
F813  34 04        PSHS  B
F815  1F 20        TFR   Y,D
F817  E3 A1        ADDD  ,Y++
F819  ED 81        STD   ,X++
F81B  6A E4        DEC   ,S
F81D  26 F6        BNE   $F815 
F81F  C6 0D        LDB   #$0D 
F821  A6 A0        LDA   ,Y+
F823  A7 80        STA   ,X+
F825  5A           DECB
F826  26 F9        BNE   $F821 
F828  31 8D F7 D4  LEAY  $F7D4 ,PCR
F82C  8E 20 FE     LDX   #$20FE 
F82F  AC A1        CMPX  ,Y++
F831  26 02        BNE   $F835 
F833  AD A4        JSR   ,Y
PRESS SPACE TO CONTINUE, Q TO QUIT 

With a little more 6809 assembly language programming experience under my belt, it is interesting to compare it to the other 8-bit processor I am most familiar with, the 6502. Let me list a few thoughts here.

Having two accumulators is very handy. Often one is being used as an accumulator for some form of data, but another may be needed for indexing or as a parameter to calling another routine. Surprisingly, I also found myself using the 16-bit D register (which uses A and B) because I needed 16-bit data. Some functions, like addition and subtraction, are supported on the D register, but many only have 8-bit versions which you need to combine using several instructions to work on 16 bits of data.

Two index registers is also handy (the 6502 has two, but the 6809's predecessor the 6800 only had one). But I found in practice that I rarely needed a second one. Having 16-bit index registers, unlike the 8-bit registers of the 6502, was much more convenient as you often find you are using them to store addresses.

The 6502 typically makes the programmer heavily use addresses in the first 256 bytes of memory (page 0). Some key instructions and addressing modes can only work with page zero. For that reason, these tend to become valuable real estate and you can run out of them or run into collisions between different uses of them. In contrast, the 6809 has a more orthogonal instruction set and all relevant instructions can work with full 16-bit addresses. It does have direct mode (8-bit addresses) but with the Direct Page register you can have them work with any page of memory, not just page zero. I did not use this feature (the ASSIST09 monitor does) but I can see it being useful when you wanted to optimize the size of your code.

In general the 6809 is more orthogonal than the 6502, with few limitations on the addressing modes or operands of instructions. Unlike the 6502 you can push, pull, transfer, or exchange any registers. The push and pull (PSHS/PSHU/PULS/PULU) instructions are particularly nice in that you can push or pull a set of registers in one instruction. The order of push and pull is defined, so that you do not have to ensure that the order is correct in your code (provided you push and pull the same list of registers). There are two stack pointers, but I only used one. And of course, the 16-bit stack pointer is much more reasonable than the 8-bit stack on the 6502 that is fixed in page 1 of memory.

Transfer (TFR) and Exchange (EXG) are two other instructions which are very handy for moving registers around without any restrictions. The 6502 had some limitations on what registers you could transfer and had no equivalent to EXG.

The 6809 introduced a MULtiply instruction, which sounded at the time like a luxury for assembly language programmers. I actually used it in an early version of my disassembler program when I needed to multiply the offset to a table by 4 and get a 16-bit result. I felt it was overkill using a multiply to do this, and later did it using two shifts (you can easily implement a 16-bit shift of the D register using two instructions: ASLB, ROLA).

The 6809 has many more addressing modes than the 6502, with 24 variations of indexed addressing. I think it is unlikely that assembly language programmers would use the majority of these as just a few of them generally suffice. I suspect the original intention may have been to help support compilers of high-level languages that could use these.

One quirk with indexed addressing that could confuse programmers is that the 5, 8, and 16 b-t offset modes consider the offset to be signed. So, for example, the 5 bit offsets are not 0 to 31 but rather -16 to 15. If you have a lookup table of 256 elements, for example, and expect the 8-bit offset indexed addressing mode to access all of them starting from an offset of zero, you will be surprised when values of $80 and higher don't read the table entries you expected. I ran into this, and solved it by using 16-bit offset in this case.

One instruction that you could easily overlook is LEA (Load Effective Address). It might not seem particularly useful, essentially removing one level of indirection. In fact it is very useful, and is the key to a lot of efficient programming as it can make use of all of the indexed addressing modes and make code position independent.

The 6809 supports position independent code (PIC). The ASSIST09 monitor, for example, is fully position independent. It is not particularly hard to write PIC code, and I made some effort to try this in the disassembler. Mostly it is a matter of using branches rather than jumps and using the PCR (program counter relative) addressing mode when working with addresses. I did leave the memory locations in RAM used by the program at fixed addresses. One annoyance is that as code gets larger during development 8-bit branches often fail and need to be converted to long branches. Unlike some assemblers, the one I was using did not automatically select short or long branches as needed.

Overall, the 6809 is quite a pleasant processor to program, with more instructions, more and larger registers than the 6502. Of course, it is not really a fair comparison as it came a generation later and could make use of advanced in technology that allowed a more complex chip. The 6800 was of the same vintage as the 6502. In fact, the decision to use the 6502 over the 6800 in a number of early computers was based on cost. Compared to the $300 price tag of the 6800, the 6502 sold for $25. The Apple 1 was originally designed to use a 6800, but was converted to the 6502 when Steve Wozniak learned about it. The schematic diagram for the Apple 1 still listed the circuit changes needed on the board to use a 6800.

Sunday, January 27, 2019

A 6809 Single Board Computer


As well as the 6502, 6800, and 68000 chips, another CPU I used early in my career was the Motorola 6809, the more powerful successor to the 6800. Having completed some retrocomputing projects with the other chips, I start looking for a project where I could play with this CPU for nostalgia purposes.

I soon came across a Single Board Computer design by Grant Searle. A five or six chip design, it has serial i/o and can run a version of Microsoft BASIC that he adapted from the version in the Radio Shack Color Computer.

The basic specs are a 6809 processor running at just under 2 MHz, 32K of static RAM, 16K of EPROM, and a 6850 ACIA-based serial port.

The design is simple, potentially buildable on a breadboard, and had been reproduced by other people, so I decided to give it a try.

I entered my own schematic using the EasyEDA web-based CAD software. This would make it easier to make design changes and potentially a printed circuit board (PCB).

I made a few small changes in my version of the board:

  • Used a 6-pin connector for a standard FTDI USB to serial breakout board and omitted any RS-232 line driver/receiver circuitry. I also omitted the optional hardware handshaking circuit.
  • Added a simple power on reset circuit to the pushbutton reset.
  • Added a power on LED.
  • Provided a jumper to select USB or external power source.
  • Added a 32-pin header with access to most signals, for future expansion and to help with debug.

The system can plug into a computer's USB port where it shows up as a serial port. It is powered by USB (taking about 230 mA of current) and you communicate with it using a terminal emulator.

The provided BASIC is a port of Microsoft Extended BASIC for the 6809-based Radio Shack Color Computer. A disassembly of it was published in two books. In Grant Searle's port, all code and commands that were not applicable (e.g. graphics, sound, cassette tape i/o) were removed. It is just under 10KB in size. Pretty typical of Microsoft BASIC of the era, it has a few quirks, e.g. available memory i available from the variable MEM rather than a function FRE(). Extended Color Computer BASIC has some additional commands that are useful like RENUMber, additional math functions, PRINT USING, TRON/TROFF and even EDIT to support editing program lines. Apparently this was the last version of Microsoft BASIC that Bill Gates personally worked on. You can find online copies of books on the Colour Computer and its version of BASIC.

I took the BASIC firmware and got it to build under Linux using the as09 cross-assembler with no warnings. I found and fixed a small typo that might have affected the PRINT USING command.

I breadboarded the CPU, clock, and reset circuit on a solderless breadboard. Then I got the 6809 to free run by forcing all the data lines all low. I decided not to breadboard the entire circuit as it would be quite tedious to do so, wouldn't fit on my small breadboard, and the design looked stable and had been verified by others, so I opted to move directly to a PCB layout.

I made a PCB layout from EasyEDA (using the autorouter). Once it looked good, I ordered some PCBs from JLPCB, a partner of EasyEDA which offers PCBS for as little as $2 per board.

There are high quality double-sided boards with plated-through holes, silkscreened, solder masked and even electrically tested. They are built in about one day and arrive in about 5 business days. With the availability of suppliers like this, it really doesn't make sense to etch your own boards at home.


I had found and orders the remaining parts I needed on Ebay. Some, like the Motorola 68B50 and 68B09, are readily available as new old stock (NOS).


I programmed the firmware onto a 27C128 EPROM using my UV eraser and programmer.


Once the boards arrived, I build one up, starting with the power, then clock and reset circuits. Everything checked out and before long BASIC was up and running!

I read some books on Color Computer BASIC to review the commands, played with the commands and tested some old programs. Here is an example, a little horoscope program I wrote in BASIC some time again, which ran with some minor changes:

           YOUR HOROSCOPE
           --------------

THE PROGRAM GENERATES A PERSONAL
HOROSCOPE. I NEED SOME INFORMATION
ABOUT YOUR DATE AND LOCATION OF BIRTH.
I WILL THEN GENERATE AN ANALYSIS BASED
ON YOUR ASTROLOGICAL DATA.

WHAT IS YOUR FIRST NAME? Fred
YOUR YEAR OF BIRTH (E.G. 1980)? 1980
YOUR MONTH OF BIRTH (1=JAN)? 6
DAY OF THE MONTH (1-31)? 21
COUNTRY OF BIRTH? Canada
IN WHAT CITY? Ottawa
CALCULATING HOROSCOPE...PLEASE WAIT.

Fred, YOUR ASTROLOGICAL SIGN IS:
CANCER.

HERE IS MY ANALYSIS:

AT TIMES YOU ARE EXTROVERTED, AFFABLE,
SOCIABLE, WHILE AT OTHER TIMES YOU ARE
INTROVERTED, WARY, RESERVED.

YOU WORRY ABOUT YOUR HEALTH AS YOU GET
OLDER.

YOU ARE CONCERNED ABOUT THE HEALTH OF
AN AGING RELATIVE.

GENERATE ANOTHER HOROSCOPE (Y/N)? 

Looking for machine language monitors, I found source code for the ASSIST09 program that Motorola offers for their 6809-based development ports. I got it to cross-assemble under Linux, and modified it to work with the 6850 ACIA instead of what the Motorola hardware used. With a little debugging, I got it running. It works well, and provides most feature you want for development and debug, including memory display and change, register display and change, running and breakpoints, and generating and loading Motorola S record files. here is a sample session:

ASSIST09
>D 1000 20

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
1000 45 41 4C 49 53 54 49 43 2E 22 20 3A 20 90 00 10  EALISTIC." : ...
1010 56 2F 26 87 20 22 54 48 45 20 42 49 52 54 48 44  V/&. "THE BIRTHD
>R
PC-F842 A-00 B-00 X-20FE Y-F002 U-60C2 S-6051 CC-F4 DP-00 
PC-
>M 1000
45-55
>P 1000 100F
S13100055414C49535449432E22203A2090001014
S9030000FC
>

I am able to cross-assemble code on a Linux computer and then load the S record file onto the board via the serial port. This is much more efficient than erasing and burning EPROMs.


Note that for uploading you need to add delays due to no hardware handshaking. I use the ascii-xfr program on Linux to do this, as well as the minicom terminal emulator.

I wrote a couple of example programs that run with the ASSIST09 monitor, using it's SWI functions for i/o.

Next, I combined BASIC and ASSIST09 into one EPPROM. It comes up in ASSIST09 but you can get to BASIC using the "G D000" command. This offers the ability to play with BASIC or machine language without swapping EPROMs.

ASSIST09
>G D000
6809 EXTENDED BASIC
(C) 1982 BY MICROSOFT

OK
10 FOR I = 1 TO 10
20 PRINT I,
30 NEXT I
RUN
 1               2               3               4               5
 6               7               8               9               10
OK

I have built up a second board and am just waiting to receive a second 68B09 chip to complete it. I have a few programming projects in mind to work on, and some code (like a small C compiler) that I want to look at.

If you want to give this a design a try, I encourage you to do so. Feel free to use my PCB design files if you wish, or just breadboard it up.

References


  1. Grant's 6-chip 6809 Computer: http://searle.hostei.com/grant/6809/Simple6809.html
  2. My git code with firmware and other software: https://github.com/jefftranter/6809/tree/master/sbc
  3. EasyEDA project: https://easyeda.com/tranter/6809-Single-Board-Computer
  4. AS9 assembler: http://home.hccnet.nl/a.w.m.van.der.horst/m6809.html

Monday, March 16, 2015

Superboard /// Enclosure

The original Superboard II was sold as a populated circuit board with no case or power supply. I owned one, and made a case out of wood and some plastic that I had handy that worked as a cover. The Challenger 1P was essentially a Superboard II in a metal case.

Case for the OSI Challenger 1P

For my Superboard ///, I wanted something better than just the board. A sheet metal case could be made, given suitable tools like a bending brake, but I don't have one.

As a simple solution, I made a plastic cover to protect the non-keyboard area of the board from dust and dropping things on it that might damage or short circuit it.



I cut a piece of 3 mm Lexan to 11 by 3-15/16 inches, and mounted it with 3/4 inch nylon standoffs using the holes in the circuit board.



I was fortunate to find suitable Lexan in an 11 x 14 inch sheet so I only had to make one cut. Less expensive Plexiglas could be used too, though not be quite as durable.

Inexpensive sets of nylon standoffs and screws of various sizes are offered by sellers on eBay. I got mine from one of these sources.



Earlier I had attached some adhesive rubber feet to the bottom of the board so it is stable on a table or bench.

While not as nice as a full case, this is at least an improvement over just the circuit board.

Sunday, February 1, 2015

Superboard /// Theory of Operation

Here are some notes on design and theory of operation of the Superboard ///. This was gleaned from looking at the circuit and I may have got some details wrong. Refer to the schematic diagram that is included on the CD.

All parts on the board are through-hole, making it easy to assemble. All ICs are socketed, and the board is silk-screened with component designations and values. Vince Briel says that the blue solder mask used is a tribute to the blue color scheme that Ohio Scientific used in their line of computers. About half of the board is taken up by the 53 keyboard keys.


Power comes in as +5V via the USB port through the USB to serial FTDI board. Vince Briel recommends a 1000 mA or more USB power supply but the USB 2 standard calls for 500 mA from a host (computer) and the board typically takes about 115 mA, in my measurements. Note that the power switch comes after the USB to serial board, so the serial board is always on and takes some power. The power LED is after the power switch.

The original Superboard took a lot more power and was specified as needing a 5 volt 3 amp power supply. Power consumption depended a lot on the amount of RAM, e.g. whether 4K or 8K was installed. I remember on mine that a lot of the chips on the board ran quite hot, especially the 2114 RAM chips. On the Superboard ///, the only chip that gets warm at all is the 6850, which is the only non-CMOS chip on the board.

An LM3940 voltage regulator IC converts the 5V from the USB port to 3.3V. All circuitry runs on 3.3V except for the 6850 ACIA.

The USB to serial board is a low cost off the shelf FTDI board. These can be ordered from various suppliers from China and the SKU on the package matched one from http://www.banggood.com. There are some units on the market which have fake FTDI chips; this seems to be a legitimate one. It also just happens to have a blue solder mask that nicely matches the main board. It looks like Vince replaced the original right angle header on the board with a straight one, as it appears to have been hand soldered.



The DTR line of the USB to serial board goes via a cap to a transistor switch to the RESET line of the Propeller switch. This allows the Propeller to be reset from the serial port as part of the protocol for in-circuit programming. Arduino boards use a similar scheme. On Linux systems you may find that when you open the serial port it toggles DTR and resets the system, which is annoying. You can disable this using this command:

  stty -F /dev/ttyUSB0 -hup -clocal raw

The Parallax Propeller chip is an interesting device that contains eight 32-bit processors which can run independently and communicate via shared memory. It has hardware on-board to assist with generating video signals in software. a serial port, and can load a program from an external serial ROM on powerup.

The Propeller CPU does some of the emulation, most notably generation of composite video in one of two video modes, and emulation of the ROM and video RAM for the 6502. It runs at 5 MHz. On reset it loads its firmware from the serial EEPROM, a 24LC256 32Kx8 serial EEPROM. This is a standard feature of the Propeller. With the Propeller development tools (which are free) you can reprogram either the Propeller or the EEPROM via the serial port from a host computer. All of the source files for the firmware are included on the Superboard /// CD.

Vince Briel, with help from Jac Goudsmit, wrote the firmware for the Propeller chip which is included on the CD. They had to use some creativity to implement the emulation in real-time and within the available pin contraints on the Propeller CPU chip. I have not looked closely at the code. It is written in the BASIC-like SPIN programming language as well as some assembly language.

The video by default is monochrome with 25 lines by 25 characters. If you hold down the BREAK key on powerup, it uses a 32x32 video mode that some models of OSI computers also supported. However, BASIC always only uses 24x24 characters for display. The Superboard /// supports the same character set font as the Superboard II, offering 255 characters including a number that could be used for games and graphics.

The BREAK key on the key board goes to an input of the Propeller so simulate reset operation. The software requires holding it down for 3 seconds to avoid accidentally hitting it. Contrary to what the manual says, on reset you do not lose any program in memory. A BASIC warm start ("W" from the boot menu) will preserve any BASIC program in memory. The random screen on powerup is simulated in software to act like the original Superboard (interestingly, the one I owned had a powerup reset circuit and did not do this, it also had a 3 second delay on the BREAK key). At the upper left of the "random screen" is the firmware version number (currently 0.06).

The serial port transmit and receive lines go to the Propeller chip. Another Propeller i/o pin directly generates the composite video output (in software). Other Propeller i/o pins control some of the address lines and the data lines for the 6502, as well as some control signals such as R/W, RESET, and CLOCK. The 1 MHz clock for the 6502 is completely generated by the Propeller in software.

The 6502 is a Western Design Center 65C02. It is clocked at 1 MHz for compatibility with the Superboard II but can run at higher speeds (mine is a 14 MHz part). It runs at 3.3V. Between the Propeller chip, glue logic, RAM, etc. it runs in a standard fashion even though some hardware like the ROM is emulated by the Propeller. Incidentally, the 65C02 has some additional instructions over the original 6502 that can be quite useful. It is backwards compatible, with the new instructions using what were invalid/unused opcode on the original 6502. It is also much lower power than the original 6502.

The RAM uses a real RAM chip rather than being emulated. It is an AS6C1008, which is a 128K x 8 chip but only 32K is used as this was the maximum that the Superboard II supported.

The 6850 ACIA provides the serial interface. This is the same chip that was used on the original Superboard II, ensuring software compatibility. It is made by Motorola and was the standard UART at the time for the 6800 series of CPUs. It is interesting that Ohio Scientific did not use the more powerful 6551 ACIA that was made by Motorola for the 6502 series (it may not have been available at the time, or possibly it was more expensive). The 6850 is the only chip that runs on +5V, and is no longer manufactured, so new old stock chips have to be obtained. Mine has a date code of 8507 (the seventh week of 1985). It runs at 9600 baud, unlike the 300 baud of the original Superboard. On the Superboard II is was usually used for the cassette tape interface. Since the baud clock is being generated by the Propeller chip, you could change it in the Propeller firmware, although there is no hardware handshaking and the 6502 when running BASIC cannot keep up to 9600 bps and needs delays added to avoid data loss.

The keyboard circuit is similar to the original Superboard II. The key switches are arranged in rows and columns. A register can select one of 8 rows of keys and drive it low. The register is then read back to detect which, if any, keys in each column of that row are pressed. The software scans each row in turn to detect key presses. This is a simple design but has some side effects, most notably that there is no latching or typeahead of keys pressed, you can only tell if a key is pressed at the time it is scanned. It does mean that you can detect if multiple keys are pressed simultaneously, and independently detect the left and right shift keys. The BREAK key is not part of the keyboard scanning circuit.



 SHIFT LOCK is a latching key and is typically on to enable uppercase characters only as BASIC did not recognize lowercase characters in keywords or commands. The keyboard circuit uses a few discrete TTL chips for the read and write registers and for address decoding. The keyboard row and column signals are also brought out to a 16-pin DIP connector (not included) on the board so that you could connect an external keyboard, if desired. The original Superboard II did not have this connector.

The keys are high quality units made by Cherry, and the key caps are custom and made by WASD Keyboards. The latching SHIFT LOCK key is no longer manufactured, so when the supply runs out Vince will have to ship small slide switches instead (there is a place on the board to install one).

More address decoding is done by a 7HC138 decoder, and some of the signals go back to the Propeller CPU to help it identify when certain blocks of addresses are selected so that ROM and video memory can be emulated. This reduces the number of signals that need to go to the Propeller CPU.

A 40-pin expansion connector brings most of the important signals out so that in theory peripherals devices could be added. It is similar to the expansion connector on the original Superboard II, but uses a different connector since it is not electrically compatible with the Superboard II, using 3.3V rather than 5V levels. It would be an interesting project to interface the Superboard /// with one of the original Ohio Scientific floppy disk controllers so that it could run the disk operating system.

The original Superboard II has a cassette tape interface that ran at 300 baud and followed the Kansas City Standard for storing data on audio tapes. This circuitry is not included on the Superboard ///, as the higher speed serial port is a more convenient way to transfer files. There is a 10-pin connector that brings out the relevant signals so you could implement a tape interface if you desired.

That's pretty much it. There's not a lot of circuitry on the board, especially compared to the original Superboard II, which has to do things like generating the video using discrete logic, and used more than 70 ICs. You could even simplify the design by replacing the 6 TTL chips with a PAL, for example, but that would take away some of the retro design.



By the way, the name Superboard ///, is clearly derived from wanting to be the logical successor of the Superboard II, and calling it /// is a nod to the (infamous) Apple /// computer which was the successor to the Apple II.

Saturday, January 31, 2015

Superboard /// Port of JMON

JMON is a machine language monitor program I wrote for the Briel Replica 1, a replica of the Apple 1. It was only natural to want to port it to run on my new Superboard ///. Given that both computers use a 6502 microprocessor, and JMON has minimal hardware dependencies, it was not hard to do. In one evening I had it all working on the Superboard ///.

After determining the addresses of suitable keyboard input and screen output routines, I very quickly got it up and running. Most of the work to fully port it was to adapt the output to the smaller screen width (24 characters) of the Superboard. I also had to disable some features that did not apply. It is now fully working and is quite useful, particularly as the built-in OSI machine language monitor is very primitive.

Years ago, when I had an original Superboard II, I wrote some machine language programs by hand assembling them and entering the hex codes into the monitor. I very quickly wrote a disassembler in BASIC in order to help verify and debug my programs.

JMON is cross-compiled on a desktop computer, and both the Apple Replica 1 and Superboard /// versions build from the same source code using ifdefs for conditional code.

Below are some representative screens showing some of the commands.

Initial Screen
Help command
Disassemble command
Memory Dump command
Info command
Changing registers and single stepping
Memory test

The Superboard ///

My latest retrocomputing project is building the Superboard /// computer kit by Briel Computers.

It is a replica of the Ohio Scientific Superboard II. The original SuperBoard II was one of the first affordable computers that featured a full keyboard, video output, BASIC in ROM.


At a price of $279 in 1979, it was an amazing bargain at the time when compared to systems like the Apple II that retailed for about $1300. For that you got an assembled board but needed to add a 5 volt power supply, monitor or TV set and RF modulator, and cassette tape for storage.

I owned one that I purchased in 1979 and it was my first computer. With it, I learned BASIC and 6502 machine language programming.

The SuperBoard /// is Vince Briel's replica of the original SuperBoard. It features a 6502 processor, but simplifies the design by replacing a lot of logic chips with a Propeller CPU. It is software compatible with the original system.

It is sold assembled or as a kit. I opted for the kit.



To date I've made three YoutYube videos on the kit, covering unboxing, assembly, and basic operation. They can be found on my YouTube channel.

I also have some files on my github account including a handy Quick reference, the OSI firmware including BASIC, and a port of my JMON monitor program. The Visual Monitor program that I entered a few months ago also works.

Below are some useful web links.

My Stuff:



Ohio Scientific:

http://en.wikipedia.org/wiki/Ohio_Scientific
http://classiccmp.org/dunfield/osi/index.htm
http://home.cmaaccess.com/~jerrytravis/
http://oldcomputers.net/osi-600.html
http://osi.marks-lab.com/
http://osiweb.org/osiweb/software.html
http://superboard.com.sapo.pt/
http://uk101.sourceforge.net/
http://www.6502.org/
http://www.6502.org/users/sjgray/computer/osi-c4p/
http://www.binarydinosaurs.co.uk/Museum/ohio/index.php
http://www.classic-computers.org.nz/collection/challenger1.htm
http://www.compukit.org/Compukit.org
http://www.cse.dmu.ac.uk/~mward/martin/software/index.html#UK101
http://www.gifford.co.uk/~coredump/uk101.htm
http://www.historyofpersonalcomputing.com/osi-superboard-i-and-ii/
http://www.lysator.liu.se/adventure/machines/OSI.html
http://www.neoncluster.com/projects-osi/osi-cassettes.html
http://www.old-computers.com/museum/computer.asp?c=572&st=1
http://www.old-computers.com/museum/computer.asp?c=860&st=1
http://www.oldcomputermuseum.com/superboard_2.html
http://www.osiweb.org/
http://www.pagetable.com/?p=43
http://www.pagetable.com/?p=46
http://www.pc-history.org/ohio.htm
http://www.technology.niagarac.on.ca/people/mcsele/OhioScientific.html
http://dabeaz.blogspot.co.uk/2010/08/using-python-to-encode-cassette.html
http://searle.hostei.com/grant/uk101/uk101.html
http://www.slideshare.net/dabeaz/using-python3-to-build-a-cloud-computing-service-for-my-superboard-ii
https://www.youtube.com/watch?v=pB2t6xG2RzE

Superboard ///:

http://forum.6502.org/viewtopic.php?f=8&t=2487
http://www.brielcomputers.com/phpBB3/viewtopic.php?f=39&t=1627
http://www.brielcomputers.com/wordpress/?cat=39
http://www.brielcomputers.com/wordpress/?cat=41
http://www.retrothing.com/2014/06/superboard-iii-briel-recreates-another-1970s-microcomputer.html

Thursday, August 21, 2014

Ohio Scientific Superboard II

The first computer I owned was an Ohio Scientific Superboard II. Bought in 1980, it was the only reasonably complete computer on the market for under $300.

I learned a lot on that machine, including BASIC and 6502 machine and assembly language programming.

Alas, it was damaged in a flood a number of years ago and had to be thrown out. I recently found this original paperwork which came with the machine:





I am, however, eagerly waiting the Superboard III.  a replica of the Superboard II that is being offered by Briel Computers. It should be fun to see the Superboard powered up again, running BASIC and the really primitive machine language monitor. I might even have some software I wrote on old cassette tapes that can still be recovered.

I'll report back here as the project progresses.

Monday, June 2, 2014

New Retro Computer Kit

Dubbed a Software Defined Computer, the Propeddle  is a new forthcoming computer kit that has a 65C02 processor as well as a Propeller CPU, and is planned to be able to emulate various 6502-based computers by changing the software. The prototype is already able to emulate an Apple 1.

The name Propeddle comes from the Propeller CPU used on the board, and Chuck Peddle, one of the designers of the 6502 microprocessor.

It has similarities to the Briel Replica 1, but aims to be able to be able to emulate different computers.

It looks like a interesting project, and one that I will keep my eye on. Being able to emulate a number of different old computers would be cool. It should be able to emulate, say, a KIM-1, Commodore PET, or Ohio Scientific Challenger by changing the firware. I wonder if it will have the processing power to emulate a more complex machine like the Apple II?

Thursday, April 17, 2014

Book Review - Collectible Microcomputers

Collectible Microcomputers by Michael Nadeau
160 pages, published by Schiffer Publishing Ltd, 2002.

I recently bought a new copy of this book. It has been out for some time, but is still relevant if you are interested in old computers.

The book has information and hundreds of pictures of old microcomputers, ranging from the early days of the Apple 1, Altair, and CP/M machines, through to the 8-bit era of Commodores and Apple ][ series, up to the early IBM PC and compatibles. It even covers some rarities like the Hyperion portable which was developed here in Ottawa, Canada.

Reading the book was a trip through memory lane for me, seeing computers that I had used in the past as well as many that I had only heard of.

I was struck by a few things as I looked over the book. First, I don't think many people realize how expensive some of these early computers were when new. For example, the NeXtcube sold for $11,495 in 1990; that's over $20,000 today. In many cases there was little or no commercial software available - you had to write it yourself. You had to be very forward thinking and perhaps a little crazy to invest in something that expensive. No wonder that so many of the early users seemed to be medical doctors.

Second, there used to be a huge variety in computers as far as appearance and operating systems offered. Something was definitely lost when the world moved to the majority of desktops being boring IBM PC compatibles.

Finally, if the price guide is accurate, the value of old collectible computers has soared since this book was published in 2002. The Apple //e, for example, is valued at $2 to $45. With the advent of eBay they now routinely go for hundreds of dollars. The Apple 1 is valued at $12K to $25K, but units have now sold at auction for over $200K.

The book does not have room for detailed specs on each computer, but covers a lot of machines and has some historical material on most of the manufacturers.

It is available, new or used, on amazon.com.