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: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).
I don't know what you mean. The decoder equation given in the picture has no accurracy of 256 bytes. If actually used for external QIMI, it would contaminate a much wider 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:
Silvester wrote: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).
I don't know what you mean. The decoder equation given in the picture has no accurracy of 256 bytes. If actually used for external QIMI, it would contaminate a much wider area.
No because its orginal Qimi (gotta log off library now...)


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 that decoder equation was not used in any external hardware?


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Q68 compatible peripherals on other QL systems

Post by Nasta »

Peter, the schematic posted is of the original QIMI, which is driven by the PCENL line of the 8301 ULA (plus HAL chip in later motherboards), which in turn decodes things very partially (tons of aliasing throughout $18000..$1BFFF).
However, both the QL stuff and QIMI code only uses the first 256 bytes (or less) at $18000..$180FF (QL) and last 256 bytes at $1BF00..$1BFFF (QIMI). This is well tested on both real and clone QIMIs and Aurora.

I'm still a bit unclear as to how you use $18000..$1FFFF on Q68. In principle, $1C000..$1FFFF was never defined so various boards can use this as they see fit. Is there a possibility to use that area for the internal RAM/ROM of the Q68? That way the $18000..1BFFF remains an IO area and can then be partially predefined amongst different systems.
BTW GC/SGC definitely pass through accesses to $18000..$1BFFF to the external bus, not sure about the parts of $1C000..$1FFFF that it uses for it's own on-board IO as there is only a few addresses. I think this was a carry-over from the trump card...


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 »

Nasta wrote:However, both the QL stuff and QIMI code only uses the first 256 bytes (or less) at $18000..$180FF (QL) and last 256 bytes at $1BF00..$1BFFF (QIMI).
Again my point: The text in the schematics proposes to decode using A19..A14, A10, A6, A1 in an external QIMI. That does not only select it for the first and the last 256 bytes!

Are you saying that all external QIMI are not implemented as the text proposes, but use more address lines instead?
Nasta wrote:This is well tested on both real and clone QIMIs and Aurora.
The question is, what has been well tested? Obviously QIMI and QL internal registers do not collide. Also a few I/O registers were used in the $18000..$1FFFF area without collision, but that could have been area snippets which are not selected by the proposed equation, or just internal QIMI overidden by DSMCL.
Nasta wrote:In principle, $1C000..$1FFFF was never defined so various boards can use this as they see fit. Is there a possibility to use that area for the internal RAM/ROM of the Q68?
No, it is much too late to change that. The QL documentation defines this as "external I/O", and that's exactly what the Q68 uses it for. I could only change the Q68 extension bus connector and ethernet areas as detailed in my previous post - they are not yet used by much software. Normally I wanted to have fixed this last weekend already.
Nasta wrote:That way the $18000..1BFFF remains an IO area and can then be partially predefined amongst different systems.
The QL defines and uses this as "internal I/O". It was never meant for external devices at all. I have my doubts, now to do the opposite, and place all new external devices right where they were never meant to be. Mind you: This is only a potential workaround for Gold Card leaving no I/O space in the "external I/O" area. It is not needed for the QL itself, the Q68, or Dave's new CPU card.

As I still have doubts about the QL internal I/O area, I tend to leave:
$1D000-$1D7FC Ethernet CP2200
$1D800-$1DFFC Q68 external extension bus connector

The worst that could happen: If a new QL extension is made that wants to re-use Q68 drivers, and if that QL extension requires the Gold Card, the base address in the driver software would have to be changed. As long as register offsets are the same, not a large effort.


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 thread is about information sharing of Q68 hardware details to ensure compatibility of future systems.

Maybe we need to collate a database of all the locations every bit of hardware uses? This is less of an issue for the Q68, which has limited expansion potential in its current form. However, developments using it as a platform may result in problems for those on other platforms. So...

Would a database be useful?


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 »

Silvester wrote:No because its orginal Qimi (gotta log off library now...)
Wasn't able to complete the sentence in my last post 'cause timer expired at library and I was being logged off.
Peter wrote:I don't know what you mean. The decoder equation given in the picture has no accurracy of 256 bytes. If actually used for external QIMI, it would contaminate a much wider area.
No it doesn't because the decoder suggested was bare minimum needed to implement Qimi address space externally (with similar incomplete addressing). Of course if you wanted to use other I/O areas (ie. $18100-$1BEFF) you would need to implemented finer decode, that's up to the designer (eg. Aurora I/O area).

You don't need PCEN in decode, but you do need to pull DSMC high (with fast transistor) to deny decoded area to QL.

BTW If you had an internal Qimi fitted and you wanted to use spare internal I/O area ($18100-$1BEFF) then pulling DSMC high would disable PCEN and thus internal Qimi from its incomplete/unaccessed address areas.


David
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?.
Silvester wrote:
The code at $1C200 is needed to exist because ROM patching of OS points there.
Anyone can prove it themselves by simply listing where the patched Trap vectors point. Just boot up to JS/Minerva (not SMSQ/E) and run this:

Code: Select all

10 FOR trap=0 TO 15
20 PRINT HEX$(PEEK_L(128+trap*4),32)
30 END FOR trap

My machines with v2.49 =

