First a big thank you to all whose unending efforts have resulted in my system being able to load the EUG disks. Hopefully, more of you will be able to help me with another problem and disk problems will not keep preventing me from sending in my programs!
I have an AP4 on my standard Electron and (Acorn) Plus 1 and it runs whatever drive(s) is(/are) connected at the time. Currently, I have two 3.5" 720K PC Drives, running on a PC PSU. My problem is that anything I write to drive 0 in DFS is unreadable on any other drive anywhere. And similarly, anything written on any other drive by any Elk, is unreadable on my drive. Hence I get bad tracks all over the hop!
I decided to have a bash with ADFS in vain. Every time I tried to "EFORM" a disk in drive 1, with the Welcome disk in drive 0, the program simply corrupted the Welcome disk. Therefore, at this moment in time, I also need a replacement Welcome disk. Can anybody help, please?
Note: on AP4s too that you can access 4k of that 8k static RAM it carries. Here's how...
First, it can only be accessed from assembler, as you need to switch out of BASIC to use it and any time you use the DFS, you are at risk of losing the data stored. Warnings aside though, here's the good bit. Find out which ROM your DFS is in (Mine is R0) and switch to it using the following procedure:
[OPT whatever
LDA &F4:STA oldrom \Store old ROM
LDA #newrom \DFS ROM No.
STA &F4:STA &FE05 \Switch!
\Here you have Your Program
\&B000-&C000 |
\free to use |
LDA oldrom \Load old ROM
STA &F4:STA &FE05 \Switch!
RTS
.oldrom EQUB 0 ]
Accessing this area between &B000 and &C000 should theoretically be twice as fast as accessing normal RAM as the Elk will think it's part of a ROM.
Now a word on the programs I'm cooking up that will, if someone can explain away my disk problems, appear in EUG #21. First, EUINDEX. This is a database of information about every article in my (unfortunately incomplete) collection of Electron User magazines. I am still feverishly trying to type all the information in. The program does work, although I have only been able to enter up to 1987 thus far.
My second idea is a program packer; a way of storing more than the thirty-one files a DFS disk directory allows using a 'lump them all in one big file' technique. (This was where my disk problems first came to light!) Using the OSGBPB (transfer bytes) call to transfer files worked, but I could only manage to extract the first three files from each archive. Not too good if you have fifty to an archive.
Then, in a response to a request in EUG #18, came a Save Protection Utility. This trapped the OSFILE vector and inserted a checking routine to see if a file existed or not before going ahead with the SAVE or *SAVE. Unfortunately, this only worked up to the point where it was supposed to actually save the file and prompt regurgitated a 'Disk full' error on an empty disk!
Lastly, a set of memory utilities are also taking shape: Dump, Ascii Dump, Search, Edit and Disassemble. These work but I am trying to turn them into machine code at the moment for relocatability purposes. (Hmmm, what a long word!)
Well, enough waffle for now from this new EUG member. Cheers for a great user group and magazine, Gus, and keep up the good work!
PS. If anyone happens to have seen any PC shareware under the name VegAsoft, let me know what you thought about it. I am thinking about going back into commercial programming (after a long break).
Wayne Skinner, EUG #20