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:
Returns attribute status for a file or directory |
|
Mount/Unmount the SD Card |
|
Display a catalog of the current SD Card directory |
|
Change the current SD Card directory |
|
Like the normal CHAIN command, but for the SD Cadr |
|
Close an SD Card file |
|
Copy an SD Card file to another SD Card file |
|
Returns the current SD Card directory |
|
Delete an SD Card file |
|
Test an open SD Card file for End Of File |
|
Set the End Of Line character sequence |
|
Return the End Of Line character sequence |
|
Test an SD Card file for existence |
|
Initializes reading a directory |
|
Flush any un-written data to an open SD Card file |
|
Iterative reading of directory entries |
|
Returns the path for the root directory |
|
Load a program from the SD Card |
|
Load a binary program from the SD Card |
|
Make a new directory on the SD Card |
|
Display a text file, with pagination |
|
Open an SD Card file |
|
Return a piece of a path |
|
Read from an SD Card file, End Of Line aware |
|
Read from an SD Card file |
|
Rename (and/or move) an SD Card file |
|
Delete a directory on the SD Card |
|
Save a BASIC program to the SD Card as ASCII text |
|
Position the read/write pointer for an open SD Card file |
|
Returns the size of an SD Card file |
|
Set the path separation character |
|
Report the path separation character |
|
Store a BASIC program as a LIF file on the SD Card |
|
Store a Binary program as a LIF file on the SD Card |
|
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.