And of course I forgot one label on my chart above:

VIDOUT = video output from DC011 video ASIC

CP/M finally.


This only works if the index pulse irq is suppressed when the fdc is busy. I'd like to know if there are any other examples of currently working machines/software when enables the index pulse irq before submitting to make sure it doesn't break anything.

*opens virtual bottle of beer*

Cheers!

Great news ... but the case of the missing irq is strange indeed ... maybe something with the esoteric RX50 drives?

That actually makes some sense that the index pulses wouldn't be passed on while the FDC was busy, but yeah it definitely needs a lot of regression testing.

I can't find any other software which even enables the index pulse irq much less is regressed with this change. There are just so many machines with fd197x fdcs though, I can't test them all.

board config option maybe, with default as the old way?

The old fd197x emulation had many per-machine hacks. Don't really want to go there again.

Hello,

have tracked down a weird CPU bug: if i do a soft reboot from within SETUP with CTRL-SETUP (a key combination from the the manual) the Z80 corrupts the 808x address space with stack data.

What i found out:

* BIOS begins an extensive memory test (BITTEST_AX) -

https://github.com/shattered/retro-bios/...-022e5-00#L3931

* problem gets visible at this location:

https://github.com/shattered/retro-bios/...-022e5-00#L4175

- BX is current address
- AL contains XOR result of correct and actual value

Z80 writes to $07f0/$07f1 (reflected at 808x offset $87f0/$87f1).

RESULT: ERROR 19 Main Board RAM (0-64K)

Why does the Z80 interfere with the memory test?

There is a reasonable suspicion the ZFLIP flag is set or handled wrongly. I just cant find where...

P.S.: floppy test on the DIAG.DISK (from 'indiviual tests') now aborts with a 'Z80 response error'. Coincidence?

Any ideas? :-)

Screenshot of Z80 caught in the act:

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

are the flags reset to their appropriate values in device_reset? if anything is only set in device_init and not _reset, and/or is not reset properly by whatever the ctrl-setup reset function does (does it somehow activate one of the reset lines on the board itself thru an i/o port, sort of like how the RESET opcode on the 68000 causes the reset pin to output 5v?)

LN

(Unrelated to Bavarese's problem):
If you run the rainbow driver compiled from latest git, you get