The Sinclair QL Forum

That could complicate things. Wouldn't it provide access only to the top byte in each long word? How do you access the other three bytes?

My apologies for my ignorance. You might like to give us a simple primer on how we might do this?

It's an important detail, because I'd like to include a duplicate of this interface on the ethernet card so a common mini-card (Q-card?) could be used on the Q68 and a QL with a little extra planning by the designer. The barrier to building a mini-card is much lower so it is very attractive. It could either require 3v3 and 5v tolerant parts, or I could incorporate voltage level shifter like the TXB0108.

Dave wrote:That could complicate things.

No, it would just waste a little address space. But then 32 Bit data bus CPUs like 68040/68060 which don't have dynamic bus sizing could use the same driver.

Dave wrote:Wouldn't it provide access only to the top byte in each long word?

Correct. But the driver software knows that it is only a byte and would not use long word access.

Dave wrote:How do you access the other three bytes?

Not at all. They wouldn't be mapped to this connector.

Oooh. That's a twist.

The adaption is to map 8 bit devices expansion side across 4x the RAM CPU side. A 2KB footprint isn't a big deal on a 32MB machine, but it could be on an unexpanded QL.

I can see the benefit for Q40/60. Can the CP2200 be added to a Q40/60 via the ISA bus? Is anyone planning new '040 or '060 based hardware?

The proposed area is 2KB inside the 16 KB QL "External I/O" area.

I'm not aware of any wellknown device using this, but I'm requesting feedback here, in case someone can see a conflict.

Yes the CP2200 could easily be added to Q40/Q60 via the ISA bus. They already support existing ISA ethernet cards (NE2000 compatible), so using the CP2200 there would only make sense if a new ISA card is made anyway for other reasons, e.g. SDHC card support.

I'm not aware of specific plans for a new highend machine. Would be more to make things "future-proof". Who knows, maybe you use the 68060 instead of the 68020 someday

After thinking carefully about the 4-byte-alignment question, I have decided I'm for it. It maintains maximum compatibility across all 68k CPUs and FPGA equivalents, and allows for a common driver across all hardware platforms.

The only slight snag is for cases where successive bytes are transferred from a 'memory mapped' buffer, byte accesses with a 4 byte address shift will be needed. Thank goodness for LEA 4(An),An

