haha I'm dumb. I just realised that it was me who suggested that idea in the first place :lol:
Of course it's the best method, clearly that's the one you should use Joe. You can have as many joysticks as you want by decoding the high address byte :)
Okay, going to have to come clean on this. The DK'Tronics interface I adapted to respond with A3 low (IN-55) that worked fine with Kempston seems now to cause interference with my DivIDE. Not sure why - if anyone can help? There's a DK-Tronics Kempston/Sinclair #1 interface on there as well (on a 48K Spectrum) and they happily play together.
Ah - is it that the DivIDE using port #E3? That has A3 low. So a simple one-bit hack isn't going to work; it needs to test A5 and possible A7 too. Or that A7/A6/A3 are low. So it only works with hacks of the original Kempston interface, or the twin-port ones, with three-line checking, not A3 on its own. Or is there more to the DivIDE that'll clash?
Of course it's the best method, clearly that's the one you should use Joe. You can have as many joysticks as you want by decoding the high address byte :)
Not if the low byte setting means that all 8 upper bits are already allocated to scanning the keyboard. You still need a completely independent low-byte setting to be able to use the upper 8 bits in that way.
Not if the low byte setting means that all 8 upper bits are already allocated to scanning the keyboard. You still need a completely independent low-byte setting to be able to use the upper 8 bits in that way.
Just don't press keys while you're using the joysticks :p
You still have to stop using that joystick socket on the machine to plug in your new input system. You then have to provide a replacement for that joystick port, so your interface needs to provide two joystick sockets just to add one extra joystick.
And now you have an interface that only works with machines with built-in Sinclair sockets that you can feed into; you still don't have one that will work with every machine.
And now you have an interface that only works with machines with built-in Sinclair sockets that you can feed into; you still don't have one that will work with every machine.
Well when I came up with the idea the thought was to come up with a way to use keyboard mapped joystick input on the +3 and +2B.
If using a sinclair machine with the lazy bus separation you'd use the traditional type of remappable cursor joystick interface circuit.
You would be losing one joystick socket and adding seven new, to get all 8 keyboard rows in total.
that's still one less than the 48k version of the interface would need :)
Okay, so you're going back to actually forcing keystrokes from the joystick inputs.
In which case the 48K equivalent is shifting a Sinclair interface down to a different row of the keyboard (which is where I started out).
The question is, have you actually made one that works? What do you actually do to the pins in the joystick socket to fool the system into thinking that's the right data for the read it's trying to do?
Okay, so you're going back to actually forcing keystrokes from the joystick inputs.
In which case the 48K equivalent is shifting a Sinclair interface down to a different row of the keyboard (which is where I started out).
Aye, I'd forgotten all about it until this thread got bumped. An 8 stick interface that maps onto the keyboard would be better than a new ZXI joystick standard from the point of view of existing software compatibility and wouldn't suffer the problem we discussed about having kempston compatibility of colliding with built-in kempston interfaces on disk stuff etc.
The question is, have you actually made one that works? What do you actually do to the pins in the joystick socket to fool the system into thinking that's the right data for the read it's trying to do?
I've not built one no because the thread went off elsewhere and I forgot all about it. Making a +3 etc see keypresses through a sinclair joystick port is certainly possible though. You just pull the appropriate pins up to 5v instead of pulling up the equivalent bits on the data bus. There's actually almost no decoding logic needed at all doing it this way, as we can just do the same as the ULA and only consider A0. The high bits just have to be inverted so that the keyboard row that is at 0v becomes 5v coming through the joystick switches. Then as you rightly pointed out in the other thread it wants diodes to separate the ports so one can't short connections on another (something that Amstrad didn't consider with the SJS ports!)
What I was just mulling over in the bath was that I'm fairly sure I could design a single interface that provides up to 8 key-mapped joysticks with a jumper to select either sinclair or amstrad compatibility (with amstrad machines needing the optional cable to link into one of the built in joy ports).
Not if the low byte setting means that all 8 upper bits are already allocated to scanning the keyboard. You still need a completely independent low-byte setting to be able to use the upper 8 bits in that way.
Well, yes and no. If you decode A0 to ensure that it is low and also A8?A15 to ensure that they are all high, then you can exclude any well behaved interface that decodes A0 to ensure that it is 1 from consideration ? you then need only consider poorly behaved interfaces that do not decode A0. Still, I'd recommend full port decoding if possible as we're starting to run out of free ports!
There is also the point that Guesser raised on IRC that you can only make use of bits D0?D4, as the others will be determined by the ULA. Actually, I'm not sure how much freedom one would have over bits D5 and D7, but it's probably best to be cautious!
Of course, none of this really helps for the +2A/+2B/+3 which cannot do I/O reads from peripherals on the expansion bus with A0 set. As has already been discussed to death, embarking on a nationwide campaign to locate the thousands upon thousands of +2A/+2B/+3 machines that still exist and cut tracks in their PCBs is really not the answer to this. I don't think would get the required media attention for this, and actually, I'm not sure we would want that sort of attention!
BTW, I've just been reading a post on nedopc.org where a certain poster steadfastly refused to acknowledge that the original Spectrum ULA performs two back-to-back burst-mode reads of two bytes (pixels and attributes) despite being shown a trace from a logic analyser. It seemed to me reading this that there might have been deliberate misinterpretation of the words "four in a row" as meaning "four in a DRAM row" and not "four at a time" as the poster clearly intended. It seems we're not alone in this problem.
You still have to stop using that joystick socket on the machine to plug in your new input system. You then have to provide a replacement for that joystick port, so your interface needs to provide two joystick sockets just to add one extra joystick.
And now you have an interface that only works with machines with built-in Sinclair sockets that you can feed into; you still don't have one that will work with every machine.
It is solely your fantasies that do not have any grounds. Of course, the device will work with the ZX Spectrum, ZX Spectrum 128/+2, ZX Spectrum +2a,b/+3.
DivIDE is also listed as using port #17 - how come that hasn't been seen clashing with Kempston-compatible interfaces that only check A5?
Are you sure?
Only I have used a DivIDE and a Kempston compatible interface (SPECTRA) together with no problems.
Black_Cat's useful port info listing shows this for the DivIDE:-
! Standby alert !
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb!
Looking forward to summer in Somerset later in the year :)
P.S. Please don't try to refer to exUSSR clones, about which you know nothing, we'll deal with them ourselves.
Then stop arguing about them all the time. The whole world does not have to play with your broken toys.
You've brought nothing to this discussion but arguments. You haven't offered anything helpful, just negative statements all the time. Yes your port listing is a useful document. Why can't you try to be as helpful?
Are you sure?
Only I have used a DivIDE and a Kempston compatible interface (SPECTRA) together with no problems.
So have I! You're right, I should have known it was the DivIDE+, not the DivIDE. I guess it's still the use of port #E3 that is clashing with my poorly decoded joystick interface as it sets A3 low. I need to start with a better interface that decodes a few more pins, or add some extra logic.
Then stop arguing about them all the time. The whole world does not have to play with your broken toys.
You've brought nothing to this discussion but arguments. You haven't offered anything helpful, just negative statements all the time. Yes your port listing is a useful document. Why can't you try to be as helpful?
This thread is called "Joystick Interfaces on +2A", if you want to discuss exUSSR clones, create topic "Joystick Interfaces on exUSSR clones". You must not intentionally distort facts, a deliberate lie't decorate you.
There is also the point that Guesser raised on IRC that you can only make use of bits D0?D4, as the others will be determined by the ULA. Actually, I'm not sure how much freedom one would have over bits D5 and D7, but it's probably best to be cautious!
That does mean no second fire button. And if it's going to read joysticks by pulsing them with +5V on the Gnd line then they're not going to support autofire, even if you want to. You'd have to buffer/invert their behaviour if you want any of that.
Another question - are you going to reverse the bit order for half the keyboard like Sinclair does or not?
But it's a trade-off - at it's most basic it needs to offer 2 ports; at least one of which is to make up for the Sinclair one you've just taken over for the input. As (I think) already suggested, it would do at least four. Then it can do, for example, Sinclair and one other complete row of keys.
But if you've already got three inputs (Sinclair 1, 2 & Kempston) is it worth it for one more?
Is it so bad to have one interface for Europe and another for Russia, and just swap the port address in software? Since one lot use TAPs and another are all on TRD, there needs to be two versions of every software release anyway...
This thread is called "Joystick Interfaces on +2A", if you want to discuss exUSSR clones, create topic "Joystick Interfaces on exUSSR clones".
The thread was on track, until you started.
But since you insist, then we will no longer consider the requirements or compatibility with any such machines. Happy?
The thread was on track, until you started.
But since you insist, then we will no longer consider the requirements or compatibility with any such machines. Happy?
To create interface four joysticks your services are not needed. Can leave this topic, if you are not able to work together.
What I was just mulling over in the bath was that I'm fairly sure I could design a single interface that provides up to 8 key-mapped joysticks with a jumper to select either sinclair or amstrad compatibility (with amstrad machines needing the optional cable to link into one of the built in joy ports).
Well, that is another thing - there'd have to be two separate paths; one a conventional keystroke/joystick I/O interface and a second one to operate the fly-lead method - if it is to work with all machines. Including those of which we do not speak.
Well, that is another thing - there'd have to be two separate paths; one a conventional keystroke/joystick I/O interface and a second one to operate the fly-lead method - if it is to work with all machines. Including those of which we do not speak.
Well not really two paths. At first I was thinking one would have to be inverted or whatever but in actual fact all it needs is to be able to disable the five bits going to the data bus. The signals can be present on a header for the joystick lead all the time whether one is plugged in or not.
That does mean no second fire button. And if it's going to read joysticks by pulsing them with +5V on the Gnd line then they're not going to support autofire, even if you want to. You'd have to buffer/invert their behaviour if you want any of that.
Basically it would be extra SJS ports.
Anything that works with a +3 works and anything that doesn't wouldn't. I know that's probably not that popular, but it would be extra joysticks :)
You are going to wire the pins up normally, right?!? :o
If it did have 8 ports, and everything was buffered, you could have all the joystick Gnd lines the same. That way you could split one joystick such that any of its spare line(s) operated FIRE on a neighbouring port (like the ST mouse does). Dunnno if you can fathom a way to do that on your straight-through method..?
You know there is another option. At least, I don't think this has been suggested yet and it is not the best solution, but it does have the advantage of not using any more I/O ports.
Make use of data bit D7 of the "Kempston" interface.
When D7 = 0, this indicates that you have read the normal Kempston joystick data.
When D7 = 1, this indicates that you have read the additional joystick data.
So the question you are now wanting an answer to, is how does it work in selecting which joystick to read?...
Well, first a switch is needed to keep the interface in normal Kempston mode (bit D7 always returns 0) so it works okay with existing games.
Second, new or modified programs will need to read 31 dec (1Fh) at least twice to obtain the joystick positions.
In the new mode, a D-type flip-flop changes state every time the Spectrum does an IN. The state of the flip-flop determines which joystick is read.
The disavanage is that although it is possible to modifiy an suitable existing Kempston compatible interface, it is a lot more work than just swapping address lines.
! Standby alert !
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb!
Looking forward to summer in Somerset later in the year :)
You are going to wire the pins up normally, right?!? :o
If it did have 8 ports, and everything was buffered, you could have all the joystick Gnd lines the same. That way you could split one joystick such that any of its spare line(s) operated FIRE on a neighbouring port (like the ST mouse does). Dunnno if you can fathom a way to do that on your straight-through method..?
well you could do it cleverly all buffered but that means logic :)
If you were doing that you could power the joysticks so autofire worked etc just like the discussion with the zxi idea.
The only constraint is that you can only get 5 bits input at a time. Other than that you can do anything with sufficient logic resources.
If on the other hand you want it cheap and simple... 8 SJS ports ("upgraded" to not ghost each other!)
The disavanage is that although it is possible to modifiy an suitable existing Kempston compatible interface, it is a lot more work than just swapping address lines.
It's vastly more awkward than just changing the address though, and much more of a pain for the software.
If all you want is an additional joystick to use with existing two sinclair inputs and a kempston then a butchered kempston with the address changed is probably the best answer so far.
Something similar was suggested a few weeks ago - use a flip-flop or counter that cycles through the ports each time it is read, and return the counter state in the top bits. Or use OUT on the same port to latch which joystick you want to read back with an IN. The latter is not really any more complicated to implement and gives you more control.
This was also the basis for a multiplexer that uses just a single port in the ZXI addressing scheme, to which you could connect upto 256 different fully 8-bit input devices.
You could do this for two sticks on IN 31 with a simple strobed flip-flop or a latched bit, but you'd have to build a new interface again. And it would be no more 'universally' compatible than picking a new IN address.
well you could do it cleverly all buffered but that means logic :)
If you were doing that you could power the joysticks so autofire worked etc just like the discussion with the zxi idea.
The only constraint is that you can only get 5 bits input at a time. Other than that you can do anything with sufficient logic resources.
If on the other hand you want it cheap and simple... 8 SJS ports ("upgraded" to not ghost each other!)
What if you used both joystick inputs and split the interface down the middle? Could you somehow have one joystick's second fire button optionally cross-coupled to its partner?
I suppose not; you'd still need logic. Each joystick could only operate a specific set of 5 keys. It couldn't just press any keys you fancied.
Comments
Of course it's the best method, clearly that's the one you should use Joe. You can have as many joysticks as you want by decoding the high address byte :)
http://fuse-emulator.sourceforge.net/
Ah - is it that the DivIDE using port #E3? That has A3 low. So a simple one-bit hack isn't going to work; it needs to test A5 and possible A7 too. Or that A7/A6/A3 are low. So it only works with hacks of the original Kempston interface, or the twin-port ones, with three-line checking, not A3 on its own. Or is there more to the DivIDE that'll clash?
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
Just don't press keys while you're using the joysticks :p
And now you have an interface that only works with machines with built-in Sinclair sockets that you can feed into; you still don't have one that will work with every machine.
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
Well when I came up with the idea the thought was to come up with a way to use keyboard mapped joystick input on the +3 and +2B.
If using a sinclair machine with the lazy bus separation you'd use the traditional type of remappable cursor joystick interface circuit.
You would be losing one joystick socket and adding seven new, to get all 8 keyboard rows in total.
that's still one less than the 48k version of the interface would need :)
In which case the 48K equivalent is shifting a Sinclair interface down to a different row of the keyboard (which is where I started out).
The question is, have you actually made one that works? What do you actually do to the pins in the joystick socket to fool the system into thinking that's the right data for the read it's trying to do?
- IONIAN-GAMES.com -
Aye, I'd forgotten all about it until this thread got bumped. An 8 stick interface that maps onto the keyboard would be better than a new ZXI joystick standard from the point of view of existing software compatibility and wouldn't suffer the problem we discussed about having kempston compatibility of colliding with built-in kempston interfaces on disk stuff etc.
I've not built one no because the thread went off elsewhere and I forgot all about it. Making a +3 etc see keypresses through a sinclair joystick port is certainly possible though. You just pull the appropriate pins up to 5v instead of pulling up the equivalent bits on the data bus. There's actually almost no decoding logic needed at all doing it this way, as we can just do the same as the ULA and only consider A0. The high bits just have to be inverted so that the keyboard row that is at 0v becomes 5v coming through the joystick switches. Then as you rightly pointed out in the other thread it wants diodes to separate the ports so one can't short connections on another (something that Amstrad didn't consider with the SJS ports!)
What I was just mulling over in the bath was that I'm fairly sure I could design a single interface that provides up to 8 key-mapped joysticks with a jumper to select either sinclair or amstrad compatibility (with amstrad machines needing the optional cable to link into one of the built in joy ports).
Well, yes and no. If you decode A0 to ensure that it is low and also A8?A15 to ensure that they are all high, then you can exclude any well behaved interface that decodes A0 to ensure that it is 1 from consideration ? you then need only consider poorly behaved interfaces that do not decode A0. Still, I'd recommend full port decoding if possible as we're starting to run out of free ports!
There is also the point that Guesser raised on IRC that you can only make use of bits D0?D4, as the others will be determined by the ULA. Actually, I'm not sure how much freedom one would have over bits D5 and D7, but it's probably best to be cautious!
Of course, none of this really helps for the +2A/+2B/+3 which cannot do I/O reads from peripherals on the expansion bus with A0 set. As has already been discussed to death, embarking on a nationwide campaign to locate the thousands upon thousands of +2A/+2B/+3 machines that still exist and cut tracks in their PCBs is really not the answer to this. I don't think would get the required media attention for this, and actually, I'm not sure we would want that sort of attention!
BTW, I've just been reading a post on nedopc.org where a certain poster steadfastly refused to acknowledge that the original Spectrum ULA performs two back-to-back burst-mode reads of two bytes (pixels and attributes) despite being shown a trace from a logic analyser. It seemed to me reading this that there might have been deliberate misinterpretation of the words "four in a row" as meaning "four in a DRAM row" and not "four at a time" as the poster clearly intended. It seems we're not alone in this problem.
http://fuse-emulator.sourceforge.net/
It is solely your fantasies that do not have any grounds. Of course, the device will work with the ZX Spectrum, ZX Spectrum 128/+2, ZX Spectrum +2a,b/+3.
Only I have used a DivIDE and a Kempston compatible interface (SPECTRA) together with no problems.
Black_Cat's useful port info listing shows this for the DivIDE:- I suspect that the port #17 reference maybe related to the divIDE+
Some info on Joystick interfaces and divIDE and divIDE+ here
Mark
Repair Guides. Spanish Hardware site.
WoS - can't download? Info here...
former Meulie Spectrum Archive but no longer available :-(
Spectranet: the TNFS directory thread
! Standby alert !
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb!
Looking forward to summer in Somerset later in the year :)
You've brought nothing to this discussion but arguments. You haven't offered anything helpful, just negative statements all the time. Yes your port listing is a useful document. Why can't you try to be as helpful?
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
This thread is called "Joystick Interfaces on +2A", if you want to discuss exUSSR clones, create topic "Joystick Interfaces on exUSSR clones". You must not intentionally distort facts, a deliberate lie't decorate you.
Another question - are you going to reverse the bit order for half the keyboard like Sinclair does or not?
But it's a trade-off - at it's most basic it needs to offer 2 ports; at least one of which is to make up for the Sinclair one you've just taken over for the input. As (I think) already suggested, it would do at least four. Then it can do, for example, Sinclair and one other complete row of keys.
But if you've already got three inputs (Sinclair 1, 2 & Kempston) is it worth it for one more?
Is it so bad to have one interface for Europe and another for Russia, and just swap the port address in software? Since one lot use TAPs and another are all on TRD, there needs to be two versions of every software release anyway...
- IONIAN-GAMES.com -
But since you insist, then we will no longer consider the requirements or compatibility with any such machines. Happy?
- IONIAN-GAMES.com -
To create interface four joysticks your services are not needed. Can leave this topic, if you are not able to work together.
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
Well not really two paths. At first I was thinking one would have to be inverted or whatever but in actual fact all it needs is to be able to disable the five bits going to the data bus. The signals can be present on a header for the joystick lead all the time whether one is plugged in or not.
Basically it would be extra SJS ports.
Anything that works with a +3 works and anything that doesn't wouldn't. I know that's probably not that popular, but it would be extra joysticks :)
If it did have 8 ports, and everything was buffered, you could have all the joystick Gnd lines the same. That way you could split one joystick such that any of its spare line(s) operated FIRE on a neighbouring port (like the ST mouse does). Dunnno if you can fathom a way to do that on your straight-through method..?
- IONIAN-GAMES.com -
Make use of data bit D7 of the "Kempston" interface.
When D7 = 0, this indicates that you have read the normal Kempston joystick data.
When D7 = 1, this indicates that you have read the additional joystick data.
So the question you are now wanting an answer to, is how does it work in selecting which joystick to read?...
Well, first a switch is needed to keep the interface in normal Kempston mode (bit D7 always returns 0) so it works okay with existing games.
Second, new or modified programs will need to read 31 dec (1Fh) at least twice to obtain the joystick positions.
In the new mode, a D-type flip-flop changes state every time the Spectrum does an IN. The state of the flip-flop determines which joystick is read.
The disavanage is that although it is possible to modifiy an suitable existing Kempston compatible interface, it is a lot more work than just swapping address lines.
Mark
Repair Guides. Spanish Hardware site.
WoS - can't download? Info here...
former Meulie Spectrum Archive but no longer available :-(
Spectranet: the TNFS directory thread
! Standby alert !
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb!
Looking forward to summer in Somerset later in the year :)
well you could do it cleverly all buffered but that means logic :)
If you were doing that you could power the joysticks so autofire worked etc just like the discussion with the zxi idea.
The only constraint is that you can only get 5 bits input at a time. Other than that you can do anything with sufficient logic resources.
If on the other hand you want it cheap and simple... 8 SJS ports ("upgraded" to not ghost each other!)
It's vastly more awkward than just changing the address though, and much more of a pain for the software.
If all you want is an additional joystick to use with existing two sinclair inputs and a kempston then a butchered kempston with the address changed is probably the best answer so far.
This was also the basis for a multiplexer that uses just a single port in the ZXI addressing scheme, to which you could connect upto 256 different fully 8-bit input devices.
You could do this for two sticks on IN 31 with a simple strobed flip-flop or a latched bit, but you'd have to build a new interface again. And it would be no more 'universally' compatible than picking a new IN address.
- IONIAN-GAMES.com -
I suppose not; you'd still need logic. Each joystick could only operate a specific set of 5 keys. It couldn't just press any keys you fancied.
- IONIAN-GAMES.com -
Nope, the inputs are just parallel like keyboard rows. The only difference is the high memory address line (column).