On Aug 8, 2014, at 6:39 AM, Dennis Boone <drb at msu.edu> wrote:
Do any of
y'all know if documentation and/or software for this
interesting-looking beast exists out in the wild? Does it require a
boot disk to do things other than BASIC, like a PC would?
These were small business DP systems. Hardware-wise, the line included
a desktop model, a deskside model, a shared hard-disk unit, several
printers, a network option in the megabit range that utilized thick
twinax cable and (iirc) a star topology, a serial communications (for a
modem) option, and likely other things. Screens were high persistence
green phosphor, with at least two intensities for text. I don't
remember point addressable graphics. Keyboards were IBM-style buckling
spring; as I recall the layout was slightly unique. Floppies were 8",
fairly capacious, reasonably quick, quite reliable. Printers were big,
fast, dot matrix, top mounted tractor feed. I think at least one model
included a multi-pass NLQ mode. Draft mode was IBM-esque, with dotted
zeros and an odd diagonal 'S' character. Construction is pure IBM, with
reliability and serviceability in spades.
The differences in the systems were just in the shared storage (floppy or
eventual hard disk). All of the compute was in the "head".
I haven't seen electronic stuff online. I have
paper docs for a couple
of models and some of the options, as well as not-yet-imaged floppies
containing diagnostics. I do intend to get them scanned/imaged
eventually, I swear. Strong need and urgent pleas for specific things
may add motivation. :)
If I recall correctly, the "library" was 23 volumes.
No boot disk is required. A fair amount of the available software was
actually written in BASIC. At least a few utilities were compiled or
assembled binaries, but as far as I recall, even those were not booted
from floppy.
As I recall, the CSFs were binaries that were loaded off of floppy.
The BASIC is an extremely capable business type, with forms, file/disk
handling, ISAM type functionality, etc. It was even possible to do
serial communications over a modem with it reasonably well, other than
some limitations in keyboard handling. I'm not sure if adding the
network and remote disk added code on adapter cards to support those
things, or if the support was in the base unit firmware.
I know that the external floppies were supported in the ROM as shipped.
I don't recall how the support for the HD was done. The ROM *was*
patchable but I doubt that entire device support would have been done
that way.
My guess (from 35+ year old memory) is that there was code on the
I/O card that handled the actual low level operations of the disk.
The weight of 90 lbs for the desktop unit is not a joke. Besides being
built like an IBM product, those 8" floppy drives are stout, and
constitute a significant chunk of the mass.
I don't recall them being quite that heavy. But I was a lot younger then. ;-)
And the reality was that we didn't move them around much. We just had
labs *full* of them (20-30 each). Even then we had to schedule time to
use/debug one.
I've not dug far enough into my desktop unit to read the markings on the
CPU chip, but a few bits like register layout shown in the maintenance
documentation match the 8085. I'm pretty sure these systems use a paged
memory layout, at least for the firmware. It's the only way they could
provide all the functionality that's in there.
Yep. It's an 8085. There was paging hardware (and some cool low level
SW to go with it). As I'm thinking about it now, I think it was 16K pages.
A fixed code page, a fixed data page, a variable code page and a variable
data page.
The memory/page management was all done at a low level and the majority
of the rest of the code didn't really know the details. Memory was allocated
as "objects" and you got a "handle" to an object. You could then get
a physical
mapping of the object. Which you needed to do anytime you wanted to
manipulate the contents of the object. To prevent fragmentation (and to make
sure there weren't memory leaks) garbage collection was done. So if the
code did any sort of memory operation, you had to re-evaluate the physical
address of the object because it could have been moved in memory.
In the code, you could explicitly free an object but the garbage collector would
reclaim any object that didn't have a reference to it. I remember that there was
a trick to prevent a newly allocated from being immediately reclaimed if the GC
ran before the object was referenced from something else. Too long ago to
remember the details.
Damn, it's all starting to come back now.
TTFN - Guy