Mr. Editor, you will really have to do something about your spelling - it really is appalling in some parts! (Grin)
The use of disk space on EUG disks could still be improved; your reliance on BASIC programs is still fairly high. The way I ultimately envisaged the EUG disk was that everything would be text apart from a few graphics files and the actual program files. Perhaps with a reader for a sort of script language? I'd also have all text free form so it could be read in both 40 and 80 columns. All those 26s and 16s would go: Soft spacing is a pain!
Going back a bit to Mr Warner's problem, we come to the word copyright. View (et al) writes to itself because if you are trying to run it in Sideways RAM, it means you must have copied an image of the ROM and thus have broken Acorn's copyright. Not being a party pooper though, and suspecting Acorn won't go around chasing Elk owners who would prefer not to waste a whole cartridge slot on View, this little procedure should solve it:
X=OPENUP"xxxx"
PTR#X=&yyyy
BPUT#X,&EA
BPUT#X,&EA
BPUT#X,&EA
CLOSE#X
xxxx is the appropriate filename and yyyy is either:
28D6 for View E1.0
0688 for ViewSHEET E1.0
2BCE for Viewstore 1.0
The program disables the bit of code that checks whether the utility is being run in Sideways RAM.
As to the speed of the PC. The main reason bootup is slow is that DOS has to be loaded (not something an Elk, or any Acorn computer for that matter, has to deal with). No doubt that the problem would go away if you got one of those PC notebooks with have a bootable MS-DOS in ROM. You could then go on about size of applications but that would be boring - these arguments always are.
Changing the physical drive which a logical drive is mapped to IS possible. I changed my EDFSE00 so that drive 0 was swapped with drive 1 (and 2 with 3, considering DFS drive 2 is just side 2 of drive 0). It's just a case of changing the bit of code which writes the drive select to the control reg (in EDFSE00 2.20, this is read out of a four byte table at &904C by code at &8D09). Obviously the position of this code depends on the version of DFS, but I hope I've pointed someone else in the right direction of what to look for.
I'm glad Derek has had success with my HD article back in EUG #7. One thing I think should be mentioned as many times as possible though is the need to turn off the cursor before *COMPACTing. Not doing so has dire consequences!
I'm confused to why he states ADFS "has to be in the highest priority socket available". It shouldn't make a difference wherever you put it (except for which filing system starts up first).
He digressed slightly about the AP2, which is actually an 8k image blown twice into a 16k EPROM. (Pres probably had a load of 27128s laying about...) Due to the fact that, as he says, the address lines aren't all there, the Plus 1 internal ROM socket only reads the top 8k.
I did wonder if the "low cost" 1MHz bus left the address decoding in the PAL for the HD controller but it obviously doesn't. One way is indeed to remove buffering and link NPFC straight through, the other is to get a new PAL programmed. I know the bloke who designed 99.9% of the stuff that ACP/Pres used to sell and can ask him about this if anybody so wishes.
Gareth Babb
Another stimulating letter from Gareth.
I have tried to arrange for files to be printed so that they can be either 40 or 80 column but have come up against the problem of word wrap where words get broken into two in the 40-column mode. I did try to adjust the files but this got so tedious. If you have a solution, there are a number of readers who will put you on their Christmas Card list for supplying it. Send it in.
As for assembly, as I have said before, I can only publish what is sent. Could you perhaps do some articles on converting BASIC to assembly? And please make them easy to understand?
The files on Acorn's pamphlets look interesting. I will try and do a review of some of them in due course. Thanks for them.
Gus Donnachaidh, EUG #17