Tibor Biczo

Looking at the chis log of Dragon Wars, it did transfer a complete sector to the machine, plus 1 byte which is the error code, that is set to #$27, and it expects #$01, that's why it resets. Drive code look like: Command loop is at $43e. reads 3 byte from computer first byte is command goes to $d1, then track number goes into $e, then sector number goes into $f Command 3 looks like format located at $4be Command 2 is write sector located at $48c Command 1 is read sector at $459 Load sector subroutine...

Run a disam tool on the test program, attached the asm file. It's very simple, just testing the unconnected lines on port b and on port c. As a side effect it changes direction and port values on the connected lines as well, but those are not tested. I'll come back to Dragon Wars later.

Attached a rudimentary test app, loads from $2000-$2060, start with G2000 runs the test, writes the result into $2060 and exits to monitor. #$01 in $f2060 means pass, #$02 means fail. I'm not familiar with the testbench framework, so the test needs to be adapted for it. Rechecked all apps with 3.61., 3.7, 3.8, 3.9 and 3.9 r45735. Each version shows the same issues Unconnected bits show as 1 when data direction is set to input BT I stucks at track 1 BT II stucks at track 3 Dragon Wars sticks at track...

Broken 1551 port handling in xplus4, bug exhibits in Bards Tale, Bards Tale II