Image Map Image Map
Page 1 of 6 12345 ... LastLast
Results 1 to 10 of 56

Thread: CP/M question...

  1. #1
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    692

    Default CP/M question...

    Andy Laird of the "cp/m handbook " states that:

    ....hardware designers arrange for some initial instructions to be forced into memory at
    location 0000H and onward. It is this feat that is like pulling yourself up by your own
    bootstraps. How can you make the computer obey a particular instruction when there is
    "nothing" (of any sensible value) inside the machine?

    There are two common techniques for placing preliminary instructions into
    memory:

    1- Force-feeding

    With this approach, the hardware engineer assumes that when the RESET
    signal is applied, some part of the computer system, typically the floppy
    disk controller, can masquerade as memory. Just before the CPU is unleashed,
    the floppy disk controller will take control of the computer system
    and copy a small program into memory at location 0000H and upward.
    Then the CPU is allowed to start executing instructions at location 0000H.
    The disk controller preserves the instructions even when power is off
    because they are stored in nonvolatile PROM-based firmware. These
    instructions make the disk controller read the first sector of the first track
    of the system diskette into memory and then transfer control to it.

    2- Shadow ROM
    .....

    Now this Force Feeding business is kinda Chinese to me. Can
    some of the folks here explain how it is possible to shut up CPU at
    time zero and let FD controller to take over?

    ziloo

  2. #2

    Default

    Reading it, it looks the same as shadow ROM in effect, because you have the boot code in an EPROM. The only difference is it is copied into RAM (per DMA) by the FDC - but it would need to hold the CPU in reset while doing so. That answers your specific question - the FDC or another chip with a known initial state keeps the CPU in reset while copying the boot code to RAM, then releases the reset line so the CPU can run it. For example, the Superbrain does this (holds a CPU in reset) for CPU2 using a line of the PIA chip at cold boot (although not to copy stuff into RAM).

    "Force feeding" seems a bit over engineered to me. Which FDCs have this ability?

    Shadow ROM (or paged, switchable ROM) is far a more common approach in my (admittedly limited) experience.
    Last edited by JonB; November 2nd, 2017 at 10:13 AM.

  3. #3

    Default

    Of course, "2- Shadow ROM" is pretty much the universal solution these days, and even for older, CP/M-era, machines. But some computers would "halt" or "hold" the CPU (effectively stop the clock) until the floppy (or other I/O) completes it's "bootstrap" command. In those cases, the I/O device would need to have DMA capability, as the CPU cannot be involved in the I/O if it has no code to run. In some cases, such as the Honeywell 200/2000 mainframes, it is a fairly manual process - the CPU powers up "halted" and the operator mounts the I/O device and starts the bootstrap operation (loads the code to run), then releases the CPU to run the code that was loaded. I think there were some "specialty" PDP-8 systems (dedicated word-processors, etc) that worked in a more-automated fashion. In those cases, when you power-up, the CPU is held idle until the floppy controller can read the bootstrap sectors. It will wait forever for you to insert the diskette, and if that is bad or not "bootable" then the hardware keeps looping - never releasing the CPU.

    I think even some modern CPUs have similar capabilities, especially for embedded use. But with ROM being so inexpensive these days, it doesn't make much sense to add extra hardware to enable a bootstrap function on an I/O device.

    The Z80 had a couple methods for this, one was the WAIT signal, which could be applied by I/O bootstrap logic on the initial instruction fetch from 0000H. Another was the BUSREQ/BUSACK logic (used by DMA devices), which I presume one could make work for that. I'm not aware of anyone ever doing either of those, though.

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,042
    Blog Entries
    20

    Default

    I think Andy was thinking of things like Don Tarbell's floppy controller. It has a small bipolar ROM in it that loads the first sector of a disk into memory and jumps to it; said ROM program forces its contents onto the data bus at location 0 after reset, during which a sector is read into 0000-0080h, with the controller managing the bus. When the read is finished, a jump to 007DH is performed and the ROM no longer appears on the bus.

    There's a copy of the Tarbell disk document on bitsavers.

    Right from the very first Altair S100 spec, there is a signal called STSDSBL (or something like it) on pin 18, which disables (tristates) the MPU's status drivers. Assert this signal and take control of the bus yourself.

    If you have a ROM in high memory, there are two approaches to getting the MPU to go there after a reset. One is to force a jump instruction onto the bus at reset (not that much different from the Tarbell scheme, above); the other is to force 00 (no-ops) onto the bus, using a comparator to check the address the MPU thinks it's reading from and then releasing the bus when the target has been reached.
    Last edited by Chuck(G); November 2nd, 2017 at 10:19 AM.

  5. #5
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    3,367

    Default

    And, the most forceful of the "force feeding" techniques: clobbering MREAD with a transistor to ground or some paralleled bus drivers and causing an intentional bus conflict to effect power-on jump! Despite having built the status disable line into the bus spec, this is the method that the MITS Turnkey board uses, as well as at least the TDL SMB and SMB 2.

    From the description, "force feeding" sounds more like DMA. There were certainly floppy controllers that could do DMA, such as the Morrow Disk Jockey DJDMA. Never personally used one, so I don't know if they also DMA in the bootstrap code.

    Shadow ROM could use the above (either intentional bus conflict or properly using the status disable line), the *PHANTOM line if system memory supported it, or bank switching if the system supported it. There were also CPU boards that could jam a JMP onto the bus by just disabling external transceivers, or switch in an onboard ROM. Using the *PHANTOM line (which, when pulled low, tells memory boards that acknowledge *PHANTOM to not respond to the bus cycle) sounds like the "masquerading" part of the "force feeding" description. But that's also how Shadow ROM can work, so who knows what the exact intention was...

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,042
    Blog Entries
    20

    Default

    The cool thing about Tarbell's design is that it worked on almost any system, z80 or 8080. You can see what's going on--he's got a 74LS367 driving the STSDSBL line as well as the now-floating status lines. What I thought was unusual was that Tarbell's boot code is storing data into the same addresses that it's executing from--0000-0080h.

  7. #7
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    3,367

    Default

    Quote Originally Posted by Chuck(G) View Post
    The cool thing about Tarbell's design is that it worked on almost any system, z80 or 8080. You can see what's going on--he's got a 74LS367 driving the STSDSBL line as well as the now-floating status lines. What I thought was unusual was that Tarbell's boot code is storing data into the same addresses that it's executing from--0000-0080h.
    IIRC I've got at least one board that does that, so that you can copy the ROM contents into real RAM at 0x0000 as part of the bootstrap. Forget which.

    The Dajen SCI took the proper approach to power-on jump with disabling the status lines and driving them itself. I don't know why more boards didn't use the approach early on, there was no reason to clobber MREAD like that!

  8. #8

    Default

    I have one of the early disk systems, made by "Digital Systems". On reset, it would take over
    the processor ( forget which line it uses ) and DMA load the disk's first sector into RAM at address 0.
    Assuming one had a front panel, one would wait for the disk light to go out and hit RUN.
    CP/M likes to use 0 to 100H so the low level disk I/O can then be loaded by the bootstrap program in
    the first few bytes.
    Once clear of 0 to 100H, loading CPM is no issue.
    I know how it works because it came with no software and I had to get it up and running myself.
    All normal disk accesses are done by DMA so that the additional hardware to handle bootstrap reset is
    minimal, from a design aspect.
    Most later disk controllers used a shadow ROM. These usually have the ROM mirrored in two locations. The
    first bit of code jumps to the normal ROM address. The act of addressing the normal address flips a flop
    that was cleared on reset to enable the shadowing.
    This is less complicated with the standard disk controller chips than doing the DMA load. The DMA
    load has the advantage that when the boot is complete, there is no need for any ROM in the memory
    address space. One can use 100% of the RAM ( or at least that part not used by some video boards
    and disk I/O ).
    One can always restart CP/M to get back to normal usage.
    Dwight

  9. Default

    The Amstrad PCW uses a variant of the force-feeding technique -- at startup, memory fetches come from the printer controller, which emits 779 bytes (instructions and data reads). The CPU executes these to generate a 256-byte program in RAM. That program then reads the first sector from disc, and jumps to it.

  10. #10

    Default

    I've seen a lot of different ways of mapping in a "bootstrap" ROM. One was to repeatedly map the ROM (which was ORG'ed in high memory) over the entire address space, then the JMP at 0000H would jump to the desired "high memory" address, then they'd usually copy the ROM to RAM (employing a "write under ROM" circuitry) and turn off ROM mapping. The Kaypro mapped (and ORG'ed) the ROM at 0000H and then after booting it disabled the ROM, and used a CP/M BIOS that switched the ROM back on for doing I/O (after making special arrangements for the user data to be copied into high memory). The H89 supported CP/M as an after-thought, and their ROM (mapped/ORG'ed at 0000H) was never used again after CP/M was booted (but was used directly for HDOS - which does not use low memory). I seem to recall some that would lock-out the ROM once you booted CP/M (requiring hardware RESET). I've never seen one that actually had a ROM in an I/O device, then transferred that ROM as an I/O command. That would be an interesting approach, and perhaps was needed to integrate into existing hardware. You still need to halt the CPU until the I/O completes, but perhaps it got away from requiring a diskette be inserted. There are probably as many different ways of doing this as there are different machines.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •