True, but a lot of older ones didn't come with through-ports to be able to daisy chain them like that. That new one does. Perhaps Ben would consider a redesign with a DIP selector on it? Or multiple ports?
But I don't see how the modified interface would continue to be Kempston compatible - it could be rather random how it responds. If you've just programmed in an IN 31 in machine code, the high byte could be anything left over from a previous operation, so the read would be unpredictable. It may take data from several sticks at once, or miss the one you have plugged in.
I meant that one modified interface would still respond to 0x001F, obviously if two were plugged in then they would both respond and there'd be a collision.
I didn't realise that IN a,(n) only sets the low address byte, I assumed the other bits would all be reset, my bad.
Just like my alternate keyboard idea, once you'd modified the interface you'd either need custom software to read it or a switch to set it back to normal.
Putting a switch to go between "normal" and "extra joystick" would be do-able, as would adding 8 dip switches to select which extra line should be considered if any. It would need mounting somewhere of course and it suddenly becomes enough of a hassle that it's easier to just build a new board :sad:
The only reason I'd go for Sinclair style is you can do two ports at once by hacking an old interface. Kempston interfaces would need a more detailed circuitry mod and only add one port each, and that's if they have a through-port.
Hacking the kempston to watch an extra line is only a case of using one of the unused OR gates and wiring it to the appropriate address line. It does mean cutting a track or leg on the chip but not terribly drastic.
If I was to build a prototype 8 port kempston would you prefer to select joysticks by setting a particular address bit, or by decoding the address down so 0x021F reads port 2?
The latter would require an extra IC but possibly makes the code to read inputs easier?
On the other hand, the former allows you to do the same trick as with the speccy keyboard if you want to wait for any fire button to be pressed to start a game for example. Just read all joysticks OR-ed together.
I could get the parts and build a prototype interface in a couple of days if you like!
If it's going to be a new protocol then I don't think the way the upper byte is used matters much. It depends on how many joysticks you want to support. Is eight (ten if you count the inbuilt Sinclair ports) really enough? :lol:
If using one bit high or low each is easier to build in hardware (as in one-bit 'decoding') then that's fine. A fully-decoded number invites a ridiculous number of joysticks.
If you are going for a decoded literal number, then you could build the board with DIP switches to set a few more bits of the Joystick IDs on that board, so you could daisy-chain them if you really were mad. God knows how many joysticks you could actually power off a single Speccy though. You wouldn't all be able to all get around the TV.
You might also want a switch to say, ignore the decoding and just return the state of Joystick #1 for all IN 31 reads, for compatibility.
But don't do anything at the moment just for me. I wouldn't know what to do with that many inputs. As I said, I have an idea for four joysticks (two players, twin-stick control) but I can do that with a modified Sinclair-type interface. I still feel that'd be the most common way of getting four sticks in there (at least, on a +2). But I think you're right, any more than that (daisy-chaining hacked interfaces) isn't worth it compared to a dedicated board.
It wouldn't look even slightly strange for a Speccy multi-player game to try to support a load of different joystick protocols.
If it's going to be a new protocol then I don't think the way the upper byte is used matters much. It depends on how many joysticks you want to support. Is eight (ten if you count the inbuilt Sinclair ports) really enough? :lol:
Well I know you could probably squeeze out 8 player controlled sprites at 50hz no bother, but would it even be playable? :lol:
If using one bit high or low each is easier to build in hardware (as in one-bit 'decoding') then that's fine. A fully-decoded number invites a ridiculous number of joysticks.
256 basically, the board would have to be enormous to fit all the joystick port headers let alone the decoding logic :)
If you are going for a decoded literal number, then you could build the board with DIP switches to set a few more bits of the Joystick IDs on that board, so you could daisy-chain them if you really were mad. God knows how many joysticks you could actually power off a single Speccy though. You wouldn't all be able to all get around the TV.
A 256 port joystick interface could have an external power source so that wouldn't be the limiting factor. I can't believe even you could make a playable game with 2048 separate inputs though ;)
You might also want a switch to say, ignore the decoding and just return the state of Joystick #1 for all IN 31 reads, for compatibility.
Yup, I was thinking about that in the car earlier, it should be simple to have a switch to disable the upper addresses and at the same time hard wire Joystick 0 on so it behaves like a standard kempston.
But don't do anything at the moment just for me. I wouldn't know what to do with that many inputs. As I said, I have an idea for four joysticks (two players, twin-stick control) but I can do that with a modified Sinclair-type interface. I still feel that'd be the most common way of getting four sticks in there (at least, on a +2). But I think you're right, any more than that (daisy-chaining hacked interfaces) isn't worth it compared to a dedicated board.
It wouldn't look even slightly strange for a Speccy multi-player game to try to support a load of different joystick protocols.
Ok, well I'll keep mulling it over, I think I more or less have all the elements worked out in my head so I'll design a circuit and post it up for comments but leave the soldering iron switched off until you come up with an idea that needs 8 joystick ports :o
A 256 port joystick interface could have an external power source so that wouldn't be the limiting factor. I can't believe even you could make a playable game with 2048 separate inputs though ;)
What I meant was, you could make a vertical board with just two or four ports on its top edge and an extender out the back. Let's say it had four ports, numbered 0-3. That only uses two bits out of the 8 that make up our joystick identifier (0-255). You then have DIP switches to set the higher 6 bits for the joysticks on that board.
So one board has sticks 0-3, then you can plug in another board and set the switches so it becomes sticks 4-7, another for 8-11, etc. You stack as many as you want. Or you could design a parent board with the main connector and a power input, then a simpler daughter board with more common connectors that you can stack to add ports.
Whereas if it's the fixed 8-way interface with one bit per stick, it makes more sense to just do it all on one big flat board; it'd just make the track layout more fiddly.
You could always build the flat 8-way board based on the 0-255 protocol anyway, and leave both an expansion port to the rear and an unpopulated spot to attach either a DIP or jumper header, for fixing the top 5 bits of the joystick IDs. Neither should then really add to the cost of the resultant board; it'd just make the track layout more fiddly.
Ok, well I'll keep mulling it over, I think I more or less have all the elements worked out in my head so I'll design a circuit and post it up for comments but leave the soldering iron switched off until you come up with an idea that needs 8 joystick ports :o
Well, as I said, I can think of using two extra ports. Two players with a twin-stick setup (or a console-style stick with extra buttons). But then I can hack an existing DK'Tronics / IF2 interface with a single crossed wire to get around the 128K's port $FE isolation.
OK, just tried my "Railscan" idea with a DK'Tronics interface. On my +2A I can read the Kempston joystick port on IN 31 (Kempston) and the diverted Sinclair one on IN 61423 ($EFEF) instead of IN 61438 ($EFFE). All I needed to do was cut line A0 and divert it to A4. Well, and fix the up/down error on this interface type. I suppose I could try and get hold of an Interface II too to demonstrate it for both ports.
The most straightforward way to make an 8 player kempston joystick interface that I can see would be to make use of the 3 unused bits of the data byte.
Although I've seen some kempston style interface schematics online that allow for 2 fire buttons the standard seems to be the 4 direction buttons + the fire button mapped to the lower 5 bits with the upper 3 bits of the byte hardwired to 0.
It would be simple to construct a circuit that output the data from 1 of up to 8 joysticks in a round robin fashion while adding the number of that joystick to the top 3 bits of the data byte.
From the spectrum side you would just do normal kempston style IN 31 commands.
If there were 3 joysticks attached
The first IN 31 executed would receive the data from the first joystick identified by bits 5 to 7 being set to 000
the next IN 31 executed would receive the data from the second joystick identified by bits 5 to 7 being set to 001
the next IN 31 executed would receive the data from the third joystick identified by bits 5 to 7 being set to 011
and so on for as many joysticks as are attached, (as there are only 3 attached in this example the next IN 31 would receive the data from the first joystick again.)
It would make it easy and fast from the software point of view. Which will be important if you're coding a multiplayer game.
You could perform a simple loop to test for how many joysticks are present at the start of the game for example.
And if a normal kempston interface was used instead the game would detect only the one joystick as bits 5 to 7 should always be 0.
I'd suggest four as being the most players you're going to be able support around a single monitor. So if this is to tie in with the multiple monitor thing then add an additional four for every extra monitor. I'd suggest supporting the Genesis 6-button controllers which are still widely available and use an Atari D-type connector. You're going to need more ports. Just use the ZXI standard and have done with it. Joystick interfaces aren't particularly expensive to make.
Yep - not keen on the cycling idea as you need direct control of what you're reading, so as not to waste time.
Maybe set aside a port now that you could write to with an identifier 0-255 as data, then read back an 8-bit digital input from. That way you have a universal input multiplexer that you could use for as many joysticks, keypads or buttons as you like. Perhaps set aside outputting '0' to then read back an interface identifier code (which itself is > 0), so you can auto-configure if you recognise it.
And at the same time, reserve another port for 8-bit encoded analogue inputs.
That's instead of occupying a new address for each controller; though it would mean the interface is more complicated as it would have to latch the active controller line following an I/O WRITE. But then you really won't run out of addresses.
I guess you could do the same with port 31 (or 55), if you knew there was a smarter joystick interface attached. But it's risky, as some of those old interfaces can't actually tell between IN-31 and OUT-31.
But I do come back to thinking that four joysticks is enough to be getting on with, for now. And I'm quite pleased to find out that K-55 doesn't clash with ZXI!
Yep - not keen on the cycling idea as you need direct control of what you're reading, so as not to waste time.
I was assuming that in a game the input handling routines would go in a specific order ie: test for input from player one, process that. test for input from player two, process that etc like a keyboard scanning routine. In that case the automatic cycling would save time because you wouldn't have to change port address etc. In fact, thinking about it, could you set up a jump offset type of routine that uses the joystick input byte as the offset for a relative jump. That might save some time. :-)
No that wouldn't work would it as there would only be a couple of bytes for code between some of the joystick directions.
Maybe, but that's assuming that all 8 ports are definitely occupied. Because you wouldn't necessarily know you're starting with the first one each time, so would have to go round all 8 and then decide what to do with the data. In reality, you'd want to be able to use the interface for fewer players.
The interface would deal with that. when it gets to a missing joystick it jumps back to 0. that way if only 2 joysticks are attached then it will just alternate between the two.
The game would test for how many joysticks there were at the start. then you would always know where you are. Or less the code jumps about doing IN 31's at random.
Err - how would it even know a resting joystick from a disconnected one? I think I'd be happier, if forced to, with reading 8 in a round each time than to muck about with variable numbers of returns. But being able to tell it which one I want would be better. You wouldn't even need an extra address decoder; writes would go direct to a latched binary decoder, then the output of that would be ANDed with a read operation to gate the data from one of the joysticks.
OK, maybe using 0 as a query/response code for a joystick interface identifier is a bad idea, as it would be too awkward to apply with simple logic circuitry. Just use a WRITE on a particular ZXI address to latch a joystick (or any 8-bit switch input device), then a READ to get its data. You'd need at least 9 bits of decoding, if not all 16, to detect the ZXI address properly. An address that minimises the decoder chips you'd need overall would be best. ;)
Err - how would it even know a resting joystick from a disconnected one?
Good point :-) A switch would be needed for each joystick socket or a phototransistor maybe to automaticly detect if the joystick is there. Or a simple push button infront of each socket to turn it on and off. That way you can leave the joysticks plugged in all the time and just select the ones you want to use before playing.
You could have a red and green LED for each socket red it's off green its on.
Every interface needs at least 1 LED :D
Seems to me the logic to latch & decode 2 or 3 significant bits from a write operation then use that data when a read occurs is no more complex (possibly less so) than using a counter to do the same. Especially since it would use the same address decoding logic. It's just that writes would trigger the latch-set and reads would trigger the latch-out, which in turn triggers one of the joystick buffers to return its data.
using a single ZXI port for many joysticks would be entirely doable yes.
Not sure quite what you're thinking with the logic of it, but the simplest from a hardware perspective would probably be to OUT a joystick number, then an IN to read the bits from that connector, and you could poll each joystick like this.
Alternatively if that takes too long then you could incorporate Basher's idea of reading ports in order. Tell the interface how many sticks you want to read with the OUT, then repeated INs to read each input in turn.
Not sure quite what you're thinking with the logic of it, but the simplest from a hardware perspective would probably be to OUT a joystick number, then an IN to read the bits from that connector, and you could poll each joystick like this.
Err - that's exactly what I mean. You need to latch the number that's sent OUT. You'd only use as many bits as you need though (3 bits for 8 sticks). If someone asked for stick #9 and they got the results for #1, so be it.
I guess if there were only 8 sticks and you had an 8-bit latch you could choose to do the latching either before or after the number was decoded.
But then an IN just triggers the latch to output its stored data, and that in turn triggers one of the joysticks to put its data on the bus.
And the side-effect is, if you're only providing one joystick through this scheme, you don't need to listen for the OUT at all, as you have no switching to control.
Well you could latch the joystick input bits at the moment you've decoded the 3 data bits into 8 joystick select lines, OR you could latch those lines themselves.
EDIT: just re-read and that's what you were saying :oops:
That means that if you OUT a joystick number, then wait 10 seconds before doing the IN you would still read the actual joystick input rather than the state at the time you selected the joystick. I know that's a silly scenario, but it means you could use the interface to take input from a particular joystick for some period, then switch to another etc and only have to do OUT, IN, IN, IN, IN, IN rather than OUT IN OUT IN OUT IN etc. That would be useful for turn based game where you don't have to pass around a single joystick for example :)
What I would suggest though is a bus receiver/buffer chip between the speccy and all the joystick ports otherwise it's likely to go haywire when you plug loads of joystick cables in :)
What I would suggest though is a bus receiver/buffer chip between the speccy and all the joystick ports otherwise it's likely to go haywire when you plug loads of joystick cables in :)
But I don't see the problem with scaling that up. I mean, each joystick port would have to have its own buffer chip to put its data onto the bus, triggered by the latched joystick selection on an IN instruction. What's likely to go wrong with that scheme?
But I don't see the problem with scaling that up. I mean, each joystick port would have to have its own buffer chip to put its data onto the bus, triggered by the latched joystick selection on an IN instruction.
Ah, tell you what, I was thinking of sinclair sticks, rather than atari style, but I think my idea still works.
If you only put 5v on the selected joystick port and left the others high impedance so all the other sticks are dead then you could in theory just feed the data bits straight into the speccy.
This obviously would be a bad idea, but if you fed those inputs via a buffer that is only active during the IN that would be perfectly adequate, I don't think there's a need for each joystick to have it's own buffer chip unless I'm missing something.
There is another possibility that would require even less logic, but since you'd most likely want to do something like this in a single CPLD these days that's not so much of a benefit.
That said, you could do away with the demux and just use the 8 bits as the 8 select lines. This would mean you'd have to use shifted numbers in the software rather than just being able to set a stick by it's binary value.
On the plus side you would be able to read all sticks simultaneously for "press fire to start" type reads. (think how you code a "press any key" on the speccy if you don't care what key is pressed).
Probably far more coding effort than it's worth having to use bit n to select joystick n, but I'm just throwing out ideas here :)
No, don't want to do that as it caps the number of devices at 8. Decoding is cheap and it would mean you could then multiplex more switches, keypads, buttons, grey-coded wheels, etc. Maybe not the full 256 x 8 bits, but at least you wouldn't hit the limit too soon.
As for linking all the joysticks' outputs together, you'd at least need a load of diodes or you'd get all sorts of matrix effects from your neighbours pressing different diagonals.
And an extension of this is a second port address for doing the same but with 8-bit A/D analogue inputs.
Is there a reason you couldn't build an interface like this using port 31?
If you make sure the joystick select register holds 0 following a reset this means that the player 1 joystick will work as expected with any game using kempston joystick (unless it does something silly and does an OUT) and any game using this scheme will work with a real kempston when set to a single player mode.
Finally there's the added bonus that you will be able to use joystick controlled printer software... ok now I'm just being silly ;)
No, don't want to do that as it caps the number of devices at 8. Decoding is cheap and it would mean you could then multiplex more switches, keypads, buttons, etc. Maybe not the full 256 x 8 bits, but at least you wouldn't hit the limit too soon.
aye, it is these days. As I say there'd almost certainly be gates left over in a CPLD anyway.
As for linking all the joysticks' outputs together, you'd at least need a load of diodes or you'd get all sorts of matrix effects from your neighbours pressing different diagonals.
Drat, I didn't think of that. Phantom diagonals/fire indeed.
Oh well, again, if using a CPLD it's no problem because you have buckets of IO which can be gated through easily.
It would soon get cumbersome and expensive using individual logic chips if you needed 8 bus receivers etc :)
Is there a reason you couldn't build an interface like this using port 31?
If you make sure the joystick select register holds 0 following a reset this means that the player 1 joystick will work as expected with any game using kempston joystick (unless it does something silly and does an OUT) and any game using this scheme will work with a real kempston when set to a single player mode.
OK, suppose not. Though are you thinking of getting away with the same reduced decoding behaviour? :D
It's just some old Kempston-compatible interfaces can't tell the difference between an IN and an OUT, so I wouldn't want to be doing OUT 31 routinely in case one of these was connected. And it wouldn't work with any of the clones with a dodgily decoded Kempston port built-in.
A fresh start might be best, even if it means extra address decoding.
OK, suppose not. Though are you thinking of getting away with the same reduced decoding behaviour? :D
Well that's one thing I guess. The main thing is compatibility with scores of existing games. In other words you would just need an 8 port joystick adapter to play everything, rather than that to play your new game, and a regular kempston for everything else :D
A fresh start might be best, even if it means an extra address decoder.
Full decoding is trivial really, the main annoyance is routing all the address lines :)
I've been sort-of working on an interface on and off that includes an IDE controller and boy does that chew through I/O pins quick! 8 Joysticks will be even worse, so I'm puzzling that one out in my head at the moment. (diodes on all the switch lines doesn't look so bad right now! :p)
You can still use port 31 (1F) for input, you just have to use a different port for stick selection.
Also about joysticks having a common bus - bad idea due to many reasons. In addition to the reasons already listed: have you considered those that have an auto-fire feature? They use the common as 0V and often use a separate pin for +5V. It would be fun seeing what chaos plugging one of these in would have!
As to the number, anything above four joystick or controller inputs is going to become increasingly impractical IMHO. I'm all for a flexible expandable design. But cost has to be taken into account given the small market for such a device.
The Atari STE had two extra multifunctional joystick/controller ports added to it. It kept the existing Atari 9 pin D connector ports. But even though lots of STEs were sold, there are not many games that use the extra ports.
! 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 :)
I'm confused by how a "normal" atari joystick works.
Does it switch the 0v line through to it's outputs? So you need to put a ground on the 0v/common pin and let the joystick pull the direction lines down?
What happens on an autofire joystick if you don't supply it with power?
Well just because something is an extensible specification doesn't mean you have to implement a 256 port joystick interface obviously. :p
Four ports is probably the maximum that it's reasonable to do cheaply enough.
What you could do, assuming the board has a through port, would be to make sure it ignores an IN if the OUT didn't address one of the joystick ports (so 0-3 for a 4 port interface and anything else the board doesn't return anything)
The magic comes if you add dip switches to select higher bits for the joystick number, because then you could chain boards together for ever more inputs. Obviously you'd have to jumper them appropriately to prevent collision but since approximately zero people are ever going to want to implement this I don't think irritating manual jumpering matters ;)
An Atari compatible joystick port uses 0V as common and yes, each switch "grounds" the direction/fire line. So the "interface" pulls up the input lines to +5V with "pull-up" resistors.
The effect with an auto-fire circuit varies depending on how it is wired. Most use pin 7 for their +5V supply. If this is not present, it does nothing (as you would expect).
But some appear to get some power through the fire button connection. Sometimes this can cause strange effects depending on the interface plugged into the Speccy.
I forget now the effect on some older "Kempston" compatible ports, where they use +5V on the common pin (pin7).
! 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 :)
Comments
I meant that one modified interface would still respond to 0x001F, obviously if two were plugged in then they would both respond and there'd be a collision.
I didn't realise that IN a,(n) only sets the low address byte, I assumed the other bits would all be reset, my bad.
Putting a switch to go between "normal" and "extra joystick" would be do-able, as would adding 8 dip switches to select which extra line should be considered if any. It would need mounting somewhere of course and it suddenly becomes enough of a hassle that it's easier to just build a new board :sad:
Hacking the kempston to watch an extra line is only a case of using one of the unused OR gates and wiring it to the appropriate address line. It does mean cutting a track or leg on the chip but not terribly drastic.
If I was to build a prototype 8 port kempston would you prefer to select joysticks by setting a particular address bit, or by decoding the address down so 0x021F reads port 2?
The latter would require an extra IC but possibly makes the code to read inputs easier?
On the other hand, the former allows you to do the same trick as with the speccy keyboard if you want to wait for any fire button to be pressed to start a game for example. Just read all joysticks OR-ed together.
I could get the parts and build a prototype interface in a couple of days if you like!
If using one bit high or low each is easier to build in hardware (as in one-bit 'decoding') then that's fine. A fully-decoded number invites a ridiculous number of joysticks.
If you are going for a decoded literal number, then you could build the board with DIP switches to set a few more bits of the Joystick IDs on that board, so you could daisy-chain them if you really were mad. God knows how many joysticks you could actually power off a single Speccy though. You wouldn't all be able to all get around the TV.
You might also want a switch to say, ignore the decoding and just return the state of Joystick #1 for all IN 31 reads, for compatibility.
But don't do anything at the moment just for me. I wouldn't know what to do with that many inputs. As I said, I have an idea for four joysticks (two players, twin-stick control) but I can do that with a modified Sinclair-type interface. I still feel that'd be the most common way of getting four sticks in there (at least, on a +2). But I think you're right, any more than that (daisy-chaining hacked interfaces) isn't worth it compared to a dedicated board.
It wouldn't look even slightly strange for a Speccy multi-player game to try to support a load of different joystick protocols.
- IONIAN-GAMES.com -
256 basically, the board would have to be enormous to fit all the joystick port headers let alone the decoding logic :)
A 256 port joystick interface could have an external power source so that wouldn't be the limiting factor. I can't believe even you could make a playable game with 2048 separate inputs though ;)
Yup, I was thinking about that in the car earlier, it should be simple to have a switch to disable the upper addresses and at the same time hard wire Joystick 0 on so it behaves like a standard kempston.
Ok, well I'll keep mulling it over, I think I more or less have all the elements worked out in my head so I'll design a circuit and post it up for comments but leave the soldering iron switched off until you come up with an idea that needs 8 joystick ports :o
What I meant was, you could make a vertical board with just two or four ports on its top edge and an extender out the back. Let's say it had four ports, numbered 0-3. That only uses two bits out of the 8 that make up our joystick identifier (0-255). You then have DIP switches to set the higher 6 bits for the joysticks on that board.
So one board has sticks 0-3, then you can plug in another board and set the switches so it becomes sticks 4-7, another for 8-11, etc. You stack as many as you want. Or you could design a parent board with the main connector and a power input, then a simpler daughter board with more common connectors that you can stack to add ports.
Whereas if it's the fixed 8-way interface with one bit per stick, it makes more sense to just do it all on one big flat board; it'd just make the track layout more fiddly.
You could always build the flat 8-way board based on the 0-255 protocol anyway, and leave both an expansion port to the rear and an unpopulated spot to attach either a DIP or jumper header, for fixing the top 5 bits of the joystick IDs. Neither should then really add to the cost of the resultant board; it'd just make the track layout more fiddly.
Well, as I said, I can think of using two extra ports. Two players with a twin-stick setup (or a console-style stick with extra buttons). But then I can hack an existing DK'Tronics / IF2 interface with a single crossed wire to get around the 128K's port $FE isolation.
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
Although I've seen some kempston style interface schematics online that allow for 2 fire buttons the standard seems to be the 4 direction buttons + the fire button mapped to the lower 5 bits with the upper 3 bits of the byte hardwired to 0.
It would be simple to construct a circuit that output the data from 1 of up to 8 joysticks in a round robin fashion while adding the number of that joystick to the top 3 bits of the data byte.
From the spectrum side you would just do normal kempston style IN 31 commands.
If there were 3 joysticks attached
The first IN 31 executed would receive the data from the first joystick identified by bits 5 to 7 being set to 000
the next IN 31 executed would receive the data from the second joystick identified by bits 5 to 7 being set to 001
the next IN 31 executed would receive the data from the third joystick identified by bits 5 to 7 being set to 011
and so on for as many joysticks as are attached, (as there are only 3 attached in this example the next IN 31 would receive the data from the first joystick again.)
It would make it easy and fast from the software point of view. Which will be important if you're coding a multiplayer game.
You could perform a simple loop to test for how many joysticks are present at the start of the game for example.
And if a normal kempston interface was used instead the game would detect only the one joystick as bits 5 to 7 should always be 0.
Maybe set aside a port now that you could write to with an identifier 0-255 as data, then read back an 8-bit digital input from. That way you have a universal input multiplexer that you could use for as many joysticks, keypads or buttons as you like. Perhaps set aside outputting '0' to then read back an interface identifier code (which itself is > 0), so you can auto-configure if you recognise it.
And at the same time, reserve another port for 8-bit encoded analogue inputs.
That's instead of occupying a new address for each controller; though it would mean the interface is more complicated as it would have to latch the active controller line following an I/O WRITE. But then you really won't run out of addresses.
I guess you could do the same with port 31 (or 55), if you knew there was a smarter joystick interface attached. But it's risky, as some of those old interfaces can't actually tell between IN-31 and OUT-31.
But I do come back to thinking that four joysticks is enough to be getting on with, for now. And I'm quite pleased to find out that K-55 doesn't clash with ZXI!
- IONIAN-GAMES.com -
I was assuming that in a game the input handling routines would go in a specific order ie: test for input from player one, process that. test for input from player two, process that etc like a keyboard scanning routine. In that case the automatic cycling would save time because you wouldn't have to change port address etc. In fact, thinking about it, could you set up a jump offset type of routine that uses the joystick input byte as the offset for a relative jump. That might save some time. :-)
No that wouldn't work would it as there would only be a couple of bytes for code between some of the joystick directions.
- IONIAN-GAMES.com -
The game would test for how many joysticks there were at the start. then you would always know where you are. Or less the code jumps about doing IN 31's at random.
OK, maybe using 0 as a query/response code for a joystick interface identifier is a bad idea, as it would be too awkward to apply with simple logic circuitry. Just use a WRITE on a particular ZXI address to latch a joystick (or any 8-bit switch input device), then a READ to get its data. You'd need at least 9 bits of decoding, if not all 16, to detect the ZXI address properly. An address that minimises the decoder chips you'd need overall would be best. ;)
- IONIAN-GAMES.com -
Good point :-) A switch would be needed for each joystick socket or a phototransistor maybe to automaticly detect if the joystick is there. Or a simple push button infront of each socket to turn it on and off. That way you can leave the joysticks plugged in all the time and just select the ones you want to use before playing.
You could have a red and green LED for each socket red it's off green its on.
Every interface needs at least 1 LED :D
- IONIAN-GAMES.com -
Not sure quite what you're thinking with the logic of it, but the simplest from a hardware perspective would probably be to OUT a joystick number, then an IN to read the bits from that connector, and you could poll each joystick like this.
Alternatively if that takes too long then you could incorporate Basher's idea of reading ports in order. Tell the interface how many sticks you want to read with the OUT, then repeated INs to read each input in turn.
Err - that's exactly what I mean. You need to latch the number that's sent OUT. You'd only use as many bits as you need though (3 bits for 8 sticks). If someone asked for stick #9 and they got the results for #1, so be it.
I guess if there were only 8 sticks and you had an 8-bit latch you could choose to do the latching either before or after the number was decoded.
But then an IN just triggers the latch to output its stored data, and that in turn triggers one of the joysticks to put its data on the bus.
And the side-effect is, if you're only providing one joystick through this scheme, you don't need to listen for the OUT at all, as you have no switching to control.
- IONIAN-GAMES.com -
EDIT: just re-read and that's what you were saying :oops:
That means that if you OUT a joystick number, then wait 10 seconds before doing the IN you would still read the actual joystick input rather than the state at the time you selected the joystick. I know that's a silly scenario, but it means you could use the interface to take input from a particular joystick for some period, then switch to another etc and only have to do OUT, IN, IN, IN, IN, IN rather than OUT IN OUT IN OUT IN etc. That would be useful for turn based game where you don't have to pass around a single joystick for example :)
What I would suggest though is a bus receiver/buffer chip between the speccy and all the joystick ports otherwise it's likely to go haywire when you plug loads of joystick cables in :)
But I don't see the problem with scaling that up. I mean, each joystick port would have to have its own buffer chip to put its data onto the bus, triggered by the latched joystick selection on an IN instruction. What's likely to go wrong with that scheme?
- IONIAN-GAMES.com -
If you only put 5v on the selected joystick port and left the others high impedance so all the other sticks are dead then you could in theory just feed the data bits straight into the speccy.
This obviously would be a bad idea, but if you fed those inputs via a buffer that is only active during the IN that would be perfectly adequate, I don't think there's a need for each joystick to have it's own buffer chip unless I'm missing something.
That said, you could do away with the demux and just use the 8 bits as the 8 select lines. This would mean you'd have to use shifted numbers in the software rather than just being able to set a stick by it's binary value.
On the plus side you would be able to read all sticks simultaneously for "press fire to start" type reads. (think how you code a "press any key" on the speccy if you don't care what key is pressed).
Probably far more coding effort than it's worth having to use bit n to select joystick n, but I'm just throwing out ideas here :)
As for linking all the joysticks' outputs together, you'd at least need a load of diodes or you'd get all sorts of matrix effects from your neighbours pressing different diagonals.
And an extension of this is a second port address for doing the same but with 8-bit A/D analogue inputs.
- IONIAN-GAMES.com -
Is there a reason you couldn't build an interface like this using port 31?
If you make sure the joystick select register holds 0 following a reset this means that the player 1 joystick will work as expected with any game using kempston joystick (unless it does something silly and does an OUT) and any game using this scheme will work with a real kempston when set to a single player mode.
Finally there's the added bonus that you will be able to use joystick controlled printer software... ok now I'm just being silly ;)
Drat, I didn't think of that. Phantom diagonals/fire indeed.
Oh well, again, if using a CPLD it's no problem because you have buckets of IO which can be gated through easily.
It would soon get cumbersome and expensive using individual logic chips if you needed 8 bus receivers etc :)
OK, suppose not. Though are you thinking of getting away with the same reduced decoding behaviour? :D
It's just some old Kempston-compatible interfaces can't tell the difference between an IN and an OUT, so I wouldn't want to be doing OUT 31 routinely in case one of these was connected. And it wouldn't work with any of the clones with a dodgily decoded Kempston port built-in.
A fresh start might be best, even if it means extra address decoding.
- IONIAN-GAMES.com -
Fair point, I forgot about things having built-in kempston ports.
Full decoding is trivial really, the main annoyance is routing all the address lines :)
I've been sort-of working on an interface on and off that includes an IDE controller and boy does that chew through I/O pins quick! 8 Joysticks will be even worse, so I'm puzzling that one out in my head at the moment. (diodes on all the switch lines doesn't look so bad right now! :p)
Also about joysticks having a common bus - bad idea due to many reasons. In addition to the reasons already listed: have you considered those that have an auto-fire feature? They use the common as 0V and often use a separate pin for +5V. It would be fun seeing what chaos plugging one of these in would have!
As to the number, anything above four joystick or controller inputs is going to become increasingly impractical IMHO. I'm all for a flexible expandable design. But cost has to be taken into account given the small market for such a device.
The Atari STE had two extra multifunctional joystick/controller ports added to it. It kept the existing Atari 9 pin D connector ports. But even though lots of STEs were sold, there are not many games that use the extra ports.
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 :)
Does it switch the 0v line through to it's outputs? So you need to put a ground on the 0v/common pin and let the joystick pull the direction lines down?
What happens on an autofire joystick if you don't supply it with power?
Four ports is probably the maximum that it's reasonable to do cheaply enough.
What you could do, assuming the board has a through port, would be to make sure it ignores an IN if the OUT didn't address one of the joystick ports (so 0-3 for a 4 port interface and anything else the board doesn't return anything)
The magic comes if you add dip switches to select higher bits for the joystick number, because then you could chain boards together for ever more inputs. Obviously you'd have to jumper them appropriately to prevent collision but since approximately zero people are ever going to want to implement this I don't think irritating manual jumpering matters ;)
The effect with an auto-fire circuit varies depending on how it is wired. Most use pin 7 for their +5V supply. If this is not present, it does nothing (as you would expect).
But some appear to get some power through the fire button connection. Sometimes this can cause strange effects depending on the interface plugged into the Speccy.
I forget now the effect on some older "Kempston" compatible ports, where they use +5V on the common pin (pin7).
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 :)
Even if a stick tries to power itself through the pull up on the fire pin though presumably it would still be neutered by the ground being taken away.