The Sinclair QL Forum

Derek_Stewart wrote:Hi François,

Are the connections to the Network sockets correct?

I checked them when I built the interface, but I will check again. I will order a few BAT43.

Francois

Hm, my money so far is on the socket. But hard to tell as I couldn't find your model anywhere. All similar looking ones had one contact come out on the top, which doesn't seem to be the case with yours.

Cheers, Marcel

mk79 wrote:Hm, my money so far is on the socket. But hard to tell as I couldn't find your model anywhere. All similar looking ones had one contact come out on the top, which doesn't seem to be the case with yours.

Cheers, Marcel

These sockets were very easy to figure out as the bottom is open so you can see what goes where. I am sure I wired them correctly. But to make sure I did the following measurements with the interface removed from the Q68.

If I plug a 3.5mm plug with flying leads into one socket and measure the resistance between the leads I have 330 ohms (because of the resistance of the other socket. Same thing with the plug in the other socket. If I install a plug in both socket and measure between the flying leads of either plug, I have an open circuit (or almost i.e. resistance > 1 MegaOhms). If I remove both plugs and measure the resistance between the signal pins and ground pins, I have 165 Ohms (because both resistances are in parallel). Finally if I measure the resistance between the ground (outer rim) and the Q68 ground pin, I have 0 ohms, showing that I did not reverse the connections.

BTW the sockets I used had their output pins straight, I bent them sideways to be able to use them with my PCB. Maybe this is why you don't find them.

I think that if it is not the diode then something might be wrong with my Q68.

Peter, if you are reading this, is it conceivable that although the Q68 works well, the circuitry associated with the network is broken ? Remember that I had an issue that destroyed both my keyboard and SD card a few months ago. That is why I ask if it would be a good idea to monitor the output of the network pin (without the adapter) to see it behave correctly.

François

Hi François,

Can you tell me what type of socket you are using?

FrancoisLanciault wrote:Peter, if you are reading this, is it conceivable that although the Q68 works well, the circuitry associated with the network is broken ? Remember that I had an issue that destroyed both my keyboard and SD card a few months ago. That is why I ask if it would be a good idea to monitor the output of the network pin (without the adapter) to see it behave correctly.

The LFXP2 is usually more robust than the datasheet specifies. But in theory, only the network I/O could indeed be broken and the rest of your Q68 works well.

What you could do, is to remove your circuit and just apply GND or 3.3V to the QLNET line. Then check if you see bit 0 of PC.MCTRL (at $18020) change accordingly.
Make sure no network driver is loaded, so the Q68 does not attempt to drive the line high while you apply GND!

In retrospective, I regret that I didn't add the few QL network components on-board. It was a compromise to save the time for an additional prototyping round, and get the Q68 released. (Back then, it was uncertain if someone would do the difficult timing stuff needed for the driver.)

I considered designing a little add-on PCB to save folks like you the work, but since the standard case offers no nice place for the connectors, I didn't. There were several ideas of alternative Q68 cases, but nothing except my own design ever materialized.

Peter wrote: What you could do, is to remove your circuit and just apply GND or 3.3V to the QLNET line. Then check if you see bit 0 of PC.MCTRL (at $18020) change accordingly.
Make sure no network driver is loaded, so the Q68 does not attempt to drive the line high while you apply GND!

Hi Peter,

is PC.MCTRL a byte long or a word long (peek or peek_w)

I have checked with nothing plugged and the value of peek(hex("18020")) is 56. I will do the test with wires tomorrow.

P.S. something is strange. The value of peek(hex("18021")) is 68. So the value of peek_w(hex("18020")) should be 14404 (56*256+68). But the value of peek_w(hex("18020")) is also 68...

Derek_Stewart wrote:Hi François,

Can you tell me what type of socket you are using?

Sorry, these sockets were bought at a local electronic shop, so I have no number or spec sheet.

François

Hi,

I used Lumberg 3.5" Jack Connectors: There needs to be a switch on the connector

FrancoisLanciault wrote:is PC.MCTRL a byte long or a word long (peek or peek_w)

Byte, as for the original QL.

FrancoisLanciault wrote:I have checked with nothing plugged and the value of peek(hex("18020")) is 56.

That's correct in inactive state (Bit 0 = 0). When you pull the line high, it should change.

FrancoisLanciault wrote:P.S. something is strange. The value of peek(hex("18021")) is 68. So the value of peek_w(hex("18020")) should be 14404 (56*256+68). But the value of peek_w(hex("18020")) is also 68...

Not strange at all, PC.MCTRL is a hardware register and only for byte wide access. Hardware registers don't always behave like RAM.