high density disks

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: high density disks

Postby MartinB » Tue Jan 20, 2009 9:08 pm

Thanks for that Tom and more importantly thanks for keeping it positive - it sometimes feels quite lonely out here on the whacky (some say deranged) hardware fringe :lol:

Hmmm... Yes, what you say about the screen v CPU does ring a bell but where does the 2MHz limit come from? I can't get my head round the maths after a cutting edge day at work :). Frame rate is 20ms and Line rate is 64us but I can't make the numbers fit - maybe resolution comes into it too? I'll have a read of the AUG and the service manual technical description and see if I can definitely rule out using normal ram. Presumably this access restriction would apply to the low pages too even though the screen circuitry doesn't go there? The major appeal to me of using system ram is hardware simplicity and the fact that it would allow all existing DFS software versions to work without modification and a new DFS would be only be needed for the new-to-the-Beeb high capacity formats such as Arc 1.6Mb and PC 1.44Mb.
Tom wrote: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.
I have two of those (which is why I have a 4MHz CPU to play with :wink: ) and their design kind of circumvents the screen ram problem by only switching to 4MHz when the Solidisk board's resident sideways roms are accessed - ram access remains at 2MHz. That scheme is thus much as you are suggesting where we we would add some private 4MHz ram as a sector buffer. Presumably, and as you inferred, the Elk $E00 DFS' effectively use this technique already to provide full speed ram although not for HD reasons.
Tom wrote:This is probably more complicated than it seems in my head, but it's one idea at least.
Well..., maybe, but still not beyond reason. Actually, if it was carefully thought out it could probably all be hosted on a 40 pin daughter board in the CPU socket in a similar way to the 177x upgrades. (If Mark's reading this, don't despair that this is going off the rails again - it could be a nice little plug-in earner for someone with PCB facilities :wink: )

Certainly worth some thought and action so I'll multiplex it in with my other projects :roll:

Martin

RobC
Posts: 1820
Joined: Sat Sep 01, 2007 9:41 pm

Re: high density disks

Postby RobC » Tue Jan 20, 2009 10:11 pm

Hi,

Great thread - although much of it is over my head!

I think the 2MHz CPU limit comes from the way the Beeb interleaves video and CPU memory accesses. Had this explained to me not too long ago by a friend...

The memory is rated at 4MHz which gives 4 'slots' per uS. The video circuitry (operating at 2MHz) gets 2 of them, say 1 and 3, and the CPU (also at 2MHz) gets the others, say 2 and 4.

So, if the CPU is instead run at 4MHz and tries to access memory on consecutive cycles, there is contention with the video circuitry.

Don't know if this is any different in 'slow' modes (e.g. 4, 5 etc.) but I think this is what Tom is getting at.

Cheers,

Rob

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

Re: high density disks

Postby MartinB » Tue Jan 20, 2009 10:31 pm

Ah ok, understood - Cheers for that Rob :)

What would happen then if the video was made lower priority and denied ram access whilst the CPU was reading a sector? I think that would be the inverse of the Electron functionality which is why my HD mod falls over on an Elk in Modes 0-3 :?

Would the screen just flicker as 0's, FF's or 'floating' garbage were seen by the video bus and then catch up on the next successful read?

Just trying to assess the pro's and con's of the various approaches :?

Martin

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

Re: high density disks

Postby SarahWalker » Tue Jan 20, 2009 11:04 pm

MartinB wrote:What would happen then if the video was made lower priority and denied ram access whilst the CPU was reading a sector? I think that would be the inverse of the Electron functionality which is why my HD mod falls over on an Elk in Modes 0-3 :?

Would the screen just flicker as 0's, FF's or 'floating' garbage were seen by the video bus and then catch up on the next successful read?


My reading of the schematics is that the CPU is taken off the DRAM bus during video access, so it would just read/write junk and crash very quickly.

This only seems to apply to the base 32k DRAM (64k on the B+ and Master), it may be possible to read everything else at 4mhz?

Don't know if this is any different in 'slow' modes (e.g. 4, 5 etc.)


It's not, the access pattern is the same no matter what the mode. Modes 4/5/6 read the same address twice, mode 7 flips A6 to keep DRAM refresh going.

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

Re: high density disks

Postby MartinB » Fri Jan 23, 2009 10:32 am

Well, had a good play with 4MHz and and I've decided that this particular idea falls into the "What on earth were you thinking Martin...? " category.... [-X

Yeah, the whole Beeb clock set-up is a heavily interdependant system and to just get a particular chunk of code to run at 4MHz is definitely a tricky task. I did eventually get the fast CPU to, err.., 'perform' at 4MHz but goodness only knows what code it was running and as for the rest of the machine.... :lol:

