Home » Recent acquisitions » Acorn ADFS disks » adfs_ArchimedesWorld_199201.adf » January92 » !AWJan92/Goodies/ArcAut/Misc/BugReport
!AWJan92/Goodies/ArcAut/Misc/BugReport
This website contains an archive of files for the Acorn Electron, BBC Micro, Acorn Archimedes, Commodore 16 and Commodore 64 computers, which Dominic Ford has rescued from his private collection of floppy disks and cassettes.
Some of these files were originally commercial releases in the 1980s and 1990s, but they are now widely available online. I assume that copyright over them is no longer being asserted. If you own the copyright and would like files to be removed, please contact me.
Tape/disk: | Home » Recent acquisitions » Acorn ADFS disks » adfs_ArchimedesWorld_199201.adf » January92 |
Filename: | !AWJan92/Goodies/ArcAut/Misc/BugReport |
Read OK: | ✔ |
File size: | 060E bytes |
Load address: | 0000 |
Exec address: | 0000 |
File contents
There exists a possible bug in either ArcAut or the OS: Install ArcAut, bring up the task manager & then set the Ram Disc to zero (NB if it is already zero, still drag it's bar to some positive value & then back to zero); now set free space to zero by dragging, say, sprite size to maximum; finally, drag an automaton file onto ArcAut - the program will hang up, requiring a reset to regain control. I have traced the problem to a call to the module TransRamFS, whose purpose is to transfer memory from 'freespace' to 'RamFS', if the space required in RamFS isn't currently available. Within this, a call to 'OS_ChangeDynamicArea' (R0=5 for RamFS) is the source of the problem. Under the circumstances described above it should return control to an error handler (here, this is the module itself, as the 'X' prefix is used); it fails to return control either to the module or to another error handler. The curious point is that even if RamFS is already zero, this problem only arises if you first drag the size bar up & then back to zero, which should of course make no difference (if you don't do this, the module behaves correctly, informing the user that it cannot allocate the memory to RamFS that was requested). Perhaps this suggests that the OS is at fault? In practice this doesn't cause much difficulty, as the conditions don't frequently occur under normal use. Nevertheless you should be warned. If you can explain and/or remedy this please let me know. Michael Rozdoba 10 Octavia Close Bedlington Northumberland NE22 6LG
00000000 0a 20 54 68 65 72 65 20 65 78 69 73 74 73 20 61 |. There exists a| 00000010 20 70 6f 73 73 69 62 6c 65 20 62 75 67 20 69 6e | possible bug in| 00000020 20 65 69 74 68 65 72 20 41 72 63 41 75 74 20 6f | either ArcAut o| 00000030 72 20 74 68 65 20 4f 53 3a 0a 0a 20 49 6e 73 74 |r the OS:.. Inst| 00000040 61 6c 6c 20 41 72 63 41 75 74 2c 20 62 72 69 6e |all ArcAut, brin| 00000050 67 20 75 70 20 74 68 65 20 74 61 73 6b 20 6d 61 |g up the task ma| 00000060 6e 61 67 65 72 20 26 20 74 68 65 6e 20 73 65 74 |nager & then set| 00000070 20 74 68 65 20 52 61 6d 20 44 69 73 63 20 74 6f | the Ram Disc to| 00000080 20 7a 65 72 6f 0a 28 4e 42 20 69 66 20 69 74 20 | zero.(NB if it | 00000090 69 73 20 61 6c 72 65 61 64 79 20 7a 65 72 6f 2c |is already zero,| 000000a0 20 73 74 69 6c 6c 20 64 72 61 67 20 69 74 27 73 | still drag it's| 000000b0 20 62 61 72 20 74 6f 20 73 6f 6d 65 20 70 6f 73 | bar to some pos| 000000c0 69 74 69 76 65 20 76 61 6c 75 65 20 26 20 74 68 |itive value & th| 000000d0 65 6e 0a 62 61 63 6b 20 74 6f 20 7a 65 72 6f 29 |en.back to zero)| 000000e0 3b 20 6e 6f 77 20 73 65 74 20 66 72 65 65 20 73 |; now set free s| 000000f0 70 61 63 65 20 74 6f 20 7a 65 72 6f 20 62 79 20 |pace to zero by | 00000100 64 72 61 67 67 69 6e 67 2c 20 73 61 79 2c 20 73 |dragging, say, s| 00000110 70 72 69 74 65 20 73 69 7a 65 20 74 6f 0a 6d 61 |prite size to.ma| 00000120 78 69 6d 75 6d 3b 20 66 69 6e 61 6c 6c 79 2c 20 |ximum; finally, | 00000130 64 72 61 67 20 61 6e 20 61 75 74 6f 6d 61 74 6f |drag an automato| 00000140 6e 20 66 69 6c 65 20 6f 6e 74 6f 20 41 72 63 41 |n file onto ArcA| 00000150 75 74 20 2d 20 74 68 65 20 70 72 6f 67 72 61 6d |ut - the program| 00000160 20 77 69 6c 6c 20 68 61 6e 67 0a 75 70 2c 20 72 | will hang.up, r| 00000170 65 71 75 69 72 69 6e 67 20 61 20 72 65 73 65 74 |equiring a reset| 00000180 20 74 6f 20 72 65 67 61 69 6e 20 63 6f 6e 74 72 | to regain contr| 00000190 6f 6c 2e 0a 0a 20 49 20 68 61 76 65 20 74 72 61 |ol... I have tra| 000001a0 63 65 64 20 74 68 65 20 70 72 6f 62 6c 65 6d 20 |ced the problem | 000001b0 74 6f 20 61 20 63 61 6c 6c 20 74 6f 20 74 68 65 |to a call to the| 000001c0 20 6d 6f 64 75 6c 65 20 54 72 61 6e 73 52 61 6d | module TransRam| 000001d0 46 53 2c 20 77 68 6f 73 65 20 70 75 72 70 6f 73 |FS, whose purpos| 000001e0 65 0a 69 73 20 74 6f 20 74 72 61 6e 73 66 65 72 |e.is to transfer| 000001f0 20 6d 65 6d 6f 72 79 20 66 72 6f 6d 20 27 66 72 | memory from 'fr| 00000200 65 65 73 70 61 63 65 27 20 74 6f 20 27 52 61 6d |eespace' to 'Ram| 00000210 46 53 27 2c 20 69 66 20 74 68 65 20 73 70 61 63 |FS', if the spac| 00000220 65 20 72 65 71 75 69 72 65 64 20 69 6e 0a 52 61 |e required in.Ra| 00000230 6d 46 53 20 69 73 6e 27 74 20 63 75 72 72 65 6e |mFS isn't curren| 00000240 74 6c 79 20 61 76 61 69 6c 61 62 6c 65 2e 20 57 |tly available. W| 00000250 69 74 68 69 6e 20 74 68 69 73 2c 20 61 20 63 61 |ithin this, a ca| 00000260 6c 6c 20 74 6f 0a 27 4f 53 5f 43 68 61 6e 67 65 |ll to.'OS_Change| 00000270 44 79 6e 61 6d 69 63 41 72 65 61 27 20 28 52 30 |DynamicArea' (R0| 00000280 3d 35 20 66 6f 72 20 52 61 6d 46 53 29 20 69 73 |=5 for RamFS) is| 00000290 20 74 68 65 20 73 6f 75 72 63 65 20 6f 66 20 74 | the source of t| 000002a0 68 65 20 70 72 6f 62 6c 65 6d 2e 20 55 6e 64 65 |he problem. Unde| 000002b0 72 0a 74 68 65 20 63 69 72 63 75 6d 73 74 61 6e |r.the circumstan| 000002c0 63 65 73 20 64 65 73 63 72 69 62 65 64 20 61 62 |ces described ab| 000002d0 6f 76 65 20 69 74 20 73 68 6f 75 6c 64 20 72 65 |ove it should re| 000002e0 74 75 72 6e 20 63 6f 6e 74 72 6f 6c 20 74 6f 20 |turn control to | 000002f0 61 6e 20 65 72 72 6f 72 0a 68 61 6e 64 6c 65 72 |an error.handler| 00000300 20 28 68 65 72 65 2c 20 74 68 69 73 20 69 73 20 | (here, this is | 00000310 74 68 65 20 6d 6f 64 75 6c 65 20 69 74 73 65 6c |the module itsel| 00000320 66 2c 20 61 73 20 74 68 65 20 27 58 27 20 70 72 |f, as the 'X' pr| 00000330 65 66 69 78 20 69 73 20 75 73 65 64 29 3b 20 69 |efix is used); i| 00000340 74 0a 66 61 69 6c 73 20 74 6f 20 72 65 74 75 72 |t.fails to retur| 00000350 6e 20 63 6f 6e 74 72 6f 6c 20 65 69 74 68 65 72 |n control either| 00000360 20 74 6f 20 74 68 65 20 6d 6f 64 75 6c 65 20 6f | to the module o| 00000370 72 20 74 6f 20 61 6e 6f 74 68 65 72 20 65 72 72 |r to another err| 00000380 6f 72 20 68 61 6e 64 6c 65 72 2e 0a 0a 20 54 68 |or handler... Th| 00000390 65 20 63 75 72 69 6f 75 73 20 70 6f 69 6e 74 20 |e curious point | 000003a0 69 73 20 74 68 61 74 20 65 76 65 6e 20 69 66 20 |is that even if | 000003b0 52 61 6d 46 53 20 69 73 20 61 6c 72 65 61 64 79 |RamFS is already| 000003c0 20 7a 65 72 6f 2c 20 74 68 69 73 20 70 72 6f 62 | zero, this prob| 000003d0 6c 65 6d 20 6f 6e 6c 79 0a 61 72 69 73 65 73 20 |lem only.arises | 000003e0 69 66 20 79 6f 75 20 66 69 72 73 74 20 64 72 61 |if you first dra| 000003f0 67 20 74 68 65 20 73 69 7a 65 20 62 61 72 20 75 |g the size bar u| 00000400 70 20 26 20 74 68 65 6e 20 62 61 63 6b 20 74 6f |p & then back to| 00000410 20 7a 65 72 6f 2c 20 77 68 69 63 68 20 73 68 6f | zero, which sho| 00000420 75 6c 64 0a 6f 66 20 63 6f 75 72 73 65 20 6d 61 |uld.of course ma| 00000430 6b 65 20 6e 6f 20 64 69 66 66 65 72 65 6e 63 65 |ke no difference| 00000440 20 28 69 66 20 79 6f 75 20 64 6f 6e 27 74 20 64 | (if you don't d| 00000450 6f 20 74 68 69 73 2c 20 74 68 65 20 6d 6f 64 75 |o this, the modu| 00000460 6c 65 20 62 65 68 61 76 65 73 0a 63 6f 72 72 65 |le behaves.corre| 00000470 63 74 6c 79 2c 20 69 6e 66 6f 72 6d 69 6e 67 20 |ctly, informing | 00000480 74 68 65 20 75 73 65 72 20 74 68 61 74 20 69 74 |the user that it| 00000490 20 63 61 6e 6e 6f 74 20 61 6c 6c 6f 63 61 74 65 | cannot allocate| 000004a0 20 74 68 65 20 6d 65 6d 6f 72 79 20 74 6f 20 52 | the memory to R| 000004b0 61 6d 46 53 0a 74 68 61 74 20 77 61 73 20 72 65 |amFS.that was re| 000004c0 71 75 65 73 74 65 64 29 2e 20 50 65 72 68 61 70 |quested). Perhap| 000004d0 73 20 74 68 69 73 20 73 75 67 67 65 73 74 73 20 |s this suggests | 000004e0 74 68 61 74 20 74 68 65 20 4f 53 20 69 73 20 61 |that the OS is a| 000004f0 74 20 66 61 75 6c 74 3f 0a 0a 20 49 6e 20 70 72 |t fault?.. In pr| 00000500 61 63 74 69 63 65 20 74 68 69 73 20 64 6f 65 73 |actice this does| 00000510 6e 27 74 20 63 61 75 73 65 20 6d 75 63 68 20 64 |n't cause much d| 00000520 69 66 66 69 63 75 6c 74 79 2c 20 61 73 20 74 68 |ifficulty, as th| 00000530 65 20 63 6f 6e 64 69 74 69 6f 6e 73 20 64 6f 6e |e conditions don| 00000540 27 74 0a 66 72 65 71 75 65 6e 74 6c 79 20 6f 63 |'t.frequently oc| 00000550 63 75 72 20 75 6e 64 65 72 20 6e 6f 72 6d 61 6c |cur under normal| 00000560 20 75 73 65 2e 20 4e 65 76 65 72 74 68 65 6c 65 | use. Neverthele| 00000570 73 73 20 79 6f 75 20 73 68 6f 75 6c 64 20 62 65 |ss you should be| 00000580 20 77 61 72 6e 65 64 2e 0a 0a 20 49 66 20 79 6f | warned... If yo| 00000590 75 20 63 61 6e 20 65 78 70 6c 61 69 6e 20 61 6e |u can explain an| 000005a0 64 2f 6f 72 20 72 65 6d 65 64 79 20 74 68 69 73 |d/or remedy this| 000005b0 20 70 6c 65 61 73 65 20 6c 65 74 20 6d 65 20 6b | please let me k| 000005c0 6e 6f 77 2e 0a 0a 20 4d 69 63 68 61 65 6c 20 52 |now... Michael R| 000005d0 6f 7a 64 6f 62 61 0a 20 31 30 20 4f 63 74 61 76 |ozdoba. 10 Octav| 000005e0 69 61 20 43 6c 6f 73 65 0a 20 42 65 64 6c 69 6e |ia Close. Bedlin| 000005f0 67 74 6f 6e 0a 20 4e 6f 72 74 68 75 6d 62 65 72 |gton. Northumber| 00000600 6c 61 6e 64 0a 20 4e 45 32 32 20 36 4c 47 |land. NE22 6LG| 0000060e