Edge connector through port

[dfzx]

I want to make an interface with a "through port" so another device can be plugged into the back of it. Is the design for that as simple as running 56 tracks from the connector on the front of the board to the connector on the back? No other components or protections required? Is there anything else that might be recommended to install on such a design?

[Guesser]

Is the design for that as simple as running 56 tracks from the connector on the front of the board to the connector on the back? No other components or protections required? Is there anything else that might be recommended to install on such a design?

Yep! Although simple is relative depending how you want to orient the PCB... That's why vertical interfaces are popular as the signals don't have to route through the middle of your circuitry
Whether you want to intercept any signals depends what you interface does. You may for example want to do what Spectranet does and give the option to prevent downstream devices from trapping the ROM by intercepting an address line.
You could perhaps also act as a "fixer" to support older peripherals behind yours when running on a +3

[1024MAK]

It’s wise to use nice wide thick tracks for the 0V/GND and the +5V and +9V power rails.

If your interface/expansion uses it’s own memory in the ROM area of the memory map, you need to think carefully about how other interface(s)/expansion(s) are handled. Do you control one of the address lines or control the ROMCS line (applies to 16K/48K/+ models only)?

Similarly if your interface/expansion uses the NMI, again how this affect other devices.

Also please note that the 128K models have some additional or different signals.

Some signals are of little use by the vast majority of interface(s)/expansion(s), for example the video signals Y, V and U. The composite video signal ‘VIDEO’ is also not used by most devices.

https://sinclair.wiki.zxnet.co.uk/wiki/ ... _connector

Mark

[Guesser]

Do you control one of the address lines or control the ROMCS line (applies to 16K/48K/+ models only)?

Once the peripheral thinks it's going to page in it's too late to do anything about it. If you try to prevent it exerting ROMCS you guarantee a bus collision between it and the ROM. This is why Spectranet (optionally) ties the through port A15 high so that a downstream device doesn't see execution enter the ROM area.
This doesn't help with NMIs but it has a scheme to attempt graceful handling of that too.
One other important thing is to only page in for your own NMI, which is to say that your logic should generate the NMI in response to a button press rather than putting the button across the NMI line itself making it indistinguishable from another device doing the same.

[1024MAK]

Yes, you should never try to prevent another device from forcing ROMCS high. As @Guesser says, you use an address line to do that.

I was thinking more along the lines of preventing your own device from trying to take control if it detected another device forcing ROMCS high. Obviously, the logic for this needs to be sufficiently early to prevent your memory from becoming enabled.

But that does mean that the ROMCS is no longer a simple straight through connection, as otherwise you would mess up the logic of your own memory control circuitry.

Sorry, I was not clear on that.

Mark

[dfzx]

Hmmm, OK, thanks for the input guys, but it's not quite gelling in my head.

My device is an "interface one"-style box, so it provides ROM. As things stand with the prototype, the device permanently asserts the ROMCS, disabling the Spectrum's ROM completely. It provides the normal 16K ROM itself (.e. it emulates the normal ROM using an onboard copy of it) and also "pages in" the 8K IF1 when it wants to (i.e. it continues the ROM emulation job it has by changing the ROM image it's using while the IF1 ROM needs to be "paged in"). This works fine, but it won't work if someone were to, say. plug a Multiface into the back of it because the Multiface will want its own ROM to work.

If a device like a Multiface were to want to page in its own ROM, it would assert ROMCS itself. In order for that to work my device would ... what? It sounds like I'd need to be able to disconnect my ROMCS signal, set my buses to high Z, and allow the Multiface's ROMCS through to the Spectrum? When the Multiface deasserts its ROMCS I reassert mine and take over ROM duties again. Wouldn't that work? I'm not seeing how the address lines you're mentioning are used here or what the extra requirement is.

My device doesn't have an NMI function, so I can pass the NMI signal straight through. It's also 48K-only, so no need to worry about 128K stuff.

[cj7hawk]

You would do it the same as the Interface 1 does.

You always assert ROMCS when you want to run your ROM. If you replace the BASIC ROM you can leave it asserted. Having a copy of the BASIC ROM in your own rom and paging works OK too.

Select your chip via an open collector and a pull-up resistor. Connect this to the external ROMCS.

Then when the MF asserts ROMCS, it will override your ROM-CS and your rom will be deslected just like you do to the Speccy ROM.

And that will HiZ the ROM outputs automatically.

[1024MAK]

Yeah, as @cj7hawk says.

The ROMCS to the computer on your board is connected to +5V, that ensures the ROM internal to the computer is always deselected.

There is no connection between the ROMCS to the computer and the ROMCS to the rear edge-connector on your board.

The ROMCS to the rear edge-connector on your board connects directly to the CS on your ROM (EPROM/EEPROM/flash) plus the control circuit output via either an open collector/open drain output and a pull-up resistor, or a normal logic output, but with a 560Ω resistor in series directly after the logic output (the connection to the ROM and the edge-connector is always after the resistor).

Mark

[1024MAK]

The address lines come into it when you want to prevent an interface/expansion that has memory from being able to page its own memory in. This can also be done by holding MREQ high. In both cases you replace the relevant signal only on the pass through edge-connector.

For example, if A15 on the pass through edge-connector is held high, any additional interface/expansion device will never see the address bus with an address in the ROM area, so will never try to page itself in.

Similarly, if MREQ is held high, on the pass through edge-connector, any additional interface/expansion device will never see any valid memory access from the Z80, so will will never respond as a memory device.

Of course, when I say never, that no longer applies when the logic of your device allows the real A15 or MREQ signal(s) through.

Mark

[dfzx]

Thanks again for the input and clarifications. Being self taught in electronics, these are the sorts of discussions I learn loads from. I need to go away and study.

[cj7hawk]

Thanks again for the input and clarifications. Being self taught in electronics, these are the sorts of discussions I learn loads from. I need to go away and study.

Nothing wrong with that - This is *exactly* how I started too. In fact, pulling out a "Shadow of the Unicorn" dongle that I had modified and explaining it was half of what got me my first job as an assembly language programmer. The other half was explaining what my Vector Graphics drawing routines were doing in some code that emulated aspects of a viking terminal. All of my knowledge was entirely self-taught and I too have asked many questions of others and will continue to do so for the rest of my life - It is an absolutely respectable way to learn.

I ask Mark questions from time to time too. I don't know what his background is, but I don't know of anyone who knows more about Spectrums than he does.

[Guesser]

The other thing to realise is there's no one right answer, there's many ways to skin a cat, and how you design it will depend what kind of devices you need it to be compatible with.
Like people making mass storage interfaces generally just don't bother at all trying to make them work with other similar peripherals because it would be a huge amount of effort for no real point