Spoofing Drive number on RiscOS

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

Spoofing Drive number on RiscOS

Post by danielj » Sun Mar 25, 2018 6:50 pm

I've just popped a Gotek in my A5000 as Drive 1 - does anyone know if it's possible to "spoof" the drive numbers on a temporary basis? (i.e. make 1=0 and vice versa) - most games are badly behaved and assume they're in drive 0...

d.

User avatar
lcww1
Posts: 229
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

Post by lcww1 » Sun Mar 25, 2018 9:31 pm

danielj wrote:I've just popped a Gotek in my A5000 as Drive 1
I don’t know if it’s possible to spoof floppy drive number, but I’m interested to hear you’ve got a Gotek running on your A5000 - I’ve never managed to get mine to work :(

I’ve got the latest HxC firmware on my Gotek - it works beautifully on my Beebs, but I’ve only ever got drive empty errors on RISC OS machines, no matter what I’ve tried. Are you using HxC, or FlashFloppy? I’m planning to have a go with FlashFloppy soon......

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Sun Mar 25, 2018 9:54 pm

Flashfloppy. We've been iterating it quite a bit (the later arcs have some peculiarities with "drive empty"), but it's behaving now :)

- are you using HxC with an 8271 beeb? As the roots of the issue should affect that too...

d.

User avatar
lcww1
Posts: 229
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

Post by lcww1 » Sun Mar 25, 2018 10:40 pm

thanks for confirming re FlashFloppy - I was hoping that might do the trick!

I'm using an HxC Gotek on a Beeb with a Retroclinic 177x DFS controller, and on a Master 128. The Master has a Datacentre fitted, so I've only ever used the Gotek with DFS.

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Sun Mar 25, 2018 10:46 pm

Okay, the 177x should be fine (it was with earlier FF too) but I suspect HxC won't play nicely with an 8271 either. It's this index signal malarkey... Anyway flashfloppy is behaving now, and any issues on beeb and ARX there's a fair idea about their root so they can be fixed fairly fast. :)

d.

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

Re: Spoofing Drive number on RiscOS

Post by steve3000 » Sun Mar 25, 2018 11:05 pm

danielj wrote:I've just popped a Gotek in my A5000 as Drive 1 - does anyone know if it's possible to "spoof" the drive numbers on a temporary basis? (i.e. make 1=0 and vice versa) - most games are badly behaved and assume they're in drive 0...
In software? ...if so, probably not easy for what you want to do unfortunately. Early games, particularly RISC OS 2 era, but some RO3 games too, simply issue equivalent of *DRIVE 0 at the start, or load data with the drive number in the filename eg. ":0.$.!gamexyz.data001". You could write some code to hang of file system vectors and replace the drive number, and this would work for simple situations. If the games have disc protection (most likely) then you'd also have to patch calls to ADFS_DiscOp, again definitely possible, but would take time and effort.

Easier, in my opinion, would be to make a hardware switch to change over the drives. This would avoid any issues with software not catching any obscure methods used by some games to access drive 0.

Otherwise, if it's only a few games of interest, it might be easier to patch the games themselves (I did this a few years back for a couple of games - Drop Ship and Etype...wasn't too difficult...).

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

Re: Spoofing Drive number on RiscOS

Post by sirbod » Mon Mar 26, 2018 11:24 am

danielj wrote:does anyone know if it's possible to "spoof" the drive numbers on a temporary basis? (i.e. make 1=0 and vice versa) - most games are badly behaved and assume they're in drive 0...
You'd have to take over the SWI vector and watch for ADFS_DiscOp and ADFS_MiscOp. In the case of MiscOp, the drive number is in R1. For DiscOp, the drive number is in the top 3 bits of the address.

Simply swap the drive number as required and pass the call to the original SWI handler.

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Mon Mar 26, 2018 11:35 am

Thanks Jon - I think it's time I learned a bit about RiscOS programming! I'd prefer to run with a software rather than hardware solution if possible...

