Ram vs Rom speed

[meynaf]

Originally Posted by Thomas Richter

No version of the 68030.library or 68020 was ever a no-op, excuse me.

Err, what? The library works both for EC and non-EC. Unfortunately, there is no reliable way how to detect a EC processor.

Even if they aren't technically no-op, they look a lot like it. Only version i had (and didn't keep) was very small. And I've never needed that on my B1230. No visible effect.
So what do they do exactly ?
If all they do is activate the mmu to solve some problem, they won't work on EC. Maybe they turn data burst off ? Then it's no-op, as it's not active at startup (and cpu command can do this anyway). What else ?

[Lisko]

Originally Posted by meynaf

Even if they aren't technically no-op, they look a lot like it. Only version i had (and didn't keep) was very small. And I've never needed that on my B1230. No visible effect.
So what do they do exactly ?
If all they do is activate the mmu to solve some problem, they won't work on EC. Maybe they turn data burst off ? Then it's no-op, as it's not active at startup (and cpu command can do this anyway). What else ?

I surely know less than Thomas but 68030 lib fixes an errata on the cpu found by Motorola years after release. It's an extremely corner case but in some circumstances could cause the cpu to crash. The fix doesn't involve the mmu and addresses the issue on both EC and non-EC cpus. For some boards missing the cache inibit for chip's data cache it uses the mmu to set correctly the chip's caching modes.

[meynaf]

Originally Posted by Lisko

I surely know less than Thomas but 68030 lib fixes an errata on the cpu found by Motorola years after release. It's an extremely corner case but in some circumstances could cause the cpu to crash. The fix doesn't involve the mmu and addresses the issue on both EC and non-EC cpus.

I can't see a thing that could be fixed by software on 030 without MMU.

[Thomas Richter]

Originally Posted by meynaf

So what do they do exactly ?

They open the mmu.library, and if that doesn't find an MMU, they activate the TTx registers to set the entire 24bit address domain non-cachable. 32bit ram remains cache-enabled. But see above, EC detection is not fool-proof, you potentially have to insert a "MMU off" in the envarc:MMU-COnfiguration.

[roondar]

Originally Posted by sandruzzo

@roondar

Thanks. That's why even a little fast ram on Amiga can almost double cpu performances