I remember now that even the Solidisk 4 Meg is a fickle beast and it will only run properly in certain of my Beebs. I wondered if by putting the DFS rom onto the Solidisk that the then faster disc code might pull back some time but of course the NMI code is downloaded to ram (usually $D00->) so there's no useful gain.

Anyway, a couple of spin off snippets for interest.....

The 4MHz CPU is a Rockwell P4 and it does run happily in a standard 2MHz Beeb although as I questioned before, there may be issues with some of the fiendish game code out there.

I first had a foray into this 'speeding things up' area some time ago when I noticed that the Acorn 6502 2P has a link, L5, alledgedly to allow the clock to be set to 4MHz if the unit is running a fast (P4) CPU instead of the standard 3MHz device. I duly fitted the P4 CPU and made the link and it kind of worked but it seemed a bit unstable. I planned one day to pursue that experiment but never got round to it. Does anyone know any more about this ?

Oh well, maybe a super efficient NMI routine is going to be the only way to go. We shall see...

Martin

RobC
Posts: 1820
Joined: Sat Sep 01, 2007 9:41 pm

Re: high density disks

Postby RobC » Sat Jan 24, 2009 1:18 pm

Just a thought but if this can't be done with efficient routines on the 6502, might it be possible to offload the high speed read/writes to something like a PIC?

This would probably involve more significant software patching but something like the 16-series PIC I'm using for my Beeb MMC interface should be able to sit between the 6502 and FDC. With a 20MHz crystal, it runs at 5 MIPS and has ~300 bytes of RAM free to act as a buffer.

Cheers,

Rob

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

Re: high density disks

Postby MartinB » Sat Jan 24, 2009 5:50 pm

Hi Rob.

I'd already considered an independant fast buffer although I hadn't particularly thought of a PIC but yes, I'm sure you're right, that would be as good a way as any :). I guess though that I'm still hoping for a Eureka moment such that I'll discover a solution which doesn't require additional hardware AND additional software. The nice thing about the original two-chip DFS/ADFS HD mod is that it just passively hangs off the Beeb, there's only the one track cut on the 1770 module, all DFS work unmodified and ADFS just requires the one small patch to keep things in FM only.

I am now focussed on a software only solution to the 16MHz MFM dilemma and I have actually made some headway at last so watch this space.... :wink:

Martin

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

Re: high density disks

Postby MartinB » Thu Feb 05, 2009 12:29 am

Hello, me again :)

I'm glad I said somewhere that I would hopefully have a true HD reader to report :(

You see I had, not for the want of trying, pretty much exhausted the approach of a super slick NMI routine when I had a lateral thought.... I figured that if a quad increase in speed (x2 for MFM and x2 for 16MHz/500KHz) was leaving insufficient (sensible) time to grab every byte, then why not just grab every other byte, say the evens, and then just read the sector again, this time grabbing the odds. Basically, we would set about processing a byte, expect to be interrupted part way through, but the NMI re-entry would recognise it was an alternate byte, clear the DRQ and then immediately RTI to the first byte process which would then finish before the next alternate byte. Sounds complicated but it's actually quite simple and thanks to the thoughtful 177x designers, a lost byte does not terminate the sector read, it just carries on regardless throwing bytes off the conveyor belt until the end of the sector providing there are no other errors. By writing a deliberately sluggish routine I was able to test the theory at slower speeds and things were looking promising :). However....

After much tortuous experimentation, I now have to question whether the 1772 is actually physically capable of functioning at the higher 500KHz rate AND in MFM. I say this because as soon as I combine the two, I cannot get the chip to 'see' any data :?. I'm only able to use Mark's Arc 1.6Mb discs or standard 1.44Mb PC floppies but in both cases I can't get the FDC to read a sector.

Looking at a re-print of an earlier picture....
cs.JPG
(7.16 KiB) Downloaded 2188 times
....we can see the (black) 'Data Ready' NMI's from the 1772 and at 16MHz/500KHz + FM, the bytes are fired out at 32us intervals (Z). If I then switch to MFM, I would expect to see Z reduce to ~16us which, although it makes things tight, is still 32 cycles-worth of instructions. Therefore, the simple NMI routine below, although not actually doing anything with the data, should allow the 'stream to flow' without falling over.

Code: Select all

        LDA fdc_status
        AND#$1F
        CMP#3
        BNE exit
        LDA fdc_data
exit    RTI
This only takes 20 cycles (17 if the branch succeeds - DRQ test fails) and is the simple routine I normally use for timing measurements but, at 16MHz MFM, the trace is blank. This suggests to me that the FDC just isn't up to the job [-X.

