The error numbers returned indicate the type of error encountered.
Exactly why slightly more meaningful messages are not returned I am unsure.
The error codes meanings are as follows :-
ST506 error codes &01 ABT Command abort has been accepted &02 IVC Invalid command &03 PER Command parameter error &04 NIN Head positioning, disc access, or drive check before SPC has been issued &05 RTS TST command invalid after SPC &06 NUS USELD for a selected drive has not been returned &07 WFL Write fault has been detected on the ST506 interface &08 NRY Ready signal has been negated &09 NSC Seek completed (SCP) wasn't returned before a timeout &0A ISE SEK, or disc access command issued during seek &0B INC Next cylinder address greater than number of cylinders &0C ISR Invalid step rate: highest-speed seek specified in normal seek mode &0D SKE SEK or disc access command issued to drive with seek error &0E OVR Data overrun (memory slower than drive) &0F IPH Head address greater then number of heads &10 DEE Error Correction Code (ECC) detected an error &11 DCE CRC error in data area &12 ECR ECC corrected an error &13 DFE Fatal ECC error in data area &14 NHT In CMPD command data mismatched from host and disc &15 ICE CRC error in ID field (not generated for ST506) &16 TOV ID not found within timeout &17 NIA ID area started with an improper address mask &18 NDA Missing address mark &19 NWR Drive write protected IDE errors - As ST506, except: &02 IVC Command aborted by controller &07 WFL Write fault &08 NRY Drive not ready &09 NSC Track 0 not found &13 DFE Uncorrected data error &16 TOV Sector ID field not found &17 NIA Bad block mark detected &18 NDA No data address mark &20 No DRQ when expected &21 Drive busy when commanded &22 Drive busy on command completion &23 Controller did not respond within timeout &24 Unknown code in error register
DiscKnight, from the ARM Club, is the recommended repair tool, which fixes both the standard and RISC OS 4 long filename formats. It's available for the budget price of 10ukp and includes free support. A checking only version is available for free download from the DiscKnight website at discknight.riscos.org
A shareware utility called 'fsck' is available to download from www.monesi.com/sergio/fsck.html and works reliably. However it doesn't support RISC OS 4 F+ format discs. A commercial version of fsck was available from Oregan Deveopments, as Oregan Disc Doctor. This is no longer available.
Another commercial disc repair application was available from Look Systems, called ADFS Rescue which also appears to be no longer available. Look Systems can be found at http://www.looksystems.org.uk/
Paul Vigay's Disc Commander application will allow you to edit bad sectors by hand and will work with the new F+ format discs under RISC OS 4 or above. However, it does have automated recovery, so is mainly designed for people who feel competant at manually editing sectors and want a powerful tool for performing disc operations. More information can be found at www.vigay.com/software/commander.html
The power on self test was introduced with RISC OS 3.0 and later versions of the OS. On power up your machine checks the hardware for physical faults before letting you use it, hopefully signalling important errors to you before further hardware damage can result.
The purple screen at power on indicates that the self-test has begun. A brief ROM, RAM, VIDC and IOC test is performed and then the screen colour changes to blue and a limited memory test [1] is performed, along with a second test of the VIDC and IOC. When the screen returns to purple, the machine is testing for an ARM3 (or better). At the end of this sequence the screen colour is set to green (for pass) or red (for fail). If the tests have all passed then the machine starts to boot and the RISC OS welcome screen is displayed.
RISC OS Select introduced some more tests (and screen colours). For detailed documentation on Select system initialisation, see select.riscos.com/prm/startup/systeminit.html
If any test fails, the screen will remain red and the disc drive light will blink a fault code. A short flash is used to indicate a binary '0' and a long flash indicates a binary '1'. The bits are grouped into eight nybbles (blocks of four bits) with the most significant bit first.
The lowest seven bits are a status word. The meaning of each bit is given below in hex :-
00000001 Self-test due to power on 00000002 Self-test due to interface hardware 00000004 Self-test due to test link 00000008 Long memory test performed 00000010 ARM ID detected (ARM 3 fitted for non-RiscPC hardware) 00000020 Long memory test disabled 00000040 PC-style IO world detected 00000080 VRAM detected
Bits 8-31 indicate the fault code and are described below. Not all the bits are used. If the code is marked as reserved on the RiscPC this means that error number is currently either unassigned or it's meaning on older hardware is no longer sensible for the newer machines (and thus it's meaning may be reassigned on the newer versions of the OS.)
00000100 CMOS RAM checksum error 00000200 ROM failed checksum test 00000400 MEMC CAM mapping failed (A reserved code on the RiscPC) 00000800 MEMC protection failed (A reserved code on the RiscPC) 00001000 (A reserved code on the RiscPC) 00002000 (A reserved code on the RiscPC) 00004000 VIDC Virq (video interrupt) timing failed 00008000 VIDC Sirq (sound interrupt) timing failed 00010000 CMOS unreadable 00020000 RAM control line failure 00040000 Long RAM test failure 00080000 (A reserved code on the RiscPC)
Some third party VIDC enhancers on older hardware trigger the self test to fail. If you are getting a failed self test with a VIDC enhancer, yet the machine is working fine, enter and run this BASIC program and then save your CMOS settings :-
REM Toggle state of power on self test bit in CMOS REM Read byte SYS "OS_Byte",161,&BC TO ,,byte% REM EOR byte with mask for bit 1 byte% = byte% EOR %10000000 REM Write byte back again SYS "OS_Byte",162,&BC,byte% END
This modifies the self test to cope with the VIDC enhancer.
[1] By limited it meant that it verifies the VRAM, if present, and checks the first 4 MB of RAM in the machine. (Or so I am told.)
This is a problem caused most often by 'rogue' software chatting to the IIC bus and incorrectly setting the pause bit on the RTC control register.
Symptoms of this happening are that the time is always the same every time you reboot and the software clock tends to run slightly slow (losing about a minute every hour or so.). If you are experiencing these symptoms this program should restart your RTC clock :-
REM poke RTC control register REM Bit 0 1 REM 7 Count ResetDivider REM 6 Count HoldLastCount REM write 0 for normal operation, write &80 or &40 freezes RTC DIM cmosdata% 16 !cmosdata%=&00000000 REM write 0 twice to RTC, first 0 is address- control reg REM second is control reg value 0 is default i.e. clock on SYS &240, &A0, cmosdata%,2 END
You will need to reset the time after running this program but hopefully your RTC will keep the correct time from here on in.
If the same symptoms persist after trying this program contact your local Acorn dealer as something more serious has gone wrong. Note that to check that the symptoms are persisting you must reboot your machine after running this program and having set the time. This is due to the way RISC OS maintains a 'soft' copy of the real time clock and until you reboot it will not be obvious whether your RTC has indeed started working again.
The *Speaker command does not work on newer RISC OS machines. The A300, A400, A3000, A540, A5000 and A4 all had software control of the built-in speaker. With newer machines this feature has been removed in favour of a automatic hardware cut off of the speaker when a jack is inserted into the sound socket on the machine.
However to ensure compatibility with old software the command *Speaker has been left in the OS, it merely doesn't do anything.
This is a problem primarily with the Risc PC machines caused by the fan lubrication drying out. Symptoms generally include the fan making a lot of noise when the machine starts and then, once warmed up, the noise going away. Progressively the amount of warm up time gets longer and longer.
The solution, and this should only be attempted if you are confident in handling your machine's internal components, is to strip the machine down to it's base slice. Remove the label from the fan and the rubber bung from the bearing. Place a drop of three-in-one oil (and not WD40) on the bearing. Replace the bung and reassemble the machine, your problem should be cured.
This is generally caused by upgrading machines fitted with slower CD Rom drives to RISC OS 4 and is caused by the CDFSSoftATAPI module trying to access the drive too fast. One remedy is to obtain a soft-loadable version of CDFSSoftATAPI from RISC OS 3.7, copy it into your !Boot.Choices.Boot.PreDesk directory and then *UNPLUG the CDFSSoftATAPI module in RISC OS 4.
Please feel free to email me if you encounter this problem because I encountered it myself upon fitting RISC OS 4.
Such freezing during Filer redraws can be caused by applications using 256 colours sprites without a palette (it's a bug in RISC OS 3.7). Only sprites private to the task trigger the problem, not the icons used by the Wimp (those in files !Sprites and !Sprites22). Note which applications are loaded when the freezing occurs and add a palette to any 256 colours sprite they use.
There are so many drives and interfaces available, it's not feasible to maintain a complete list in the FAQ itself. Therefore I've compiled a comprehensive list of compatible IDE drives which is available online at www.riscos.org/legacy/drives.html
Most modern drives have this information on a label on the drive itself.
A list of drive settings for some of the older drives is maintained at www.riscos.org/legacy/drives.html#links
Due to an obscure interaction between Acorn's IDE implementation and the Western Digital drives a problem occurs in that the computer becomes unable to find the Boot record that details the shape, format and other data of the hard drive. This results in a somewhat alarming and frustrating series of error messages that seem to indicate that the drive isn't formatted at all.
(And by extension implying that you have lost all your information stored on the drive.)
Fortunately that isn't the case. In reality your information is safe and sound on the drive and you merely need to give ADFS a helping hand in finding the boot record, after which it can carry on as normal. This BASIC program supplies dummy values to ADFS that allow it to do that.
REM< Specify drive%=4 DIM rec% 64 FOR I%=0 TO 60 STEP 4:rec%!I%=0:NEXT rec%?00= 9 : REM Sector size, 2^9 = 512 rec%?01= 8 : REM Sectors per track rec%?02= 1 : REM Heads rec%!16=4096 : REM Disc size in bytes rec%?41= 0 : REM LBA mode disabled SYS "ADFS_SectorDiscOp",,15+(rec%<<6),drive%<<29 END
(Thanks to Eduard Pfarr for this program.)
Running this program once, during boot up, will allow the drive to be used normally. This does mean, for the moment, that you cannot boot from a Western Digital IDE drive.
NB for RISC OS 3.10, or earlier versions of RISC OS, you will need to replace the ADFS_SectorDiscOp with an ADFS_DiscOp call instead.
The FAQ used (up to March 2008) to contain a comprehensive list of various peripherals, such as hard discs, magneto-optical drives, tape, CD-rom, and related interfaces etc. However, this list was vastly out of date and aimed mainly at legacy Acorn machines.
Because the list was largely irrelevant to the majority of readers, the list has now been archived at http://www.riscos.org/legacy/peripherals.html
The Iyonix takes 128MB, 256MB, 512MG or 1GB 184 pin DDR RAM rated at 200 or 266MHz. PC manufacturer PC2100 (CL2.5) RAM should be ok.
RAM for the RiscPC, while a standard 72pin SIMM, must be bought with a degree of care to avoid potential damage to your machine. EDO RAM, while it will work, is not advised as it may have different power requirements that could be detrimental to your machine.
The RAM required is 70ns (or faster), 72pin, square array (equal number of bits used for row and column addressing), non-parity RAM that supports 'fast page mode' and 'CAS before RAS' refresh. Devices that contain more than 16 memory chips (8 on each side) is not recommended as they may have power requirements above and beyond what the computer can safely supply.
Consequently SIMM 'stackers' and 30 to 72pin adaptors are also not advised.
For the more technically inclined out there maximum loads possible are:-
Address 128pF WE 140pF CAS or RAS 59pF Data bus 29pF
Finally, in the maintainers experience anyway, Hitachi parts seem to be fine.
The Risc PC Kinetic update uses 64MB, 128MB or 256MB (RISC OS 4.39 or above required for 256MB) SODIMM memory modules.
The A7000 range of machines take Fast Page Mode (FPM) SIMMS.
RISC OS 3.5 and earlier can only support drives up to 512MB. For maximum efficiency, it's recommended that you format the drive to 499MB.
RISC OS 3.6 to 3.7, on Risc PC or A7000 hardware can support up to 128GB drives. ADFSBuffers should be configured to 0. Due to an inefficient file allocation system (see Q3.15) RISC OS 3.6 & 3.7 is wasteful of disc space if you're storing a large number of very small files.
N.B. Some older interfaces may not support more than 20GB due to old style code which only addresses the first 20GB.
RISC OS 4 and above can support up to 128GB drives. The Iyonix hardware will support drives of up to 256GB but UDMA is only supported on the first 128MB.
Most modern drives over 40GB won't work when connected to the RPC motherboard interface. Instead, it's recommended you fit a third-party IDE interface capable of handling large drives i fyou want to use drives larger than 40GB.
This is a complicated question to answer with any hard and fast rules.
For starters the media and filing system being used must be considered. If you are using an IDE drive under ADFS then you usually should have your drive formatted as one whole partition due to ADFS' inability to support multiple partitions. (Although third party extensions, like Alsystems PowerIDE software, can extend the default IDE interface to include partioning.) However this is not always true and sometimes it can be beneficial to sacrifice a few Mbs of partition size to gain tens of Mb savings in reduced space wastage when storing files.
RISC OS uses, and through FileCore virtually all filing systems share this, a fairly complicated map system that tries to make a reasonable compromise between filing system overheads, speed and flexibility. For drives 512Mb or less this system works quite well. With the advent of easily available multiple Gb size drives the system begins to suffer a little.
For reasons that are beyond the scope of the FAQ to explain RISC OS links the LFAU (Large File Allocation Unit) to the minimum object size on a disc by a ratio of sixteen to one. Thus a two byte sized file occupies a minimum of sixteen kilobytes of actual disc space to store. There is an important exception to this involving the sharing of map entries, and thus disc space, but the general rule is as above. This table summarises the relationship between LFAU, disc size and minimum object size.
lfau max disc size min object 1K 499M bytes 16kb 2K 998M bytes 32kb 4K 1996M bytes 64kb 8K 3992M bytes 128kb
Consequently it can be easily seen that the larger the partition size the larger the individual file overheads of storing it becomes. (NB It is worth pointing out that Image Filing systems do not share this overhead directly.)
Thus which partition size you should aim for depends on what you intend doing with the drive. If you are primarily storing Replay films then given the multi-megabyte size of the files the overheads required for storing each file is percentage wise less and it is more important to have bulk disc storage available than it is efficiency of space utilisation. On the other hand running a news spool will involve thousands of files averaging around the seven kilobyte mark, thus a smaller partition size will greatly reduce space wastage to filing system overheads.
In the FAQ maintainers experience a good compromise size seems to be the just sub one gigabyte mark.
No current filing systems support over 2GB.
Part 2 - Upgrades and Expansion | Part 4 - RISC OS Configuration
Last edit: 10th Apr 2016 at 4:55pm (3108 days ago) |
|
| ||||||||||||||||||||