high density disks

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: high density disks

Postby SarahWalker » Tue Nov 25, 2008 1:41 pm

The 16mhz 1772 should be able to keep up with 1.6mb floppies. Acorn switched to the PC combo chip for cost reasons - it replaces at least a dozen other chips on the Arc.

Whether the 6502 can keep up is another matter!

If you could get an Electron with Plus 3 and some sideways RAM or one of those other RAM boards, then I reckon it would be doable. The Plus 3 doesn't generate NMIs so once data starts coming in you could have an big unrolled loop of

lda $fcc7 ;Data register
sta addr
nop ;however many nops are needed between bytes
lda $fcc7 ;Data register
sta addr+1
nops
lda $fcc7 ;Data register
sta addr+2
nops
etc

Don't know how workable this would be though!

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

Re: high density disks

Postby MartinB » Tue Nov 25, 2008 2:37 pm

Ooh, that's interesting Tom - I hadn't realised the Elk doesn't use NMI's for disc access :shock:. I don't have any documentation for any of the Elk disc systems so I just assumed they were pretty much the same as the Beeb. Unless there's something in the AUG?

If you have any technical info (or pointers to) that you can share I would be delighted to see it - I don't have a Plus 3 at the moment, only an AP4 so it'll be a bit tricky for me to be defiintive with read-across of any developments but I will do my best.

Please keep chipping in Tom if you have any other thoughts or ideas, the more the merrier :D

Mark - You don't half keep nibbling at my ankles with that one :lol:. Thing is, I think we're stuck in a loop here so to speak. If we use a HD floppy at all then we have to use the 500KHz clock because the HD flux and fast interface are hard-wired together in the drive. Therefore, we have to clock the 177x at 16MHz and therefore we need a hardware mod. Now, the hardware mod can either be a 177x based one like mine or a complete replacement module with an intelligent controller as you suggest, but in either case, the end-user will definitely have to have a hardware mod to use a HD floppy on a Beeb etc. whether the disc is DFS, ADFS or anything else. Hence, the proprietary format is, I think, unavoidable because it is simply the fact that it is HD.

So, I do understand where you're coming from but I don't think I have the time or resources to develop anything more elaborate. I'm actually already where I wanted to be but if I can just get the edge on ADFS for the Beeb and Elk then I'll be happy :D

Martin

SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: high density disks

Postby SarahWalker » Tue Nov 25, 2008 4:34 pm

MartinB wrote:Ooh, that's interesting Tom - I hadn't realised the Elk doesn't use NMI's for disc access :shock:. I don't have any documentation for any of the Elk disc systems so I just assumed they were pretty much the same as the Beeb. Unless there's something in the AUG?

If you have any technical info (or pointers to) that you can share I would be delighted to see it - I don't have a Plus 3 at the moment, only an AP4 so it'll be a bit tricky for me to be defiintive with read-across of any developments but I will do my best.


The lack of NMIs on the Plus 3 is I think a tradeoff - either halt the machine during disc access (which it does) or introduce noise onto the screen. Don't know what the AP3/AP4 do.

The code in Plus 3 ADFS is quite poor. Here's the read sector code - I think this runs in RAM, which doesn't exactly help the speed :

$BA52: lda $FCC4
$BA55: ror a
$BA56: bcc $BA4A
$BA58: ror a
$BA59: bcc $BA52
$BA5B: lda $FCC7
$BA5E: jmp ($0D10)

Not difficult to improve really!

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

Re: high density disks

Postby MartinB » Tue Nov 25, 2008 5:00 pm

Ok thanks Tom - understood :)

So in the Plus 3 (and different to the Beeb), $FCC4 is Status and $FCC7 is Data - the Beeb NMI code does a similar check but tests for both 'data is now ready' bits simultaneously with AND#$1F and CMP#3. It's strange but having looked at dozens of Acorn and third-party disc NMI routines, they all use the same few instructions, I suppose because there's a minimum job to do and not really any other way of doing it without either cutting (possibly unsafe) corners or allowing fast re-entrancy as discussed on the ML.

I'll have a look at the FM<>MFM technique I mentioned earlier because it might be a significant and more practical way forward. The timings would remain identical so that all existing code will still work as it does now apart from a conditional single bit switch here and there. It would still need the basic two-chip mod though and and possibly a third to allow ADFS to know the density of the disc being accessed.

Martin

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

Re: high density disks

Postby MartinB » Wed Nov 26, 2008 1:11 am

So I wrote...
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?
..and the answer is yes, it is achievable :D

It's late so the abridged version is .....

