Professor Mark Csele

Series 600 (Challenger 1P / Superboard)

Hardware

The Superboard II was designed to form a compact and simple single-board computer. Meant as a low-cost entry-level system, this complete computer featured on-board video, and BASIC in ROM for around $300. At the time (late 70’s to early 80’s) there were a limited number of choices available to hobbyists looking for a computer: there were several systems which were ‘machine code only’ (usually featuring a keypad and seven-segment displays), but the primary competition for the superboard was the Apple-II and Commodore PET systems, both introduced in 1977, which did everything (including running BASIC) but were particularly expensive at over $1000. Having BASIC-in-ROM was a great feature since it allowed a novice to learn programming without having to invest heavily in a system that featured floppy disks.

Click here to view the full ad

The Superboard itself was shipped, ungloriously, wrapped in aluminum foil. Manuals were photocopies. It cost about $400 CDN at the time (circa 1979, about $340 USD using the exchange rate at the time), with the upgrade for 4K more of 2114 SRAM costing an additional $100 or so (in 1979 … the prices of RAM were quite high then). The advertisement above is circa 1981 (from Electronics Todaymagazine, April 1981) from the place I bought it from, Arkon Electronics on Queen St. in Toronto. The place later sold Apple and is now no longer there. Click on the small ad above to see the full ad which features pricing of OSI systems as well as other electronics.

Memory, as I said, was expensive at the time. Click Here to see an advertisement for RAM from Exceltronix in Toronto. The reason I had this Ad at all was that I purchased 8K of 2114 a year or so after I got the machine and built my own RAM expansion board (giving me a total of 16K). Two 2114 chips were required for 1K of RAM and so 16 chips were required for 8K of RAM.

Aside from the “bare board” Superboard, these units were also shipped as the packaged Challenger 1P – the identical board in a nice plastic case with a power supply – as pictured in this 1981 Ad from Popular Electronics aimed not at the hobbyist, but the ‘serious’ computer user.

Hardware

The Superboard and has several notable elements of hardware design, some quite elegant for the time (remember: this was 1978 and so, for example, 2114 1K*4 RAM chips were standard, perhaps even somewhat advanced since a few years before this the 2102 1K*8 chip was used extensively). All of the comments here refer to the revision B board (circa 1978) but apply equally to newer revisions (however chip numbers will change).

The circuitry was quite simple by today’s standards and most chips were ‘normal’ 74xx series TTL, except for the data bus buffers which were 8T28’s (and difficult to obtain at that). The board contained the keyboard, CPU, ROM, RAM (up to 8K on board), a video section for connection to a monitor or TV via a composite output or an additional RF modulator, and cassette I/O. 

Expansion was provided via a 40-pin IC socket. A ribbon-cable jumper allowed this board to connect to a 610 expansion board which also allows connection to an OSI bus (rare, though, to expand a C1P system in this way). The 610 board featured RAM (up to 24K more) and a floppy-disk controller. In my case (i.e. since the expansion board probably cost as much as the original machine), I built my own expansion boards in which the OSI expansion connector was connected to several 44-pin card-edge sockets. I had built an I/O port board for the unit as well as a RAM expansion unit (for 16K of total RAM). 

The entire board, like other OSI products, was fabricated on simple plated-through, double-sided printed-circuit board. Traces are fairly wide (by today’s standards) making the board both servicable and easy to repair. You might also note several blank prototyping areas on the board allowing easy modifications as required. 

Complete schematics for a Revision B (circa 1979) board and diagrams for the Ohio Scientific Model 600 Board:

  • Page 1 showing the CPU, buffers, and address decoding circuitry
  • Page 2 showing memory (RAM and ROM)
  • Page 3 showing memory (ROM) and the ACIA (serial port) used for the cassette
  • Page 4 showing cassette interface and video RAM circuitry
  • Pages 5 showing clock circuitry and video character generator ROM
  • Page 6 showing keyboard and related circuitry
  • Page 7 showing Keyboard and optional DAC components
  • Page 8 Chip Locations on the PCB
  • Page 9 Connections external hookup of the power supply, video, and cassette
  • Page 10 Memory Map detailing the placement of memory and peripherals in the 64K address space

A few pinouts and detailed photos

Connector J2
RS-232 Option
ROMS
IO Connector
Video RAM

While my original board was a revision B (schematics above), the newer revision D boards – functionally similar to the C1P series II – were enhanced to include RAM for colour video and had an installed RS-232 port. These boards feature a connector (J3) for connection of a 4-pole, 3-position switch allowing connection of the on-board serial port to the cassette, a modem, or a printer. This connector must be installed in order for the cassette to operate. Other features of the rev D board include provisions for colour video and a delayed power-on reset where the BREAK key must be pressed for two seconds to effect a reset.

Click here to view the PDF file.

  • PDF Page 1: J3 Wiring showing the switch required for the cassette, modem, and printer
  • PDF Page 2: Sheet 1 of 5 showing the CPU and the Monitor ROM (including 2716 jumpers)
  • PDF Page 3: Sheet 2 of 5 showing RAM and ROM wiring including 2716 jumpers
  • PDF Page 4: Sheet 3 of 5 showing video clocking, RS232 drivers, and cassette circuitry
  • PDF Page 5: Sheet 4 of 5 showing video circuitry
  • PDF Page 6: Sheet 5 of 5 showing the keyboard
  • PDF Page 7: Chip Placement for the rev D board

