Image Map Image Map
Results 1 to 9 of 9

Thread: IMSAI 8080 / RAM17 / NorthStar / VSG / 88-2SIO and CP/M

  1. #1

    Default IMSAI 8080 / RAM17 / NorthStar / VSG / 88-2SIO and CP/M

    Hello all.

    Back at it. Trying to get IMSAI 8080 system running both Northstar DOS and CP/M.

    My system is:
    - IMSAI 8080 with original CPU card.
    - 88-2SIO board which features two serial ports (Altair style) and a monitor ROM.
    - Just got Godbout RAM 17 w/ 64K, currently top 16K is disabled
    - NorthStar Disk Controller, with a VSG in-line

    I was using 6 x 8K RAM cards that were problematic. So I just picked up a new to me 64K RAM card which is awesome to replace the 384 RAM chips that made up the 48K before (which was never fully working.)

    Last time I messed with it, I was able to use the monitor ROM on the 88-2SIO to write out two copies of Northstar DOS and two copies of CP/M which are already setup for 48K/88-2SIO/Northstar disk controller (yay Deramp!)

    The Northstar DOS disk boots... but CP/M just hangs.

    I do notice that when I have the RAM17 in, I can no longer front panel examine RAM locations. Also, it seems like the system is always forced to the jumpstart address for the ROM monitor on the 88-2SIO.

    I have tried various combinations of dip switch/jumper settings, including enabling and disabling the phantom signal on both the RAM17 and 88-2SIO. I've changed the pair of DIP switches on the RAM17 to turn on front panel memory writes and turn it off. But as far as I can figure, the examine next type stuff is a read operation.

    I turned off the jumpstart function on the 88-2SIO thinking that it's just always forcing it's start address somehow and that is blocking the examine next -- but the EPROM becomes inaccessable with that off.

    Any thoughts?

  2. #2
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,882

    Default

    Quote Originally Posted by telemonster View Post
    I do notice that when I have the RAM17 in, I can no longer front panel examine RAM locations. Also, it seems like the system is always forced to the jumpstart address for the ROM monitor on the 88-2SIO.
    I didn't realize you have a RAM17 -- I still have your RAM16, haven't finished wire wrapping a replacement for it.

    The RAM17 is an IEEE-696 board and grounds S-100 pins 20 and 70. This disables all of the one-shots on the IMSAI front panel, since the IMSAI panel is pre-696. You can put some thin tape over pins 20 and 70 (they're opposite each other, front and back) on the RAM17 for testing, or just cut the lines to them near the edge connector.

    Additionally, you need to disable the RAM that overlaps with your disk controller. Typically I just switch off the entire 8K block from 0xE000 - 0xFFFF. The manual covers that.

  3. #3

    Default

    Quote Originally Posted by glitch View Post
    I didn't realize you have a RAM17 -- I still have your RAM16, haven't finished wire wrapping a replacement for it.

    The RAM17 is an IEEE-696 board and grounds S-100 pins 20 and 70. This disables all of the one-shots on the IMSAI front panel, since the IMSAI panel is pre-696. You can put some thin tape over pins 20 and 70 (they're opposite each other, front and back) on the RAM17 for testing, or just cut the lines to them near the edge connector.

    Additionally, you need to disable the RAM that overlaps with your disk controller. Typically I just switch off the entire 8K block from 0xE000 - 0xFFFF. The manual covers that.
    Hey buddy! Yea, picked up a RAM17 before Xmas on a whim to hopefully at some point swap out projects on the project table!

    Okay, that totally worked as far as restoring the functionality of the front panel and being able to step through things. Plus I am able to examine/execute at E800 (NorthStar Controller ROM) or F800 (AMON Rom on the 88-2SIO.) Before I would land on the 88-2SIO ROM and easily do EX E800 to jump.

    I was able to get NorthStar DOS to boot. It takes some finagling. I thought it might be the VSG or battery on it, but I'm thinking I might have a ribbon cable issue between the NorthStar controller and the VSG. I really need to (and plan to) mount the VSG inside the external drive case and power it from the drive PSU or something but that can come later. Once it boots NorthStar DOS though, it should boot CP/M.

    Much thanks for that Glitch, I would have never figured it out (and I spent a good chunk of time between the manuals and jumpers on the various boards.)

    Now that the front panel is working I will try to boot CP/M and see where the loop is stuck at.

  4. #4
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,882

  5. #5

    Default

    Quote Originally Posted by glitch View Post
    Excellent, glad that took care of it!
    Well that fixed the issue with the front panel. The CP/M disk still isn;t executing. Will sit down and figure out where the program is looping at.

    I am using CP/M disk image from Deramp that is already setup for the Northstar controller + 88-2SIO + 48K.

  6. Default

    I didn't realize you have a RAM17 -- I still have your RAM16, haven't finished wire wrapping a replacement for it.

    The RAM17 is an IEEE-696 board and grounds S-100 pins 20 and 70. This disables all of the one-shots on the IMSAI front panel, since the IMSAI panel is pre-696. You can put some thin tape over pins 20 and 70 (they're opposite each other, front and back) on the RAM17 for testing, or just cut the lines to them near the edge connector.

    Additionally, you need to disable the RAM that overlaps with your disk controller. Typically I just switch off the entire 8K block from 0xE000 - 0xFFFF. The manual covers that.
    tiny newbie question
    why do you need to disable the RAM exactly?

  7. #7

    Default

    NSDOS doesn’t need high RAM to boot whereas CP/M needs the RAM from 40K-48K (assuming the 48K CP/M you mention) to be good in order to operate properly. Do you have the 4K version of AMON with the memory test command in it (MT) so you could easily run a memory test on the RAM 17?

    Which North Star controller do you have - the single or double density controller? Make sure you write the proper version of CP/M for your controller.

    Mike

  8. #8

    Default

    I'm curious as to how one get N* dos to run on a S100. Does the N* have firmware on the mother board or is that just for I/O and the disk controller does the boot?
    I have a N* but I've not done much more than repairs and get it to boot a disk ( too many projects ). I have an IMSAI with a full 64K of RAM. What is a VSG?
    Dwight

  9. #9

    Default

    Quote Originally Posted by Dwight Elvey View Post
    I'm curious as to how one get N* dos to run on a S100. Does the N* have firmware on the mother board or is that just for I/O and the disk controller does the boot?
    I have a N* but I've not done much more than repairs and get it to boot a disk ( too many projects ). I have an IMSAI with a full 64K of RAM. What is a VSG?
    Dwight
    Hi Dwight,

    I have the N* double density controller. On it is an OTP PROM, which is programmed to recognize address E800 and start a program there. So on my SOL if I send the processor there with command EX E800, it starts up the disk controller and loads the disk. I have tried both 48k CP/M 2.2 and N* DOS , configured for 48k memory and they both work and it boots to that DOS from the disk. I have a 64k memory that is disabled above 48k to allow for addresses above, where the SOL's systems operate and the disk controller operates.

    I think this was the great thing about the N* disk controller cards, no additional software or driver or loader is required to make them work on the s-100 bus. There are single and double density cards.

    As noted by Mike CP/M needs some space in high memory to work. On testing, I found that the CP/M 2.2, I have, uses up high memory from 9BF0 to BFFF. I have a MEMAP program that is supposed to report the memory usage of CP/M but it reported a little less memory was used. To find out I filled the entire memory with byte AA, ran CP/M for a while and then looked to see what bytes in high memory it had altered.

    The VSG (virtual sector generator) was created by Mike, it plugs in series with the ribbon cable that leads from the N* controller to the disk drive, so that soft sector disks can be used, but it also is "transparent" in that hard sector disks will work (if the actual drive unit will "play" these, my particular drives YD-580 won't).

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
  •