Disk, Tape and SD Card Storage

EBTKS provides emulated Disk and Tape storage.

Emulated means that there is no actual physical Disk or Disk drive, and no physical Tape or Tape drive. Instead, EBTKS uses a combination of software and hardware on the EBTKS board to create a storage system that from the point of view of a person writing programs on a Series80 computer, and also from the point of view of the built- in software of the Series80 computer, standard commands that access Tapes and Disks operate as if there was one or more Disk Drives and/or a Tape Drive. Neither the standard built-in software or user program can tell that real disk and tape is not connected to the Series80 computer. Configuring the emulated Disk and emulated Tape is done in the CONFIG.TXT file that is located in the root directory of the SD Card that is plugged into EBTKS. The configuration can include disabling the facility, if for example you have a functioning Tape Drive on an HP85A/B.

EBTKS can also co-exist with real Disk Drives, connected via an HPIB module. The only requirement is that the HPIB module select code (default is 7) does not match the select code used by EBTKS (default is 3). Thus, using the standard EBTKS configuration together with a real floppy Disk Drive, the following CAT commands can access both.

Command

What happens

CAT

Display the catalog of “:D300”, an emulated drive on EBTKS

CAT “:D300”

Display the catalog of “:D300”, an emulated drive on EBTKS

CAT “:D700”

Display the catalog of the first real floppy Disk Drive

CAT “:T”

Display the catalog of the emulated Tape Drive on EBTKS

EBTKS can emulate multiple disk drives concurrently, and at most, one Tape Drive.

SD Card Storage using FAT32

Separate from all of the above emulated Disk and Tape storage, EBTKS also provides its own native hierarchical storage on the SD Card, implemented as a FAT32 file system. Unlike the restrictive filename rules that the Series80 computers typically use, EBTKS FAT32 file names can be any length (over 60 would be silly), and this is also true of subdirectory names. There is no practical limit to the depth of subdirectories. The SD Card provides 16 Gigabytes of storage. The FTA32 file is accessed with new keywords provided by the AUXROMS that are part of EBTKS. Follow these links to learn more:

SDATTR

Returns attribute status for a file or directory

SDCARDMOUNT

Mount/Unmount the SD Card

SDCAT

Display a catalog of the current SD Card directory

SDCD

Change the current SD Card directory

SDCHAIN

Like the normal CHAIN command, but for the SD Cadr

SDCLOSE

Close an SD Card file

SDCOPY

Copy an SD Card file to another SD Card file

SDCUR$

Returns the current SD Card directory

SDDEL

Delete an SD Card file

SDEOF

Test an open SD Card file for End Of File

SDEOL

Set the End Of Line character sequence

SDEOL$

Return the End Of Line character sequence

SDEXISTS

Test an SD Card file for existence

SDFFIRST

Initializes reading a directory

SDFLUSH

Flush any un-written data to an open SD Card file

SDFNEXT

Iterative reading of directory entries

SDHOME$

Returns the path for the root directory

SDLOAD

Load a program from the SD Card

SDLOADBIN

Load a binary program from the SD Card

SDMKDIR

Make a new directory on the SD Card

SDMORE

Display a text file, with pagination

SDOPEN

Open an SD Card file

SDPATH$

Return a piece of a path

SDRDLINE

Read from an SD Card file, End Of Line aware

SDREAD

Read from an SD Card file

SDREN

Rename (and/or move) an SD Card file

SDRMDIR

Delete a directory on the SD Card

SDSAVE

Save a BASIC program to the SD Card as ASCII text

SDSEEK

Position the read/write pointer for an open SD Card file

SDSIZE

Returns the size of an SD Card file

SDSLASH

Set the path separation character

SDSLASH$

Report the path separation character

SDSTORE

Store a BASIC program as a LIF file on the SD Card

SDSTOREBIN

Store a Binary program as a LIF file on the SD Card

SDWRITE

Write to an SD Card file

Disk Drive emulation

EBTKS currently emulates 1 HP 82937A HP-IB interface. There can be a number of disk devices each with a maximum of 4 disk drives using the AMIGO protocol.

Each emulated disk drive uses a disk image file stored on the SD card.

There are no changes required on the HP85 side software wise - for all intents and purposes, the HP85 thinks it has a ‘real’ HP-IB card and peripherals.

The select code can be set via configuration in the CONFIG.TXT file that is loaded at boot time.