d.

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

Re: Spoofing Drive number on RiscOS

Post by sirbod » Mon Mar 26, 2018 12:15 pm

danielj wrote:Thanks Jon - I think it's time I learned a bit about RiscOS programming!
It's probably less than 30 lines of code...as this is on RISC OS 3.11 you can simply write over the SWI vector in Page Zero to redirect to yourself, no need for any legal calls.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Mon Mar 26, 2018 3:23 pm

Hmm. I'm not sure I'd agree with that.

Attaching to the SWI hardware vector may indeed be only 30 lines of code, but they're 30 extremely fiddly lines of code, especially if you want to get every last detail right.

Also, hacking the hardware vectors is a very vertical skill that isn't much use for anything else once you've learned it.

I'd favour instead patching the ADFS module. That way, firstly mistakes probably don't leave you needing to reboot and secondly you learn a bit about relocatable modules, which is a good skill to learn.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Mon Mar 26, 2018 3:48 pm

steve3000 wrote:Easier, in my opinion, would be to make a hardware switch to change over the drives. This would avoid any issues with software not catching any obscure methods used by some games to access drive 0.
That would actually be a pretty straightforward hardware project for well under a tenner, if someone has a soldering iron.

You'd just need:
  • Sacrificial floppy drive cable (only a couple of quid if you screw up)
  • 8-conductor cable to reach the back of the machine (these aren't high-speed cables, so maybe an offcut of Cat5?)
  • A spare expansion slot blank
  • A 4PDT toggle switch
  • 16 little bits of heat-shrink sleeving
Procedure:
  • Identify the 7 signals which get twisted over between drives B and A. These are A, GND, B, GND, C, GND, D
  • At some convenient point between the PC and drive B, separate those conductors from the rest of the ribbon cable for 3-4cm. Cut cables A, B, C, D. Call the bare ends A_PC, B_PC, C_PC, D_PC, A_DRV, B_DRV, C_DRV, D_DRV
  • Thread bits of heat-shrink sleeving onto all the conductors in your 8-conductor cable. Solder it to those 8 bare ends. Pull down the heat-shrink sleeving to cover the exposed wire, shrink into place.
  • At the other end, wire the toggle switch so A_PC D_PC connect to either A_DRV and D_DRV or are exchanged. Similarly with B_PC,C_PC and B_DRV,C_DRV. (This will involve four little bits of wire joining pins together.) Thread heat-shrink up all the wires (or pairs of wires, in four cases) and shrink them into place over the contacts afterwards.
  • Drill hole in expansion slot blank. Fit switch.
  • Install in place of normal floppy cable. Test. Enjoy.
As a one-off, I'm not sure which is quicker: that, or patching ADFS. (-8

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

Re: Spoofing Drive number on RiscOS

Post by crj » Mon Mar 26, 2018 4:02 pm

(Hmm. It's a real shame there's no 5V line on floppy cables. If there were, it would be possible to rig up a far neater drive exchanger board that used a multiplexer chip like the Nexperia CBT3257 and had only two conductors going to a switch.

You could do it anyway, but only by messing around with diodes and a boost converter to scavenge a bit of +5V from the select and motor signals themselves. Ick.)

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Mon Mar 26, 2018 4:31 pm

Given what a ballache it was to tuck the cable in there for two floppies and how much I hate taking the A5000 apart if I don't have to (and also that I don't want to make holes in anything and wish to avoid danglies) I think I'd prefer the software solution on this one... :)

d.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Mon Mar 26, 2018 5:33 pm

Hey, at least it's better than the BBC Micro, where you don't have podule bays. Fitting an extra switch or two on an Archimedes is way more benign!

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

Re: Spoofing Drive number on RiscOS

Post by sirbod » Mon Mar 26, 2018 7:16 pm

crj wrote:Hmm. I'm not sure I'd agree with that.

