The Sinclair QL Forum

Hi, are there established or recommended methods to detect a QL (or QL compatible) machine by hardware, and not just by the operating system?
Like checking a hardware register, or similar? I would like to let the Q68 follow existing methods, if there are any. Thanks!

Peter,
to my (faded) knowledge, only the Thor series of CST computers used to have some sort of hardware identification. CST/Dansoft implemented this to support node-locked licensing of software. Obviously, it could also be used to distinguish Thors from other QL-likes. Psion XChange, for example, didn't run at all if it couldn't find the computer identity. Modern versions of XChange have had this check removed, however. I also think the Ritzaus software used this to derive a node identity from.

How exactly this worked, however, is beyond my knowledge.

Tobias

There are some flags set in SMSQ/e to mark the machine type - see SMS_MTYP in the QDOS SMS Reference Manual

I seem to think that one of my own toolkits and one of Dilwyn's includes an extension to try and ascertain the system - but can't find it.

I guess SMSQ/E just marks the machine type from knowing its own binary. But here the idea was to provide a hardware check that any OS could use. The CPU is plain 68000, so it doesn't offer much to distinguish the Q68 from a QL or GC for example. Also, in case of further development, it could be nice to see if it is a Q68, or for example a Q68-II.

RWAP wrote:There are some flags set in SMSQ/e to mark the machine type - see SMS_MTYP in the QDOS SMS Reference Manual

I seem to think that one of my own toolkits and one of Dilwyn's includes an extension to try and ascertain the system - but can't find it.

Hi Rich,


I updated the Reference manual last year. You are quoting an out of date link, you should be using:

http://www.wlenerz.com/QLStuff/SMSQE_Guide.zip

The Machine ID is built into SMSQ/E., so I guess when SMSQ/E comes to the Q68... a new machine ID could be programmed in to the Q68 SMSQ/E.

I'm almost certain that C68 has or used to have something in the startup code to determine the cpu in use. As far as I remember it had something to do with stacking A7 and checking the stacked value against A7.

Move.l A7, -(A7)

If the value on the stack equalled A7 then the cpu was whatever, and if it didn't, then it was some other cpu.

Now that we gave lots of cpus in the family, this might not be a great test anymore. I suppose some instructions are privileged on some processors but not on others etc?

Sorry, not much explicit help!


Cheers,
Norm.

Found it.

Thor computers with ROM versions >4.0 implemented a "Watermark" in ROM (basically, the computer's serial number) and a specific system trap that allowed access to this watermark.

4.02. THOR ROM's from issue 4.00 onwards contain both a checksum verification routine, which should guarantee the integrity of the code therein; and a serial number/watermark identifying the machine as a THOR. This can only be checked by using a new trap-call in the extensions to the operating system. No attempt should be made to verify this by direct access to the ROM's as any access to
this area will cause a hardware lock-up of the machine to occur.

Still searching for that specific trap to retrieve the watermark

Tobias

Someone has done work along these lines (detecting the CPU type, which is half of the work you need) but it relies heavily on trapoping the unimplemented instruction vector...
See here:
http://romanworkshop.blutu.pl/asm68/proc.htm

What does Minerva do to initialize the 68020 CPU correctly?

While it is historically interesting to hear about the Thor, that sounds more like a deliberatley obfuscated method used for dongles.

I am not looking for CPU identification. The idea is to maybe provide a piece of hardware that allows to distinguish the Q68 from other machines with the same CPU.

I don't think such a feature is stricly necessary. But maybe nice to have, if sort of a "standard" can be agreed upon.

I considered setting the last byte of the rom to a checkable identifier. It would not be a serial number, just a fixed code representing the hardware I. Use, which could be checked by SMSQ/e.

As we are the only two likely to produce new hardware with a CPU, if we used the same system it would be beneficial to SMSQ/e and more likely supported.