Announcing the new "Gold Card" - QIMSI Gold

[Peter]

I have a question: could some way be implemented to get the video output of the QL through the video port of the QIMSI Gold?

I did in fact implement this for Gold Card and Super Gold Card as a fun project. Requiring one extra wire.
Probably I could also do it for 68008 QLs with two extra wires. But I plan no public release at this time.
Actually I find it quite cool to use dual screens.

urely only by having a job running on BBQL to periodically copy 32K screen dump through FIFOs to QIMSI Gold

No. But the "how" remains my secret for now.

[Peter]

Do you have also added the clamp diode option to all the pins ?

Yes, that is mandatory of course.

I guess there 'll be no problem using resistors for the reliability in the long run because they are quite big and the longer rise time doesn't affect the speed, for the speed to the QL bus is not high anyway.

Not just that. The RC filter resulting from the pin capacities and the series resistors shapes the signal, so there is much less overshoot and ringing on the QL motherboard.
But be very careful: The compromise must be thoroughly simulated with the FPGA diodes characteristics, the max. voltage swing and the expected range of pin capacities on both sides. These may not be the same for your FPGA and you risk either damaging your FPGA I/O buffers in the long run, or signal problems with some QL hardware setups. Without a suitable Pspice model of your FPGA and a lot of simulation, your traditional approach is more safe. Probably preferable, as long as you have the board space.

[Nasta]

An simple internal DIN41612 to ROMport connector board might be useful

You may have noticed 2 x 2 extra pins in addition to the QL ROM port (the smaller ones near to the edge).
One of them is leading QLNET and one is a "detection" pin.
The other two could be used with such a connector board. Possibly one as R/W and one as a chip select.

This is the second thing I noticed

The first of course was the idea to use the QL as a coprocessor and this is brilliant because it solves a multitude of issues providing some clever software is provided on the QL side through the ROM port, which I see it is.
So, a hat's off Peter, this is the best QL hardware idea I have seen in a really long time!

Kind of interesting to me as a long time ago I was thinking of a similar concept but for the actual QL, another stripped down 'QL' used as an IO coprocessor that would be booted through some common RAM. I never thought of doing it the 'other way' but did briefly think of something similar back in the day while developing the ill fated GoldFire but back then CPLDs were just a dream and it would not fit efficiently into a CPLD, so I quickly discarded the idea.

Back to the two extra pins, might I offer a suggestion?
Instead of the R/W pin there should be a 'rom write'. An undecoded R/W is not much help as it does not qualify the data with a data strobe, but decoding a write signal for the ROM space, now we are cooking. The idea behind this would be to provide faster access to the communications FIFO to the CPU on the QIMSI Gold, because the QL side is quite slow at bit-banging. Basically just use the same address as a byte write to put a whole byte of data instead of shifting it bit by bit. I am sure more could be done but this would be the one thing I would do if just one thing could be done
The remaining pin could be a reset? Maybe bidirectional? I can guess how a QL side reset is detected but resetting the QL side from QIMSI might be useful.

Oh, BTW is the 'detect' pin an input?

So, someone could do a really small board with a really cut down QL. If no video is needed, some RAM, CPLD that would emulate the basics of the 8302 (the clock, the interrupts and the IPC access), and the IPC (with keyboard inputs). In theory even less is required if a different ROM is provided or even better if the QIMSI side provides some boot code)...

[FrancoisLanciault]

I was hoping the support code to drive the keyboard and such was provided at address 0, so the 68008 would boot using the special code.

Technically, I could implement this - but I don't understand your reason. Do you not own your QL ROMs anymore?

I use this QL with an external ROM port dongle (made by Chr$) with a single 64k EEprom socket. I can install a variety of OS/Toolkit. I currently have 5 different flavors I can choose from. So I can change the OS/ROM toolkit without opening the QL every time. I was hoping that, instead of plugging the dongle, I could plug the QIMSI Gold and enjoy super fast QL.

Further questions: what video modes are supported ?

They have been listed in the manual.

Indeed they are. I missed that part on my first read.

François

[Peter]

So, a hat's off Peter, this is the best QL hardware idea I have seen in a really long time!

Many thanks Nasta. It is debatable whether a card for the expansion slot would have been a better idea.
Doing it in an unorthodox way was more fun though.

I never thought of doing it the 'other way' but did briefly think of something similar back in the day while developing the ill fated GoldFire but back then CPLDs were just a dream and it would not fit efficiently into a CPLD, so I quickly discarded the idea.

It is sad that you didn't finish the GoldFire. The 68EC040-like CPU with multiplexed bus was really cool at the time. A few years ago, I had the chance to get the CPU in new condition for low cost and was quite tempted. But in the end, the 68060 is probably the better way to go when it comes to a "high end" QL compatible.

Back to the two extra pins, might I offer a suggestion?

The extra pins are not used yet, so I'm open for whatever ideas you have. It is easily possible to solder a 2.54 mm pin dual row header to the QIMSI Gold pads and plug it onto a different PCB. The extra pins just allow a bit more flexibility.

Instead of the R/W pin there should be a 'rom write'. An undecoded R/W is not much help as it does not qualify the data with a data strobe, but decoding a write signal for the ROM space, now we are cooking.

That is a nice possibility. Of course it only makes sense together with a second board generating that signal, which brings up the question what the goal of that board would be.

The idea behind this would be to provide faster access to the communications FIFO to the CPU on the QIMSI Gold, because the QL side is quite slow at bit-banging.

Another possibility would be to use an atomic CPU access that has a data bus write immediately following a read, e.g. an OR.B Dx,(Ax) instruction. The FPGA would see the read access and know that the write data will follow after a known delay, when it can sample. That would already work with the traditional ROM port.

Oh, BTW is the 'detect' pin an input?

Yes, with pullup. It is not actually used yet, but the idea was to see if QIMSI Gold is plugged into "something else" and then provide "something else" on all the other pins.

So, someone could do a really small board with a really cut down QL. If no video is needed, some RAM, CPLD that would emulate the basics of the 8302 (the clock, the interrupts and the IPC access), and the IPC (with keyboard inputs). In theory even less is required if a different ROM is provided or even better if the QIMSI side provides some boot code)...

If you have something specific in mind, I'm willing to adapt to your requirements, time permitting.
The Qzero might also be an option. It has more hardware resources and I/O.
Or we revive the "N68" idea. I have seen the the ECP5 is now available in a TQFP-144 case.
Hope we can talk at Dormagen.

[Cristian]

So Peter, you've written a new page in the history of QL!