Conclusions? I will have another go with the Atari 'Ajax' in place of the 1772 but that probably won't now be until after Byte-Back so unless someone has any bright ideas, I think that the HD Holy Grail, like so many other Grails before it, will remain an urban myth for the time being :wink:.

Beeb and Elk DFS on HD floppies is still a total result for me (and ADFS too if you don't mind a patch and ADI as a formatter) so I remain, as ever, well 'appy :D

Martin

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

Re: high density disks

Postby MartinB » Fri May 15, 2009 10:45 am

It's funny how when you revisit stuff after a break that you suddenly spot something obvious you missed the first time round... #-o

I have been playing with some ex-Atari PH-02-02 and Ajax chips on and off and decided that I was ready to fit a socket to one of my Acorn 177x modules to progress the HD investigation. Whilst contemplating that thought, I have also been idly studying some Atari disc I/F schematics and I noticed that on the Falcon, which uses the Ajax, Pin 26 of the chip, /DDEN, is tied straight to ground. That in itself was not startling, it just tells us that the Falcon doesn’t use SD FM at all, but the eureka bell it rang was that the 177x chips aren’t commanded to SD or DD by software but by hardware. Stupidly, I already knew this, but one''s thinking is fogged a little on the Beeb etc. because of the ‘Drive Control Register’ (DCR) which, as I’m always reminding people, is a ‘pseudo-register’ in that it’s not actually a 177x internal register but is Acorn’s software access point to the various hardware control lines associated with an FDC implementation. It looks like a typical chip control register but in fact the single bits within essentially have a logic gate or two behind them which then set or reset hardware control lines to the 177x or the drives. Thus, the DD/SD bit in the DCR simply sets or resets Pin 26 of the 177x.

Now, you may remember that the ADFS side of my mod got a bit messy because, although I got it working, I’d had to patch the ADFS (1.30) code in several places to ensure that the 177x was held in SD FM if a HD floppy is being accessed. The problem with this software method is that it necessarily requires a special patched version of any and every ADFS version that people may use and basically that just becomes an unworkable nightmare [-X

So, given all of the above, it just dawned on me that if I were to simply isolate Pin 26 of the 177x from the DCR and add some form of direct hardware control, I could automate the SD/DD selection and remove the need for a patch. To prove the idea, I have thus far simply cut the track to Pin 26 and (only temporarily!) added a switch to 0v (DD) or +5v (SD). The result of this is that by setting the switch to SD, (and with my original 16MHz clock mod), any version of ADFS now works happily with HD floppies \:D/

All I need to do then to automate this selection is to add a few gates that will only allow ADFS to select DD via the DCR if a DD floppy is being accessed. If a HD floppy is being accessed, the DCR request will be inhibited and SD will be forced. This method will not only remove the need for a patch, and hence allow any ADFS to be used, but will also remove the need for the extra LS244 I added to flag the presence of a HD floppy in a drive. Finally, it will also allow the Electron version of my mod to be upgraded and hence HD ADFS on the Elk is now a goer after all :D

One problem remains though – whilst this extra tweak works fine in that an un-patched ADFS now happily reads and writes HD floppies, the Beeb version of AFORM still fails in exactly the same way as before i.e., the format flies through fine but the verify fails with an error 10 ($10?) at track 0. I can still use ADI to format an ADFS HD floppy but I don’t understand why AFORM fails :?. Maybe, as we have discussed previously, it’s something to do with those mysterious (to me) control bytes in the format stream? Anyone have any ideas?

Anyway, I’ll create the active circuit necessary to automate the 177x Pin 26 SD/DD selection and publish the details in due course. This is certainly another leap forwards and IMHO makes the whole HD floppy thing an even more viable modification =D>

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 Jul 08, 2009 5:39 pm

Good news, I have duplicated Martin's result and got DFS working in high density on the 2791. Waiting the recommended 50 µs for the controller to reset apparently made all the difference. The delay has been put into the latest EDOSpat and simply changing the latch values yields the HD mode. *jammy git*

I have tested it with Reet Petite (of course) and just for comparison, formatted the same surface to 'normal' DFS and it failed as expected.

But... interestingly, setting the latch to high-speed and MFM gets as far as reporting "Lost data". Again success was not expected, but it may just be a case of reworking the NMI routines as I described before in this thread and have done in the multiformatter.

Btw I tried a while back to get EDOS to attempt reads in three densities, but it didn't work and the insufficient reset delay was probably why. I may try to merge that fork into the current code at some point.

--Greg

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

Re: high density disks

Postby MartinB » Wed Jul 08, 2009 6:42 pm

Nice one Greg =D>

And to clarify where you are (for me and others), I assume you mean you can now use HD floppies for DFS and AFDS as I can or have you additionally been able to read/write higher HD capacities?

Also... as you know, I ended up with 100% HD media functionality under DFS :D but I still have to use ADI to format HD ADFS floppies :roll:. Would your mutiformatter perhaps hack the latter with a 1772 ?
I confess that I was so engrossed in what I was doing that I never actually asked you that specific question :?

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 Jul 08, 2009 8:58 pm

MartinB wrote:And to clarify where you are (for me and others), I assume you mean you can now use HD floppies for DFS and AFDS as I can or have you additionally been able to read/write higher HD capacities?
HD floppies for DFS: yes. \:D/
HD floppies for ADFS: no ](*,) ADFS was never ported to the '91 :cry:
PC-style high density: no, [-X I haven't done the necessary suite of fast NMI handlers but it is tantalisingly close.
Would your mutiformatter perhaps hack the latter with a 1772 ?
Don't see why not. The last numeric in the controller DATA line should be made nonzero to tell the program it has HD support (although in Martin's machine HD is selected by the second sensor in the drive):

Code: Select all

DATA &FE84,&00,&D9,&80,&FE80,&29,&03,&04,&08,&80,"Acorn 1772"
The ADFS format lines also need to be changed to HD FM (6th and 7th numerics), to write the appropriate style of lead-ins.

Code: Select all

DATA 2,80,16, 256,  0,0,1,  3,  1,&24,&2C,-3,  0,"Acorn ADFS (L) 640 KB"
I don't anticipate any other mods are needed right now, though no doubt this won't work first time. --Greg

This site is ace This site is ace This site is ace

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

Re: high density disks

Postby regregex » Sat Jul 11, 2009 11:24 pm

Following hot on the heels of Mark's USB enabled BBC comes another first: quad density floppy disc access with contemporary parts!
hddisc.jpg
high density disc screenshot
(17.65 KiB) Downloaded 1792 times
Proving that the Beeb can sustain the necessary transfer rate through NMI servicing. For your amusement here is the worst case timing diagram for each of the I/O memory handlers:

Code: Select all

                      |             FDC service deadline
v                             v     NMIs (allowing for jitter, fast discs)
0....:...10....:...20....:...30.... 2 MHz ticks

Prev..Nmi....EoSta.InBnInc...Lda>>> Write from I/O
Prev..Nmi....Lda.EoSta...InBnInc>>> Read to I/O
Prev..Nmi....Sta.Dec....BnInLda>    Format
Prev..Nmi....Lda.EoDeBnSta.Rti>>>   Read ID to Tube

Prev..Nmi....Sta...InBnInc...Lda>>> Write from I/O (FDC @ 1 MHz)
Prev..Nmi....Lda...Sta...InBnInc>>> Read from I/O  (FDC @ 1 MHz)

RTIs not shown are executed at a less busy time.

Busy loop cannot contain 7-cycle instructions
(unless controller is 2793/2797/Ajax on 2 MHz bus -- remove EORs)
The disc above was formatted with my multiformatter and then *CATGENed with the patched EDOS.

It's not yet perfect, built-in formatting doesn't work at all and the first byte of any write is copied to the first byte of every sector. If I try to preserve A between sectors it fails with 'Lost Data' and I'm now down to a process of minimal increments to find the bug. This is fairly agonising as on each iteration the program must be crunched, sent to the BBC, assembled, loaded into ROM and then tested, taking about 8 minutes each time. Also Reet Petite is hanging before the first sample which may be a different problem.

--Greg
PS. As a subscriber to the mantra of 'publish before you perish' I have posted the unfinished versions above.
PPS. Not that I'm planning to go anywhere...
Last edited by regregex on Sat Jul 11, 2009 11:56 pm, edited 2 times in total.
Reason: links

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 Jul 11, 2009 11:34 pm

Hey, that's looking good! It's good to know that the Beeb can keep up with the timing. *CAT and read/write to an Arc ADFS 1.6M disk on a Beeb is getting closer....

regregex wrote:This is fairly agonising as on each iteration the program must be crunched, sent to the BBC, assembled, loaded into ROM and then tested, taking about 8 minutes each time


Holy Cow :shock: 8 minutes?!?! I'd be at my wits end if I had to do that whilst developing RamFS! For me, once I've changed the code, BeebASM takes about 2 seconds to assemble it, another few seconds to download it to the Dataman S4, then that Emulates a 27128 on a Beeb, so the whole process is about 8-10 seconds for each rewrite.

Time to get your credit card fired up....

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=260443530591

Mark.

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

Re: high density disks

Postby regregex » Sat Jul 11, 2009 11:58 pm

retroclinic wrote:Time to get your credit card fired up....

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=260443530591
Can your EPROM blower play GORILLA.BAS? :)

