General Stuff(tm)

[rubber_jonnie]

I can't recall, did you replace the drive belt(s) and clean all the drive pulleys etc?

Yes, I refurbished all of that first.

I was sure you would have. Very annoying these cassette decks, my Atari 410 works for saving and loading basic, but not commercial cassettes...

It was horrible to change the belts on.

[stephen_usher]

It's probably some analogue magic which isn't working any more.

[rubber_jonnie]

It's probably some analogue magic which isn't working any more.

Very probably. Does it have a tone control? IIRC that was always the key component in making my tapes work correctly BITD, could it be a failure of the analogue magic there?

[stephen_usher]

It's probably some analogue magic which isn't working any more.

Very probably. Does it have a tone control? IIRC that was always the key component in making my tapes work correctly BITD, could it be a failure of the analogue magic there?

No, it's just got a volume slider.

On the PCB there are just capacitors (ceramic and electrolytic) and resistors plus this one chip marked "Orion 1001012", which seems (from Internet searches) to be also a Toshiba amplifier chip.

(https://venieris.com/%CE%97%CE%A7%CE%9F ... xtSearch=*)

[rubber_jonnie]

Very probably. Does it have a tone control? IIRC that was always the key component in making my tapes work correctly BITD, could it be a failure of the analogue magic there?

No, it's just got a volume slider.

On the PCB there are just capacitors (ceramic and electrolytic) and resistors plus this one chip marked "Orion 1001012", which seems (from Internet searches) to be also a Toshiba amplifier chip.

(https://venieris.com/%CE%97%CE%A7%CE%9F ... xtSearch=*)

Sounds like the IC then...

[stephen_usher]

While I'm waiting for things to arrive I thought I'd try something different...

The Sinclair QL doesn't have a diagnostic ROM at the moment so I'm trying to create one. Unfortunately lost of push back on the QL Forum with people saying that either it's pointless as if the custom chips are broken there's no point going further and anyway Minerva has a RAM test and others saying, "oh, maybe we should make an FPGA system which can plug into the expansion port?" which would cost a lot of money.

My project is for a system ROM replacement, in the same manner as the Amiga DiagROM.

Anyway, at least under an emulator I've got as far as booting, running a memory test of the bottom 128K (own address and march tests), (probably) sending information out of the serial port and then printing information on the screen.

ScreenShot.jpg (155.89 KiB) Viewed 356 times

It should work with a minimum of the CPU, ZX8301 partially working, i.e. clock generation, DTACK control and address decode and the ZX8302 merely being able to output serial data.

The next part will be an initial IPC test, then I can read the serial port if that passes and also assume that the keyboard hardware is working well enough to not break things if I read it. At that point I can create a menu for the full tests (to be written).

[stephen_usher]

I've uploaded the initial code to Github. https://github.com/stephen-usher/Sincla ... l-Diag-ROM

I may get some more time to get more done today.

[rubber_jonnie]

Very neat, nice work

[stephen_usher]

I'm now stumped by the IPC (keyboard/RS232 receive/beep) processor communication.

To say that the "documentation" is fragmentory is an under estimate.

As far as talking to the hardware to send the commands to the IPC and receive data from it, so far, talking on the QL Forum etc., the response has basically been, "Read the source Luke!" pointing to cryptic m68k assembler which describes the mechanics of what the code is doing but not the intent. In other words I've actually got no understanding of the process, especially as the code I've seen seems to use a few "neat tricks" for optimisation. Not helpful.

Then there are the commands themselves, which the QL Technical Manual warns are not error checked and if you get them wrong can "lock up the computer". (This would only be the case if the OS/code doesn't have a timeout for data receive.)

Only three of these are documented in the technical guide. There are more listed elsewhere but they don't give any of the parameters. When people have asked in the past it's been a case of, "Why don't you read the disassembly of the IPC source code on the Dilwyn repository?", which again is quite unhelpful.

*IF* I get this working I'm going to write an easy to understand PDF with all this information in it. But at the moment it's a *BIG* if.

[rubber_jonnie]

I'm now stumped by the IPC (keyboard/RS232 receive/beep) processor communication.

To say that the "documentation" is fragmentory is an unser estimate.

As far as talking to the hardware to send the commands to the IPC and receive data from it, so far, talking on the QL Forum etc., the response has basically been, "Read the source Luke!" pointing to cryptic m68k assembler which describes the mechanics of what the code is doing but not the intent. In other words I've actually got no understanding of the process, especially as the code I've seen seems to use a few "neat tricks" for optimisation. Not helpful.

Then there are the commands themselves, which the QL Technical Manual warns are not error checked and if you get them wrong can "lock up the computer". (This would only be the case if the OS/code doesn't have a timeout for data receive.)

Only three of these are documented in the technical guide. There are more listed elsewhere but they don't give any of the parameters. When people have asked in the past it's been a case of, "Why don't you read the disassembly of the IPC source code on the Dilwyn repository?", which again is quite unhelpful.

*IF* I get this working I'm going to write an easy to understand PDF with all this information in it. But at the moment it's a *BIG* if.

Good luck!!!

Not a very good response form the QL forum it seems