ULA replacement - could it work in 16-bit mode ?

[Nasta]

[68EC030 solution]

Bruce Lee is choke full of 68030RC33 and similar stuff at $5/piece.
680EC030 is IIRC limited to 16MiB only.

Nope, unlike the EC020 which came in a 100 pin package and had only 24 address lines, the EC030 comes il an 132pin package so they had space for all 32 address lines.

Lots to comment on but little time at the moment. But here is something:

[68SEC000 overclocking]

Depending on mask set, 40MHz seems to be quite common with pins actually driving stuff, and it does not scale perfectly with power supply voltage. Buffering everything of note and a somewhat lower than 5V supply might provide the best performance.
In theory, one could use a common clock, a sh*tload of buffers and a 4-phase bus approach to get 4 of them work on the same bus without contention (or rather, rare contention as operations can take non-multiples of 4 clocks). Multiplexing will reduce this number. I doubt things would work on a cable (even ATA 80-pin like) as the bus gets quite involved. So, napkin calculation, 40MHz=25ns per clock, assuming good buffer control one would lose about 7-10ns of that on the data bus (maybe a few ns on the address bus), leaving about 15ns for some sort of RAM, which points to fast SRAM.
But looking at that, a very tight build on a multilayer board with actual multiplexers might be needed for best performance, plus a fast CPLD to arbitrate and produce proper handshake signals for the 68SEC000 side(s). Lack of on-board cache is a plus in this case as it prevents data incoherency - everything is always made into a true copy in RAM, for all the CPUs to see. Certainly doable but far from trivial.

[Nasta]

Pre-fetch of the next word on the 68k with 16-bit bus has a good chance of being a hit, but the problem is actually the amount of logic needed to detect a hit or miss (lots of address bits to compare).

Long word pre-fetch is actually fairly easy with the 68340 because it actually tells you when it wants to fetch a long word, though there might be a snag...more below. Since t has a 16-bit bus, interfacing regular DRAM to it may offer an opportunity to use a page mode cycle to fetch two 16-bit halves of a long word a bit fasted, and also write a long word faster. However, since long words can be aligned to a word boundary, one must check that the two consecutive words of a long word reside in the same DRAM page, which is always the case if the column address is not all 1s. The DRAM controller has the whole previous memory access to check on that and decide what to do for the next one. Using 4Mx4 DRAM would be the most efficient here so given that each row has 2048 words and only the last one is a problem with long word prefetch, it is almost always possible to do a prefetch and save some time.
The snag here is that it is not clear what happens when data pre-fetched by the CPU32 core is discarded on a change of program flow, the first pre-fetched word of a long word might get discarded and the second word never read. That being said, the 68340 having no cache and a 16-bit bus, it may benefit quite a lot by using the short synch bus cycle, which is 2 clocks total. The problem with that is the address is only available for about 1.5 cycles, and data for less than 1 cycle, which requires either SDRAM (extra problems may be due to 3V3 conversion) or SRAM. Given that 25MHz 340s seem to be able to operate at 30+ MHz, a fairly fast 45ns access time static RAM is a must.

