Things I learned: it's slower at 25 MHz than 24 MHz due to inbuilt RAM timing, has another sweet spot at 30MHz but needs a heat sink.
Of course, though I know it boots, I can't SEE much
Fun things to do with an MC68EC020....
Fun things to do with an MC68EC020....
Clock it at 24 MHz, and give it 16 MBytes of 32 bit wide SRAM to play with. Put a 32-bit wide Minerva image at $0, so you don't have to do SGC trickery. Try to figure out video since that's forced to be an 8-bit data bus
Things I learned: it's slower at 25 MHz than 24 MHz due to inbuilt RAM timing, has another sweet spot at 30MHz but needs a heat sink.
Of course, though I know it boots, I can't SEE much
Things I learned: it's slower at 25 MHz than 24 MHz due to inbuilt RAM timing, has another sweet spot at 30MHz but needs a heat sink.
Of course, though I know it boots, I can't SEE much
Re: Fun things to do with an MC68EC020....
This post is aimed at the lay person, who hasn't ever designed hardware.
So...
One of the neat tricks of the 68EC020 is that it can use an 8, 16 or 32-bit bus. On the fly. The address decoder can be configured to not just select devices, but also let the CPU know the width of the data bus for that access. The CPU is natively 32-bit all the time, but can freely access 16- and 8-bit areas/devices.
It goes without saying that one access to 32 bits (a long word) is four times faster than four consecutive accesses to 8 bits (a byte), and that moving contents around memory being a big chunk of what computers do, wider is better. Think 4-lane freeway versus single lane country road.
One of the problems with the QL is that it is implemented on an 8-bit data bus. The video, main memory and all devices are structured as 8-bit. Even the ROMs are 8-bit. That means a QL is always running at a quarter of the speed of the same computer with a 32-bit bus.
So, let's get back to the 68EC020. It can access any width on the fly. We can upgrade the memory with 32-bit wide RAM, replace the ROMS with a pair of 16-bit wide EEPROMS or flash. Even with the crappy video, the stock QL would run a LOT faster.
The SGC does all this and more. It has a copy of the video RAM in its own fast memory space. It copies the ROMs containing QDOS into faster, wider RAM. All neat tricks I'm far from capable of copying. However, I think I can get 80% of the results with about 40% of the effort.
Now, if someone wants to do a 32-bit video implementation, we have the beginnings of a computer
So...
One of the neat tricks of the 68EC020 is that it can use an 8, 16 or 32-bit bus. On the fly. The address decoder can be configured to not just select devices, but also let the CPU know the width of the data bus for that access. The CPU is natively 32-bit all the time, but can freely access 16- and 8-bit areas/devices.
It goes without saying that one access to 32 bits (a long word) is four times faster than four consecutive accesses to 8 bits (a byte), and that moving contents around memory being a big chunk of what computers do, wider is better. Think 4-lane freeway versus single lane country road.
One of the problems with the QL is that it is implemented on an 8-bit data bus. The video, main memory and all devices are structured as 8-bit. Even the ROMs are 8-bit. That means a QL is always running at a quarter of the speed of the same computer with a 32-bit bus.
So, let's get back to the 68EC020. It can access any width on the fly. We can upgrade the memory with 32-bit wide RAM, replace the ROMS with a pair of 16-bit wide EEPROMS or flash. Even with the crappy video, the stock QL would run a LOT faster.
The SGC does all this and more. It has a copy of the video RAM in its own fast memory space. It copies the ROMs containing QDOS into faster, wider RAM. All neat tricks I'm far from capable of copying. However, I think I can get 80% of the results with about 40% of the effort.
Now, if someone wants to do a 32-bit video implementation, we have the beginnings of a computer
Re: Fun things to do with an MC68EC020....
Dave,Dave wrote: The SGC does all this and more. It has a copy of the video RAM in its own fast memory space. It copies the ROMs containing QDOS into faster, wider RAM.
I'm sure you're right with the latter, but unsure with the former - I dare to doubt the QL's video logic would be able to access the wider RAM on the extension. Video RAM /needs/ to be in the original QL's memory space for the video to work.
The tricks GC/SGC do with copying the ROM have (I guess) mainly been introduced to cope with copyright issues (something that should no longer be needed), ease of run-time patching the ROMs (something you probably want to avoid) and speed (you can probably do without when you're locating the ROM in 32-bit address space).
If you would succeed in mapping the original video RAM and hardware ports into their original places in the 020's address space 8-bit wide, and leave everything else in 32-bit space you could have a working 68020 QL (tadaa!) without any software mods.
Regards,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Fun things to do with an MC68EC020....
Dave,
Ah, so the Altera is there just for the ROM copying(/ZX8301/2?). That's interesting.
As for the Video, the ZX8301 takes over the bus, reads the 8-bit video data, then releases the bus (I'm assuming)
Two ways to do it :-
* Emulate the ZX8301, just with a 32-bit bus.
* Add a Dual Port RAM for the Video
\=> Video can access the the Dual Port RAM, whilst the CPU can continue working.
I may play around with DPRAM idea for a bit.
Of course there is many ways to skin a cat, I've just outlined two.
YMMV.
Ah, so the Altera is there just for the ROM copying(/ZX8301/2?). That's interesting.
As for the Video, the ZX8301 takes over the bus, reads the 8-bit video data, then releases the bus (I'm assuming)
Two ways to do it :-
* Emulate the ZX8301, just with a 32-bit bus.
* Add a Dual Port RAM for the Video
\=> Video can access the the Dual Port RAM, whilst the CPU can continue working.
I may play around with DPRAM idea for a bit.
Of course there is many ways to skin a cat, I've just outlined two.
YMMV.
Re: Fun things to do with an MC68EC020....
It's most probably also doing the adress decoding (overlaying original QL and video RAM into the external address space in the right places) and the complete bus interface to the "original" QL - it also needs to prevent the 68008 CPU from doing anything nasty and be able to access the QL memory and peripherals - Memory to be able to communicate to the 8749 (I'd guess the buffers need to be in 8-bit memory space) and use the original Video RAM (Can't imagine an external card on the bus can effectively "shadow" this) - Hardware is obviously the Microdrives (we could probably live without) and serial ports (I could probably live withouttwellys wrote:Dave,
Ah, so the Altera is there just for the ROM copying(/ZX8301/2?). That's interesting.
As for the Video, the ZX8301 takes over the bus, reads the 8-bit video data, then releases the bus (I'm assuming)
).And another way to obtain some cat fur: Do it like Miracle's originals do - Use the native video logic and 8-bit video RAM, at least for a start. This would be much slower and crappier to design - and also prevent highter resolution/color depth, but keep compatibility and software the same. (And software has always been the problem with any QL hardware expansion.)twellys wrote: Two ways to do it :-
* Emulate the ZX8301, just with a 32-bit bus.
* Add a Dual Port RAM for the Video
\=> Video can access the the Dual Port RAM, whilst the CPU can continue working.
Of course there is many ways to skin a cat, I've just outlined two.
YMMV.
The Miracle cards also started to use the original video and evolved from there with the Aurora option.
Regards,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Fun things to do with an MC68EC020....
Yes, you can use the native video logic (ZX8301) and the Altera CPLD from the (S)GC - Mapping 8-bit bus from BBQL to 32-bit DNQL. However I'm assuming Dave would like to get rid of the Altera and go fully 32-bit. That's all.tofro wrote: And another way to obtain some cat fur: Do it like Miracle's originals do - Use the native video logic and 8-bit video RAM, at least for a start. This would be much slower and crappier to design - and also prevent highter resolution/color depth, but keep compatibility and software the same. (And software has always been the problem with any QL hardware expansion.)
The Miracle cards also started to use the original video and evolved from there with the Aurora option.
As I said previously, YMMV.
Cheers,
Tim
Re: Fun things to do with an MC68EC020....
First, I understand that the SGC copies the OS ROM into a wide bus area, makes a couple of modifications to the image, then write protects that RAM and restarts the CPU booting from the faster, edited copy of the OS image held in RAM. The OS image in ROM is so narrow, and accesses to that range so frequent that using the original ROM is a huge performance hit.
Second, I understand they do much the same with the video RAM. They map it into a new area on the SGC. Then, on an interrupt, it is quickly copied across into the QL's RAM, and the QL generates the image from that copy. This means the SGC's accesses to its own private RAM are over 12x faster than main-board RAM (24 vs 7.5MHz and 32 bits instead of 8-bits width.)
I don't think Miracle had any copyright issues, because they were making an internal working copy on the same machine strictly for execution purposes.
My inspiration here is the Thor 68EC020 implementation, which I have heard about but not seen. It took the low road of putting a faster CPU in there, giving it some memory, trapping calls into the higher space and handling them quickly. It got a large proportion of the gains of the SGC but with a fraction of the complexity and cost. It would give something slightly better than GC performance, though for CPU-bound operations, it could go a lot faster.
In theory, with the correct permissions and details of all the custom logic, I would be able to make a run of Super Gold Cards using modern SMD technology to reduce power draw. I could give more room to memory, allowing up to the 16MB limit of the EC020 or the much higher limit of the 68020.
Before Nasta left the scene, he was working on a 'Goldfire' card using a Coldfire processor - a particular one could run at 300MHz. He was using a very specific FPGA that was hard to find (I bought 20-some of them and have them here if he ever moves forward on it).
The point is, I can make things which mostly work, and which are not ideal, because I always take the simpler path - using the commonest ICs and the simplest solutions to a problem, even if they cost a little more in components or board space.
I would love to do a re-engineered QL PCB that takes many of the existing components and fits in the existing case, but which gives SGC speed, large memory, a few modern interfaces etc. The catches are drivers are hard to write and it's expensive to make 100 of something (£150 each * 100 = £15,000 investment before the first sale). Can you imagine prototyping and testing? You have to get it 99% working just to even get it to boot - and then you find out keyboard input doesn't work, etc, so you have trouble testing other subsystems... This is why I haven't taken on such a project - just experimented with CPUs.
Reasonably, I could do a 24MHz 8-bit CPU upgrade alone with no fancy trickery for a relatively small amount of money, or with a chunk of faster expansion memory on it for a fair bit more. It's something I'd like to do.
Meanwhile, I'll satisfy myself with selling off donated hardware and getting some smaller projects out there. In a way, the smaller projects are "stepping stones" because they teach me subsystems of the QL. I now have a good familiarity with the 68EC020 in a QL, the ROM system, and expansion memory (I recall memory and disk/parallel interfacing from my time at Sandy but didn't get much further into it since they changed direction and I left)...
Mostly, I enjoy getting things to work, and the mental exercise. I lay in bed at night and do schematics in my head, then in the morning, if they didn't evaporate at the first touch of sunlight, I put them in Eagle and see what I have.
As I'm prone to say.... Fun times!
Second, I understand they do much the same with the video RAM. They map it into a new area on the SGC. Then, on an interrupt, it is quickly copied across into the QL's RAM, and the QL generates the image from that copy. This means the SGC's accesses to its own private RAM are over 12x faster than main-board RAM (24 vs 7.5MHz and 32 bits instead of 8-bits width.)
I don't think Miracle had any copyright issues, because they were making an internal working copy on the same machine strictly for execution purposes.
My inspiration here is the Thor 68EC020 implementation, which I have heard about but not seen. It took the low road of putting a faster CPU in there, giving it some memory, trapping calls into the higher space and handling them quickly. It got a large proportion of the gains of the SGC but with a fraction of the complexity and cost. It would give something slightly better than GC performance, though for CPU-bound operations, it could go a lot faster.
In theory, with the correct permissions and details of all the custom logic, I would be able to make a run of Super Gold Cards using modern SMD technology to reduce power draw. I could give more room to memory, allowing up to the 16MB limit of the EC020 or the much higher limit of the 68020.
Before Nasta left the scene, he was working on a 'Goldfire' card using a Coldfire processor - a particular one could run at 300MHz. He was using a very specific FPGA that was hard to find (I bought 20-some of them and have them here if he ever moves forward on it).
The point is, I can make things which mostly work, and which are not ideal, because I always take the simpler path - using the commonest ICs and the simplest solutions to a problem, even if they cost a little more in components or board space.
I would love to do a re-engineered QL PCB that takes many of the existing components and fits in the existing case, but which gives SGC speed, large memory, a few modern interfaces etc. The catches are drivers are hard to write and it's expensive to make 100 of something (£150 each * 100 = £15,000 investment before the first sale). Can you imagine prototyping and testing? You have to get it 99% working just to even get it to boot - and then you find out keyboard input doesn't work, etc, so you have trouble testing other subsystems... This is why I haven't taken on such a project - just experimented with CPUs.
Reasonably, I could do a 24MHz 8-bit CPU upgrade alone with no fancy trickery for a relatively small amount of money, or with a chunk of faster expansion memory on it for a fair bit more. It's something I'd like to do.
Meanwhile, I'll satisfy myself with selling off donated hardware and getting some smaller projects out there. In a way, the smaller projects are "stepping stones" because they teach me subsystems of the QL. I now have a good familiarity with the 68EC020 in a QL, the ROM system, and expansion memory (I recall memory and disk/parallel interfacing from my time at Sandy but didn't get much further into it since they changed direction and I left)...
Mostly, I enjoy getting things to work, and the mental exercise. I lay in bed at night and do schematics in my head, then in the morning, if they didn't evaporate at the first touch of sunlight, I put them in Eagle and see what I have.
As I'm prone to say.... Fun times!
Re: Fun things to do with an MC68EC020....
Sorry, Dave, I'm afraid I can't agree to that [why does that sound familiar??]Dave wrote:
Second, I understand they do much the same with the video RAM. They map it into a new area on the SGC. Then, on an interrupt, it is quickly copied across into the QL's RAM, and the QL generates the image from that copy. This means the SGC's accesses to its own private RAM are over 12x faster than main-board RAM (24 vs 7.5MHz and 32 bits instead of 8-bits width.)
Any speed gained when setting a single pixel in fast RAM would be lost when 32k of screen would have to be copied under interrupt to slow 8-bit RAM. I'm pretty sure the (S)GC accesses video RAM directly across the bus.
That was what I was trying to say - The (Super)GoldCard entered the market when Sinclair and Amstrad were still very anxious to keep their copyrights untouched. Miracle went the easy way by not including the firmware, but instead copying and patching the original ROM at runtime - The software (and implementing support for quite some different ROM versions, Minerva, international versions.....) must have been a real nightmare. But they didn't have any copyright problems and the additional speed increase. CST went the other way by implementing ARGOS (maybe it was called that name because they were watched by Sinclair through Argus' eyes (Sorry, pun intended)).Dave wrote: I don't think Miracle had any copyright issues, because they were making an internal working copy on the same machine strictly for execution purposes.
Whatever you're doing, keep on - You seem to be quite close to something really usable. Whether actual boards will ever be produced or not - I think whatever you find out about hardware possibilities is fascinating (at least to me) and adding insight to possible ways of re-creating ancient hardware. Once you disclose your designs (I hope you will, once you have something working), someone with the necessary skills and/or access to PCB manufacturing could help himself to a faster QL.
Regards,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Fun things to do with an MC68EC020....
Absolutely, everything I am working on will be 'Open'...
For most of the smaller projects I am happy to order PCBs and components and do assembly, then sell them myself and send half over to Rich at RWAP/SellMyRetro.
Today I received in the mail two 68000s - one FN10 and one FN16. If I can get the Thor video fixed, I might start experimenting with getting it running at double speed. I also read up on better voltage regulation systems than the cheap but inefficient 7805.
This afternoon I was mainly playing with one of my Raspberry Pi toys. Didn't get much done
For most of the smaller projects I am happy to order PCBs and components and do assembly, then sell them myself and send half over to Rich at RWAP/SellMyRetro.
Today I received in the mail two 68000s - one FN10 and one FN16. If I can get the Thor video fixed, I might start experimenting with getting it running at double speed. I also read up on better voltage regulation systems than the cheap but inefficient 7805.
This afternoon I was mainly playing with one of my Raspberry Pi toys. Didn't get much done
Re: Fun things to do with an MC68EC020....
That's absolutely right - my ultimate goal is simply a 32-bit QL. All 32-bit all the time.
With what I have in place or upcoming, I know the following is achievable with light complexity/cost:
68EC020 @ 25MHz
'an amount' of 32-bit RAM -self-refreshing
Minerva in 32-bit ROM (2x16)
Floppy and IDE/CompactFlash storage
10/100 ethernet
What I have no clue about at this time:
Video & Keyboard (these are essentials)
Serial/Parallel/Joystick
No desire to get microdrives or QL net working
USB
Of those, I think USB is the most interesting. I believe a 'simple' USB host could allow software solutions to adding a keyboard.
I am not alone in that I do love real hardware, and the steady sales at SellMyRetro.com back that up. That said, I also believe that emulation is the future. I would love to help test and improve anything that runs on a Pi. I have two - one is replacing my clunking quad athlon server, using 1/80th the power, and the other will do double duty as a QL and Risc PC.
With what I have in place or upcoming, I know the following is achievable with light complexity/cost:
68EC020 @ 25MHz
'an amount' of 32-bit RAM -self-refreshing
Minerva in 32-bit ROM (2x16)
Floppy and IDE/CompactFlash storage
10/100 ethernet
What I have no clue about at this time:
Video & Keyboard (these are essentials)
Serial/Parallel/Joystick
No desire to get microdrives or QL net working
USB
Of those, I think USB is the most interesting. I believe a 'simple' USB host could allow software solutions to adding a keyboard.
I am not alone in that I do love real hardware, and the steady sales at SellMyRetro.com back that up. That said, I also believe that emulation is the future. I would love to help test and improve anything that runs on a Pi. I have two - one is replacing my clunking quad athlon server, using 1/80th the power, and the other will do double duty as a QL and Risc PC.