The Sinclair QL Forum

javier2112 wrote:

Derek_Stewart wrote:I woukd just remove the 68008 an try and interface a 68020... oh wait it has been done ... called the Super Gold Card!!!

Super Gold Card is a very expensive and non open piece of hardware and it doesn't support IDE devices.

You can use the 68HC001 as "just a replacement" for the 68008, but it can also be used to expand the RAM beyond 1 Mb. To me, it's ideal in combination with a Qubide interface.

Sounds great, I would like to buy it, but I think this like other ideas, will only stay ideas...

javier2112 wrote:

Derek_Stewart wrote:I woukd just remove the 68008 an try and interface a 68020... oh wait it has been done ... called the Super Gold Card!!!

Super Gold Card is a very expensive and non open piece of hardware and it doesn't support IDE devices.

You can use the 68HC001 as "just a replacement" for the 68008, but it can also be used to expand the RAM beyond 1 Mb. To me, it's ideal in combination with a Qubide interface.

So if I understand, you basically are replacing the 68008 with a slightly faster CPU and are using some logic to align to the internal QL's clock? Is this similar to this project for the Amiga:

https://github.com/Mathesar/14mhz-accelerator

javier2112 wrote:

Nasta wrote:If the original ULA chipset is used, and the CPU is operated at higher speed, there has to be extra circuitry that will fairly faithfully emulate the original 68008 running at 7.5MHz. This is because the 8301 ULA makes certain assumptions about the signal timing on the 68008 in relation to the clock signal, given that the 8301 is also the clock signal generator. Once the CPU clock is not coming from the 8301 those assumptions are not correct and you get RAM read and write errors. If you are reconstructing the entire circuit from scratch, you should not have any problems.
The particular assumption has to do with when write and read data should be present with regards to the DSL signal and DTACKL signal. 68000 derivatives (including 68008, 68HC000, EC000/1 and SEC000 as well as some 68300 series integrated CPUs) latch read data once clock cycle after DTACKL is recognized low so in principle you can pull DTACK low before actual data is available as long as it is available at the appropriate clock edge one cycle later (this is all explained clock edge to clock edge in the relevant datasheets). The 8301 is also the RAM controller and uses this all the time.

Looks nice what you are doing!
I follow you on the group of Telegram and I know you will achieve the goal.

Derek_Stewart wrote:

javier2112 wrote:

Derek_Stewart wrote:I woukd just remove the 68008 an try and interface a 68020... oh wait it has been done ... called the Super Gold Card!!!

Super Gold Card is a very expensive and non open piece of hardware and it doesn't support IDE devices.

You can use the 68HC001 as "just a replacement" for the 68008, but it can also be used to expand the RAM beyond 1 Mb. To me, it's ideal in combination with a Qubide interface.

Sounds great, I would like to buy it, but I think this like other ideas, will only stay ideas...

I studied Digital Systems 30 years ago. Since then, I've been working as software developer, so my experience in this area is very limited, which is why I ask in forums like this and others. At this moment I've designed a schematic and I hope to finish the project if I'm able to understand how works microprocessor and memory of the QL.

javier2112 wrote: I studied Digital Systems 30 years ago. Since then, I've been working as software developer, so my experience in this area is very limited, which is why I ask in forums like this and others. At this moment I've designed a schematic and I hope to finish the project if I'm able to understand how works microprocessor and memory of the QL.

Do not worry Javier, sometimes it is impossible to understand why somebody answer something that sounds not polite in our thinking way. Do not let those drain your energy. We know you are going to get it, later everyone will copy it and say... oh that was pretty simple, my child would do it without too much effort... no pay a penny for such comments and go ahead with whatever you decide to develop. We are going to do it well, cheaper and free.

Popopo wrote:

javier2112 wrote:Do not worry Javier, sometimes it is impossible to understand why somebody answer something that sounds not polite in our thinking way.