Regarding caches, in a multiprocessor system, having a separate cache for each core can result in a number of problems due to cache coherency if another core is capable (or indeed needs to) change data which is cached in the cache of a separate core. Typically more modern CPUs have a cache snoop option which makes it possible for an alternate bus master to access the cache inside the CPU and update it's contents, but even then the logic gets quite involved.
On the other hand, this all depend on how one structures the system. If a core is never supposed to access parts of memory that can be cached by another core, things get much simpler, and it becomes a software thing. In principle, private data and code for a given core will reside in some space in memory that no other core or job is supposed to access anyway. The one possible problem case is shared re-entrant code if it's not static (unchangeable), which is generally only the case when the code is loaded or purged from RAM, during which access for program execution is not to be done anyway, so this is again software problem. What remains are areas of memory that are 'publicly accessible' by any core and ones dedicated to exchanging data between cores. Since these would be allocated from the general RAM pool, the easy way to get around cache coherency is to have a whole alias of the entire RAM where caching is disabled and in order execution is enforced so data written to RAM is really written without write combining or folding (this is when a value is written to an address by the CPU internally but not yet made into a true copy in RAM, and then another value is written to the same address, which will make an advanced CPU alter the data to the new value before it's actually written to RAM, even without caching). The latter is rarely a problem even if it does happen unless someone is being careless about semaphore structures in RAM.
On the OS level, when such a piece of RAM is allocated, the calling party simply gets the aliased address (with some high order bit set rather than reset) to insure it's working with a true RAM copy of any data, tough (much) slower. Since one expects access to such areas to occur rarely and/or the size of such memory area to be small, in the grand scheme of thins the speed loss is negligible compared to the advantage of having two cores to do useful work. In particular, this approach is the only one viable if the other core is used for all IO operations, since it wants to work on actual memory data anyway.

[Peter]

* Quite large and potentially (very) hot running chip (especially overclocked)

