Extended expansion connector...

[Nasta]

Ok, this is one of those 'been there, done that' topics. Getting more out of the 64-pin J1 has been a MAJOR part of the GF design. OK, I know nothing ever came of it but I put in a whole lot of research and thought into that so let me share my findings:

Signals that were never used:

DBGL - it only has a pullup on the motherboard, it was intended as a control pin for the data bus buffer on a buffered motherboard, without any clear definition of why it would do what it was intended for. To my knowledge, apart from homebrew projects, PCML was the the only one to produce a 4-position buffered backplane box but I suppose that's one of those unseen rarities so there is really no point in supporting this signal on the off chance this backplane used it.
* SAFE

R, G, B - Important note: HSYNCHL and VSYNCH _ARE_ used, notably by GC and SGC to trigger RAM refresh periodically. The initial prototypes of Qubide did not have these passed to the through connector and failed with GC/SGC. For the same reason shorting either of the sync signals on the video output connector will result in the GC/SGC not wroking. VSYNCH is also used as the source of the frame interrupt (20ms), and timing for the PAUSE command. Aurora uses different timings for video yet in order to be compatible must generate 20ms pulses on VSYNCH and 16384Hz pulses on HSYNCHL. In other words, these signals must remain (even HSYNCHL but I'll get to that later).
RGB lines are indeed candidates for output lines. Using them for video conversion is certainly possible though care must be taken because they are very nosiy - they are passed in parallel to the outputs on the video connector so there is a long and convoluted PCB line with no signal integrity measures taken, running the length of the QL motherboard with one end on the J1 connector. A piggyback board for the 8301 or indeed a replacement would be a far better idea, also using them as RGB lines is controversial in a system which is in all likelyhood not going to offer compatible RGB signals on them anyway, since we are designing a new computer.
* MAYBE CONTROVERSIAL

FC0, 1, 2 - As far as i know these are only used internally to the QL to provide the VPAL input that causes the CPU to use autovectoring. Although interrupt acknowledge happens when FC0..2 are all high, the QL only tests for FC0 and 1 being high, which means that FC2 is completely unused. GC and SGC being the usual suspects when it comes to replacing the internal CPU with something else, may require FC0 and 1 and VPAL, but since we are designing a new CPU board, they are never going to be connected to it so these signals can be re-used for something more creative.
* SAFE

VPAL, E - 6800 family interface signals. VPAL is pulled low by logic on the QL motherboard, E is CLKCPU/10, and runs constantly. To my knowledge only the QEP programmer used E and VPAL and I am not even certain of that, IIRC some version suse 6800 PIA chips for IO. E might be used on some RAM expansions to derive a refresh clock. Again, it is profoundly unlikely such a RAM expansion is going to be connected.
EDIT: any 68k CPU above 68010 does not implement 6800 peripheral compatibility, and even if it did it did and ran above 10MHz it would likely not work, so anything 6800 based cannot be supported anyway, hence these can be re-used. On the GF in particular VPAL was left open because it could run with a QL motherboard, so QL motherboard logic would pull down VPAL whenever a high level would appear on pins originally used by FC0 and FC1.
* SAFE

ROMOE - this has to my knowledge only been used on the MPLANE so that a ROM slot can be put on it. Not sure MPLANE actually passes all signals from the discussed set so it's usefulness is questionable here.
* POSSIBLE

EDIT:
IPL02L and IPL1L - to my knowledge only the QL motherboard generates them. However, I would rather not redefine these as IPL0L, IPL1L and add IPL2L, since using the pins directly is not practical. They were actually intended to be used through an interrupt priority encoder and it's actually more practical to redefine them as discrete level interrupts. Also, the QL internally uses only one interrupt level (EXTINTL is routed through the 8302 ULA and geenrates the same level), IIRC level 2?
More on interrupts later.
* POSSIBLE

EDIT:
BERRL - forhot about that one. As far as i could find out this was never used. It is normally used to indicate that a bus device is not responding (not generating DTACKL) and when pulled low will terminate the bus cycle and generate an exception - normally this would result in some sort of error handling code being called. However, none of the OS versions provide for this so depending on OS pulling it low will either crash the QL or do nothing. This signal is pulled high on-board and it permanently remains high. It's most suitable for redefining as a 5V power supply pin.
* POSSIBLE

Signals that are used but should not be:

ASL - It is actually explicitly mentioned in the hardware literature not to use this pin and use DSL instead for everything. However, there are boards that use it to gate data bus buffers, latest I have looked at is the Sandy superQboard. The big question is, does plugging one into a 3-row connector make sense? For the GF I re-used this signal as a 32-bit cycle, since it makes little sense to connect practically all old-style peripherals to the J1 connector, in any case anything made before Qubide and thereabouts.
* POSSIBLE

Signals that have fixed connections:
SP0, 1, 2, 3 - these are all connected to ground on the motherboard. And should probably stay that way.

This gives us 11 possible signals on the standard J1 which could be used differently.

Now, that being said, let's consider what would need a wider and faster expansion bus?
There are really only two possibilities:
1) Enhanced video
2) Fast IO (such as fast IDE)
Adding RAM on J1 makes little sense as it's impossible to make it run really fast like in the case of closely coupling it to the CPU - because trying to get fast signals on J1 is asking for trouble. To an extent doing the same for a graphics card is prone to the same restriction - it will be faster than 8-bit access by a factor of 10 but with added logic and still about half the speed it could be with the same hardware if connected to the local CPU bus. However, with some clever shadowing that can be overcome.
Fast IO on the other hand may not require full 32-bit access, and definitely not a lot of address lines.
ANd what would require more address lines but not necessarily speed or a wide bus? The only thing would be something like a large flash memory. Problem being, it's likely going to be 3.3V so again probably not feasible. Also, whatever is in it will benefit from being copied into RAM, and this immediately points to rather storing the contents on a mass storage device.
Also - a 32-bit bus MUST use either byte select lines or separate byte write lines, this in itself takes up 4 signals on the bus.