Let’s now examine individual hardware elements in detail (with reference to the revision “B” board).

Video

One of the best selling features of the Superboard was integrated video. The Superboard featured a 24 by 24 character display (yes, only 24 characters across) held in 1K memory mapped from $D000 to $D3FF. It was arranged in memory as 32*32 characters however not all are visible. From page 8 we can see the video RAM is selected via U55. Signal /WVE (Page 2) selects video RAM into 6502 memory map when A10&A11 are both low.

Essentially, video RAM is dual-ported between the video scan logic and the processor – in typical 6502 fashion, the RAM is connected to the processor only when clock phi-2 in high (i.e. when the processor has the ability to R/W the data bus).

The address decoder (Page 2, U23) Y6 output ($Dxxx with A12 on U20) selects video on U20. U20 output Y7 then selects video RAM for writing when A10 & A11 low, mapping the RAM to location $D000 to $D3FF. The RAM is mapped to the 6502 CPU only during phase-2 clock, where A0 to A9 on the RAM chips are mapped to 6502 CPU lines. Alternately, when not connected to the CPU, these RAM address lines are connected to clock lines C3 to C7 (five lines = 32 characters) and C11 to C15 (five lines = 32 scan lines on the monitor). Clock lines C8 to C10 selects the line (eight rows scan for each complete character) – these are actally connected to A0 to A2 of the character generator ROM to select the row of the character to use with row 0 the top row, and row 7 the bottom row.

Shift register U42 clocks eight pixels (dots) across from the pattern stored in the character generator at the rate of CLK (the crystal frequency of 3.93216MHz = the dot clock). The RAM location is then incremented (address lines C3-C7) and the next eight pixels are scanned across. 256 clock cycles later, lines C8-C10 increment to point the character generator to the next row. The same memory locations are scanned again and the process is repeated for eight rows completing one line of 32 characters. Address lines C11 to C15 then increment and the next line of characters is scanned. This repeats 32 times for 32 rows of characters.

One-shot U65 generates a horizontal sync pulse at the end of each line (C7, at 15.375KHz) and a vertical sync pulse at the end of each frame (C15, at 60.0 Hz).

Upon boot-up, a screen full of random characters appears (the random characters corresponding to the contents of RAM when first powered-up). When the BREAK key is pressed (on the latest revision of the Superboard this happens automatically), the screen clears and a boot prompt appears. The video section is essentially independent of the processor and even with no CPU chip installed should display a screen of random characters as seen here.

Memory:

For simplicity, static RAM was used. At the time (circa 1978), dynamic RAM existed offering a significantly higher density per chip however DRAM, in those days, required three power supplies (+5, +12, and -5V or -9V) as well as requiring periodic refreshing of memory cells – implementing DRAM on a simple computer such as this would require the addition of significant amount of hardware (although OSI did offer a DRAM board, the 530, for larger bus-based C2 systems).

RAM is simple: 74LS138 decoder U23 (Page 2) decodes the 64K address region into 8K blocks, the lowest of those blocks being the on-board RAM. Further decoding is performed by U22 into 1K blocks for each pair of 2114 RAM chips on Page 3.

The four BASIC ROMs are mapped to $A000 through $BFFF in four 2K blocks via 74LS139 1-of-4 decoder U17.

Monitor (SYNMON) ROM must be mapped to the highest 2K of memory ($F800 through $FFFF) since it contains the reset and interrupt vectors. This is accomplished by combining the highest 8K block selected by U23 with A12 via U15 and A11 via U19.

Miscellaneous I/O:

The Polled keyboard is simply a latch and input port selected via U20 (mapped to $DF00 but in reality mapped to a 1K memory block for simplicity).

The ACIA is mapped to $F000 (and $F001) via U17 (likely used since it is the second half of the decoder already used for the BASIC ROMs).

Normally, the ACIA is used for cassette I/O via the Frequency-shift keyer (FSK) transmitter and receiver on page 7. Baud rate generation is provided by U57 which is 300 baud for the standard cassette port – it may be increased up to 9600 baud by changing the input on pin 2 to a higher clock frequency in the chain of clock dividers (U30/U59). For example, connecting pin 2 to the CLK clock line yields 9600 baud operation (useful when bypassing the cassette altogether and loading programs from a PC).

Using 2716 ROMs

A popular modification, but one I never did to my machine, was to upgrade the SYN600 monitor PROM to a third-party one such as CEGMON. CEGMON gave the user the ability to backspace, for example, while the original monitor lacked this feature. Today, a number of collectors must use 2716 ROMs to replace missing ones on the board (I have one unit like that). When using 2716 ROMs instead of the factory masked 2316 ROMs one must jumper the board as follows:

  • Character Generator ROM: Cut traces currently between pin 18 and +5V and between pin 20 and +5V. Run a wire from each pin (18 and 20) to ground (pin 12 on the ROM).
  • Monitor ROM: Immediately below the ROM is a jumper – Follow the trace from pin 20 to this jumper. Cut the trace and jumper as shown in the photo below (cut the trace shown, add the trace shown in yellow).
  • BASIC ROMs: Follow pin 20 from each ROM and cut the traces before they reach the output of the 74LS04 inverters (U16). Run wires from pin 20 of each ROM directly to the outputs from the 74LS138 decoder (U73) – pins 12-15 as shown in the photo. While the original masked ROMs use active-high selects, 2716 EPROMs require active-low select lines.

