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-FFFF, 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
indicating this additional IO space is being accessed, were added. The
Aurora still implements DSMCL so, being a QL motherboard replacement,
still emulates DSMCL functionality - it's internal decoding, including all
the add-ons, can be overridden using DSMCL.
Assuming the ethernet board is going to have it's drivers loaded from a
file on some other device, the expansion ROM can be dispensed with and the
actual interface hardware can reside inside this extra space where it will
not disturb anything else.
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.
Finally - there is a way to have the cake and eat it too, as far as ROM
slot and external device decoding matters are concerned.
A piece of hardware on the expansion connector can appear in any place in
the memory map, the non-obvious thing being, it can appear at as many
places as it needs to, and more importantly, it does not have to appear at
the same place at all times.
If one constructs an interface using the extra space within 18000-1BFFF
for the hardware control registers (because this needs to be fixed at a
place where the driver can find them), eg. the registers within an
ethernet chip, the interface can also use a 16k ROM mapped into the ROM
slot, but the system will still be able to use whatever is in the ROM
slot, using the following scheme:
At reset, the ROM on the ethernet interface ROM is mapped at the position
of the ROM slot, C000-FFFF. This is done by disabling the actual ROM slot
by pulling DSMCL high when it's addresses appear on the bus. The OS will
find the ROM there, and start executing the initialization code in it.
This code has to do 3 things in order for the scheme to work:
1) Copy itself into RAM. This is advisable and already done for eg. Qubide
in order to make use of much faster execution of the code when it's
running from accelerated memory, as found on the GC or SGC - it also
enables the use of bank switching or compression to fit more code into the
available ROM slot - in the latter case the ROM contents would be
decompressed into RAM on-fly. In the former case, bank switching is much
easyer if you don't have an annoying little bit at the end of the 16k
'bank' that you can't use - in case more than 16k code is to be used, this
is likely to be the method used to fit more code as EPROM/FLASH is real
cheap nowadays, in fact, it's hard to find less than 64k capacity.
2) Disable the over-ride of the ROM slot and the decoding of the interface
ROM, usually done by writing to a special address in the 18000-1BFFF area
used by the rest of the hardware on the particular interface, which the
decoder on the interface recognizes and changes the way it decodes
addresses and manages DSMCL from that moment on. This makes whatever is in
the ROM slot appear at the appropriate ROM slot addresses once again. The
initial decoding can normally only be restored by hardware reset. This
'variable decoder' resides on the interface itself so absolutely no
modifications are needed to the QL's hardware.
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.
Done!
:)
Nasta
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
