Ethernet for the QL

Nagging hardware related question? Post here!
Post Reply
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Ethernet for the QL

Post by Peter »

Hi,

in the past, ethernet for the QL has been discussed here quite a lot. Now that Martin's ethernet driver for the Q68 has arrived, see viewtopic.php?f=3&t=3578, I think it is a good time to provide information and schematic sources here to help others building the equivalent hardware for an original QL. I think it has become practical now - unless all who are interested in ethernet have or want a Q68 anyway.

I chose the CP2200 ethernet controller for the Q68, because it also interfaces very easily to the original QL bus. Firstly, all signals are 5V tolerant. Secondly, it has a non-multiplexed 8 bit data bus, requiring no serialization. Thirdly, it requires only address decoding, no further logic to interface directly with the QL bus. Please find below the priciple schematic, based on the working and tested Q68 circuitry:
ethernet_ql.jpg
Explanations:
  • The CLKIN signal has to be a 20 MHz clock.
  • The /ETH_CS signal needs to be generated by an address decoder, which is specific to the project into which ethernet is integrated. For a stand-alone extension this could be a GAL.
  • The /ETH_IRQ signal has to generate a level 2 interrupt for the QL. There is a specialty here, inasmuch the CP2200 activates the interrupt line on power-up. If possible, it should be deactivated by software before interrupts are allowed for the CPU. If this is not desired, as it requires a (minimal) ROM change, a hardware register should be added in the external logic which gates this signal.
The only change to make the Q68 ethernet driver work for a QL is probably the address space. At least a memory expansion is required for the driver. And keep in mind the QL is a slow machine. Less than a Gold Card system would result in data rates only moderately faster than QL network. If someone wants to design a CP2200 card for the QL, please feel free to ask questions. I think this could also be interesting for Tetroid if he designs new (S)GC clones.

All the best
Peter


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Ethernet for the QL

Post by NormanDunbar »

Happy New Year Peter.

Thanks for that. It looks interesting -- even if it is way above my level!


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Ethernet for the QL

Post by Pr0f »

INT could be gated by a control signal from a flip flop - the flip flop could be reset at startup (cleared by /reset signal from QL) and not allowed until both an access to the CP2200 address range AND the CP2200 INT line being high (in other words a suitable control byte has been written to clear INT status internally within the CP2200) A status read or something similar maybe required after the /INT line is allowed to set the flip flop


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Ethernet for the QL

Post by Pr0f »

I presume a 20MHz crystal could be used across both XTAL lines on the CP2200, or an external oscillator can with TTL output ?


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Ethernet for the QL

Post by Derek_Stewart »

HI,

I wonder if an expansion card could be made for a standard QL, it would probably need sort of ram expansion.

Maybe the Qubide Ram card could be modified to have Ethernet integrated into the circuit board. I say this as the circuit board schematics are available.


Regards,

Derek
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Ethernet for the QL

Post by Peter »

NormanDunbar wrote:Happy New Year Peter.
Thanks for that. It looks interesting -- even if it is way above my level!
Happy new year Norman! That with your level looks like British understatement to me. ;)
Pr0f wrote:INT could be gated by a control signal from a flip flop - the flip flop could be reset at startup (cleared by /reset signal from QL) and not allowed until both an access to the CP2200 address range AND the CP2200 INT line being high (in other words a suitable control byte has been written to clear INT status internally within the CP2200) A status read or something similar maybe required after the /INT line is allowed to set the flip flop
A creative idea! :) I thought of a register with separate address, but this is more elegant.
Pr0f wrote:I presume a 20MHz crystal could be used across both XTAL lines on the CP2200, or an external oscillator can with TTL output ?
Yes, both is possible. On the Q68, I used an oscillator.
Derek_Stewart wrote:Maybe the Qubide Ram card could be modified to have Ethernet integrated into the circuit board. I say this as the circuit board schematics are available.
I'm not sure which exact card you mean, can you post a link maybe?

Ideally, the solution would also allows an (S)GC. I didn't have an idea how this could be done, except with a backplane.


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Ethernet for the QL

Post by Martin_Head »

Peter wrote:The only change to make the Q68 ethernet driver work for a QL is probably the address space. At least a memory expansion is required for the driver. And keep in mind the QL is a slow machine. Less than a Gold Card system would result in data rates only moderately faster than QL network.
The Q68 Ethernet driver also uses the Q68's hardware timer. A replacement timer would not have to tick at exactly the same speed, as the loop counters can be adjusted.

Also, at the moment the driver allocates 256K of RAM as a buffer for the data packets that are read from the CP2200.

As for speed, If you flood the Q68 with UDP data packets. The driver can't keep up clearing the CP2200, and processing the data packets, and will loose some. Peter would know better than me, but I did a quick 'back of an envelope' calculation. And unless I got a decimal point in the wrong place, or made some bad assumptions, If you flood the Q68 with data packets. It will have trouble just keeping the CP2200's read buffer empty without doing anything else.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Ethernet for the QL

Post by Peter »

Martin_Head wrote:The Q68 Ethernet driver also uses the Q68's hardware timer. A replacement timer would not have to tick at exactly the same speed, as the loop counters can be adjusted.
Sorry, I forgot that. A high resolution timer should not be required in principle, wouldn't an interrupt-driven 50 Hz counter be sufficient for your driver?
Martin_Head wrote:As for speed, If you flood the Q68 with UDP data packets. The driver can't keep up clearing the CP2200, and processing the data packets, and will loose some.
That could in theory happen with any machine, so UDP based protocols like TFTP include acknowledge mechanisms. One should simply not flood an UDP endpoint. ;)


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Ethernet for the QL

Post by Martin_Head »

Peter wrote:Sorry, I forgot that. A high resolution timer should not be required in principle, wouldn't an interrupt-driven 50 Hz counter be sufficient for your driver?)
Off hand I can't remember all the places I use the hardware timer. But I know I use it in the CP2200 initialization. And without looking at the source code, I'm not sure if the interrupts are running when I use the hardware timer. I also use the QL's hardware RTC clock (PC_CLOCK is it?) in places. But the hardware timer could probably be worked around.


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Ethernet for the QL

Post by Pr0f »

From a very quick digest of the datasheet for the CP2200, the places where a timer may be required:

Waiting for initialization after clock stabilized - this could be done simply by checking the interrupt flags to see if we got that interrupt or not - and wait on an interrupt polling loop until it was received.

Waiting for Flash Write - the write itself is done by hardware and no timers are required to manage the write - only to verify the process has completed - again it's flagged on interrupt register.

Reading packets from FIFO buffer in the CP2200 after interrupt - there is conditional requirement these are read withing 51.2us of the interrupt, otherwise a random read must be used rather than autoread. I don't know how latent the external interrupt line is (as that would have to be used if not polling for interrupt statuses on the default interrupt scheduler.

The chip seems to take care of a lot of the very low level stuff, provided it is serviced quickly by it's interrupt handler.


Post Reply