Attaching to the SWI hardware vector may indeed be only 30 lines of code, but they're 30 extremely fiddly lines of code
There’s nothing fiddly to it at all, maybe you’re thinking of something else. The only complication is providing a way to switch the drives around, be it * command or key combination.

Any programmer with basic assembler knowledge could code a hardware vector handler, there’s nothing special about them except for R14 being offset.
crj wrote:especially if you want to get every last detail right.
If it’s not right, the machine is going to instantly lock!

Daniel was quite clear that he wanted a software solution, this is the cleanest way to do it. You could attach code to the end of ADFS and modify it’s FS entry points, but then you’re into disassembling ADFS and figuring out what to modify, not to mention how to add a * command to turn the switch on.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 5:00 am

sirbod wrote:There’s nothing fiddly to it at all, maybe you’re thinking of something else.
Well, for starters you'll need to have interrupts disabled while patching the SWI hardware vector. So far as I'm aware, nothing prohibits interrupts from updating the hardware vectors (well, except to the extent that I'm not sure RISC OS condones changing the SWI hardware vector at all), and you otherwise risk shear whereby the value you capture might have changed before you overwrite it.

Secondly, you need to call the previous handler. The instruction at &8 will probably be a branch, but there's no requirement for it to be. If it is a branch, you'll have to relocate it (paying careful attention if the offset is changing sign) in order to execute it from a different address. If it's a PC-relative LDR you'll need to perform a different relocation. And so on.

The third subtlety, unfortunately, RISC OS itself seems to ignore. (I suppose it's excusable in a single-user OS which doesn't pay much attention to security, and uses identical supervisor and user memory maps.) The OS should, however, be careful when accessing the memory where the SWI instruction supposedly resides. If SWI was invoked from user mode, it ought to use LDRT to fetch the SWI instruction, otherwise LDR.

The fourth subtlety is that you will also need to patch up registers on return from the real handler, so you need to make sure the normal SWI handler returns through you, rather than providing a straightforward follow-on call. Note that you must return ZNCVIF as set by the normal SWI handler, but M0 M1 from your saved stash of R14_svc.

The final issue which has just occurred to me is somewhat show-stopping: FileCore doesn't call ADFS_MiscOp and ADFS_DiscOp anyway! It calls the offsets that ADFS provided in the FS Descriptor Block when it called FileCore_Create, and those are what you'd actually need to intercept.
If it’s not right, the machine is going to instantly lock!
Yeah, right. There's no chance at all of everything apparently working perfectly but things going wrong the first time an X-variant SWI tries to report an error because you accidentally restored the V flag, or you having accidentally broken OS_IntOff. And no chance of your code to call the previous handler working in your test environment only to explode messily when certain other software happens to be running. And so on...
You could attach code to the end of ADFS and modify it’s FS entry points, but then you’re into disassembling ADFS and figuring out what to modify, not to mention how to add a * command to turn the switch on.
You really wouldn't have to disassemble much: just look for the FileCore_Create call, work backwards a tiny bit to find the address of the FS Descriptor Block, change the offsets in it.

As for switching: just drop the modified ADFS and reinit the normal one. The idea of changing the drive mapping under the feet of ADFS without reinitialising it doesn't bear thinking about!

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Tue Mar 27, 2018 5:50 am

Head. Spinning.

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

Re: Spoofing Drive number on RiscOS

Post by sirbod » Tue Mar 27, 2018 10:21 am

I've tested swapping the drive by trapping ADFS_DiscOp and ADFS_MiscOp this morning - it doesn't work. The OS doesn't use ADFS_... to talk to ADFS, but instead goes direct via the Filecore entry points. The upshot is that *. catalogues the actual drive 0 (ie not swapped), but an SWI ADFS_DiscOp addressed to drive 0 reads from drive 1 (ie swapped) #-o

The only other method short of modifying ADFS directly, is the one ADFFS uses - take over the ADFS FileCore entry points and modify the FileCore calls before passing them onto the actual ADFS entry points.

Anyhow...here's the code should anyone want to hack around with SWI's at any point:

Code: Select all

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

DIM code% 1024
Vector_SWI = 2

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)+"1.00 (27 Mar 2018)":DCB 0
 .Help_SwapFloppy DCB "*SwapFloppy swaps drive 0 and 1 around":DCB 0
 .Syntax_SwapFloppy DCB "Syntax: *SwapFloppy":DCB 0
 .Error_Vector_Release DCD 0:DCB "Failed to release the SWI vector":DCB 0
 .Commands DCB "SwapFloppy":DCB 0
 ALIGN
 DCD Entry_SwapFloppy
 DCD 0
 DCD Syntax_SwapFloppy
 DCD Help_SwapFloppy

 DCD 0


