Using the QIMSI-QL Link

[Peter]

Hi Jan!

Here is a slightly modified fifo driver which accepts anything starting with 'ser4' for those who want to test SERnet.

Many thanks. I have moved this over to a separate topic. For clarity, I have attached your QL-side SER4 driver for the QIMSI-QL link again here. Has to be loaded with "LRESPR ser4_bin". Testing purposes only!

Please also find attached a primitive program for the Mini Q68 side. The file Q68_ROM.SYS must be placed unfragmented onto the FAT32 filesystem of the microSD card. Testing purposes only!

This MiniQ68 program transfers data between the QIMSI serial port (binary for 115200 Baud or 9600 Baud) and the QL via the FIFO link. It toggles the green QIMSI LED on each character sent or received. I have not done intense testing, but it appears to basically work. This way, the QL should sooner or later get a fast and reliable serial port. With no handshake, but huge FIFOs.

While everything seems fine under BASIC, the SERNET driver responds with the error message "Problem with the serial port". I have not yet figured out the reason. Currently working under SMSQ/E on SGC. Q68 on the other end of the serial cable.

All the best
Peter

[martyn_hill]

Hi Peter

Some further questions arise rating to use of the QIMSI-QL Link.

My next question is, whilst an application is running on the mini-Q68, is there any timing interference with any on-going SD-Card access, or are those managed independently from the 68k emulation in the FPGA?

More specifically, if Interrupts are disabled for a time within the emulated 68k whilst it handles any timing-critical onboard IO (to the fast SERial port, the SOUND interface or it's embedded QLNet link, as examples), would this hold up any concurrent SD-Card access?

M.

[janbredenbeek]

While everything seems fine under BASIC, the SERNET driver responds with the error message "Problem with the serial port". I have not yet figured out the reason. Currently working under SMSQ/E on SGC. Q68 on the other end of the serial cable.

A quick peek at sernet.txt learns that it requires separate channels for sending and receiving, i.e. STXn and SRXn as provided by SMSQ/E.
Looks like I have some more work to do on the fifo driver...

[Peter]

Hi Martyn!

I have been thinking along the same lines with regards to some form of arbitrated 'command/response' protocol to allow sharing of the FIFO resource.

I developed such a protocol for the QLUB adapter which allows multiple applications to share the 'Message Queue' system over, in that case, the virtual SERial USB port on the host PC.

Also pulled this here, so the main QIMSI announcemend thread does not branch out into very specific discussions.
If the QL-MiniQ68 Link is indeed used for different purposes in parallel operation, it would in fact be nice to agree on a suitable protocol.

However, let's keep in mind that:
- The FIFO link is effectively just a full duplex serial port with buffers
- The MIniQ68 is not a major QIMSI feature, it is short of memory and poorly documented
- The MIniQ68 can only execute one "program" at a time

I would propose not to make things too complex at this stage. Let's first see how well the MiniQ68 works and gather some practical experience.

All the best
Peter

[Peter]

My next question is, whilst an application is running on the mini-Q68, is there any timing interference with any on-going SD-Card access

There is no interference. As soon as the QL side driver has accessed the SD card for the first time, the SD card interface is completely decoupled from the MiniQ68. This is a safety precaution implemented in hardware. The MiniQ68 can only access the SD card, before the QL side touches it for the first time. The LED is also switched on by hardware when this happens. (But it remains programmable from both sides afterwards.)

or are those managed independently from the 68k emulation in the FPGA?

First of all, there is no emulation happening at all. The MiniQ68 is a hardware implementation. You would not speak of "emulation" when using GALs or other primitive logic chips which are programmable. Just that this programmable logic is more complex, does not turn it into some sort of emulator. Which is also the reason, why things can run perfectly in parallel.

On power-up the SD card is at first coupled to the MiniQ68, so the loader can quickly fetch a "ROM" image from SD card before the QL side driver starts. So it is not "independent" at first. But it gets "independent" later on. By the way: If you use QIMSI outside the QL, the SD card remains attached to the MiniQ68.

More specifically, if Interrupts are disabled for a time within the emulated 68k whilst it handles any timing-critical onboard IO (to the fast SERial port, the SOUND interface or it's embedded QLNet link, as examples), would this hold up any concurrent SD-Card access?

Again, there is no emulation. But yes, the MiniQ68 hardware and the SD-Card hardware get completely decoupled once the QL has "grabbed" the SD card interface. You can do whatever you want on the MiniQ68 without any effect on the QL using the SD card. By the way, the mouse interface also gets decoupled from the MiniQ68 once the QL has accessed it. This is implemented in hardware, also.

[Derek_Stewart]

While everything seems fine under BASIC, the SERNET driver responds with the error message "Problem with the serial port". I have not yet figured out the reason. Currently working under SMSQ/E on SGC. Q68 on the other end of the serial cable.

A quick peek at sernet.txt learns that it requires separate channels for sending and receiving, i.e. STXn and SRXn as provided by SMSQ/E.
Looks like I have some more work to do on the fifo driver...

Hi Jan,

I used use SIMSER extension to QDOS, which adds STX,SRX and allowed SerNET to operate on SER1/2.

I hoped SIMSER could operate with SuperHermes SER3, but the extensions seem to operate direct with the IPC, some SER3 got no SerNET access.

There seems to be no source to Simser, though I msy of disassembled it.

[Peter]

Hi Derek,

thanks for these infos. Are STXn and SRXn actual device names? I guessed these were just SERNET specific code names and would be translated into SERn when actually opening the serial ports.

Peter

[Derek_Stewart]

Hi Peter

I am unsure about the history, of STX/SRX, just they were part of SMSQ/E to allow SerNET to work.

I suppose this a software approach to having a split serial port, so that the Tx (Transmission) and Rx (Receive) can operate on a single serial port.

[martyn_hill]

Hi Peter!

Thanks for confirming - and yes, by now you'd have thought I'd remember to use the correct terminology to describe the FPGA implementation of the 68k!

Are STXn and SRXn actual device names?

Correct, both SMSQe and SimSER implement independent, unidirectional serial devices as well as the original bidirectional type and SERNet requires the independent, unidirectional devices internally.

I'd imagine that's to allow QDOS IO calls to remain pending in both directions; you can't otherwise query for a new Get-byte whilst a Put-byte is still pending to the same channel - whereas split channels accommodate this.

M.

[Peter]

Correct, both SMSQe and SimSER implement independent, unidirectional serial devices as well as the original bidirectional type and SERNet requires the independent, unidirectional devices internally.

I'd imagine that's to allow QDOS IO calls to remain pending in both directions; you can't otherwise query for a new Get-byte whilst a Put-byte is still pending to the same channel - whereas split channels accommodate this.

Many thanks for explaining. I was not aware the OS keeps a device from blocking on both I/O directions independently.
I'm surprised that a split of devices is needed for such a basic requirement. Another lesson learned late...