It was a bit of a tricky task because I needed a known start-point and all I have in original ADFS is a dodgy Dual 40/80 format Master Welcome disc on DD 5.25" :(. Undaunted, I first confirmed using ADI that 16MHz HD FM could indeed support 256 byte x 16 sectors and it was fine! So, I then used ADI to repair and copy the dodgy disc to a 3.5" in my new format and I then had a decent start point. Next job was to patch ADFS 1.30 to force it to work in FM rather the MFM. That wasn't too tricky :^o and once done, away we went - ADFS on HD floppy.

So basically, as I suspected, a 177x running at 16MHz in FM produces exactly the same disc 'layout' as a 177x running at 8MHz in MFM.

What does all this mean? Well, it means I can now go on and finish this project such that we can now use HD floppies on Beebs and Elks in DFS and ADFS :D. There are still technical details to resolve and in particular I need to come up with a way of reporting 'HD disc present' to ADFS so that the FM / MFM patch selection can be automated. Also, since ADFS doesn't have a built in format command, any third-party formatters would need to support a HD FM option so there's certainly more to do but at least I now know it can be done and it's just a matter of detail.

No support for larger formats at this stage (e.g. PC 1.44 or ARC 1.6) which, as Mark says, would be the Rolls-Royce solution but this latest implementation would be a better springboard for further investigations.

ADFS 1 Martin 1

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

Re: high density disks

Postby MartinB » Mon Dec 01, 2008 12:53 am

You can always rely on me to break these silences....

So, how’s ADFS on HD going? Well, fine – I have added the LS244 chip as per my other hardware thread and by connecting the two ‘HD Floppy Present’ lines to a couple of the new inputs, I can now detect in software whether ADFS needs to use single or double density according to media type. I have patched ADFS 1.30 accordingly and the end result is that I can, as with DFS, freely mix’n’match HD and DD floppies under ADFS :D

At this stage though, it’s important that I concur with Mark (retroclinic) and agree that whilst the DFS HD mod had no compatibility issues and would work with any DFS and 177x module going, the ADFS side of things has become a bit more bespoke to type and my producing an Acorn ADFS 1.30 version certainly doesn’t account for all the ADFS variants out there. So, I’m going to treat the ADFS HD mod as a ‘technology demonstrator’ and whilst I’ll still document what I’ve done, I don’t realistically see it as a de-facto solution for all. Hopefully though, all the information that has surfaced during this thread will allow anyone wishing pursue the ‘Holy Grail’ of multi-format capability (e.g. PC 1.44, Arc 1.6 etc.) to have a better foundation to work from.

I established that to patch ADFS 1.30 I would need about 20 contiguous free bytes and I naively assumed these would be no problem to find. However, I now know that this FS has been truly shoehorned into a 16k rom and apart from a couple of "Hugo"s :?, I could not find an ounce of free space. It’s possible that there is some redundant code in there but unless I attempt a full intelligent disassembly I won’t know.
So, to create the necessary space, I had to shorten two error messages to a more cryptic outburst and split my tiny patch into two parts joined with a JMP! I reduced “Can’t delete Library” to “Lib!” and “Compaction required” to “Compact!” which gave me a 16 byte and an 11 byte space to fit the patch into. On the plus side, I was relieved to find that Acorn had only used explicit writes to the 177x control register ($FE80) which contains the Drive Select bits and the Density Select bit. Therefore, the patch simply involves replacing theses writes (4 off) with a JSR HD_PATCH and the patch then selects the required density by setting the (normally reset) Single Density select bit according to the type of disc in the drive. The Drive Select bits are 0 & 1 for physical drives 0 & 1 and by my connecting HD_PRESENT_0 and HD_PRESENT_1 from the drives to bits 0 & 1 of the new LS244 ($FE18) input register, a simple logical AND of the two LSB’s of $FE80 and $FE18 is all that’s needed and any non-zero result tells us that a HD floppy is in use. The patch then writes out the (possibly) modified control word and continues with an RTS.

