Q68 compatible peripherals on other QL systems

Nagging hardware related question? Post here!
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 compatible peripherals on other QL systems

Post by Peter »

Silvester wrote:Unfortunately that would clash with SGC/GC: I/O at $1C000-$1C1FF, Eprom is copied to RAM at $10000-$17FFF & $1C200-$1FFFF.
Thank you for this important hint.
Are you sure that $1C200-$1FFFF is not again mapped to the QL bus later?
What is the source of your information?
Silvester wrote:That only leaves QL internal I/O area, and to avoid ZX8301/2, and possibly Qimi, leaves $18100-$1BEFF free for use (via DSMC).
It is not a nice thing to use an area explicitely marked "internal" for the QL. It is unclear how exactly GC/SGC access $18100-$1BEFF. This has probably never been used, and the PLD sources do not exist. There might even be version differences.
Silvester wrote: $18100-$188FF <slot 0> Ethernet CP2200
$18900-$190FF <slot 1> Q68 compatible external I/O (*)
I won't shift address ranges by $100. Also not above $19000. As I wrote, this is start of a Q68 internal 12 KB ROM/RAM area. But we could consider:
$18400-$187FF Ethernet CP2200 (uses only 8 address lines anyway)
$18800-$18FFF Q68 compatible extension bus

Requires that we can make absolutely sure there is no issue with the internal I/O area. Somehow I don't have a good feeling.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 compatible peripherals on other QL systems

Post by Peter »

Silvester wrote:
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).
QIMI does not just occupy those three addresses used by the driver, but every address it gets mirrored to.

I hope to be wrong, but from a very quick look at the picture on Dilwyn's site, it seems like QIMI contaminates lots of the area between $18xxx and $1Bxxx by incomplete decoding.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68 compatible peripherals on other QL systems

Post by Dave »

This:
Attachments
http://www.dilwyn.me.uk/docs/manuals/qimi.png
http://www.dilwyn.me.uk/docs/manuals/qimi.png
qimi.png (9.38 KiB) Viewed 3452 times


User avatar
tofro
Font of All Knowledge
Posts: 2688
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 compatible peripherals on other QL systems

Post by tofro »

Peter wrote:
Silvester wrote:
Peter wrote: I hope to be wrong, but from a very quick look at the picture on Dilwyn's site, it seems like QIMI contaminates lots of the area between $18xxx and $1Bxxx by incomplete decoding.
It doesn't seem to me like this is QIMI's fault, but rather incomplete decoding of the original QL memory done by the 8301 or, in later revisions, the HAL. QIMI uses /PCEN && A10 as a base address. To me, it seems like the 8302 would occupy the complete area (maybe, depending on what exactly happens in the 8301 and/or HAL) anyhow and QIMI just steals 1024 addresses from there by intercepting /PCEN.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 compatible peripherals on other QL systems

Post by Peter »

Yes, but there is the remark "omitting requires address decoder... also assert DSMC" which led me to the assumption that some QIMI devices have that incomplete decode also.


User avatar
tofro
Font of All Knowledge
Posts: 2688
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 compatible peripherals on other QL systems

Post by tofro »

Peter wrote:Yes, but there is the remark "omitting requires address decoder... also assert DSMC" which led me to the assumption that some QIMI devices have that incomplete decode also.
I'd rather think that means "you can leave the red part away" (not relying on /PCEN), "but then you need to replace this with an address decoder" (which can be a good one or a worse one, but hopefully is a proper one).

You apparently still need to intercept PCENL in order to not have it answer to that full address range.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 compatible peripherals on other QL systems

Post by Peter »

Let me rephrase what needs to be decided soon. Will the Q68

(A) have it's external 8 Bit bus within the QL external I/O area $1C000..$1CFFF, namely:

$1D000-$1D7FC Ethernet CP2200
$1D800-$1DFFC Q68 external extension bus connector

Or (B) should it be moved to the QL internal I/O area $18000..$1BFFF, namely:

$18400-$187FC Ethernet CP2200
$18800-$18FFC Q68 external extension bus connector

Obvioulsy, (A) is the natural way, taking the official QL documentation seriously. (B) would be to work around a Gold Card compatibility issue, so future QL extensions in Gold Card systems could share drivers with Q68. It would be step forward to know:

1. Does the Gold Card actually not access $1D000-$1DFFC externally after it has completed the boot process?
(This is not obvious. The Gold Card logic might "detach" it's ROM after it has done the job.)

2. Are the future QL extension cards likely to be used with Gold Card - and would they actually work well in the QL internal I/O area?


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Q68 compatible peripherals on other QL systems

Post by Silvester »

Peter wrote:Are you sure that $1C200-$1FFFF is not again mapped to the QL bus later?
What is the source of your information?
I did a disassembly of v2.49 EPROM: The first 32K of Eprom is copied to $10000-$1FFFF (TK2, FLP, PAR etc), the following 15.5K of Eprom is copied to $1C200-$1FFFF (contains all the routines called from the patched OS ROM), then all the patching is done. Just download v2.49 from Dilwyn's site. $C000 of Eprom is placed at $0C000 ROM port. If you do quick disassembly of the first few hundred bytes from $C000 you'll find the code which does the copy.
Peter wrote:It is unclear how exactly GC/SGC access $18100-$1BEFF. This has probably never been used...
Well I did. I placed 8255 PIO for PAR device on a GC QL, and it worked fine. Also have extensively used Aurora's EXIO area ($18100-$1BEFF) on SGC.
Peter wrote:QIMI does not just occupy those three addresses used by the driver, but every address it gets mirrored to.
hope to be wrong, but from a very quick look at the picture on Dilwyn's site, it seems like QIMI contaminates lots of the area between $18xxx and $1Bxxx by incomplete decoding.
I did the diagram from a rough hand-drawn circuit from QImi PCB supplied to me by by Dennis Briggs/Terry Harman. Apparently they didn't have much luck getting one working external to QL PCB. I did. I also supplied Nasta with same info and he implemented Qimi on Aurora. Yes of course it contains a lot of incomplete decoding, but you don't need them, you can just decode what you need ie. just three address - or a 256 byte area (as I did, and quite obviously Nasta).
Peter wrote:Yes, but there is the remark "omitting requires address decoder... also assert DSMC" which led me to the assumption that some QIMI devices have that incomplete decode also.
Yes, that is my comment. The diagram is copy of Qimi which sits on ZX8302 and intercept pin. I did the part in red to show what you don't need if you make one external - just provide your own decode as suggested.


David
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 compatible peripherals on other QL systems

Post by Peter »

So are you sure $1C200-$1FFFF is not hardware-mapped to external usage again by (S)GC after booting/patching is done?

You said that you extensively used $18100-$1BEFF for external hardware on GC, but was it also tested without GC? Obviously that's not possible with Aurora.


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Q68 compatible peripherals on other QL systems

Post by Silvester »

Peter wrote:So are you sure $1C200-$1FFFF is not hardware-mapped to external usage again by (S)GC after booting/patching is done?.
Yes. The code at $1C200 is needed to exist because ROM patching of OS points there.
Peter wrote:You said that you extensively used $18100-$1BEFF for external hardware on GC, but was it also tested without GC? Obviously that's not possible with Aurora.
I have also extensively used the $18100-$1BFFF area on Trump card (where I also implemented first DIY external Qimi!).
Last edited by Silvester on Wed May 03, 2017 11:23 am, edited 2 times in total.


David
Post Reply