--G

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 » Sun Jul 12, 2009 12:48 am

regregex wrote:
retroclinic wrote:Time to get your credit card fired up....

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=260443530591
Can your EPROM blower play GORILLA.BAS? :)

--G


I've not tried, but I doub't it...but it can do EPROM emulation :wink: What one have you got then?

Can yours program a CK2605? :-k

Mark.

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

Re: high density disks

Postby regregex » Sun Jul 12, 2009 11:12 am

retroclinic wrote:What one have you got then?
A Stag Stratos ISA card with a Dell 486 attached. No fancy stuff like EEPROM or MCUs, but it can program devices up to 1 MBit.

--G

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

Re: high density disks

Postby MartinB » Sun Jul 12, 2009 3:38 pm

Nice work Greg =D>

Can you post the NMI routine in assembler or pseudo-code? I can't quite fathom what you've done from the post (good as it is :wink:)

Martin

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

Re: high density disks

Postby regregex » Sun Jul 12, 2009 5:06 pm

MartinB wrote:Nice work Greg =D>

Can you post the NMI routine in assembler or pseudo-code? I can't quite fathom what you've done from the post (good as it is :wink:)

Martin
They're much as described before; the write routines store before fetching so as to be sure of making the FDC's service time. This complicates the busy loop which now has to leave the accumulator free as it may change at any time. Note that if we're saving from the Tube, the instruction at edospat_disc_op_addr fetches one byte too many per sector; I'm running into problems trying to replace this.