I’ll add some detail to that in my next post and then overview the whole ADFS mod. I have one last thing to crack and that’s to patch an ADFS format utility because AFORM obviously always uses double density which, as we now of course know, isn’t compatible with HD when we are already doubling up the clock speed. I’ve had a cursory look at AFORM but it doesn’t look as if it uses explicit 177x register addressing (why would Acorn be consistent #-o) so I’ll have to do a bit more digging there.

Martin

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

Re: high density disks

Postby MartinB » Mon Dec 01, 2008 11:40 pm

Here’s the details of the ADFS 1.30 changes I made to squeeze in the HD/DD patch. Yeah, I know it's not pretty but hey...

1. To create some space :

91DB : 4C,69,62,21,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

(“Lib!” + seventeen 0’s to $91EF - was “Can’t delete Library”)


8668 : 43,6F,6D,70,61,63,74,21,00,00,00,00,00,00,00,00,00,00,00,00

(“Compact!” + twelve 0’s to $867B - was ‘Compaction required’)


2. Intercept drive control to take charge of density :

Four off JSR to patch, JSR $8671 (20,71,86), replacing STA $FE80 (8D,80,FE) at BA9E, BCD5, BEC6 and BF35.

I did first confirm what each of the $FE80 writes does and in my first HD only hard-coded version I modified the lead-in code to permanently set single density which didn’t require additional space.

3. And finally, the patch itself :

Code: Select all

HDPATCH1   8671 : PHA         48          /temp stack of drive ctrl word
           8672 : AND $FE18   2D 18 FE    /AND ctrl word with HD detect bits
           8675 : JMP $91E0   4C E0 91    /jump to part 2

HDPATCH2   91E0 : AND #3      29 03       /mask for two lsb
           91E2 : BNE SD      D0 05       /non-zero means accessing HD
           91E4 : PLA         68          /else retrieve drive ctrl word
RTN        91E5 : STA $FE80   8D 80 FE    /write drive control to 177x
           91E8 : RTS         60          /and return to ADFS
SD         91E9 : PLA         68          /retrieve drive ctrl word
           91EA : ORA #8      09 08       /set single density bit
           91EC : BNE RTN     D0 F7       /and goto write to 177x and exit

With the patch installed, HD and DD discs are now automatically catered for without any user intervention. It works just fine as long as you don’t mind the two shortened error messages :wink:.

The technical summary - mixed HD & DD discs are handled in ADFS by setting the 177x to Double Density (ADFS default) for DD and to Single Density (new mode) for HD. The two-chip clock switcher automatically selects the correct 8 (DD) or 16 (HD) MHz clock speed for the 177x according to media type and the additional LS244 input port informs the patched ADFS whether the drive being currently accessed is using HD or DD media. (The two additional wires added after the 244 is fiited are HD_PRESENT_0 from S4 West to S11-1 and HD_PRESENT_1 from S10 East to S11-2)

As I said in my previous post, all that now remains is for me to modify (or write :shock:) an ADFS formatter such as AFORM to operate in HD 16MHz single density.

Overall, I acknowledge that the ADFS mod is a bit involved and would still require a bespoke patch for a different version or brand of ADFS. However, it’s now in my Beebs and, with the lid on, they look and behave just like any other but, as with the DFS version, the great thing is that I can freely use ADFS HD and DD discs without a second thought.

I still think the DFS mod is spot-on and I can’t think of a single reason not to fit it. It only mods the 177x module with one (reversible) track cut, doesn’t need any software and so will work with any DFS out there and when it’s properly fitted with all but one of the wires under the motherboard it doesn’t look too bad either….
clock switch neat.JPG
It's just a shame they don't make green Veroboard....
(88.08 KiB) Downloaded 2252 times

I’ll bring one of these Beebs along to the Byte-Back event and put it on show as the ‘Floppiest Beeb in the World’ :lol:. They have a dual 8271/1772 interface, correctly use HD floppies in DFS and ADFS and can directly read a PC floppy containing an archive disc image and convert it to a true DFS floppy (courtesy of RAMagic! of course :wink: )

Martin

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

Re: high density disks

Postby MartinB » Sat Dec 06, 2008 12:35 am

I've still had no joy with a disc-based ADFS HD floppy formatter but at least now I understand why :evil:

I've been getting some crazy things going on and it's basically been down to a) that the disc-based AFORM I have been playing with is for the Master (of course it is you fool #-o) - the latter having different 177x register addresses and a different Drive Control word and b) to really confuse me, typing *AFORM has been either running AFORM from disc or, thanks to ADT allowing an 'A' prefix for it's rom commands, been running FORM xxx from rom! What a mess.. :oops:

Anyway, I now realise that I don't actually have a disc based format program for ADFS on a Beeb, only for the Master. I could re-work the Master version to be Beeb compatible but before I do, I thought I'd ask if anyone has an ADFS disc formatter for the Beeb. If Acorn sold ADFS for the Beeb then I presume there was some sort of utilities disc as per the Master?

If anyone has such a utility, or can point me to one, I would be grateful and a DFS ssd or dsd would be better than an adl since I don't have a swish real disc-maker for adl images although perhaps I could convert an adl through BeebEm using the ADFS file format conversion commands?

I'm not screwed without this, I can happily format HD floppies with ADI but I wanted finish the ADFS HD project with a deliverable ADFS 1.30HD image and a matching HD floppy format program.

Thanks in advance, Martin

[ PS - I haven't abandoned HD ADFS on the Elk, I just wanted to get the Beeb finished first but I also do need to come up with an equally neat way of flagging the presence of a HD floppy to the ADFS software. Ideally a similar idea to the Econet ID on the Beeb but of course such things are always trickier on the Elk :( ]

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 » Sat Dec 06, 2008 10:54 am

Hi.

Utilities for the BBC B Attached. (In ADFS Explorer format)

You're doing sterling work there, keep it up! Remember True HD ADFS is in MFM mode - I know it's a work in progress, just a bit worried to see you wanting to patch ADFS to use FM, but presumabely that's a step on the road to testing to get it working in full 1.6MB...

Mark.
Attachments
BEEB ADFS.zip
BBC ADFS 1.30 (1.33) Floppy Utilities
(6.51 KiB) Downloaded 106 times

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

Re: high density disks

Postby MartinB » Sat Dec 06, 2008 12:57 pm

Thanks Mark, you're a star :D

Yep, full HD not forgotten and the end of this phase should be ideal to work from. If you have a mental picture of what hardware and software the final solution might/should/must consist of, please feel free to think out loud. I'm probably going HD stir crazy so might miss an obvious trick - even my imaginary friend has been missing for a week :)

Martin

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

Re: high density disks

Postby MartinB » Mon Dec 15, 2008 12:14 am

Do we have any experts on floppy formatting? I've modified the Beeb ADFS AFORM program to work in SD (FM) for use with my HD floppy mod and it formats ok but then won't verify or *MOUNT :?. However, if I duplicate a normal DD (MFM) ADFS disc onto a HD floppy in single density (FM) using ADI then that disc works fine. I'm now suspecting that ADI sees that I'm going from DD to SD (or specifically MFM to FM) and is modifying these Gap thingies etc. to suit the FM SD. Therefore, I'm perhaps not actually cloning the disc bit-for-bit but am re-writing it in FM SD which, despite the 16 sectors, I am able to do in SD because of my 16MHz mod.

The ADI manual has this info in it :

Code: Select all

Field                     FM      Value   Length  MFM   Value   Length
Post Index Field Gap (1)  -        &FF      P      -     &4E      P
                          -        &00      6      -                 
Sector ID Field           -                        -     &00      12
                          -                        -     &A1      3
ID Address Mark           -        &FF      1      -     &FE      1
T/ID                      -        Track    1      -     Track    1
H/ID                      -        Head     1      -     Head     1
S/ID                      -        Sector   1      -     Sector   1
L/ID                      -        Length   1      -     Length   1
CRC                       -        CRC      2      -     CRC      2
Post ID Field Gap (2)     -        &FF      11     -     &4E      22
                          -        &00      6      -     &00      12
                          -                        -     &A1      3
Data Field                -                        -               
Data Address Mark         -        &FB      1      -     &FB      1
Data Bytes                -        Data     Sector -     Data     Sector
CRC                       -        CRC      2      -     CRC      2
Post ID Field Gap (3)     -        &FF      P      -     &4E      P
                          -        &00      6      -               
Final Gap (4)             -        &FF      -      -     &4E      -

I wonder then if I should further modify AFORM to change these Field Gap parameters (and some others?) to match the FM set assuming they currently correspond to the MFM set :?.

It's a complicated area (made more so by me I suppose) because I'm using FM SD but at 500KHz on a HD floppy and am therefore achieving the 16 sectors normally only possible with MFM. Get yer thinking caps round that if yer can... :)

(Of course, I am assuming these parameters are under software control and not an automatic function of the 177x? - Yes, I'm being lazy and haven't read the WD data sheets I provided... :roll: )

Martin

SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: high density disks

Postby SarahWalker » Mon Dec 15, 2008 11:41 am

Those parameters are all under software control. The WD177x doesn't have a format command, just a 'write track' command. The formatter has to build up a blank track in memory.

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

Re: high density disks

Postby MartinB » Mon Dec 15, 2008 2:12 pm

Ok, thanks Tom :)

