Nasta wrote:This requires a complete re-design, so no cloning.
Tetroids latest work was more a redesign than a clone already! My thought was, that he might need/want to replace the "INGOT" PLD anyway, sooner or later.
At this point, adding simple graphics could make sense for him. I personally would be okay with the QL modes, no extra video RAM needed. If he can at least add 13 lines to the PLD (RGB, HSYNC, VSYNC, 8 data lines) I think it is doable. That's the route I'd go, if I was very familiar with the SGC as Tetroid certainly is, and had PCB/schematics already in my CAD.
Advantages: No new software timings for network, the good retro-feeling of an actual Motorola 68020 chip, and working microdrives!
Well, the INGOT PLD is a very small and simple one by today's standards but it does have a few unusual features (like full connectivity - it's not block based).
As long as it's on there, it's really a clone. I don't have the EXACT schematic, but I have a fairly good idea of the SGC schematic - some time ago I did look into replacing the INGOT.
Adding graphics means replacing the CPLD with a FPGA. Even with a fairly large CPLD extra video RAM would be needed to implement QL graphics BUT using standard VESA timing, using existing DRAM would cripple the 68020. Once we are speaking FPGA, then there is the availability of internal RAM - if nothing else as a buffer for video data.
Also any change to timing on a SGC does require changes to net and mdv timing, some things are still software based, the advantage being, there is a template that can be modified, i.e. the original SGC.
Regarding CPLDs, today's development tools hardly give the developer any way to leverage the actual architecture of the CPLD and use the available logic in a manner most natural to how it is structured internally in the PLD. Basically, there are many ways to describe what logic has to do, but old ('less clever') compilers would not try to optimize the code you were writing if it was expressed according to the structure of the targeted CPLD. This can be very beneficial to cramming as much logic as possible inside the CPLD, or better said, using as much of the available resources as possible. On Aurora I had usage in the 90+% range on all chips and it was quite easy (though restrictive when it comes to preferred pinout, but those chips were never good at that). The INGOT is one of such examples and it's full connectivity plus some other features make the job of replacing it anything but straightforward.
BTW a curiosity: A large number of pins on GC INGOT are used just as an address buffer for the QL bus, so there is unused logic in that chip. Quite a pity, as re-doing it would have been a great oportunity to support more RAM (and same for the SGC for that matter).
Perhaps the simplest one to replace it with would be one of the Atmel offerings (ATF1500/2500) but since Atmel and microchip have merged, these are on the way out too
Nasta wrote:What I meant is that clone SGCs can still use Aurora, and there are some that can be made available, the non-existence of SGCs being the bottleneck.
Aurora availability would be wonderful, and I would certainly buy one. But to be honest, I always found the Aurora very difficult for the original QL case, which is the only target of this discussion.
So much DIY work is needed to build the required cables and adaptors, that even I would not be in good mood... let alone persons that can not solder. Mind you: Not even the QL matrix keyboard can be attached directly to Aurora.
It's almost like an unmodified Q68 was easier than that... well of course the matrix keyboard adapter would have to be active, not passive then.
Fair enough, but it was never really built for the QL case, just happened to be small enough that it could be built in with a lot of work.
Unless one re-works the whole motherboard, or replaces it, it is not the best basis for 'extreme' expansion. Signal integrity is... well, a lottery.
The original idea was to make a small backplane that would hold 3 or 4 boards, pretty much standard euro size, perhaps with slightly different length constraints.
The ultimate idea was to have a 'largely CPU board' a 'storage management board' and a 'graphics board'. Of course, some related peripherals could be integrated on any of these boards.
So, while we started at SGC + Aurora (with (super)Hermes perhaps) + Qubide, the aim was GoldFire (which put basic peripherals on the CPU board, like keyboard, mouse, serial, parallel, floppy, and optionally sound and ethernet), Qubide II (that could also have flash based media and optionally ethernet), Aurora II (which could also have extra and faster hard drive ports). The possible redundancies were there with a reason, to introduce 16 and 32 bit peripherals, but have 8-bit ones to start with.
Nasta wrote:To be perfectly honest, your implementation of the 68k core is worth further developing, perhaps into a FPGA implementation of some sort of a real 68k CPU 'chip'.
Q68 "as a chip" is indeed an intersting idea, it could be understood as a relatively fast and inexpensive 68K microcontroller. The chip is flash-based, so it could be pre-programmed in a TQFP socket and distributed just like a non-programmable microcontroller. What I don't like about it: There would be so much documentation work for registers, timings, etc. And the QL-style "ROM Loader" inside would also need an overhaul for more general use.
Well, yes, and less peripherals (perhaps none?) but things like interrupt pins. Perhaps a serial (SPI/QSPI) EPROM to load boot code?
Nasta wrote:Given that we know that even the 'tiny' 256b caches in the 020/030 rather significantly improves the speed of QL program code, 2k should be plenty to get the performance to virtually 0 wait state operation.
Unfortunately not, because my implementation is just writethrough.
Wellll... yes, but so is the 68030s. On the other hand, if a long word sized write buffer is included (a simple one, i.e. if a write is attempted while another is in progress, it will have to wait for write completion) it will save a lot of cycles on average. We don't do MOVEM that often
Nasta wrote:1) 32-bit wide RAM bus (so, dedicated memory bus)
So many pins lead to a BGA package, a technology where I'm probably out.
In this case I was thinking no 'on board' peripherals - which would probably save a number of pins, see below...
Nasta wrote:2) fast IO bus, probably multiplexed address/data in some manner.
Mayby this could be done with the amount of pins already available at the extension bus? Theoretically a multiplexed mode, e.g. 16 bit address + 16 bit data could be added, if one of the existing pins gets a secondary function as "address latch enable" signal.
Exactly - but this opens up a comparatively huge address space. Even if you just use a 16-bit multiplexed address/data bus with some control pins, you would have a 128k IO area for expansion. This does sound small, but for IO uses, this is enormous. There is rarely a device that needs more that 256 bytes of directly accessible addresses, most need a small fraction, although often use more just for ease of decoding. This 'link' can be very fast as it's intended to be local, which in turn also means it could be a bit more complex with regards to communications protocol, but then, use less pins - eg. a simplified LPC style bus.
Now, instead of integrating peripherals inside the 'main' FPGA, you could dedicate a separate small FPGA and put in as many peripherals you like or it fits. Or, do that and also convert the 'link' into something resembling a QL bus. I'm sure I don't have to further explain the possibilities
Since peripherals in the Q68 are internally addressed through a reduced bus (i.e. a dedicated portion of the entire addressing space) the aforementioned IO area would just be that same space, extended.
Nasta wrote:Someone did mention a software emulation of a CPU core brought to a hardware level. This is another possibility, again requiring a huge amount of work.
I use software emulation purely as a tool. Gives me no fascination whatsoever. Even going from Motorola chips to FPGA almost hurts emotions, especially when the black case is the target. But at least it is still hardware, and the flash-based solution feels more QL-style than those FPGA boards where a microcontroller soft-loads volatile logic at powerup.
All the best
Well, while I do agree, a long time ago such 'hardware assisted software emulation' did catch my interest, in the form of the Transmeta Crusoe CPU...
On the other hand, it seems that keeping the 68k CPU alive is destined to be a task for FPGAs...
I do have two questions:
1) Is the MOVEP instruction implemented - if yes, then successive bytes on 8-bit peripherals can be efficiently accessed, if such peripherals are capable of some sort of block mode data transfers. (Un?)fortunately using just half the 16-bit bus means code execution from 8-bit memory is not possible.
2) What is the fast SRAM on Q68 used for? Sounds like a great place to put some emulation code into