.Entry_init
 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
 MOVEQ   R1, R1, LSL #2                 ;YES, shift address up
 ADDEQ   R1, R1, #16                    ;..correct the address
 BICEQ   R1, R1, #%11111100 << 24       ;..clear the ARM command bits
 STREQ   R1, OS_SWI_Vector              ;..save the original vector
 ADREQ   R1, vectorHandler - 16         ;..our vector handler, -16 to correct
 MOVEQ   R1, R1, LSR #2                 ;..shift address down
 ORREQ   R1, R1, #&EA000000             ;..set the ARM command
 STREQ   R1, [R0]                       ;..and replace the vector
 MOV     PC, R14

.Entry_kill
 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     PC, R14

 ._failed
 ADR     R0, Error_Vector_Release       ;oops, can't release vector
 SWI     "OS_GenerateError"


 .FloppiesSwapped DCD 0
 .OS_SWI_Vector   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, #&40                      ;ADFS_DiscOp possibly?
 TEQNE   R12, #&4C                      ;ADFS_MiscOp possibly?
 LDREQ   R12, FloppiesSwapped
 TEQEQ   R12, #1                        ;are we swapping the floppies?
 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, #&240 << 12          ;R12=&40240 << 12 "ADFS_DiscOp"

 TEQ     R14, R12                       ;DiscOp?
 BEQ     ADFS_DiscOp                    ;YES

 ADD     R12, R12, #&C << 12
 TEQ     R14, R12                       ;MiscOp?
 BEQ     ADFS_MiscOp

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


.ADFS_DiscOp
 ANDS    R12, R2, #%111 << 29           ;drive 0?
 TEQNE   R12, #1 << 29                  ;drive 1?
 EOREQ   R2, R2, #1 << 29               ;YES, swap
 B       pass_to_OS


.ADFS_MiscOp
 CMP     R1, #1                         ;drive 0/1?
 EORLS   R1, R1, #1                     ;YES, swap
 B       pass_to_OS

]:NEXT

OSCLI "SAVE FloppySwap "+STR$~code%+" "+STR$~O%
OSCLI "SetType FloppySwap Module"

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

Re: Spoofing Drive number on RiscOS

Post by jgharston » Tue Mar 27, 2018 10:44 am

You mustn't use error number 0, that's a fatal error, it means that the error will bomb out whatever attempts that command and ON ERROR will never be able to trap it.

Luckily, 'failed to release vector' is an existing error, so that's error number &1A1.

Code: Select all

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

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 1:23 pm

