Ethernet for the QL
Re: Ethernet for the QL
LS245 or F245 buffers with direction controlled by BG signal ? No other card will assert that apart from GC or SGC
Re: Ethernet for the QL
EPROM: it strikes me that after a while there will be stable code to add a TCP device and operate it, and that code should be held in EPROM on a BBQL.
Buffers: The (S)GCs go through the BR/BG process to take control of the QL's bus. If BG is asserted, then the direction of R/WR function is reversed? If this is the case, the direction of buffers could be reversed on /BG?
Buffers: The (S)GCs go through the BR/BG process to take control of the QL's bus. If BG is asserted, then the direction of R/WR function is reversed? If this is the case, the direction of buffers could be reversed on /BG?
Re: Ethernet for the QL
It's relatively unlikely that a full TCP/IP stack for the 68000 is ever going to fit into a 16k EPROM. I would rather assume the stack should be loaded into RAM (also much easier to maintain). That makes ROMs on a network card obsolete, but obviously prohibits network-booting a QL.Dave wrote:EPROM: it strikes me that after a while there will be stable code to add a TCP device and operate it, and that code should be held in EPROM on a BBQL.
This, however, opens up a different problem: Drivers on expansion ROMs don't need to be told where their hardware registers are - They're always fixed relative to their run address (because the ROM is in the same place). With a driver in RAM, that is not the case. So you either need to software-reconfigure the driver to the (fixed) location where the hardware registers are located, or provide a mechanism that allows the driver to easily "find" the hardware registers.
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Ethernet for the QL
Would having some basic system calls in ROM and a loadable updatable section to make it live work? That way, system variables for location and some linked in elements like NTP functionality could be live just because the ROM's linked in? Chances are, I'm just talking nonsense though.
Also, nothing says the ROM has to be 16K.
Also, nothing says the ROM has to be 16K.
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: Ethernet for the QL
Hi Dave!
Following on from Tobias, I still see value in the basic hardware interface code being held in a ROM - the generic TCP/IP stack being loaded in to RAM.
That way, the physical/device-specific registers etc could be 'found' in the traditional manner by the on-board code, and these low-level primitives exposed for other layers to exploit without needing to know the details. I believe that's how the various layers are typically segregated.
Following on from Tobias, I still see value in the basic hardware interface code being held in a ROM - the generic TCP/IP stack being loaded in to RAM.
That way, the physical/device-specific registers etc could be 'found' in the traditional manner by the on-board code, and these low-level primitives exposed for other layers to exploit without needing to know the details. I believe that's how the various layers are typically segregated.
Re: Ethernet for the QL
There's no cost to including the position and a chip select for it. If it's not installed, RAM can be mapped, and if it is, well, it will be found and executed.
One of my deep regrets about the QL is that expansion manufacturers, including Sandy, did not use the SP0..3 lines properly, or often at all! Bruce Gordon told me the original intent of the SP0..3 lines was that the first card would see 0000, then add to that the number of 16K ROM slots it needed. If two, it would pass through 0010. The next card would see 0010 and add for 1x 16K slot, and pass through 0011, and etc. Because this was terribly, very badly, not goodly documented, and because of conflicting documentation, a lot of people interpreted it as have four jumpers and if SP0..3 matches your jumpers your card is mapped there.
Sinclair always wanted the cards to be relocatable and self stacking. Comically, they thought 16x 16K slots was a hugely generous amount as nobody would ever want 16 cards or ROMs in their machine.
This conversation happened in a debate about Futura expansion options, which were moved to a DIN-96 connector.
One of my deep regrets about the QL is that expansion manufacturers, including Sandy, did not use the SP0..3 lines properly, or often at all! Bruce Gordon told me the original intent of the SP0..3 lines was that the first card would see 0000, then add to that the number of 16K ROM slots it needed. If two, it would pass through 0010. The next card would see 0010 and add for 1x 16K slot, and pass through 0011, and etc. Because this was terribly, very badly, not goodly documented, and because of conflicting documentation, a lot of people interpreted it as have four jumpers and if SP0..3 matches your jumpers your card is mapped there.
Sinclair always wanted the cards to be relocatable and self stacking. Comically, they thought 16x 16K slots was a hugely generous amount as nobody would ever want 16 cards or ROMs in their machine.
This conversation happened in a debate about Futura expansion options, which were moved to a DIN-96 connector.
Re: Ethernet for the QL
Something like this might work on the QL :
https://en.wikipedia.org/wiki/LwIP
It was successfully ported to the Kiwi 68K project - which is also built around the 68008 (all be it the 4Mb addressing version in the 52 pin PLCC). The footprint is relatively small at around 40K and would use less memory than 256K of RAM. It sensibly breaks down into 'driver' type code and TCP/IP applications that sit atop those primitives.
https://en.wikipedia.org/wiki/LwIP
It was successfully ported to the Kiwi 68K project - which is also built around the 68008 (all be it the 4Mb addressing version in the 52 pin PLCC). The footprint is relatively small at around 40K and would use less memory than 256K of RAM. It sensibly breaks down into 'driver' type code and TCP/IP applications that sit atop those primitives.
-
- Font of All Knowledge
- Posts: 3973
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Ethernet for the QL
I was going to built a Kiwi, but got distracted by other things...Pr0f wrote:Something like this might work on the QL :
https://en.wikipedia.org/wiki/LwIP
It was successfully ported to the Kiwi 68K project - which is also built around the 68008 (all be it the 4Mb addressing version in the 52 pin PLCC). The footprint is relatively small at around 40K and would use less memory than 256K of RAM. It sensibly breaks down into 'driver' type code and TCP/IP applications that sit atop those primitives.
Can the Ethernet Card fit inside the QL Case?
Regards,
Derek
Derek
Re: Ethernet for the QL
I was looking at this too - but the video chip - V9990 is rarer than rock horse poop.
Still - it proves that an IP stack can fit in a reasonable footprint - let's face it I don't think anyone is expecting to be able to open a full colour browser with java, etc on a QL - I hope not. But smtp / ftp and text browser should be possible, and some functionality similar to QL net (opening a disk drive on another QL over TCP/IP)
Still - it proves that an IP stack can fit in a reasonable footprint - let's face it I don't think anyone is expecting to be able to open a full colour browser with java, etc on a QL - I hope not. But smtp / ftp and text browser should be possible, and some functionality similar to QL net (opening a disk drive on another QL over TCP/IP)
Re: Ethernet for the QL
It does. I ported lwIP two decades ago already, as part of my QLwIP project, demonstrated at several QL shows.Pr0f wrote:Something like this might work on the QL :
https://en.wikipedia.org/wiki/LwIP
With full multitasking socket API and drivers it can be larger, and also quite slow on a 68008. The current UDP drivers form Martin and Wolfgang are more adequate.Pr0f wrote:The footprint is relatively small at around 40K and would use less memory than 256K of RAM.