SGC successor brainstorming

Nagging hardware related question? Post here!
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: SGC successor brainstorming

Post by Peter »

olifink wrote:Curious - how do I make QD-SD work with SGC?
Order one from Marcel, he builds them ready for SGC. Also, original devices designed by me and distributed by Paul could be updated if someone cares. I freely published the QL-SD hardware, so that improvements can flow back.
olifink wrote:Also the classic QL doesn't unless you do/can do internal modification which not everyone is comfortable with or wants to.
How about yourself, would you do it? QL-SD is a relatively small modification, and not extremely hard to reverse.

Back on topic: If QL-SD is already daunting, asking users to rip out their mainboards for an SGC successor altogether, or even to file their case, looks like a no-go.
By the way, the Spectrum Next, which you admire, requires both: Rip out the mainboard, file the case.
olifink wrote:
Peter wrote:Nothing? The Q68 is in full production.
And I'm trying to get my hands one, but it clear isn't straightforward unless you know what you're looking for and whom to ask.
That is true, the Q68 is at the moment distributed without advertising. But as your example shows, it is not impossible to find. ;)


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: SGC successor brainstorming

Post by Peter »

stephen_usher wrote:Maybe we should thing in reverse and think of the original QL as a peripheral to a new single-board computer which fits within the expansion slot?
If you read my first post again, at which point do you see it deviate from the concept you propose?
Nasta wrote:This is exactly what the GC/SGC are. So, this problem has already been looked at from that angle, but what remains is that virtually ALL of the constraints are right there on the old QL motherboard. It has, in a very real sense, become a 'ball and chain' for any new expansion.
What keeps GC/SGC from being single-board computers, is the lack of graphics. Somehow Stuart Honeyball, may he rest in peace, never achieved this goal. This is what led to Aurora and Q40/Q60 eventually.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: SGC successor brainstorming

Post by Peter »

tofro wrote:I'm not so sure the case variants are much of a problem - You could make some laser-cut steel filing stencils for cheap for the new openings and have people modify their cases themselves. The BT plugs are anyhow nearly impossible to find nowadays. But if someone absolutely wants their case left unmodified, so be it.
If ripping out the original mainboard and dumping the microdrives is acceptable, we could even ask: Why not use the Q68 plus a little kit? The non-british case would not require filing for that:
Q68insideQLexample.jpg
We'd need at least a cable adaptor to the existing card socket portion of QL-SD (grey), and a matrix keyboard adaptor (yellow).
A power lead (green) is not strictly necessary, 5V could also be supplied by a modified PS/2 Y-cable for the mouse.

Even the Aurora, which was targeted as QL mainboard replacement, was not easy to build into a QL. I can imagine the Q68 would be easier than that, if a kit is provided. Most external connectors are easier accessible than Aurora. A cover for the case opening, also fixing the Q68 board, could easily be derived from the Q68 back panel I already designed. If made wider, it could even hold the NET connectors at the original place.

Significant design work would "only" be the keyboard adaptor. In quotation marks, because a 100% compatible solution requires IPC and ULA implemented somewhere. Doable inside FPGA, but work. Even less compatible matrix converter projects did not finish yet. This is where keeping the original mainboard actually saves work.

However, I remain in a lot of doubt about ripping out the original mainboard, after what we just read from a returning QL user.

Peter


User avatar
Andrew
Aurora
Posts: 786
Joined: Tue Jul 17, 2018 9:10 pm

Re: SGC successor brainstorming

Post by Andrew »

The QL keyboard can be used with Q68 by using a matrix to PS2/USB adaptor like this https://www.nxp.com/files-static/microc ... DRM014.pdf


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: SGC successor brainstorming

Post by Peter »

A few answers on Nasta's nice long post. Wish I had the time for more.
Nasta wrote:Currently 1a + 2a is covered with the Tetroid SGC clone. The problem here is the Ingot CPLD which is becoming impossible to find and to a lesser extent the floppy controller chip.
Even under the assumption CPLDs can be sourced, I'm not sure it is covered, lacking decent video. This is mainly why I opened the topic. And I would close it, if Tetroid or you added video.
Nasta wrote:Also, 1b + 2b os covered by the Q68 which is it's own single board computer and has no ties to old hardware except virtually
Maybe the term "virtual" sounds like "emulated" for some readers. Let me clarify: The Q68 implements QL components in hardware. Like SGC+Aurora, just with different features, and CPU inside programmable logic.
Nasta wrote:In fact, given that the 68EC030@40M tends to run just fine at 50M and is actually cheaper than 68020 variants, AND it supports dynamic bus sizing which lets it easily use various bus widths concurrently in the system (extremely useful if you are doing a SGC replacement!), AND it can also be interfaced to burst-capable RAM sich as SDRAM, it would be THE chip to use for this purpose, without breaking the bank. Given proper support for external hardware, this option actually runs significantly faster than the current Q68.
Agreed, but only due to DRAM waitstates. If we compare for fast SRAM (thereby looking only at CPU speed) the Q68 executes many instructions in a single clock cycle, including multiplication. Even if a 16-bit databus is kept for the Q68, I doubt the 68030 still beats the Q68 at this core discipline. I know this is hard to believe, but I put much effort in getting the CPU to run that fast inside a lowest-speedgrade decade-old FPGA. If someone had time, 68030 reference hardware, and benchmarks that fit the Q68 SRAM area, it can already be checked on the current Q68.