Yeah, if DMA load is particularly heavy then some Fast RAM will definitely improve CPU performance by a large degree (much more so if you're running 68020+), though doubling is probably a bit of an overestimate for the 68000. And if you code for using Fast RAM effectively, you should be able to improve Blitter performance as well by letting it blit during all those cycles the CPU would normally be busy.

Originally Posted by Thomas Richter

No version of the 68030.library or 68020 was ever a no-op, excuse me.

Off-topic, but I would like to know: where exactly can I find the 68030.library? I don't think I've ever seen it on any of my systems and I have several 68030's. Sounds like it could be useful.

[meynaf]

Originally Posted by Thomas Richter

They open the mmu.library, and if that doesn't find an MMU, they activate the TTx registers to set the entire 24bit address domain non-cachable. 32bit ram remains cache-enabled. But see above, EC detection is not fool-proof, you potentially have to insert a "MMU off" in the envarc:MMU-COnfiguration.

And that's all ?
So either they can't do a thing at all (not even half working MMU that can be used) or they slow the machine down activating the MMU to fix a rare corner case ?
All that, taking the risk of a crash due to potentially defective MMU in EC cpu ?
Sorry, but this doesn't sound very useful to me.

[Bruce Abbott]

Originally Posted by meynaf

And that's all ?
So either they can't do a thing at all (not even half working MMU that can be used) or they slow the machine down activating the MMU to fix a rare corner case ?
All that, taking the risk of a crash due to potentially defective MMU in EC cpu ?
Sorry, but this doesn't sound very useful to me.

EC doesn't have a (properly working) MMU, so it shouldn't be used at all. But if CIIN isn't properly asserted for non-cachable memory then you have limited choices - disable the data cache entirely, or try to use the faulty MMU to exclude that memory.

Or just avoid code that is sensitive to caching - but that could penalize other systems that have better hardware. To avoid that in the OS you might need duplicate code to handle the broken accelerator cards, potentially slowing down critical sections and wasting ROM space, or separate versions of the OS for different hardware configurations.

CPU libraries are used to avoid having multiple OS versions just to handle buggy cards or new CPUs. We don't want to be like the Mac, which wouldn't work if you didn't have the exact OS version with all the correct patches for your model!

[meynaf]

Originally Posted by Bruce Abbott

EC doesn't have a (properly working) MMU, so it shouldn't be used at all. But if CIIN isn't properly asserted for non-cachable memory then you have limited choices - disable the data cache entirely, or try to use the faulty MMU to exclude that memory.

Yes but this isn't useful for accelerator boards that aren't broken.

Originally Posted by Bruce Abbott

Or just avoid code that is sensitive to caching - but that could penalize other systems that have better hardware. To avoid that in the OS you might need duplicate code to handle the broken accelerator cards, potentially slowing down critical sections and wasting ROM space, or separate versions of the OS for different hardware configurations.

Well, the only problem i can see is reading from chipmem - which is slow and ought better be avoided.
And when we need to do it, we have CachePostDMA from exec that can take care of it. In fact, perhaps making chipmem not cacheable at first place isn't such the great idea it looks like.

Originally Posted by Bruce Abbott

CPU libraries are used to avoid having multiple OS versions just to handle buggy cards or new CPUs. We don't want to be like the Mac, which wouldn't work if you didn't have the exact OS version with all the correct patches for your model!

The fixes for faulty boards shouldn't alter the working of non faulty ones. Activating the MMU on a 030 does not come for free in terms of performance.

[Thomas Richter]

Originally Posted by roondar

Off-topic, but I would like to know: where exactly can I find the 68030.library? I don't think I've ever seen it on any of my systems and I have several 68030's. Sounds like it could be useful.

Part of 3.2 or the MMULib package on Aminet.

[Thomas Richter]

Originally Posted by meynaf

And that's all ?

That's all in terms of "which CPU specific issues are there to fix for the 68030", and that is the job of the cpu libraries. The 68040 library is longer since it also has to provide the fpsp package, and the 68060 is even longer since it also includes the isp.

Originally Posted by meynaf

So either they can't do a thing at all (not even half working MMU that can be used)

Have you actually read what I have written? They always do *a thing*, or one of two possibilities.

Originally Posted by meynaf

or they slow the machine down activating the MMU to fix a rare corner case ?

They fix a CPU problem, yes.

Originally Posted by meynaf

All that, taking the risk of a crash due to potentially defective MMU in EC cpu ?

If there would be a crash, the crash would be caught upon startup and would lead to an EC detection. But what a defective MMU can do otherwise we do not know. The user can setup the library accordingly for an EC processor - that's the best that is possible ATM, or the vendor of a board can provide such a configuration as part of the installation. In particular setups, a EC CPU will not work at all, no matter what the software setup is. A CVision3D in a zorro-III slot with an EC CPU is such an example - this setup cannot be made working at all. Ok, turn off all caching if you accept this as solution.

Originally Posted by meynaf

Sorry, but this doesn't sound very useful to me.

Getting working bridgeboards and working graphic cards sounds very useful to me.

[meynaf]

Originally Posted by Thomas Richter

Have you actually read what I have written? They always do *a thing*, or one of two possibilities.

No they can't do anything if there is no MMU (that can be at least partially used).
Or tell me what they can do in that case ? Get a line-F exception while trying a pmove to tt0/tt1 ?

Originally Posted by Thomas Richter

Getting working bridgeboards and working graphic cards sounds very useful to me.

Yes but i wrote "to me". With my B1230, no room for these.
Besides, if these are properly designed there is absolutely no reason for incompatibility with a 030. Original hardware works fine, these should too.

[Thomas Richter]

Originally Posted by meynaf

No they can't do anything if there is no MMU (that can be at least partially used).

Yes, they can. Once again: If no MMU is detected, the entire 24-bit address space is set to cache-inhibited by means of the TTx registers. These registers are *also* present on the EC processors. Unfortunately, they are very coarse (i.e. no way to enable caching on 16-bit fast RAM).

Originally Posted by meynaf

Yes but i wrote "to me". With my B1230, no room for these.
Besides, if these are properly designed there is absolutely no reason for incompatibility with a 030. Original hardware works fine, these should too.

Oh, do you think any VGA chip vendor cared about the Amiga, the 68030 and its hardware bugs? The S3Virge, just to name one particular problem, has the interrupt status and interrupt request clear register and the blitter done flag both in a 32-bit aligned 32-bit word. Now what? Sue S3 for not being compatible with a 68030 bug?

[meynaf]

Originally Posted by Thomas Richter

Yes, they can. Once again: If no MMU is detected, the entire 24-bit address space is set to cache-inhibited by means of the TTx registers. These registers are *also* present on the EC processors. Unfortunately, they are very coarse (i.e. no way to enable caching on 16-bit fast RAM).

I doubt. These registers are MMU registers. This means : no working MMU, no working TTx. If MMU is completely disabled, say hello to line-F when attempting to use PMOVE instruction.
What you wrote here implies a partial MMU is always there and working.

Originally Posted by Thomas Richter

Oh, do you think any VGA chip vendor cared about the Amiga, the 68030 and its hardware bugs? The S3Virge, just to name one particular problem, has the interrupt status and interrupt request clear register and the blitter done flag both in a 32-bit aligned 32-bit word. Now what? Sue S3 for not being compatible with a 68030 bug?

The chip isn't alone on the board. It is certainly possible to circumvent that by hardware.
Of course a properly written hardware abstraction layer can also avoid this kind of problem.

[Thomas Richter]

Originally Posted by meynaf

I doubt.

Then, I suppose, you better read the 68030UM from Motorola.

Originally Posted by meynaf

The chip isn't alone on the board. It is certainly possible to circumvent that by hardware.
Of course a properly written hardware abstraction layer can also avoid this kind of problem.

Will you reroute the existing CVision3Ds in the field? Will you rewrite the CyberVision software?

[meynaf]

Originally Posted by Thomas Richter

Then, I suppose, you better read the 68030UM from Motorola.

I did. Having found nothing mentioning that, i suppose you should read it too - and if you find it, it would be nice if you directly tell (not just me, but everyone) at which page in said manual this is documented. As you have to admit this is at least weird.
https://www.nxp.com/docs/en/referenc.../MC68030UM.pdf
https://www.nxp.com/docs/en/referenc...C68EC030UM.pdf

Originally Posted by Thomas Richter

Will you reroute the existing CVision3Ds in the field? Will you rewrite the CyberVision software?

Maybe not. Yet new ones can perfectly take that into account.
Patching existing software shouldn't be that hard either.

[Thomas Richter]

Originally Posted by meynaf

I did. Having found nothing mentioning

Check closer. The TTx registers always exist. They have a different name on the ECs, though the register mapping is exactly identical (obviously).

Originally Posted by meynaf

Maybe not. Yet new ones can perfectly take that into account.
Patching existing software shouldn't be that hard either.

Then, who's stopping you? I'm personally not touching third party software I do not own and whose copyright I do not have.

[meynaf]

Originally Posted by Thomas Richter

Check closer. The TTx registers always exist. They have a different name on the ECs, though the register mapping is exactly identical (obviously).

Sorry, but even EC030 addendum doesn't mention anything like that.
In the regular manual i don't see anything EC related.
So, exact location please.

Originally Posted by Thomas Richter

Then, who's stopping you? I'm personally not touching third party software I do not own and whose copyright I do not have.

Nobody's stopping me. It's just that it won't happen until i have such a configuration (i.e. probably never).

[robinsonb5]

Originally Posted by meynaf

Sorry, but even EC030 addendum doesn't mention anything like that.

What you're looking for are called the Access Control Registers on EC030 - see page 23 (1-12) of this document: https://www.nxp.com/files-static/arc.../M68000PRM.pdf

[meynaf]

Originally Posted by robinsonb5

What you're looking for are called the Access Control Registers on EC030 - see page 23 (1-12) of this document: https://www.nxp.com/files-static/arc.../M68000PRM.pdf

I should have guessed i needed to hunt that in 68000 manual...
Ok, it's an oddity i didn't know of.

[Solo Kazuki]

Originally Posted by meynaf

Atari ST has a cartridge connector and it hasn't been used that much...

Moreover, cartridge to what port? Extension port which only older Amigas have? Amiga 600 and Amiga 1200 have PCMCIA here and... it can be used to put RAM here so no problem to use ROM with small NV-RAM to cartridges (or rather card-ridges? ). But no one made such since A600 and A1200 have IDE controller, and it made cartridge-like media little obsolete.