Yeah, that prompted me not to be lazy and to do some reading and I see what you mean. This kind of fits what's going on too because I guess you could write any old nonsense when doing a 'format' but it wouldn't necessarily make a usable disc. That's probably why the format sequence works fine but because the gap data etc. isn't correct for SD it subsequently fails to verify or mount. Buliding a track in memory also explains why the format program first relocates itself right to the top of ram and why I see the rest of the ram, including all the usually safe 'cubby holes', filled with various patterns of bytes.

I think then that I will have to try and find these format specific bytes in Beeb AFORM and change them to their SD equivalents.

Sounds like fun... :^o

Martin

User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: high density disks

Postby regregex » Tue Dec 16, 2008 9:33 pm

retroclinic wrote: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.
While PCs won't be expecting the combination of 500 KHz and FM, the format isn't as unbreakable as say C64 or Mac CLV discs. In fact this is what the IBM minis used on 8" floppies :)
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.
IMHO it was to consolidate more functions on less silicon, and because Atari had all the Ajax controllers :) ADFS F also uses 1024 byte sectors IIRC, so a lot of routines would need to be reworked.
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.
Then you'll be glad to know I've done HD with a proper stacking NMI service routine (watch). I've only ever written a (slightly more marginal) routine for writing but it proves that reading can also be completed in time. For instance the read routine would be