May I propose the following:
Keep $18000..$1BFFF for byte mapped devices (so the IO hardware expects to be able to use all bytes in this area (devices expect to have A0 and A1)
Use $1C000..$1FFFF for long word mapped devices (IO hardware only uses top byte, address lines A0 and A1 are not used and do not exist on the connector)
Of course multiple IO devices can be further decoded within the same slot provided 2048 or 512 addresses is enough.

A 2k address raster is not a big deal. Strictly the QL IO area is at $18000..1BFFF but since nothing uses $1C000..1FFFF it might as well be extended there. That gives us 16 slots for 'well known hardware', strictly speaking the 0th and 7th are used by the 8301/8302 ULAs and QIMI respectively. The rest is currently not allocated although I would vote for new versions of the Qubide to relocate the IDE registers there and free the full 16k of EPROM for the driver (normally since V2.xx the IDE registers are located in the top 256 bytes of the EPROM space and move with the Qubide base address).

We would need to agree on which 2k slot is for what. So far we have:
Byte addressing:
$18000..$187FF QL original or compatible hardware (originally 8301/8302 ULAs).
$18800..$18FFF Qubide could be here
$19000..$197FF
$19800..$19FFF
$1A000..$1A7FF
$1A800..$1AFFF
$1B000..$1B7FF
$1B800..$1BFFF QIMI (also uses EXTINT line)
Long word addressing:
$1C000..$1C7FF
$1C800..$1CFFF
$1D000..$1D7FF
$1D800..$1DFFF Q68 Ethernet?
$1E000..$1E7FF
$1E800..$1EFFF
$1F000..$1F7FF
$1F800..$1FFFF

Thanks for your comments, Nasta!

Nasta wrote:Keep $18000..$1BFFF for byte mapped devices (so the IO hardware expects to be able to use all bytes in this area (devices expect to have A0 and A1)

That is exactly what the Q68 does. The start of this area for it's own QL hardware compatible registers, and the last 12 KB for internal Flash/RAM, all bytes mapped. Normally, the Q68 would not place this area on it's extension bus and just use it internally.

(Time permitting, I might later design a special Q68 variant which which routes $18000..$18063 to an original QL bus connector. By simple buffers, that would allow to plug the Q68 into a QL and use everything meaningful in there. Since the Q68 has fully QL compatible video, it is probably not required to have more than 6 address lines leading to the original QL. But this is of not much relevance here.)

At first I was considering to include QIMI function inside the Q68 (hardware-generated from PS/2 mouse) which is in conflict with the internal ROM/RAM there. But in the end I decided for direct PS/2 mouse support, because of better pointer movement on large screen, 3 buttons, scrollwheel etc. Having ROM/RAM at $19000..$1BFFF turned out very nice for the loader, leaving a continous 96 KB ROM emluation area starting at $0.

Nasta wrote:Use $1C000..$1FFFF for long word mapped devices (IO hardware only uses top byte, address lines A0 and A1 are not used and do not exist on the connector)

The Q68 uses $1C000..$1CFFF for it's own registers. They are not longword aligned yet. But if I find the time to change all three operating systems plus mass storge drivers, I would like to update that in order to make the logic more "future-proof".

Unless there are objections, $1D000..$1FFFF will become the longword aligned, byte-wide external bus.
Ethernet at $1D000..$1D7FFC, the single chip select area on the connector would be $1D8000..$1DFFC.
A QL CP2200 ethernet card should work with the same software as Q68, if it also starts at $1D000.

Except for QIMI I see no conflict between Q68 and QL in the 2K slots list posted by Nasta.
Probably irrelevant, because the Q68 has it's own mouse hardware and driver.

Does anyone know how exacty QIMI decodes it's addresses?

*** I prepared this before visit to library for internet access, so excuse me if I repeat any of the above (I'll read and digest it later)

Peter wrote: Planned start address is $1D000 for the CP2200 ethernet controller chip select, and $1D800 for the external chip select.
I'm not aware of any wellknown device using this...

Unfortunately that would clash with SGC/GC: I/O at $1C000-$1C1FF, Eprom is copied to RAM at $10000-$17FFF & $1C200-$1FFFF. That only leaves QL internal I/O area, and to avoid ZX8301/2, and possibly Qimi, leaves $18100-$1BEFF free for use (via DSMC).

Aurora also offers this 15.5K area on extended ROM port connector with EXIO signal (similar to your Q68 ext. I/O). Perhaps it can be used similarly for QL/Q68 compatible 2K slot scheme, suggest: * Could do QL bridge board to offer Q68 compatible connector for common board interface (with 3.3V regulator).
** Could be used for QL version of Q68 8-bit stereo sampled sound port with FIFO buffer (any details Peter?), and DS1374 RTC.

Perhaps the 3 unused bytes in long word could be used to provide unique ident that the expansion board exists and its version/facilities (simple pull up/down). ie. Ethernet slot 0 is equipped with CP2200 device (2K Tx/4K Rx buffer), W5100 (8K/8K), or W5500 (16K/16K).

Edited: Changed addresses to 2K boundary (Doh!, its been a while since I did any hardware)

Dave wrote: I have little idea how multiple cards are addressed.

The old way (expansion slots at $C0000-$100000) was to access your I/O relative to the base of card (ie. EPROM). Sometimes by also using next 16K slot for I/O, or by using just a single slot and overlaying end of 16K EPROM space with I/O (eg. PCML Q+ disk interface uses base+$3F80). But see my other post regarding QL/Q68 compatible address space. This new scheme means I/O addresses would be fixed, with driver in RAM (faster and easier to upgrade/evolve). The only tricky one is boot device, QubIDE/ATA at $0C000 is easy solution (like tetroid's TC+).

Peter wrote:Does anyone know how exacty QIMI decodes it's addresses?

Qimi at $1BF9C/$1BFBC/$1BFBE. See Dilwyn's site for my Qimi SCR (also PNG).