Code: Select all

\Disc operation busy loop, copied to &0D10
\Based on NMI disc op routine from EDOS 0.4 by Alan Williams
\On entry A=saverom, X=address low byte, Y=FDC command
.edospat_disc_op
        JSR edospat_disc_op_switch_rom \change to *OPT 9 saverom
.edospat_disc_op_wait
        LDA fdc_base+0                 \wait until controller in accepting state
        EOR #st_sense% EOR disc_op_eor%
        AND #disc_op_and%
        OPT FNbndrq(ps%,disc_op_bne%,edospat_disc_op_wait)
                                       \loop while b5 and b7 both clear (WD2791)
        PHP
        SEI                            \disable interrupts
.edospat_disc_op_addr
        LDA nmi_form_bytes+0           \if writing, first address pasted here
        STY fdc_base+0                 \send command, A and X now out of bounds
        LDY #&14                       \wait 50us for status register to settle
.edospat_disc_op_settle
        DEY
        BNE edospat_disc_op_settle
.edospat_disc_op_loop
        LDY fdc_base+0
        OPT FNbrdy(ps%,st_sense%,edospat_disc_op_test_busy)
                                       \if b7 shows Ready, test b0 else loop
        JMP edospat_disc_op_loop
.edospat_disc_op_test_busy
        STY edos_disc_op_temp
        LSR edos_disc_op_temp          \test status bit 0
        OPT FNbbusy(ps%,st_sense%,edospat_disc_op_loop)
                                       \if b0 shows Busy, loop else exit
.edospat_disc_op_exit
        PLP                            \restore interrupt state
        LDA edos_disc_op_rom
.edospat_disc_op_switch_rom
        STA mos_romsel_copy            \page EDOS ROM back in
        STA bbc_romsel
        TYA                            \present FDC status in A
        EOR #sense%
        LDY edos_disc_op_cmd           \preserve for Read ID (&BCAE)
        RTS

\NMI service routines, each copied to &0D00
\If the FDC is on the 1 MHz bus remove EOR #sense%, there isn't time
.nmi_wrio                              \write to disc from I/O memory
        EOR #sense%
        STA fdc_base+3
        INX
        BNE nmi_wrio_addr
        INC nmi_wrio_addr+2
.nmi_wrio_addr
        LDA mos_nmi AND &FF00,X        \address high byte pasted here (low=0)
.nmi_wrio_exit
        RTI \===15
        EQUB &01 \...1                 \on entry A=byte from I/O, X=address low

.nmi_wrtu                              \write to disc from Tube
        EOR #sense%
        STA fdc_base+3
        LDA tube_host_fifo_3
        RTI \===9
        BRK:BRK:BRK:BRK:BRK:BRK
        EQUB &02 \0010                 \on entry A=byte from Tube, X=don't care

.nmi_rdio                              \read from disc to I/O memory
        LDA fdc_base+3
        EOR #sense%
.nmi_rdio_addr
        STA mos_nmi AND &FF00,X        \address high byte pasted here (low=0)
        INX
        BNE nmi_rdio_exit
        INC nmi_rdio_addr+2