ROM JUMPERS a photo detailing the jumpers for the monitor ROM as well as the four BASIC ROMs. You will notice that my board uses 2816 EEPROMs (pin-compatible with 2716 UV EPROMs) and a red jumper is visible instead of the proper modification to the monitor ROM jumper – the pin on the monitor ROM was simply bent sideways allowing the quick patch. A jumper was later soldered properly as shown.

RS-232 Connection

One contact on the internet suggested the use of MP3 files to store old tape images and load them back into the machine but a better solution is to use the RS-232 port to load and store BASIC programs to a PC running a terminal emulator package such as Procomm or Hyperterminal. This is facilitated by the fact that typing ‘LOAD’ or ‘SAVE’ on the machine simply sends data going to the video display to the ACIA and accepts data arriving at the ACIA as if it were typed on the keyboard – this is one of the stranger features of an OSI C1P system an reminiscent of old PDP-8 teletype-based systems. For a PDP-8 running FOCAL, for example, the user ‘saves’ programs by listing them to the teletype but first setting the paper-tape punch ON so that received characters are punched to the tape. Similarly, the PDP-8 could not ‘tell’ whether a user was entering a program manually or via a paper-tape being read by the teletype so simply loading a paper-tape into the teletype and setting the punch to ‘read’ mode caused characters to be sent to the PDP-8 and the program to be entered.

So, typing ‘SAVE’ on an OSI C1P system simply routed all text destined for the screen to the serial port as well (ditto for the ‘LOAD’ command). In that respect, simply replacing the FSK demodulator for the cassette tape system with an RS-232 level converter allows the Superboard to load programs from that port. Note that earlier 500-series systems often used an RS-232 serial connection instead of a video display and keyboard – video display was an added board and an added option.

Revision D boards often come with the RS-232 option already installed, all that is required is a switch on J3 allowing the user to select cassette, RS-232, or modem operation. Revision B boards have wiring on the PC board for the RS-232 level converters however these must be installed by the user. A series of jumpers configures the input to the ACIA to come from the cassette tape’s demodulator circuitry or from the RS-232 level converter (useful for connecting, say, a modem or for the output line, a serial printer which I did on my original system). In general, to use the serial port on a revision D board one needs to jumper pins 1 to 9 (to ground the /CTS input allowing the ACIA to transmit), and jumper pins 8 to 10 (for 300 baud operation) or pins 8 to 12 (for 1200 baud operation). Pin 2 is the transmit data output.

The RS-232 interface (for a revision ‘B’ board) requires the addition of two transistors as shown in the schematic – Q1 is a 2N3906 PNP and Q2 a 2N3904 NPN. As well, several resistors and a diode are required to be installed. Follow the circuit diagram, the photograph, and the top-down placement diagram for details. Note the unusual position of the transistors – leads must be bent in an unusual manner (with the base pin out front) in order to be mounted on the board. Otherwise, assembly is not critical.

Circuit Details

RS-232 circuit details

Aside from addition of the circuit components, one jumper (a PC board trace) must be cut. The diagrams show two ‘W10’ jumpers. One, only two wires, is broken to allow full-spec’d RS-232 voltage levels by applying -5 volts to pin 7 of J3. This is normally not required, however, so this jumper may be left alone. In this case, non-standard RS-232 levels of 0 and 5V are used instead of the true bipolar signal – so long as the RS-232 cable is short, most PC’s handle the signal properly.

The actual ‘W10’ jumper which must be cut is located on the bottom side of the board and detailed in the photograph. With this jumper removed, even cassette operation requires a jumper on J3.

Connector J3 Wiring (for Cassette Tape operation):

  • Jumper J3 Pin 5 to J3 Pin 6

Connector J3 Wiring (for RS-232 operation):

  • Jumper J3 Pin 4 to J3 Pin 6
  • J3 Pin 2 (RS-232 Out) to DB-9 Pin 2 (Transmit to PC)
  • J3 Pin 3 (RS-232 In) to DB-9 Pin 3 (Receive from PC)
  • Board Ground to DB-9 Pin 5 (Ground)

After modification, the system should be tested to ensure the cassette operates then the jumper switched and the RS-232 connection tested. On the PC, run a terminal emulator such as Procomm or Hyperterminal and set it for 300,N,8,1 (300 baud being the normal baud rate of the tape system – this can be changed later). Type ‘SAVE’ on the OSI. Now, anything typed on the OSI keyboard should be echoed to the PC via the serial port, including program listings (this is, of course, how programs are saved to the PC, by capturing incoming data on the terminal emulator program to a text file).

