help to identify unknown boot selector switch

  • Thread starter Thread starter fordav1
  • Start date Start date
  • Replies Replies 7
  • Views Views 1367

fordav1

New member
Joined
Aug 31, 2014
Posts
162
Country
Australia
Region
WA
Can anyone identify the origin of this boot selector switch?
It's very well made and has a PAL on the PCB under the 8520.
The grey wires go to a SPDT (on-off-on) switch and the yellow wire goes to a +5V source (not sure why the power was not taken from the CIA socket?). It came in an A500+ I picked up recently.
Just curious who made it or where it comes from.
Anyone know?
 

Attachments

  • unknown-boot-selector.jpg
    unknown-boot-selector.jpg
    191.9 KB · Views: 4
Last edited:
Can anyone identify the origin of this boot selector switch?
You could exhaustively search e.g. amiga.resource.cx or bboah for that "RK" etching on the PCB.
Other than that, I vaguely recall a very similar switch surfacing some time ago. But like yours, I think it was an unidentified construction.

It's very well made and has a PAL on the PCB under the 8520.
The grey wires go to a SPDT (on-off-on) switch and the yellow wire goes to a +5V source (not sure why the power was not taken from the CIA socket?).

It does draw power from the CIA socket. A tell-tale sign is the two pullup resistors seen on the underside. Also the trace from the yellowish wire pad has the usual signal-width, not power-width.
Which means there's no logic in the yellowish wire connecting to +5V, even as a constant "HIGH" signal (could very well be taken from the on-socket +5V).
The yellowish wire connects somewhere else to either receive or provide a signal.
My educated guess is it goes to pin7 of the other (odd) CIA chip (U7).

It came in an A500+ I picked up recently.
Just curious who made it or where it comes from.
Anyone know?
 
BBOAH and ar.cx has no info.
The yellow wire connects to the last pin on the external floppy connector.
I measured it and it's +5v, so yes, logic high. At the PCB end the yellow wire trace joins to pin 12 of the PAL.
 
Last edited:
I don't think so.
You probably confused last and first pin of the external floppy connector. Last pin (pin #23) on the external connector is +12V power source anyway, not +5V.
First pin on the external floppy connector is RDY, same as pin7 on U7.
Actually it's _RDY (active low), which means it'll measure +5V most of the time unless after the drive motor has been started and about half a second has passed.
 
ah yeah last pin. well looking from the front with the top of the A500+ off, it's the left-most pin.
See pic attached.
 

Attachments

  • DSCN1559.jpg
    DSCN1559.jpg
    203 KB · Views: 4
Yep that's pin #1 (notice the unique square solder pad signifying #1 vs the other round solder pads), that's the _RDY signal.
Could use a clip-on probe hook on pin #7 of U7 instead, but net result is the same.
That's for proper drive switching, if you disconnect it you'll lose the internal drive in the switched-drives state.
 
it seems to be a bit dodgy because when the external drive is DF0: the internal drive doesn't work and when I switch the SPDT the other way the external drive becomes DF1: as normal but the internal drive still doesn't work. If I remove the boot selector it works fine as DF0:
However I tried switching a few times and at one point it did boot from DF0: internal drive. Doesn't work now though, it only works to set external drive as DF0: and the internal drive doesn't work regardless of the switch position.
 
A complete drive switcher (vs simple boot selector with no extra logic) must cater for 2 things:

1. swap SEL0/SEL1 lines (like a simple boot selector), this can be done purely mechanically of course but needs 4 wires, so in your switcher (3 wires) it's the PAL that handles the SEL0/SEL1 swapping based on the mechanical switch state

2. ensure proper ID for the internal drive when it's controlled by CIA SEL1. Drives controlled by CIA SEL0 don't really need to ID themselves. This is where the wiring to _RDY comes into play, as the ID is handed down to the system via this signal. The PAL must be properly programmed though as lots of input signals (_MTRX, _SEL0, _SEL1) come into play to produce the ID.

So maybe the PAL is somehow malfunctioning (badly programmed/corrupted).
 
Back
Top Bottom