The Sinclair QL Forum

I have an HyperCache 030 board for my MegaST 4 and the difference between CACHE_ON and CACHE_OFF is enormously.

I bought this recently and I have to say it hugely exceeded my expectations. Some great articles, and the QL does get a few mentions.
Standout articles are:
* the tech tips section that has lots of peripherial news includuing almost 2 full pages onn the vDrive (Speccy and QL discussed), an ethernet adapter for the Sepctrum , etc,
* a large section on Spectrum Next games,
* the "Making of a Game: Neadeital" - basically an homage to Tir Na Nog - looks superb and gets awarded a Crash Smash elsewhere in the annual.

The production quality is top notch, the pages are crammed full of goodies. Game reviews are a mixture of retrospectives and loads on the buoyant current Spectrum scene. TBH, although I knew that the Spectrum scene was active, I had no idea quite how many quality titles were being created.

I bought it directly from the publisher (https://fusionretrobooks.com/) and it was delivered within the week. Funnily enough, I spotted in the info on page 1 that Crash is now owned by Future Publishing, where I worked as a developer for several years. If I was still there I could have got the PDF to this fo free!

68EC030 does not have the MMU, and has 4GB of flat addressable space. It has dynamic bus sizing.

68[S|V]Z328 was the last and fastest family to have dynamic bus sizing, but it wasn't done on a per cycle basis. The 33 and 66MHz parts have four configurable chip selects, and the selects can be register configured to be 8- or 16-bit. Accesses for those selects can also be configured to have either an externally generated or internally generated DTACK. That DTACK could be delayed from 0 to 12 clock cycles. So it is an excellent CPU to mate with fast 16-bit SRAM or slower 8-bit system, just by making all accesses to the BBQL 8-bit with internally generated slow DTACK.

Of course, a 68EC030FN40 with caches will be a bit faster than an FLX68000 at 66MHz that only has a few bytes of instruction cache.

How compatible is the 68K core in these 68[S|V]Z328? - I know the coldfire project ran into some issues with instructons not behaving in the same way, which broke compatibility with QL software. A lesser issue occurs with 68020/68030 and using instructions that have become priveleged - these have to be trapped and the correct code run to simulate the effect of the original instruction.

Pr0f wrote:How compatible is the 68K core in these 68[S|V]Z328?

The 68328 (or, rather, the Dragonball) has nothing to do with Coldfire, and doesn't share its incompatibilities.

It shares the same fully static CPU core with the 68EC000, which means it supports selectable bus size. There's just "a whole lot more stuff around it" (UART, SPI bus, GPIO, RTC, Timer, LCD controller, ....)

Thanyou for clarifying

Not directly QL-related, but it's connected to the TV alongside my computer desk to keep me entertained while QLing:

tofro wrote:

Pr0f wrote:How compatible is the 68K core in these 68[S|V]Z328?

The 68328 (or, rather, the Dragonball) has nothing to do with Coldfire, and doesn't share its incompatibilities.

It shares the same fully static CPU core with the 68EC000, which means it supports selectable bus size. There's just "a whole lot more stuff around it" (UART, SPI bus, GPIO, RTC, Timer, LCD controller, ....)

I dropped a VZ on an adapter board and ran it at 7.5MHz. A lot of the accessories are turned off by default. The registers to activate them are very high in the memory map so they don't interfere, which is nice. A couple of bits do need intervention to configure before the part could be considered "QL compatible"... It will likely need a double boot system like the original Gold Cards. I've been playing with configuring the DTACK/CS functionality to see if it's elastic enough to work with fast RAM and at the same time work with the QL local bus. So far I have learned that the examples in the manual/datasheet are EXCELLENT and I have had it work with a pair of 2Mx8 SRAMS and a 2x2 array of 2Mx8 DRAMs with functional refresh from the inbuilt DRAM controller.

It does have good potential to create a Gold Card type device, but given the ready availability of 68EC030 parts that is simpler to design around and also has higher throughput at 40MHz than a Dragonball at 66MHz. Porting the INGOT code to a more modern CPLD and making edits to support more memory, the 030 is a much more appealing target. It also has the advantage of leveraging the existing GC ROM 2.49, which already exists.

Dave wrote:Freescale was having another clear-out and I got a half pallet of this stuff.

Cool... you are wizard in sourcing parts.

Dave wrote:These are fast and run cool, but MAPBGA144 packages:

After soldering Qzeros manually, I've become quite reckless regarding BGA packages, so I'd find it exciting if really fast. Unfortunately 66 MHz is quite misleading... not sure it would even beat the SGC. Better find cheap 66 MHz 68EC060 in TBGA304.

Dave wrote:It turns out Motorola, then Freescale, would buy their own ICs on the open market from shady sellers and test them to see if they were genuine, counterfeit, remarked or fake. They would shut down illegitimate sellers, and remove remarkers from the supply chain. All the good ICs they got would be kept in case there were materials handling problems. And now they're mine, for basically free. All tested and work great!

Intersting story.

Dave wrote:Of course, a 68EC030FN40 with caches will be a bit faster than an FLX68000 at 66MHz that only has a few bytes of instruction cache.

Not just the caches, but the 68EC030 has 2.6 times faster bus throughput per clock. So even with zero-wait RAM, the FLX68000 has no chance.

Today I received a new router. Well, for a 50E router and a 9E per month internet subscription, I guess it works pretty well.