| |
Fire & Ice loading issues |
| |
sirbod (15:27 1/10/2012)
TomWalker (17:22 1/10/2012)
sirbod (21:04 1/10/2012)
|
| |
|
Jon Abbott |
Message #121143, posted by sirbod at 15:27, 1/10/2012 |
Member
Posts: 563
|
Fire & Ice doesn't work on a lot of machines, having researched this over the past few days, the reason for this is:
1. It requires an HD capable drive (this was known already)
2. It relies on a bug/feature when the 710/771 chipset is present
The bug/feature:
DIM A% 72
DIM B% 16*1024
!A%=&0202050A
A%!16=&C8000
A%!64=&20000000
I% = 1<<4 : REM 0 for track read, 1<<4 for sector ID read
SWI "OS_DiscOp", 0, 3 + (A% << 6) + I%, 0, B%
The above code will return the list of sector ID's for Track 0 of a floppy. Setting I% to 0 will return the complete track data.
If a 710/771 is present however, only sector ID's are returned, regardless of the value of I%.
Fire & Ice relies on this bug, expecting a list of sector ID's when its actually requesting the track data.
There's actually a second bug. If a list of sector ID's is requested as above, A%?1 should be set to the number of sectors per track - this doesn't happen on a 710/711, but does on a 1772.
I'm uncertain if DiscOp 3 is not fully implemented in the 710/711 or if these are bugs in RISC OS. Does anyone have any detailed documentation on the 710/711?
I've verified this behaviour on an A440/1, A5000 both running RO3.11 and a RiscPC running RO3.5 and RO3.7 |
| |
 [ Log in to reply ] |
| |
|
Tom Walker |
Message #121144, posted by TomWalker at 17:22, 1/10/2012, in reply to message #121143 |
Member
Posts: 25
|
This isn't really a bug, more of an odd implementation. The 710/771 (and all compatibles) aren't capable of implementing the 'Read Track' DiscOp 3; the Read Track command only returns data fields, whereas the 177x Read Track command returns everything. (http://web.archive.org/web/20060220001947/http://www.pinknoise.demon.co.uk/Docs/Arc/ADFS/Flp/FlpSpec.html seems to suggest that the original plan was to fail DiscOp 3)
Therefore Acorn seem to have implemented DiscOp 3 as the Read ID command, which was/is intended for hard discs.
I'm a little confused by your description of Read ID, it doesn't seem to match the PRMs. You seem to have I% backwards, though the 710/771 floppy drivers do ignore it, always setting the maximum ID count to 64. I've seen no mention of A%?1 setting the number of sectors per track - I suspect that actually Acorn screwed up when implementing this DiscOp for both FDCs.
Detailed documentation for the 710 - the datasheet is at http://www.chiark.greenend.org.uk/~theom/riscos/techdocs.html, though as the FDC part is an enhanced µPD765 you could use any number of datasheets.
[Edited by TomWalker at 18:23, 1/10/2012]
[Edited by TomWalker at 18:24, 1/10/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121145, posted by sirbod at 21:04, 1/10/2012, in reply to message #121144 |
Member
Posts: 563
|
This isn't really a bug, more of an odd implementation. The 710/771 (and all compatibles) aren't capable of implementing the 'Read Track' DiscOp 3 I figured as much, but couldn't find an Acorn data sheet to confirm.
You seem to have I% backwards PRM2-225 states:
If the alternate defect list option bit (bit 4) is set in R1 on entry when reading a track/ID, then a whole track’s worth of ID fields is read.
This matches the behaviour I'm seeing on a 1772.
I've seen no mention of A%?1 setting the number of sectors per track - I suspect that actually Acorn screwed up when implementing this DiscOp for both FDCs. Again, PRM2-225 states:
The disc record provided is updated to return the actual number of sectors per track found (at offset 1). Note to use this option you must provide a valid defect list, which at a minimum is a word of &20000000 following on after the disc record.
It's implemented correctly in the 1772 driver, but seems to be missing in the 710/710 driver. |
| |
[ Log in to reply ] |
| |
|
