25 Dec
2010
25 Dec
'10
5:11 p.m.
Date: Sat, 25 Dec 2010 15:38:05 -0500
From: dmabry at mich.com
To:
Subject: Re: C64-C128 CP-M Cartridge Interest
dwight elvey said the following on 12/25/2010 10:30 AM:
Hi Dave
I think you are correct. It has been a long time since I booted an MDS800.
Still, it is well documented that the early Kildall's machines used Torode's
disk controller that would DMA the first sector into RAM on reset.
This was before he had a MDS800 as was used for later versions of
CP/M. I would guess that Kildall's first machines had no ROMs in them
at all.
Dwight
---snip---
Hi
I suspect that the reason for this may have been that the original
CP/M was done on computers with 0 based RAM and methods to
load code at 0 on boot.
I don't recall how the MDS800s did this but I do know that early
work on CP/M was done with one of Torode's early controllers.
These were DMA and had there own state machine that
could auto transfer the first boot sector into RAM on reset, independent
of what processor was in the machines.
I have one of his later controllers in my IMSAI and that is how it
works.
Adding hardware to do the ROM/RAM transfer on boot is relatively
easy with the addition of a 7474. Most machines decode a I/O
address. You use the first I/O to toggle the 7474 and that turns
on the RAM and the ROM off. Reset is connected to the 7474.
Most ROM and RAM boards use some type of comparator to
determine the addess ( a 74688 was what I recall ). Normally
the input was tied to ground. This could be tied to the 7474.
On newer boards, there was the phantom signal.
The boot ROM would transfer all the needed ROM to RAM
and then switch to all RAM.
Dwight
While I remember, at least I *think* I remember, I'll fill in one
question here. The MDS800 had a switch on the front panel called
"boot." When in the up position it switched a small EPROM (1702) into
low memory that had the initial boot code in it. That was enough to
load the first track of the floppy disk into RAM. That boot switch only
affected the *read* cycles. *Writes* were still deposited into the RAM
at low memory.
Once the boot code from the disk was read into low RAM the execution
from the 1702 went into a tight loop waiting. There was an indication
of that in an LED on the front panel, INT2 as I recall. The user would
toggle the "boot" switch and execution would continue but now from the
ram that was just loaded. The boot process would finish by bringing in
the operating system from the disk, either ISIS-II, CP/M, FORTH, or
whatever you were using.
Pretty sure I remember that correctly. Wish I never sold mine. It was
definitely a classic!
Dave