ADFS 1.30 disassembly

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Sat May 20, 2017 2:20 pm

Hi Jonathan,

jgharston wrote:I've tracked down what needed to be done - and it could have been done without removing the floppy drivers, just adding a couple of JSR-to-RTS calls. Anyway, ADFS 1.x3 revision 23 works with the 32016. I've also corrected the Unsupported OSFILE code to use non-65c12 opcodes for the BBC.

It's definitely still broken on the Model B (not tested on the Master).

I've narrowed it down to this change (adding JSR SetGeometry) introduced in 1.21):

Code: Select all

 1960[OPT FNorg(LAADD,LAB03)
 1970JSR SetGeometry            :\ Select sector for BGET/BPUT
 1980JSR WaitNotBusy:LDA #1:STA &FC42:CLC    :\ one sector


If I NOP that JSR SetGeometry out in the binary of v1.23:

Code: Select all

< 002ac0 ca 10 e5 4c 76 a9 48 20 05 83 20 d5 81 20 0f 83
---
> 002ac0 ca 10 e5 4c 76 a9 48 20 05 83 ea ea ea 20 0f 83

Panos will boot correctly on the Model B.

Dave

User avatar
jgharston
Posts: 2660
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: ADFS 1.30 disassembly

Postby jgharston » Sun May 21, 2017 1:55 pm

hoglet wrote:If I NOP that JSR SetGeometry out in the binary of v1.23:

Code: Select all

< 002ac0 ca 10 e5 4c 76 a9 48 20 05 83 20 d5 81 20 0f 83
---
> 002ac0 ca 10 e5 4c 76 a9 48 20 05 83 ea ea ea 20 0f 83

Panos will boot correctly on the Model B.
Dave

I've NOP'd it out and it works on the Master (code here).

I also managed to squeeeeeze one byte out of the *Help code to display the revision number in the *Help string, so it now displays eg Acorn ADFS 1.33r23 so the user doesn't have to examine the ROM image to find the revision number in the final byte.

I think I put in that call to SetGeometry as a belt-and-braces check. All my examination of the code told me that the disk geometry would have always have already been set before a BGET or BPUT is used, but I put it in as a preventative against the user (or a rougue program) changing the disk geometry between BGET/BPUT calls.

I'm now very tempted to dismantle my 32016 CoPro setup and plug my PiCoPro in instead.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Sun May 21, 2017 2:16 pm

jgharston wrote:I also managed to squeeeeeze one byte out of the *Help code to display the revision number in the *Help string, so it now displays eg Acorn ADFS 1.33r23 so the user doesn't have to examine the ROM image to find the revision number in the final byte.

Great, I'll merge that into my build as well.

Did you seem my earlier question about the RamFS specific addition? Can you explain what it does?

Code: Select all

IF PATCH_DATACENTRE
        BNE     LBFAE
.LBF6A
.LBF6C
        LDX     L00B0
        LDY     L00B1
        LDA     #$76
        JSR     LFFF1
        JMP     LBFAE
        PAD00   14
ELSE

jgharston wrote:I'm now very tempted to dismantle my 32016 CoPro setup and plug my PiCoPro in instead.

Go for it!

There is also a release candidate of the soon-to-be-released Cobra release available:
https://github.com/hoglet67/PiTubeDirect/releases

Amongst other things, this release includes a "debug" kernel that is slightly slower, but include integrated debugger support for most Co Pros (modelled on the debugger in B-Em). It supports break points, watch points, dumping memory, single stepping, disassembling, etc.

To use it you just need a Pi Serial to USB cable. This is the one I use:
https://thepihut.com/collections/cables ... rial-cable
(Just don't connect the red +3.3V wire)

If you develop any second processor software (or new client ROMs for that matter) this will be very useful.

Dave

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Sun May 21, 2017 4:13 pm

I've merged the latest v1.23 IDE patch and uploaded a new binary release of all builds:
https://github.com/hoglet67/ADFS130/releases

I've also added a better README describing the different builds included:
https://github.com/hoglet67/ADFS130/blo ... /README.md

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Sun May 21, 2017 7:37 pm

I've just been looking at a disassembly of the original ADFS 1.00, to see if there is any Elk specific stuff we are missing when using a Model B version of ADFS.

What I've found is that the floppy driver NMI setup code includes some Elk specific stuff:

Code: Select all

.LBB20
        PHP
        PLA
        STA     L0D16
        SEI
        LDA     L00CE
        STA     L0D13
        LDA     L00CF
        STA     L0D14
        LDX     #$01
        LDA     #$73
        JSR     LFFF4

        LDX     #$00
        LDY     #$FF
        LDA     #$F2
        JSR     LFFF4

        TXA
        STA     L0D12
        AND     #$F9
        TAX
        AND     #$20
        BNE     LBB4F

        TXA
        ORA     #$30
        TAX
.LBB4F
        STX     LFE07
        RTS

.LBB53
        LDA     L0D12
        STA     LFE07
        LDX     #$00
        LDA     #$73
        JSR     LFFF4

        LDA     L0D13
        STA     L00CE
        LDA     L0D14
        STA     L00CF
        LDA     L0D16
        PHA
        PLP
        RTS

This looks like it is testing to see if the ULA is running in Mode 0..3, and if so switching to Mode 6.

As I don't have this code in ELK100 and ELK103 (both derived from ADFS 1.30) it's fair to assume the floppy driver won't work in Mode 0..3.

I don't have a Plus 3, so I can't verify this myself.

Ho hum....

Dave

User avatar
richardtoohey
Posts: 3361
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: ADFS 1.30 disassembly

Postby richardtoohey » Mon May 22, 2017 4:05 am

hoglet wrote:This looks like it is testing to see if the ULA is running in Mode 0..3, and if so switching to Mode 6.
Just curious, is that related to this?

https://en.wikipedia.org/wiki/Acorn_Ele ... DFS_quirks

... *COMPACT command used screen memory (by default) as working space during the operation, and the software-implemented blinking cursor corrupted that memory space. An alternative would be to give arguments to make it use non-screen memory for workspace, for example *COMPACT 40 20 in MODE 6.

Doesn't sound like that was fixed in ADFS 1.00, though? :-k

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Mon May 22, 2017 6:28 am

richardtoohey wrote:
hoglet wrote:This looks like it is testing to see if the ULA is running in Mode 0..3, and if so switching to Mode 6.
Just curious, is that related to this?

https://en.wikipedia.org/wiki/Acorn_Ele ... DFS_quirks

... *COMPACT command used screen memory (by default) as working space during the operation, and the software-implemented blinking cursor corrupted that memory space. An alternative would be to give arguments to make it use non-screen memory for workspace, for example *COMPACT 40 20 in MODE 6.

The *COMPACT issue is more about screen memory usage (and making the memory used by *COMPACT doesn't get accidentally corrupted).

Changing modes (briefly) during data transfers is (I think) to ensure the system is fast enough to handle the data read from/written to the floppy. This generates an NMI for each byte transferred, and this must be serviced in time for the next byte (nominally 16us, and no hardware buffering).

Lots of gory details on Beeb Wiki:
http://beebwiki.mdfs.net/High_density_f ... isc_access

Now, what I'm slightly confused about is that I though the ULA did this automatically (that's why it has a NMI input).

Here's what the Electron AUG has to say about bit 7 of &FE05 (the NMI bit):
Bit 7 is associated with the non-maskable interrupt. This type of interrupt is generated by very high priority devices like discs. An NMI automatically gives the 6502 precedence over the ULA, even if it is in the middle of displaying a screen. White snow may therefore occur on the screen when discs are being accessed. Once the 6502 has dealt with the source of interrupt, it should clear it by writing a ‘1’ to bit 7. This gives the screen memory back to the ULA.

But I don't see any evidence of ADFS 1.00 writing to this bit.

Dave

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

Re: ADFS 1.30 disassembly

Postby Elk Towers » Mon May 22, 2017 6:54 am

This may clarify things

this is taken from the manual for pres` ADI

For the ELECTRON

The ADI ROM must be fitted to the Plus1 via a suitable ROM carrier board, such as the ROM adaptor boards supplied by ACP. For ADI to operate correctly in the Acorn Plus3 a small link (LK1)must be joined inside the unit. This may invalidate the warranty on the Plus3. If necessary, see your dealer.

Checking LK1

The link in the Plus3 may already be joined. This can be checked by performing the following task. First fit the ROM cartridge into the Plus1 as described below. Turn on the computer and type *ADI. Insert a formatted disc into the drive and select the command 'Edit a Sector', by pressing 'E'. At this point, if a 'snowstorm' effect appears on the screen then the link HAS been joined and nothing further need be done. If the 'snowstorm' effect does not appear then the link HAS NOT been joined. The 'snowstorm' effect is the result of temporarily turning off the screen display to provide the extra processing time while accessing the disc.

Joining LK1

After turning off the power, isolate the Plus3 by disconnecting the Plus1 & Electron. Remove the top cover of the Plus3 by unscrewing the 9 fixing screws on the bottom of the Plus3.

Locate LK1 situated to the top left of the disc drive between IC6 and IC10. If the link is not joined, make the connection with a small piece of wire, ideally soldering it to the board. Replace the cover and reconnect the Electron and Plus1. Fit the ROM cartridge to the Plus1 as described below. To check that the link has been properly joined, follow the procedure shown above (Checking LK1)
Nick

User avatar
1024MAK
Posts: 6679
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: ADFS 1.30 disassembly

Postby 1024MAK » Mon May 22, 2017 7:48 am

So from that, I assume that LK1 connects to the NMI line. And that Acorn did not actually use the NMI line ??? Strange...
<wanders off to power up my PC to see if I have a Plus 3 schematic...>

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

dp11
Posts: 674
Joined: Sun Aug 12, 2012 8:47 pm

Re: ADFS 1.30 disassembly

Postby dp11 » Mon May 22, 2017 8:44 am

Well done everyone for getting this going.

I wonder instead of slowing down tube transfers for everyone, is there a chance that the 32016 code could be fixed ?

With PiTubedirect except for the normal speed 6502 I think the data transfer rate could be uped by say x4

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Mon May 22, 2017 8:47 am

Elk Towers wrote:This may clarify things

Actually, quite the opposite!

Looking at the schematic is seems without LK-1 being made, the WD1770 on the AP3 cannot create an NMI request.

As the default setting for this like is not-present, this appears to suggest NMIs are not used.

Yet the ADFS 1.00 code does look like it's setting up NMIs.

Can anyone explain this apparent contradiction?

User avatar
danielj
Posts: 5139
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester

Re: ADFS 1.30 disassembly

Postby danielj » Mon May 22, 2017 9:04 am

Page 14/15:
http://chrisacorns.computinghistory.org ... lus3UG.pdf

I need to check the internals of my plus 3 to see how it's set up... (all those blasted screws...) It definitely always used to do the flicker thing in those screen modes.

d.

User avatar
CMcDougall
Posts: 5540
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: ADFS 1.30 disassembly

Postby CMcDougall » Mon May 22, 2017 10:44 am

Screws?? What are they :? :lol:
Attachments
217267_5731507729_5184_n.jpeg
207516_5731502729_4925_n.jpeg
216507_5731512729_5440_n.jpeg
ImageImageImage

User avatar
1024MAK
Posts: 6679
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: ADFS 1.30 disassembly

Postby 1024MAK » Mon May 22, 2017 10:49 am

hoglet wrote:Looking at the schematic is seems without LK-1 being made, the WD1770 on the AP3 cannot create an NMI request.

There's a slightly better schematic in the zip file in this post :wink:

It also appears that the NMI comes from a latch/register (which gets it's inputs from the data bus). And that the INTRQ pin of the WD1770 is not connected / not used.
So that even when LK1 for the NMI is connected, NMI is software controlled...

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Mon May 22, 2017 11:19 am

I've been looking at the disassembly a bit more, and I'm now pretty sure Acorn ADFS 1.00 doesn't use NMI at all. i.e. It's basically all done with polling.

And to maximise the speed of the system, if in Mode 0 .. 3 it will temporarily switch to Mode 6.

As all of the transfer code is actually in ROM (which will run at 2MHz) it will be significantly faster (that a NMI handler at &0D00).

This is one of the data transfer loops (the write one):

Code: Select all

.LBA38
        LDA     LFCC4
        ROR     A
        BCC     LBA4A

        ROR     A
        BCC     LBA38

        STX     LFCC7
        INY
        BEQ     LBA38

        JMP     (L0D10)

and here's the other (the read one):

Code: Select all

.LBA4A
        ASL     A
        AND     L0D15
        BEQ     LBA95

        BNE     LBA88

.LBA52
        LDA     LFCC4
        ROR     A
        BCC     LBA4A

        ROR     A
        BCC     LBA52

        LDA     LFCC7
        JMP     (L0D10)

The vector at L0D10 points back into the ROM to one of 4 places, depending on read/write and tube/memory.

Code: Select all

;; tube -> floppy
.LBA61
        LDA     LFCE5
        TAX
        JMP     LBA38
       
;; floppy -> tube
.LBA68
        STA     LFCE5
        JMP     LBA52

;; floppy -> memory
.LBA6E
        STA     (L00CE),Y
        INY
        JMP     LBA52

;; memory -> floppy
.LBA74
        LDA     (L00CE),Y
        TAX
        JMP     LBA38

What I might try to do is clean up the ADFS 1.00 disassembly, and then try to extract the floppy driver code and see if it can be added into the ADFS 1.30 tree.

Where I'm trying to get to is:
- an ADFS 1.30 based build (as it's much less buggy than ADFS 1.00)
- that runs on the Elk
- that allows the SCSI drivers to be replaces by IDE (or MMC) drivers
- and allows floppies to be used as well

This may take a while!

Dave

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Mon May 22, 2017 3:15 pm

Here's a clean(ish) disassembly of ADFS 1.00:
ADFS100.zip
(47.83 KiB) Downloaded 10 times

I like the error message: Won't

It looks like the floppy driver starts at &BA00 with a Jump table into the driver entry points.

It's exactly the same structure (and address) in ADFS 1.30.

Dave

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Mon May 22, 2017 4:54 pm

Right, is anyone with an Elk Plus 3 feeling brave?

I've extracted the Elk floppy drivers from Acorn ADFS 1.00 and added them to the new build tree.

They are included in builds ELK100 (SCSI/Floppy) and ELK103(IDE/Floppy).

This is completely untested as I don't have a Plus Three.

Anyone care to give it a spin?
https://github.com/hoglet67/ADFS130/rel ... elease_003

I'm particularly interested if the floppy support in either of these two builds is showing any signs of life.

For reference, the Elk floppy driver source is here:
https://github.com/hoglet67/ADFS130/blo ... ectron.asm

Dave

User avatar
1024MAK
Posts: 6679
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: ADFS 1.30 disassembly

Postby 1024MAK » Mon May 22, 2017 6:27 pm

Good work getting this far =D> =D> =D>

I'd love to test it Dave, but I don't have a working Plus 3...

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Mon May 22, 2017 6:45 pm

1024MAK wrote:I'd love to test it Dave, but I don't have a working Plus 3...

I'm hoping Colin will volunteer, as he is such a fan of ADFS :lol:

User avatar
daveejhitchins
Posts: 3629
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: ADFS 1.30 disassembly

Postby daveejhitchins » Mon May 22, 2017 10:38 pm

I'll see if can dig a Plus 3 out tomorrow . . .

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
1024MAK
Posts: 6679
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: ADFS 1.30 disassembly

Postby 1024MAK » Tue May 23, 2017 2:39 pm

daveejhitchins wrote:I'll see if can dig a Plus 3 out tomorrow . . .

Dave H :D

Careful, Colin may have other ideas on what to use the shovel for... :lol:

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
fordp
Posts: 873
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: ADFS 1.30 disassembly

Postby fordp » Tue May 23, 2017 2:59 pm

FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ADFS 1.30 disassembly

Postby Arcadian » Tue May 23, 2017 3:18 pm

No, that's a Cumana interface*, which uses its own proprietary DFS.

* = it's possible that the Eprom could have been switched with the SEDFS that was available from Slogger, which would in turn convert the interface into an Acorn-compatible DFS.
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug Leicestershire (17-19 November 2017)

User avatar
daveejhitchins
Posts: 3629
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: ADFS 1.30 disassembly

Postby daveejhitchins » Tue May 23, 2017 5:22 pm

I think that's the Cumana interface. The Gold fingers don't look good and there's a battery! I have one belonging to Arcadian, waiting for repair (battery damage :?

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
jgharston
Posts: 2660
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: ADFS 1.30 disassembly

Postby jgharston » Wed May 24, 2017 9:53 am

hoglet wrote:Anyone care to give it a spin?
https://github.com/hoglet67/ADFS130/rel ... elease_003

I'll have a go when I'm back in Sheffield and swap the Compact for the Electron.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Wed May 24, 2017 11:00 am

jgharston wrote:
hoglet wrote:Anyone care to give it a spin?
https://github.com/hoglet67/ADFS130/rel ... elease_003

I'll have a go when I'm back in Sheffield and swap the Compact for the Electron.

Cheers.

BTW, I was looking at the ADFS 1.03 on your site:
http://mdfs.net/Info/Comp/BBC/IDE/ADFS/ADFS103

What's the history of this?

The reason I ask is that it seems to have a Beeb-like floppy driver that uses NMI.

I'm curious if this actually ever worked on the Electron.

Dave

User avatar
jgharston
Posts: 2660
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: ADFS 1.30 disassembly

Postby jgharston » Wed May 24, 2017 2:32 pm

[quote="hoglet"BTW, I was looking at the ADFS 1.03 on your site:
http://mdfs.net/Info/Comp/BBC/IDE/ADFS/ADFS103
What's the history of this?
The reason I ask is that it seems to have a Beeb-like floppy driver that uses NMI.
I'm curious if this actually ever worked on the Electron.
Dave[/quote]
Not sure, it was in my ROMS directory tree. I must have got it from somewhere, I'll see if I can track it down when I get home.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
simoni
Posts: 314
Joined: Wed May 25, 2016 6:18 pm

Re: ADFS 1.30 disassembly

Postby simoni » Wed Aug 02, 2017 10:18 am

Just wanted to put an update here to show some additional testing I did on the backported Elk version of ADFS 1.30 (SCSI version). Using an prototype AP5 (kindly supplied by Mr Hitchins) and the new ROM build from Dave (Hoglet) I have connected a BeebSCSI board to the (new) AP5 and performed some basic testing of the ROM image.

The ADFS version works perfectly both reading and writing. *MOUNT and *BYE function, as do the vendor specific SCSI commands provided by the BeebSCSI utility ROM (these perform status checking and 'jukebox' functionality). I also used the SCSI MODESENSE command to read back the drive geometry.

Unlike the original ADFS for the Elk, the new version also worked flawlessly with SuperForm and I was able to correctly format a SCSI LUN. The original ADFS fails due to the lack of *FADFS implementation (although you can get around this by simply deleting line 270 of superform before running it).

Since BeebSCSI is a SCSI-1 standard system, this should also mean that the new ADFS ROM is fully compatible with the original Acorn Winchesters too.

Interestingly the original ADFS for the Elk managed around 50Kbytes/sec read performance (using a simple *LOAD test of a 16K file). The new ROM bumps this up to about 57Kbytes/sec; not an insignificant improvement :)

User avatar
hoglet
Posts: 6379
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: ADFS 1.30 disassembly

Postby hoglet » Wed Aug 02, 2017 10:22 am

Thanks for the update, Simon.

I must get hold of a BeebSCSI at some point.

Now, just need a kind volunteer Plus3 owner to check the floppy driver part still works. Any takers?

User avatar
simoni
Posts: 314
Joined: Wed May 25, 2016 6:18 pm

Re: ADFS 1.30 disassembly

Postby simoni » Wed Aug 02, 2017 10:50 am

I must get hold of a BeebSCSI at some point.


Considering the amount of benefit I've had from your work on ADFS and the PiTubeDirect; I will make and send one to you gratis. Just PM me your address and contact details. I have a bunch of parts that should be delivered tomorrow, so I can probably make some over the weekend.


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 6 guests