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).
Of course, but this thread is about a drop-in replacement for the 68008, not about the SGC with its extra ROM and other magic.
I once built a 68020 card for the QL as a replacement for the 68008. And believe me, it was a pain to patch QDOS to make it work at all. Minerva at least boots...
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).
Of course, but this thread is about a drop-in replacement for the 68008, not about the SGC with its extra ROM and other magic.
Well, I for once don't think the SGC patches are made just for fun, so they might be needed for a "drop in replacement" also. Mind you, it's mainly invalidating the code caches on re-schedule and after traps (no magic since I documented everything). So things will probably mostly work as you experienced, self-modifiying code isn't that common and the cache is small enough that one might get away with not invalidating it after loading an EXE, but it might still impact compatibility in unexpected ways. Including the code in the ROM itself to make it full 020 compatible isn't even that difficult, if space permits. Just something one should have in mind when doing this stuff.
mk79 wrote:Well, I for once don't think the SGC patches are made just for fun, so they might be needed for a "drop in replacement" also.
Of course, and not only the same patches. But it would be no SGC, which means the extra ROM doing those patches is not there. Minerva is at least something that has basic 68020 support "as such", independent from the specific Miracle hardware.
If the cache is not enabled (and by default it's not), interrupt stack, stack frames and privileged instruction emulation have to be added for the 020 to behave like a 000/008.
There are, however, several CPUs that can work like a 68008:
1) 68EC001
2) 68SEC000
3) 683xx (not all members)
The latter are quite interesting. Some have an embedded 000/EC001 core that can select bus width. Others (much more interesting) use a CPU32 core, which is actually based on the 020 but does not have the extra stack pointer, complex address modes and bit field manipulation instructions, but depending on the version have a 16 or 32-bit wide bus with automatic bus sizing (so it can work on an 8-bit wide data bus), and faster external and internal cycles. Sometimes also a full 32-bit address bus. Instruction execution requires less clock cycles than the original 000 core so it is faster at the same clock. However, it does not have a cache so having fast memory is required to get the most performance out of these (and they do come close to 020 cached performance even without a cache if you can use the fastest memory access mode).
Some of these integrated CPUs have a lot of interesting on-chip hardware as well. And the best part is 100% 68000 software compatibility.
Could the 68SEC000 be connected to the QL 68008 socket with an appropriate DIP to QFP adapter board, with the possibility of using it own un-contended ram?
Could the 68SEC000 be connected to the QL 68008 socket with an appropriate DIP to QFP adapter board, with the possibility of using it own un-contended ram?
It is directly compatible when powered with 5V and the 8-bit bus width is selected. Some extra wiring is required (wiring together interrupt lines, using /AVEC instead of /VPA). Adding RAM however requires a bit of logic and I outlined how to do it in a thread fairly recently. Up to 2MB can be added with some small caveats in the logic keeping everything compatible with most OS versions. That being said, Minerva is the best suited here as it removes a couple of relevant bugs regarding testing and determining RAM size as well as scanning for peripherals.
Again, if a higher clock speed is needed, the rules I already mentioned in earlier posts apply if the old ULA chipset is to be used.
*grins* I worked with Nasta to design a 4M DRAM card that uses a PLCC 68000. That has some extra address lines. The project got far along but the logic for refresh never got completed. I then got a large supply of 2Mx8 5V SRAMs so I replaced the 68000 with a 68SEC000 and the 4MB DRAM with SRAM. No refresh.
I have gone a bit further and used 8MB PSRAMs that are 3.3v, using level shifters.
Either way, one nice benefit of the SEC model of the 68000 is that it is a fully static design. You can change the clock rate on the fly. This opens up the possibility of running it at 30MHz (if cooled it can do 50 MHz) and then when doing an access into the QL's address space, slowing it back down to 7.5 MHz. Using a modest CPLD, it is quite easy to have two clocks and a switchover logic that when the QL is addressed the clock switches over without a runt clock. This does more or less limit the CPU to running at a whole multiple of the 7.5 MHz core clock. That does resolve all DTACK timing issues in a rather brute force way.
The alternative that Nasta's mentioned often is a DTACK generator. To use internal logic that tracks the set-up time the QL needs to latch input data correctly, or to allow the output data to settle for the CPU to latch. This can be divided into two paths. The first is the SGC's state machine. The second is a special DTACK handler that holds the QL bus during those CPU cycles. In the second case, it's not just a matter of counting clock, alas. Different instructions can take a different number of cycles but almost exclusively when accessing video it's JUST writes (as reads will come from shadow RAM) and for IO it's read and write cycles.
Having a DTACK generator does allow much more freedom to use non-multiple CPU frequencies. That said, performance while accessing the QL IO and doing video writes can match or be slower than the state machine.
Where it really gets entertaining is that some QL expansions are capable of running much more quickly than the base QL. If you know the speed the card is capable of bus transactions, you can include the peripheral space in the DTACK scheme and optimise per card.
A QubIDE card with top speed components/GALs will happily run at 30 MHz, if the drive supports it.
This is the longest thing I have ever typed on my phone!