Trap  Gold Card   Super Gold Card
#0     $0005A     $1C2B2
#1     $1C4CC     $1C434
#2     $00D78     $1C2C4
#3     $00E5E     $1C2D6
#4     $00F26     $1C2E8
#5     $001E4     $1C2FA
#6     $001E6     $1C30C
#7     $001E8     $1C31E
#8     $001EA     $1C330
#9     $001EC     $1C342
#10    $001EE     $1C354
#11    $001F0     $1C366
#12    $001F2     $1C378
#13    $001F4     $1C38A
#14    $001F6     $1C39C
#15    $001F8     $1C3AE
For some reason SMSQ/E doesn't use the 15.5K area at $1C200 in its slice allotment (only $10000-$17FFF).

I should also point out that the first 64 bytes (at least) of $1C200 appear to have some shadowed hardware. It is used for RTC chip protection, unless the bytes at $1C200, $1C238, $1C220 are accessed in that strict order (in Supy mode/Ints off!) you can't write to RTC. Any other access to that area locks out RTC write.

Here's some old notes I made about SGC/GC address map:

Code: Select all

For both GC mark 2 (red) & SGC using EPROM v2.49
================================================

SF $1C064 pages in the EPROM
SF $1C060 pages out the EPROM

=======================================================
Gold card
=======================================================

EPROM paged in
--------------

Read  $0000-BFFF         reads OS ROM    $0000-BFFF
Write $0000-BFFF         writes GC RAM   $0000-BFFF

Read  $C000-FFFF         reads EPROM     $C000-FFFF
Write $C000-FFFF         no useful action

Read  $1,0000-1,7FFF     reads GC RAM    $1,0000-1,7FFF
Write $1,0000-1,7FFF     writes GC RAM   $1,0000-1,7FFF

Read  $1,C200-1,FFFF     reads GC RAM    $1,C200-1,FFFF *
Write $1,C200-1,FFFF     writes GC RAM   $1,C200-1,FFFF

Read  $4,0000-4,FFFF     reads EPROM     $0000-FFFF
Write $4,0000-4,FFFF     no useful action

EPROM paged out
---------------

Read  $0000-BFFF         reads GC RAM    $0000-BFFF
Write $0000-BFFF         not allowed

Read  $C000-FFFF         reads ROM slot  $C000-FFFF
Write $C000-FFFF         no useful action

Read  $1,0000-1,7FFF     reads GC RAM    $1,0000-1,7FFF
Write $1,0000-1,7FFF     writes GC RAM   $1,0000-1,7FFF

Read  $1,C200-1,FFFF     reads GC RAM    $1,C200-1,FFFF *
Write $1,C200-1,FFFF     writes GC RAM   $1,C200-1,FFFF

(* v2.28 EPROM uses area RAM at $1,C100-1,FFFF)

=======================================================
Super Gold card
=======================================================

EPROM paged in
--------------

Read  $0000-FFFF         reads EPROM     $0000-FFFF

Write $0000-BFFF         writes SGC RAM  $0000-BFFF
Write $C000-FFFF         no useful action

Read  $1,0000-1,7FFF     reads SGC RAM   $1,0000-1,7FFF
Write $1,0000-1,7FFF     writes SGC RAM  $1,0000-1,7FFF

Read  $1,C200-1,FFFF     reads SGC RAM   $1,C200-1,FFFF
Write $1,C200-1,FFFF     writes SGC RAM  $1,C200-1,FFFF

Read  $40,0000-40,FFFF   original OS ROM $0000-FFFF

EPROM paged out
---------------

Read  $0000-BFFF         reads SGC RAM   $0000-BFFF
Write $0000-BFFF         not allowed

Read  $C000-FFFF         reads ROM slot  $C000-FFFF
Write $C000-FFFF         no useful action

Read  $1,0000-1,7FFF     reads SGC RAM   $1,0000-1,7FFF
Write $1,0000-1,7FFF     not allowed

Read  $1,C200-1,FFFF     reads SGC RAM   $1,C200-1,FFFF
Write $1,C200-1,FFFF     not allowed

Read  $40,0000-40,FFFF   original OS ROM $0000-FFFF
Edit: amended GC/SGC table
Last edited by Silvester on Mon May 08, 2017 2:11 pm, edited 2 times in total.


David
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: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?
Perhaps, given the potential SGC/GC clash on absolute addresses, wouldn't it be just sufficient to ensure the hardware layout (I/O register offsets within addressed area) is consistent and the base address is held in config block ('Q68'/'QL' toggled option?). If you provided unequivocal identifier on Q68 it could even be done automatically - if ident not found assume QL base address for driver. Any future machines would also provide ident, absence is to always assume original QL.

All the drivers I have ever seen use a base register (usually set in one simple LEA xxx,An, RTS routine). Nothing is ever addressed directly (MOVE.B D1,$xxxx), apart from OS.


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 »

Silvester wrote:Of course if you wanted to use other I/O areas (ie. $18100-$1BEFF) you would need to implemented finer decode, that's up to the designer (eg. Aurora I/O area).
Exactly! It is up to the designer, and the text in that picture is a suggestion for such a design, NOT to implement finer decode.
That suggestion might have been followed - how can I know?
Silvester wrote:You don't need PCEN in decode, but you do need to pull DSMC high (with fast transistor) to deny decoded area to QL.
I know of course, but that's not the point. An external QIMI can not be disabled this way.
Last edited by Peter on Wed May 03, 2017 12:13 pm, edited 1 time in total.


Post Reply