Wondering if a "dead test" ROM is feasible on the QL.

[Pr0f]

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 the on board ROM's - but the signal comes direct from the ZX8301 I believe - so it would not like that shorting out.

So that idea is a non starter.

However - it is more than possible to disable any amount of the onboard harware - selectively - using either the BR / BG logic (to place your own proccessor on the bus) - which is what gold and super gold cards do, or to use DSMCL line to block the ZX8301 from decoding addresses in the lower 256K - this is exactly what plug in cards do.

So a plugin card could perform the needed actions to test the QL hardware - and you have the posiblity of outputting the data to any device you want- serial, led's - an OLED screen - even video. It just needs a ROM and some supporting hardware.

[stephen_usher]

Those sound far more expensive to implement than an EPROM and an adapter for the original ROM socket(s).

[pjw]

Forgive my ignorance of QL hardware matters, but wouldnt it be possible to plug in an "active" device, ie something with its own CPU and output possibilities? Raspberry PI based, for example?

[Pr0f]

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 driven by the top 2 address lines (A16 and A17) - except for the fact your code has made that request.

so Perhaps the ROM port idea still has mileage...

[stephen_usher]

Tiny first steps.... My m68k assembler is *SO* rusty! Not done anything in earnest since the late 80s!

I wonder if this will work...

[stephen_usher]

Starting to get somewhere with the ROM now.

Initial 128K memory tests (own address & march tests) not using RAM done and working. Basic string output to serial (probably) and screen working.

Now to figure out initial IPC tests before I can go to a test menu and read the serial port and keyboard for test selection.

[Pr0f]

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:

kbdr_cmd equ 9 keyboard direct read
* kbdr_cmd requires one nibble which selects the row to be read.
* The top bit of this is ignored (at least on standard IPC's...).
* It responds with a byte whose bits indicate which of the up to eight keys on
* the specified row of the keyrow table are held down.

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

[Pr0f]

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

[stephen_usher]

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

Yes, it's replacing the main ROM, as in remove QDOS ROMs and fit an EPROM with an adapter, as you would with Minerva.

[stephen_usher]

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:

kbdr_cmd equ 9 keyboard direct read
* kbdr_cmd requires one nibble which selects the row to be read.
* The top bit of this is ignored (at least on standard IPC's...).
* It responds with a byte whose bits indicate which of the up to eight keys on
* the specified row of the keyrow table are held down.

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

Thanks for this information. Those should be rudimentary functionality tests for the IPC, if those pass then can try to use it for serial port input and bring up a menu. with options to do full tests.

We could probably make this a community effort if people would like to contribute.

As long as the routines save all the registers and restore them before returning it should be safe. I've set up a "system variable" area and the stack is in the lower 128K of RAM which has been tested.

There are utility routines for sending strings to the serial port and a rudimentary screen driver which can position the cursor and write strings (and interpret carriage return and line feed). I'll be finishing off the ANSI compatible cursor positioning routine, CLS for serial and screen and a scroll for the screen. That should be ample for any information display.

I'll look to set up a Github repository, maybe over the weekend.