Home Page Forums MAME MAME Requirements?

https://dl.dropboxusercontent.com/u/83147066/Siemens%20PC-D%20Praxisbuch%20Anhang%202.pdf

Here is more technical info on the Siemens PC-D - it's in German, but if some kind soul wants to work on the driver, I'll translate what's necessary.

Robert

Here is a nice TXT that explains interrupt vector assignments, and more differences between the 'A' and 'B' models (and DOS 2.01 vs. 2.05).

I was asked about IRQ priorities. VBI has highest,
'Interrupt from Z80' has lowest priority (others are in between, in the order shown below for 40 thru 47 or A0 - A7.

Subj: MS-DOS Interrupt Vector Assignment

Rainbow 100 MS-DOS Interrupt Vector Assignment (in hexdecimal)

Interrupt 0 - Divide by zero
Interrupt 1 - Single step
Interrupt 2 - NMI used for Memory Parity error or 8087 error
Interrupt 3 - Break point instruction
Interrupt 4 - Overflow

Interrupt 18 - Firmware functions

Interrupt 20 - DOS program terminate
Interrupt 21 - DOS function call
Interrupt 22 - DOS terminate address
Interrupt 23 - DOS Control-Break exit address
Interrupt 24 - DOS fatal error address
Interrupt 25 - DOS absolute disk read
Interrupt 26 - DOS absolute disk write
Interrupt 27 - DOS terminate & fix in storage
Interrupt 28 thru 3F - Reserved for DOS

; INT 40 thru 47 are used for hardware interrupt if:
; 1. use MS-DOS V2.01,
; 2. use RAINBOW 100 (not 100+).

Interrupt 40 - Vertical frequency refresh interrupt
Interrupt 41 - Not used
Interrupt 42 - Graphic controller interrupt
Interrupt 43 - DMA controller interrupt (from extended comm. board)
Interrupt 44 - Communication/Printer interrupt
Interrupt 45 - Hard disk or Extended communication interrupt
Interrupt 46 - Keyboard interrupt
Interrupt 47 - Interrupt from Z80

Interrupt 64 - timer (60 or 50 ticks/second)

; INT A0 thru A7 are used for hardware interrupt if:
; use MS-DOS V2.05 (or above) WITH RAINBOW 100+.

Interrupt A0 - Vertical frequency refresh interrupt
Interrupt A1 - Not used
Interrupt A2 - Graphic controller interrupt
Interrupt A3 - DMA controller interrupt (from extended comm. board)
Interrupt A4 - Communication/Printer interrupt
Interrupt A5 - Hard disk or Extended communication interrupt
Interrupt A6 - Keyboard interrupt
Interrupt A7 - Interrupt from Z80

Interrupt F0 - Alternate DOS interrupt 22 - Terminate address
Interrupt F1 - Alternate DOS interrupt 23 - Control-Break exit address
Interrupt F2 - Alternate DOS interrupt 24 - Fatal error address

3. alternate interrupt vectors for DOS INT 20-27

DOS INT 20 ------------> INT F8
DOS INT 21 ------------> INT F9
DOS INT 22 ------------> INT F0
DOS INT 23 ------------> INT F1
DOS INT 24 ------------> INT F2
DOS INT 25 ------------> INT FD
DOS INT 26 ------------> INT FE
DOS INT 27 ------------> INT FF

if you read it by interrupt vectors order:

INT F0 ---- DOS INT 22
INT F1 ---- DOS INT 23
INT F2 ---- DOS INT 24
INT F3 thru F7 reserved by DOS
INT F8 ---- DOS INT 20
INT F9 ---- DOS INT 21
INT FA ---- reserved by BIOS
INT FB ---- reserved by BIOS
INT FC ---- reserved by BIOS
INT FD ---- DOS INT 25
INT FE ---- DOS INT 26
INT FF ---- DOS INT 27

Source: RBTECDOC.ZIP (Latrobe and mirrors)

Gotcha, the priority's easy enough to fix.

Is "RAINBOW 100 (not 100+)" 100A?

The info on Wiki seems to be corroborated by this:

http://oldcomputers.net/dec-rainbow-100.html

First Rom, HD not supported = Rainbow 100A
Second Rom, HD supported but not factory installed = Rainbow 100B
Second Rom, HD supported and factory installed = Rainbow 100+

Robert

'100' = '100-A' (system module 70-19974-00, PSU H7842-A, 24 K ROM)
'100+' = '100-B' (system module 70-1994-02, PSU H7842-D, 32 K ROM)

Once upon a time there was a 'Winchester Upgrade Kit' for the '-A'. Could explain the '+' sign.

Question: are the alternate interrupts (above) implemented in our driver?

Yes, bit 7 of the interrupt vector is controlled by the appropriate line on the keyboard 8251, as per the schematics.

Some facts about the mysterious arbitration logic inside the Rainbow...

Quote: reliable floppy operation is not possible 'if both CPUs operate outside of shared memory'.

View from Z80:
- private RAM (2 K static RAM) can be accessed at any time without any wait states

- 62 K shared RAM considered 'busy' when an 8088 cycle or a refresh cycle is in progress
- an arbitration logic ensures that refresh has highest priority. Z80 has equal priority to 8088 except in cases where both access shared memory (Z80 wins).
- if shared RAM is 'busy' at the time of Z80 access, the Z80 will execute wait states until the RAM is free
- extra +1 wait cycle on machine one (M1) cycles when accessing shared memory. WAIT is also used When the RX50 board decides it needs additional time.

In any case, the Z80A is held in a wait state no longer than ~ 2 us.

References: Technical Manual 3.3.1 (page 72); 4-17 (page 115; fig.4-10) ; 4-22 (4.4.5.1) page 120.

In the light of the deadlocks observed - will it be necessary to emulate all this?

P.S.: the READ ID fix Curt did for Osborne had no (apparent) impact on 'rainbow.c' - so i'll submit my patch - minus the keyboard workaround - to version control and hope for the best.

Currently, 'READ_ID_BLOCK_TO_DMA' and 'READ_ID_BLOCK_TO_DMA_BYTE' fail on the Rainbow with CPM 2.x (CPM 1 and DOS 3 boot, other issues with DOS 2.x remain).

It's nice to make buggy software fail on an emulator the same as it does on real hardware, but in this case I suspect the overhead far outweighs the benefit.

You will struggle to find any software that relies on the unreliable floppy operation, so how would you test it?

smf is correct: by definition, if floppy operation on the hardware is correct and doesn't randomly fail all the time, then obviously the operating systems do not cause trouble with the arbitration. And therefore there is no need to emulate it in order to get them to boot and run.


ETA: There is one wrinkle, though.


Some systems in MESS cannot currently be emulated because they wire the WDx7xx so that it halts the CPU when its busy, and then the firmware/software doesn't need to ever busy-wait for the controller. If the RX50 is actually wired that way, you might be in trouble, but the fact that multiple OSes do boot already suggests that that isn't the case. It would be useful to trace on the schematics exactly what causes the RX50 to assert WAIT though.

Guys, I am only trying to find out why the current implementation (even with newest floppy code ***) is so unreliable

Isn't it possible that the 'shared memory' arbitration we talked about synchronizes both CPUs - and we miss important details?

When i look at the signals passed at the J1 connector (left = computer; right = floppy) i can't find evidence that the Z80 is halted by the RX50 controller -

https://dl.dropboxusercontent.com/u/37819653/RX50_Controller_5415482.png

@R.Belmont: there is a 500 ms delay between MOTOR ON and DISK SELECT (middle part). How is that implemented best?

The following bugs remain in current SVN:

a. occasional deadlocks between Z80 and 8088 (near or at HLT instruction).
-> CPU communication / timing? Z80 core?

b. DOS 2.x and CPM 2.x booters fail (CP/M BDOS: 'Read error at track 2 sector 1').
-> The bootstrapper (1) loaded via READ SECTOR, the 2nd part begins with READ ID and fails
-> Think it is command 0xc0; see also my post here )

c. CP/M 1 -sometimes- prints segment addresses to the console
-> crashes during floppy operation...?

d. UCSD systems probe A,B,C then D - and lock up if not all 4 drives have images attached.
-> Drive detection!



(***) preliminary version (patch against 30456):
https://dl.dropboxusercontent.com/u/37819653/_Prelminiary_PATCH_for_SVN_30456.diff

https://dl.dropboxusercontent.com/u/37819653/_MISSING_FILES_for_SVN_30456.7z