high density disks

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: high density disks

Postby regregex » Sun Nov 16, 2008 10:17 pm

MartinB wrote:Many thanks for the support Greg, much appreciated :wink:

If I just push up the sector buffer size to 512 from 256 then timing shouldn’t be an issue. No, my worry bead on the Elk was whether it could pull the data from the 500KHz stream before the 1772 times out given that it (the Elk) has a variable speed system clock depending on Ram access.
Good point, is snow-mode cleared as soon as the NMI line goes back to normal? If so Tom Seddon's idea may save enough time to guarantee the address is incremented.

--Greg

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Sun Nov 16, 2008 11:28 pm

Yeah, subsequent to discovering the Arari forum discussions on this topic I did see that the Mailing List had visited the subject some time ago too. However, these are seriously clever people and I couldn’t work out whether they were discussing specifically PC format HD or if they were generalising about the ‘DFS on HD’ I was pursuing :?. Also, as far as I could see, it looked as if there wasn’t ever an end result, just lots of theorising (albeit impressive) which seemed to conclude that neither was likely possible without modifying the DFS firmware?

To be clear on my part, I haven’t got any particular interest in upping the capacity of Beeb floppies, just to allow new or nearly new media to be used with standard DFS or ADFS in place of the now rare and ageing DD discs. With regard to timing issues, I haven’t seen any evidence that HD DFS performance is marginal because since getting the first Beeb up and running it hasn’t missed a beat despite significant testing and use. Even the unlikely Elk is now looking good but I obviously haven't done as much testing on this machine to date. If I can get my head round setting up a test to measure this stuff (scopes, debuggers, headaches etc...) then I might have a try but, as I'm sure you've realised, I'm more inclined to go with what works in practice rather than getting bogged down trying to prove whether it may or may not work.

That all said, one point raised on the mailing list and elsewhere, is whether or not it’s ok to overclock the 1772. As usual, only anecdotal evidence is available and it’s impossible to know how many people besides me and a handful of Atari users have actually applied the technique in practice but to my knowledge nobody has yet reported harming one. However, this conveniently leads to me to a refinement to the clock switch I have already tried and which I believe will completely eradicate this grey area :D

Whilst messing on the Elk, it occurred to me that due to the way the various 151 control signals operate, the principal state of the 1772 clock is now 16Mhz unless the drives are being accessed with a DD disc inserted when the clock will drop down to 8MHz. A much better arrangement would be to have the clock always sitting at 8MHz unless a drive is accessed with a HD disc present – i.e. the complete opposite. Part of the problem is that the 35 drives report HD even when empty and my manual density 525 will always report HD if so switched. So, if we could modify the clock switch to only select 16MHz when the drives are accessed with a HD disc present, then the average time spent at 16MHz versus running hours would be miniscule. It would probably be in the order of 1% or less since the 1772 spends most of it's powered-up time idle anyway.

To this end, I’ve decided to add a second 151 which monitors both Drive Select n lines and takes advantage of the fact that, since in the Beeb these lines are gated with Load Head, both lines are High when neither drive is in use. The second 151 then only transmits a 16MHz clock to the first 151 if at least one of the drives is actually being accessed and transmits 8MHz otherwise. I‘ve already lashed this up and it does the job a treat so I will do a reprint of the circuit to include this change asap.

Apologies to anyone who has already built the circuit (although I think it’s usually only me and my imaginary friend :lol: ) but the addition of this second chip will mean that there’s absolutely no downside to adding the HD facility. There may not be any downside already, it's only speculation, but hey, let’s get this 100% perfect if we can.

Martin

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Tue Nov 18, 2008 12:00 pm

I’ve built and installed version 2 of the HD clock switch and, even if I say so myself, it’s perfect :D.
The 1772 now always defaults to the original 8MHz unless one of the drives is mechanically active (motor running) and there is a HD disc loaded.

To achieve this change, I’ve added a second 74HC151, IC2, which monitors the single common ‘Load Head’ signal (even simpler than monitoring both drive selects as I initially proposed ) and uses this to determine whether to make a 16MHz clock available to the original 151, IC1. There are plenty of other ways that this second selector could be implemented but, since in all cases a second IC would be needed, might as well stick with the fast, low power and non-loading 151. (…and because I had already bought a handful :wink: ) The extra wiring is pretty simple and it only adds one more pick up point on the Beeb - 'Load Head' at IC79 Pin 8.