Code: Select all

0D00    LDA &FE83   ;FDC data register
0D03    STA &FF00,X ;top byte is set to appropriate page, bottom byte is always 00
0D06    INX
0D07    BNE &0D0C
0D09    INC &0D05
0D0C    RTI
so the busy loop must preset X then leave A and X alone, and test the status register only using Y. LDY copies bit 7 (motor on) to N, bit 0 (busy) can be tested with pairs of INYs in a loop or BIT-ing a 128 byte lookup table.

When writing, the loop must fetch the first byte to write into A, set the 'split' pointer to the second byte, then send the command. The fastest write routine would then be

Code: Select all

0D00    STA &FE83
0D03    LDA &FF00,X
0D06    INX
0D07    BNE &0D0C
0D09    INC &0D05
0D0C    RTI
I hasten to add that only the DRQ line can raise an NMI in this case; INTRQ would have to be disconnected and the status determined by polling. EDOS has operated this way in all densities from the start.

--Greg

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

Re: high density disks

Postby MartinB » Tue Dec 16, 2008 10:09 pm

Hey thanks for that Greg - I knew you were more of an expert on this stuff than you were letting on :D. Enlightened to your identity, I've studied your EDOS work and it's brilliant, props to you mate! It's also encouraging to know that on top of the hardware mod there's still scope for further stretching of the envelope with some slick NMI code. Before progressing to that though, I'd like to finish the current phase and be able to offer a solution for DFS & ADFS HD and, if you've read the preceding trail, I'm all but there apart from an ADFS format program. Am I right in thinking that if I change the Gap etc. parameters to SD as in the table above then the formatter should work? Slightly out of my depth you see... :)

Martin

User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: high density disks

Postby regregex » Wed Dec 17, 2008 4:43 pm

Hi Martin,
MartinB wrote:Do we have any experts on floppy formatting? I've modified the Beeb ADFS AFORM program to work in SD (FM) for use with my HD floppy mod and it formats ok but then won't verify or *MOUNT :?.

Don't know why this should be. The byte stream to the controller may as well be the same, just without the F5/A1 sync bytes. Other differences like the filler byte values and gap2 shouldn't matter at this stage.
However, if I duplicate a normal DD (MFM) ADFS disc onto a HD floppy in single density (FM) using ADI then that disc works fine. I'm now suspecting that ADI sees that I'm going from DD to SD (or specifically MFM to FM) and is modifying these Gap thingies etc. to suit the FM SD. Therefore, I'm perhaps not actually cloning the disc bit-for-bit but am re-writing it in FM SD which, despite the 16 sectors, I am able to do in SD because of my 16MHz mod.

"Monsieur Neary, I envy you." Never had the opportunity to run a disc imager due to my alien controller. I'm mystified how ADI could know about changing from MFM to FM, I would expect it to duplicate like for like. But an MFM byte stream to the controller should write either an MFM or a (slightly non-compliant) FM track simply according to the logic level on /DDEN. Did you say you were massaging /DDEN according to the media type sensed by the drive? So I expect ADI is regenerating the track format as normal, expecting to create a DD/MFM disc like the input, only it is writing HD/FM instead. So the difference between FM and MFM, 250 kHz and 500 kHz is fully encapsulated in the 1772, with only minor differences in the format byte stream.

At the very least, this is one route to making blank HD ADFS discs.

AFORM should work okay with the current byte stream, or better if the stream is modified to FM as per the ADI manual. From my own tests I suggest a gap1 size of &24 and gap3 of &5F to space the sectors evenly.

--Greg

SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: high density disks

