Here is my test code:
Code: Select all
10DIM BLOCK% 100 20D%=&2000 30?BLOCK%=0 40BLOCK%!1=D% 50BLOCK%?5=3 60BLOCK%?6=&53 : REM READ SECTOR 70BLOCK%?7=0 : REM TRACK 80BLOCK%?8=0 : REM SECTOR 90BLOCK%?9=&22 : REM TWO SECTORS 100X%=BLOCK% 110Y%=X%/256 120A%=127 130CALL &FFF1
If I turn the CoPro on (*FX151 230 1) and run it... the data loads at &130A instead. In testing with TurboMMC, and using BeebEm for comparison:
1) BeebEm no CoPro: works
2) BeebEm with 65C02 CoPro: works
3) BBC B with no CoPro and TurboMMC: works
4) BBC B with Matchbox CoPro and TurboMMC: loads at &130A
5) Master with no CoPro and TurboMMC: works
6) Master with John Kortink's internal 65C102 and TurboMMC: loads at &130A
(in fact there were two BBC B's; one issue 4, one issue 7, both the same results).
It doesn't matter what I set D% to, it always loads at 130A which makes me wonder if the OSWORD 7F routine is corrupting the address value somewhere.
I was told SmartSPI also worked with TurboMMC (it seems to!), so I tested that (tests 3 and 4)... exactly the same results. The sectors are loaded at &130A. This makes me think there might be a problem with the code going all the way back to Martin's original routines.
This normally has no impact (it seems to require OSWORD 7F and a copro to exercise it) so I'm not too surprised it hasn't been seen before. The Z80 copro uses it to try and load CPM, which is where I saw it.
Can anyone else verify this? Is my code just bad and wrong (it works on BeebEm...) or is there a bug?
Duikkie? Dunno if you're in a position to test/verify...