Finally there is the issue of signal integrity. This is not obvious and has less to do with signal termination and even ground planes, and everything to do with signal return paths.
Most people are not aware that ground planes are NOT used for shielding or power supply primairly, but to offer an automatically optimized return path for each signal running over or under the ground plane. If a power plane is included, it actually also acts as a ground plane, but for the intents of this text, assume there is only one ground plane. When current passes through a PCB line, it obviously has to return to the source in order to complete the circuit. In digital systems, current mostly flows during a change in the signal state either 0 to 1 or 1 to 0. This means it flows in short and very fast peaks. But because a line and it's return path form a loop (and this means inductance) and the procimity of the line to everything else including the ground plane forms a capacitor, you get in the forst approximation a resonant circuit. Actually it's more complex and something called a 'transmission line' is formed. However, the dominant character is inductive, and inductance is actually a property of a circuit to opose the change of current. In other words, it will opose the propagation of the signal in the first place, and the resonant characteristic of the line as such will also provide for ample ringing at the beginning and end of the signal changing state - in other sords, the signal will be corrupt and may indeed corrupt other signals through various coupling phenomena.
The primary mission of a ground plane is to reduce the area the current loop circumscribes. It does this because current always tries to find the path of least resistance, or to be more precise impedance - simplified, impedance is a sort of equivalent resistance of an inductor. Because the inductance of the loop is proportional to the area enclosed by the loop. the smaller this are, the less inductance. In wires, this is done by twisting signal and return wires together or maing coaxial cables, which insures that the signal and return parths are along the same path as much as possible, making the area of the loop virtually zero. A ground plane on the other hand does this by providing an unbroken plane for the return current to find a path on, and it will automatically find one immediately under the related signal trace simply because the resulting loop will be the smallest and the current will flow most easily along that path. In other words, if an unbroken ground plane is provided for the signals on the PCB to find return paths with minimum loop area, they will do so automatically.

