Plea for new hardware
I'm posting this as a poll as I want to judge if I'm a solo loon going on about this, or if people really are interested in either of the following Speccy devices. It seems to me we have amongst us the ability to do both quite readily:
1. A plug-in graphics card, like SPECTRA or Clashbasher, that skims off reads to the video memory into its own screen buffer and generates a SCART-compatible RGB image of its own. The difference is, this one would support the palette-switching and Timex-multicolour functions from the ULA+ specification.
So that it doesn't become redundant when we can actually get internal ULA+ upgrades, it would have the ability (typically by a hardware switch, but maybe via an OUT command) to re-map itself to skim-read from an alternative address, so that it could be used as a second or even third screen. As a minimum it should re-map to intercept reads to the ROM address space, and treat them as if written to the 16K video-accessible RAM. Better would be able to place its screen address at least on any of the first three 8K boundaries (0000h, 2000h, 4000h) allowing up to three normal screens (by stacking devices) or two multicolour screens mapped across the ROM and lower 16K address spaces. (That the ROM occasionally writes to itself is easily overcome by not using ROM routines. But note that this external video RAM is not readable).
It would probably be best if the ULA+ OUT commands that control the cards shifted accordingly, though I guess it wouldn't be a disaster if write-only port addresses were all the same, such that all cards ended up in the same mode with the same palette.
Being able to double-buffer the display (like SPECTRA can) would be a handy trick, but again, not essential as it deviates from what ULA+ will do.
A through-port is essential.
2. A 2-port joystick interface that supports IN-31 and IN-55, for adding an extra two joysticks to a setup that already has 2 Sinclair ports, such as a 128K +2, +2A, +3. Or a single port interface with a jumper/switch to select one or the other protocol.
Again, a through-port is essential.
The first is so that developers can get on and add ULA+ features to games and see the results on real hardware, instead of stumbling over a diversity of devices and varying support across emulators.
The second is so that we can start writing some serious multi-player games like other machines have (i.e. The C64, ST and Amiga have all had additional joystick inputs).
Personally, I have no specific projects which are waiting on either, though I am working on adapting a few old RAM Kempston-compatible joystick interfaces to K-55 and passing them on to developers to get things moving on that front. But the question is, is there the demand in the community? I'm sad to see new gizmos come and go without much support. And yet ULA+ seems to be something people want to support but are still waiting for. Are there things we can come together to support?
1. A plug-in graphics card, like SPECTRA or Clashbasher, that skims off reads to the video memory into its own screen buffer and generates a SCART-compatible RGB image of its own. The difference is, this one would support the palette-switching and Timex-multicolour functions from the ULA+ specification.
So that it doesn't become redundant when we can actually get internal ULA+ upgrades, it would have the ability (typically by a hardware switch, but maybe via an OUT command) to re-map itself to skim-read from an alternative address, so that it could be used as a second or even third screen. As a minimum it should re-map to intercept reads to the ROM address space, and treat them as if written to the 16K video-accessible RAM. Better would be able to place its screen address at least on any of the first three 8K boundaries (0000h, 2000h, 4000h) allowing up to three normal screens (by stacking devices) or two multicolour screens mapped across the ROM and lower 16K address spaces. (That the ROM occasionally writes to itself is easily overcome by not using ROM routines. But note that this external video RAM is not readable).
It would probably be best if the ULA+ OUT commands that control the cards shifted accordingly, though I guess it wouldn't be a disaster if write-only port addresses were all the same, such that all cards ended up in the same mode with the same palette.
Being able to double-buffer the display (like SPECTRA can) would be a handy trick, but again, not essential as it deviates from what ULA+ will do.
A through-port is essential.
2. A 2-port joystick interface that supports IN-31 and IN-55, for adding an extra two joysticks to a setup that already has 2 Sinclair ports, such as a 128K +2, +2A, +3. Or a single port interface with a jumper/switch to select one or the other protocol.
Again, a through-port is essential.
The first is so that developers can get on and add ULA+ features to games and see the results on real hardware, instead of stumbling over a diversity of devices and varying support across emulators.
The second is so that we can start writing some serious multi-player games like other machines have (i.e. The C64, ST and Amiga have all had additional joystick inputs).
Personally, I have no specific projects which are waiting on either, though I am working on adapting a few old RAM Kempston-compatible joystick interfaces to K-55 and passing them on to developers to get things moving on that front. But the question is, is there the demand in the community? I'm sad to see new gizmos come and go without much support. And yet ULA+ seems to be something people want to support but are still waiting for. Are there things we can come together to support?
Post edited by joefish on
Joefish
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
Comments
Providing that there is a through port, interface I/microdrive and Multiface 128 compatible then I'm a happy bunny.
Cost?
Keep up the great work Jason.
Download the latest version of Bomb Munchies Ver2210 4th July 2020
Both ideas are just the sort of crazy thing I would build "just because I can".
- IONIAN-GAMES.com -
McLeod_IdeaFix's plug-in ULAplus is on the back burner while he works on ZX-Uno. But on the plus side, ZX-Uno is going to support the Chloe 280SE. And if you've got money to burn you can order this keyboard for it from WASD Keyboards:
:p
Depends on the joysticks being waggled.....
That keyboard looks very professional but why is 'colour' spelt wrong on it as its meant to be a KB replacement for a British machine and therefore should be written the correct way for authenticity.
Maybe someone who's built one could say for sure, but would an external video device even work on a 128K? If so, then, like SPECTRA, it's going to need 32K on-board in two 16K chunks. It can then listen to the 128's own page-swapping OUT port and, if it hears that page 5 or 7 is paged in, then it can start listening for writes to the upper RAM and replicating them in the appropriate bank. It would also listen to the bit that controls whether to display the normal or the shadow screen. I guess it wouldn't be a disaster if this behaviour wasn't specifically disabled when plugged in to a 48K Speccy. But you'd have to sacrifice your upper memory to exploit it.
As for when it's set to act as a second-screen and mapped over the ROM; then, like SPECTRA, it would need its own OUT port to control which bank to write to, and which one to display. But here you can add another trick. Instead of just one jumper on the board to set this mode, have two or more, so you can tell it it's board A, B, etc. Then the top bit (or bits) of the OUT control word could say which board you're commanding. And if you command, say, board B to listen to writes and channel them into its Bank 0, then board A knows to stop listening for writes. Then you can stack two or more boards to add extra displays. (Though you may need a way to add an external power supply if you get carried away).
As for hi-res mode, well, the ULA+ spec does actually say you don't have to support everything, and as a game developer I could live without it. Though don't let anyone use that as an excuse not to at least try!
- IONIAN-GAMES.com -
Sounds like a fairly easy project.
One XC9536XL should be capable of doing the (partial) address decoding for both port 31 and 55, and passing inputs of 2 joysticks.
With partial I mean that for almost all games that use Kempston joystick, it's enough to decode IORQ, RD, A3, A4, A5, A6 and A7.
I'm not sure about port 55 however.
It would barely take a much larger pcb than my current Kempston Joystick interface, as the XC9536 is a lot smaller than a GAL:
And it wouldn't cost that much extra either.
http://www.worldofspectrum.org/forums/showthread.php?t=45303
I did send a message on your site about it - I wondered if you could just do the port switch with a jumper or something, so you could daisy-chain those mini interfaces you make.
There was some long discussion about port addresses and device compatibility I can track down and link to if you like, but there were a couple of good reasons for settling on port 55 and no obvious problems.
The main advantage was that you could easily modify an old interface from IN-31 to IN-55 by exchanging the A3 and A5 address lines. Or in most cheap decoder schemes, simply cutting the A5 pin and jumping it from A3 instead. Address 55 (00110111b) sets the A5 pin high and the A3 one low, so it doesn't clash with Kempston (00011111b), but leaves the other pins in the same low/high pattern as Kempston, in case you're re-purposing an interface that was a bit more selective in its decoding.
The +D interface uses port #EF, so would clash with something using A4-low. There were other reasons for not using A1 or A2 low, and A0 is obviously a bad idea, but I can't remember all the reasons right now.
Obviously no-one's going to manufacture an interface if there are no games to use it, but no-one's going to write games for interfaces that don't exist either! That's why the purpose of choosing IN-55 was to make a home-made interface easy to start with, then look at production once games (like Bomb Munchies) appear. Don't forget it's also ideal for two-player twin-stick shooters or tank games!
It's the same thinking really behind making an external graphics card that at least supports ULA+, rather than re-inventing.
- IONIAN-GAMES.com -
Ah yes, we've spoken about it.
At that time I thought there wasn't that much interest in it, and I still have my hands full.
But I am planning forward, and am expecting to have some more time in a month.
Furthermore the response to this topic gave me the idea that there is indeed more interest.
But, is port 55 a new port then?
If it is, and the dual port interface would be sold, people expect that current multiplayer software would work with that too.
Wouldn't it be better to use a combination of 31 and Sinclair 1 joystick or something?
Interfaces that use the keyboard input port don't work on the +2A/+2B/+3 and I think Joefish wants a standard that is compatible with all ZX Spectrums...
So if you have a 48k Spectrum or 128k toastrack, you can use a Interface Two for Sinclair joysticks 1 and 2 (keys 1 to 0) and a port 31 & port 55 joystick interface to enable a system with up to 4 joysticks.
Or if you have a +2/+2A/+2B/+3, add a port 31 & port 55 joystick interface to enable a system with up to 4 joysticks.
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 :)
If you just want to add two ports to a 48K Speccy you're already spoiled for choice - there are plenty of old Sinclair or Kempston+Sinclair devices knocking around on eBay for that.
The idea was always a two-port interface to add two MORE ports, for four joysticks. There wasn't really any other standard that worked (Fuller clashes with everything under the sun, including Kempston, and key-substitution is out) so a new one was needed.
I guess there may be a market for a two-port Sinclair 1+2 joystick interface for 48K Speccys (that could then be daisy chained with a Kempston+K-55 two port interface) but I'd rather see the new one for use with +2s first. I assume that making one interface with interchangeable behaviour is too hard, since the Sinclair ports (a) invert their bits and (b) actually have different bit ordering for the two sticks.
There is a bit of hassle with compatibility with the RAM Turbo (which has a through-port) and the Kempston Pro interface (with its 3 ports) as whilst they support Sinclair 1 & 2, they have an annoying habit of returning Kempston signals AS WELL. To use in a 4-joystick system, they'd have to be modified to stop the Kempston response.
- IONIAN-GAMES.com -
That's a feature inherited from the Timex.
It's 99.9% finished. There's an issue with LOADing and SAVEing via the audio IN and OUT. There's an audio expert involved in the ZX-Uno project so I'm hoping when that's done he can sort out the 0.1% of the plug-in ULAplus and it can be made available.
If you're using some other storage method then it's good enough now:
It's much more fun for hardware tinkerers to dream up their own stuff than implement designs other people have come up with. If we were all working towards the same goal then all new devices would use ZXI ports and all graphics cards would support ULAplus as the baseline standard. Fortunately ULAplus is already the de facto standard for new clones, even Russian ones, and ZXI is gaining ground.
Yes. At one point Winston was considering building an external ULAplus for the Amstrad machines and calling it Spectra. He said as much quite a while before the other SPECTRA was released. The plug-in ULAplus should work fine on ULA-based 128s. A different approach would be required for the ASIC-based machines.
I wouldn't use any jumpers at all. There are plenty of spare ports in the ZXI range to support doing it all via I/O calls.
I don't think many people are going to use hi-res mode, but SE Basic IV (which will run on a 128 with a full ULAplus) provides an 80x24 text mode using it that's much nicer for doing text based things.
It's spelled that way because the Chloe 280SE prototype was derived from the Timex 2048 and that's how they spell it. Also, it's only a sticker so you can leave it off entirely if you want.
Kempston Joystick Interface with extra Joystick port 2ep by 1024MAK
Note that this is almost fully decoded, but not quite fully decoded.
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 :)
Personally I'd ditch the +5V supply and use that line as FIRE-2 as well, so you can use the red wire in Quickshot leads as FIRE-2. And there's the risk that some sticks, when supplied with 5V, can crash the Spectrum by grounding it through a button press. Maybe the +5V supply could be optional, a jumper again to connect pin7 to either +5V or to the FIRE-2 returns from pin5+9?
- IONIAN-GAMES.com -
And actually, now I think about it, an external version of ULA+ goes hand-in-hand with an internal version, perhaps for people that really aren't sure about opening up their Speccys. No need for it not to be done, whatever the schedule for actually producing the internal version.
- IONIAN-GAMES.com -
I'm trying to work up a multicolour scrolling and sprite engine to support plug-in mini-games for four players, so you just have to code the game engine; all the graphics routines and control menus are done for you. The idea is that you can load as many 4/8/16K game engines as memory will allow, and a central controller can randomly select from them between rounds.
If anyone is interested in a RAM Mk2 interface, hacked to work as K-55, drop me a PM as I have a couple spare I got in a bundled lot that I was going to meddle with - I'll see if I can get round to it this weekend. There's a genuine flat Kempston interface in there too somewhere, but that needs cleaning and a new 9-pin socket fitted. I'm afraid I can't guarantee anything though.
I've got some DK'Tronics Kempston/Sinclair interfaces I was going to look at converting, but that's a longer job. I originally got them to shift the Sinclair port to another row of the keyboard, then I thought about going from IN #FE to IN #EF, but now I'm looking at turning it into K-55. Looks possible though. They use +5V on one stick and 0V on the other so the Sinclair bits come back inverted. Set them both to use the same common wire, move the address lines, and re-map the Sinclair bits by re-routing some diodes (up and down are wrong anyway) and job's a good-un. Probably less work to build one from scratch really, but I'm not into making my own PCBs. And at least it'd have a fancy case. Still no through-port though.
I've also got a bit of 3-pin strip-board to make one, which I was then going to graft over the top of a DivIDE as a dedicated +2A all-in-one box for shows.
- IONIAN-GAMES.com -
Also, there's no way you can adapt an old interface to do the necessary decoding.
But if you've got a specific reason why #37 will clash with something important, please explain it.
But I rather think compatibility with all original ZX-Spectrum models is most critical! :D
- IONIAN-GAMES.com -
Why do you think so? Prove that it is impossible. :)
And to adapt an old Kempston interface, most of them simply looked for one address line (A5) going low. At most they would have checked for A7 (and maybe A6) going low and perhaps A0 being high as well. So you need to pick another address line you can send low, and an actual address number to use that has A7 & A6 low, A5 & A0 high (so it doesn't look like a Kempston or Sinclair read), and doesn't obviously clash with the +D disk interface (which is #EF in the low byte, so you can't use A4 low) and ZXI (which drives A2 low). That pretty much leaves relying on A3 going low, hence #37 (IN 55). It's either that or #3D (with A1 low), but I'm pretty sure that clashes with something else.
Now if you have a better idea that meets all of those requirements, I'd love to hear it!
Or at least explain why you think #37 won't work with Russian clone machines?
- IONIAN-GAMES.com -
Because all exUSSR clones have a built-in Kempston Joystick, simplified decoding which does not allow to distinguish #1F from #37.
If it's about higher bits then we could just pick a different number for reading that has A5 high and A3 low. It wouldn't really change much. But it would be more helpful if you had just explained the bit pattern problem!
- IONIAN-GAMES.com -
/ AAAAAAAA \ \ 76543210 / -------------------------------------------------------------------------------- #1F/31 xxxxxxxx00011111 xxxxxxxx xxxxxxx1 Kjoy(7) - xxxxxxxx xx0xxxx1 Kjoy(D) - xxxxxxxx 0xx11xx1 KjoyPrn(C) - xxxxxxxx 0x0xxx11 Kjoy(6) - -------------------------------------------------------------------------------- 1/+1 - ZX Spectrum(issue 1-2/3-6) 6 - Scorpion ZS256 Turbo+ B - Scorpion GMX 2 - ZX Spectrum +128,+2 7 - KAY-1024SL/Beta Turbo C - Quorum 128/+ 3/+3 - ZX Spectrum +2a,+2b/+3 8 - Pentagon 128(1991) D - Pentagon-1024SL 4 - Timex Computer 2048 9 - Profi-1 (v3.x) (ver. 28.09.2006) 5 - Didaktik Gama A - ATM Turbo-2+ --------------------------------------------------------------------------------Seems to me there's only one type there, 'KAY-1024SL/Beta Turbo', that has a problem. And with only detecting bit A0 then it's completely hopeless - if it works with that then it won't work with a +2A/B/3 and vice versa. It's such a crude decode there really isn't any hope of anything working with it. As for all the others in that list, they WILL read 00110111b as distinct from 00011111b, as they either expect A3 high or/and A5 low when reading Kempston IN-31.- IONIAN-GAMES.com -
This way is unacceptable. You know how in +3, it is locked rd #xxFE?
1/+1 ZX Spectrum/Didaktik Gama 7 Profi+ (v3.x) D Profi 3+ (v5.x) 2/+2 ZX Spectrum 128/+2 8 Pentagon 128(1991) E Pentagon-1024SL v2.2 3/+3 ZX Spectrum +2a,b/+3 9 KAY-1024SL/Beta Turbo F/+F ZXM-Phoenix 5 Baltik B Quorum 128/+ rev0-2/3-5 6 Scorpion ZS256 C Scorpion ZS256 Turbo+ G Scorpion GMX N Novosibirsk 64k #1F/31 xxxxxxxx00011111 xxxxxxxxxxxxxxx1 Kjoy(9) - xxxxxxxxxx0xxxxx Kjoy(4) - xxxxxxxxxx0xxxx1 Kjoy(E) - xxxxxxxxxx0xxx11 KjoyWD1793(C) - xxxxxxxxxx0xx111 KjoyWD1793(6) - xxxxxxxx0xxxx111 Kjoy(F,+F) - xxxxxxxx0xx11xx1 KjoyPr(B) -