Spoofing Drive number on RiscOS

Arc/RPCs, peripherals, RISCOS operating system & ARM kit eg GP2x, BeagleBoard
User avatar
danielj
Posts: 5977
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Spoofing Drive number on RiscOS

Postby danielj » Wed Mar 28, 2018 4:40 am

I make my own floppy leads (straight through) so that's not a worry :)

sirbod
Posts: 819
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: Spoofing Drive number on RiscOS

Postby sirbod » Wed Mar 28, 2018 9:00 am

I've spent an hour this morning seeing if the method ADFFS uses can be used to swap the floppy drives around, with a proof of concept Module.

First the bad news...it's not possible to swap drive 0 and drive 1 due to quirk of ADFS. From testing, it appears the drive number is sometimes fed back from MiscOp to DiscOp, meaning DiscOp sometimes receives a drive number that's already swapped. It looks like this occurs when it's reading the catalogue, but may occur at other times. The upshot is that swapping the drives around in DiscOp/MiscOp causes thorough confusion as to which drive is being accessed.

Now the good news...It is possible to redirect drive 0 to drive 1. Attached below is the proof of concept sourcecode and Module, *RMLoad FloppySwap and issue *SwapFloppy when you want drive 0 to redirect to drive 1, issue *SwapFloppy again to turn off the redirection.

I've tested under Arculator, but not physical, so let me know if it actually works with your Gotek.

Code: Select all

REM Floppy Swap
ON ERROR REPORT:PRINT " at line ";ERL:END

DIM code% 1024
Vector_SWI = 2
Module_ReInit = 3