As homework, I’ll leave it to you figure out the fine detail of the why’s and wherefore’s of the second chip truth table and wiring but essentially, the theory of operation is this - IC1 still functions exactly as it did before, selecting one of a choice of two clocks depending on whether a given drive is reporting HD, but now, IC2 only offers 16MHz to IC1 as a clock option if a drive motor is actually running. If not, IC1 can only choose between 8MHz and 8MHz – no choice then!

The reason for this enhancement is so that the HD mod can be fitted and enjoyed and you need have no worries whatsoever about whether the faster clock might reduce the longevity of the 1772. I doubt it would anyway but as I said in the previous post, with this version 2 of the mod, the time spent actually running at 16MHz over the next 20 years of power-applied will be completely insignificant.

Apologies again for the revision if you had started version 1 but even Acorn got to Issue 7 of the Beeb before they were happy! This is now the production version and I will be fitting it to all my Beebs asap.

Electron version to follow – already tested, just need to finalise the best connections etc.

Martin
clk_sw_schematic_v2.JPG
(22.65 KiB) Downloaded 2433 times
Attachments
clock switch v2.JPG
(85.51 KiB) Downloaded 2432 times

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Wed Nov 19, 2008 11:59 pm

The Elk AP4 (or AP34) HD floppy driver is now built, tested and working a treat :D. The clock switch circuit is identical to the Beeb Version 2 (above) so the only difference is where I picked up the connected signals.

Plus 3 – I don’t have one so I don’t even know if it has a 1770 or 1772 as standard - can anyone enlighten me :?: For the connections in a Plus 3, there is easy read-across and I specifically mention how to identify suitable clock connections. I recommend though that you first do the minimum, i.e. one track cut and hard wire the 1772 (if it has one) to 16Mhz, to see if the Plus 3 works ok at HD before building the circuit etc. I’m only advocating a cautious approach because I don’t know whether the Elk maintains it’s best clock speed when accessing discs through a Plus 3. Does the Plus 3 have it’s own ram like the AP4 :?: Is it an &E00 DFS or a something higher Page ADFS :?:

Anyway, returning to the mod - Drive Select 0 (DS0), the two HD present lines (HD0 & HD1) and ‘Load Head’ are all picked up from the 34 way floppy IDC edge connector on the solder side of the board and the power rails (+5v & 0v) are picked up from arbitrary points on the component side.

The three clock signals (16MHz, 8MHz & Clock Out) are worth a special mention since these are the only ones I can’t specifically cater for on the Plus 3. However, the technique of identifying suitable connection points is identical and very straightforward – the standard 8MHz clock is connected to the WD1772 Pin 18 and will be tracked to an IC which will produce the clock by dividing the Elk 16MHz clock by 2. Thus, follow this track backwards, by eye or with a digital multi-meter, until you reach the first IC it is connected to. Along it’s route there may be plated-through holes (which carry the track from one side of the board to other) or it may just be a direct track to the 8MHz source IC. This done, it is now only necessary to find a suitable point at which an isolating cut can be made. The HD circuit 'clock output' can now be connected anywhere suitable between the cut and the 1772 and the HD circuit '8MHz input' can be connected anywhere between the opposite side of the cut and the IC to which it was traced.

In the case of the AP4, the 16Mhz clock can be picked up from the cartridge edge connector at Pin A17 or anywhere along the track between A17 and it’s first destination IC. In the case of the Plus 3, the 16Mhz clock is passed along the wide expansion connector on Pin 12 and so can be picked up here as it enters the Plus 3 or again, anywhere between this pin and the first IC it is connected to inside the Plus 3.

The photos below show the AP4 connections I used and the (nearly) finished unit. To complete, I will simply enclose the clock switch in a small plastic box, such as those that jewellery shops use, and fasten it in place with double-sided mounting tape.

I have separately attached a full-size version of the signal connection picture in case anyone wants to see more clearly what I have done.

Greg (beardo) – For interest, I will have a go at characterising the DD versus HD byte transfer timing on the Beeb and the Elk. I think that the latter probably maintains max CPU speed when accessing the cartridge which, on the AP4, contains the disc I/O buffer ram so it’s possible that the timing is exactly the same as the Beeb - the functional performance certainly is.

