The Sinclair QL Forum

Yes. If only one network jack needed, you can also drop one of the termination resistors and use a type without switch.
I would wire directly. It's only three wires QLNET, 3.3V, GND - no expansion card in sight. It's not a big deal to remove the wires later, if you prefer a connector.

Q68 add-ons (how likely are they at all?) might not even use the extension bus, but I²C or SER.

BTW Peter

Are we sure that the output is solely sourcing current OR tri-stated? The standard contention check (during the SCOUT phase) is rather dependent upon allowing the line to float when an inactive bit was just sent (the pull-down resisters obviously take care of grounding in the absence of another current source), listening for another station that might be trying to set the line active. If we actually ground the line on inactive, we run in to which station can sink/source the most current as to whether the contention is detected.

Note to self - one small thing we'll need to remember is that the Q68 QLNET output is now active-positive - in the original QL design, it is active negative out of the 8302, before being effectively inverted by that PNP transistor. The 8302 obviously inverts it from what is actually written to pc_tctrl.b7.

martyn_hill wrote:Are we sure that the output is solely sourcing current OR tri-stated?

Yes, we are sure.

martyn_hill wrote:If we actually ground the line on inactive, we run in to which station can sink/source the most current as to whether the contention is detected.

The line is never actively grounded by the QLNET pin, only pulled down by the termination resistor(s).

martyn_hill wrote:Note to self - one small thing we'll need to remember is that the Q68 QLNET output is now active-positive - in the original QL design, it is active negative out of the 8302, before being effectively inverted by that PNP transistor.

Yes, apparently the chip used for the 8302 could not deliver a sufficient highside driver with tristate, so it was done by transistor and separate input/output pins.

Thanks! As we develop this aspect of the project, I guess we should spin-off a new thread...

Hi Martyn,

The Q68 Expansion port connector is not fitted, so you will have to solder a connection yourself.

Here is a simplified diagram of the Q68 QL Network connection:

Warning: Derek's diagram could be mistaken as a partial Q68 schematics - which it is not! Pin numbers and reference designators are wrong for the Q68.

The purpose of my diagram was to show the differences to the QL, making clear it is still the QL schematics. For a Q68 diagram, specific schematics would be better. The above diagram could be misleading.

A few more general points, when it comes to Q68 purchase decisions:

1. Suitable monitor: While the VESA standard resolution of the Q68 should be recognized by a wide range of VGA monitors and DVI converters, the best results are achived with native 1024x768 resolution flatscreens. There is a separate thread to share experiences here:
http://qlforum.co.uk/viewtopic.php?f=20&t=1885

2. Speed: If you are used to emulators, please keep in mind the Q68 is a native 68000-style hardware, not a Gigahertz PC. You can expect the Q68 to be slightly faster than a SuperGoldCard, or similar to a first generation QXL, but not more. The Q68 is further slowed down by using the 256 or 65536 colour modes in 1024 pixel horizontal resolutions. The required memory bandwidth is about 25 to 50 times larger than for the original QL screens - this reduces system speed significantly.

3. Ethernet: This was only tested on a hardware level. Although I had some experience with QL native TCP/IP and ethernet 15 years ago, I can not promise to release driver software for the Q68. It is possible that I do something, but purely as a hobby. Software from me could appear late, or never, or just as a demo. The CP2200 has documentation from the manufacturer, I keep nobody else from writing software.

Speed reduction:

Note that, even if the contention created by video circuitry eats a lot of memory bandwidth, the 256 and 64k colour modes are way easier (and faster) to handle than the original QL modes:

Setting a pixel in mode 4 or 8 means

• pick the word containing the pixel from video memory
• Create (or reference) a proper mask that addresses the proper pixel in that word
• Clear the pixel to black
• OR in a properly shifted color mask
• write the screen word back to video memory

In modes 16 and 33 you simply move the pixel color to the proper place in video memory as a .B or .S. Done.

So speed is always relative - from a programming viewpoint, the 256 and 65535 color modes are way faster than the original modes 4 and 8. Probably even if you take into account that you need to modify a lot more pixels at higher resolutions.

Tobias

Hi Peter,

Peter wrote:A few more general points, when it comes to Q68 purchase decisions:
3. Ethernet: This was only tested on a hardware level. Although I had some experience with QL native TCP/IP and ethernet 15 years ago, I can not promise to release driver software for the Q68. It is possible that I do something, but purely as a hobby. Software from me could appear late, or never, or just as a demo. The CP2200 has documentation from the manufacturer, I keep nobody else from writing software.

That would be a nice challenge, but I guess also a lot of work since everything has to be written from the hardware driver up to the native TCP/IP stack. Unlike those of emulators which more or less wrap onto the host OS's TCP/IP stack.
I hope that enough hardware information will be provided to take on this job. Thanks in advance...

Jan.

Here is complete hardware information:

Start address is $1D000, registers are byte length and mapped longword-aligned, as already mentioned.
To enable ethernet interrupt, write 1 to $1C040. Datasheet of the controller is here:
https://www.silabs.com/documents/public ... CP2200.pdf

It might still be the easiest if I port QLwIP, because that already worked under QDOS Classic on the Q60 with RTL8019. We'll see. No promises.