Now, I know this is an awfully long text but here is how it is relevant:
Because ground pins on J1 are situated at oposite ends separated by many centimeters of signal pins, even if two boards with perfect ground planes are connected through a mail and female part of J1, they cannot form a uniform ground plane between them. This is because the ground plane has a big hole around all the signal pins. Wen current goes from one board to the other, the signal will pass through the actual pin but the return must go all the way to the closest edge where it will find a ground connection and then back all the way to get under the signal trace. This part forms a large loop, and what is worse, the loops of every signal must pass through the same space so you get coincident loops - which is also known as a transformer. So all signals couple to all other signals electromagnetically around J1 and I think it is obvious that can't be good. It's even much worse if anything magnetic is placed anywhere close to the middle of J1, or the whole lot is in a magnetic material enclosure such as steel.
If there were ground pins dispersed along the length of J1, there would always be one 2-3 pins aeay form any signal in question, reducing the break in the ground plane from one board to the other, and quite drastically reducing loop area, as well as separating loops for signals to the left and right of it. A single ground pin in the middle would already separate thing into two groups of signals and reduce coupling 4-fold, as well as reduce loop area by half (in real world terms this means at least 2x reduction in ringing, or the ability to pass at least 2x faster signals with the same integrity.
GF was designed to have a 3-row connector that actually had practically all of the 3rd row pins connected to ground, which means that there is a ground pin close to every 2 signal lines, providing near perfect ground plane connection - certainly as good as can be done with that connector type.
This sort of thing may well be mandatory to get sufficient signal integrity even for a fast 8-bit bus, never mind a 32-bit bus. Because I wanted to implement a good quality bus in order to run it fairly fast, I actually rather used the entire third row (except for some detect pins) as ground, and thought up a multiplexed 32-bit bus that can run over the regular J1 connector, even though that requires more logic to interface a CPU to the bus. In the case of GF, the 68060 had to have 3.3V to 5V translation done anyway along with dynamic bus sizing (the 68020 has this built in), so all signals had to pass through a PLD - adding the multiplexed option was just a combination of bypass paths around the bus sizing logic so it was very easy to add. Although it's not capable of extreme speeds, it would easily be an order of magnitude or more faster than the original bus, but not trivial to implement on a 68020.

[Dave]

A great contribution, Nasta. Thank you.

Given the very small pool of cards that might be plugged in, and the almost certainty of another QL nearby to use them with, do you think it would be better to just start over from scratch with an incompatible layout? Maybe even consider a different connector type that is more physically compact?

Also, if doing complex things(tm) with the bus is a compromise, is it simpler to just put the plain, unfiltered bus on the connector, but keep the CPU very close to the connector and memory, and keep all the lines really short and clean?

Finally, would someone plug a (S)GC into this board? Or memory? Will anything actually use the VSYNC and HSYNC? I suspect all the usual suspects will already be covered by on-board ports - floppy, IDE, etc. The CPU would also be as fast or faster. Things do get simpler if we specify a limit on the CPU that is targeted. For an example, a 68020 @ 25MHz is around $12 in bulk NOS, but a 68060 is not available in bulk anywhere I can see, and the ones I do see are $80+ and beat up.

That said, I now must contradict myself by saying this extended expansion is not just for us, but for anyone in the community who wants to design expansions or future boards. If they see an opportunity to use an '060, it should be planned for now.

[Nasta]

So, to sumarize:
Here are signals that could be considered safe to re-define:
DBGL
FC0
FC1
FC2
E

As it turns out, we already have 8 bits of data nd 20 bits of address, which means a total of 28 signal lines which can all potentially be IO (although at present address lines are either high impedance, which is exactly what inputs would appear as, or outputs). If only we had 32, now, we could do something with that
The answer is extending the address bus to A23 by using FC0, 1, 2 and E as the extra 4 address lines.
Having 32 signal lines at disposal immediately suggests a 32-bit wide multiplexed bus, and this was one of the major reasons for including it into the GF spec. It offers the most extra vapability with the least change and maximum compatibility to the existing bus. All that is needed are two extra signals to tell the system that a 32-bit cycle is being performed, while leaving the signal DSL in the inactive state so that 8-bit peripherals don't see this cycle happening. The major decision here was to use DBGL as the 32-bit cycle strobe and ASL for the multiplex signal, in order to be able to run (slower) 32-bit cycles over a 64-pin bus/backplane, the cost being only 8-bit peripherals that do not use ASL, as was recommended in the technical and hardware manuals, are compatible.

What about a non-multiplexed solution?
This requires a 3-row connector, but has two serious disadvantages and one not so serious.
The serious disadvantage is a lack of pins if one wants to keep things compatible. The same things apply as for the multiplexed option, basically we have FC0, 1, 2, E, DBGL that we know for sure can be used. Assuming no address extension, we still need 24 more data lines and 4 more data strobes (remember, DSL cannot be used or 8-bit peripherals will respond to 32-bit cycles when they shouldn't), which is already 28 out of the total 32 more pins available. Further, one more ground and one more power line would be a good idea. They may not be as needed for current sourcing as to prevent situations where a 2-row card is accidentally plugged into rows 2 and 3 instead of 1 and 2, so these pins go right over the existing GND and VDD. This leaves only 2 pins unused, and these should be interspersed within the added 32 pins and connected to ground if any sort of signal quality is desired. And this is the first disadvantage - along with these 2, we can only perhaps redefine VPA as ground. It is a far cry from a full row of grounds.
The next major disadvantage is heavily unequal loading on the various data lines - D0..7 being heavily and unpredictably loaded, while D8..31 are probably less loaded as there are only a few peripherals that one could envision using a 32-bit bus. This is of course because all the 8-bit peripherals must use bits 0..7, which are in fact bits 25..31 of the 32-bit bus. This can be a serious problem with getting the 32-bit peripherals to run fast.
EDIT - it should be noted that the multiplexed solution has the same problem. One small thing that aleviates it is that as 32-bit peripherals are added, the loading evens out as every 32-bit peripheral also loads the address lines which double as additional data lines for 32-bit accesses, while this is not so for a non-multiplexed solution - there the only thing loading the extra data lines are 32-bit peripherals.
The minor problem is lack of address space, but since 4 lines can be added for a total of 24, this theoretically gives separate 16 meg address spaces for 8 bit and 32 bit peripherals, which is frankly more than enough.

Regarding interrupts:
The QL links everything to a single interrupt level but this can be rather impractical for some peripherals, notably interrupt driven floppy, hard drives, ethernet, sound. On the other hand, interrupt driven polling (i.e. a periodic interrupt) can actually in some cases simplify and even outperform regular prioritized interrupts - one good example is the Q40/60, as far as I remember this uses a fast poll interrupt running at 20kHz. For the GF I actually thought of a slightly more complex scheme 'somewhere in the middle' that used 6 levels of interrupt, from 2 to 7.
The poll and external interrupt were separated from a single level 2 interrupt to levels 2 and 3.
Level 2: low frequency poll interrupt (20ms) uses pin IPL1L (this lets it be compatible with the QL)
Level 3: low priority IO interrupt, uses pin EXTINTL (ZX8302 would generate both 3 and 2 but this can be handled in software).
4 more interrupts were added:
Level 4: high frequency poll interrupt (generated internally on the board and not visible on the bus)
Level 5: high priority IO interrupt, uses pin IPL02L (which normally generates level 5 anyway). This is fpr peripherals that can require simple and fast service routines, such as emptying or filling hardware FIFOs or buffers.
Level 6: used to manage dual CPU configuration, generated internally on the board
Level 7: NMI, could be generated by a serial port or RTC for debug purposes, again only generated internally on the board.
These were handled by priority encode logic, various hardware interrupt pins could be routed to various levels using PnP sequences to program the SuperIO chip on board.
The exact same approach can be used on a different system, obviously without level 6 and level 7 can be included in the form of a big red button if need be.

[Nasta]

A great contribution, Nasta. Thank you.
Given the very small pool of cards that might be plugged in, and the almost certainty of another QL nearby to use them with, do you think it would be better to just start over from scratch with an incompatible layout? Maybe even consider a different connector type that is more physically compact?

The way I see it, an upgraded 8-bit J1 based on the original spec should definitely be included because it's well known and relatively simple to interface things to. Additions could include higher speed and more address space, though the latter is a bit questionable since it's quite difficult to immagine hat could require say 16 megs of space on the 8-bit bus, given that RAM and possibly flash and video RAM are connected directly to the CPU.

Also, if doing complex things(tm) with the bus is a compromise, is it simpler to just put the plain, unfiltered bus on the connector, but keep the CPU very close to the connector and memory, and keep all the lines really short and clean?

The problem I see here is that one cannot guarantee the lines will remain short and clean when something is connected to the connector. One way to insure this is to limit the actual size of what can be plugged there. And, to be honest, about all you would want there is a graphics card.
So if this option is used, it would have to be a local bus connector, perhaps for a daughterboard (old 68k MACs used this approach, and 99.9% of them got a graphich card in there or a replacement CPU with graphics card).

Finally, would someone plug a (S)GC into this board? Or memory?

(S)GC definitely not. Memory, unlikely, unless its a flash chip but unlikely to be something like 16 megs. An order of magnitude or more expensive than a CF or SD and much more difficult to support in software. Ditto no for 6800 based stuff.

Will anything actually use the VSYNC and HSYNC? I suspect all the usual suspects will already be covered by on-board ports - floppy, IDE, etc. The CPU would also be as fast or faster. Things do get simpler if we specify a limit on the CPU that is targeted. For an example, a 68020 @ 25MHz is around $12 in bulk NOS, but a 68060 is not available in bulk anywhere I can see, and the ones I do see are $80+ and beat up.

Look at what I wrote about the non-multiplexed version. HS and VS are not that problematic and can well be left open etc or provided for an initial option with an 8301 - this may not be such a bad idea as some sort of working system is needed before advanced graphics becomes available.

That said, I now must contradict myself by saying this extended expansion is not just for us, but for anyone in the community who wants to design expansions or future boards. If they see an opportunity to use an '060, it should be planned for now.

Well, that's where the difference lies. It is easyer to make a non-multiplexed bus on the 68020, but 040 and 060 are a completely different problem because one needs a bunch of logic to get the 8-bit bus to work at all due to lack of dynamic bus sizing and 3.3V operation. In nay case bus signals should not be let directly on a bus or forget about signal integrity, so some kind of buffering is required. In the case of the 040 or 060 it has to be some sort of PLD to implement bus sizing (and possibly logic level conversion) and then it's actually equally complex or even simpler to do a multiplexed version, leaving row 3 for signal integrity. On the other hand a bit more complexity in buffering or simple PLDs such as GALs can be used with the 020 to provide the same functionality. Although I'd rather go the local bus route on the 020.

The actual multiplex scheme is based on the fact that certain types of RAM (notably DRAM and this includes Video RAM) can perform cycles that automatically de-multiplex the bus on-fly with no extra logic, while at the same time reducing the number of signals and simplifying routing.
IO stuff on the other hand requires very simple demultiplexing and latching of data anyway so no special precautions are needed to separate the data and address lines, just latching the address in a latch from the multiplexed lines, and passing the multiplexed lines directly to RAM, Flash or IO chip data lines. Multiplexing also at least theoretically supports a 256 meg address range, 28 address bits and 4 byte selects neatly fit on the 32 signal lines during the address phase. Actually on the GF it was 128 meg, the remaining bit could be used to signal burst accesses, increasing the speed by at least 60% for 4-word bursts, all without running the actual signals faster, but the logic for this was never developed, just the spec. It should be noted that GF bus would have been driven to 3.3V levels and would be 5V tolerant. Also - and this is something that really needs to be done - all lines would have series termination resistors.

[Paul]

I would feel much safer with a 100% compatible J1 and a physical different extended bus so no doubt could be what should be connected where.
Kind regards
Paul

[Nasta]

Oh, BTW it is also possible to use the same multiplexed system to implement a 16-bit multiplexed bus, quite substantially simplifying the logic (as address lines A15..A1 and D12 remain non-multiplexed, A0 is not used) but this does run into the unequal loading for bus segments problem.

The multiplexing scheme went like this:
QL D7 = 8 bit D7 = 32-bit BS3/D31 = 16-bit UBS/D15
QL D6 = 8 bit D6 = 32-bit BS2/D30 = 16-bit LBS/D14
QL D5 = 8 bit D5 = 32-bit High/D29 = 16 bit Low/D13 ... selects 32 or 16 bit bus size
QL D4 = 8 bit D4 = 32-bit Reserved,Low/D28 = 16 don't care/D12 ...reserved for burst 32-bit mode
QL D3 = 8 bit D3 = 32-bit A27/D27 = 16 bit A27/D11
...down to...
QL A16 = 8 bit A16 = 32-bit A16/D16 = 16 bit A16/D0
QL A15 = 8 bit A15 = 32-bit A15/D15 = 16 bit A15
...and so forth down to...
QL A2 = 8 bit A2 = 32-bit A2/D2 = 16 bit A2
QL A1 = 8 bit A1 = 32-bit BS1/D1 = 16 bit A1
QL A0 = 8 bit A0 = 32-bit BS0/D0 = 16 bit don't care

BS3/UBS selects data bits D31..24 in 32-bit and D15..D8 in 16 bit mode
BS2/LBS selects data bits D23..20 in 32-bit and D7..D0 in 16 bit mode
BS1 selects data bits D15..D8 in 32 bit mode, these lines should not be driven by the peripheral in 16-bit mode.
BS0 selects data bits D7..D0 in 32 bit mode, again these lines should not be driven by the peripheral in 15-bit mode.
All unimplemented address lines should be driven to a known level (some care should be taken if compatibility is desired between implementations with varying address space sizes), to be determined.

[Nasta]

I would feel much safer with a 100% compatible J1 and a physical different extended bus so no doubt could be what should be connected where.
Kind regards
Paul

Agreed there. Hence the idea of a multiplexed extension to J1 since it IS in fact cramped, but for that the aforementioned 5 lines are enough + different treatment of ASL (the latter can be an option). This makes the J1 work just as before in 99% of all cases, adds some extensions if one wants simple expandability, and yet also offers an upgrade if implemented - if not, advanced cards will simply not work.
Local bus connectors should be different and definitely system specific. Fine if some forward thinking is designed in, but at this point we are talking about the first iteration.

My favorite would be a slightly extended version of the J1 with 4 more address lines on E, FC2,1,0, and possibly a ground on VPAL, and the extended interrupt scheme if only for int 2, 3 and 5. Defining a multiplexed system using DBGL/ASL is possible and simply not implementing it (DBGL=high as in the original QL) renders 32 or 16 bit cards inert if plugged in.
If there is a third row it should mostly be connected to ground, and if possible laid out so that accidental plugging on of a 2-row card into rows 2 and 3 does not cause damage. This can actually be very simply prevented, just put a jumper between two adjecent ground pins, this will act as a stop should someone attempt to plug a 2-row incorrectly. It is also possible to remove certain pins in order to simplu show where the jumper should go. With careful layout a 5V regulated line and say, a high speed clock line as well as a 3-row detect pin can be added (a 3-row peripheral would pull this to ground and then this could be detected by the motherboard). I would actually include this third row on the PCB, so either a 2-row or 3-row J1 can be soldered in as desired.

[Dave]

What existing QL gear would want/need to plug into a QL2?

[Peter]

-> Dave: Isn't it more relevant what future QL gear would plug into it?

-> Nasta: The HF return path length is not what matters for the inductance, but the area encircled by it (and the signal line). If both PBCs have decent ground planes (and I don't see why there would be a large hole in those planes) even a wide connector with far GND pin opens only a small area, as long as it is not deep. For QL style signals I would not consider the connector as deep. I know about Dave's grounding experiment, but that was done with a QL mainboard, not relevant for an upcoming design. Consider the (faster than QL) ISA bus which has similar distance from ground pin to signal pins.

[Dave]

-> Dave: Isn't it more relevant what future QL gear would plug into it?

That's precisely my point.

I'm proposing to extend the QL bus in the most practical way that enables the most future options, while not being a burden on the design or cost of the proposed QL board or future expansions. ALL existing expansions except maybe QEPIII can be summarily dismissed as not relevant for the new machine, which will contain everything traditionally an extra.

It's nice to not have conflict - which is why I made this proposal and let the discussion take its own path. I know some will think it is flawed, but some will be unhappy with ANY proposal that isn't a QL down to the last nut and bolt. At the end of the day, we will end up with something. Something better than we had before. This is the consultation period. I'm seeing the exact kind of detailed proposals I was hoping for.

If you would like to suggest a pin out and spec, and we (all of us) think it's as good as anything we could come up with ourselves, and you're prepared to license it on the same terms as I've given in the first post, you're more than welcome to suggest something.