.nmi_rdio_exit
        RTI \===15
        EQUB &04 \.100                 \on entry A=don't care, X=address low

.nmi_rdtu                              \read from disc to Tube
        LDA fdc_base+3
        EOR #sense%
        STA tube_host_fifo_3
        RTI \===9
        BRK:BRK:BRK:BRK:BRK:BRK:BRK
        EQUB &00 \0000                 \no entry conditions
--G

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

Re: high density disks

Postby regregex » Fri Jul 17, 2009 2:58 pm

I have fixed the problems and released EDOSpat 5.00. Reading, writing and formatting all work, and I have prepared what should be a suitable image for you Martin!
Here's the multiformatter line you'll need to create suitable discs:

Code: Select all

DATA 1,80,30, 256,  0,1,1,  9,  1,&48,&5A,-2,  8,"Opus DDOS (HD) 600 KB"
I'll work this into the release later.
Edit: Also works for 5.25" drives as well, whoopee! I find they have to be left at the factory setting of 360 rpm for HD so the gaps have to be adjusted:

Code: Select all

DATA 1,80,30, 256,  0,1,1,  5,  2,&48,&18,-2,  8,"Opus DDOS (5.25in) 600 KB"

--G
Last edited by regregex on Fri Jul 17, 2009 8:12 pm, edited 1 time in total.
Reason: 5.25in format line

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

Re: high density disks

Postby MartinB » Tue Jul 21, 2009 7:31 pm

Hi again Greg.

Many thanks for your continued efforts - I managed to miss this latest post again :oops:. I've downloaded all the relevant info so I'll sit down and have a study as soon as I can. As usual, spinning too many plates :roll:

Martin

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

Re: high density disks

Postby regregex » Sat Jul 25, 2009 5:33 pm

I've put an article up on Beebwiki with more details. ...Anyone up for octal density? :lol:

--G

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 Jul 25, 2009 7:33 pm

That's a great write up on the Wiki, nice one.

regregex wrote:Anyone up for octal density?


Ohh...ED, you just want to make that lil' 6502A sweat eh? :lol:

Mark.
Last edited by retroclinic on Wed Jul 29, 2009 3:17 pm, edited 1 time in total.

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

Re: high density disks

Postby MartinB » Wed Jul 29, 2009 3:00 pm

Brilliant article Greg, somehow makes it all worthwhile... =D>

(And I will be back on the case as soon as I can :wink:)

Martin

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

Re: high density disks

Postby regregex » Thu Jul 30, 2009 1:19 pm

MartinB wrote:Brilliant article Greg, somehow makes it all worthwhile... =D>
Thanks, now I don't feel so bad about losing sleep over it (yes, when there's a bug – I burned the big eprom this week then had to re-burn it twice due to some real show-stoppers.) :)

Also I read the first 1.6 MB ADFS disc on Tuesday, transferred an .adf of Stunt Racer 2000 to the PC. Sorry Mark! I'll leave it to you though to do the first *CAT :P

– Greg

User avatar
mga1103
Posts: 184
Joined: Mon Jan 24, 2011 4:00 pm
Location: Galway, Ireland

Re: high density disks

Postby mga1103 » Sun Mar 06, 2011 3:05 pm

Well, this thread has been quiet for a while....well, wakey, wakey :wink:

When I first read this thread, I was intrigued (and somewhat blown-away) by MartinB’s excellent research and explanations of getting a 3.5” drive to work properly with HD disks (and I’m still in awe at how clever this mod actually is!).

Given that HD disks are more readily available than DD disks, I was determined to give this mod a go and hoped to give my beeb HD-disk compatibility! So, ordered a few 151’s and set the stage. Little did I realise the journey ahead of me at the time (not due to the mod itself, but due to the floppy drive I was using! More on that later).

(WARNING: This is a bit wordy, but I’m including details on the issues I encountered in the off-chance they might help anyone attempting this mod. This is all old news to MartinB, who’s way too familiar with the issues I had! :roll: ).

My 3.5” is an Alps DF-354 ripped from an old PC (a HP Vectra VL420). Also in my configuration is a 5.25” drive operating as Drive 0. The 3.5” connector had pins 10 & 12 flipped so figured I was good to go.

Incidentally, during various email exchanges with MartinB, his mod became unofficially christened as MBM (Martin B’s Mod, or Martin’s Brilliant Mod – take your pick. Regardless, we subsequentially referred to it as MBM. It needed an acronym and MBM sounds better than “the mod” :) ).

So I built the MBM (!) and fitted it, with one small change from Martin’s published schematic – as I wasn’t fitting a switch to my 5.25” I tied IC1 Pin 10 to 0v, via a 10K resistor. I had also made the change to the 3.5” drive to signal “HD mode” on pin 4 of its connector (0v with a DD disk inserted, otherwise +5v. In my case the DD disk was a HD disk with tape over its density-select hole).

