Mode l II custom CPU card ROM disassembly

[kb2syd]

I have a Model II CPU card used in a custom application and would like to disassemble the ROM. Any advice? Does the model II start at 0000 or some other address within the ROM? I know it will be z80 code and this machine has no floppy or hard drive and was not built to have any.

Thanks in advance,
Kelly

UPDATE: I've been able to dump the ROM contents. I don't remember enough z80 programming so I've started reading again. The first few instructions already don't make sense so maybe I've read the content incorrectly.

0x00	f3 	di 
0x01 	43	ld b,e 
0x02	1f	rra 
0x03	01cd29	ld bc,0x29cd 
0x06 	00	nop

Here is the data from the ROM View attachment mux.zip

 

[gp2000]

The Z-80 starts at 0 so I'm sure the Model II will. Entry points due to interrupts can theoretically be anywhere, but I'd expect them to use interrupt mode one (in which case you'll see an "IM 1" instruction) where maskable interrupts are vectored to 0038 and the NMI to 0066. If "IM 2" is issued, then the code will eventually need to load "I" register to point to table of interrupt vector addresses.

If the RST instructions are used there will be subroutines at 0008, 0010, 0018, 0020, 0028 and 0030. They'll tend to stand out in the disassembly and you'll see the RST instructions elsewhere.

 

[kb2syd]

I've read the content of the ROM using2 different devices and I have the same content. Counting NOPs it ends at 0x141. Not encouraging, although this was a pretty simple device. Read data from the bus and push it out the UART. Read from the UART and push to the bus.

 

[gp2000]

I'm pretty sure there's a bit error in there and that 43 hex byte should be C3. This changes the startup code to:

0x00	f3	di 
0x01 	c31f01	jp	011f
0x04	cd2900	call	0029

The code at 0x11f outputs 1 to port 0xff, initializes the stack pointer to 0xe000 and jumps to 0x04 which all seems quite reasonable.

I've seen flipped bits like this in ROM dumps before. After a quick look at the disassembly I can't see any other obvious instances, but hard to know for sure, of course.

 

[kb2syd]

That makes the rest of the code make sense. Now I just need to figure out what all of those outs are doing. Probably setting up the CTC and the serial ports. I compared the board to a model II z80 board and it is close, but just a little different. I need to put them side by side. I couldn't find a good enough picture of it online so I'll pull one from one of my model IIs.

 

[veco]

I've read the content of the ROM using2 different devices and I have the same content. Counting NOPs it ends at 0x141. Not encouraging, although this was a pretty simple device. Read data from the bus and push it out the UART. Read from the UART and push to the bus.

Keep in mind that in the old days, the data was sometimes bit-swapped or address-swapped so that PCB routing could be done easily. So I would double-check the PCB to see if D[7-0] are really going to D[7-0] on the eprom (same with the address lines).

If you can read from software, it's easier since you don't have to care about this.

-Fred

 

[kb2syd]

OK, so I've got the code from the ROM. It appears to set up a lot of parameters. I have verified the bits are in order. So, how the heck do I determine what is on the opposite end of the inp/outp calls? For example, the following is called quite freqently:

   .data:0x0000010f f5 push af 
   .data:0x00000110 3e00 ld a,0x00 
   .data:0x00000112 d341 out (0x41),a 
   .data:0x00000114 dbf6 in a,(0xf6) 
   .data:0x00000116 cb57 bit 2,a 
   .data:0x00000118 ca1401 jp z,0x0114 
   .data:0x0000011b f1 pop af 
   .data:0x0000011c d3f4 out (0xf4),a 
   .data:0x0000011e c9 ret

Just prior to calling, a is set to 0x79, after return set to 0x41, called again then set to 0x03 and called again. So what is at 0x41, 0xf6 and 0xf4? Forgive me, it's been years since I've been working on this level.

 

[gp2000]

OK, so I've got the code from the ROM. It appears to set up a lot of parameters. I have verified the bits are in order. So, how the heck do I determine what is on the opposite end of the inp/outp calls?

The IN and OUT instructions talk to devices on the board which could be anything. You either need the schematic of the board or a technical reference manual to figure out what chips are being talked to.

If what you have is a Model II CPU card with a different ROM then the Model II Technical Reference manual will describe it. I made some notes on some of the Model II hardware that might be relevant. Writing to port 0xff sets the memory bank.

0xf6 is the serial I/O channel A command/status
0xf4 is the serial I/O channel A data

0xf0 is CTC channel 0
0xf1 is CTC channel 1
(I forget what CTC is, perhaps DMA related)

Assuming that, it looks like the subroutine at 0x10f transmits a byte in A register and the subroutine at 0xff receives a byte.

I've no idea what port 0x41 is. By symmetry I'd guess that the "out (0x41),a" in subroutine 0x10f should really be "out (0xf6),a" as seen in subroutine 0xff but that is pretty broad speculation.

Looking a bit more closely at the disassembly I get the impression that it is a little bootloader that reads Intel HEX records into memory and then executes the loaded code.

 

[kb2syd]

If what you have is a Model II CPU card with a different ROM then the Model II Technical Reference manual will describe it. I made some notes on some of the Model II hardware that might be relevant. Writing to port 0xff sets the memory bank.

What section of the tech ref did you see the 0xff? I figured out the channel A and CTC (clock timer chip) ports, but was getting confused by the 0x41 (which could be custom for this box) and the 0xff.

Looking a bit more closely at the disassembly I get the impression that it is a little bootloader that reads Intel HEX records into memory and then executes the loaded code.

Could it be reading the HEX records from port A? If so then that makes sense since there is no other storage device attached to this machine.

There are two serial ports and 16 phone lines and nothing else on this box. It was designed to arbitrate sixteen 300 baud modems over the two model II serial ports. The modems are auto answer and put out serial data onto 16 8250 serial ports also attached to the model II bus.

If that's the case then there is no hope in ever getting this to boot again. I'm afraid there is no copy of the boot system for this anywhere. The code does look too simple for what it does. I'm guessing I'm dead in the water now. Not terribly surprised.

 

[gp2000]

What section of the tech ref did you see the 0xff? I figured out the channel A and CTC (clock timer chip) ports, but was getting confused by the 0x41 (which could be custom for this box) and the 0xff.

I saw 0xff mentioned in the VIDEO/KEYBOARD INTERFACE section.

Could it be reading the HEX records from port A? If so then that makes sense since there is no other storage device attached to this machine.

There are two serial ports and 16 phone lines and nothing else on this box. It was designed to arbitrate sixteen 300 baud modems over the two model II serial ports. The modems are auto answer and put out serial data onto 16 8250 serial ports also attached to the model II bus.

If that's the case then there is no hope in ever getting this to boot again. I'm afraid there is no copy of the boot system for this anywhere. The code does look too simple for what it does. I'm guessing I'm dead in the water now. Not terribly surprised.

Yes, I think it is reading HEX records from port A. It looks like it issues some kind of command out port A in order to tell the connected system to send the HEX records.

Unless you have or can find whatever attached to port A, you're pretty much stuck. Not completely stuck as you could download your own hex records and try and figure out how to talk to the modems, etc., but I can't imagine there would be much use in that.

 

[lowen]

What section of the tech ref did you see the 0xff?

Look at pages 63 and 64 of the M2 tech ref.

As I recall, port 0FFH is also the memory bank select port, write-only, and the lower four bits are used by the 32/64K RAM cards among others to do bank switching. It's a distributed 'half' port; each card latches its own copy of the port's lower four bits of data for its own bank select purposes. This is how is the extra 16K on the Model 12, a 32K window on the 68K memory cards, the 16K on the ARCnet and HD interface boards, etc are addressed. While I don't have the tech ref on the hi-res graphics board, I would imagine it would be bank-mapped as well. The lower four bits give a total of 16 32K 'pages' available (page 0 is always in at 0000-7FFF, and pages 1 through 15 address from 8000-FFFF, just like the LS-DOS compatible way the Model 4 maps banks, but I'm ignoring the 'CP/M compatible way' which switches the memory from 0000-7FFF instead of 8000-FFFF), which gives a theoretical max RAM of 16*32K, or 512K, addressable from the Z80 (and LS-DOS 6.3.1 will address up to 8 32K banks on top of the resident 32K, or 288K of that 512K). Pages 75 and 76 in the M2 TR give the details on how the RAM boards can use this port, and on how to deal with the video RAM, too.

 

[kb2syd]

Look at pages 63 and 64 of the M2 tech ref.

Thanks for the reference. I did some reading last night in the catalogs and usenet groups. Having the ROM read code from the serial port now makes sense. Based on what I now know and pages 20&21 of RSC-12 (1985 Computer catalog) here is how this mux worked.

It involved a model 16B (later 6000) running Xenix and the "Videotex and Office Information System" (26-6470) (hereafter VIS) as well as the VIS Multiplexer software (26-6471). The MUX would load it's code from the Xenix machine and then do its thing, sharing up to 16 modems with the two serial ports on the Xenix box to disseminate VIS pages to consumers. It really kind of makes sense to me. My only other question is does it share two serial ports between the 16 channels, or is one a supervisor port (Serial A) and the other (Serial B) used to access VIS.

I have someone sending me the VIS software, but he does not have the MUX driver software. I guess this beast will not breath again any time soon.

Thanks for all the help from everyone.