The emulation is fairly simplistic and only implements the bare minimum to ‘work’. Currently status reporting is not fully implemented. The disk image file format is identical to the one used by Everett Kaser’s emulator - basically a sector by sector image stored in a file.

No benchmarks have been done to compare the performance relative to a ‘real’ disk drive - I would expect it to be significantly faster - no mechanical movement is required, the burst transfers are not throttled and there is no ‘real’ HP-IB to speak of. Many operations appear instantaneous.

There is plenty of scope for improvement - the first would be to complete the AMIGO emulation to give proper status reporting. Then SS/80 might be the next step.

Currently we’ve been using the mini-floppy (82901/9121) as most of the available disk images are for this format, and 5 MB hard disks (emulated winchester disk drives). EBTKS also supports (but not yet tested) emulation of 8” floppy disks.

For those that want to delve into the code:

HPDisk.h has the class that implements a single disk drive. The mapping of tracks/sectors for the disk drive types is done here.

HPIBDisk.h has the class that implements a disk drive device. It has a collection of HPDisk objects (up to 4 - HP s/w limitation) and forms the virtual HPIB device. The AMIGO protocol is implemented here.

EBTKS_1MB5.cpp is where the virtual hardware HPIB interface is implemented. The 1MB5 translator chip and the Intel i8049 processor (the HP custom chip and microprocessor used in the real interface) are emulated - but not completely. Only the bare minimum is done - the goal was a functional implementation rather than a cycle and function perfect emulation. Up to 31 instances of the HPIBDisk class are supported.

The basic hierarchy:

                                      EBTKS_1MB5
                                          |
                  +-----------------------+--------------------+
                  |                                            |
              HPIBDisk0                                    HPIBDisk1
                  |                                            |
   +---------+----+----+---------+              +---------+----+----+---------+
   |         |         |         |              |         |         |         |
HPDisk0   HPDisk1   HPDisk2   HPDisk3        HPDisk0   HPDisk1   HPDisk2   HPDisk3

The code has functions that emulate the 1MB5 hardware registers that are called via the bus Interrupt Service Routine (ISR). The emulation is split between the real-time functions (responding to ISR events) and the non-realtime processing (which represents the bulk of the work) and is processed in the main background processing loop. Due to this, the interface is rather complex due to the operation of the 1MB5 - there’s interrupts, acknowledges, burst transfers and timing sensitivities. Tread carefully if you want to modify this! As well, the code cannot block as there are other tasks in the background loop that may need attention.

If you’re feeling adventurous and like a challenge - there’s always the possibility of writing a new ROM to implement the filesystem directly on the SD card and avoid the HPIB/AMIGO stuff.

The emulation does not create blank disks. Instead we copy a reference file that has the required initialization to achieve this, using the MOUNT command.

Tape drive emulation

Like the disk drives, the tape is a functional emulation. i.e. it doesn’t attempt to precisely mimic a real tape. It does enough to keep the HP85 code happy to think it has a tape unit. The tape emulation file format is identical to Everett Kaser’s HP emulator. This mimics the real tape as an array of bytes with flags to emulate the tape drive motor tachometer slots. Due to this the file is 800k or so bytes for a 120 KB tape. On the other hand, we have 16 GB of storage on the SD Card.

Due to the emulation method, the emulation is faster than the real one, but we still have to traverse the virtual tape so it is not much faster. Like the real tape drive, the CRT is blanked while the virtual motor is moving the virtual tape past the virtual read/write head. We do not implement a virtual failed capstan rubber roller, or a virtual failed tape cartridge drive band.

The emulation uses a windowing method where a block of tape data is loaded into and out of memory from the SD card file. As the tape is traversed, the required block is loaded. This is done to preserve the amount of ram required for the tape emulation.

The emulation does not create blank tapes. Instead we copy a reference file that has the required initialization to achieve this, using the MOUNT command.

No write protection is implemented. The emulation hasn’t been exhaustively tested - especially with the corner cases like a full tape and extensive file operations.

We don’t expect much interest in the tape - once you have disk functionality, the tape becomes a historical curiosity. Which is kind of sad, given that tape emulation was the original purpose of EBTKS.

The code for the tape emulation is in the file EBTKS_Tape_Drive.cpp

The CRT blanking during Tape operations is built into the HP85 system ROM code. HP did this to reduce the load on the power supply.