• Please review our updated Terms and Rules here

Looking for CompuPro ROM source code

RichCini

RichCini

Veteran Member
Joined
Aug 7, 2005
Messages
547
Location
Long Island, NY
All --

I'm pulling items together for my next S-100 project (3-board CompuPro 8086 system) and I have a quick question. Does anyone have the source code for the ROM on the Disk 1 controller and for something called the "8088/8086 Monitor-Debugger"? I have the Disk 1 EPROM, so that's no problem (just looking for code), but Googling for the second doesn't produce much that's useful.

Thanks!

Rich
 
I have a CompuPro 8/16 in my garage that hasn't been powered on for a few years. I could see if the rom is removable and perhaps meet up with someone who lives near Massachusetts for a quick read of the rom if its socketed. It has an external HD, 8" and 5.25" drive in a CompuPro cabinet.
 
That would be great, Michael. Thank you. No rush. My system isn't an 8/16 (but it will consist of the 86/87 CPU, Disk 1, and System Support Board) which is why I was looking for the source of the monitor. I'll look for the 8/16 manual -- I didn't think to look for that manual.

Rich
 
Thanks Randy. I had that archive but hadn't gotten through it all. That file looks like the x86 portion of the boot ROM from the Disk 1. I found two binary files elsewhere so I need to find out which version of the EPROM I have.

What's interesting, and I'm not sure how this works, but the EPROM has four or eight different routines in it for different boot combinations. So somewhere there must have been a combined source to build the ROM.

Now I just need to locate the monitor ROM.

Thanks again!
Rich
 
Compupro ROMs had several boot images built from the same source. You would assemble the different ones and burn them in diff locations in ROM - then just jumper/switch select which ROM image was seen on the BUS.

Added to that the 8 bit code started at 0, the 86 code started at top.

The code was a simple small boot routine so you could have many configs in one ROM.


Randy
 
Looks like that tree does have DISK1(A) boot ROM code. No monitor - and I never saw any Compupro with anything but simple boot ROMs.

What's missing are the DISK2 and DISK3 ROMs. I will dig out my DISK3 and copy the ROM but I no longer have a DISK2.

I will also copy my DISK1A ROM.

Generally the code is simple enough so disassembly should be trivial if the source code is desired.


Randy
 
The Disk-1 does not support boot direct to the Disk-2 (8") or Disk-3 (5.25" MFM) hard drives. The standard Disk-1 Prom contains eight boot routines for the 8085 or Z-80, OR the 8088, 8086, 286, or 68K.

With a Disk-1, you bring in a Loader (off the Boot Tracks of a floppy disk) which will contain the primitives for the Disk-2 or Disk-3 hard disk controller.

