The Sinclair QL Forum

I think that sometimes the trick to add data register to itself to affect a shift may be done to set flag bits. Without looking it up - not sure what the rotate instruction would do regarding flags.

BaudX4 is literally 4 times the baud rate that's been set - so it's not the output of register ...

This may help a bit futher - from Nasta's write up on the ZX8302:


$18003 WRITE IPC Write:

Controls the IPC communication pin.
* There are several unknowns regarding this location. While only 1 bit is
significant and used to drive the COMDATA line, the masks used by the OS suggest
that 4 bits ...

It's only one bit that really carries any data - and another that's used to signal when comms is ready.

From that other thread - I put up the basic sequence for the really low level side:

75 Send bit to IPC
76 ---------------
77
78 1. ZX start bit (COMDATA = 0)
79 2. IPC clock (COMCTL = 0, COMTL ...

That's the CST unit - CST RAM Plus - it's a 512K memory expansion, plus 4 Eprom positions (upto 32K each I believe - sockets and additional components not usually fitted for these ROM positions) and an additional bay to take another expansion card.

https://qlwiki.theqlforum.com/doku.php?id=qlwiki ...

I'm wondering if you have an unstable voltage - is this machine still running with the 5v regulator? If it is, you could try replacing that - they are not soldered (usually) so it's a just a matter of opening the case, removing the screw that holds the regulator to the heatsink - and then do your ...

I suppose a checksum calculation on the lower 48K coud tell you which ROM might be installed as well.


Well, that's not very useful. Of course, it's going to be the ROM that's just running....


The original post suggested the ROM may be plugged into the ROM port - and potentially called ...

I was looking at your source code - just realised that your ROM is starting at 0h not C000h

I wondered why you had all the exception table in there

The IPC has an echo back test - command, and the random numner one - maybe less useful:

*rand_cmd equ 14 random number generator, returns a sixteen bit number.

*test_cmd equ 15 test, expects a byte, which it then sends back.

Plus you could interactively cheque the keyboard with direct reads ...

That's true Per - that could also work .

The other thing that's possible, is that if you are acting as a ROM and controlling the computer - you could issue code and observe the data bus and the lower 16 address lines to see the result of that, you just wouldn't know what address is actually being ...

The ROM port is active for any address in the lower 64K - it's just that you would need to disable the lower 48K of that to stop the onboard ROM's providing data - since they will also be looking at the ROMOEH line to provide data on the bus. If you could keep this signal low, then you could supress ...