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:If you provided unequivocal identifier on Q68 it could even be done automatically - if ident not found assume QL base address for driver.
I was already looking for a good definition of such an ID here:
http://qlforum.co.uk/viewtopic.php?f=2&t=1894

Seems like most saw this as matter of operating system ROM. No established hardware method seemed to exist. Do GC/SGC have something?


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: ..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?
No, it never was meant to, the text in the picture is how to replicate decode of original Qimi (warts and all). It was assumed anyone who was able would know it was the basis to work from.
Peter wrote:An external QIMI can not be disabled this way.
Of course, but that's the problem for who ever implemented one externally (I assumed DIY). If they subsequently wanted to add something that might compromise their design, it's their problem. Apart from Aurora, the only ones I've seen are internal copies using PCEN, which would react to DSMC.
Last edited by Silvester on Wed May 03, 2017 1:10 pm, edited 1 time 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:Do GC/SGC have something?
Yes, SMSQ/E is careful to avoid a 'Gold' :

Code: Select all

; loader tables
mod_table
        dc.l    sms.base-4,$4000         ; first slice
        dc.l    $4200-4,$c000            ; second slice
        dc.l    $10020-4,$17d00          ; third slice (avoid 'Gold')
        dc.l    0
Though I don't know what may use it.


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 »

Could you explain what you mean? Does the Gold Card have the letters "GOLD" somewhere in hardware? Or just in EPROM?


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:Could you explain what you mean? Does the Gold Card have the letters "GOLD" somewhere in hardware? Or just in EPROM?
Not in hardware, but something copied from Eprom to $17D00. I'll have to look at disassembly (done back in 2001). I think it may be something only for Gold card v2.28. IIRC SGC firmware v2.49 was not done by TT (as was GC), but in-house, which I don't think went down very well.


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 »

I had look at earlier v2.28 disassembly (Gold card 68000 only version) and I can't see anything that would copy a 'Gold' marker to $17D00-$17FFF, just code routines. I'd need to look at closely at SMSQ/E sources to figure out what the comment 'avoid Gold' meant in hwinit_asm. Though I did go through all of SMSQ/E Gold setting up process a few years ago and don't recall any other reference to it.

You easily figure out if running on GC/SGC: page in Eprom and look for 'Gold' text at offset $000A. (Assumes that Trump card, the only other thing using $1C000 area, won't be upset by $1C064/60 page control access).

BTW I noticed v2.28 Gold card firmware exploits ram starting from $1C100 (GC/SGC v2.49 only uses it from $1C200).


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 »

Dave wrote: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?
AFAIK it was only with the advent of the 768K Trump card that area at $1C000-$1FFFF was used for I/O. Up until then anything on expansion connector used top 256K area $C0000-$100000. Any locations used for I/O would have been relative to the base of their 16K 'slot' (SP0-3), so nothing gained from documenting them.

Since only the Trump card, Gold card/Super Gold card use $1C000-$1FFFF. I would think only documentation is needed for proposed $18100-$1BEFF usage.


David
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 »

On the subject of detecting CPU, is there a method of detecting the currently used bus width by the OS? The CPU does this transparently to the OS, so is there a way for it to find out?

Have we made any progress on the location of the ethernet and expansion port both in terms of logical address, and of byte or LW access?


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

Re: Q68 compatible peripherals on other QL systems

Post by tofro »

Dave wrote:On the subject of detecting CPU, is there a method of detecting the currently used bus width by the OS? The CPU does this transparently to the OS, so is there a way for it to find out?
Nope, at least not intrinsically. That is transparent to code running on the CPU.

In case you have no CPU cache and relatively accurate timers, you can do a series of .B, .W and .L memory transfers in a tight loop. In case all 3 have roughly the same timing, you are on a 32-bit bus. If .B and .W is the same, it's a 16-bit bus, and if .B is fastest, you apparently are on an 8-bit architecture. Note this is also different between the CPUs of the 68k family.

And, obviously, any further complications like cycle stealing from peripherals or otherwise contended memory might further complicate matters.

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 »

There was a small change of Q68 extension bus signals. A signal "QLNET" was added, which implements physical QL network, if some minor components are added externally (two resistors and a clamp diode). For that pupose, one address pin had to be removed.
Q68ExtensionBus.jpg
Currently the Q68 extension bus base address is in the QL external I/O area. Should future Q68 compatible peripherals prefer the QL internal I/O area, the driver software must support a different base address. This seems trivial, as long as the register offsets are the same.

The Q68 8-Bit extension bus will be longword aligned.


Post Reply