The other slight variation in my setup is that my 1770 is Mark’s (RetroClinic) interface! Thanks to Mark for providing his schematic and MartinB’s input on figuring out where to make the clock track cut.


Thinking I had everything as it should be, I started to play with the MBM. It wasn’t working, so time to start probing. (My new scope had arrived a few days earlier – perfect timing, so the ideal opportunity presented itself to plug it in an give it it’s first mini-workout!).

I could see that IC2 Pin 5 was sending the 16Mhz signal to IC1 on Load Head, otherwise sending 8Mhz. All fine on IC2. However, IC1 wasn’t switching 16Mhz out to Pin 5 (1770 clock output). Therefore, time to check the input controls lines on IC1 (Pins 11, 10 & 9).

S10 East was correctly showing +5v with a HD disk inserted, thus picking up the “HD mode” signal from the drive and 0v on DD mode. I had already verified this before connecting the MBM. However, now with the MBM connected it was being pulled low to 0v, therefore the conditions for switching to 16Mhz didn’t exist. Disconnected MBM and the 5v was back. Hmmm… #-o

Taking the 10K resistor out of the equation solved this. So, was there something in the 3.5” density-select switch unable to tolerate any additional load, thus pulling it low? I still don’t fully understand why this was happening but at least now I had a steady 5v in HD mode (& 0v on DD mode) with the MBM connected. Happy days! :D

Still didn’t have a working MBM! Onto the next input control line (Pin 10). As this was tied to 0v, this wasn’t a problem (remember, I wasn’t using a switch on my 5.25” so having this continuously in DD mode was fine).

The non-auto-switching issue had to be related to the last input line (Pin 9, Drive Select 0). This should have been showing +5v on drive 0 being accessed and 0v on drive 1 being accessed. Not so! It wasn’t showing any voltage on the meter and the scope showed frequencies hopping “all over the place”. Double-checked this was indeed connected to IC79 Pin 6 (and it was).

Hmmm…(again)… :?

At this point it started to emerge that I had a drive identity crisis! Drive 0 was fine (*.0) but drive 1 only illuminated with *.3. Not having used the 3.5” previously on the beeb (no DD disks and no HD capability!) I never verified my 3.5” was working correctly as drive 1 before starting this (doh!). Shame on me!
:oops:

With the 3.5” taken apart again, I could see it had some pads labelled DS1 & DS0. The DS1 pads were linked to Pin 12 on the drives connector and the DS0 pads (not linked in the pic below) were connected to Pin 10. My expectation here was that only Pin 12 would be used in the drives ID selection. In other words, with the DS1 pads linked (as in the pic) I expected the drive to operate as drive 1 and with the DS0 pads linked it would operate as drive 0.


Why would a drive use Pin 10 to signal its ID? Afterall, Pin 10 was “Motor Enable” in the beeb and I verified this by making the DS0 pad link and hooking it up to the beeb. Sure enough, the drives motor remained illuminated!

Hmmm…(yet again!)… :?

As I pondered over the Pin 10 & Pin 12 thing, it suddenly reminded me of my ribbon cable and the fact it had Pins 10 & 12 flipped! The penny dropped! :idea: What if I used a cable with straight-through connections (no twist)? This would reverse the symptoms I was seeing above, namely, with the DS0 pads linked (i.e. Drive 0) I should be getting Drive Select 0 output on Pin 12, which is where I needed it.

So, I engineered (!!) a straight-through connection for the 3.5”, removed the DS1 link and connected the DS0 link. I also changed the jumper on the 5.25” to change its ID to drive 1. (If I was going to have a choice in drive ID’s, then I wanted my 3.5” to be my drive 0 and my 5.25” to be drive 1).

When I hooked it up, both drives were now operating just as I wanted them: 3.5” was drive 0 and the 5.25” was drive 1. Happy days (again!).

Now, back to MBM. With the scope on the 1770 clock speed input, I wasn’t seeing 16Mhz with the 3.5” when access a HD disk, but I was seeing the 16Mhz when accessing the 5.25”. What now?!

But as I had switched my 3.5” drive to be drive 0, I needed to also switch the connections on IC1 Pins 11 & 10, such that my DD/HD signal was now on Pin 10.

With the switch made, I could now see IC1 auto-switching from 8Mhz to 16Mhz when accessing drive 0 (3.5”) with a HD disk present and in 8Mhz mode with a DD (HD disk with the density hole taped over) disk present. It was also correctly operating in 8Mhz mode on drive 1 (5.25).