To load a program from the PC into the OSI, type ‘LOAD’ on the OSI keyboard. When something is typed on the PC, it will now be entered into the OSI as if it were typed locally. In this manner program files stored in a text file can be uploaded to the OSI. This method will be considerably more reliable than the use of cassette tapes (or MP3 audio files) – even the original tape system had a high error rate and unless everything was just right, loaded programs frequently had an error or two which required the user to manually correct the offending program line – programs ALWAYS came with a full listing allowing the user to correct minor errors which occurred during loading from tape.

Software and System Operation

Upon boot-up, the user was presented with a prompt for ‘D/C/W/M ?’ which allowed you to boot from disk, cold boot, warm boot (and preserve memory contents), or enter the monitor to debug machine-code programs. Few systems had disk drives since floppy disk drives alone sold for $650.00 in 1980, let alone the controller! Don’t believe me … look at one of the advertisements above. If an upgraded third-party monitor called “CEGMON” was installed, a similar boot prompt appears on the top of the screen.

Pressing RETURN to the “Memory Size?” and “Terminal Width?” prompts completes the boot process directly to BASIC which resides on the board in four 2K ROMs (so BASIC was 8K in length). The amount of actual memory is displayed as well. A system with 8K installed shows 7423 bytes since some is required for zero-page, some for the 6502’s stack, and some for scratch variables for BASIC. A system with 20K displays 19711 bytes – booting from a Disk, for example HEXDOS, will also lower the amount of available memory since the O/S will reside in RAM (and possibly even the BASIC interpreter depending on the O/S used).

Perhaps the most interesting section of circuitry on the system was the video display which used a meagre 1K of RAM. Video circuitry in the OSI switched the address and data lines of the video RAM from the 6502’s bus to an internal clock generator composed of binary counters. When a character was retrieved from the video RAM it was converted to a dot pattern by the character generator ROM (U41 in the schematics) which was output as an analog signal representing video levels (black or white). Although the video RAM could store 1024 characters and the actual video RAM was mapped as 32 lines of 32 characters, the actual display was 24 characters across by 24 lines – peripheral characters were not visible and used as a ‘guard band’ to prevent off-screen characters. Later revisions of the OSI board included a socket for a third 2114 video RAM which stored colour information. Further add-on boards (available from third-party manufacturers) even allowed bitmapped graphics with resolutions up to 256 by 256 pixels! (This, incidentally, would require at least 8K of video RAM for a monochrome display where each pixel could only be ‘on’ or ‘off’ … more than most OSI systems were shipped with). RAM, in those days, was a precious commodity and were the most expensive chips in the machine. 

The inclusion of an on-board video generator was a big selling feature of the Superboard-II since some OSI systems using 500 series hardware required an RS-232 ASCII terminal. Back in the late 70’s, these terminals cost more than the machine they were attached to! Many Challenger-II systems did feature video but using a separate video card which, of course, increased the cost of the system.

And as a huge bonus the character generator supported ASCII characters as well as a large number of graphics characters for games. Character zero, for example, was a race-car so where you’d normally drop a character 0x41 into a video memory location to make an “A” appear there (e.g. “POKE 53381,65” would make an “A” appear in the upper left corner), a character zero could cause a race-car to appear. Similarly, characters 248 through 255 depicted a tank in one of eight possible orientations 45-degrees apart, as used in the “tank for two” game (below, left). Some gaming graphics were large and required two side-by-side characters including contemporary Star-Wars fighters, Starship Enterprises (Character codes 9 and 10), and ships and submarines. The machine lacked enough memory to allow true bitmapped pixels.

Software was supplied on cassette tape which loaded at 300 baud. You could actually watch the data as it was loaded into the machine which took an average of 3-5 minutes per program.

One predominant software supplier for OSI systems was ‘Aardvark Services’. Aardvark’s ad from Micro magazine, August 1981 details the myriad of software available for an OSI system at the time, most of it on cassette tape.

Anyone heard of them since? 

Early Eighties Computer Hardware:

The early eighties were a time of homebrew computers. Unlike today, where even an amateur can buy a peripheral or upgrade and install it, to upgrade a computer in the early eighties required most users to become quite fluent in hardware (and to own a soldering iron). It was common for users to make extensive modifications to their machines as illustrated below.

Micro magazine was dedicated to the 6502 and 6809 crowd. Featured articles in this issue (Aug 1981) included the making of a coprocessor board to do complex mathematics (yes, a real Intel math coprocessor attached to an OSI CIIP!), adding I/O to the OSI system, and numerous software articles most using machine code. The magazine covered 6502 systems like the Apple, OSI, and Rockwell AIM-65. Surprisingly, the magazine was not Apple-centric (as this was the most popular 6502 system at the time) – likely because it was a bit of a ‘hardware hacker’ magazine. 

OVERCLOCKING was popular even with machines such as these. One of the modifications I made to my original machine was a ‘GT’ option which increased the clock frequency from 1MHz to 2MHz. I found the original documentation on this and scanned it for your amusement:

“GT MODIFICATION FOR 600 BOARD

The CIP or Superboard II as delivered by OSI has a primary clock frequency of 3.932l60MHZ. This frequency is a multiple of 60 (the video vertical sync frequency) and also 15,360 (the video horizontal sync frequency). One cycle of this primary frequency corresponds to a single dot, or 1/256th of a horizontal scan line on the monitor.

