*Dear Rod,*
**
*Feeling nostaligic, I googled 'Arcturus Minicomputer', and your letter
below was the only reference I found. I know the letter is from 2007. I
hope the email address is still in use.*
**
*I programmed an Arcturus minicomputer at the Atkinson Morley Hospital in
Wimbledon from 1973 to 1976. It was used to do image processing on pictures
>from the first CT scanner in the world, which was located in that hospital.*
**
*All the programming I did on the machine was in assembler. The computer
did not have a disk operating system. Every action involved first loading
the program you need from paper tape, then the data, etc.*
**
*The first thing I did was to write a very rudimentary disk operating
system. It took 6 weeks, but it worked.*
**
*I knew that Arcturus had installed the monitor system in Gatwick.*
**
*Best Wishes,*
**
**
*Jon Griver*
**
**
**
*Fri Mar 30 02:45:49 CDT 2007*
- Previous message: On topic? Looking for old computer book
<http://www.classiccmp.org/pipermail/cctech/2007-March/037565.html>
- Next message: NeXTstep: cloning a drive
<http://www.classiccmp.org/pipermail/cctech/2007-March/037495.html>
- *Messages sorted by:* [ date
]<http://www.classiccmp.org/pipermail/cctech/2007-March/date.html#37488>
[
thread ]<http://www.classiccmp.org/pipermail/cctech/2007-March/thread.html#37488>
[
subject ]<http://www.classiccmp.org/pipermail/cctech/2007-March/subject.html#37488>
[
author ]<http://www.classiccmp.org/pipermail/cctech/2007-March/author.html#37488>
------------------------------
Hi All
Whilst sitting on the plane on the way back from Newcastle
yesterday. It reminded me of a system I saw at Gatwick airport in the
early 1970's. I'm pretty sure it was run by a mini computer called an
'Arcturus'. I can clearly remember the grey rack mounted box with its
row of toggle switches and lamps. I was there to install a VDU
(sometimes referred to as a glass teletype). The big teletype they drove
it from made the whole place shake and the VDU I fitted of course did
not.
It drove the departure / arrival TV monitors. The way it generated the
characters was curious to say the least. It had a large number of
circuits which generated parts of characters. One did a vertical bar,
another produced a whole circle whilst others output parts of a circle,
forty-five degree bars and so on. For each character cell the component
parts of the required character were selected summed and added to a TV
raster. Does anybody remember the Arcturus?
Rod Smallwood
Google Maps will release a version for the 8-bit Nintendo Entertainment
System. http://www.youtube.com/googlemaps
It appears that the NES has a problem with the cartridge connector.
Michael Holley
Hi. Brand new to this list. I joined because based on your past posts I believe you guys might be able to help me with my problem. I just acquired an old Heathkit system consisting of an H19 terminal, an H11 computer, and an H27 disk drive. I have managed to get the H19 and H11 talking to each other (see my short video at http://www.youtube.com/watch?v=SzZ3HHd1V3o&feature=youtu.be but I don't have any documentation for the H27 so I don't know how to use it with the H11. I have two floppies that came with it (actually I have a bunch that came with it as shown in my photo gallery http://gallery.me.com/rbarline#100619), one titled "Softech UCSD H11 System Disk" and one titled "Softech UCSD System H11 Utilities".
Can anyone help me figure out what to type on the terminal in order to get the disk drive to start the boot process? Thanks in advance.
I've got my OSI C2-4P into a basically working state, to the point where the boot code seeks to track 0 and tries to load the OS boot code.? I know I had a couple of plastic disk-boxes with my OSI boot disks and some software, but I cannot find it anywhere.? I do have some C1 Boot disks, but these won't work with a C2.? If anyone with a working OS65D boot disk (and hopefully the tutorial disks) for a C2/4/8 would be willing to make some copies for me, I'd be most grateful.
I believe it's possible to reconstruct a boot disk over a serial port, but I'd rather keep that as a last resort.? That would be an exercise much like building a ship in a bottle.
Thanks,
Dave
It looks like the developers of TRS-80 Model II TRSDOS were very
paranoid that someone might be able to bypass the filesystem and access
data on a floppy directly. I'm not sure if their primary concern was
file password protection, or if they had other reasons. Obviously you
could write a program that accesses the floppy directly, by talking to
the FDC and DMAC chips yourself, and there's not really anything that
can be done to prevent that.
Oddly enough, this was exactly *opposite* to what Apple did in Apple
DOS. Apple published the APIs to read and write sectors (RWTS), but
never published the "File Manager" APIs that allowed access to the file
system through means other than passing commands through the character
output vector (e.g., the BASIC statement PRINT CHR$(4);"OPEN FOO").
I'll mostly describe how things work in Model II TRSDOS 1.2, the
earliest version I've been able to obtain. I haven't studied 2.0 nearly
as much yet. The TRSDOS 1.2 "kernel" consists of three parts, while
later versions are more monolithic.
The Model II boot ROM loads all of drive 0 track 0 (single density, 26
sectors of 128 bytes) into memory starting at 0e00. First it looks for
the four characters "DIAG" at 1400 and "BOOT" at 1000. If either are
missing, it refuses to proceed. It calls the code at 1404, which in
TRSDOS is a simple hardware diagnostic. When that returns, it jumps to
the first stage boot loader code at 1004. Some other operating systems
don't bother with a diagnostic, and just start their boot code at 1404,
never returning to the ROM.
The first stage boot loader actually understands the TRSDOS filesystem
enough to find the directory entries of files in TRSDOS load module
format, and load them into memory. In 1.2, it loads "IODVRS/SYS" and
then "TRSDOS/SYS", and jumps into the latter. The Model II TRSDOS
filesystem is similar in many regards to that of Model I TRSDOS, but not
enough to actually be compatible. Unsurprisingly, it looks like an
intermediate step in the evolution from Model I TRSDOS to Model III
TRSDOS. As in Model III TRSDOS, files can only have a single directory
entry, with a limited number of extents.
IODVRS/SYS contains, as the name implies, the low level I/O drivers for
the system, including the keyboard, display, printer, and floppy drives,
the dispatching for system (SVC) calls, and a few utility SVCs.
However, it only contains the SVC handlers for services 0-28, the I/O
functions and basic utility SVCs. Note in particular that it contains
no file system code. IODVRS/SYS is conceptually similar to the CP/M
BIOS, though lacking CP/Ms charming simplicity. IODVRS/SYS provides
several undocumented SVCs for internal use by TRSDOS, including floppy
subsystem initialization (13), floppy sector read (14), and floppy
sector write (16). Note that at the time IODVRS/SYS is loaded, no call
is made into it to initialize it.
TRSDOS/SYS, however, is called after being loaded. It basically
performs the TRSDOS initialization that only has to happen at boot
time. It has another implementation of filesystem reading and load
module format handling, very similar to what is present in the stage 1
boot, but now instead of talking to the FDC and DMAC directly, it uses
the undocumented floppy SVCs described previously. After various
initialization, it loads SYSRES/SYS and jumps into it.
SYSRES/SYS contains the filesystem code and other relatively high-level
TRSDOS infrastructure code. It generally relies on SVC calls into
IODVRS/SYS to perform all I/O, and has very little other dependence on
IODVRS/SYS internals. This is conceptually similar to the CP/M BDOS.
It loads system overlays to handle some SVCs and user commands.
Overlays SYS0/SYS through SYS9/SYS are small overlays, occupying one
disk granule (five sectors) and loading into 2200-26ff. Other overlays
may be larger, and load at 2800 or higher. Many of the overlays *do*
depend on knowledge of the internals of SYSRES/SYS, directly accessing
subroutines and data structures without the use of vector tables or the
like. This means that SYSRES/SYS and the overlays must have been built
at the same time, and would generally not be interchangeable with
earlier or later releases.
Anyhow, getting back to the paranoia part. Someone apparently decided
that simply not documenting the SVCs that provide sector-level access to
the floppy was not sufficient to thwart those that might want to bypass
the filesystem. After TRSDOS/SYS uses those SVCs for its part in the
boot process, it actually *removes* them from the SVC vector table, and
sets up jumps to them at undocumented internal TRSDOS locations 1130
(read sector) and 1133 (write sector).
In TRSDOS 1.2, access to all of the system files, including overlays, is
done through the file system. The system files have normal file system
entries. Unlike Model I TRSDOS, neither the system file directory
entries nor the file contents need to be in any special location on the
disk.
In TRSDOS 2.0, things are much more monolithic. The stage 1 boot code
only loads and jumps into a single file, SYSRES/SYS. The boot code does
not care where this file is located, but other parts of the system do.
All of the overlays, small and large, are stored in a single file,
SYSTEM/SYS, which is required to start on the track after the primary
directory. The first sector of SYSTEM/SYS contains a kind of overlay
directory that gives the track and sector numbers at which each overlay
starts.
There is perhaps some advantage to putting all of the overlays in a
single file, since the number of directory entries on the diskette is
limited to 96. However, the need for a second, special directory
mechanism for overlays is ugly, even if it is only a simple one.
Requiring the system files to be at fixed locations on the disk (at
least relative to the primary directory) might be a reasonable
requirement if it yielded some performance gain, but it generally
doesn't. (With 1.2, the system files are set up when the disk is
formatted, so even though they *could* be anywhere, in practice they are
grouped together.)
TRSDOS 2.0 introduced changes to the disk organization, such that TRSDOS
1.2 and 2.0 diskettes are not interchangeable, except that the 2.0
XFERSYS utility can convert a 1.2 diskette to 2.0 format. The disk
organization changes are basically gratuitous, and don't provide any
benefit to the user, while obviously being a great inconvenience to
users with TRSDOS 1.2. They mashed the GAT (granule allocation table)
and HIT (hash index table), which were sectors 1 and 2 of the directory
track in 1.2, into just sector 1 in 2.0. In 1.2, the directory occupied
sectors 3-26, while in 2.0 it occupies sectors 2-25. The only apparent
rationale for doing this is to free up sector 26 on the directory
track. In TRSDOS 1.2, sector 26 was not used on any track but the
directory track, for any purpose. In TRSDOS 2.0, sector 26 of *every*
track is used to store five bytes of unique disk ID, to better detect
disk changes. (it has been suggested that those bytes might also have
been used for software copy protection.) However, rather than mashing
the GAT and HIT together, which made it impossible to support larger
disks such as double-sided disks, they easily could have special cased
the directory track(s) and stored the disk ID in either the GAT or HIT
sector.
TRSDOS 4.0 introduced much larger changes to the disk organization, in
order to support double-sided disks and hard disks. I haven't yet begun
to dig into the 4.0 code.
Eric
Hi
I have ten (10) remaining S-100 MS DOS Support board PCBs left in case
anyone would like one or more.
http://s100computers.com/My%20System%20Pages/MSDOS%20Board/MSDOS%20Board.htm
This board should dramatically improve MS DOS compatibility on the S-100 bus
using an S-100 8086 CPU board.
It can be used by any 8 or 16 bit CPU. Basically it is the guts of a PC/AT
motherboard minus the CPU, RAM, and ISA slots.
Thanks and have a nice day!
Andrew Lynch
{revision of first CCTalk post on 3/22/12}
Thanks to those who have been inquiring on these items,
I can now render a more helpful post.
Location: Washington, D.C., or near Frederick, Maryland.
For trade (preferred) or best offers:
- 1974 DG Nova 2 rackmount (untested, unrestored) top cover missing
.Front panel (cosmetics very good condition)
.Nova 2 CPU
.Standard Memories 16k core
.Basic I/O
-- all electronics working condition unknown, but appear
undamaged in very good condition.
- 1971 DG Nova 1200 rackmount (untested, unrestored) w/ all covers.
.Front panel (cosmetics -- fair condition)
.Nova 1200 CPU
.DG 4k core
.Basic I/O
-- all electronics working condition unknown, but appear
undamaged in very good condition.
- 1984 DG Desktop Generation R20 (untested, unrestored) w/ D461 terminal
.dual power supply unit
.R20 SPU unit with SPU, 256k ram, USAM, and asynch modules --
(note: no terminal cables or adapters.)
.single drive diskette unit
.hard drive unit
.tape drive unit
.manuals (setting up, testing, users in 2 encased binders) and
3 diskettes.
-- all electronics working condition unknown, but appear undamaged
in excellent condition.
-- cosmetics, very good to excellent.
PM me with trades, offers, questions, corrections.
Looking for (in order of priority):
- PDP 11/04 or 11/34 half-height (only) chassis, complete with PSU,
covers, backplane, cables. No CPU or other logic boards needed.
- HP 35721A monochrome monitor
- Emulex TC12 tape controller or similar: Unibus->Pertec interface
which emulates a "TS" device
- ribbon cables for above -- controller -> Pertec-formatter tape drive.
- Unibus ESDI controller
- Pro/Venix docs (I'm using version 1.0 on a DEC Pro 350).
- MFM drives:
. CDC Wren II 9415-*
. CMI CM-5412
. IMI 5012H
. Maxstor XT-2085
. Micropolis 1324A
. Priam V170 or V185
Thank you,
John Singleton
p.s. to check my reputation, see my ebay handle "MdntTrain".
On Thu, 29 Mar 2012 19:57:58 +0100 (BST), ard at p850ug1.demon.co.uk (Tony
Duell) wrote:
> Which has just suggestesd a totally OT queestion to me. Some cultures
> prohibit the drinking of alcohol. This is normally taken to mean drinks
> containing ethanol. But how do they handle other -OH molecules in foods?
Those cultures, and their rules prohibiting the drinking of alcohol, are
quite old AFAIK. Without knowing any details of their history, it would
seem logical to me to assume that they would not be aware of the
presence of other -OH molecules, so they would have no special rules
about them. I suppose the rules are religious? If so, some of them may
well be reasonable for health reasons, but others would be illogical or
based on misconceptions of physical facts.
/Jonas