Non-overclocked, the 68EC060 stays cool. (Maybe you had the '040 in mind?)

* FPGA may get obsolete by the time the design is finished since it is practically an impossibility to make this a widely co-operative project.

As I did not see any widely co-operative QL hardware projects in the last two decades, I doubt this makes a difference.

Usually it is a one-man band thing so it will require time, and FPGA manufacturers always want to sell you their latest and greatest.

Agreed in general, but for example the LFXP2 was a choice that turned out available for >12 years already. And no end in sight.

This is about retargetting the hardware to one of the latest ColdFire chips, particulairly V4 is the most interetsing

If some chips could be recovered from printers, and datasheets would leak, the V5 was the absolutely fastest. It runs at > 500 MHz, supports 2-way superscalar execution and has a 64-bit harvard memory architecture.

The MCF5102 Coldfire 'bridge chip' and the only V1 chip is essentially a compiled version of a slightly reduced 68EC040, with only the multiplexed bus mode available and smaller caches.

This is a nice chip and would in my opinion be more interesting than the '030. A good design with SDRAM is likely to perform better than the Q40.

* Used to be fairly cheap, now it is unreasonably expensive and may also be faked (lower grade re-marked as higher grade)

NXP has sold excess inventory directly to this distributor: https://www.rocelec.com/search?q=MCF5102
Should be very reliable. I don't find the price of $24 a problem, given all the other overhead which every QL hardware project has.
I was even tempted a little myself, but if I ever do a design with a Motorola 68K CPU again, it has to be the 68060.

[NormanDunbar]

060-50 is $225 even in ******************. Yikes.

Just call it China. That's its name after all. Thanks.

Cheers,
Norm.

[NormanDunbar]

I'm not triggered, or even Roy Rogers. I was merely pointing out your bring a little too close to getting racist. We also had your "8 bit faggotry" recently as well. You might think it's funny, but it's not.

Stay on topic, stay off the name calling, keep it polite.

Consider this a friendly warning. Do it again, you will be toast. I have the power, and I'd rather not use it. Be nice -- even though you tell me you don't do nice.

Strike one.

If you want to nitpick names, by the way, it (Kung Fu) originated in the Shaolin temple in Henan province.

Cheers,
Norm. (Moderator hat on)

[Nasta]

* Quite large and potentially (very) hot running chip (especially overclocked)

Non-overclocked, the 68EC060 stays cool. (Maybe you had the '040 in mind?)

EC060 consumes the least current and is a much cooler chip than the 040 for sure.
However, I have seen a number of Amiga ccelerators using overclocked (100+ MHz) chips which have substantial heatsinks and a fan somewhere near., but they also up the power supply voltage.
The EC060RC66 consumes ~3W depending on pin loading which is a fairly small amount of heat but if this was made as something like a QL expansion card, it's not trivial - about as much as the regular QL's voltage regulator. Using a switching power regulator however significantly offsets this, and even more if the entire system is 3V3 powered.

If some chips could be recovered from printers, and datasheets would leak, the V5 was the absolutely fastest. It runs at > 500 MHz, supports 2-way superscalar execution and has a 64-bit harvard memory architecture.

As far as I know V5 was only made as application specidic, I doubt documentation is available, but would not be surprised if the chips are. You can find anything in China
The integration is a + and a - but it's mostly about getting it trulz 68k compatible. For now, unexplored territory. Also, as far as I can tell, V4 is also 2-issue superscalar.

This is a nice chip and would in my opinion be more interesting than the '030. A good design with SDRAM is likely to perform better than the Q40.

At the time, this was the base for GoldFire (hence the name). It does need substantial CPLD help to get onto a QL expansion board, but if it was made as a completely independent board, that would be simplified. SDRAM is a must. The reason I abandoned it for 060 was that all of a sudden the supply dwindled and prices went up, while there were plenty of cheaper and more available, though much physically larger 060, but considering the performance, it was a no-brainer.

NXP has sold excess inventory directly to this distributor: https://www.rocelec.com/search?q=MCF5102
Should be very reliable. I don't find the price of $24 a problem, given all the other overhead which every QL hardware project has.
I was even tempted a little myself, but if I ever do a design with a Motorola 68K CPU again, it has to be the 68060.

I would agree and I am surprised to see that low a price (though lack of the 40MHz part). This is exactly the opposite to what happened back then. Had a look to eBay and Ali, and some of the parts are OBVIOUSLY sanded and re-printed. But the price asked for the 68060 is just insane.

[XorA]

Just call it China. That's its name after all. Thanks.
Cheers,
Norm.

Actually, its name is Chongua, I think.
Also, if they are not fussing about this, why is it triggering you ?
Cheers,
Brane

Original post moderated to remove the racism from forum. No more of this behaviour, I see Norman has already given you strike 1, do not try and earn more!

(another mod)

[RalfR]

Shake hands!

[Nasta]

Just call it China. That's its name after all. Thanks.
Cheers,
Norm.

Actually, its name is Chongua, I think.
Also, if they are not fussing about this, why is it triggering you ?
Cheers,
Brane

Original post moderated to remove the racism from forum. No more of this behaviour, I see Norman has already given you strike 1, do not try and earn more!

(another mod)

While I do not normally comment on these things, let me respectfully point out that calling someone a racist is rather more of an offence than referring to a country by way of a very popular and well respected pop culture figure. While I do understand that the appropriate level of decency might be differently perceived depending on where one comes from, and opinions may differ. Aside from Chinese not being a race (and insinuating that may in fact actually be considered racist), being offended on behalf of people you do not know and who almost certainly couldn't care less (*) and bringing it to an ad-hominem is not the way to that decency I just referenced above, just a way to even more escalation. This is the last place on the net I would expect to see this sort of thing, so let's keep it real, civilized and toned down, all involved. Please.

(*) There are plenty of, putting it mildly, derogatory terms for people of Slavic descent, which I am, used widely in every day communication in all of our countries including the Slavic ones, and believe me, I am not going to waste any precious time on this earth being offended over that, though I may well hold a certain opinion of people who use them. Words only hurt if you let them and not being exposed to ones you don't like is not a human right or guaranteed in any way.

[NormanDunbar]

While I do not normally comment on these things, let me respectfully point out that calling someone a racist is rather more of an offence than referring to a country by way of a very popular and well respected pop culture figure.

It wasn't his first offence. Sadly.

I haven't called him racist yet, merely pointed out his "bordering on racist" comment.

Why bother going to all that trouble to be derogatory (spelling) when it's easier to just call it by name?

I'm Scottish, my step father was Italian, my uncle was gay back when it was illegal. I know about racism and homophobia. There's no need for it, and certainly not here.

Thanks for your response, but there have been other complaints to the moderators.

Cheers,
Norm.