The clock signal fed to pin 37 of the 6502 is the primary frequency divided by 4, or .98304MHZ. This is within 2% of the nominal lMHZ which most vendors advertise, for 6502 based systems (KIM, SYM, AIM, APPLE, ETC.)

Fortunately for us, a clock frequency of 1.96608 MHZ (approx 2 MHZ) is available in a very convenient spot. With a short length (1″ or so) of small diameter insulated wire, a sharp instrument to cut a trace, and two simple soldered connections, you too, can be running your 600 Board at twice normal speed.”

The instruction sheet goes on to describe in detail how to connect the clock, then it warns you as follows:

“Both the basic proms and the monitor prom have fast enough access to run at the 2MHZ rate. There could be a problem with 2114 memory chips, especially on the CIP because of the enlosure. Chips get a little warmer when you box them up and don t circulate the air. I have one chip in my system that gets flaky after about an hour. I’ll either replace it or put in a fan”

A diagram showing how the modification was made to the board (original) 

… Some things just haven’t changes in over 20 years: computer types are ALWAYS trying to push their chips past the limit! 

Floppy Disk Drives

Ohio Scientific computers employed unique floppy drives which provided separated data and clock signals. In the beginning (1976), OSI used eight-inch drives made by GSI with a 470 controller board which was originally designed to use such a drive. Later eight-inch drives shipped by OSI, made by Siemens and Shugart, also featured data separators on the actual drive . Such drives use pin 30 as clock (separated) and pin 34 as data whereas ‘industry standard’ drives on many other machines feature a single, combined, output on pin 30 only. These drives also used AC drive motors which ran continually – no motor control was required.

When OSI went from an eight-inch to a 5.25″ drive for their smaller machines they chose to ship drives made by Micro Peripherals (MPI) which also have internal data separators. Like their eight-inch predecessors drive spindles also ran continually and OSI made no provision for drive motor control. Note, though, that not all MPI drives feature an internal data separator. Model 52 drives (which are double-sided), for example, feature a connector on the controller board (J5) which is not normally populated – except for an OSI drive where J5 connects to a data separator daughter board. Where the data separator card is not present, pin 3 of J5 should be shorted to pin 5 so that read data appears on pin 30 of the drive connector (and so an external data separator circuit could be used).

Modern drives, which provide combined clock and data on pin 30 of the 34-pin card-edge connector, require an external data separator circuit. One interesting article I’ve found regarding the interfacing of a 610 board to an actual drive is from the Aardvark Journal, Feb. 1982 in an article entitled “OSI AND THE SHUGART SA400 BY STANLEY WINDES” which described the changes required to add a standard Shugart SA-400 floppy drive to an OSI system.

The author writes: “The first thing that became apparent upon examining the OSI hardware was that the Data Separator was not on the 610 Board and it was not part of the SA400 electronics either. After much searching and head scratching I concluded that since the OSI system never misses inserting the clock pulse before each data pulse that is written on the disk, the Data Separator would be easy and simple to design. Some of the disk writing systems withhold some of the clock pulses written on the disk. This makes the data separator much more difficult. The data separator I came up with, and found to work very well, is shown in figure 3.”

Click here to view figures to accompany the article.

I had a disk-drive working with two types of controllers (although problems have developed – read on). The first controller, a third-party disk controller built from plans featured in Elektor magazine in the early 1980s, is connected to an OSI 600 board with 12K of 2114 RAM (4K of which is piggybacked on top of the original 8K chips on the motherboard itself). The drive is an original MPI model-52 5.25″ drive, but one without the internal data separator (so any drive like a Shugart SA-400 could theoretically be used here). The controller is almost fully compatible with the OSI 470, 505, and 610 controllers (although the 600 board has been modified to use the controller) and the system was booting HEXDOS (which, when loaded onto the 12K machine shows 8K of free RAM avalable). Like the original OSI floppy system the motor runs continually and it was necessary to jumper the drive to be selected continually.

HEXDOS is a simpler operating system than OSI’s standard OS-65D – it is only one track long (occupying only track zero) and uses OSI’s Monitor and Basic ROMs to save memory (i.e. it runs OSI’s on-board 6-digit BASIC). A ‘normal’ OSI configuration using a floppy disk was a 24K machine (the extra memory on a 610 expander board) running OS-65D. OS-65D was a complete O/S having it’s own BASIC so that BASIC-in-ROM was not required (larger disk-based OSI systems like the C4P-MF often had only a boot PROM installed).

OSI also offered “PicoDOS” which was a smaller version of OS-65D specifically for the C1P which, like HEXDOS, used the internal BASIC on the board adding only “load” and “save” commands which worked on disk files. Unfortunately, PicoDOS could only store eight programs on a disk and all were accessed as a number (1 through 8) so a user would type “LOAD 1” to load the first program on the disk. HEXDOS was far more advanced allowing the use of named files (LOAD “FORMAT”) and so it appears it was far more popular with C1P hobbyist users. HEXDOS, in general, appears to have been the prime choice for C1P users while those with larger systems (e.g. C4P machines with 64 column video) primarily used OS-65D.