I don't think an insult was meant it is just a statement of fact of the people already here like me that are thinking about doing things but don't have the time to do them or they take years.

javier2112 wrote:

Derek_Stewart wrote:

javier2112 wrote: Super Gold Card is a very expensive and non open piece of hardware and it doesn't support IDE devices.

You can use the 68HC001 as "just a replacement" for the 68008, but it can also be used to expand the RAM beyond 1 Mb. To me, it's ideal in combination with a Qubide interface.

Sounds great, I would like to buy it, but I think this like other ideas, will only stay ideas...

I studied Digital Systems 30 years ago. Since then, I've been working as software developer, so my experience in this area is very limited, which is why I ask in forums like this and others. At this moment I've designed a schematic and I hope to finish the project if I'm able to understand how works microprocessor and memory of the QL.

Hi Javier,

I am sorry about my comments, I was only pointing out there was an existing solution, I do not want inhibit any development into QL hardware or software.

And I apologise for any non-polite comments

I am interested in any enhancement to the QL.

It is possible to run a faster 68008 variant on the QL as long as it is made to look exactly as the original 68008 at 7.5MHz.
To make a long story short, the signals that need to be passed through extra logic are /DS and /DTACK.
The 68008 uses both clock edges to generate various signals, If it is running on a faster clock, many signals will appear before they would on the original CPU but except in the case of the two mentioned above, this is an advantage. The QL motherboard and peripherals only look at /DS to determine when the CPU is accessing the bus, so that has to behave the same as the 68008. The accelerated CPU's /DS has to be somewhat delayed and synchronized to a particular 7.5MHz clock edge. Also, the accelerated CPU must not be able to see /DTACK directly without delaying it, because it will react much faster than the original CPU and finish the access too early. Since the motherboard circuits expect certain signals to behave like the CPU was running at 7.5MHz, logic has to be added to make this happen.
There is the extra complication if the CPU clock is not in some kind of fixed relation with the original 7.5MHz clock. The simplest way is to use the 7.5MHz clock and double it using an edge detector circuit (2 input XOR with the clock signal connected directly to one input and through a resistor-capacitor delay of about 1/4 of a clock cycle to the other). The doubled clock can then be used for the accelerated CPU as well as the 'compatibility logic' since this logic needs to work synchronously with both rising and falling edges of the 7.5MHz clock to emulate the old 68008 properly/
That being said, the speed up one could expect from this is not very big as the only benefit happens when the CPU is doing internal operations. The 68008 is essentially starved of input (instructions and data) due to the 8-bit bus and will run around 30% slower in general than the full 68000, because it needs to do two bus accesses for the same amount of data compared to the 68000. This will not change when the CPU clock is faster as it has to emulate the slower one. For some more complex internal operations the faster clock will have advantages. I would expect perhaps 25% average speed increase for a CPU running double clock.
Regarding the 68020 or higher 68k CPUs, it is fairly simple to interface them to the QL bus using the same logic described above, but these CPUs have extra features that are not directly compatible with the original 68008 and need to be handled in software by configuring extra registers inside the CPU and adding exception handling routines. These need to be set up before the OS even starts up. Things are considerably simpler if the chosen CPU is directly 68000/68008 compatible.

Nasta wrote:Regarding the 68020 or higher 68k CPUs, it is fairly simple to interface them to the QL bus using the same logic described above, but these CPUs have extra features that are not directly compatible with the original 68008 and need to be handled in software by configuring extra registers inside the CPU and adding exception handling routines. These need to be set up before the OS even starts up. Things are considerably simpler if the chosen CPU is directly 68000/68008 compatible.

Minerva supports the 68020 and finds it during initialization. E.g. look at ss_init_asm in the sources.

Peter wrote:Minerva supports the 68020 and finds it during initialization. E.g. look at ss_init_asm in the sources.

There is some limited support, but still even more is patched by the SGC ROM (mostly cache handling and stack frame adjustment).