Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

Recent Posts

Pages: [1] 2 3 ... 10
1
Amiga Software Issues and Discussion / Missing icons
« Last post by Brunty on February 26, 2020, 08:50:26 PM »
Hi peeps, I'm having an odd issue with missing icons. OS 3.9 with the boing bags, PeterK icon library etc.
The weird thing is that when I open a drawer I intermittently don't get all the icons displayed, but the text will appear. If I click where the icon should be, it'll appear in it's clicked form, click elsewhere and it stays as it should.
Any ideas? Oh, also suffering really bad stability problems, freezing mostly, and seems worst when the icons don't appear as they should!
2
It looks like Tabor will NEVER be released.
3
I believe to remember the Tabor was meant to be produced in Britain?
4
Amiga Software Issues and Discussion / Re: 68060.library update
« Last post by Thomas Richter on February 25, 2020, 04:44:06 PM »
It's a bit more complicated than that. CachePreDMA() and frieds and access error issues are related, but not identical. Consider for example debugging. For a completely harmless instruction like
Code: [Select]
fmove.d fp0,(a0)
the fpsp may be run if the operand may require denormalization. If a0 is invalid, for example NULL, a debugging tool should show the instruction as the source of the trouble. Unfortunately, if the CPU library does not play well, it will instead show an instruction in the fpsp as fetching the invalid address. As this is run in the supervisor, the task context is lost, and the stack trace is also lost.

Concerning MuFastZero: Depending on its application, it may remap quite a bit more than the zero page, depending on where exec and expansion are placed.

Why it is "wise" not to properly support MMU remapping remains rather opaque to me, really.
5
Amiga Software Issues and Discussion / Re: 68060.library update
« Last post by SpeedGeek on February 25, 2020, 04:19:00 PM »
The original 68040.library does not run into this borderline case because it does not exist on the 68040, that's quite simple. The issue exists on the 68060 since it does not, unlike the 68040, attempt to fetch operands into its stack frame. The mentioned call-outs are only available on the 68060, for reasons.
This mentioned 68060 call-outs again assume virtual memory is enabled, if the CachePre/PostDma() functions don't support it then there is no practical need for the call-outs either.

If it doesn't work correctly because it does not satisfy specs, it does not work correctly. That's as simple as it goes.

"But these functions are wrong - but look how fast they are!". Hey, everyone can write "fast functions" violating the specs. That's not an art. The issue does not only exist for virtual memory. It also exists for any type of MMU remapping, such as MuFastZero or MuMapROM. In both cases, DMA will be run from the wrong addresses.

The specs are conditional for virtual memory support, so most CPU library developers wisely exercised the option not to support it. The Zero page is not a valid memory location for DMA but the ROM could support read only DMA. Now, if the remap is a mirror image of the physical ROM then there is no problem for a DMA read (without translation).

So, now we come to the extremely uncommon case of the unreliable MMU hacks for loading Kickstart image files... and of course a DMA read will fail here (without translation) but your giving up some really impressive performance improvements to maintain such an uncommon case.  ::)     
6
Amiga Software Issues and Discussion / Re: 68060.library update
« Last post by kolla on February 25, 2020, 03:32:54 PM »
Justified and Ancient, oh the irony....
7
@thread

Quote
Matthew Leaman informed me that, due to factory shutdowns, several of his new classic Amiga hardware products have not been shipped or are now greatly behind schedule. A-EON Technology's A1222 early Adopter development and release schedule has similarly been affected and Matthew thinks the delays could push production into the third quarter of this year.
and

Quote
Matthew also confirmed that the AAA Bundles themselves will now be shipped out the first week of March.

Source Trevor's blog - February 24, 2020

#6
8
Amiga Software Issues and Discussion / Re: 68060.library update
« Last post by Thomas Richter on February 25, 2020, 03:21:33 PM »
This library, the original C= 68040.library (and ALL 3rd party libraries EXCEPT your mmu.library) don't support virtual memory.
The original 68040.library does not run into this borderline case because it does not exist on the 68040, that's quite simple. The issue exists on the 68060 since it does not, unlike the 68040, attempt to fetch operands into its stack frame. The mentioned call-outs are only available on the 68060, for reasons.

I assume that's one of the reasons (besides your own EGO) why you trolled against FastCache040+ when it was first released (even though the documentation clearly warned users about this).
If it doesn't work correctly because it does not satisfy specs, it does not work correctly. That's as simple as it goes.

What is interesting, is that since you already added the logical to physical address code to the mmu.library you failed to realize this simple test can determine the choice of using the dog slow CachePre/PostDMA() functions or the much faster functions.
"But these functions are wrong - but look how fast they are!". Hey, everyone can write "fast functions" violating the specs. That's not an art. The issue does not only exist for virtual memory. It also exists for any type of MMU remapping, such as MuFastZero or MuMapROM. In both cases, DMA will be run from the wrong addresses.

9
Amiga Software Issues and Discussion / Re: 68060.library update
« Last post by kolla on February 25, 2020, 02:24:22 PM »
Why don't you guys just form a committee or something... share the code, peer reviews, ask for votes... (lolz)
10
Amiga Software Issues and Discussion / Re: 68060.library update
« Last post by SpeedGeek on February 25, 2020, 01:47:53 PM »
A common problem is that its CachePre/PostDMA() functions do not work properly - they need to translate logical to physical addresses and not just pass them through. Another typical problem is the exeception generation of floating point exceptions in case its target address is not mapped. In such a case, the 68060.library needs to generate an access error of the right address - namely the address of the EA in the code being emulated. The original mot sources have call-outs ("hooks") to get this work done, but most - if not all (but one) - 68060 "optimizations" simply drop these call-outs and then generate an exception that is coming from the wrong code path, namely within the 68060.library, and not within the user code.

Thus, while I haven't tested, I afraid that we have here a library that falls into the same pitfalls the P5 libs fell into, namely not handling exceptions properly. It is a case that does not typically happen, but in case we would have virtual memory, would fail miserably. The Mu-based libs have been carefully crafted to handle such cases correctly, thus do not generate exceptions by executing code itself, but creating artificial exceptions that (seem to) come from the user code, such that the Os layer can handle them correctly.

Here we go again... ::)

This library, the original C= 68040.library (and ALL 3rd party libraries EXCEPT your mmu.library) don't support virtual memory. I assume that's one of the reasons (besides your own EGO) why you trolled against FastCache040+ when it was first released (even though the documentation clearly warned users about this).

What is interesting, is that since you already added the logical to physical address code to the mmu.library you failed to realize this simple test can determine the choice of using the dog slow CachePre/PostDMA() functions or the much faster functions.

So, far I've never received a single request to support virtual memory (Thanks to many smart users!), but I did quote it as one of the reasons why TurboMMU040+ doesn't support the mmu.library.  ;)
     
Pages: [1] 2 3 ... 10