It was discovered (see the diagnostics below), that the MPI disk drive had become ‘flaky’ and booted only once every twenty-five tries. On many attempts the drive appears to boot, displays reduced memory (the O/S consuming some 3.5K), then ‘hangs’. It was originally thought that the controller was at fault but the actual drive was the issue.

Thinking the controller was at fault, the next logical step was to get the system running with a 610 controller. An external data separator was built according to the article above. Input to the separator is from pin 30 of the disk drive and output connects to pins 10 and 11 on J2 of the 610 board. The controller was calibrated by adjusting the potentiometer to give a 6μs pulse (active high) from the Q output of the 74121 (pin 1). A cable was built as follows which connects the original OSI 610 board (connector J3 – pin 24 is the outermost pin near the edge of the board) to the floppy-disk drive 34-pin connector as follows:

OSI-610 J3 Pin Function FDD Connector Pin
1 Head Load 2
3 HSelect Drive 1 10
5 Step 20
6 Step Direction 18
8 Write Enable 24
9 Write Data 22
10 Receive Clock From Data Separator
11 Receive Data From Data Separator
12 Ground All ODD Pins
13 Ground All ODD Pins
17 Index 8
18 Select Drive 2 12
19 Write Protect 28
20 To Ground  
23 Track 00 26
24 To Ground  

The rear of the OSI 610 board, seen here with a SA400 floppy drive. The multicoloured ribbon cable connects the 34-pin connector on the rear of the floppy drive with the connector protruding from the rear of the 610 board.

Also visible in this shot is the data separator in the lower left. This is the simple two-chip circuit described in the article above built on a small piece of perf board. 

The system originally worked well with the MPI-52 drive running HEXDOS. Since the 610 has 12K of RAM on it alone, and the 600 board 8K, the system has 20K and so should be able to boot OS-65D DOS. Once again, though, the drive itself is problematic and so an attempt was made to use a Shugart SA-400L drive with this controller. The SA-400 drive boots HEXDOS reliably, however it cannot write to the disk! Time for diagnostics …

Diagnostics of the Floppy Disk System

Floppy disks use FM encoding in which a clock pulse consists of a single high-going 400nS pulse every 8μS, an a data bit is encoded as two pulses spaced 4μS apart. This can be seen in the timing diagrams that follows.

First, the timing of the one-shots on the 610 board was adjusted as per the procedure outlined in the 610 service documentation from the Sam’s PhotoFact (which is available from Dave’s OSI repository, along with the original OSI schematics for the 610 board) as follows:

  • With the 610 board disconnected from the drive, the pulse at pin 13 of the U68 one-shot is adjusted for a width of 400nS using R18. This is the TxClock signal now transformed into a clock stream.
  • Similarly, pin 12 of the same one-shot is adjusted for a negative-going width of 400nS using R9.
  • This adjusts the Tx Clock settings, now for the Read Clock:

  • Jumpering J3 pin 9 (Write Data) to J3 pin 10 (Receive Clock), adjust R10 so a 1μS pulse appears at pin 5 of U70 (which produces the clock signal fed to the UART).
  • Jumpering J3 pin 9 (Write Data) to J3 pin 11 (Receive Data), adjust R19 so a 6μS low-going pulse appears at pin 4 of U70 (which produces the data signal fed to the UART).

Use of floppy disks with an OSI machine require the addition of a data separator which extracts separate data and clock streams from the incoming data stream from the floppy disk drive. The simple data separator used here consists of a a one-shot and several gates and the operation is illustrated by a analyzer capture of incoming and outgoing signals. The top trace (channel 1) represents data coming from the disk drive and channel 2 the extracted clock stream. For every data bit (whether a logic 0 or a logic 1), a clock pulse (channel 2) is generated at a constant clock rate of 125KHz. Channel 4 shows the low-going pulse from the data separator’s one-shot set for approximately 5.2μS. Each blue line in the capture represents 1μS.

Operation of the data separator on a stream of data is illustrated in another capture in which each blue line is 8μS apart and three bit cells are outlined from the long stream of data recorded.

The floppy disk system can boot reliably and reads disks fine (i.e. it can load programs on subsequent tracks on the disk so it is reading beyond track 0) however the write function does not currently work, so a logic analyzer was used to verify the timing and operation of the write logic of the 610 board as follows:

  • Channel 1 is pin 8 of the U67 7400 gate which consists of the addition of the clock pulses (channel 2) with data signals from the UART (channel 3). It is the exact format specified for floppy drive write data but is inverted.
  • Channel 2 is pin 13 of the U67 7400 gate which is a continuous clock stream consisting of 400nS pulses spaced 8uS apart. This clock stream is generated from the master 125KHz clock on the 610 board whoch triggers a 74123 one-shot (U68) to produce 400ns wide pulses. The pulse width is adjusted by R18.
  • Channel 3 is the data stream from the UART at pin 8 of the U69 7404 inverter for data. This verifies the operation of the UART and the inverter.
  • Channel 4 is the final data stream to the disk drive, which is simply the inverse of channel 1 (inverted by one sixth of U69) and is used to ensure the output drivers on the 610 board are all functioning.

