The Sinclair QL Forum

Pr0f wrote: Fri Apr 25, 2025 7:27 pm
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....

A long time ago. Where I used to work repairing printers, we had some small testers that you plugged into a ROM socket to preform various tests on the printers boards.

It comprised of a small board with a four character, seven segment display, a rotary switch to select a test, a ROM which could be changed depending on which printer model you had. And had one or two other small IC's.

It was maybe twice the size of a Minerva board. You just selected the test you wanted, then powered up the board. The display would report PASS or FAIL. It could test RAM, motors, the control panel etc. And I think one test would drive the data and address lines with square waves.

Like what you are suggesting, this relied on the Processor actually working.

But something like this could be useful on a QL as you don't need to rely on the QL's display working to know a test has passed or failed.

I've uploaded the project onto GitHub: https://github.com/stephen-usher/Sincla ... l-Diag-ROM

The next part of the code will be basic testing of the IPC before doing anything else. As I mentioned before, if any of you wish to contribute test code please feel free. Hopefully this can become the Amiga DiagROM equivalent for the QL.

Hi,


Excellent work on the assembley language routine.

I was thinking the same think, but using PJWs idea of a plugin Arduino or Raspberry Pi board or similar, that could interface withe QL, and use PROFs idea of enabling each specific function of the QL like a sub-circuit, by using BR / BG logic and Address lies to test each function of the QL circuit board.

The advantage if this is the test routines could be written in a higher level language like C.

The diagnostic board could use the main expansion connector, giving access to all the QL board functions.

All diagnostic tools are useful and test things differently. You can't have too many.

An EPROM and adapter are cheap and quick and easy to make, so that's the main advantage.

tofro wrote: Sat Apr 26, 2025 10:58 am

Pr0f wrote: Fri Apr 25, 2025 7:27 pm
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 from the OS ROM - so my comment wasn't that unuseful - you've just made an assumption as did I about where the ROM was running from.

Pr0f wrote: Sat Apr 26, 2025 12:46 pm

tofro wrote: Sat Apr 26, 2025 10:58 am

Pr0f wrote: Fri Apr 25, 2025 7:27 pm
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 from the OS ROM - so my comment wasn't that unuseful - you've just made an assumption as did I about where the ROM was running from.

I really made that assumption in your favour, because: As (as mentioned above) the ROM port ROM on the QL is (different from most cartridge-supporting computers like the Atari ST and C64, for example) enabled very, very late in the boot process, you basically need a fully working QL to be able to execute any diag code from there. A fully-working QL has VER$ to verify the ROM version.....

Code updated, mostly a tidy but also a routine to print to the screen without using RAM, which is used at initialisation and in the memory test error routine.

I need to write an integer to acsii converter library routine for the main code and something to allow printing useful memory test errors.

Patched sQLux so that it outputs the bytes send to I/O-base + 0x22 to stdout so I can verify that the code is sending the right stuff to the serial port.

Some more code updates and reorganisation.

Also cursor control for the serial output and CLS for both terminal and screen. This required the writing of an integer to ASCII conversion routine.

That's it for today. Too tired now.

I've updated Github with the latest changes, but the project is on pause for the next few weeks as I have to work on a display for RetroFest2025.

Having worked out how to include files in vasm I've split everything up and moved the library routines, tests, font data and strings into separate files.

I have a set of maybe working IPC communications routines written and they at least partly work under Qlay3.

Have a look if you're curious.