After lengthy debugging, the Rainbow now boots DOS 3.10 (with a proper NVRAM file that must match DIP / RAM Settings)...
Still, DOS 2.01, DOS 2.05, DOS 2.11, CP/M 2.x _and_ Concurrent CP/M fail with quite the same error!
Now i have a good log from an attempt to boot Concurrent CP/M - together with a commented source file from Digital Research (-> right hand side -> WD1797).
It shows why the seek to track 00 happens - instead of a seek (or read) @ track 2 - as expected.
Thank you very much for your work on the NCR DMV driver ... it's amazing to see the machine come to life.
As always the following thoughts are just meant as ideas, not as impatient nagging or criticism.
Althought the DMV now boots CP/M, the error message with no disk inserted as shown in the before last post persists. The message should simply read "Disk A: not ready (CR)"
The DMV relies heavily on its slots and modules. Slot 1 can take a 64K, 192K or 448K memory module. Slot 7 can take a CPU module (8086 or 68008) or the diagnostics module. There is a slot 7a on the rear side of some mainboards that can take the internal 8086 module. Slots 2-6 can take the various expansion modules (Centronics, Serial, RTC, Mouse, Harddisk). On some machines there is a slot 3a on the rear side that accepts the internal harddisk adapter.
A few pages back I posted these files that could come in handy now the DMV is booting.
Originally Posted by rfka01
Sometimes small wonders happen ... I was given the DMV diagnostic module by a guy who used to work for NCR ... he has already ditched the module case, but miraculously kept the PCB.
This archive contains the dumps of the two EPROMS.
I've prepared two files that could, once they're filled with actual code, reside in emu/bus/dmv ... one is dmvbus.c, the other is dmvdiag.c, both contained in the above archive. At the moment they only contain ASCII graphics of the bus connector resp. the PCB layout of the diagnostics module.
Also included is the PDF about the diagnostics module from the documentation and a picture of the PCB.
Again, Sandro, thanks a lot for your work.
Robert
NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Althought the DMV now boots CP/M, the error message with no disk inserted as shown in the before last post persists. The message should simply read "Disk A: not ready (CR)"
That error just means the drive isn't ready so I don't know why it wouldn't just display the "not ready" error. Possibly the ready line isn't supposed connected to the controller.
I was looking through the MESS drivers to find one that uses the same graphics chip (the NEC �PD7220) as the NCR DMV and already has the UPD7220_DISPLAY_PIXELS_MEMBER entry populated.
The Epson QX10 driver fits that category, and it seems to use a similar model to differentiate between its monochrome and colour graphics adapter (1 colour plane vs. 3 colour planes, on the DMV 32KB vs. 96KB of graphics memory).
Unfortunately the QX10 driver still seems to have some issues as the one disk image that boots into a graphics mode automatically (the keyboard's dead too) has the graphics sort of backwards.
The 7220 has a text only and a "mixed mode" for graphics and text ... I think that's the one used here. The mathprof demo start screen is quite long with jumbled graphics, so it's a good test point
NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
I've updated the "NCR Diagnostics Module" archive from a few posts up with more info on the Bus(es).
Slot 1 (memory modules) has a different pinout, but the same physical connector as the expansion module slots. Slots 7 and 7a (CPU and Diagnostics modules) carry additional signals to slots 2-6
Robert
NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
I have an idea why the 8251 does not pass the BIOS check on a Rainbow-100
The startup code uses an internal loopback to check the communication, printer and keyboard ports (all serial) for framing errors.
Bit 4 and bit 5 in 8088 register 0A (diagnostic write) are used in the process.
This is done in a way that the output of one port is connected to another when bit 5 is set.
We neither have COMM, PRINTER, nor loopback connected to anything. So the Rainbow startup code literally falls apart (as tests are incremental; COM -> PRN -> KBD -> FLOPPY ...)
Bit 4 uses a similar concept to validate the video and floppy controller signals with the help of a printer port.
Info pieces are from chapter 2.1.7.2 and 2.1.7.3 of AA-V523A-TV (PDF March 83).
Code
WRITE8_MEMBER(rainbow_state::diagnostic_w) // 8088 (port 0A WRITTEN). Fig.4-28 + table 4-15
...
// * BIT 4: DIAG LOOPBACK (0 at power-up; 1 directs RX50 and DC12 output to printer port)
/* 2.1.7.3 DIAGNOSTIC LOOPBACK Maintenance Bit - The DIAGNOSTIC LOOPBACK bit is a
maintenance bit that is cleared on power - up.This bit, when set to 1,
allows the floppy data separator and the serial video output to be tested
through the use of the printer port. The following table shows how signals are routed.
DIAGNOSTIC LOOPBACK = 0 DIAGNOSTIC LOOPBACK = 1 SIGNAL INPUT
SIGNAL SOURCE SIGNAL SOURCE TO
FROM FROM
PRT RDATA(J2) VIDEO OUT PRT RXD(7201)
PRT RXTXC 500 KHZ PRT RXTXC(7201)
MASTER CLK 250 KHZ VIDEO CLK(DCO11)
FLOPPY RAW DATA PRT TXD(7201) FLOPPY DATA SEPARATOR
During Diagnostic Loopback, the - TEST input of the 8088 is connected to the
interrupt output of the MPSC.Thus, using the 8088's WAIT instruction in a
polled I / O loop, the diagnostic firmware will be able to keep up with the
500 Kb data rate on the MPSC.
*/
if (data & 16)
{
printf("\nWARNING: UNEMULATED DIAG LOOPBACK (directs RX50 and DC12 output to printer port) ****");
}
if (data & 32)
{
/* BIT 5: PORT LOOPBACK (1 enables loopback for COMM, PRINTER, KEYBOARD ports)
2.1.7.2. of AA-V523A-TV (PDF Mar83) says how the signals are routed:
port_loopback_0 | port_loopback_1 SIGNAL INPUT TO
COMM RCV DATA.......COMM TXD..........COMM_RXD
PRT RCV DATA.......KBD TXD...........PRT RDATA
KBD RCV DATA.......PRT TXD...........KBD RXD
*/
printf("\nWARNING: UNEMULATED PORT LOOPBACK (COMM, PRINTER, KEYBOARD ports) ****");
}
Ahh, that's interesting, and it could definitely help understand why we sync the bitstream correctly and then lose it later. I'll try and set that up later today.