log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Elsear brings super-fast Networking to Risc PC/A7000/A7000+ (News:)
- Latest hardware upgrade from RISCOSbits (News:)
- RISCOSbits releases a new laptop solution (News:4)
- Announcing the TIB 2024 Advent Calendar (News:2)
- RISC OS London Show Report 2024 (News:1)
- Code GCC produces that makes you cry #12684 (Prog:39)
- Rougol November 2024 meeting on monday (News:)
- Drag'n'Drop 14i1 edition reviewed (News:)
- WROCC November 2024 talk o...ay - Andrew Rawnsley (ROD) (News:2)
- October 2024 News Summary (News:3)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: Games: Fire & Ice loading issues
 
  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 ]
 

The Icon Bar: Games: Fire & Ice loading issues