Difference between revisions of "The Gemini 80-Bus Saga - Part 1"
(→Introduction) |
(→CP/M Via the Serial Port) |
||
| Line 327: | Line 327: | ||
32k CP/M vers 2.2 | 32k CP/M vers 2.2 | ||
A:> | A:> | ||
| + | |||
| + | ==Adding a Real Floppy Disk Drive== | ||
| + | |||
| + | As I was completing the work with the Gotek, I was given a very dirty Teac FD55F floppy disk drive. The Gotek is fantastic for getting software to the machine but its not very 'Retro'. I cleaned up the drive reattached the resistor R13 which had been fed trough a switch. I assume this is a mod that allows the disk to be switched between 40 and 80 tracks. My basic GM815 64K system disk image is a 35 track image so 40 tracks is good. | ||
| + | |||
| + | I assumed that if I could get the drive working that I would be able to use SYSGEN to transfer the CP/M system to the disk, however, sysgen wouldn't write to the disk for some reason. I then tried various disk copy utilities (COPY.COM, COPYX.COM, ICOPY etc), these utilities wouldn't update the system track ether. In the end I wrote a utility that accessed the BIOS routines to read in the first 80 128 byte sectors from disk A: before writing them back out to B:. The only issue I had was that I had to make sure that when the floppy drive was formatted it used the same sector skew (0 in my case) for both A: and B:. | ||
| + | |||
| + | Swapping the Gotek with the real floppy means that the system will boot from floppy disk (A:) as originally intended and with the Gotek as disk B: I still benefit from the flexibility the device offers. | ||
==CP/M Via the Serial Port== | ==CP/M Via the Serial Port== | ||
Revision as of 19:46, 4 November 2019
HELP NEEDED!..... I am desperately seeking to archive Gemini 80-Bus software before it is lost forever. I am particularly interested in GemPen, CP/M bios versions, SYS and any disk images that may be around. I am also keen to preserve as much hardware as I can (finances allowing). Please get in touch if you can help or have a similar interest.
- Facebook: https://www.facebook.com/john.newcombe.skipton
- Twitter: https://twitter.com/johnnewcombeuk
For the resources gathered so far please see the Gemini 80-Bus Resource page.
Contents
- 1 Introduction
- 2 A Potted History
- 3 My Gemini System
- 4 Power Supply Unit
- 5 A Two Card System
- 6 A Three Card System
- 7 Parallel ASCII Keyboard Converter
- 8 MBasic (Basic-80)
- 9 Creating a Cassette Tape of MBasic
- 10 The XBeaver Gemini Emulator
- 11 Upgrading RP/M to 9600 Baud
- 12 Connecting a Gotek Floppy Disk Emulator
- 13 Adding a Real Floppy Disk Drive
- 14 CP/M Via the Serial Port
- 15 Updating the BIOS and Configuring CPMTOOLS
- 16 IVC Hit by Lightning
- 17 Installing T-Net
- 18 More BIOS Updates - Adding a Winchester Disk
- 19 A Note From the Author
- 20 Appendix A - PS/2 to Parallel ASCII Converter Wiring Diagram
- 21 Appendix B - Creating an RP/M Hex File
- 22 Appendix C - Tape Connector
- 23 Appendix D - Converting from .DMP to .IMG Format
- 24 Appendix E - Floppy Interface Connections
- 25 Appendix F - IVC Terminal Codes
- 26 Appendix G - Patching Wordstar 3.0 for the Gemini IVC Card
- 27 Appendix H - Configuring Turbo Pascal 3.0 for the Gemini IVC Card
Introduction
This article describes the journey undertaken in order to bring a Gemini 80-Bus CP/M system back to life. The system was purchased via eBay in April 2019 and included quite a lot of documentation and circuit diagrams. Should be easy right? The truth is that if I had known at the beginning the amount effort that would be exerted in order to get this machine into a usable state, I probably wouldn't have bothered. But then I would have missed a real gem.
Before I started this project I knew very little about the workings of CP/M, I had very little experience in Z80 Assembler and my electronics was rusty at best. However, with the help of people out there in the community the journey has yielded some great results.
A Potted History
The original Gemini 80-Bus system was a two board system designed to be a replacement for the popular UK computer, the Nascom-2. Nascom had been taken into receivership and there was concern from outside the company that if buyer could not be found, the whole Nascom community would die. The new company Gemini, was headed by John Marshall who had previously headed Nascom and was based in Amersham, Buckinghamshire, England.
The 80-bus system used in Gemini machines was a tidied up version of the bus used on the Nascom and was thought by many to be the UK's answer to the S100 bus. The bus was backward compatible with the Nascom bus and provided a means for Nascom owners to expand and improve their systems. The Gemini boards were 8 inches square and were typically fitted into a 19 inch rack and as the company grew many types of expansion boards were produced. A Gemini system could consist of a singe board or have its functionality spread across multiple boards making the the system very flexible. In addition many other companies supplied 80-bus compatible cards.
The Gemini system was primarily designed to be a CP/M system and, with the right expansion cards, could support 8 and 5.25 inch floppy drives as well as Winchester (hard) disk drives.
My Gemini System
In April 2019 I took delivery of what appears to be a fairly typical Gemini system. The computer consisted of a G811 Z80 CPU card, a MAP80 memory card populated with 64K of Memory, an G812 intelligent video card and a GM829 floppy/hard disk controller card. These were all fitted to a 19 inch rack with a home made Veroboard based backplane. All that was needed was a power supply, a suitable keyboard, disk drives and software. Hmmm!
There were a couple of interesting details regarding the machine, the first is that it includes RP/M version 2.2. This is odd as version 2.2 of RP/M was (supposedly) never released, the version numbers leapt from V2.1 to V2.3 to avoid confusion with version 2.2 of CP/M, this was confirmed in an article written for 80-bus news by RP/Ms creator Richard Beal (80-BUS vol. 3 iss. 6 p. 9).
The second interesting thing is that there is also an EPROM containing the Gemini Boot ROM for 8 inch Disks. This appears to be written by Roger Brooks, and, based on the included source code listings and manuscript amendments, this would appear be the machine he created it on. So, if Roger is reading this or anyone knows anything about Roger please get in touch via twitter @johnnewcombeuk (https://twitter.com/johnnewcombeuk).
Power Supply Unit
For the PSU I opted to use an ATX PSU with a 24 pin connector. I used a 24 pin extension lead to attach to the Gemini backplane which meant that the PSU could simply be plugged into the Gemini and swapped as required. The Gemini documentation suggests that the usual +12v, +5v, -12v and -5v supplies are required. However the later ATX PSU units do not tend to supply -5v. Checking the circuit diagrams for the cards I am using showed that a -5v supply was not actually required making things simple.
A Two Card System
The CPU board includes, ports for an RS232 serial device, a keyboard and a cassette tape recorder. The card also includes an EPROM based system monitor called RP/M (see below). The card is configured using a series of wire straps placed on DIL headers and was, as you would expect, configured to use the external G812 video card I had.
My initial aim was to see the system running with the minimum of hardware, namely the CPU board and the memory board. By making the connection between pins 6 and 7 on link LKB1 on the CPU board I configured the system to use the serial port for input/output. In the end I added a small jumper that could be used as required to switch between using the serial port and the video controller. By using the serial port for control, all that was required was to create a short lead and connect to a machine running a terminal emulator set to 300 baud (7E1).
Inspection of the CPU board showed a couple of issues, the first was rusty pins on a couple of ICs. In this case they were the two Proms used for addressing. Unfortunately the affected pins broke off flush with the plastic body of the IC as soon as they were disturbed. However, by grinding away a slither of the plastic IC casing with a Dremel, fresh metal was exposed allowing me to attach some pins from a donor IC. The second issue was that the EPROM that contained the system monitor had been inserted incorrectly and seemed to have been splashed with a large blob of paint. This was easily remedied before powering up the two card system.
57344 bytes - RP/M for Gemini V2.2 ** RP/M ready ** *_
At this point I was able to use the monitor to inspect and set memory, so I dumped the contents of the RP/M EPROM to the screen of my terminal emulator and pasted this into a text file for safe keeping.
For the knowledgable amongst you, you will notice that the Version of RP/M is 2.2. This is odd as version 2.2 of RP/M was (supposedly) never released, the version numbers leapt from V2.1 to V2.3 to avoid confusion with version 2.2 of CP/M, this was confirmed in an article written for 80-bus news by RP/Ms creator Richard Beal (80-BUS vol. 3 iss. 6 p. 9).
A Three Card System
By removing the connection between pins 6 and 7 on link LKB1 on the CPU card and inserting the video card, the system proudly displayed the ready message on the connected composite monitor.
IVC Monitor V2 - 1982 57344 bytes - RP/M for Gemini V2.2 ** RP/M ready ** *_
However, without a keyboard, not much more could be achieved.
Parallel ASCII Keyboard Converter
The Gemini was designed to use a parallel ASCII keyboard and, whilst I had an old Apple II clone keyboard that probably could have been coaxed into life, I wanted a keyboard with function keys and a full set of cursor keys. I decided that until I could obtain an original Gemini keyboard, the best solution would be to use a PS/2 keyboard and make a simple Arduino based PS/2 to parallel ASCII adapter. I used the small Arduino Micro and created a sketch to do the trick.
The sketch is described here https://bitbucket.org/johnnewcombe/geminikeyboard/src/master/ and the wiring diagram to connect the Arduino to the IVC card and the PS/2 connector is shown in #Appendix A - PS/2 to Parallel ASCII Converter Wiring Diagram.
Once I had the keyboard connected and working, I needed to try and run some software.
MBasic (Basic-80)
RP/M is a system monitor written by Richard Beal specifically for the Gemini system and is uses a subset of the CP/M api in that something written 'against' RP/M will also run on CP/M the reverse is not necessarily true as RP/M supports only one sequential file being opened at a time and random access is not supported. RP/M was designed support cassette based storage rather than disks, although it will allow booting to disk. Having said that, it is reported that the CP/M version of MBasic and Digital Research's ZSID Dynamic Debugging Program will run under RP/M, so, given the absence of any form of disk storage this seemed to me to be the logical next step, so I downloaded the binary from one of the many CP/M repositories with the aim of somehow getting it into the machine.
Despite the absence of MBasic on cassette tape, I had a few options to explore. The first was to try and create a .wav file containing MBasic in cassette format (KCS/CUTS). The difficulty here is that whilst is is reasonably easy to create a .wav audio file from an array of bytes, there is more to a Gemini tape archive than just a stream of audio. The Gemini RP/M tape system adds a header to the stream including a filename and, on the basis that an error results in a prompt to rewind the tape before continuing, it is safe to assume that each block of data (128 bytes) includes a frame number and checksum.
The second option is to enter the byte values directly into the monitor, or rather, paste the data into a terminal emulator window. It is an approach that has worked for me before. By ensuring that each CR/NL is followed by a short delay, the system can easily cope with the pasting of a large amount of data. So for this to work is was necessary to switch back to using the RS232 port with a terminal emulator (see #A Two Card System).
The first task was up the speed of the serial port from 300 baud to 9600 baud. This can be done at the RP/M prompt e.g.
** RP/M ready ** * UD 9600
After entering this command, change the speed setting of the terminal emulator to match. Next set the CR delay to 200ms, this value was determined from trial and error. The higher the value, the more reliable and the slower the transfer is, 200ms seems to be optimal. I tend to use Minicom as a terminal emulator which can be configured by selecting the Meta Z (typically Esc+Z) to bring up the main menu, from here the Terminal Settings option can be selected in order to set the delay.
Next, the MBASIC.COM binary file needs to be converted to a HEX file in the following format (see #Appendix B - Creating an RP/M Hex File) and pasted into the terminal window.
S 100 c3 8c 5d 7a 29 dc 29 06 44 bf 11 9e 45 ec 14 63 18 86 39 40 19 18 15 95 14 67 14 51 16 e6 43 7d 14 d1 14 ee 14 01 44 9c 16 0e 45 89 20 20 43 85 15 73 44 03 20 2b 1e c0 22 5d 44 c9 0c c9 0c fd 1f 94 16 84 20 00 00 24 20 ee 14 7c 44 7d 44 82 44 c4 44 e3 3c 10 16 d3 15 7c 22 ... ... 38 31 0d 0a 00 00 00 00 00 00 00 00 .
The S 100 RP/M command allows data to be set in memory starting at address 0100h. In this example each row has 40 hex bytes although anything from 1 to 42 is possible the more hex digits in the row, the quicker the transfer will be. The final full stop should return you to the RPM prompt.
After 2-3 minutes, all 24340 bytes should have been entered and time to see the results. Press I to run the code fro 0100h e.g.
** RP/M ready ** * I BASIC-80 Rev. 5.21 [CP/M Version] Copyright 1977-1981 (C) by Microsoft Created: 28-Jul-81 31538 Bytes free OK
The files below contain the RPM txt files for MBasic and ZSID.
Creating a Cassette Tape of MBasic
This turned out to be far easier than expected. I knew that if the method described above was used to enter data using the RS232 port, it would not be possible to switch to the cassette interface to save the program to tape. This is due to the serial hardware being used for both RS232 and cassette. However, it turns out that the G811 CPU board can support both the IVC and RS232 as input with IVC providing the display. Therefore with the configuration set to use the IVC (see #A Three Card System data can still be entered using the RS232 port.
By using the PS/2 keyboard to set the serial baud rate to 9600 e.g.
** RP/M ready ** * UD 9600
The process described in the above section (#Running Some Software) can then be used to load MBasic into memory although I did find it necessary to set the character delay to 50ms and the CR delay to 250ms. Once the data has been loaded all that is required is to tell RP/M the size of the program using the L command before switching to cassette using UC and writing the program to tape e.g.
* L BE * UC * W MBASIC
Once the recording is complete it can be tested by using the R command e.g.
* R MBASIC
Insert file: MBASIC
Start Playing Press return
****************************...
Remove file: MBASIC
Press return
The program can then be run with the I command e.g.
* I BASIC-80 Rev. 5.21 [CP/M Version] Copyright 1977-1981 (C) by Microsoft Created: 28-Jul-81 31538 Bytes free OK
For details of the tape connector see #Appendix C - Tape Connector.
The XBeaver Gemini Emulator
In order to take things further I needed to get up and running with a floppy disk solution to boot CP/M but before that I needed to obtain some disks.
John B Hanson (http://81.105.120.101/xbeaver/) has created an emulator that can emulate, amongst others, the Gemini system and after contacting him via the UK Vintage Radio Repair and Restoration forum (https://www.vintage-radio.net/forum/showthread.php?t=156106) he very kindly sent me some Gemini CP/M images in .DMP format. As his emulator supports DMP format, I thought it would be useful to get it up and running.
The code can be downloaded from http://81.105.120.101/download/xbeaver.tgz and can be compiled for many systems.
Compiling
To compile this on a recent version (May 2019) of Arch Linux (my distribution of choice), a few changes to the Makefile were made as follows.
A change was made to CC label to include the tirpc include folder, e.g.
CC =gcc -I/usr/include/tirpc
The linux section of the Makefile was modified to be as follows
linux: $(VIRTUALBEAVER_OBJS)
$(CC) $(CFLAGS) $(VIRTUALBEAVER_OBJS) -o xbeaver \
-ltirpc -lX11 -lXpm -lXt -lncurses -lm -lutil -lpthread
On my system all of the linked libraries in the above command line were present on the system making things very simple. If these are missing simply install the package as required. The libraries are as follows.
In addition to making sure that the libraries above were installed, the festival speech package was added with an english voice e.g.
# pacman -S festival # pacman -S festival-english
Keyboard Input Issues
I use KDE/SDDM as my windowing environment, however with this combination there was an issue with Xbeaver in that I could not switch focus to the Xbeaver window. The README file that came with the download describes the issue. The work-around for me was to ust TWM as a window manager for times when I was using Xbeaver. If I get time in the future I will try and see what the issue is with KDE/SDDM as it would be great to use it without switching environments. I understand that Gnome does not have the issue although Openbox and LXDE do.
Configuration
The default configuration gave me an all singing all dancing Gemini system, however, as I was looking to emulate my own physical system I decided to start with a minimalist configuration.
The basic xbeaver.cfg file I used was as follows.
verbose cpuclock 4 board 0xfe gm813_mmu board 0xb0 gm832 BeaverBoot planes green board 0xb8 serial_8250 bvrnet ~/beaver/network board 0xe0 gm829_floppy -debug DSZ -geometry DP35.2.10.512 ~/beaver/images/GM512_ORIGINAL.DMP binload 0xf000 ~/beaver/roms/RPM_2.3.ROM byte 0f0a8 21 00 f0 #Patch top of ram for RPM
Note that I am using version 2.3 of RP/M (see below).
A Note about RP/M Versions
RP/M is one of the monitor programs, supplied in EPROM, that was available for the G811 processor board. Version 0.1 was the initial release, the second enhanced version was 2.0. When the MAP256 memory board was released there was, under certain hardware combinations, a conflict with RP/M when it was trying to detect if a disk was present. This was entirely due to the MAP256 board, however, a small patch was made available for RP/M to deal with the anomaly, this was deemed to be version 2.1. Version 2.2 was never released in order not to be confused with CP/M 2.2 and the final version was 2.3 which had some enhanced disk boot routines.
My system was supplied with version 2.2 which, according to Richard Beal, the authors of RP/M, never existed. It appears that 2.2 I is a patched version of 2.1 to work with a different disk arrangement. Thanks go to John B Hanson for determining this. As a result I have now been able to create version 2.3 for use with both Xbeaver and the real hardware. The images are available here Gemini_80-Bus_Resource#ROM_Images.
Upgrading RP/M to 9600 Baud
When using the serial port for keyboard/screen IO using a terminal emulator I was manually switching from the default 300 baud to 9600 baud. In order for RP/M to default to 9600 baud a small patch to RP/M can be made. The GM811 (Z80 CPU) docomentation shows a whole list of divisor values that can be used to set the default serial port speed.
F009 is the location of the two byte divisor. To set the default speed to 9600, set the values as follows.
F009 = 00 F00A - 0D
Connecting a Gotek Floppy Disk Emulator
Preparing Disk Images
I was keen to get a floppy drive working with the Gemini and, as I had access to some CP/M boot disks in .DMP format I thought that using a Gotek device (http://www.gotekemulator.com/) with the FlashFloppy firmware written by Keir Fraser (https://github.com/keirf/FlashFloppy) would be a sensible first step. Whilst this took me some considerable time to understand what was required, it turned out to be quite easy to acomplish.
By using a simple python script, the .DMP disk images were converted to a simple .IMG format. With the .DMP image, each sector had an eight byte sector header which showed the layout to be very simple, it is shown below. The .IMG format I needed was to be the same layout but without the eight byte sector. #Appendix D - Converting from .DMP to .IMG Format shows a small script that was used.
Side 0, Track 0, Sectors 0 - 9 Side 1, Track 0, Sectors 0 - 9 Side 0, Track 1, Sectors 0 - 9 Side 1, Track 1, Sectors 0 - 9 ...
This format is often referred to as track interleaved, not to be confused with sector interleaving.
The image files I have are available here, Gemini_80-Bus_Resource#Disk_Images.
Connecting the Gotek
Adding a Gotek (or floppy drive) to the GM829 requires either a SA400 Shugart interface drive with a straight cable or an IBM PC drive with a standard 7 wire twisted cable, see #Appendix E - Floppy Interface Connections. The firmware chosen for the Gotek (see below) allows this to be configured in software so either cable type should be suitable as long as the necessary configuration option is set in FlashFloppy. This article assumes a straight cable has been used with the Gotek drive select link set to S0. This article also assumes that the GM829 is configured to use Pertec Drives, by ensuring that the setting of Link 1 connects B to C.
There are several Gotek devices to choose from e.g. 24 pin, 34 pin and USB. A 34 pin device should be used, ideally with a 3 digit LED. These are very cheap, the Gotek used in this article was purchased in May 2019 for $15 from a Chinese supplier. It arrived postage free in around 2 weeks.
Configuring the Firmware
The FlashFloppy firmware written by Keir Fraser was installed on the Gotek using the instructions on Keir's website (https://github.com/keirf/FlashFloppy). This is a simple process, however, version 2.x of the firmware is required as this allows for custom disk formats. Once FlashFloppy is installed, all that is required is to create two text configuration files and place them in the root of the USB stick that is to be used with the Gotek. The files are as follows.
IMG.CFG. This file defines that all *.IMG files should be treated as Gemini 35 track DDDS CP/M images.
[default] cyls = 35 heads = 2 secs = 10 bps = 512 id = 0 iam = no file-layout = interleaved # '80' matches images of the form *.80.img and *.80.ima and is used for the 80 track QDDS CP/M images. [80] cyls = 80 heads = 2 secs = 10 bps = 512 id = 0
FF.CFG. Many of these are default settings, and some relate to optional display and other uogrades, however, the whole file is reproduced here for completeness.
interface = shugart host = unspecified pin02 = nc pin34 = nc write-protect = no side-select-glitch-filter = 0 track-change = instant index-suppression = no head-settle-ms = 12 ejected-on-startup = no image-on-startup = last display-probe-ms = 3000 autoselect-file-secs = 2 autoselect-folder-secs = 2 nav-mode = default nav-loop = yes twobutton-action = zero rotary = full display-type = auto oled-font = 6x13 oled-contrast = 143 display-off-secs = 60 display-on-activity = yes display-scroll-rate = 200 display-scroll-pause = 2000 nav-scroll-rate = 80 nav-scroll-pause = 300 step-volume = 10 da-report-version = "" extend-image = yes
Booting the System
Once the Gotek is connected and configured all that is required is a reset of the CPU and CP/M should be up and running.
57344 bytes - RP/M for Gemini V2.1
Executing boot
Gemini Multiboard Auto Density System (1.4)
32k CP/M vers 2.2
A:>
Adding a Real Floppy Disk Drive
As I was completing the work with the Gotek, I was given a very dirty Teac FD55F floppy disk drive. The Gotek is fantastic for getting software to the machine but its not very 'Retro'. I cleaned up the drive reattached the resistor R13 which had been fed trough a switch. I assume this is a mod that allows the disk to be switched between 40 and 80 tracks. My basic GM815 64K system disk image is a 35 track image so 40 tracks is good.
I assumed that if I could get the drive working that I would be able to use SYSGEN to transfer the CP/M system to the disk, however, sysgen wouldn't write to the disk for some reason. I then tried various disk copy utilities (COPY.COM, COPYX.COM, ICOPY etc), these utilities wouldn't update the system track ether. In the end I wrote a utility that accessed the BIOS routines to read in the first 80 128 byte sectors from disk A: before writing them back out to B:. The only issue I had was that I had to make sure that when the floppy drive was formatted it used the same sector skew (0 in my case) for both A: and B:.
Swapping the Gotek with the real floppy means that the system will boot from floppy disk (A:) as originally intended and with the Gotek as disk B: I still benefit from the flexibility the device offers.
CP/M Via the Serial Port
During the writing of this article my GM811 IVC display card developed a fault. This made booting to CP/M a little tricky as the Gemini CP/M is designed to send its output to the IVC or SVC display card. John B. Hanson provided a patch to direct CP/M output to the serial port, therefore, by switching back to using the serial port (see #A Two Card System) I could at least use the machine until such time as the IVC is sorted. The patch sacrifices the printer routines, however, for the purpose of testing CP/M, it works well.
The patch was implemented during the .DMP to .IMG conversion and the disk image is provided below. This image was designed to operate the serial port at 300 baud.
Updating the BIOS and Configuring CPMTOOLS
Now that I have a Gotek bootable Gemini system, I thought that it may be an interesting exercise to see if I could create an 80 track image to give me more storage space. In addition I wanted to be able to use cpmtools (http://www.moria.de/~michael/cpmtools/) manipulate these images as the product works on MacOS and Linux, the two operating systems I use the most.
Before I could even start with the cpmtools utilities I needed to create some definitions for them to make use of. cpmtools can manipulate all manner of CP/M disk formats as long as the format has been defined beforehand.
The disk definitions for cpmtools are located in a text file, the path below shows the Arch Linux and MacOS path, other systems may vary some Ubuntu systems may use /etc/cpmtools/diskdefs.
/usr/local/share/diskdefs
There are several disk formats that can be used with the Gemini e.g.
GEMDDSS: 164K, 35 Track, Single Density, Single Sided GEMDDDS: 340K, 35 Track, Single Density, Double Sided GEMQDSS: 388K, 80 Track, Double Density, Single Sided GEMQDDS: 788K, 80 Track, Double Density, Double Sided
The existing images I have are of the GEMDDDS type, the 80 Track, 788K format I will be creating are of the GEMQDDS type. In order to support these two types within cpmtools, The following disk definitionas should be added to the diskdefs file.
diskdef gemddds
seclen 512
# double sided disk format, 35 tracks * 2 sides
tracks 70
sectrk 10
blocksize 2048
maxdir 128
skew 1
boottrk 2
os 2.2
end
diskdef gemqdds
seclen 512
# double sided disk format, 80 tracks * 2 sides
tracks 160
sectrk 10
blocksize 4096
maxdir 128
skew 1
boottrk 2
os 2.2
end
To create a blank disk image I was expecting to be able to use the mkfs.cpm command (see http://www.moria.de/~michael/cpmtools/), however, this failed to give me a disk that was of the correct size. In the end I used a few snippets of python code to create a file that was 819200 bytes in size, made up of the following. The first 6144 Bytes (12 sectors) were taken directly from the existing bootable 35 track disk image. This simply required some Python to read the 340K disk image into byte array, slicing the array to take the first 12 sectors before writing that to a new binary image. The next 4096 Bytes (8 sectors) are used for the BIOS, this couldn't be taken from the 360K disk image as the BIOS I had did not support the larger capacity 788K drives/disk images.
The source for the Gemini Bios used on my 360K images, was made available by John B. Hanson through the vintage computer section of the UK Vintage Radio Repair and Restoration forum (https://www.vintage-radio.net/forum/showthread.php?t=156106), along with a host of invaluable advice of how to add additional drive support. The BIOS includes a single Disk Parameter Block to support four 340K floppy disks. In the end I decided to keep things simple I would change a few EQU statements and compile the bios to support four 788K floppy disks instead. This was very simple and after assembling and linking on the XBeaver emulator I had the bios in a CP/M binary file (.COM) file. The changes required buffer areas to be changed, however, changing the EQU statements at the beginning of the source, changed the values of the calculated EQU values further down the source making things easy. This binary file was padded out to 4096 Bytes with bytes of 76h (the value 76h was selected as that was the padding value used on the 340K disk images), loaded and appended to the new image with some more Python. The remaining sectors were filled with the value E5h for no other reason than to comply with tradition for freshly formatted disks.
With this complete, the image can be checked with the cpmtools utility fsck.cmp e.g.
fsck.cpm -f gemddds mydisk.img
Note how the -f gemqdds format parameter is used to tell cpmtools how to treat the disk image. From this point forward cpmtools can be used to copy things from one disk to the other e.g.
Get MBASIC from the 340K disk (note that the -f parameter specifies the respective format)
cpmcp -f gemddds mydisk.img 0:MBASIC.COM mbasic.com
Copy the file to the 788K format.
cpmcp -f gemqdds mydisk.img mbasic.com 0:MBASIC.COM
Once complete the image was transferred to the Gotek and the system was booted.
To check the bios disk definitions STAT and DISKINFO can be used (these are both available on the 340K disks posted above). This is the 340K disk image.
A:> STAT A: DSK:
A: Drive Characteristics
2720: 128 Byte Record Capacity
340: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
128: Checked Directory Entries
256: Records/ Extent
16: Records/ Block
80: Sectors/ Track
1: Reserved Tracks
DISKINFO shows the disk parameter block (DPB) from within the BIOS.
A:> DISKINFO A: SPT=80 BSH=4 BLM=15 EXM=1 DSM=169 DRM=127 ALO=192 AL1=0 CKS=32 OFF=1
When issuing the same commands to the 80 track image the following is returned.
A:> STAT A: DSK:
A: Drive Characteristics
6304: 128 Byte Record Capacity
788: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
128: Checked Directory Entries
512: Records/ Extent
32: Records/ Block
80: Sectors/ Track
1: Reserved Tracks
A:> DISKINFO A:
SPT=80 BSH=5 BLM=31 EXM=3 DSM=196 DRM=127 ALO=128 AL1=0 CKS=32 OFF=1
The final disks are here including a disk for serial access to CP/M and a .DMP image for use within the XBeaver emulator.
There is still work to do as I would like to add a SASI hard disk and have a SCSI2SD (http://www.codesrc.com/mediawiki/index.php/SCSI2SD) card for the very purpose, however, I have not yet been able to obtain a Gemini Bios that supports a hard disk. Having said that, there's no rush as 788k disks are relatively large in terms of CP/M and make a very useful system.
IVC Hit by Lightning
During my Gemini journey I was originally thwarted by a faulty GM812 IVC video card which failed a couple of weeks after I purchased the machine in May 2019. This tied in nicely with obtaining a working CP/M disk, except it didn't, as the CP/M version required the IVC Doh! Thankfully, as described earlier, CP/M could be patched to use the serial port for TTY by changing a couple of bytes so I was off and running. However, in parallel with using a serial terminal to talk to the Gemini CP/M, I set about fixing the IVC card.
The effort to resolve the IVC issues took on a whole journey of its own and as a result ended up with its own article. The article can be found here Gemini IVC Problems
Installing T-Net
T-Net is a networking utility written by John B Hanson that provides a network drive on a Gemini system to be connected to a folder on a system such as Linux. T-Net uses a 9600 baud serial connection between the Gemini and the serving system.
On the Linux server, the Xbeaver emulator (see #The_XBeaver_Gemini_Emulator) is run with a fileserver configuration which typically causes the server to listen on a serial tty such as /dev/ttyS0. Gemini clients can then connect to this server using the T-NET command.
The configuration file (fileserver.cfg) used on my Linux systems is as follows...
#XBEAVER network server configuration file #Define as a server file - eg no main processor activity cpuclock 0 board 0x00 serial_extloop 9600 trace tty tty /dev/ttyUSB0 bvrnet /home/john/xbeaver/network echo echo bvrnet file server running - use t-net on the clients to connect
In my case I used a USB to Serial connector on the Linux machine connected via a null modem cable to the serial port on the G811 CPU card. All that was required then was to create the folder that I wanted to be served e.g.
$ mkdir /home/john/xbeaver/network
At this point I was able to run XBeaver as a file server
$ ./xbeaver fileserver.cfg
This reported the followng
Trace tty : Baudrate requested 9600 set 9600 Trace tty : Modem control RTS:1 DTR:1 bvrnet file server running - use t-net on the clients to connect
Back on the Gemini, I simply had to run TNET N which causes drive N: on the Gemini to be mapped to a folder that is being served by the XBeaver application running on the Linux system e.g.
A:> T-NET N
The folder on theLinux system can now be accessed as a network drive e.g.
A:> DIR N:
Troubleshooting
During my experiments with T-Net I had an issue with the built in serial port of my Linux machine. This was determined by some useful debug information provided by T-Net's author John B Hanson that would allow me to check the serial link including the cable and UART.
Once the two systems were connected it was possible to check communication by using GEMDEBUG on the Gemini (see Gemini 80-Bus Resource) and a terminal emulator on the Linux machine, e.g. Minicom.
On the Linux machine run the terminal emulator connected to the serial port to be used, using the settings 9600 baud, no parity, 8 bits, 1 stop bit.
On the Gemini it is necessary to start T-NET and then remove it before using GEMDEBUG e.g.
A> T-NET N A> T-NET R A> GEMDEBUG -
The following GEMDEBUG command sends character 41 on the serial port and this should be seen on the terminal emulator as an upper case 'A'.
-ob8 41
And the following GEMDEBUG command will display the last character received on the serial port, i.e. the last character to have been sent from the terminal emulator.
-qb8
In my case this identified issues when using the built in serial port. By switching to a USB device my problems were solved
More BIOS Updates - Adding a Winchester Disk
Now that the machine can boot to CP/M, I would love the machine to operate with a Winchester disk and perhaps a few more peripherals. I am desperately looking for a later Gemini CP/M bios that supports a hard disk. If you can help, please get in touch.
Rolling My Own Bios
Without a genuine Gemini Winchester supporting Bios, I decided that I would look into what is required to add SASI disk support to to the existing Bios that I have. The list of requirements was quite short. I needed to add a disk system with controller to the Gemini, learn enough about CP/M, in particular the CP/M 2.2 Bios Functions, to add the hard drive routines to the BIOS and last but not least, learn Z80 assembler, so that I can implement the necessary changes. How hard could it be?
One thing that I decided not to undertake, at least initially was to create a bootstrap process that will boot the system using the disk. My intention was to keep things simple to start with and boot to a floppy that recognised the Winchester.
Selecting a Disk System
The Gemini GM829 Floppy controller includes a Floppy Disk Controller (WD 1797), however, to use a hard disk, a separate hard disk controller is required. The GM829 includes a SASI interface that can be accessed from ports C5/C6 or E5/E6, therefore, all that was needed was to add a disk controller that had a SASI interface. The Xebec controller was used on the original Gemini Winchester disk systems and this connected to an MFM hard disk of the period, however, these seem difficult to get hold of. I decided instead, to opt for the SCSI to SD Adapter (SCSI2SD) V5.1 (http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD) as it is able to emulate the SASI interface of the Xebec controller and provides a modern storage medium. I have no idea if this is the best approach but in for a penny... I chose the Miniscribe IV M4010 Winchester 10Mb disk to emulate as this is a disk of the period.
The emulated disk approach is a good compromise for me as it makes use of the Gemini hardware whilst giving me a modern reliable storage system. In addition, if I add CP/M support for the Xebec controller and a real Xebec based disk system turns up, I am good to go... perhaps.
The Interface
The GM829 Floppy/SASI card uses one of two blocks of IO ports, namely ports C0 to C7 or E0 to E7, the specific block used is selected by Link 5 on the card. The normal position for Link 5 is to use the ports at E0-E7 e.g.
E0 - E3 1797 Floppy Controller.
E4 Floppy Drive Density Select/Read Flag.
E5 SASI control (write),
SASI status (read).
E6 SASI data.
E7 Decoded but not used.
In summary therefore, the SASI connection uses 2 byte parallel interface on ports E5 and E6.
Development Environment
In order to make changes to the Bios, I first needed a development environment, this turned out to be very simple in that I used XBeaver with T-Net to point at a folder on my Mac. With this folder defined as the project folder using the Atom editor, I could use the Mac with for editing etc. and M80/L80 on XBeaver to compile. In addition, a git repository was created in the project folder this will be made public once the work is is a usable form.
Disk Organisation
The version of the Gemini Bios I was working with included support for four floppy disks. Within the bios the 'DRIVE' memory location is used to store the current drive (bits 0-3 as well as the density (bits 4-7) as a result, the maximum number of drives that can be supported using this format is four. Adding a fifth drive would have required a rewrite of many parts of the system. As I wanted my changes to have a minimal impact, I opted to reduce the number of floppy drives to two and add support for two Winchester drives maintaining the drive count at four. This allows all of the existing code to work with only a few minor changes and make it easy to determine if the currently selected disk is a floppy or a Winchester.
By taking this approach, the original Gemini code needed only a few minor changes in order for almost all of it to be used for both floppy and Winchester drives. The two most significant changes were;
- add support for different sector sizes for floppy and Winchester disks;
- prevent the Winchester from auto-sensing the floppy density.
With the above changes in place only the final read/write sector routines were swapped for their Winchester counterparts (see #Adding the SASI Commands). All of the disk selection and logging, buffering, buffer in-use checks, flushing and DMA transfers make use of the original Gemini code.
Disk Parameter Tables
The CP/M bios uses a combination of Disk Parameter Headers (DPH) and Disk Parameter Blocks (DPB) to define the disk geometry, directoy entries etc. I had already played with these to upgrade the Bios to use GEMQDDS 788K 80 track disks, however, I had more decisions to make when adding the Winchester support.
Firstly as I was emulating a disk drive with the SCSI2SD I guess I could have picked any geometry I wanted, however, I wanted the system to behave as much like the original as I could so I opted to emulate a Miniscribe 4010 10Mb disk. That gave me the cylinders, heads, sector details. But I still needed to define the maximum number of directory entries for the disk and a suitable allocation block size.
CP/M is able to store a maximum of 65535 records (128 bytes), the maximum value of the random record field of a CP/M file control block (FCB) seems to be the limiting factor. Therefore the maximum disk size for CP/M is 8Mb. If I assume that the average file size is 8Kb, I need 1024 directory entries to fill the disk, This seems to tie in roughly with Gemini's approach as the GEMQDDS 788K 80 track disk provides 128 directory entries.
Each directory entry takes 32 bytes and is stored on the earliest data blocks of the disk, therefore, with 1024 directory entries using 4K blocks, 8 blocks will be used.
The choice of the allocation block size is a compromise between performance/disk usage and, to a degree, bios buffer space. The larger the block size the less the directory needs to be accessed by the disk thereby increasing performance. However, the block size is the smallest a file can be, therefore, a large block size can be wasteful in terms of disk space usage. A further consideration in this case is that the buffer size for the disk allocation map is based on the maximum number of blocks that the can be stored on the disk, the larger the block size, the less space needed for the buffer, more on that later.
Once the disk to be emulated was identified and the allocation block size and number of directory entries were determined (4096, 1024 respectively), it wasw possible to work out the disk parameter header (DPH) and the disk parameter block (DPB) for the Winchester disk and add them to the bios alongside those that exist already for the floppy drives.
The definitions of the values and how they are determined is described in the CP/M Alteration Guide File:CPM 2.2 Alteration Guide 1979.pdf.
Defining the DPH
The existing floppy disk parameter headers for two floppy drives (0 and 1) are defined as follows;
DEFW 0,0 DEFW 0,0 DEFW DIRBUF,DPBLK DEFW CHK00,ALL00
DEFW 0,0 DEFW 0,0 DEFW DIRBUF,DPBLK DEFW CHK01,ALL01
The two Winchester disk parameter headers have replaced floppy disks 2 and 3 as follows;
DEFW 0,0 DEFW 0,0 DEFW DIRBUF,WDPBLK DEFW 0,ALL02 ; no check vector for fixed disks
DEFW 0,0 DEFW 0,0 DEFW DIRBUF,WDPBLK DEFW 0,ALL03 ; no check vector for fixed disks
Points to note are that there is no translation vectors on either disk, they both share the directory buffer (DIRBUF), the Winchester does not have a check vector as this is a fixed disk and each disk has a separate allocation vector.
The buffers were defined as follows
ALL00: ;Disk allocation map floppy ALL01 EQU ALL00+DSM/8+1 ;Disk allocation map floppy ALL02 EQU ALL01+DSM/8+1 ;Disk allocation map Winchester ALL03 EQU ALL02+DSM/8+1 ;Disk allocation map Winchester CHK00 EQU ALL03+WDSM/8+1 ;Check vectors floppy CHK01 EQU CHK00+DIRENT/4 ;Check vectors floppy BUFFER EQU CHK01+DIRENT/4 ;Sector buffer floppy DIRBUF EQU BUFFER+SECSIZ ;Directory buffer floppy
The next buffer in the source code (LBUFF) is defined as follows, leaving 128 bytes for DIRBUF e.g.
LBUFF EQU DIRBUF+128 ;Edit mode buffer
Defining the DPB
The first thing is to calculate the disk size in blocks.
;System Parameters (Miniscribe IV M4010 Winchester 10Mb 2 heads) WBLKSIZ EQU 4096 ;CP/M Block allocation size WSECSIZ EQU 256 ;Physical sector size WDIRENT EQU 1024 ;Max directory entries WMAXSEC EQU 64 ;Physical sectors/track (2*32) WMAXTRK EQU 480 ;Tracks/Disc
Note however that the following EQU will not work in the same way as it does with the parameters for a floppy disk due to the higher numbers involved.
; bad WDSM EQU (WMAXSEC*WSECSIZ/WBLKSIZ)*(WMAXTRK-1)-1
The following hard coded value is used instead
WDSM EQU 1915 ;(WMAXSEC*WSECSIZ/WBLKSIZ)*(WMAXTRK-1)-1
Once we have this, the DPB can be specified e.g.
DEFW WMAXSEC*WSECSIZ/128 ;CP/M sectors/track DEFB 5 ;Block shift factor (4k block) DEFB 31 ;Block mask (4k block) DEFB 1 ;Extent mask (4K blocks > 255 blocks) DEFW WDSM ;Disc size in blocks DEFW WDIRENT-1 ;Max directory entries less 1 DEFB 0FFH ;Reserved directory.. DEFB 00 ;...blocks (AL0/AL1 FF00 = 8 blocks) DEFW 0 ;Check size (none for fixed disk) DEFW 1 ;System tracks
The definitions of each of these values and how they are determined is described in the File:CPM 2.2 Alteration Guide 1979.pdf.
Moving CP/M to Make Room
Adding the extra DPH and DPB tables described above increased the size of the BIOS beyond the space that was available. Therefore, it was necessary to move the CCP and the BDOS down a page or two to allow for the new tables and additional code that is required.
The traditional way is to use MOVCMP.COM utility under CP/M, however, as I was working with disk images it was far simpler to use a little python to shift the CCP, BDOS and Boot Sector code to any address I needed.
I was already using python to build the bootable disk images from hex representations of the CCP/BDOS, the newly compiled BIOS and the Boot Sector code. As I had the original 32K and 64K versions of CP/M provided by John B Hanson, a script was used to compare the two versions and identify each difference. The differences, i.e. the most significant byte of the many jump statements and the CP/M load address in the boo sector code, were then tokenised and stored to disk as hex. This allowed me to build the disk images from the tokenised hex files and add an appropriate bias to the tokens on the fly. This gave me the ability to build disks with CP/M located anywhere in memory I wanted. Nice!
Adding Code for the Xebec S1410 Winchester Controller
Command Block
The Xebec S1410 disk controller is a SASI controller that interfaces the Gemini GM829 disk card with a Winchester disk. The disk controller supports two classes of command, Class 0 relates to the commands used in normal operation e.g. Read, Write, Re-calibrate etc. and Class 7 commands which are diagnostic in nature.
Each command requires a six byte command block to be created appropriate to the operation being performed e.g.
Byte 0 Opcode in bits 0-4 (5-7 = 0 = CMD Class 0) Byte 1 High address in bits 0-4 (5-7 = 0 = LUN See Note) Byte 2 Middle Address Byte 3 Low Address Byte 4 Interleave or Block Count Byte 5 Control Field
Full details is available in the Xebec S1410 Owners Manual see below.
File:Xebec S1410 Owners Manual.pdf
Logical Block Addressing
SASI controllers address the disk using a system referred to a Logical Block Addressing, as opposed to cylinders, heads, sectors etc. This means that a conversion needs to be made when sending commands to the controller. The calculated LBA address forms part of the six byte command block.
The calculation is quite simple
LBA = (Cylinder * Heads per Cylinder + Head) * Sectors per Track + Sector
However by considering each cylinder to be a track things can be simplified. For example with a disk with two heads that has 32 sectors per track, we can treat this as a single sided disk with 64 sectors per track. The calculation then becomes...
LBA = (Track * Sectors per Track) + Sector
Adding the SASI Commands
Once I had slept with the SASI and Xebec Manuals firmly wedged under my pillow I was in a position to create all of the SASI routines I would need to access a Winchester disk. As described above, the standard I/O ports that the controller is mapped to are E5h for the Control Port and E6h for the data port. Looking at the circuit diagram for the GM829 controller, it can be seen that the data port (E6h) is connected to the data bus and the control port (E5h) is connected to the various control signals as follows...
When reading the control port the status bits are as follows
Bit Signal
0 -REQ
1 I/O
2 C/D
3 -MSG
4 -BSY
When writing to the control port the following bits are set/reset
Bit Signal
0 -ATN
1 -SEL
2 -RST
This makes it very easy to program the controller using the protocol described in the SASI and Xebec documentation. See the Gemini 80-Bus Resource page for SASI and Xebec documentation.
Testing the Code
The routines to select the card and read and write the data were coded into a standalone .COM file and tested successfully in the xbeaver emulator. However, when testing the code on the real hardware the code hung. The issue was that when reading the status port value FFh was returned in all circumstances, suggesting that something was wrong with the connection to the controller or the port selection mechanism. It was time to get the logic probe out...
More coming soon...
A Note From the Author
Considering how many of these machines must have been sold, there seems to be very little left out in the wild, as a result, I am very keen to try and preserve the Gemini system.
I still have a lot of work to do and a lot to learn so if anyone owns or has a connection with the Gemini, please get in touch, I would love to talk things through with others and find out more about the company and its history. I can be contacted via twitter @johnnewcombeuk or via the Vintage Computer section of the vintage-radio.net forum (https://www.vintage-radio.net/forum/showthread.php?t=156106)
I would also like to take this opportunity to thank to John B. Hanson and Neal Crook for helping me in so many ways, and others that have added their support via forums and social media.
John Newcombe
Appendix A - PS/2 to Parallel ASCII Converter Wiring Diagram
This is the wiring diagram for the PS/2 to parallel ASCII keyboard converter described in the text. The associated sketch is described here https://bitbucket.org/johnnewcombe/geminikeyboard/src/master/.
IVC Keyboard Connector Arduino Usage
1 ------------------------- VIN
2 ------------------------- Pin 12 STRB
3 N/C
4 N/C
5 ------------------------- Pin 10 D5
6 ------------------------- Pin 9 D4
7 ------------------------- Pin 11 D6
8 ------------------------- GND
9 N/C
10 ------------------------- Pin 7 D2
11 ------------------------- Pin 8 D3
12 ------------------------- Pin 5 D0
13 ------------------------- Pin 6 D1
14 N/C
15 N/C
16 N/C
PS/2 Keyboard Connector Arduino Pin Usage
5V ------------------------- 5V
GND ------------------------- GND
CLK ------------------------- Pin 2 CLK
DATA ------------------------- Pin 3 DATA
Appendix B - Creating an RP/M Hex File
The following Python script will take the binary file MBASIC.COM and create a HEX file suitable for pasting into a terminal emulator. See #Running Some Software.
#!/usr/bin/env python3
LINE_LENGTH = 22 # Number of entries passed to the RP/M monitor per line, should be less than 42.
# 22 seems optimal as it reduces the number of carriage returns issued.
def write_rpm(filename, rawdata):
rpm_file = open(filename, "w")
rpm_file.write("S 0100\r\n")
count = 0;
for byt in rawdata:
rpm_file.write("{0:02x} ".format(byt))
count +=1
if count % LINE_LENGTH ==0:
rpm_file.write('\r\n')
rpm_file.write("\r\n.\r\n")
rpm_file.write("L {0:02x}\r\n".format(int(count / 128)))
rpm_file.close()
if __name__ == '__main__':
# Read the binary file
data = open("MBASIC.COM", "br").read()
# create abyte array
rawdata = bytearray(data)
# create rpm package file
write_rpm("mbasic_rpm.txt", rawdata)
Appendix C - Tape Connector
Tape DIN Connector as viewed from the front of the G811 CPU card.
Input
\ |
Gnd -
/ |
Output
Appendix D - Converting from .DMP to .IMG Format
Python script used to convert from .DMP to .IMG image format.
#!/usr/bin/env python3
DATA_LENGTH = 512
HEADER_LENGTH = 8
def write_raw_interleaved(filename, rawdata):
# create output file
raw_file = open(filename, "wb")
# get sectors from raw data
sectors = list(get_chunks(rawdata, DATA_LENGTH + HEADER_LENGTH))
# write the sectors without the .DMP 8 byte header
for sector in sectors:
raw_file.write(sector[HEADER_LENGTH:])
# all done
raw_file.close()
if __name__ == '__main__':
# Read the binary file
data = open("GM512.DMP", "br").read()
# create a byte array
rawdata = bytearray(data)
# write the .IMG file
write_raw_interleaved("GM512.IMG", rawdata)
Appendix E - Floppy Interface Connections
Shugart Pin Assignments
Pin Name Dir Description --- ---- --- ----------- 2 /DCD --> Disk Change Detect 4 /INUSE A common open-collector LED driver signal? I have never seen this signal used anywhere. 6 /DS3 Device Select 3. 8 /INDEX <-- Index 10 /DS0 --> Device Select 0 12 /DS1 --> Drive Sel B 14 /DS2 --> Device Select 2 16 /MTRON --> Motor On 18 /DIR --> Direction 20 /STEP --> Step 22 /WDATE --> Write Data 24 /WGATE --> Floppy Write Enable 26 /TRK00 <-- Track 0 28 /WPT <-- Write Protect 30 /RDATA <-- Read Data 32 /SIDE1 --> Head Select 34 /RDY --> Drive Ready/Disk Changed
IBM PC Pin Assignments
Pin Name Dir Description 2 /REDWC --> Density Select 4 n/c Reserved 6 n/c Reserved 8 /INDEX <-- Index 10 /MOTEA --> Motor Enable A 12 /DRVSB --> Drive Sel B 14 /DRVSA --> Drive Sel A 16 /MOTEB --> Motor Enable B 18 /DIR --> Direction 20 /STEP --> Step 22 /WDATE --> Write Data 24 /WGATE --> Floppy Write Enable 26 /TRK00 <-- Track 0 28 /WPT <-- Write Protect 30 /RDATA <-- Read Data 32 /SIDE1 --> Head Select 34 /DSKCHG <-- Disk Change/Ready
Gemini GM829 Pin Assignments
Pin Name Dir Description --- ---- --- ----------- 6 /RDY *Drive Select D/Ready line 8 /SECP <-- Index 10 /DS1 --> ) 12 /DS2 --> )Drive Select Lines A-C 14 /DS3 --> ) 16 /MTRN --> Drive Motor Enable 18 /DIRN --> Direction 20 /STEP --> Step 22 /WDA --> Write Data 24 /WRT --> Write Gate 26 /TRK0 <-- Track 0 28 /WPT <-- Write Protect 30 /RDA <-- Read Data 32 /HSLT --> Side Select 34 /DS4 --> *Unused/Disk Select D
- The function of lines 6 and 34 are selected by Link 1. e.g. With B linked to C pin 6 is the fourth drive select line. With A linked to B and C linked to D, pin 34 will be the fourth drive select line and pin 6 will be the drive ready line.
Standard 7 Wire Twist
10 --------. .-------- 10
\ /
12 ----. .---\-/---------- 12
X X
14 ----' `---/-\---------- 14
/ \
16 --------' `-------- 16
Pins 11, 13 and 15 are also twisted, however, all odd-numbered pins are all connected to ground and are not shown here.
Appendix F - IVC Terminal Codes
General
07 Bell 08 Backspace 0A Linefeed 0D Carriage Return
Cursor Operations
1C Cursor left. 1D Cursor right. 1E Cursor up. 1F Cursor down. 1B 3D <Row> <Col> Cursor addressing. 1B 3F Return coordinates and character. 1B 44 Delete cursor. 1B 45 Enable cursor. 1B 59 .. Define cursor type.
Screen Editing
0B Delete line and scroll up. 0E Insert line. 16 Delete character in line. 17 Insert character in line. 1A Clear screen. 1B 16 Delete character in screen. 1B 17 Insert character in screen. 1B 25 Delete to end of screen. 1B 2A Delete to end of line. 1B 5A Return contents of current line.
Screen Format
1B 31 Select 80 wide format. 1B 32 Select 40 wide format. 1B 33 Select user defined format. 1B 46 .. Define user format. 1B 42 Blank screen. 1B 56 Video on (un-blank screen). 1B 49 Video invert screen. 1B 4A Video normal screen. 1B 41 Alternate character generator is default. 1B 4E Normal character generator is default. 1B 4D Memory lock on. 1B 4F Memory lock off
Character Set and Block Graphics
1B 43 .. Define character. 1B 63 .. Define character set. 1B 47 Construct block graphics character set. 1B 48 Duplicate lower character set in upper but invert. 1B 68 Duplicate lower character set in upper. 1B 52 .. Reset point X,Y. 1B 53 .. Set point X,Y. 1B 54 .. Test point X,Y.
Keyboard
1B 66 .. Define function keys. 1B 6B Test keyboard status. 1B 4B Get keyboard character. 1B 58 Get one line of input.
Miscellaneous
1B 57 .. High speed write to display. 1B 4C .. Load user program. 1B 55 Execute user program. 1B 50 Return light pen co-ordinates. 1B 76 Return Version Number
Appendix G - Patching Wordstar 3.0 for the Gemini IVC Card
The following patches can be made to WS.COM in order to support the Gemini IVC Card. All values are Hex.
049B: C3 67 052D: 7F 0649: 1C 00 064B: 65 63 064D: 1D 00 064F: 5B 63 0651: 1F 00 0653: 24 64 0655: 1E 00 0657: 3E 64 0248: 19 50 024A: 02 1B 3D 0253 to 025D: ALL ZERO 025E: 20 20 00 00 00 00 00 00 C9 026D: 02 1B 2A 0274: 01 0B 027B: 01 0E 0284: 02 1B 41 028B: 02 1B 4E 0292 to 02A3: ALL ZERO 02A4: 00 00 C9 00 00 C9 00 00 00 00 02AE: 01 01 02B0: 00 00 00 02D2: 10 0190: 47 65 6D 69 6E 69 20 49 56 43 019A to 01AE: ALL 20
Appendix H - Configuring Turbo Pascal 3.0 for the Gemini IVC Card
The following screen definition provides support for the Gemini IVC card. Enter a minus sign ("-") to set the value to Nothing.
Send Init : N Reset : N Cursor Lead In : $1B $3D Cursor position Command between line/column : Nothing Cursor position Command after line/column : Nothing Column First : N Offset to add to line : $20 Offset to add to column : $20 Binary Address : Y Clear Screen : $1A Clear screen also home : Y Delete Line : $0B Insert Line : $0E Delete to end of line : $1B $2A Low Video : Nothing Number of rows : $19 Number of columns : $50 Delay after cursor address : 25 Delay after Clear, Delete, Insert : 25 Delay after erase to end of line : 25