The timing of the signals conforms with that outlined in the Shugart SA400 manual – it was verified by the logic analyzer that the write enable goes low as the index goes from low-to-high with the data line consting of nothing but zero’s (clocks, 8μs apart) until at 1.2ms after the index transition data actually appears on the write data line (a logic 1 appears, followed by a zero, and several more 1’s). When a known good disk is read with the analyzer on the floppy disk lines, a similar pattern appears (i.e. blank clocks on the read data line until 1.2ms after the index pulse goes high) but when a disk formatted on this drive is read in a similar manner, only clocks appear on the read data line. Finally, it seems that the drive is at fault here.

Observing the operation of the actual drive (with the control PCB moved to the side), one can see that it steps erratically. This may well explain the situation since HEXDOS resides on one track so a drive which cannot step properly would still load! I recall reading in an old PEEK journal that HEXDOS can be set for any step rate however the instructions were for HEXDOS 2.3, not my 4.0 version.

Disassembling HEXDOS in memory (remember, it sits on track zero and so loads even if the drive cannot step properly), one finds the stepping routines as follows (with my comments added):

04D2 48     PHA   
04D3 9006   BCC $04DB  //If Carry set, step out
04D5 E6D8   INC $D8    //Increment current track # counter
04D7 A9FB   LDA #$FB   //Step out = PB3 low
04D9 D004   BNE $04DF  
04DB C6D8   DEC $D8    //Decrement current track # counter
04DD A9FF   LDA #$FF   //Step in = PB3 high
04DF 8D02C0 STA $C002  //Output to PIA	
04E2 29F7   AND #$F7   //Isolate bit for PB3 (J3 pin5)
04E4 8D02C0 STA $C002  
04E7 0908   ORA #$08   
04E9 8D02C0 STA $C002
04EC A203   LDX #$03   //Default step rate - this is the problem   
04EE 2091FC JSR $FC91  //Time delay (1.25mS times X)

So, by changing the variable at location $04ED from $03 (5mS step) to $25 (50ms step), the drive can step properly. This is done as follows:

  1. Boot a copy of HEXDOS 4.0
  2. Hit BREAK and enter Machine code mode (M)
  3. Enter address “04ED”, and the data field should display as “03” (the default delay)
  4. Press “/” to go to data mode, and enter “25”
  5. Hit Break again and warm start (W)
  6. Load FORMAT from the HEXDOS disk (and it will actually step to that track properly now) and format a new disk

HEXDOS formats all tracks (and you can see it step properly now) then writes itself to track zero of the newly formatted disk. Since it copies itself from memory the new step delay value will be written as well. You now have a patched copy of HEXDOS with a slow step rate that will run on an SA-400 drive. This does not help with booting OS-65D which likely has similar problems with step timing so ultimately, a working MPI drive might be required for that. Furthermore, according to an OSI manual a special version of OS-65D was required for use with a C1P which uses 24-by-24 (440 style) video … this will complicate any attempt to port the O/S from my 8-inch systems to a 5-1/4 inch system.

Oh yes, one final comment of the use of floppy drives with an OSI: A reader from Florida had a problem recently in using a newer model 52 MPI drive in place of an older model 51. Apparently the 51 has a daughterboard (the data separator) but the 52 does not. He writes the following on changes that must be made to the model 52 drive:

I just found the change in a very old article by David Livsay – “To use the newer MPI drives without the separator board you must follow the trace from pin 30 to the 7438 NAND pin 3. Now follow pin 3 of the NAND and you will find it goes two places-
1. Daughterboard connector
2. pin 5 and 9 of the 74LS123

CUT the connection between pin 1 (NAND ) and the 74LS123.”

When I examined a old model 51 board I found that trace is cut (right at pin 1 of the NAND, bottom of the board), whereas on the 52 it is intact.

Hopefully that helps someone else trying to make their floppy system work!

Using the HEXDOS Operating System

HEXDOS is a simple operating system residing on a single track. It was written by Steven Hendrix in the early 1980’s and was very popular with Superboard users primarily because of the low cost both of the O/S and of the hardware – HEXDOS could run well on a system with only 12K of memory. Unlike OS-65, it does not offer BASIC on disk but rather uses the BASIC residing on the Superboard ROMs – it simply adds LOAD and SAVE functionality (Mind you, disk BASIC was 9 digit while BASIC-in-ROM was only six). When booted (using the “D” option), HexDOS loads then returns immediately to BASIC – the only indication it has loaded being the display of 2.3K fewer bytes free than a cold boot (i.e. 17407 bytes free on a 20K system, for version 4.0 at least). To get a directory of a disk, the “LOAD/” command is used which loads the directory into memory as a program file. Typing LIST displays the actual contents of the disk as seen to the right.

HexDOS supports named files so a user can type LOAD “FORMAT” to load that program . Like contemporary operating systems of the late 70’s, few functions were internal to the operating system and basic functions such as formatting a disk or deleting a file required the user to load a program to accomplish this.

Internals of the HEXDOS Operating System

It is instructive to examine precisely how HEXDOS works by looking at both the command programs (such as FORMAT) and the disk format itself. We begin by examining the essentials of the FORMAT program, written in BASIC, since this program not only formats tracks but also copies the O/S to the disk using O/S calls. For brevity, only essential code is presented here (not, for example, the required “Are You Sure?” code).