Postby SarahWalker » Wed Dec 17, 2008 6:53 pm

I'm not certain the gap size is that important. What is important though, are the ID address and data marks - if these aren't right then the FDC won't be able to read any data at all.

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

Re: high density disks

Postby MartinB » Wed Dec 17, 2008 6:59 pm

Hi again Greg.

beardo wrote:I'm mystified how ADI could know about changing from MFM to FM, I would expect it to duplicate like for like.
When you use ADI's copy disc functon, it defaults to like-for-like but if I try that it fails when it tries to write to the HD 500KHz destination. However, if I override the default settings (ADI caters for this) and set the destination to FM (obviously leaving the DD original source at MFM) then it works fine. I'm not otherwise touching ADI, no patches or anything.

I've already patched ADFS 1.30 to set density to SD (1) when a HD disc is flagged as present via the new 'port' at $FE18 and doing this allows an ADI formatted HD disc to be used quite happily under ADFS :D

I initially patched Beeb AFORM in exactly the same way (it otherwise just hangs with a HD disc) and whilst the format now flies through, the verify phase reports an error and sure enough, the disc can't be used, even with my patched ADFS :(

This is how I then got drawn to the gap etc. bytes because I couldn't see any other reason for the
failure :?

Martin

User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: high density disks

Postby regregex » Wed Dec 17, 2008 9:13 pm

Thanks Martin, you've made it a lot clearer. Good of ADI to press on with FM even though the disc would ordinarily not have enough space. I admire programming like that, not setting arbitrary limits :)

Clearly then ADI is formatting a legit FM track and succeeding. If AFORM is having a problem then the byte streams aren't as interchangeable as I thought. One problem may be the F5 tokens that make the A1 sync bytes - in FM mode they are 'not allowed.'

@ Tom Walker: You're right, gap values aren't significant as controllers are v. forgiving. But a balanced arrangement of sectors is desirable, no? Or the disc will shake in the drive?

--G

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

Re: high density disks

Postby MartinB » Thu Dec 18, 2008 1:03 am

Nope, all getting a bit too much :roll: - this AFORM program is a bit tricky to manipulate at object code level so I think I'll just stick to using ADI. It's a suitably quick and reliable way of formatting a HD ADFS floppy and all it can't do is create the 6 system (map & directory) sectors but that's just a quick 1 track copy from a DD blank master. So....

1. Master formatted (blank) ADFS disc in drive 1. (After the first blank HD disc is made this master can of course itself be a HD)

2. Disc to be formatted in drive 0

3. Format both sides of drive 0 using <0 96 FM T:80 S:16x256> and <2 96 FM T:80 S:16x256> with track ID's 0-79 on both sides. (Must reset track ID to 0 after first side or it will continue from 80 upwards.)

4. Copy Track 0 (Side 0) from master blank to new disc. If master blank is DD then set source to <1 96 MFM> or if master blank is HD then set source to <1 96 FM>. (Destination HD disc is always <0 96 FM>)

Might sound like a bit of a handful but it actually only takes slightly longer than AFORM and this is easily offset by the sheer joy of being able to use HD floppies under ADFS :D