jgharston wrote:You mustn't use error number 0, that's a fatal error,
Never mind that - you must never call SWI OS_GenerateError from a module at all! (Well, unless you've been Started). Correct behaviour is to set R0 to the error and return with V=1.

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Tue Mar 27, 2018 2:23 pm

:shock:

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 2:35 pm

OK. I'm actually a little pissed off, right now.

To recap:
sirbod wrote:It's probably less than 30 lines of code...as this is on RISC OS 3.11 you can simply write over the SWI vector in Page Zero to redirect to yourself, no need for any legal calls.
crj wrote:Hmm. I'm not sure I'd agree with that.

Attaching to the SWI hardware vector may indeed be only 30 lines of code, but they're 30 extremely fiddly lines of code, especially if you want to get every last detail right.
[...]
I'd favour instead patching the ADFS module.
sirbod wrote:There’s nothing fiddly to it at all, maybe you’re thinking of something else.
[...]
Any programmer with basic assembler knowledge could code a hardware vector handler
crj wrote:[Lots of things to watch out for, including...]
You will need to patch up registers on return from the real handler.

FileCore doesn't call ADFS_MiscOp and ADFS_DiscOp anyway! It calls the offsets that ADFS provided in the FS Descriptor Block when it called FileCore_Create, and those are what you'd actually need to intercept.
So here we are.
sirbod wrote:I've tested swapping the drive by trapping ADFS_DiscOp and ADFS_MiscOp this morning - it doesn't work.
Yes, I told you it wouldn't.
The only other method short of modifying ADFS directly, is the one ADFFS uses - take over the ADFS FileCore entry points and modify the FileCore calls before passing them onto the actual ADFS entry points.
And how are you proposing to do that without modifying ADFS (or, presumably, FileCore) directly? (Er... also without relying on the layout of the FileCore%ADFS instance workspace and molesting it directly.)
Anyhow...here's the code should anyone want to hack around with SWI's at any point:
I notice that:
  • About 60 of those lines of code relate to intercepting SWIs. You said 30.
  • Your module is self-modifying. You should actually be claiming module workspace and putting the entry point of your SWI modification in that.
  • You call SWI OS_GenerateError.
  • You only handle the SWI hardware vector being a branch instruction
  • You modify the hardware vector with interrupts (potentially) enabled
  • You don't zero OS_SWI_Vector in finalise, nor make sure it is zero in initialise
  • If initialise fails, it is silent, so leaves the module as a zombie that can never be finalised
  • You don't revert the drive number ADFS_DiscOp returns in R2. (You thereby omit possibly the fiddliest part of the code!)
  • Your SWI routine is woefully inefficient:
    • Especially for other SWIs with numbers ending &40 or &4C
    • You pay no attention to code alignment
    • You have long runs of conditional execution, where a branch would be quicker
    • You use R12 (and therefore also load and store it) unnecessarily
Top tip of the day: if you think something is easy, and someone else says it's difficult, before assuming they're wrong and patronising them, be very sure they don't understand the problem better than you do.

*sigh*

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Tue Mar 27, 2018 2:39 pm

OK, there's no need for being pissed off or anyone taking anything personally, this is just a programming conversation - there's more than one way to skin a cat, different people have different ideas, it's not the end of the world, no one died, etc, etc, etc :) :)

d.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 2:50 pm

Still preferring the software solution? :-p

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Tue Mar 27, 2018 3:05 pm

:D

*orders dpdt switch*

d.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 3:44 pm

Um. If you're serious, you need a double pole crossover switch. But they're rare, so you actually need a four-pole crossover switch to fake it with. DPDT isn't enough.

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Tue Mar 27, 2018 4:14 pm

Would this not work? You're just swapping 0 and 1 over?http://www.vegoilguy.co.uk/reverse_pola ... tching.php

d.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 4:26 pm

But you need to swap both the drive selects and the motor controls.

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

Re: Spoofing Drive number on RiscOS

Post by danielj » Tue Mar 27, 2018 8:22 pm

No, only the drive selects on the A5000 - only one motor control is used.
A5000 disc.png
d.

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

Re: Spoofing Drive number on RiscOS

Post by crj » Tue Mar 27, 2018 11:59 pm

Gosh. I thought the A5000 marked the beginning of Acorn's daring policy of doing things the PC way whenever there was no good reason to do otherwise! (-8

I guess that means you can't use a standard floppy cable with a twist to attach two drives and are actually messing with the drive selection links? Ugh.

My comment about it not mattering if you messed up a £2 floppy drive lead may not apply if the A5000 requires something non-standard.

Post Reply