On 17/07/2011 10:01, Memory Lane Computing Ltd wrote:
All,



Here is some news about two new projects, still in the very early stages,
code-named Q-BUS and Ser-USB++



Whereas the Ser-USB is targetted solely at file transfers, and is limited by
the speed of the QL's truly abysmal serial ports, the Ser-USB++ would be a
full fixed disk replacement operating at significantly higher speeds.



The Ser-USB++ would use the same core driver (with a different Hardware
Abstraction Layer slotted in) and would be targetted solely at Base QLs
running QDOS versions up to and including Minerva.  It will use the ROM port
for its connection and a microcontroller (essentially another IPC outside
the QL, but 100s of times more powerful than the QL itself) to provide a
standard command interface that will isolate the QL from the underlying
protocols of the storage devices that it controls.



Why the ROM port? Because every QL has one, and the expansion slot is often
occupied with floppy controllers, Trump Cards, Gold Cards etc. Obviously
this will not deliver the same performance as direct connection to the QL's
expansion bus, but it worked well enough for the Miracle Hard Disk and the
fantastic ROMDisQ (Tony - why on Earth don't you start making that again?).



Writing through the ROM port has been done several times before and there's
no great technical wizardry involved; just allocate a 256 byte range of
addresses for write operations and map the low eight bits of the address bus
onto the outbound data bus when that range is accessed. (OK, there's a
little bit more to it than that, but anyway).



Instead of creating a ROM port interface dedicated solely to the Ser-USB++,
this project would be built upon a new base peripheral called Q-BUS. This
card will plug into the ROM port and provide an external bus with 256
individually addressable read/write 8 bit I/O ports. It will also provide
operating system extensions to manage the new I/O bus.



The Q-BUS prototype has been constructed using discrete logic, but this will
ultimately be replaced with a single PLD to do all the address decoding,
latching etc.



Anyway, here are some pictures of the prototype hardware:



Q-BUS Prototype - Top View

This is built around a scrapped QL ROM cartridge that somebody had hacked
about to take a 27512. This saved the need run off a PCB for the connector.
The logic consists of address decoding, bidirectional tri-state buffers and
a peripheral select latch. The red jumper allows the interface to draw power
from the QL (but it could be externally powered), the white jumper pulls the
external Interface Enable line low.

Note the unpopulated EPROM pass-through socket. It would be a simple matter
to extend the address decoding logic to support paged ROMs, but the
prototype does not do this.

http://imageshack.us/photo/my-images/232/p1020116v.jpg/



Q-BUS Prototype - Side view

http://imageshack.us/photo/my-images/189/p1020117n.jpg/



Q-BUS Prototype - Underside view of wiring

You cannot imagine how much fun this was to wire up!

http://imageshack.us/photo/my-images/29/p1020118t.jpg/



Prototyping Rig - Top View

The principal components are a Pic32 microcontroller board and a USBWiz
(which currently talks via I2C to the Pic32).

http://imageshack.us/photo/my-images/543/p1020121m.jpg/



Q-BUS Prototype plugged into QL ROM Socket

This is way too long, but replacing the discrete logic with a PLD should
solve that issue.

http://imageshack.us/photo/my-images/96/p1020119g.jpg/



Q-BUS Prototype connected to Prototyping Rig

http://imageshack.us/photo/my-images/39/p1020120n.jpg/



Q-BUS Prototype connected to Prototyping Rig

Pull-ups are added to the data lines so that the Pic32 (which is 3.3v logic)
can drive them to TTL levels with pins configured as open collector.

At the completion of this first test run, it was confirmed (by numerous
PEEKs) that the Peripheral Address Select Latch was working and that the
bi-directional data bus was functioning correctly.

http://imageshack.us/photo/my-images/35/p1020122s.jpg/



The next step is writing the firmware for the Microcontroller, which will
use I2C or SPI to talk to the USBWiz . or it may not use a USBWiz at all
(once the microcontroller is interpreting commands from the QL, it could
talk to anything - and I have some other ideas about better ways of
providing USB and SD card interfaces having gone this far).



There is no timetable for this project, and absolutely no guarantee
whatsoever that the Ser-USB++ might become a product that you could buy (my
fingers are still burning from the investment that I made in the Ser-USB!)
but I thought people here on the list might be interested in what's going
on.



For the moment, the Ser-USB remains the current solution.  btw If I'm
allowed a small plug . there are still three left to buy at sellmyretro ;)
when they are gone I will only be producing Ser-USBs to order.







Adrian

  <http://www.memorylanecomputing.com>  www.memorylanecomputing.com





_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

I am dependent upon the ROMDisQ in my port. Would I still be able to use it without too much projection; I have limited front to back room in my desk set-up.

Bryan H

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to