PDA

View Full Version : Looking for CompuPro ROM source code



RichCini
July 17th, 2016, 03:45 PM
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

mlaferriere
July 17th, 2016, 04:30 PM
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.

RichCini
July 17th, 2016, 04:37 PM
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

Randy McLaughlin
July 17th, 2016, 04:52 PM
http://pcsauro.altervista.org/CPMSW/os/COMPUPRO.ZIP

Both under the CP/M-86 and CP/M-816 - look for GBCROM.A86

That should be what you need. I'll look at it closer later this evening.


Randy

RichCini
July 17th, 2016, 05:09 PM
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

Randy McLaughlin
July 17th, 2016, 05:41 PM
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

Randy McLaughlin
July 17th, 2016, 06:09 PM
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

MicrocomputerSolutions
July 17th, 2016, 06:30 PM
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.

Randy McLaughlin
July 17th, 2016, 08:16 PM
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

RichCini
July 18th, 2016, 01:39 PM
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!

Randy McLaughlin
July 18th, 2016, 06:54 PM
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

MicrocomputerSolutions
July 18th, 2016, 07:52 PM
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


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.

Randy McLaughlin
July 18th, 2016, 10:26 PM
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

RichCini
July 19th, 2016, 04:27 AM
Yup, good point. I'll continue looking using Godbout. Still haven't surfaced anything.

RichCini
July 30th, 2016, 06:02 PM
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!

MicrocomputerSolutions
July 30th, 2016, 09:20 PM
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)?

RichCini
July 31st, 2016, 06:35 AM
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).

Randy McLaughlin
July 31st, 2016, 11:25 AM
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).

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

RichCini
July 31st, 2016, 12:19 PM
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!

Randy McLaughlin
July 31st, 2016, 02:12 PM
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!

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

RichCini
July 31st, 2016, 02:28 PM
Thanks Randy, good point. I just looked at the manual and there is an input port (BASE+3) that's used to disable the boot ROM. It appears that you load the DMA register with an address and then read the disk into that location...at the end you then release the ROM by reading the above port. I need to read the code in more detail, though.

Randy McLaughlin
July 31st, 2016, 05:23 PM
Thanks Randy, good point. I just looked at the manual and there is an input port (BASE+3) that's used to disable the boot ROM. It appears that you load the DMA register with an address and then read the disk into that location...at the end you then release the ROM bu reading the above port. I need to read the code in more detail, though.

It's a bit confusing but the port+3 is a bit banging port - the high bit is the status of the serial line, when written the high bit is to bang out.

Also when written (not read as the manual appears to say) the low bit hides the ROM when low, once hidden it stays hidden until S100 reset.

You can bang out data without disabling ROM by keeping the low bit high.

I never used the bit banging serial port - I always used a real serial port.


Randy

RichCini
August 1st, 2016, 05:39 PM
Tonight I tried another tact. Rather than using the Disk1 for booting to a monitor, I tried to put an EPROM in U16 on the System Support Board (F000:F800) and set the 86/87 to boot. The EPROM has a JMP at offset 7F0 in the EPROM (which would be F000:FFF0) to absolute F000:F800 (which should be offset 0 of the EPROM). No dice.

Has anyone ever gotten a system booting off of only the SSB and CPU card, even experimentally? This is driving me nuts.

Thanks!

Randy McLaughlin
August 1st, 2016, 07:08 PM
Tonight I tried another tact. Rather than using the Disk1 for booting to a monitor, I tried to put an EPROM in U16 on the System Support Board (F000:F800) and set the 86/87 to boot. The EPROM has a JMP at offset 7F0 in the EPROM (which would be F000:FFF0) to absolute F000:F800 (which should be offset 0 of the EPROM). No dice.

Has anyone ever gotten a system booting off of only the SSB and CPU card, even experimentally? This is driving me nuts.

Thanks!

You are bootstrapping in the truest sense. The magical cartoon style - you are in a hole, you grab your bootstraps and lift yourself out of the hole.

If possible do it the easy way - do you have a working system that either boots to CP/M or goes to a monitor with less than 64K of RAM (say 32K) even better a computer with a front panel?

if so setup the SS1 as non-extended f000-ffff and peek at it with monitor or DDT.

Find your ROM verify you can read it.

Test your serial port.

A blind bootstrap is hard, bringing up a system from another system is easier.

The SS1 has so many ways to go wrong - is it setup to show the memory at all, is it setup to only show when phantom is asserted, is it setup no only show when phantom is not asserted?

Is it in the right extended block?

Is it in the right 64K block?

These are questions best answered from a front panel, monitor, or debugger.



Randy

RichCini
August 2nd, 2016, 03:43 AM
Thanks Randy. I have one more thing to try tonight (I may have gotten an address in the ROM wrong; need to re-read the 86/87 manual today) and then I'll pull out my other system if needed.

More to come...

{Evening Update}

I made some changes to the code and now the test code in U16 works fine -- all it does is print "*" for each part of the init and then halts. I also used a debug board from S100 Computers (System Monitor Board) which has a 6-digit hex address display.

I'm using NASM which doesn't handle ORGs the same as Microsoft Assembler so I think it was a matter of getting the location of the code right.

On to the monitor!