RFC: ZXI (interface standard for ZX peripherals)
OwenBot
Speccy than ever before, but none of them seem to work together, or
with existing peripherals. For example, divIDE+ flat out refuses to
work with most Kempston joystick interfaces.
Sinclair gave Richard Altwasser about 6 weeks to design the Speccy
from start to finish, so you can't really blame him for not stepping
back and thinking that perhaps full port decoding would have been a
good idea. As a result there are *no* free I/O ports on the Speccy.
To give you an idea of how bad it is, the ULA uses 32768 ports. Most
of the remaining devices (ZX printer, IF1, etc.) use about 8192 ports
each. Poorly implemented Kempston joystick clones use around 16384
ports each. Rubbish isn't it? The upshot is, it's very unlikely that
you can put three devices on the expansion bus and have them all
function properly.
Until now the only solution was to get a Timex (which uses full port
decoding). But there is another problem which that doesn't resolve ...
there is no standard for devices to use to set a priority to page in
their own ROMs.
However, solutions are available to both of these problems. There is a
single address range that only breaks one peripheral (the ZX Printer)
and there is a hardware fix for that problem. This gives a potential
of 256 I/O ports that do not clash with any other hardware. This port
was chosen for use with ULAplus, but that still leaves 254 ports
available. SpectraNet will use four of those ports, but that's still
250 free ports that don't clash with anything. SpectraNet is also the
solution to the ROM paging issue. It uses a dasiy chaining method to
set a priority so multiple devices that page their own ROMs can live
together in harmony (http://spectrum.alioth.net/doc/index.php/
Spectranet_CPLD).
I propose to combine these two methods into the ZXI standard. Devices
that have the ZXI logo (already got one I developed years ago that
will do nicely) will be guaranteed to work together and with a minimum
of one uncertified device (providing it is the last device connected).
Allocation of ports will be by committee. Devices that have the same
function may use the same ports. This should allow for a decent range
of peripherals and reassure buyers that they will all work together.
Comments? Suggestions? Vampire Willow references? :)
Guesser
>
> Comments? Suggestions? Vampire Willow references? :)
no replies yet? that's a bit rubbish, I'd better do one:
mmmmmm Vampire Willow... or something
--
My rubbish website
http://alistairsserver.no-ip.org/
Brian Gaff
landfill?
Brian
--
Brian Gaff....Note, this account does not accept Bcc: email.
graphics are great, but the blind can't hear them
Email: bri...@blueyonder.co.uk
______________________________________________________________________________________________________________
"Guesser" <alis...@alistairsserver.no-ip.org> wrote in message
news:i00f9j$9p4$1...@news.eternal-september.org...
BloodBaz
I am aware of both problems you have stated although I am not that
hardware savvy. I didn't realise that there was a solution to the ROM
clash issue however. Very interesting.
I can't make any suggestions over what you have already stated TBH.
Designers of hardware will need to be the people to get on board and I
can't see why they wouldn't as it is in everyone's interest to do so.
With 250 ports remaining under a full decode, there should be plenty
enough space for everyone for quite a while.
One suggestion I could make is to search out existing, less well known
hardware which might already be using the empty 256 ports under a full
decode so that they can be allocated before it is reassigned to a ZXI
compliant device.
A site/forum will also need to be put together of course.
OwenBot
> I think ZXI is a great idea.
Thanks.
> With 250 ports remaining under a full decode, there should be plenty
> enough space for everyone for quite a while.
Or forever, assuming that devices that do the same thing (for example
IDE devices) can use the same ports.
> One suggestion I could make is to search out existing, less well known
> hardware which might already be using the empty 256 ports under a full
> decode so that they can be allocated before it is reassigned to a ZXI
> compliant device.
http://zxspectrumio.pak21.user.dev.freebaseapps.com/?port=3b
As far as we know, the only device that is called by a write to port
xx3B is the ZX Printer. Because any write to that port is likely to
turn the motor on or print endlessly, it's likely that any hardware
from back in the day avoided that port. That doesn't discount obscure
hardware projects, but unless the creators publish details of them
there's not a lot we can do.
Dylan Smith
> I am aware of both problems you have stated although I am not that
> hardware savvy. I didn't realise that there was a solution to the ROM
> clash issue however. Very interesting.
It's a simple solution - if your peripheral has a through port, just hold
A15 high on the through port whenever your ROM is paged in. This provides
a simple 'ripple priority' scheme where the device closest to the Spectrum
has the highest priority, and the one furthest has the lowest.
This solves the basic electrical problem (two devices now cannot have
a ROM paged simultaneously, because the downstream board will not see
an address below 0x4000 when the upstream board has its ROM paged in) -
and works for things like intializing on reset very well. However, the
rather thornier problem is RST 8 BASIC extensions. Only one device can
have them. Tape traps can be a problem, too - because of this, as well
as the A15 high thing on the upstream device, the downstream device
must *not* latch it's "I'm supposed to be paged in" register until
it sees MREQ go low to high with a valid trap address still on the bus.
I have a feeling the DivIDE at least doesn't do this (tape traps crash
for instance with the Spectranet on the bus, I think when the Spectranet
tape trap exits, the DivIDE then pages in, although I've not really
subjected it to proper analysis yet).
BloodBaz
> On 2010-06-26, BloodBaz <chris.wa...@real-sense.com> wrote:
>
> > I am aware of both problems you have stated although I am not that
> > hardware savvy. I didn't realise that there was a solution to the ROM
> > clash issue however. Very interesting.
>
> It's a simple solution - if your peripheral has a through port, just hold
> A15 high on the through port whenever your ROM is paged in. This provides
> a simple 'ripple priority' scheme where the device closest to the Spectrum
> has the highest priority, and the one furthest has the lowest.
>
OwenBot
that we could have done with it 25 years ago.
Here's the wiki page:
http://scratchpad.wikia.com/wiki/ZXI_interface_standard
In case anyone is wondering, the 'informal advisory committee' is
myself, Dylan, and Chris. It's not a closed shop. Anyone with an
interest in Speccy hardware development can join.
The logo is available as a .SCR file for hardware developers that want
to display it on-screen when their ROMs are paged in.
BloodBaz
> Ok, well I guess there's no problem with the standard then, except
> that we could have done with it 25 years ago.
Except I guess people weren't so prepared to fully decode the address
bus back then :-)
> Here's the wiki page:
>
> http://scratchpad.wikia.com/wiki/ZXI_interface_standard
So, 3B - that's the magic number!
> In case anyone is wondering, the 'informal advisory committee' is
> myself, Dylan, and Chris. It's not a closed shop. Anyone with an
> interest in Speccy hardware development can join.
>
> The logo is available as a .SCR file for hardware developers that want
> to display it on-screen when their ROMs are paged in.
Nice!
george velesoft
> On 2010-06-26, BloodBaz <chris.wa...@real-sense.com> wrote:
>
> > I am aware of both problems you have stated although I am not that
> > hardware savvy. I didn't realise that there was a solution to the ROM
> > clash issue however. Very interesting.
>
> It's a simple solution - if your peripheral has a through port, just hold
> A15 high on the through port whenever your ROM is paged in. This provides
> a simple 'ripple priority' scheme where the device closest to the Spectrum
> has the highest priority, and the one furthest has the lowest.
>
devices. If PROFI use any extra memory instead ZX rom, then set A15
high = external device can't detect access to rom area. Only if IORQ
signal is active then NEW A15 go to original state ( is possible
connect also external PC keyboard interfaces or use additional AY
interfaces ).
OwenBot
Assuming you're using the default ports for AY and keyboard, then your
PROFI interface should be ZXI compliant.
george velesoft
Yes. AY ports use same adressation as original AY on ZX machines.
Profi work with external PC keyboard interfaces correct, but
SPECTRANET can work only with original internal ZX keyboard.
OwenBot
I don't see why that would be the case. Providing that the keyboard
interface is between the edge connector and the Spectranet and uses
only the #xxFE port range, then it should be fine. In fact even if it
was connected behind Spectranet I don't see why it wouldn't work since
no ROM paging is involved.
I will be hooking up a Spectranet and a Proface-AT later this year so
I'll be able to say for certain if that combination works or not.
Trying to IRC on a rubber keyboard is teh suck.
george velesoft
If spectranet memory is connect instead rom then new adress line A15
is set to 1. If any keyboard interface is connect to through ZX bus
connector on spectranet then need original A15 state for possibility
detect keys SPACE,SYMBOL,M,N,B. (port #7FFE is readable only if
SPECTRANET memory is disconnect)
OwenBot
Ok, if that's correct then it would cause a problem, but I'd still
like to hear what Dylan has to say about it. On the other hand,
plugging the keyboard interface in between the Speccy and the
Spectranet shouldn't cause any problems and should enable both devices
to work correctly.
jgharston
halfway
across the country, but is http://mdfs.net/Docs/Comp/Spectrum/SpecIO
any use?
JGH
OwenBot
If there's anything missing you could add it to FreeBase. That data is
used by this to show any potential conflicts:
http://zxspectrumio.pak21.user.dev.freebaseapps.com/?port=3b
It turns out that, apparently, the Didaktik Gamma disk system clashes
dreadfully with port xx3B. However, it's just one of many illegal
clones and, as mentioned in the ZXI standard doc, there are "NO FREE
PORTS". Of the legitimate machines and plug-ins, xx3B clashes only
with the ZX Printer, which is supposed to be on port 0x7B on the
Speccy. The ZX Printer can be modified to work around this issue. On
the Gamma I'd suggest disconnecting the disk system and using
something else.
Dylan Smith
> If spectranet memory is connect instead rom then new adress line A15
> is set to 1. If any keyboard interface is connect to through ZX bus
> connector on spectranet then need original A15 state for possibility
> detect keys SPACE,SYMBOL,M,N,B. (port #7FFE is readable only if
> SPECTRANET memory is disconnect)
That bug has been fixed, A15 now is only held high while a memory
operation is taking place (i.e. /MREQ + /A15 + /A14 while the Spectranet
memory is supposed to be paged in). Otherwise what's on A15 is simply
passed through.
OwenBot
people to discuss it anywhere, but proposals need to be posted to this
thread.
jgharston
> > Ok, well I guess there's no problem with the standard then, except
> > that we could have done with it 25 years ago.
> Except I guess people weren't so prepared to fully decode the address
> bus back then :-)
When I built my centronics printer interface in 1984 and ASCII
keyboard
interface back in 1985 I fully decoded the addresses (Printer on &FB,
keyboard on &F9/FD).
JGH
OwenBot
The partial decoding is a hangover from the ZX80. It was done then to
keep things simple. It could have been sorted out with the ZX81 since
that used a ULA, but it wasn't and then it was considered 'acceptable'
for the Spectrum. It's just crazy that the scheme effectively forces
you to use memory based I/O on a chip with 65536 I/O ports.