Following good advice from our host, I refitted ADT and sure enough, it does have an ADFS/DFS formatter
Straight to the results then, ADFS 1.15 did not work
. The format failed almost immediately which suggests that an all system ram DFS in an Elk cannot run fast enough to support HD floppies. It would seem then that the only way to use HD on an Elk is by using an ACP with an &E00 DFS (or probably &E00 ADFS if there is one?) where there is a speed increase by virtue of it’s using private static ram. I think this also suggests that the Plus 3 would fail at HD unless there is a similar &E00 DFS which uses fast SWR.
So, I’m alright then
. (Well, in Modes 4-6 anyway
Moving to spin-off territory and for background interest, I’ve had a cursory look at some of the timings involved in this DD/HD stuff. This really might kill off the casual reader but stick with it if you can, I’ve tried to keep it as ‘everyone friendly’ as possible and I think it’s worth a read. This is in fact the angle that Greg (beardo) was alluding to when he mentioned Tom Seddon’s code change suggestions during the Mailing List HD discussions.
For a first quick test, I simply scoped the 1772 data ready output (Pin 27) which is the signal that causes an NMI (Non Maskable Interrupt) to the 6502 when a byte is ready for collection during a disc read, or when the next byte is required during a disc write. I’m only looking at read for now but that’s sufficient for a basic DD v HD comparison. The NMI causes the 6502 to immediately ‘drop everything’ and to shoot off to a disc interrupt routine (usually at $0D00) which will grab the waiting byte from the 1772 and store it in memory either directly at the target location or in a temporary sector buffer ready for subsequent transfer to the target location.
All I’m actually doing is repeatedly <Shift><Break>’ing Elite from a 3.5” DD floppy and then from a 3.5” HD floppy (the latter works fine incidentally.) Once the main program starts to load, the 1772 output settles down to a steady data stream for a few seconds so a reasonable measurement can be made. Any figures are approximate (as are all my discussions
) but probably well within a microsecond and good enough for now.
Look at the (simulated) scope trace below : Time is horizontal and logic 1’s & 0’s are vertical such that for this particular signal a 1 (high level) means a byte is available for collection and a 0 (low level) means nothing is ready yet. Thus, at the precise point the signal goes high, i.e. the leading or rising edge of the pulse, the 1772 has signalled that it has a byte ready for collection and an NMI will occur. This signal will not be reset by the 1772 until the instant that the 6502 reads the byte from the waiting register. Therefore, the width of the pulses, X, tells us how long the 6502 took to read the byte after it was reported available. The time to the rising edge of the next pulse, Z, measured from rising edge to rising edge, tells us in how quick succession the bytes are being presented for reading.
Using the DD disc, I measured 15us (microseconds) for X and 65us for Z and, using the HD disc, I measured 15us for X and 35us for Z. The identical value for X is as we would expect since the 6502 is always running at 2MHz regardless of DD/HD and hence in both cases it takes the same time to respond to the NMI and read the byte from the 1772. The Z value changes though because at HD, the bytes are coming in at roughly twice the speed (not quite twice for a variety of boring reasons) and hence we see less time between the pulses.
So, what does this mean in terms of how well the 6502 copes with HD? Well, at 2MHz, one CPU clock cycle is 0.5us. Any given machine code instruction (op-code + data) takes a number of cycles to execute so let’s for easy discussion say that all instructions take 3 cycles or 1.5us. At DD, we see we have 65us to get the byte, stash it and be ready for the next byte. 65us is 130 cycles (65/0.5) which allows us roughly 43 (130/3) instructions. Using the same calculation, at HD, we measured 35us or roughly 23 instructions. We do lose some of these cycles or instructions as the 6502 has to pause and resume what it was doing (before & after the NMI) by saving registers etc. and it has to get to the NMI code and back so let’s say we deduct 8 instructions leaving a final 35 instructions for DD byte retrieval and 18 for HD.
Now, I wrote my own NMI routine for RAMagic where it does it’s own 1772 byte reading for DD DOS discs. It’s not a terribly tight routine, it probably could be optimised, but I used somewhere around 13 instructions so the rough figure of 18 we have calculated to be available for HD mode does seem to back up what we have found with the Beeb – i.e. it works.
If you look at the trace (and have understood any of my ramblings), I have put on three coloured markers, only roughly, to show where we would, at the latest, ideally like to be when ready for the next byte (green), when things would be getting a bit tight (amber) and where things will fail (red). In the case of the Beeb, I think we are green, in the case of the Elk with an AP4 (using it’s own faster static ram) I think we are between green and amber and in the case of the Elk running a system ram only DFS, we are red!
I will try and quantify this better, it’s not terribly scientific or accurate, but I think I’ve got a feel for it now. The trickier side of things is to more accurately find out where we actually are on the time line and this usually then involves logic analysers and/or clever debuggers to couple the 6502 program code sequence to a trace such as the one shown.