With the MBM finally working as expected, it was time to try to format a HD disk. It got as far as “…track 00” and hung. This should be working! Auto-switching betweeb 8 & 16Mhz was happening!

I eventually discovered that I needed to issue an *OPT80,1 command to force 80-track mode. I was using Watfords DDFS 1.54T. Why is this needed on the 3.5” when it automatically assumes 80-track mode on the 5.25” ? While it’s no big deal to issue this command before formatting a HD disk, I’d like to understand why it’s required! If anyone can explain this, I'd love hear your thoughts...

Anyways, a long story to get here, but the end result is a good one. I now have HD-capability on my 3.5”. =P~

Mega thanks must go to MartinB who’s knowledge and expertise was fundamental to getting this solution working! =D> =D> =D>
The number of emails back and forth between us could probably fill a few HD disks :lol: .


Regards,
Martin :D :D :D .
Attachments
IC79 Pin 6 and 8.JPG
IC79 Pin 6 & Pin 8 connections.
(108.74 KiB) Downloaded 990 times
MBM.JPG
The MBM in place!
(149.51 KiB) Downloaded 990 times
35 DS Links Highlighted.jpg
DS0 & DS1 Links on 3.5".
(272.32 KiB) Downloaded 990 times
RetroClinic 1770 Highlighted.jpg
RetroClinic's 1770 with new 8/16Mhz Clock input.
(190.07 KiB) Downloaded 990 times

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 » Sun Mar 06, 2011 3:20 pm

=D> Nice work!

I really should have a play with this too - the additional circuitry could be fitted on the board by using a larger PAL. The 16V8 I use (set as a 16R4) is fully utilised, but using a 22V10 could incorporate the extra logic perhaps? May also negate the need for the LS02 I had to put on it as well for the reset.

Something else for the to-do pile!

Mark.
Image

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

Re: high density disks

Postby MartinB » Sun Mar 06, 2011 7:05 pm

Image It is safe to come out...? Has he got it working now...?

Heh heh, yes it was an err..., entertaining exercise :wink:. Every credit to Martin A (mga1103) though - he did a suberb job and is a great student =D>. As he said, it wasn't the MBM itself, just in the end some niggly issues with the drives and their ID configuration.

I am puzzled about the WE 1.54T though. Someone else posted in the PC 3.5" drives thread that they had to do a *OPT80 to get a 35 drive working :-?. You (Martin) said you used *OPT80,1 which is even more confusing since the second parameter is supposed to be the drive number but in the end you had the 35 as Drive 0 and so the *OPT would appear not to affect that drive. Most odd...

Mark, you sometimes supply 1.54T, do you have any idea why it sometimes appears to default to 40T mode and then requires the *OPT? I've looked at the info I've got and I can't make sense of it.

(Personally, unless the DDFS features are specifically required, I always favour Acorn DFS 2.26 for maximum compatibility.)

I should point out again that HD floppies cannot be used with DDFS or ADFS as they will result in quad density access and that's just not possible on a Beeb. It's not an issue, you can still use the MBM but you just have to always use DD floppies with DDFS's and ADFS. I did actually devise an extension to the mod to address these densities but never published it. Maybe I'll get round to it one day if there were sufficient interest.

Mark - Nice idea to roll up the HD facility in a 177x module. Not sure if you can get/create all the signals required without still using flying leads but well worth considering. You certainly have my blessing if you want to look at an upgraded version of your module.

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

Re: high density disks

Postby regregex » Sun Mar 06, 2011 11:03 pm

Great hack Martin A! Welcome to the club :)

Martin A & Martin B, I was musing that the need for *OPT 80 (in this and the other case) was because track auto detection may just be defaulting to 40 tracks when it doesn't recognise the disc format. Thats the way it's done in <insert blatant EDOSpat plug here>. But evidently Watford DFS doesn't autodetect, so like how magnets work. "I can't explain it".

--G

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

Re: high density disks

Postby MartinB » Sun Mar 06, 2011 11:53 pm

As you know Greg, I'm familiar with EDOSPAT and I thought perhaps WE 1.54T was following suit. I said in an email to Martin A -"I think 1.54T has some sort of 40/80/SD/DD automation..." but like you (Greg), on further reading I'm just not sure now. I think it is trying to do something clever but if it means you're forever having to issue a *OPT80,n then clever it isn't [-X

I'll talk Martin A into an Acorn DFS 2.26 rom and then he will undoubtedly benefit from a more enjoyable HD customer experience. (Hey, if you can't beat cold-callers.... :wink:)

(Incidentally, magnets don't really work, it's just a trick...)


Return to “hardware”

Who is online

Users browsing this forum: No registered users and 8 guests