The Early Disk-1A Prom (labelled 290F) is the same as the late Disk-1 Prom (labelled Boot F), so the early Disk-1A with the 290F Prom will not directly boot a Disk-2 or a Disk-3 either (same as a Disk-1, must bring in the Loader which will have the routine/s to boot a hard drive controller. A 290F Prom from a Disk-1A can be inserted in a Disk-1, and it will work. You will find the Early DISK-1A 290F Prom on Disk-1A Board Revisions C, D, E, & F. The standard 291X Disk-1A Proms contain sixteen boot routines.

Prom 291 A-M? can be installed on any Revision Disk-1A (Revision D has a trace error that must be corrected) and are capable of booting a hard drive directly, without bringing in the hard drive routines in a Floppy Loader first.

None of the standard Disk-1 or Disk-1A Proms contain a Monitor Program. The different boot routines are all made to load a operating system from a floppy or hard drive.
 
The DISK 1(A) boot ROM boots the DISK 1(A), and is disabled in a hard disk system once the OS is loaded on the Hard drive.

All of Compupro's disk controllers have ROM's so if you have a DISK 1 and a DISK 2 or DISK 3 you normally disable the DISK 1 ROM.

I always preferred the boot ROM on the disk controllers for several reasons. Mainly the ROM always matches the boot media. Systems that put the ROM on the CPU board often require changing the ROM for different configurations.

Compupro went the extra step in providing boot code for several processors on the disk controllers.


Randy
 
I have never tried the boot routines on the Disk 1 (preferring to use my own in ROM), so it'll be interesting to see if this works right. Also, the monitor name I quoted I found a reference to on-line but I have never seen the code for it. I looked in the 8-16 manual but it doesn't appear to be there. I'm sure it's a "generic" x88/x86 monitor (which I have a few of) but I was looking for the CompuPro-issued one. I'll keep looking for it as well.

Thanks!
 
When looking keep in mind Godbout changed their name to Compupro when they decided to get away from the hobbyist systems and go turn-key business systems. So I wouldn't expect to find the monitor with a Compupro name - more likely under Godbout.


Randy
 
Randy McLaughlin said:
The DISK 1(A) boot ROM boots the DISK 1(A), and is disabled in a hard disk system once the OS is loaded on the Hard drive.

All of Compupro's disk controllers have ROM's so if you have a DISK 1 and a DISK 2 or DISK 3 you normally disable the DISK 1 ROM.

Randy
Click to expand...


Compupro's Floppy Controllers (Disk-1, Disk-1A, Disk-1B), all have Boot Proms/Roms. The Disk-2 and Disk-3 Hard Drive Controllers do not have Boot Proms/Roms. They expect the User to have a Compupro Floppy Controller (with Boot Prom/Rom) onboard to start up the system.
 
Been a few years since I used my DISK 3, and I forgot the boot ROM it uses is on the DISK 1A. But no you don't need a floppy to boot. It looks like Compupro ran out of space and decided people would be using their DISK 1A controller and they could save the space needed to have a boot ROM.

The DISK 2 on the other hand does have it's own boot ROM and the Compupro floppy disk controller isn't needed.

The DISK 2 was many years older design and was at a time people were using a variety of manufacturer boards when building a system.

Early S100 computers were a hodge-podge of hardware and later ones were usually populated with one or two manufacturer boards. This meant different boot ROMs and console ports were less likely to match from one board to another in a system. This required turning off ROMs on non booting devices and customizing the console in the BIOS on older systems.



Randy
 
Following up on this, I still haven't located the "monitor" mentioned in the CompuPro advertisement. However, I want to run something by the group.

I have four boards in my experimental system: Disk 1 (171F), CPU 86/87, RAM 22, and System Support Board 1. All boards are configured per the instructions in the Disk 1 manual, which for this experiment includes using a boot routine in the Disk 1 EPROM @ offset 200h (SysSupBd).

I also have a second Disk 1 (171F) in my IMSAI. Out of curiosity, I pulled both EPROMs and compared them and the EPROMs are different @ offset 500h. Not sure what the difference is since one is labeled and one isn't. Maybe the 68k boot code?

Anyway, I have not yet taken the code @ 200 and decompiled it to see if it is indeed X86, but does anyone have a Disk 1 EPROM image known to boot the 86/87 CPU card so I can compare it to what I have?

Thanks!
 
There are eight Boot Routines contained in the DISK-1 PROM/ROM. What is printed on the label on the PROM that you do have? Does it say "BOOT F" or something else (the BOOT F PROM contains 68K boot routines)?

You get the individual Boot Routines by setting the switches, AND the (3-pin) jumper to the left side of the PROM. Without looking at the Disk-1 Manual, I think it's jumper on the two higher pins for 8-bit boot rountines, and jumper on the two lower pins for 16-bit boot routines.

With the CPU-8086, you probably need to choose from the (4) 16-bit boot routines. With a CPU-8085/8088, depending on what Version of CPM-80, CPM-86, CPM 8-16, MPM, or CDOS you are trying to boot there may be a way to run a 8-bit boot routine OR a 16-bit boot routine (late Compupro versions of operating systems use a 16-bit boot for all 8085/8088, 8086, and 286 processor boards). Early versions of Compupro 16-bit operating systems could boot the 8085/8088 processor board with either a 8-bit or a 16-bit boot routine.

Are you trying to boot a version of CPM-86 CPM 8-16 from Compupro? If so, which version is it (examples would include 1.1PA, 1.1PD, 1.1R, and 1.1T)?
 
Thanks. It's not being used in a real CompuPro system or with any of its software (yet) but I am trying to validate the hardware. I have the jumpers and switches set correctly for the boot routine per the manual. I looked at the EPROM code @ offset 0x200 to confirm that it's 8086 code which matches the code in GBCROM...it does. I did notice, however, that at the reset location (offset 0x02f0 in the EPROM), it codes for "JMP 0000:0006". Not sure if that's right given the floppy code would actually be at F000:FF06. It's almost like it was supposed to be a short jump but it turned out to be a long jump.

Based on this I modified the EPROM to have the correct jump and now it tries to access the floppy drive (which has a blank disk). My next goal is to replace the boot code with board initialization code and put a monitor in U17 on the System Support Board (@ F000:F000).
 
RichCini said:
Thanks. It's not being used in a real CompuPro system or with any of its software (yet) but I am trying to validate the hardware. I have the jumpers and switches set correctly for the boot routine per the manual. I looked at the EPROM code @ offset 0x200 to confirm that it's 8086 code which matches the code in GBCROM...it does. I did notice, however, that at the reset location (offset 0x02f0 in the EPROM), it codes for "JMP 0000:0006". Not sure if that's right given the floppy code would actually be at F000:FF06. It's almost like it was supposed to be a short jump but it turned out to be a long jump.

Based on this I modified the EPROM to have the correct jump and now it tries to access the floppy drive (which has a blank disk). My next goal is to replace the boot code with board initialization code and put a monitor in U17 on the System Support Board (@ F000:F000).
Click to expand...

FYI early System Support boards had ROMs used when the 8088 swapped in on the 8085/8088 boards. Later they used RAM the 8085 would load the code in.

Call me crazy but I was working on a boot ROM for Howard Harte for his SuperIO board that had 3 CPU support: 8 bit starting at 0, 8086 @ fff8, and 68K low but not interfering with the 8080 code.

All three processors have different ways they boot so one ROM makes a lot of sense (to me any ways). All you need are three different OS's to boot. If you add in how say TurboDos boots you could put CP/M, CP/M-86, and CP/M-68K on one media just have a ROM with the ability to read the file system and load the right system by name.

Just one ROM no jumpers.

He got the SuperIO going Z80 only - I recoded it to work 8080+ and was working on the 8086 and 68K stuff.

The original CPU was going to be Z180 but when the EZ80 came out he wanted to go that way. The biggest issue is the EZ80 has a shitty MMU for 8 bit operations.


Randy
 
I spent a bit of time with this today and maybe I'm not seeing the interaction between the SSB and the Disk 1 properly. Both boards are configured pursuant to the instructions in the Disk 1 manual (I give CompuPro credit with that -- the instructions are good).

I have the Disk 1 "booting" properly, which is good. I replaced the default ROM with another ROM that was simple -- it initializes the serial controller, PIC and PIT, printed a few characters and then had an absolute jump to F000:F000 which should be U17 on the SSB (the lower ROM). What happens is that the terminal shows repeating characters of that pattern, so the code is repeating, i.e., the board is starting from the boot location again.

I'm not sure if the boards were really designed to do what I want in this regard (using the Disk 1 boot EPROM to run a ROM monitor) at least temporarily. I wonder -- out loud -- if the ROM is PHANTomed because the Disk 1 ROM block overlays the SSB block. Interesting...need to check that. In which case I guess the boot ROM could put a JMP in RAM which then JMPs to the monitor. Arrrgh.

Replacement Disk1 code attached for the curious...

Thanks!
 

Attachments

  • disk1.txt
    4.8 KB · Views: 5
RichCini said:
I spent a bit of time with this today and maybe I'm not seeing the interaction between the SSB and the Disk 1 properly. Both boards are configured pursuant to the instructions in the Disk 1 manual (I give CompuPro credit with that -- the instructions are good).

I have the Disk 1 "booting" properly, which is good. I replaced the default ROM with another ROM that was simple -- it initializes the serial controller, PIC and PIT, printed a few characters and then had an absolute jump to F000:F000 which should be U17 on the SSB (the lower ROM). What happens is that the terminal shows repeating characters of that pattern, so the code is repeating, i.e., the board is starting from the boot location again.

I'm not sure if the boards were really designed to do what I want in this regard (using the Disk 1 boot EPROM to run a ROM monitor) at least temporarily. I wonder -- out loud -- if the ROM is PHANTomed because the Disk 1 ROM block overlays the SSB block. Interesting...need to check that. In which case I guess the boot ROM could put a JMP in RAM which then JMPs to the monitor. Arrrgh.

Replacement Disk1 code attached for the curious...

Thanks!
Click to expand...

As I remember Disk 1 ROM exists throughout memory map replicated. It would read a boot sector in, turn off ROM and fall through to boot routine.

You may need to copy ROM to RAM (just read and write the 512 bytes back on to it's self), turn off ROM then it may work.

The ROM is turned off by writing 0 or 1 (cant remember which) to one of the controllers ports, once turned off the ROM requires a reset to turn back on.


Randy
 
You must log in or register to reply here.
Back
Top