CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind... - CP/M

This is a discussion on CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind... - CP/M ; On 2006-02-23, Michael Heimbach wrote: > > Roger Ivie wrote: >> I did get it running (out of a RAM disk image booted over Ethernet) on my >> trusty MicroVAX 2000 before my wife got me hooked on World of ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

  1. CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    On 2006-02-23, Michael Heimbach wrote:
    >
    > Roger Ivie wrote:
    >> I did get it running (out of a RAM disk image booted over Ethernet) on my
    >> trusty MicroVAX 2000 before my wife got me hooked on World of Warcraft.

    >
    > That sounds interesting.
    > Is the image still remaining somewhere?



    Well, give me a few days to pull stuff together. I still have the
    sources and a bootable image and it's certainly not doing anyone any
    good gathering dust on my hard disk.

    Unfortunately, I cannot currently build it. I suffered a motherboard failure
    last month which scribbled all over my hard disks; I took the opportunity
    to upgrade my PC from NetBSD 1.6.2 to NetBSD 3.0. Since then I have been
    utterly unable to build GCC as a cross-compiler for VAX. But I also haven't
    tried very hard, either.

    I made no changes to the Digital Research sources beyond those I did for
    exchange, a flavor of CP/M-68K that runs under Unix to allow
    manipulation of CP/M disk images. That can be found over at the bottom
    of http://cpm.z80.de/source.html.

    I have a 3.5" diskette drive in my MicroVAX 2000 (hint: mount the drive
    upside down) and intended to use the P112 disk format, which is why
    exchange supports that format. However, that format has changed since I
    did exchange, and I've not yet updated it to the new format. The good
    news is that the change to the P112 disk format reserves an additional
    track for the system, which should provide enough space to allow a
    CP/M-2 style boot on a MicroVAX 2000 instead of the CP/M-68K boot to
    a stripped-down system that loads the full system. The system is
    astonishingly small; the load image is only about 280,000 bytes,
    INCLUDING a 256,000 byte disk image.

    I got sucked into World of Warcraft right when it was time to start
    doing floppy support. The system currently includes an 8" SSSD disk
    image in the BIOS that is used to hold files for the system; that image
    is the only drive currently supported.

    There is, of course, a severe shortage of applications. In fact, there
    is only one: a little FORTH I did to allow me to play with the system
    and issue BDOS calls to try things out. I'm pretty certain that's the
    only thing on the disk image at the moment, but I'll have to get my
    MV2000 set back up and boot it to see for certain.

    The system currently assumes 2MB of RAM beginning at zero. This is how
    much memory is included on the motherboard of a MicroVAX 2000. The base
    page is at 0, but loaded programs a passed a pointer to the base page
    that they should use instead of assuming they've been loaded at zero.
    The base page is located at the bottom of the region into which a
    program has been loaded and the stack pointer is initialized to the top.
    A user program is called via CALLS, and passed a pointer to the base
    page, which includes:

    - A pointer to the BDOS entry point that may be CALLed by the program,
    - The base address of the memory region (i.e., the address of the base
    page),
    - The address immediately following the top of the memory region,
    - A pointer to the program entry point,
    - A copy of the initial value for the stack pointer,
    - The starting address of the .TEXT segment (I'm currently using a
    .COM-style executable format, so this is the only segment currently
    used),
    - The size, in bytes, of the .TEXT segment,
    - The base address of the .DATA segment, currently always zero because
    only the .TEXT segment is used,
    - The size, in bytes, of the .TEXT segment,
    - The starting address of the .BSS segment, currently initialized to
    the address immediately following the .TEXT segment,
    - The size, in bytes, of the .BSS segement, currently zero because
    only the .TEXT segment is used,
    - The drive number from which the program was loaded,
    - Two FCBs parsed from the command line,
    - And a copy of the command tail.

    This is padded to 512 bytes, so programs are currently loaded at
    location 0x200 in memory.

    CP/M-68K includes some functions that are processed in the BIOS before
    they are passed to the BDOS. I've taken advantage of this to add a couple
    handy BDOS calls, some of which are supported by CP/M-68K and some of
    which are not. They are:

    - Function 50, DIRECT BIOS CALL, which allows a user program to call
    BIOS functions.

    - Function 64, ENTER PROGRAM, which allows a loaded program to be
    called. This is used by the CCP to enter a loaded program.

    The remainder of the BDOS functions are processed by the DRI code,
    although a few of them are not currently terribly useful given the
    simple CP/M-2-style memory model I'm using.

    I've been toying with migrating to simh and RL02 rather than dealing
    with horrible, icky floppies (hates 'em), but given that I haven't done
    anything with this stuff in about a year I wouldn't hold my breath if I
    were you.
    --
    roger ivie
    rivie@ridgenet.net

  2. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    How VAX-specific are the changes that were made? Do you think that they
    would work properly on a -11 or would more cahnges have to be made?


  3. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    On 2006-02-24, madcrow wrote:
    > How VAX-specific are the changes that were made? Do you think that they
    > would work properly on a -11 or would more cahnges have to be made?


    The changes made to the DRI code are not at all VAX-specific. They are
    only minor tweaks here and there to get it to compile with a modern
    compiler.

    All of the VAX code is at the level of the BIOS and the transition
    between a user program and the BDOS (i.e., how the user program gets
    calls the BDOS). The vast majority of the VAX-specific code is in C; the
    bootstrap is pretty much the only assembly code in the system. The BDOS
    is called via a pointer in the base page rather than through a trap
    instruction, so no interrupts or traps are handled; although there is
    (of course) a vector table, all entries currently point to a HALT
    instruction.
    --
    roger ivie
    rivie@ridgenet.net

  4. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    On 2006-02-24, Roger Ivie wrote:
    > On 2006-02-24, madcrow wrote:
    >> How VAX-specific are the changes that were made? Do you think that they
    >> would work properly on a -11 or would more cahnges have to be made?

    >
    > The changes made to the DRI code are not at all VAX-specific. They are
    > only minor tweaks here and there to get it to compile with a modern
    > compiler.
    >
    > All of the VAX code is at the level of the BIOS and the transition
    > between a user program and the BDOS (i.e., how the user program gets
    > calls the BDOS).


    I should probably expand on this a bit.

    There is, in fact, one corner of the BDOS proper that knows it is
    running on a 68K: the BDOS services to manipulate trap vectors have
    hard-coded knowledge of some of the 68K trap numbers. I do not yet have
    a plan for dealing with this because I simply have not gotten that far.
    Nothing in CP/M requires interrupts to work and my current
    implementation does not use them. This will need to be dealt with at
    some point and properly dealing with it will require changes to the BDOS
    code proper.

    I've split the VAX-specific code into three pieces:

    - arch.c contains stuff that must be done by a VAX regardless of model.
    This includes some math utility routines relied upon by the BDOS,
    byte swapping, the operating system entry point, gluing user program
    BDOS calls to the BDOS, and loading and entering executables. In
    CP/M-68K, this sort of stuff is handled by a chunk of assembly
    code.

    - bios.c contains stuff that is specific to the MicroVAX 2000. This
    is the CP/M BIOS that we all know and love, with a few additions
    required by CP/M-68K (a memory region table, for example). My
    current BIOS handles a single serial line (the console terminal)
    and a RAM disk image.

    - boot.s contains the system bootstrap. It contains position-independent
    code to initialize the system (turning the Ethernet controller off
    so it's not modifying memory, setting up the system stack) and
    copy the system image to its final location.

    It should be possible to create an initial PDP-11 CP/M system by
    replacing only these three pieces, procrastinating trap vector
    manipulation as I've done with the VAX.

    The remainder of the system is the CP/M-68K C code developed by DRI.
    --
    roger ivie
    rivie@ridgenet.net


  5. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...


  6. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    In article ,
    Roger Ivie writes:
    > OK, guys, see http://anachronda.webhop.org/~rivie/cpm-vax/
    >
    > Enjoy!


    Is there anything in this that would make it only work on a 2000 or is
    it likely to work on other models like the MicroVAX II/III or the 3100?
    (or even the 4000?)

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  7. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    On 2006-02-25, Bill Gunshannon wrote:
    > In article ,
    > Roger Ivie writes:
    >> OK, guys, see http://anachronda.webhop.org/~rivie/cpm-vax/
    >>
    >> Enjoy!

    >
    > Is there anything in this that would make it only work on a 2000 or is
    > it likely to work on other models like the MicroVAX II/III or the 3100?
    > (or even the 4000?)


    It would need a new BIOS and bootstrap to work on anything else.

    Although the BIOS doesn't yet touch the disk controller, it does assume
    a DZ at the 2000's base address. Minor tweaks should bring it up on the
    3100 and 4000/60. I'd stay away from the 4000/90 and /96; this runs with
    the MMU disabled and the flash on those machines is write-enabled. I'd
    be a bit nervous about accidentally hosing the flash (I've done it
    before). I don't know how the console port works on a uVAX II/III.

    The bootstrap disables the 2000's LANCE to stop it from scribbling on
    memory. This would also have to be tweaked for the 3100 and 4000/60. And
    stripped for the II/III.

    Performance would not be optimal on a machine such as the 4000/90, since
    it doesn't know how to initialize the cache and turn it on.
    --
    roger ivie
    rivie@ridgenet.net

  8. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    In article ,
    Roger Ivie writes:
    > On 2006-02-25, Bill Gunshannon wrote:
    >> In article ,
    >> Roger Ivie writes:
    >>> OK, guys, see http://anachronda.webhop.org/~rivie/cpm-vax/
    >>>
    >>> Enjoy!

    >>
    >> Is there anything in this that would make it only work on a 2000 or is
    >> it likely to work on other models like the MicroVAX II/III or the 3100?
    >> (or even the 4000?)

    >
    > It would need a new BIOS and bootstrap to work on anything else.
    >
    > Although the BIOS doesn't yet touch the disk controller, it does assume
    > a DZ at the 2000's base address. Minor tweaks should bring it up on the
    > 3100 and 4000/60. I'd stay away from the 4000/90 and /96; this runs with
    > the MMU disabled and the flash on those machines is write-enabled. I'd
    > be a bit nervous about accidentally hosing the flash (I've done it
    > before). I don't know how the console port works on a uVAX II/III.
    >
    > The bootstrap disables the 2000's LANCE to stop it from scribbling on
    > memory. This would also have to be tweaked for the 3100 and 4000/60. And
    > stripped for the II/III.
    >
    > Performance would not be optimal on a machine such as the 4000/90, since
    > it doesn't know how to initialize the cache and turn it on.


    Oh well, so much for taking a quick look. I have a bunch of VAXen but
    no 2000. I really thought they were a lot closer to each other than
    that at the lower levels with the bigger differences being things like
    DSSI vs. SCSI and such. Probably be just as easy to go straight to
    looking at a PDP-11 port. :-)

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  9. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    On Sat, 25 Feb 2006 16:46:52 GMT, Roger Ivie
    wrote:

    >On 2006-02-25, Bill Gunshannon wrote:
    >> In article ,
    >> Roger Ivie writes:
    >>> OK, guys, see http://anachronda.webhop.org/~rivie/cpm-vax/
    >>>
    >>> Enjoy!

    >>
    >> Is there anything in this that would make it only work on a 2000 or is
    >> it likely to work on other models like the MicroVAX II/III or the 3100?
    >> (or even the 4000?)

    >
    >It would need a new BIOS and bootstrap to work on anything else.
    >
    >Although the BIOS doesn't yet touch the disk controller, it does assume
    >a DZ at the 2000's base address. Minor tweaks should bring it up on the
    >3100 and 4000/60. I'd stay away from the 4000/90 and /96; this runs with
    >the MMU disabled and the flash on those machines is write-enabled. I'd
    >be a bit nervous about accidentally hosing the flash (I've done it
    >before). I don't know how the console port works on a uVAX II/III.
    >
    >The bootstrap disables the 2000's LANCE to stop it from scribbling on
    >memory. This would also have to be tweaked for the 3100 and 4000/60. And
    >stripped for the II/III.
    >
    >Performance would not be optimal on a machine such as the 4000/90, since
    >it doesn't know how to initialize the cache and turn it on.


    Myself once I get a bit of time a T-11 cpu and IO running CP/M would
    be a nice small system (only 30kWords, 2kW IO space).


    Allison

  10. Re: CP/M-VAX, was Re: Interesting PDP-11 Stuff to do WITHOUT violating Mentec's IP rights and Bill's legalist mind...

    On 2006-02-25, Bill Gunshannon wrote:
    > Oh well, so much for taking a quick look. I have a bunch of VAXen but
    > no 2000. I really thought they were a lot closer to each other than
    > that at the lower levels with the bigger differences being things like
    > DSSI vs. SCSI and such. Probably be just as easy to go straight to
    > looking at a PDP-11 port. :-)


    They are similar, but not identicaly. The 2000, 3100, 4000/60, and
    4000/9x all have a LANCE for Ethernet and a DZ for the serial ports, but
    they are at different addreses. The addresses I used are specific for
    the 2000 and will definitely not work on the 4000/60 and 4000/9x.

    It MIGHT work on a 3100. I'm not familiar enough with the system internals
    to be sure.

    When I accidentally wiped my 4000/90 flash (which, as I mentioned, is
    write enabled), it was by attempting to manipulate the console DZ at the
    4000/60 address. There is real danger on the /90 and /96.
    --
    roger ivie
    rivie@ridgenet.net


+ Reply to Thread