Martin
ap4_conns_bottom_s.JPG
I really must buy some different colours of wire.
(77.74 KiB) Downloaded 2427 times
ap4_conns_top_s.JPG
Just the +5v and 0V here.
(72.23 KiB) Downloaded 2426 times
ap4_testing.jpg
I normally leave stuff like this if it works.
(55.65 KiB) Downloaded 2423 times
ap4_cased.JPG
...but since I'm going public I made a (weak) effort.
(57.43 KiB) Downloaded 2424 times
Attachments
ap4_conns_bottom.zip
(4.21 MiB) Downloaded 117 times

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Thu Nov 20, 2008 7:48 am

Martin

With a plus 3 - It is a 1770 in a socket, but there us no ram and if you have it connected page is at &1D00.

would this mod work with acp`s ADFS E00 which runs in SWR?

Nick
Last edited by Elk Towers on Fri Nov 21, 2008 7:23 am, edited 1 time in total.
Nick

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Thu Nov 20, 2008 9:10 am

I'm very glad you asked that question Nick because in pondering the answer I decided to do a quick knowledge refresh on the Elk CPU speed control and this has exposed an Achilles Heel in the Electron implementation of the HD mod :shock:

The Elk 6502 nominally runs at 2MHz and for memory access above the 32k boundary (Roms etc.) it stays at this speed. When accessing ram below 32k, the CPU is slowed to 1MHz due to the way in which the ram is shared with with screen memory refresh circuitry. For screen Modes 4-6, this has little effect other the obvious overall loss of performance and, with the ACP, it's still fine for the quicker HD data stream. However, in screen Modes 0-3, the CPU has lower priority than the video circuitry and it is denied access to ram during a screen refresh. The unfortunate effect of this is that in Modes 0-3, the CPU can no longer keep up with the HD data rate and basically, it starts to fall over. It's a very step change, perfect in Modes 4 and above and fails in Modes 3 and below :( .

This speed moding will apply to the AP4 and the Plus 3 and I don't think there's any way round the problem. The bottom line then then is that the HD mod is fine for the Elk as long as we confine ourselves to Modes 4-6 but I'm not sure if that isn't too much of a restriction to make the mod worthwhile for the majority of users? I shall definitely keep it anyway because for things like software development and compatibility with my HD Beebs it'll be fine but for games etc. that switch to Mode 0-3 before they finish loading then it won't work. (Do they do that?)

With this unfortunate restriction in mind then but answering your question, yes, it will work with the ACP &E00 ADFS. However, I can't be sure about the Plus 3 unless someone tries it. The ACP has it's own workspace/buffer ram so that during a sector read/write it has faster ram which is then copied to system ram but the Plus 3 uses system ram directly and so is subject to 1MHz slow-down. This may still be ok in the higher Modes 4-6 but I wouldn't like to say for certain.

Hmmm.., seems like there really isn't any such thing as a free (Electron) lunch #-o

None of this applies to the Beeb by the way, it's a 2MHz machine regardless of screen mode :D

Martin

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Thu Nov 20, 2008 10:53 am

One other thing that springs to mind is an AP3 uses system ram as well, it is only the AP4 that has its own private workspace.
Nick

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Thu Nov 20, 2008 12:16 pm

Yes you're right - I'd forgotten about the AP3 - I don't have one of those either :( .

All DFS systems have to ultimately use system ram to some extent but what's important is the time critical phase when a single sector is being read or written. The 177x will pass data out as the disc rotates past the head and it's effectively an unstoppable stream of bytes - 256 in our case.

A good analogy is the Charlie Chaplin film 'Modern Times' where he tightens nuts on units coming at him on a conveyor belt. If he gets distracted or is too slow with a given unit then the whole production line fails.

During a sector read, the 177x causes an NMI each time a byte is ready for collection and the host computer must read this byte and stash it somewhere before the next one becomes available because the 177x cannot 'wait'. Now, I think all DFS copy a fast NMI code loop to system ram anyway and this routine will store the bytes somewhere so it's the additional time taken to store the data in slower system ram that may be an issue with the DFS that don't have their own private ram. Once a sector has been read, it doesn't matter how long the CPU takes to move the data to it's final destination because it (the host CPU) won't request the next sector of bytes from the 177x until it's good and ready.

As I said, I'll have a little probe around and try and measure some of the timings and it'll actually be helpful to have the Modes 0-3 failure case in order to gain a better understanding but off the top of my head I don't see a way around this - we are stuck with how the Elk works.

If anyone feels inclined to try a Plus 3 (or AP3!) in Mode 0 and Mode 6 (minimal temporary hard-wired HD) then this would be useful information.

Martin

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Thu Nov 20, 2008 1:52 pm

you could remove the ADT chip from your AP4 and put an ADFS chip (v1.15) in just to try it. :)
Nick

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Thu Nov 20, 2008 2:15 pm

You are right, I could and I wil do that tonight! It's an original and it's just sitting there doing nothing so no problem at all.

Which am I likely to have given that it was an AP34 - I don't think I ever tried it, I just whipped it out. Will it be the &E00 ADFS or the system ram version with increased Page? If it's the latter I assume it will just ignore the onboard ram?

This is the problem with my being a newcomer to the in-depth secrets of the Elk, I'm not as familiar with it as I am with the Beeb. It would never have naturally occurred to me to try some hardware add-on of this type in different screen modes until I read the technical info in more detail. Still, I guess there's always something new to learn even after all these years :)

Martin

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Thu Nov 20, 2008 2:48 pm

It will be the system ram version and page will be at &1D00. :x
Last edited by Elk Towers on Fri Nov 21, 2008 7:23 am, edited 1 time in total.
Nick

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Thu Nov 20, 2008 10:30 pm

So, the simple plan was to test ACP Pres ADFS 1.15 in my AP4 to see if it works ok with the HD floppy mod.

I discovered that the rom I originally removed was actually 1.13 so, sticking to the plan, I first erased the chip and re-programmed it to 1.15 (thanks STH for the image :).) To ensure there was no cheating, I removed the ADT rom (just a toolkit anyway) together with the DFS rom and the 8k ram chip.

Switch on – nothing. Maybe the hardware needs to see the 8k ram chip at least present in the cartridge even though ADFS won’t use it? Nope, still nothing. So, I finally refitted the DFS rom alongside ADFS and finally it boots up Hmm…, this AP4 must be a trickier beast than I thought :?

Quick check then in DFS and all is well so, over to ADFS and immediately, nothing on the disc front works at all, not even double density discs. It took me a while but yes, I realised, I now need ADFS formatted discs but I don’t have any and ADFS appears not have a built-in format command? I have a genuine Master Welcome disc and I could catalogue that (joy!) but nothing seemed to want to run and I couldn’t see a format command anyway.

Now I remember why I unplugged that ADFS rom as soon as I got the AP4 :evil:

ADFS 1 Martin 0

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Thu Nov 20, 2008 11:13 pm

you could download the welcome disc from the sth electron disc software archive and use omniflop or similar to make it into a disc.
Nick

User avatar
Arcadian
Posts: 2798
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: high density disks

Postby Arcadian » Fri Nov 21, 2008 1:31 am

Your ADT rom should have a built-in DFS/ADFS formatter, if there's room to slot that back in?

Also, if you hold CTRL-F-Break (or type *FADFS) that should initialise ADFS without accessing the disc.

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 7:43 am

Thanks Dave =D>
I removed the ADT rom (just a toolkit anyway)...
What a complete plonker :oops:

Yes, I have cartridges so I have plenty of room. Now, if I can just prise the ADFS rom from the bottom of my shoe.... Temper, temper Martin [-X

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 12:11 pm

Following good advice from our host, I refitted ADT and sure enough, it does have an ADFS/DFS formatter :D

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 :D. (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 :wink:) but probably well within a microsecond and good enough for now.

Look at the (simulated) scope trace below :
waveform.JPG
(6.58 KiB) Downloaded 2237 times
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.

Martin

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 1:48 pm

A thought occurs to me – I wonder if I’m missing a trick here with ADFS :?. I’ve never particularly used it unless I needed to but thinking about it, I presume it has a higher capacity format than DFS in order to allow the hierarchical directories and to achieve that, does it use a higher bytes-per-sector density such as 512? If so, this may be the reason that ADFS didn’t work on the Elk rather than it being related to memory access speeds. If there are twice the bytes per sector then that would (I assume?) halve the timings I reported above which would then tip us over the edge timing-wise.

Hmm.. need to think about that one then. If it's correct, the final tally for the hardware only HD mod would be Beeb - 100% DFS, no ADFS and Elk – 100% DFS in Modes 4-6, no Modes 0-3 and no ADFS.

Final test then is for me to try ADFS on a Beeb.....

Whatever the outcome, and to repeat myself, I’m alright then :D

Martin

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Fri Nov 21, 2008 3:39 pm

Both DFS and ADFS are 256 bytes per sector.

I think your first assumption that the elk cant shift data fast enough using system ram is probably correct.

If one uses a master ram board in turbo mode, i do believe both cpu and ram run at 2mhz, then it should shift data fast enough.

When you get your SWR cartridge there will be 2 (3.5")discs enclosed, 1 will be ADFS E00 on an ADFS disc and there other will be ADFS E00 on a DFS disc. That way you should be able to plug in the ram, remove the ADFS chip from the AP4 and put ADT back in, and then run the ADFS E00 disc(dfs disc).

The discs will be suitably marked :)

Nick
Nick

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 5:03 pm

Cheers Nick.

I'll have a closer look at ADFS anyway and might as well check it out on the Beeb to complete the picture. As usual, more later..... :roll:

Aren't there different sizes of ADFS disc though? I've heard people refer to 'large' format but never really knew what that meant. What total capacity are Elk ADFS discs?

The SWR cartridge sounds exciting, looking forward to that! =P~

Martin

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Fri Nov 21, 2008 5:21 pm

depends wether you have a 5.25" 40T drive or 5.25" 80T or 3.5" drive and wether they are single or double sided.

1. 5.25" 40T SS drive = 160K (S)
2. 5.25" 40T DS drive = 320K (M) same for 3.5" and 5.25" 80T SS drive
3. 5.25" 80T DS drive = 640K (L) same for 3.5" DS drive

I think i have that right unless someone says different.
Nick

User avatar
retroclinic
Posts: 3016
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: high density disks

Postby retroclinic » Fri Nov 21, 2008 6:49 pm

Hi.

There are more versions of ADFS, but not used on the Beeb.

2 types of 800K, one with a directory structure the same as the 640K, and the other using a more robust directory system. Also a 1.6MB true HD version, only used on A4000 upwards Arcs. The DD Arcs also used a 1772 controller, but HD Arcs used a PC compatible controller (which is hugely sensitive to static damage), maybe so they could get the 1.44MB PC format to be truly compatible, or because it was cheaper at the time?

Mark.

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 7:47 pm

Thanks Nick & Mark :)

So, what is the track & sector arrangement to get the ADFS 640k capacity then? The biggest DFS disc is 400k which is achieved by 256 bytes x 10 sectors x 80 tracks x 2 sides. If the 256 bytes is the same for ADFS and we can't increase the tracks beyond 80 then I presume there are more sectors per track?

I'll have a play on the Beeb anyway and if ADFS works at HD then I guess my questions go away. It's just that if it doesn't work then I'd like to understand why.

Martin

User avatar
retroclinic
Posts: 3016
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: high density disks

Postby retroclinic » Fri Nov 21, 2008 7:50 pm

Hi.

Yes, there are 16 sectors per track for ADFS 640k.

Don't forget things like Watford DDFS, that do near 400k per side on DFS.

Mark.

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 8:07 pm

Thanks Mark.

I see, so that's effectively a 50% increase in angular density then and, trying to visualise it :?, the byte transfer rate is going to increase accordingly given the fixed rotation speed of the drive - I think?

Anyway, could still be then that ADFS is failing because it runs out of time - in or beyond my red marker perhaps :(

Enough speculation, time to do some more testing. I'll be back...

Martin

User avatar
Elk Towers
Posts: 489
Joined: Sun Apr 23, 2006 2:10 am
Location: Kettering, Northants
Contact:

Re: high density disks

Postby Elk Towers » Fri Nov 21, 2008 8:23 pm

My penny worth of deduction is

1. on a beeb adfs will work as it will shift the data fast enough

2. on the elk as the cpu has to slow down for ram access then it wont work.

3 on an elk with swr and adfs e00 it will work because the cpu doesnt slow down to access the ram.

[-o<
Nick

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Fri Nov 21, 2008 11:32 pm

Sorry Nick mate, the ADFS news isn’t good :(

I didn’t have a Beeb ADFS rom (this was never going to be easy) so I blew one to Acorn ADFS 1.30 (thanks yet again STH) and fitted it along with ADT and ADI (used later).

Straight in then, blank 35 HD floppy in Drive 0 and *FORM 80 0 but alas, as with the Elk, bit of noise, disc error (44 I think) and game over. So, the rest of the tests had to be done using DD floppies in order to try and understand the failure mechanism. I formatted a disc to ‘Large’ (although the smaller capacities proved to behave the same) and saved some large test files. (*MOUNT, *MOUNT, adfs - must remember, *MOUNT….)

I then repeated the measurement I used before and the first thing that jumped out was that I saw exactly the same timing as I did with DFS when it’s in HD mode. This of course initially confused me but it also immediately suggested that by trying to double the data rate with a HD disc (as we do by clocking the 1772 at 16Mhz) that our 35us would become 18us and our (roughly) available 18 machine-code instructions would become just 9. It’s not going to work then is it [-X

To give me a further clue, I used ADI to analyse the ADFS disc which showed that the capacity and layout were as Nick and Mark had said but the one difference I saw (sparking an enlightening) was that ADFS discs are reported as MFM as opposed to FM with a DFS disc. (I now remember Colin McD mentioning this in relation to the Archimedes several hundred posts ago but at the time we were pondering the longevity of Arc discs and it just passed me by.)

I did ask if I’d missed a trick with ADFS and of course this is it. MFM doubles the storage capacity of a disc by allowing the magnetic representation of data to be physically shorter along the track than in FM mode – by half in fact. Therefore, we see exactly as one would expect and get bytes streaming out at twice the rate of DD DFS or at the same rate as our new HD DFS. So, with a 2Mhz 6502 and ADFS we can’t double the rate again by using HD and expect to get away with it without coming up with an NMI byte grabber that can function in the small amount of time remaining. With hindsight, I can now see that this is undoubtedly what the Mailing List gurus were discussing and they have probably been watching and wondering just how long it was going to take me to get here :lol:

That all said, I’m still over the moon with my HD DFS mod – my workbench is already littered with a mixture of HD and DD 3.5” discs and I can happily use them at will without giving a thought as to which is which :D. I do have to remember to flick the switch on the 5.25” drive but that’s just trivia given the overall media benefits. Ultimately, my original objective has been fulfilled and as a DFS devotee the only slight downside is the Elk Mode 4-6 limitation. (On the latter, the memory access issues are still very relevant because, as you will all now understand, every CPU cycle saved is crucially helping to keep us 'in the green' and 'out of the red'.)

I’m sorry though to disappoint any ADFS users who had been hoping to use this facility (e.g. Nick) but you never know, I might yet have one of my off-the-wall eureka moments :wink:

Martin

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Sat Nov 22, 2008 5:53 pm

Thinking about it, now I've got Beebs and an Elk which automatically support HD it will be really easy to try some fine tuning of the NMI routines. I can run ADFS from SWR (soon on the Elk :wink: ) and just try different methods. I'll have a closer read of the Mailing List discussions and, acknowledging Greg's pointer to Tom Seddon's suggestions, there'll be plenty of things to try.

I do still need to set up a way of measuring exactly where the timings sit in practice because if it suddenly works, I don't want to declare success if it's only 'in' by a couple of cycles. If that were the case, variations in system configurations might mean it works on some machines but not others. I think it needs to be well inside the critical time (perhaps 'amber' at worst using my pictorial) before any ADFS change could be considered suitable for reliable use by all.

So don't give up hope just yet Nick 8)

Martin

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Mon Nov 24, 2008 12:51 am

Well… :?

Had an intensive read (and re-read, and…) of the Mailing List thread on this subject and, whilst I fully understand the technicalities of the discussion, I think any implementation of a ‘tuning’ change to any ADFS is going to be much more complex than just tweaking the NMI routine itself. I’ve had a hands-on play but only revealed more problems than I’ve solved :(.

One thing I have learned (and this shows how much I’m still a newcomer) is that a chap called Greg C… contributed significantly to this on the ML and I have only just twigged that this is in fact beardo :shock:.
So Greg, I now understand why you were expecting me to struggle at some point but since I was only ever targeting HD DFS (FM) and had never really given a thought to ADFS (or realised that it is MFM), I was missing the finer points of what you were saying. Sorry about the crossed wires then (no pun...) :oops:

Briefly then, I have essentially just tried playing with the existing NMI code to see what reductions it would tolerate. From a timing point of view it can indeed be shortened but I think that the wider usage context of these routines means that more invasive changes would also be needed to the overall code structure.

For example, to visualise the byte ready report versus the Status and Data register reads, I scoped 1772 /CS (red) with Pin 27 (black) during a settled file read and saw this :
cs.JPG
(5.86 KiB) Downloaded 1918 times
This by itself suggests that the Status read, mask and test (first red pulse) are redundant because we always go on to read the data anyway (second red pulse). So I tried NOP’ing out the Status read etc. (not for speed, just to see if was needed) and it makes the system fall over. I assume from this that an NMI is generated earlier on in an access sequence (‘spin-up’ or ‘data mark’ perhaps?) and so we can’t just scratch the test. Amongst other things, I also tried killing the buffer page increment but again this causes more problems beyond timing issues.

I don’t doubt that it can be done, probably ultimately using a nifty re-entrant handler as you have suggested but I think the wider changes across the ADFS package needed to achieve this might outweigh the ultimate benefits - certainly for me as a DFS only user anyway. Still, if anyone else wants to run with this then my HD clock mod certainly makes experimentation easier :).

So, HD DFS only then! (Well, for the time being anyway...)

Martin

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Tue Nov 25, 2008 11:36 am

I’ve been thinking again….. (I know, I know, but these things get under my skin :evil: )

At the outset, my objective was to allow the use of the abundant HD media on a Beeb etc. under DFS and, although I didn’t think this one through, under ADFS. However, the latter requires a much higher capacity media so, in order to pack more onto a disc, Acorn switched to the 177x FDC which additionally supports MFM recording allowing DD discs to carry twice the data of FM DFS by halving the physical track space that a given byte occupies.

Now, by my clocking the 177x at 16MHz and using HD media, I think, although I can’t of course physically ‘see’ it, I’m achieving the exact same thing by writing each ‘pulse’ of data for half the time but at a higher flux which is exactly how HD media was intended to be used.

My latest train of thought then is that if we suppose for a minute that there had been no such thing as MFM available, but the 177x had actually been supplied as a single density 16MHz device, then Acorn could have done exactly the same as me by switching to HD media and a fast clock (but without the scruffy Veroboard perhaps :wink: ) and hence achieved the ADFS requirements by a different route.

The problem I now have is that if I try to use my HD mod in conjunction with ADFS, I am effectively trying to (unnecessarily) quadruple the capacity and the associated byte transfer rate of a disc and it’s this which then gets all too much for the humble 6502 at 2MHz.

Ok, so here’s my ‘out-loud’ punchline thought, which is also a question if beardo or anyone who hasn’t yet turned to stone is listening….

If I was to lightly patch ADFS such that it simply doesn’t use MFM (a control bit to the 177x), then shouldn’t ADFS be achievable just by using HD media and a 16MHz 177x clock in FM only :?: If so, then the problem would be solved without any re-writing of the ADFS NMI routines.

There would be one little extra something needed to allow existing ADFS DD MFM media to be mixed and matched with the new ADFS HD FM media – i.e. something similar to how I automatically cater for DD & HD media with the current mod. This would amount to a conditional ADFS patch which would need to be able to detect the presence of a HD disc (the clock would already have been automatically switched to 16MHz by the current auto-clock mod) and it would then simply select 177x FM for HD and 177x MFM for DD. Once implemented, the mod would again be transparent to the user who could freely mix their existing ADFS DD media with the new ADFS HD media as I now do for DFS.

I can feel some more experiments coming on unless someone can save me from this psychotic obsession by pointing out a fatal flaw in my thinking :?:

Martin

User avatar
retroclinic
Posts: 3016
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: high density disks

Postby retroclinic » Tue Nov 25, 2008 12:09 pm

Hi.

I have to say you're doing great work, keep up the enthusiasm, which I don't want to dent....but....

By doing what you suggest with ADFS, and also, with what you have been doing with FM, you're making propriatory formats, that only those with the same mod can use. An idea goal, in the ADFS scenario, would be to make the mod, in combination with a mod to ADFS, that can read Arc 1.6MB ADFS floppies. That would be a true landmark acheivement. I'm not sure that the beeb is fast enough to keep up with the data rates though, let alone the 1772 itself. Acorn ditched the 1772 on the A4000 up for HD 1.6MB probably for that reason, and used a PC type controller.

I had toyed with the idea of a HD controller for the Beeb myself a while back, but theorised that it would have to be done with a faster microcontoller on the board with some RAM, to read/write a sector at a time at full HD speed, then supply it to the beeb at a slower rate. If the Beeb truly is quick enough for full HD, that would be great.

Mark.


Return to “hardware”

Who is online

Users browsing this forum: mlouka and 8 guests