Re: [Ql-Users] Ethernet adapter for QL ?
El 26/09/2010 17:42, Petri Pellinen escribió: Hello, am studying if it would be feasible to use the EPROM slot and create a module with something like Microchip ENC28J60 Ethernet controller and Maybe you want to take a look at the Spectranet project: an Ethernet controller for the ZX Spectrum, by Dylan Smith. Dylan uses an integrated ethernet controller, the WIZnet W5100, which offers a high level socket-oriented interface to the host. http://spectrum.alioth.net/doc/index.php/Main_Page ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
Nasta, thank you for taking the time to write this - wonderful information! On Mon, Sep 27, 2010 at 3:09 AM, Z N zeljko.nasta...@zg.htnet.hr wrote: Maximum data throughput on 10Base ethernet approaches about 800-900k bytes/second. Well, the good thing is that it takes around 0.1s to fill up the main memory of the original hardware at this speed :) Anyway, seriously speaking - what I really had in mind is a replacement for the PPP over serial connection setup which I currently run. Main use for me would be non-throughput intensive applications like a small web server, web clients and interactive applications like telnet. less than half if it's done by an ordinary 68008 CPU. Unless a very simple communication protocol was adopted, the ethernet would run quite slow and while doing that, bog down the CPU considerably. I agree, that's why I thought a microcontroller based board would be optimal, essentially hooking up a more powerful cpu to do the heavy lifting and leave a very thin driver layer on the ql side. This guy has a nice writeup which might serve as one possible starting point: http://www.tuxgraphics.org/electronics/200606/article06061.shtml that a packet has been sent or received. Here we get back to the inadequacies of the ROM port - no interrupt line. There is one on the expansion port Based on all the information from you and Miguel the expansion port definitely looks like the way to go. DSMCL can over-ride any decoding internal to the QL, on ANY address. This was really interesting stuff that defnitely was not in the documents I found so far. which are actually used by the software to access these registers - if I recall correctly, it's 64 bytes at the very beginning, starting from address 18000. The Sinclair QDOS companion seems to agree with you :) However, the choice of address is not straight-forward. Hardware like the TC, GC, SGC use some addresses in this area to decode their own on-board hardware. Unfortunately I do not recall off the top of my head exactly which ones but something about the top 256 bytes rings a bell. Hopefully someone has the details on the addresses in use by those. 3) Mimic the OS initialization scheme using the initialization data normally found at the beginning of a (presumed) ROM in the ROM slot. It may be possible to do this by manipulating register values passed in the initialization of the external interface, but I would not recommend it as the init code is different in various OS versions - besides, what the OS does on init is quite well documented and not too difficult to emulate, so better keep things clean and compatible. There seems to be a writeup on this in The Sinclair QDOS Companion. Don't know if the procedure outlined there still applies with the newer ROMs, etc. Done! With your instructions, easy as pie :) Cheers, Petri ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
Nasta, Petri said thank you for taking the time to write this - wonderful information! So do I. John in Wales ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ethernet adapter for QL ?
Hello, hopefully everybody is having a great weekend. Might be a FAQ, but... has anyone developed an ethernet adapter for the original QL either as a commercial product or a hobby project? I am studying if it would be feasible to use the EPROM slot and create a module with something like Microchip ENC28J60 Ethernet controller and a microcontroller e.g. the ATmega168 to interface with a device driver on the QL side. I have essentially zero experience in building any kind of hardware interfaces but I think it would be a great hobby :) Best regards, Petri ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
- Original Message - From: Petri Pellinen p...@iki.fi To: ql-users ql-us...@q-v-d.com Sent: Sunday, September 26, 2010 4:42 PM Subject: [Ql-Users] Ethernet adapter for QL ? Hello, hopefully everybody is having a great weekend. Might be a FAQ, but... has anyone developed an ethernet adapter for the original QL either as a commercial product or a hobby project? I am studying if it would be feasible to use the EPROM slot and create a module with something like Microchip ENC28J60 Ethernet controller and a microcontroller e.g. the ATmega168 to interface with a device driver on the QL side. I have essentially zero experience in building any kind of hardware interfaces but I think it would be a great hobby :) Best regards, Petri If using the EPROM slot, you need to bear in mind that this slot is read-only - it is designed just for EPROMs to plug in. That said, people like Miracle Systems (and others) have used it as a write interface by using a special technique like a double read - the first read is an address (to write to) and the second read puts data on the address line somehow. I don't pretend to even half understand it, but I'm sure there are others on this list with more knowledge of the QL hardware than me. Do bear in mind that some QL add-on interfaces like Trumpcard use pretty much all available addressing space to provide more than the original design limit of 640K RAM. I think Nasta (Zeljko Nastasic in Croatia) once proposed a QL ethernet interface, and I think Peter Graf once suggested the possibilities of such an interface for Q40/Q60. Dare I mention the dreaded word... drivers ? This is where so many proposed hardware add-ons have fallen down over the years. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
Hi Dilwyn, the bit about the EPROM slot being read-only is very interesting. The documentation in the technical guide and service manual are a bit vague around this subject but I didn't realize that the data lines on the connector would be one-way. The block diagram suggests that the slot's data lines would be one-way but the circuit diagram shows both the J1 and J2 slots' data lines directly connected to the CPU which would lead one to believe that the data lines would be two-way active on the ROM connector. My initial assumption was that a manner of memory mapped I/O would be possible through the slot. If someone has any h/w designs lying around I would be happy to colllaborate and pitch in on the dreaded driver side of things. I can definitely see why the Qx0 platform is interesting to a wide audience but, bitten by the retrocomputing bug, I would love to implement something on the original hardware. Being a S/W engineer by profession I'm very much in the dark about the whole microelectronics side of things so I have no idea whether this whole project is at all feasible but it's an interesting subject, nonetheless :) Cheers, Petri On Sun, Sep 26, 2010 at 7:00 PM, Dilwyn Jones dil...@evans1511.fsnet.co.uk wrote: - Original Message - From: Petri Pellinen p...@iki.fi To: ql-users ql-us...@q-v-d.com Sent: Sunday, September 26, 2010 4:42 PM Subject: [Ql-Users] Ethernet adapter for QL ? Hello, hopefully everybody is having a great weekend. Might be a FAQ, but... has anyone developed an ethernet adapter for the original QL either as a commercial product or a hobby project? I am studying if it would be feasible to use the EPROM slot and create a module with something like Microchip ENC28J60 Ethernet controller and a microcontroller e.g. the ATmega168 to interface with a device driver on the QL side. I have essentially zero experience in building any kind of hardware interfaces but I think it would be a great hobby :) Best regards, Petri If using the EPROM slot, you need to bear in mind that this slot is read-only - it is designed just for EPROMs to plug in. That said, people like Miracle Systems (and others) have used it as a write interface by using a special technique like a double read - the first read is an address (to write to) and the second read puts data on the address line somehow. I don't pretend to even half understand it, but I'm sure there are others on this list with more knowledge of the QL hardware than me. Do bear in mind that some QL add-on interfaces like Trumpcard use pretty much all available addressing space to provide more than the original design limit of 640K RAM. I think Nasta (Zeljko Nastasic in Croatia) once proposed a QL ethernet interface, and I think Peter Graf once suggested the possibilities of such an interface for Q40/Q60. Dare I mention the dreaded word... drivers ? This is where so many proposed hardware add-ons have fallen down over the years. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
Excellent writeup, thanks Miguel! Your explanation does make it very clear why it is a read-only port :) I was guessing the double read mechanism would be something like you outlined below. It's actually a very clever trick. If you want help with the software side of things I'll be glad to help where I can. I don't have tons of 68k Asm experience but have written some stuff on it. Best regards, Petri On Sun, Sep 26, 2010 at 9:27 PM, Miguel Angel Rodriguez Jodar miguel.an...@zxprojects.com wrote: El 26/09/2010 19:40, Petri Pellinen escribió: Hi Dilwyn, on the ROM connector. My initial assumption was that a manner of memory mapped I/O would be possible through the slot. Of course, but you mast take into account that: - The ROMOEH signal goes active only with read bus cycles, not write cycles. - There's no R/W signal on the ROM expansion connector (although it would be possible to wire that signal on one of the unused pads). If you would decide to forget about the ROMOEH to perform true writes, you would find that there's no AS or DS signals available too, so you would only rely on the value of address lines to know when your device is being addressed. Besides, there's no way to signal the end of the bus cycle, as DTACK is not available too. So there's no way (AFAIK) a card plugged into the ROM expansion would know when a write bus cycle is about to happen. This is because odd techniques must be applied to perform a write using reads. One of them is, as explained, to reserve a region of the ROM address space (0C000-0) which will hold your device hardware registers. That region cannot be the last 512 bytes, i.e. 0FE00 - 0, because that region will be reserved for our write scheme. Let's assume you will need at most 256 hardware registers for your device (surely you will need far less than this). Let's say you want to put a value dd (8 bits) into the register numbered aa (8 bits). You first make a read bus cycle from address FEaa (and discard the result). Your device captures the LSB of that address from the CPU address lines and store it in an internal 8 bit address latch. Then, you make a read from address FFdd (and again, discard the result). Your device will take the LSB of the CPU address (actually the data you're going to write) and will write it into the device register pointed by the address register. Something like (not sure if this is correct assembly for 68000): move.l #$FEaa,a0 ; Where aa is the register number we want to write into. move.b (a0),d0 ; Discard the result in D0. move.l #$FFdd,a0 ; Where dd is the 8-bit value we want to write move.b (a0),d0 ; Discard the result in D0. ; Value dd has been writeen into register aa. For normal reads, we'd just use a standard approach. Let's say your hardware registers are mapped into addresses 0FD00-0FDFF . So, this will do the job: move.l #$FDaa,a0 ; We are going to read from register aa move.b (a0),d0 ; Read it and store the result in D0. If someone has any h/w designs lying around I would be happy to colllaborate and pitch in on the dreaded driver side of things. I can I've some ideas but I lack experience on writting 68k assembler and writting directory drivers. I've just bought the Advanced QL User Guide, and hope to have enough time to read it carefully and start making experiments. but, bitten by the retrocomputing bug, I would love to implement something on the original hardware. I have three original QL's, and no modern QL's, so if I do something, it will be for the original hardware. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
Petri Pellinen wrote: Excellent writeup, thanks Miguel! Your explanation does make it very clear why it is a read-only port :) What's about the Miracle WIN device plugged in the QL ROM port? This works on the ROM port, so it should work. Maybe, they can give details. Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ethernet adapter for QL ?
The ROM port is not a very good idea when it comes to hardware expansions such as an ethernet card. The maximum theoretical data throughput of the original QL's bus is only about 1.875 Mbytes/second. You can only approach this using something like the Super Gold Card, assuming your CPu does nothing else except move data around. Maximum data throughput on 10Base ethernet approaches about 800-900k bytes/second. Although sending packets over ethernet is relatively easy, as the chips do all that is required, managing the packet buffets requires some overhead - using the ROM slot with it's 'write using read' scheme cripples the data throughput to less than half its already low maximum - considerably less than half if it's done by an ordinary 68008 CPU. Unless a very simple communication protocol was adopted, the ethernet would run quite slow and while doing that, bog down the CPU considerably. That being said, because sending packets over ethernet is not too much work software-wise, it should be possible to almost directly adapt the QL's net device to use ethernet. To do so, there are two problems - one is software based, the other hardware. The first one is translating the 6-byte ethernet MAC address to something the QL can use to identify a net point to communicate with. Fortunately, chips generally have registers where you load a MAC address your ethernet interface is supposed to have, so a, say, 5-byte prefix could be adopted for all QL ethernet interfaces, and the final 6th byte would be configurable by the user and correspond to a netX device. The second problem is that most chips use interrupts to signal to the CPU that a packet has been sent or received. Here we get back to the inadequacies of the ROM port - no interrupt line. There is one on the expansion port - one need only look at SuperHermes to see how it was used despite the fact it's not connected to the IPC socket. In theory, something like it could be done to add it and a write line to the ROM slot but this only adds more complication to a slot that is not too stable for any large-ish piece of hardware, especially one with a cable dragging out of it - edge connectors are really unsuitable for this and unplugging something from the slot while the QL is running, never mind the fact it may have been done by accident, may prove fatal to the QL or the interface. IIRC the proper place to put the interface would be on the expansion slot. It has all the required lines, and one important feature - the DSMCL line. DSMCL is the connection between DSL from the 68008CPU or indeed an external CPU as found on a GC or SGC, and the DSL input on the 'master chip' also known as the Video ULA. The latter is responsible for decoding the addresses for everything on the QL's motherboard, and it looks for DSMCL (normally the same as DSL) to see if the 68008 wants to access some part of the memory map. When DSMCL is pulled high, mormally by decoding a suitable address from the address lines, the internal decoding is disabled. This means that using DSMCL can over-ride any decoding internal to the QL, on ANY address. For instance, if it is activated on addresses C000-, it will disable the ROM slot. Using an external decoder for those addresses can put an 'external' ROM or indeed, any other hardware, WITH write ability, in the place of the original ROM slot, and the rest of the QL would be none the wiser - if the hardware corresponds to the expansion ROM standard, the OS will happily initialize it and use it as if it were on the ROM slot. Now we come to the important bit: If we look into the various guides and manuals, there is a place in the QL's memory map used for all the registers that control the QL's on-board hardware - such as the register in the Video ULA that selects the graphics mode and screen address, or various registers that implement the clock, IPC comms, microdrive control and data registers, serial ports. These are all located in a very small portion of a 16k address space at 18000-1BFFF, and repeat many times inside that space. Using DSMCL it is possible to override all decoding inside that address space except the small number of addresses which are actually used by the software to access these registers - if I recall correctly, it's 64 bytes at the very beginning, starting from address 18000. This leaves a seizable amount of space for hardware expansion, because most hardware (not counting ROMs) uses a relatively small number of control and data transfer registers, usually 256 bytes per device is more than enough. This also suggests that the address space should be decoded in 256 byte chunks, the very first one being left untouched so that the QL's on-board hardware can function normally. In fact, such a scheme was implemented on the Aurora board and while at it, some extra lines, including a write strobe and a line