This code generates then writes a blank directory to track one
 160 DATA0,16,0,24,1,2,0,255                  //The data file header region is filled here, 568=char pointer 
 170 FORI=566TO573:READT:POKEI,T:NEXT
 180 REM FILE #4 IS NOW DIRECTORY
 190 DATA0,11,1,0,3                           //This is actually the first four bytes of the track 1 directory
 200 FORI=0TO4:READT:PRINT#4,CHR$(T);:NEXT
 210 PRINT#4,A$                               //Date and time header is added to the directory
 220 PRINT#4,MID$("JANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDEC",3*M-2,3);
 230 PRINT#4,D;Y
 235 P=PEEK(566)+256*PEEK(567):T=PEEK(568)-PEEK(566)+2:POKEP,T    //P=4096, and T=21 by inspection here
 236 PRINT#4,CHR$(0);CHR$(T+6);
 240 DATA11,2,0,165,0,0,0
 250 FORI=0TO6:READT:PRINT#4,CHR$(T);:NEXT
 260 SAVE*4                                   //Write buffer to disk (device #4)

This code writes blank tracks 2 through 39
 280 B=PEEK(125)+256*PEEK(126)+10             //B is a pointer to the first array, by inspection B=3698
 290 DIMA(525)                                //Empty array - will fill the track with zeroes
 300 FORI=2TO39:SAVE#I,B:NEXT

This code writes the O/S to track zero from memory
 310 POKE2818,0:SAVE#0,768:POKE2818,11        //2818 is the first byte of the FORMAT program - made invisible here
                                              //then the O/S is copied from memory to track zero

Although we are not privy to the exact format of the disk header, it is observed that the number at location 568, initialized to 1, increments after each character is printed to device #4. After line 200, for example, it has a value of 5. On line 235, T is found to be 21, although the exact function of the POKE in that line is unknown.

The actual format as written to the disk was investigated by examining the data read directly from a working disk. Using the HEXDOS command “LOAD #n,9000” to load 2048 bytes from track “n” to (in this example) location 9000, the memory was then interrogated to see the exact format of bytes on the disk. This was done for several tracks including zero (where the O/S resides) and one (where the directory resides).

Following the format expected by the OSI boot ROM, track zero is special in that it begins immediately with the load address (high, low address) followed by the actual O/S code as follows (with all numbers in decimal since they were dumped using a BASIC program using PEEK and PRINT statements):

03, 00, 09, 32, 182, 03, 21 ...

The first two bytes specify the address to load HEXDOS into memory as $0300. A total of 2K is loaded so the space $0300 through $0AFF holds the O/S. The third byte, “09”, is the number of pages – one would expect (from the OS-65D convention) that this be eight (i.e. eight pages of 256 bytes each for 2K total per track) however a nine was actually read from a working disk – the reason why is a mystery.

The vast majority of the FORMAT program above is hence devoted to forming a directory on track 1 which is then updated by HEXDOS as program files are written to the disk. A working directory (from a disk with several programs on it) was read as follows:

87, 01, 27, 11, 01, 00, 03, 72, 69, 88, 68, 79, 83, 13 ...

As expected, the first two bytes are the sync character ($57) and the track number (the thirs number is once again a mystery). The disk name is seen in the data as “HEXDOS …”. Inspection of that track further reveals directory entries as follows:

... 11, 02, 00, 70, 79, 82, 77, 65, 84 ... 

Which spells “FORMAT” which begins on track 2. The actual files on the directory were as follows:

 2843 
 22597 DOS
FEB 20  5 

 2 FORMAT
 3 DELETE
 4 CREATE
 5 DISASSEMBLER
 7 REVERSI
 9 *

Further tracks contains BASIC programs in “core image” format (i.e. tokenized and as it appears in memory) such as track two which contains the actual BASIC “FORMAT” program:

87, 02, 33, 11, 10, 00, 142, 32, 68, 73, 83, ... 

Again, the sync character and track number, (and a mysterious third number), followed by “11” to identify the program as a BASIC program, the BASIC token for the line number (two bytes, in binary, “0010”) followed by the BASIC token for a REM statement (142), and the actual text of the remark “DIS …” since the first line of the program was “10 REM DISK FORMATTER FOR HEXDOS”.

Track three contains a program called DELETE for which the first line is “10 FILE DELETE …” as seen in the following dump of track three:

87, 03, 31, 11, 10, 00, 142, 32, 70, 73, 76, 69 ... 

All tracks follow a similar pattern.

My Original C1P System

My superboard was originally used as a single, open board for which I built an external memory board and I/O interface on 44-pin card edge boards. The memory board features 8K of 2114 RAM chips stacked together giving the system a total of 16K. Later, Dad built a wooden box for the system (which I used for some time) and finally I built the system into a PDP-8/A case as pictured to the left. The OSI 48-pin bus was connected to the PDP-8 backframe and I built cards to suit.

In order to fit into the case the keyboard was separated from the single board – it was connected via a large cable (I literally cut the printed-circuit board with a jigsaw). I/O and memory cards were then built which fit into the backframe. The cards pictured here include two parallel I/O interfaces, a sound/voice card featuring an ‘SN’ chip, and a 24K memory card using newer 2K-by-8 memory chips.