To reduce Q68 DRAM waitstates, I work on cache. My first implementation has only 2 KB, but there is a tag entry for every single word, I did not split it into lines. This should be very appropriate for QL-style code. (Currently I'm struggling with a bug, and I fear it is inside the synthesis tools.) Hard to predict if a 40 MHz Q68 with cache beats a 50 MHz 68030 with 32-bitwide DRAM, but the chance has become realistic. After all, 2048 bytes cache is more than 2x256 bytes, and 1 clock cycle per basic instruction is less than 2.
Nasta wrote:On the high end, there is a FPGA implementation of a new 68k+ sompatible core called the 68080, which includes a FPU and extension to 64-bits. It is not as fast as the fastest still available coldfires (which I have decidedly skipped for reasons I'll get to below), but still about 3-4 times faster than the fastest 68060, possibly more, depending on how much you are willing to pay for the FPGA to implement it.
And depending on how much you are willing to pay for licensing - the "68080" is a strictly commercial core. They offer a massively clock-reduced and otherwise limited version without royalties, in the hope to get money for upgrades. But once you want that outside their Amiga-accellerator boards, there is need for negotiation and probably paid support work, besides large amounts of work for platform and FPGA vendor adaption. Since my name is known from Q60 and Q68 designs, they seemed open for cooperation, although I doubt they are aware how extremely small the QL scene is, and how little money they could make. I got some questions answered, but postponed a closer look. At the moment I don't feel like another high-end design, and anyway a SGC successor would probably not be the right place for it.

Peter


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SGC successor brainstorming

Post by tofro »

I doubt if it is worth looking into DRAM at all. With memory prices in the QL size range where they are, I wouldn't even bother to think about a DRAM controller.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: SGC successor brainstorming

Post by stephen_usher »

Nasta wrote:
stephen_usher wrote: ..Maybe this is being looked at from the wrong direction? Maybe we should thing in reverse and think of the original QL as a peripheral to a new single-board computer which fits within the expansion slot? It sounds like it's possibly a simpler solution to all the bottlenecks of the original system.
This is exactly what the GC/SGC are. So, this problem has already been looked at from that angle, but what remains is that virtually ALL of the constraints are right there on the old QL motherboard. It has, in a very real sense, become a 'ball and chain' for any new expansion.
From what I understand, the SGC still share the same data bus as the QL. I was wondering if the card would be a distinct machine with a peripheral interface connecting to the QL bus to access the QLs hardware, such as keyboard, microdrives etc. but fully decoupled from the new system. All video generation and all other functionality would be on the "new computer". This means that the new system is not hobbled by the QL bus etc. at all.


User avatar
XorA
Site Admin
Posts: 1358
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: SGC successor brainstorming

Post by XorA »

stephen_usher wrote:
Nasta wrote:
stephen_usher wrote: ..Maybe this is being looked at from the wrong direction? Maybe we should thing in reverse and think of the original QL as a peripheral to a new single-board computer which fits within the expansion slot? It sounds like it's possibly a simpler solution to all the bottlenecks of the original system.
This is exactly what the GC/SGC are. So, this problem has already been looked at from that angle, but what remains is that virtually ALL of the constraints are right there on the old QL motherboard. It has, in a very real sense, become a 'ball and chain' for any new expansion.
From what I understand, the SGC still share the same data bus as the QL. I was wondering if the card would be a distinct machine with a peripheral interface connecting to the QL bus to access the QLs hardware, such as keyboard, microdrives etc. but fully decoupled from the new system. All video generation and all other functionality would be on the "new computer". This means that the new system is not hobbled by the QL bus etc. at all.
This is pretty much how they work already!


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: SGC successor brainstorming

Post by Peter »

XorA wrote:
stephen_usher wrote:From what I understand, the SGC still share the same data bus as the QL. I was wondering if the card would be a distinct machine with a peripheral interface connecting to the QL bus to access the QLs hardware, such as keyboard, microdrives etc. but fully decoupled from the new system. All video generation and all other functionality would be on the "new computer". This means that the new system is not hobbled by the QL bus etc. at all.
This is pretty much how they work already!
Unfortunately not for the most important unit beside CPU + main memory: Video generation!


stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: SGC successor brainstorming

Post by stephen_usher »

So, replacing the video completely should mean that there's no need to directly access the QL memory at all.

This would mean that you could completely decouple the QL's address and data bus from the new computer, either accessing the hardware via a proxy I/O controller or turning the QL's 68008 into an I/O controller and get it to run the hardware and talk to it via some sort of gateway protocol, with the new system virtualising the hardware for the software (possibly highly modified version of Minerva running on the new board?)

By decoupling in this way the architecture of the new system doesn't even have to be m68k based. It could even be some sort of ARM SoC running an m68k simulation at the most extreme.


Post Reply