FOR A%=4 TO 6 STEP 2
O%=code%:P%=0
[OPT A%
 DCD 0                  ;start
 DCD Entry_init         ;initialisation
 DCD Entry_kill         ;finalisation
 DCD 0                  ;service call handler
 DCD Title              ;title
 DCD Help               ;help
 DCD Commands           ;command table

 .Title DCB "FloppySwap": DCB 0
 .Help  DCB "Floppy Swap"+CHR$(9)+"2.00 (28 Mar 2018)":DCB 0
 .Help_SwapFloppy DCB "*SwapFloppy redirects drive 0 to 1":DCB 0
 .Syntax_SwapFloppy DCB "Syntax: *SwapFloppy":DCB 0
 .Error_Vector_Claim DCD 0:DCB "Failed to claim the SWI vector":DCB 0
 .Error_Vector_Release DCD 0:DCB "Failed to release the SWI vector, please reboot your machine":DCB 0
 .Commands DCB "SwapFloppy":DCB 0
 ALIGN
 DCD Entry_SwapFloppy
 DCD 0
 DCD Syntax_SwapFloppy
 DCD Help_SwapFloppy

 DCD 0


.Entry_init
 STR     R14, [R13, #-4]!
 MOV     R0, #Vector_SWI << 2           ;hardware vector address
 LDR     R1, [R0]
 MOV     R2, R1, LSR #24
 TEQ     R2, #&EA                       ;does &8 contain a B xxxx command
 BNE     swi_claim_failed
 MOV     R1, R1, LSL #2                 ;YES, shift address up
 ADD     R1, R1, #16                    ;..correct the address
 BIC     R1, R1, #%11111100 << 24       ;..clear the ARM command bits
 STR     R1, OS_SWI_Vector              ;..save the original vector
 ADR     R1, vectorHandler - 16         ;..our vector handler, -16 to correct
 MOV     R1, R1, LSR #2                 ;..shift address down
 ORR     R1, R1, #&EA000000             ;..set the ARM command
 STR     R1, [R0]                       ;..and replace the vector

 MOV     R0, #Module_ReInit
 ADR     R1, ADFS_Module
 SWI     "XOS_Module"                   ;Reinit ADFS to get it's DiscOp / MiscOp
 LDR     PC, [R13], #4

 .swi_claim_failed
 MOV     R0, #1<<31
 ADDS    R0, R0, R0                     ;set V
 ADR     R0, Error_Vector_Claim         ;..and exit with an error
 LDR     PC, [R13], #4


.Entry_kill
 STR     R14, [R13, #-4]!
 MOV     R0, #Vector_SWI << 2           ;SWI hardware vector address
 ADR     R1, vectorHandler              ;..get our handler
 SUB     R1, R1, #16                    ;..correct its address
 MOV     R1, R1, LSR #2                 ;..shift address down
 ORR     R1, R1, #&EA000000             ;..set the ARM command
 LDR     R2, [R0]
 TEQ     R1, R2                         ;check we still own the vector
 BNE     _failed                        ;NO, report an error
 LDR     R1, OS_SWI_Vector              ;YES, replace with original vector
 SUB     R1, R1, #16                    ;..correct the address
 MOV     R1, R1, LSR #2                 ;..shift address down
 ORR     R1, R1, #&EA000000             ;..set the ARM command
 STR     R1, [R0]                       ;..and replace the vector

 MOV     R0, #Module_ReInit
 ADR     R1, ADFS_Module
 SWI     "XOS_Module"                   ;Reinit ADFS to get it's DiscOp / MiscOp
 LDR     PC, [R13], #4

 ._failed
 MOV     R0, #1<<31
 ADDS    R0, R0, R0                     ;set V
 ADR     R0, Error_Vector_Release       ;can't release vector
 LDR     PC, [R13], #4


 .FloppiesSwapped DCD 0
 .OS_SWI_Vector   DCD 0
.ADFS_FS_Create_Block
 DCD 0                                  ;Filing system number etc
 DCD ADFS_Module                        ;Filing system title
 DCD ADFS_boot                          ;Boot text
 DCD Entry_DiscOp                       ;DiscOp entry
 DCD Entry_MiscOp                       ;Misc entry

 .ADFS_boot     DCB "Acorn "
 .ADFS_Module   DCB "ADFS" : DCB 0
                ALIGN
 .ADFS_DiscOp   DCD 0                   ;ADFS entry points
 .ADFS_MiscOp   DCD 0




.Entry_SwapFloppy
 LDR     R0, FloppiesSwapped
 EOR     R0, R0, #1
 STR     R0, FloppiesSwapped
 MOV     PC, R14


.vectorHandler
 STMFD   R13!, {R12, R14}
 BIC     R14, R14, #&FC000003           ;clear PC flags on 26bit OS

 LDRB    R12, [R14, #-4]                ;get instruction bits 0-7
 TEQ     R12, #&41                      ;FileCore_Create possibly?
 LDMNEFD R13!, {R12, R14}               ;NO
 LDRNE   PC, OS_SWI_Vector              ; |+ pass to OS

 LDR     R14, [R14, #-4]                ;get instruction
 BIC     R14, R14, #1 << 17             ;clear X bit
 MOV     R14, R14, LSL #12              ;shift SWI# to top bits

 MOV     R12, #&40000 << 12
 ORR     R12, R12, #&540 << 12          ;R12=&40541 << 12 "FileCore_Create"
 ORR     R12, R12, #1 << 12

 TEQ     R14, R12                       ;FileCore_Create?
 BEQ     FileCore_Create                    ;YES

.pass_to_OS
 LDMFD   R13!, {R12, R14}
 LDR     PC, OS_SWI_Vector


.FileCore_Create
 LDRB    R12, [R0, #3]                  ;get the file system number
 TEQ     R12, #8                        ;is it ADFS?
 BNE     pass_to_OS                     ;NO, forward to OS

 LDR     R12, [R0]                      ;1st word of ADFS' FileCore block
 STR     R12, ADFS_FS_Create_Block      ;our FileCore create block

 LDR     R12, [R0, #12]                 ;load ADFS' DiscOp relative address
 ADD     R12, R12, R1                   ;ADFS' DiscOp physical address
 STR     R12, ADFS_DiscOp
 LDR     R12, [R0, #16]                 ;load ADFS' MiscOp relative address
 ADD     R12, R12, R1                   ;ADFS' MiscOp physical address
 STR     R12, ADFS_MiscOp

 ADR     R0, ADFS_FS_Create_Block       ;redirect FileCore to our FS block
 ADR     R1, 0                          ;redirect FileCore to our module
 B       pass_to_OS


.Entry_DiscOp
 STR     R12, [R13, #-4]!

 AND     R12, R1, #%1111                ;check for commands to swap
 TEQ     R12, #7
 TEQNE   R12, #8
 BEQ     pass_discop_on
 CMP     R12, #9
 BHI     pass_discop_on

 ANDS    R12, R2, #%111 << 29           ;drive 0?
 LDREQ   R12, FloppiesSwapped
 ORREQ   R2, R2, R12, LSL #29           ;YES, swap

 .pass_discop_on
 LDR     R12, [R13], #4
 LDR     PC, ADFS_DiscOp


.Entry_MiscOp
 STR     R12, [R13, #-4]!
 LDR     R12, FloppiesSwapped
 TEQ     R1, #0                         ;drive 0
 ORREQ   R1, R1, R12                    ;swap
 LDR     R12, [R13], #4
 LDR     PC, ADFS_MiscOp

]:NEXT

OSCLI "SAVE FloppySwap "+STR$~code%+" "+STR$~O%
OSCLI "SetType FloppySwap Module"
Attachments
FloppySwap.zip
(664 Bytes) Downloaded 7 times

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

Re: Spoofing Drive number on RiscOS

Postby danielj » Wed Mar 28, 2018 9:04 am

Wow - thanks Jon - I'll give it a go. That would actually solve most issues, as almost nothing assumes you're going to have two drives in the machine.

I'll be demoing the GOTEK at Wakefield this year in the A5000 and on the Master.

d.

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Spoofing Drive number on RiscOS

Postby crj » Wed Mar 28, 2018 12:21 pm

Whatever you do, don't trust it near any important data. I've taken a glance and it's still riddled with serious bugs.

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

Re: Spoofing Drive number on RiscOS

Postby danielj » Wed Mar 28, 2018 12:35 pm

The chances of me keeping important data on an A5000 are approximately zero. :)
(although helpful might be to nicely suggest what they are and how to fix?)

d.

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

Re: Spoofing Drive number on RiscOS

Postby danielj » Wed Mar 28, 2018 6:00 pm

sirbod wrote:I've spent an hour this morning seeing if the method ADFFS uses can be used to swap the floppy drives around, with a proof of concept Module.

First the bad news...it's not possible to swap drive 0 and drive 1 due to quirk of ADFS. From testing, it appears the drive number is sometimes fed back from MiscOp to DiscOp, meaning DiscOp sometimes receives a drive number that's already swapped. It looks like this occurs when it's reading the catalogue, but may occur at other times. The upshot is that swapping the drives around in DiscOp/MiscOp causes thorough confusion as to which drive is being accessed.

Now the good news...It is possible to redirect drive 0 to drive 1. Attached below is the proof of concept sourcecode and Module, *RMLoad FloppySwap and issue *SwapFloppy when you want drive 0 to redirect to drive 1, issue *SwapFloppy again to turn off the redirection.

I've tested under Arculator, but not physical, so let me know if it actually works with your Gotek.


Hi Jon, unfortunately that didn't work - it keeps accessing 0, no matter what. :?

sirbod
Posts: 819
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: Spoofing Drive number on RiscOS

Postby sirbod » Wed Mar 28, 2018 6:48 pm

danielj wrote:unfortunately that didn't work - it keeps accessing 0, no matter what. :?

Assuming you don't have ADFFS loaded (they will conflict), it doesn't sound like it's attempting to do the redirection.

Can I suggest you try it under Arculator just to confirm it works, then perhaps try modifying the DiscOp/MiscOp code to write the drive number to &7000 before it passes to ADFS, so you can see if it's actually doing the redirection.

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

Re: Spoofing Drive number on RiscOS

Postby danielj » Wed Mar 28, 2018 6:51 pm

No, no adffs - just vanilla 3.11 boot. I am using IDEFS for the HDD?

I don't have Arculator working on anything I'm afraid (I'm mostly mac here) :(

I'll try and have a go at the &7000 thing a bit later :)

d.

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Spoofing Drive number on RiscOS

Postby crj » Wed Mar 28, 2018 7:25 pm

danielj wrote:The chances of me keeping important data on an A5000 are approximately zero. :)

Oh, OK. Given you seemed to want both real floppy and emulated, I assumed you had a use for both, which suggested data on physical floppies which matters to you, or matters to the archives, or whatever. Fair enough. (-8

(although helpful might be to nicely suggest what they are and how to fix?)


Well, I remain convinced that the simplest fix is to patch ADFS, or even to write a utility that can mechanically patch any FileCore-based filing system module, rather than to try and do this by intercepting SWIs. That's a way more robust option.

So far as the problem of DiscOp calling MiscOp or vice-versa goes, given FileCore itself is not re-entrant this can easily be solved by keeping a re-entrancy count on the shim: increment the counter each time one of those routines is entered, then decrement it on exit. Only patch drive numbers if the count (before you increment it!) is zero. That would allow the drive numbers to be remapped arbitrarily.

In terms of general robustness of that recent code:
  • Disable interrupts while messing with the hardware vectors (using LDM^ or MOVS to exit will restore the previous enablement state from r14 for free).
  • If the *RMREINIT ADFS fails, the module must tear down its SWI intercept before returning an error, because it's about to get removed from memory!
  • The SWI intercept seems to be ignoring the top 4 bits of the SWI number. (You're not likely to be running RISCiXfs, I grant, but...)
  • FloppySwap is telling FileCore_Create that it, not ADFS, is the module instantiating FileCore. That's a little grim, and makes me very uneasy. After all, there must be some reason FileCore wants to know!
  • MiscOp and DiscOp must preserve the Z,N and C flags
  • Having changed the drive portion of the disc address on the way in to DiscOp, FloppySwap must then change back the drive portion of the disc address it returns. Otherwise, a caller doing arithmetic to tell how many sectors were transferred will get a dangerously nonsensical answer
  • Similarly, MiscOp must preserve R1.
  • It is calamitous to call *SwapFloppy while ADFS is doing anything at all... and, especially with the DIR option, it's likely to have cached parts of the disc almost the moment it's launched. I'm not sure what the best way to proceed there is; maybe dismount the drives that are about to be exchanged?
  • FileCore expects a drive's content will never change under its feet. So making the same drive appear as both drive 0 and drive 1 is a recipe for disaster if writes are performed via either drive number while the other drive number is in use (which, under the Wimp, it likely will be).
  • The FileCore_Create hack should inspect R3 to make sure there actually is a second floppy drive! If there is not, then FileCore will ask ADFS to perform operations on drives ADFS said didn't exist. The best you could hope for would be bizarre errors, but something worse might happen for all I know.

The efficiency of the speed-critical SWI intercept (ignoring for a moment that I feel this is a fundamentally bad approach anyway), can be improved:

Code: Select all

.vectorHandler
 STMFD   R13!, {R14}
 BIC     R14, R14, #&FC000003           ;clear PC flags on 26bit OS
 LDRB    R14, [R14, #-4]                ;get instruction bits 0-7
 TEQ     R14, #&41                      ;FileCore_Create possibly?
 LDMNEFD R13!, {R14}                    ;NO
.patch_1
 BNE dummy                              ; Patch this instruction to be BNE OS_SWI_Vector

 LDMFD   R13, {R14}                     ; NB: no !, so leave R14 on the stack
 BIC     R14, R14, #&FC000003
 LDR     R14, [R14, #-4]                ;get instruction
 BIC     R14, R14, #&FF000000 ;clear instruction bits
 BIC     R14, R14, #1 << 17             ;clear X bit
 EOR     R14, R14, #&40000
 EOR     R14, R14, #&00500
 TEQ     R14,      #&00041
 LDMNEFD R13,{R14}
.patch_2
 BNE dummy                              ; Patch this as well
.dummy

; If we reach this point, the SWI was FileCore_Create

That saves 2S+1N+1I cycles from the fast path, a little less from the slow path.

As broader quality issues, rather than outright bugs:
  • The ON ERROR is pointless
  • Given the assembler supports it, set L%=code%+1024 and add 8 to the OPT values, to get a bounds check
  • Given LDM of a single register is just as quick as LDR, it's more literate and less error-prone to use STMFD sp!,{lr} rather than STR lr, [sp,#-4]! and LDMFD sp!,{PC} rather than LDR PC,[sp],#4
  • Similarly, LDMFD sp!,{lr} : ORRS PC,lr,#V_bit is both quicker and more literate than MOV r0,#1<<31 : ADDS r0,r0,r0 : LDMFD sp!,{PC}
  • The errors should have real error numbers, not 0
  • The module should use workspace, rather than self-modifying. It's more literate and robust, plus it opens the possibility of burning it into ROM and/or creating multiple instances of it.
  • If, during finalisation, deatching from the SWI hardware vector succeeds, but *RMREINIT ADFS fails, the module unnecessarily becomes a zombie. It should record that it has successfully detached itself, and then allow a subsequent finalisation to succeed if the *RMREINIT ADFS succeeds.
  • The module hard-codes "Acorn ADFS" as the boot text and filing system title, rather than going with whatever the real ADFS module passed to FileCore_Create.
  • SYS "OS_File",10,"FloppySwap",&FFA,code%,O% is rather tidier than synthesising a *SAVE command line then doing *SetType
  • It's curiously inconsistent to have a FloppySwap module with a SwapFloppy command.

steve3000
Posts: 1816
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Spoofing Drive number on RiscOS

Postby steve3000 » Thu Mar 29, 2018 10:21 pm

Thought about this for a couple of hours tonight and I now have a 100% robust software solution, tried and tested on my dual drive A5000.

Daniel - which drive connectors did you plug your floppy and Gotek into on the A5000 PCB? I'd guess at PL10 for the floppy and PL11 for the Gotek? Or did you use a split cable, so both plug into PL10?

...then I'll post up what you need to do, as it only takes a couple of minutes :)

User avatar
IanS
Posts: 565
Joined: Mon Aug 31, 2009 6:02 pm
Contact:

Re: Spoofing Drive number on RiscOS

Postby IanS » Thu Mar 29, 2018 10:29 pm

steve3000 wrote:Thought about this for a couple of hours tonight and I now have a 100% robust software solution, tried and tested on my dual drive A5000.

Daniel - which drive connectors did you plug your floppy and Gotek into on the A5000 PCB? I'd guess at PL10 for the floppy and PL11 for the Gotek? Or did you use a split cable, so both plug into PL10?

...then I'll post up what you need to do, as it only takes a couple of minutes :)

For it to be drives 0 and 1, wouldn't it have to be both in PL10?
Edit: actually i don't think I understand the floppy drive connectors in an A5000.

steve3000
Posts: 1816
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Spoofing Drive number on RiscOS

Postby steve3000 » Thu Mar 29, 2018 10:35 pm

IanS wrote:
steve3000 wrote:Thought about this for a couple of hours tonight and I now have a 100% robust software solution, tried and tested on my dual drive A5000.

Daniel - which drive connectors did you plug your floppy and Gotek into on the A5000 PCB? I'd guess at PL10 for the floppy and PL11 for the Gotek? Or did you use a split cable, so both plug into PL10?

...then I'll post up what you need to do, as it only takes a couple of minutes :)

For it to be drives 0 and 1, wouldn't it have to be both in PL10?

No, on the A5000 RISC OS polls all four possible drives on startup, and assigns drive numbers 0,1,2,3 in the order it detects the drives, starting with PL10 then PL11.

So an A5000 with two internal floppy drives, both on PL10, they would be labelled as 0 and 1 by RISC OS. However, with one internal drive on PL10 and two external drives on PL11, then the internal drive would be 0 and the external drives would be 1 and 2.

steve3000
Posts: 1816
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Spoofing Drive number on RiscOS

Postby steve3000 » Thu Mar 29, 2018 11:46 pm

My thought was, wouldn't it be better to intercept the final stage of the process when ADFS sends the drive select/motor-on message to the FDC? Working on the assumption that ADFS used only one piece of code to do select a drive (why would you use more?), and providing this routine could be tracked down easily, then a small patch here would offer a 100% robust method of swapping the drives. :)

Quick peak at the A5000 TRM and the 82C711 data sheet, shows the A5000 has the 82C710 drive select address wired to &3010FC8.

Hardware addresses are usually stored as a word in the module data, rather than being created by MOV and ADD instructions, for simplicity and ease of modification. So I searched the ADFS module for &3010FC8 but didn't find a hit. Next thing was to search for an offset to this, so I chose &3010FC0...and found a single hit at &4894. Quick disassembly of the surrounding code showed R0 being loaded with this value and then a STR R14,[R0,#8] - and we have identified the drive select code. A bit more poking around and you find a 4-byte table of predefined drive select/motor-on bits at &4554, which are selected based on a value of 0-3 in R1.

So to swap the drives, you simply swap the appropriate byte entries in the ADFS drive select/motor-on table! Simples :D

The following should swap round two drives connected to PL10 on the A5000 (tested on ADFS v2.67 and ADFS v2.68):

Code: Select all

10 SYS"OS_Module",18,"ADFS"TO,,,addr
20 len=!(addr-4)-4
30 DIM adfs len
40 FOR i=0 TO len-4 STEP 4:adfs!i=addr!i:NEXT
50 IF !(adfs+&4554)<>&33232110 STOP ELSE !(adfs+&4554)=&33231021
60 PRINT"Press Y to swap drives":key$=GET$
70 IF key$="Y" THEN SYS"OS_Module",11,adfs,len ELSE STOP

If your second drive is on PL11, change line 50 as follows:

Code: Select all

50 IF !(adfs+&4554)<>&33232110 STOP ELSE !(adfs+&4554)=&33102123

To revert to normal type:

Code: Select all

*RMKill ADFS
*RMReInit ADFS

Note: This drive swap code will only work on an A5000 as it needs the 82c71x controller. Later Archimedes (A3010/A3020/A4000/etc.) do use this controller, but were only wired for one drive :(

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Spoofing Drive number on RiscOS

Postby crj » Fri Mar 30, 2018 2:46 am

Sneaky. (-8 That looks like it should be pretty solid in practice, though it's a pity it doesn't work on earlier machines.

The number of different places to choose from in placing such a hack is impressive. You opted for the lowest software level; it briefly occurred to me that patching FileCore would do the trick just as surely as patching ADFS.

Indeed, a surprisingly legal option would be to trap OS_FSControl 12 on the way from ADFS to FileSwitch and interpose a shim that swapped the drives at the filename level on the way up and down the stack. It would be a lot of work, but is the one way I can think of that doesn't play fast and loose with the OS and its APIs in one way or another.

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

Re: Spoofing Drive number on RiscOS

Postby danielj » Fri Mar 30, 2018 5:31 am

Both on PL10. PL11 is the funky one that you can fiddle with to get odd drives to work.

Thank you for this! I'll give it a go this morning! :D

It's a gotek festival here at the moment!

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

Re: Spoofing Drive number on RiscOS

Postby danielj » Fri Mar 30, 2018 8:34 am

That is working perfectly! Thank you for your help everyone :D

steve3000
Posts: 1816
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Spoofing Drive number on RiscOS

Postby steve3000 » Fri Mar 30, 2018 11:55 am

Glad it works :)

One thing to be aware of if using this to swap two real drives (not Gotek) is that in the eyes of ADFS, this patch is equivalent of swapping the physical drives at the connector. So the drive step settings are also swapped. This initially confused my 5.25" external drive, and made my internal 3.5" drive chug very slowly! This is not an issue for Gotek, or swapping two similar spec drives, but if like me, anyone feels the urge to use this code to swap a 5.25" external drive with the internal drive, in this situation you may need to configure the internal drive to use a slower step setting before swapping.

crj wrote:it's a pity it doesn't work on earlier machines.

I've not looked into the 1772 code, but something similar may be possible. I remember on my A310 b.i.t.d. its external drive buffer board had an external switch to swap the external drive with the internal. I found this very useful at the time, as I'd moved to the A310 from a beeb, so had plenty of 5.25" discs, but only a handful of 3.5" ones.

User avatar
lcww1
Posts: 200
Joined: Wed Mar 15, 2017 11:16 pm
Location: East of the Sun and West of the Moon
Contact:

Re: Spoofing Drive number on RiscOS

Postby lcww1 » Fri Mar 30, 2018 12:22 pm

This is utterly awesome! :D =D>

I've been following this thread with some interest, though most of the technicalities remain beyond my current level of understanding.

steve3000 wrote:Quick peak at the A5000 TRM and the 82C711 data sheet, shows the A5000 has the 82C710 drive select address wired to &3010FC8.


I've been looking at the A5000 TRM lately, but I can't figure out how you worked out the drive select address from these documents - I can see from the I/O system memory map in Fig 1-5 on p1-7 that the 82C710 is mapped to the region from &3010000 to &3011000, but I can't fathom how you worked out the drive select address of &3010FC8 - can you put me out of my misery?

steve3000
Posts: 1816
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Spoofing Drive number on RiscOS

Postby steve3000 » Fri Mar 30, 2018 11:10 pm

lcww1 wrote:I've been looking at the A5000 TRM lately, but I can't figure out how you worked out the drive select address from these documents - I can see from the I/O system memory map in Fig 1-5 on p1-7 that the 82C710 is mapped to the region from &3010000 to &3011000, but I can't fathom how you worked out the drive select address of &3010FC8 - can you put me out of my misery?

Sure.

The TRM is only half the storey.

Look at the circuit diagram, you'll see A0-A9 of the 82C710 are mapped to LA2-LA11. So the addresses of the 82C710 registers are shifted left by 2 places = x 4 to the addresses quoted in the datasheet.

In the 82C711 datasheet here (which I assumed is compatible with the 82C710, used in the A5000) you'll find on page 26 the drive/motor select address register at &3F2. Multiplying this by 4 gives &FC8.

The TRM shows the address space for 82C710 starts at &3010000, so the drive/motor select register will be at &3010FC8. :D

User avatar
lcww1
Posts: 200
Joined: Wed Mar 15, 2017 11:16 pm
Location: East of the Sun and West of the Moon
Contact:

Re: Spoofing Drive number on RiscOS

Postby lcww1 » Sat Mar 31, 2018 9:58 am

steve3000 wrote: the 82C710 registers are shifted left by 2 places = x 4 to the addresses quoted in the datasheet.


Many thanks indeed for taking the trouble to spell this out for me! I wouldn’t have figured out the left shift, but your explanation makes it all clear to me now - this has been a most important educational thread, so thanks again :D