Home Page Forums MAME MAME Requirements?

Well, DEC manuals state the FDC code has a 'sweet spot' (whatever that tells us). I may have to look that paragraph up.

(i dont want to argue...)

Found a description of the wait state logic, as described by DEC:

(Technical manual, PDF page 115)

WAIT logic (DUELL schmatics, saved from Shoutbox):


Sorry for the bad quality.

I believe that MAME currently doesn't do dynamic wait states, so if the software depends on it, it propably needs to be faked somehow by the driver.

I have a similar problem with the lack of DTACK for the 68K which can stretch the access time when accessing slow devices. I'd really like to see a propert DTACK working but I am not even close to that level of understanding yet.

68k Macs have some magic where you can do a DWORD read of the 5380 SCSI controller and it'll freeze the processor via DTACK until 4 bytes come in over the SCSI bus. That's the situation where no DTACK is fatal. If it's just causing a wait state, you can m_maincpu->adjust_icount(cycles) to add more cycles to the access. (the # of cycles must be *negative* to have a wait state, a positive number makes the CPU effectively speed up on access instead ;-)

Ahh, interesting, that might help to implement VME bus accesses too, I'll have a look at it.

Command $1C (SEEK_WITH_VERIFY) does not work as intended.

The diagnostic routines (RX50 DIAG.DISK) appear to use it extensively for READ and WRITE tests. Where is the bug?

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/SEEK_WITH_VERIFY_FAILS_1.jpg

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/SEEK_WITH_VERIFY_FAILS_2.jpg

Hint: there is a disassembly of the main BIOS routines for the Z80 at

https://github.com/shattered/retro-bios/tree/master/dec-rainbow100b

Search for WRITE and 1Ch.

A SEEK_WITH_VERIFY (command $1c) ends with FORCE_INTERRUPT (c=d0) instead of SCAN_ID. I cant figure out why.

Output from log file ("IRQ REQUEST OBTAINED" stems from my own driver)
..
[:fd1793x] SEEK_WAIT_STEP_TIME_DONE
[:fd1793x] SEEK_MOVE
[:fd1793x] SEEK_WAIT_STEP_TIME_DONE
[:fd1793x] SEEK_WAIT_STABILIZATION_TIME_DONE
[:fd1793x] SEEK_DONE
[:fd1793x] SEARCH_ADDRESS_MARK_HEADER in case SEEK_DONE
[:fd1793x] Initiating command d0 <------------- ???
[:fd1793x] Forced interrupt (c=d0) <------------- ???
...

_SHOULD_ LOOK LIKE THIS:

[:fd1793x] SEEK_MOVE
[:fd1793x] SEEK_WAIT_STEP_TIME_DONE
[:fd1793x] SEEK_WAIT_STABILIZATION_TIME_DONE
[:fd1793x] SEEK_DONE
[:fd1793x] SEARCH_ADDRESS_MARK_HEADER in case SEEK_DONE
[:fd1793x] SCAN_ID <<<< ----------------
[:] FLOPPY - IRQ REQUEST OBTAINED: TRUE <<<< ------------ OK
[:] FLOPPY - IRQ REQUEST OBTAINED: false

I can't get it to boot at all. Is there some procedure to make it work?

Thanks for jumping in. Just activate the keyboard workaround, as follows:

Necessary header files (important):
https://dl.dropboxusercontent.com/u...W-100_KEYBOARD_WORKAROUND_2016_05_30.zip

Without it, emulation stops with fatal ERROR 13 (keyboard stuck). R.Belmont already has spent considerable time on this one, and might know more.

Note that the workaround patches the BIOS heavily. It is the only way to get the machine going (for now).

- because the workaround disables standard BIOS procedures, you will also need a proper NVRAM file for 832 K:

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/nvram_832.zip

Please set max. RAM accordingly in DIP settings (RAM = 832K; important).

- The RX50DIAG image is very valueable when testing. Especially READ and WRITE tests (available under INDIVIDUAL TESTS, with key 3, then 4 for FLOPPY TESTS) and also SYSTEM INTERACTION - because it hangs emulation.

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/rx50diag.td0

- Force interrupt ($D0 or $D4) kicks in sooner or later, and SEEK_WITH_VERIFY or SCAN_ID fails (see RX50DIAG, again).

I suspect the Z80 runs too fast now (as I-O and MEMORY WAIT states aren't properly implemented; compare diagrams above).

There is an option to STALL_ON_WAIT for the Z80 and i experimented with it, without success...

- Work in progress (no guarantees) -

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/rainbow.cpp

Of course, it could also be a silly bug i overlooked for years (e.g. interrupt handling and arbitration in update_8088_irqs @ rainbow.cpp changed at some point, and it is unclear if it is presently correct).


- To help with emulation, i have disassembled most parts of the Rainbow BIOS and put it on Github, available under

https://github.com/shattered/retro-bios/tree/master/dec-rainbow100b

Ask me anytime if you need more details

P.S.: help with untangling the monolithic driver would be very welcome

I believe there should be an interrupt right here as enabling the transmitter should cause txrdy to go high. That interrupt ought to cause the reset command to be sent to the keyboard.

Edit: CTS is tied to ground on the schematic so it set to 0. That what is blocking the irq.

Is the CTS pin on the uart supposed to be the direct CTS pin state (translated from rs232 voltage as described below in a direct fashion through a voltage divider) or the inverted state (through a discrete voltage divder+inverter or an inverting receiver)? This makes a big difference. The datasheet should say.

RS232 Voltage:
-3 to -25VDC is MARK (OFF for control lines like CTS, for serial tx/rx this is the '1' state)
3 to 25VDC is SPACE (ON for control lines like CTS, for serial tx/rx this is the '0' state, and if held this way for more than 8/9 bit cycles counts as a serial BREAK))

MC1489 is an example of a quad rs232 receiver.

LN