I'll call this a wrap then and summarise the whole package in a subsequent post. Next, it's HD ADFS on the ELK (if it's possible) and then, after a long lie down, I'll have a tinker with Greg's ideas and see if we can get ADFS MFM. Unless of course someone else fancies..... :)

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 » Thu Dec 18, 2008 9:49 pm

Hi.

I've never used ADI (I suppose I should start, when I get some free time!), but going by what you typed, what would happen if you asked it to do:

<0 96 MFM T:80 S:20x512>
<2 96 MFM T:80 S:20x512>

Would it spit out an error? If not, then aren't you almost at ADFS 1.6M? [-o<

Still would need to do some tweaking to the ADFS filing system, for the different filemap, "Nick" vs "Hugo" etc...but that should be the easy part...

Mark.

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

Re: high density disks

Postby MartinB » Fri Dec 19, 2008 10:20 am

Yeah, out of a similar curiosity, I have already done some experimenting with extended formats using ADI but the problem is how to interpret the results and then how to take things further - as I said, I'm not the world's expert on this stuff [-X

For example, I tried your suggestion last night and, with a DD disc and MFM or with a HD disc (+ clock mod) and FM, the format appears to go ahead and complete. If you then do a Scan to analyse the disc, it is does seem to read back ok but the basic layout of the disc is reported as 11 (?) sectors per track. However, the scan then proceeds and lists 20 sectors for each track but each is tagged with a result code of 14 where 0 would mean an error-free successful read. Just looking now at the manual, it doesn't actually list the error codes but suggests a subsequent *HELP RESULTS would detail any errors "for an 8271 controller" but I'll perhaps have to try and see if there's a way of getting some more info on 177x results.

There are of course finite limitations as to how much data can be physically be written to, and recovered from, a floppy disc but I suppose the Archie format demonstrates that 1.6Mb is achievable by using MFM on a DD disc. (I assume the Arc does use DD discs?) It would be interesting to see what ADI on a 177x Beeb made of an Arc 1.6Mb disc but I'm not sure that even if ADI could correctlty ascertain the layout, it would then be able to actually read the data. I suspect it would, as a minimum, need the 500KHz read rate?

Hmmm... complicated subject, well to me anyway, but they do say that if you put a hundred monkeys on typewriters then sooner or later one will produce a novel to compete with Shakespeare. Now I'm just one monkey but maybe if I keep going over it a hundred times over then there's a chance that sooner or later I might stumble on the complete solution :wink:.

Martin

SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: high density disks

Postby SarahWalker » Fri Dec 19, 2008 11:00 am

Arc 1.6mb uses HD discs not DD. The Arc DD format is 800k (5 1024-byte sectors per track).

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

Re: high density disks

Postby MartinB » Fri Dec 19, 2008 11:42 am

Ah, ok thanks Tom.

We already have 640k via ADFS with MFM and WE DDFS at nearly 800k so probably then the Arc 800k format would work too on an unmodified 177x Beeb assuming we had a version of ADFS that understood the Arc layout. For the 1.6Mb HD though we are straight back to MFM + 500KHz which is of course where we have the problem of keeping up with the data stream. Ho hum... :roll:

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 Dec 19, 2008 4:06 pm

Hi.

Do you have access to an Arc with HD? If not, PM me your address again, and I'll format you some HD 1.6MB disks, and the other DD formats, put some stuff on and send them on over, and see if you have any luck reading them?

Mark.

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

Re: high density disks

Postby MartinB » Fri Dec 19, 2008 4:47 pm

No I don't have an Arc but yes, that would be very useful :D

Thanks Mark, I'll send a PM.

Martin

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

Re: high density disks

Postby MartinB » Tue Jan 20, 2009 12:40 am

Mark (retroclinic) kindly sent me some floppies to play with in pursuit of the HD floppy ‘Holy Grail’ and I had a little play over the Xmas hols but due to the slow post-festive sobering process, I thought I’d return to the experiments when fully, err.., refreshed :wink:

Mark basically added the WE 800K (on DD) and Arc 1.6M (on HD) formats to my collection across a number of empty, populated and (deliberately) defective discs. Not surprisingly I think, the Arc 1.6M discs were fundamentally unreadable even with my HD mod and ADI just reported ‘No sectors found’. Out of interest, I then had a cursory play with some fast NMI routines as suggested by Greg (beardo) and I did, by modifying some of my RAMagic! low-level routines in conjunction with the HD mod, manage to grab the odd sequence of bytes but never yet a full sector. This I feel will require a lot more thought and measurement-driven testing :?

Also not surprisingly, ADI could happily read the WE 800K discs and revealed them to be 80 MFM tracks of 5x1024 byte sectors. Since these are DD discs, reading them was easy for the Beeb because this capacity is within the design envelope of the standard 8MHz DD 1772. So, as an initial test, I tried to copy one of these DD discs to a HD disc supported by my HD mod (and hence at 16MHz FM) because I already know that the latter configuration will happily support the ADFS 640K (80x16x256) capacity. However, on each track, ADI smoothly copied the first four sectors but issued an error 24 (?) for the fifth sector. A subsequent scan of the copy disc then suggested that there were only four error-free sectors per track at 5x1024. This is perhaps slightly puzzling but I guess is likely due to the fact that 16MHz FM isn’t quite as angularly efficient as 8MHz MFM and hence the full 5x1024 sectors don’t quite physically fit into 360 degrees at the given rpm. However, I was copying from 35 DD to 525 HD so it’s still possible that if I were to copy to another 35 disc, the marginal increase in angular density offered by the 35 format might allow the 16MHz FM mode to cope.

Oh well, as expected, plenty of work to do to get full HD but as a cheerful update, the HD modified Beebs (DFS & ADFS) and Elk (DFS) have had a damn good thrashing and are working just fine :D.

For interest, my background task on HD floppy DFS is to see if an Opus Challenger 3in1 can support HD – I just love these units and if I can mod one to HD it will make a great peripheral even better :)

Martin
Last edited by MartinB on Tue Jan 20, 2009 6:58 am, edited 1 time in total.

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 Jan 20, 2009 12:48 am

Glad to see it's keeping you busy, keep up the good work! =D>

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

Re: high density disks

Postby MartinB » Tue Jan 20, 2009 3:23 pm

This is a kind of spin-off topic and I think it has sporadically cropped up before but…..

If you have been following the above thread then you will know that the fundamental problem with reading a seriously high capacity disc is that whilst the (pimped) 16Mhz 1772 fdc can happily read the data, the poor old 2MHz 6502 struggles to retrieve and stash the byte stream quickly enough and even with some slick NMI coding I think a working solution will always be marginal :(

Therefore, I was wondering if I could perhaps replace the 6502 with a 4MHz version and add a clock switch similar to the 177x switch I’ve already installed? This faster CPU would nominally run at 2MHz but, during the critical phase of HD sector reads, would be transiently accelerated to 4MHz via some appropriate logic. Blinkers on, this would immediately solve the problem and would in fact allow the existing DFS/ADFS code to remain as is :). I’ve initially suggested 4MHz over 3 since there is a 4MHz clock already available in the Beeb whereas a 3Mhz clock would have to be generated and would (slightly) increase the complexity. I suspect I could knock up a prototype with just one extra IC and a few flying lead pick-ups. In fact, with my 1772 mod and for a quick test, it would be incredibly simple for a 4MHz CPU if I just added a divide-by-four to the 1772 clock input such that when the 1772 is accelerated to 16MHz the CPU would automatically be stepped up to 4MHz and at 8MHz it would step down again to 2MHz. The downside to that quick fix though would be that the drive 'Motor-On' period (which is when the 1772 is speeded up) may be way too long to allow the Beeb to stay sane. It may therefore actually require a software switchable CPU speed selector such that in the DFS code, the 'turbo' mode would only be engaged immediately after the read sector request has been issued and cancelled as soon the sector has been read.

Anyway, without having given this too much thought, I can foresee one or two possible problems but I thought I’d throw this open for discussion. The first issue I can see is that any chips active during the ‘turbo’ period must have access specs. fast enough for 4MHz (e.g. the main DRAM IC’s). Secondly, and this is where I’m not sure what the problems might be, is that it might have some strange effects on the display system. Would the screen fall over? Will the closely linked memory refresh and display access fall over? If any problems were just transient trembles during HD disc access periods then I guess it wouldn’t matter – I suppose it would be a bit like the sluggish Elk copes now with the higher res screen modes and a disc drive :?. Finally, are there issues with these faster processors having extended instruction sets which would then clash with software (typically games) which exploit the current 6502 ‘undocumented’ and/or ‘illegal’ op codes?

If this were possible, then the new ‘turbo’ mode could be invoked for all manner of things, not just HD disc access, and if the clock switch were another 151 or similar then there would be scope for different enables/inhibits for the faster speed. I would stress that this type of speed-up, assuming it is technically feasible in this context, can only ever be used for transient bursts because there are huge designed-in dependancies on the 2Mhz clock and the Beeb as a whole cannot support a full-time speed increase without major changes to the hardware and firmware.

Praise, discuss or ridicule as you see fit.... :wink:

Martin

SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: high density disks

Postby SarahWalker » Tue Jan 20, 2009 7:02 pm

Anyway, without having given this too much thought, I can foresee one or two possible problems but I thought I’d throw this open for discussion. The first issue I can see is that any chips active during the ‘turbo’ period must have access specs. fast enough for 4MHz (e.g. the main DRAM IC’s).


The DRAMs are fast enough for this, but :

Secondly, and this is where I’m not sure what the problems might be, is that it might have some strange effects on the display system. Would the screen fall over? Will the closely linked memory refresh and display access fall over?


I _think_ that the CPU cannot access RAM during what would be display access slots, ie it cannot run faster than 2mhz.

There's nothing stopping it accessing other memory faster, though! What you could do is hook the CPU up to an SRAM (like one of the ones I sent you) and have the SRAM mapped in over the bottom 4/8k of memory, like the various Electron upgrades do. You could then have sector read/write code in this area, and just switch to 4mhz on entering one of these routines, and back to 2mhz on leaving?

This is probably more complicated than it seems in my head, but it's one idea at least.

The Solidisk Fourmeg board upgrades the beeb to a 4mhz 6502, but I'm not sure how it works, or how it interfaces with the rest of the machine.


Return to “hardware”

Who is online

Users browsing this forum: 1024MAK, DutchAcorn, GrahamN, myelin, nama and 25 guests