cdimauro Quote:

It's possible both on software and FPGA side, but provided the schematics to perfectly reproduce the original chips. WinUAE seems to have a cycle-accurate 68000 emulation, and the upcoming version has a very accurate chipset emulation thanks to the use of some (unfortunately not all) schematics found for Alice. But nothing prevents to have a perfect emulation of all other components (included a 68EC020), getting their schematics.

Windows can not maintain timing. A bare metal system like emu68 or a RTOS can. A cycle exact 68000 in Windows may be a goal but it is not obtainable.

cdimauro Quote:

Such 68k instructions aren't atomic: the RMW cycle doesn't guarantee that the memory location is atomically updated. Only TAS, CAS, CAS2 68k instructions are atomic, but even those can be emulated by architectures having load/store atomics (not x86/x64: this requires transaction extensions, which are a bit more complicated to be used).

We have talked about this before. All RMW instructions are atomic in the sense that the instruction and memory access is one uninterruptible instruction. This used to be the definition of an atomic instruction before multicore. The 68k Amiga is a preemptive multitasking system which can be interrupted after any instruction yet it is safe to use atomic RMW instructions without disabling interrupts. Replacing with RISC load+add+store instructions is not safe and the locked versions are much slower than a simple CISC atomic RMW instruction. A CISC atomic RMW instruction is not safe with SMP using the modern multicore meaning of an atomic instruction. A locked atomic instruction is needed for SMP that locks the memory bus so no other cores can access memory. In order to get SMP working on the 68k Amiga, pages marked as shared (using MMU) could be upgraded to use locked RMW instructions while non-shared pages would continue to use regular RMW instructions for better performance. A couple of more little hardware tricks and I believe SMP would be possible on the 68k Amiga with most OS friendly software and minimal changes for most programs that do not work. PPC AmigaOS 4 has needed extensive and performance killing changes including Load-Acquire/Store-Release loops in place of 68k RMW instructions and memory access fences everywhere due to the weak memory consistency model with a decade of failure. RISC architects think they have an advantage by rearranging loads/stores but after all the fences they may be slower than a stronger TSO like memory consistency model common for CISC. The 68060 performs all loads and stores in program order. Multicore atomics are sometimes simpler on x86(-64) and code written for x86(-64) sometimes has problems with RISC weak memory consistency models too.

@matthey

I think you guys are going way over the top, I mean I dont own a FPGA system yet, mainly due to in my humble opinion, emulation, particularly WinUAE, is very good.

We already seen for the vast public the ARM min Console in shiny mini cases with software emulation is good enough, true you will always get your die hards and the odd 5% of software not quite working as it should maybe, but software emulation is good enough for most people.

However now that cheaper FPGA systems are appearing however, I am getting more interested in checking it out and really seeing if I notice a difference. Plus it does seem to please some die hard.

Plus I was thinking more of a Siamese System / Rabbit hole type solution, where AmigaOS5 would run natively ported to ARM with of course all the popular apps of the day ported to it, and if we have that level of resources, then surely some kind of system that run old Amiga software you could boot up a perfect AmigaOS3 system ran by FPGA chip, Run in a window or maybe even transparently like Rabbit hole does, that bring Linux Apps on to the emulated Desktop. So the end user would never really know what your running on. Sure it would require some cleaver software, (that kinda exist already) but this is a fantasy anyway.

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

Another side note, what software is there that requires that kind of cycle-accurate 68000 CPU?

In fact its been a while since I notice any software emulation issue with WinUAE, I just tried googling for Emulation errors or games bugs, there maybe a few when JIT is active and your trying to go beyond the old Amiga system specs. But far as I can tell, Amiga software emulation is very good (compare to other systems.)

I do understand the befits of FPGA, I been reading up on it, (to work out, if its worth getting)
https://www.timeextension.com/features/fpga-vs-software-emulation-which-is-best-we-asked-four-experts-to-find-out

https://www.youtube.com/watch?v=sMMiBEhnizE&ab_channel=What%27sKenMaking

So I get why it can be beneficial. I just feel the last few posts are debating about how do we get to the last 5% (at most) to 100% Amiga 1 to 1 system in modern solution, which to me seem nuts, but maybe there a case for it.

_________________
AmigaNG, YouTube, LeaveReality Studio

@matthey

Quote:

matthey wrote: cdimauro Quote: It's possible both on software and FPGA side, but provided the schematics to perfectly reproduce the original chips. WinUAE seems to have a cycle-accurate 68000 emulation, and the upcoming version has a very accurate chipset emulation thanks to the use of some (unfortunately not all) schematics found for Alice. But nothing prevents to have a perfect emulation of all other components (included a 68EC020), getting their schematics. Windows can not maintain timing. A bare metal system like emu68 or a RTOS can.

You can reach a similar situation on WinUAE by:
- bounding the WinUAE's process and its threads to specific cores/hardware threads;
- raise their priority to real-time;
- change their memory pages to non-pageable (so that the OS can't swap them);
- enable huge pages (e.g. 1GB) to nullify the page translation hits (e.g.: page not in the TLB).
The last two steps require that WinUAE directly uses Windows's APIs for virtual memory de/allocation, to have properly set all memory areas which are relevant by the emulator code (not the GUI & application code: this can continue to use the regular C's malloc/free APIs).

Most of the above is performed by many AAA games on Windows to ensure the best fluid gaming experience.

Of course, this doesn't give 100% control of system and some glitches might happen from time to time, but they are very rare. Plus, x86/x64 processors have so high performance that likely no user will face them.
Quote:

A cycle exact 68000 in Windows may be a goal but it is not obtainable.

As already stated, it was already implemented: 68000 and OCS/ECS are cycle-exact on the last WinUAE beta versions. AGA is very close (the only problem is that the are no schematics available for Lisa). And the 68020 is partially cycle-exact (because, and usual, no schematics for the processor are available).

The problem that WinUAE faces are exactly the same of every FPGA/ASIC project: no schematics -> no perfect emulation.
However, WinUAE is currently the only project which offers the most accurate implementation of any Amiga.
Quote:

cdimauro Quote: Such 68k instructions aren't atomic: the RMW cycle doesn't guarantee that the memory location is atomically updated. Only TAS, CAS, CAS2 68k instructions are atomic, but even those can be emulated by architectures having load/store atomics (not x86/x64: this requires transaction extensions, which are a bit more complicated to be used). We have talked about this before. All RMW instructions are atomic in the sense that the instruction and memory access is one uninterruptible instruction. This used to be the definition of an atomic instruction before multicore.

Yes, but then why Motorola implemented the TAS instruction on the 68000?
Quote:

The 68k Amiga is a preemptive multitasking system which can be interrupted after any instruction yet it is safe to use atomic RMW instructions without disabling interrupts. Replacing with RISC load+add+store instructions is not safe and the locked versions are much slower than a simple CISC atomic RMW instruction. A CISC atomic RMW instruction is not safe with SMP using the modern multicore meaning of an atomic instruction. A locked atomic instruction is needed for SMP that locks the memory bus so no other cores can access memory. In order to get SMP working on the 68k Amiga, pages marked as shared (using MMU) could be upgraded to use locked RMW instructions while non-shared pages would continue to use regular RMW instructions for better performance. A couple of more little hardware tricks and I believe SMP would be possible on the 68k Amiga with most OS friendly software and minimal changes for most programs that do not work.

This trick doesn't work. SMP is not easy on Amiga OS, because the OS was Broken-By-Design.

AROS already tried to implement the SMP adding A LOT of changes (duplicating the relevant OS structures for each core and changing several parts of the code trying to use mutexes/semaphores, where possible, instead of the nasty Forbid/Disable or the even more nasty Disable/Enable APIs), but it's still unstable.

I don't see any possibility to add SMP on an Amiga/-like OS without discarding the compatibility and breaking a lot of things.
It's the same for other modern and desired features (64-bit, virtual memory, isolated tasks execution, properly dynamic stack growth, resource-tracking).

IMO it makes no sense insisting on modernizing something which was very badly designed: its wasted time.

The solution for me is simple: Amiga OS (as it is) on a sandbox, running on a new, Amiga-inspired, OS (which is, of course, almost completely incompatible with the original one).
Quote:

PPC AmigaOS 4 has needed extensive and performance killing changes including Load-Acquire/Store-Release loops in place of 68k RMW instructions and memory access fences everywhere due to the weak memory consistency model with a decade of failure.

OS4, being just a port of the Amiga OS, is also Broken-By-Design (despite attempts to fix a few things) --> same as above.

It's a waste of time trying to keep alive a dead corpse, by implanting alien parts.
Quote:

RISC architects think they have an advantage by rearranging loads/stores but after all the fences they may be slower than a stronger TSO like memory consistency model common for CISC. The 68060 performs all loads and stores in program order. Multicore atomics are sometimes simpler on x86(-64) and code written for x86(-64) sometimes has problems with RISC weak memory consistency models too.

I agree on that (but for the 68060 is quite easy: it's an in-order core ).

@amigang

Quote:

amigang wrote: @amigang Another side note, what software is there that requires that kind of cycle-accurate 68000 CPU?

There are games which were written by complete idiots, that don't work without a cycle-exact 68000 emulation/core.

kolla might know which ones.
Quote:

In fact its been a while since I notice any software emulation issue with WinUAE, I just tried googling for Emulation errors or games bugs, there maybe a few when JIT is active and your trying to go beyond the old Amiga system specs. But far as I can tell, Amiga software emulation is very good (compare to other systems.) I do understand the befits of FPGA, I been reading up on it, (to work out, if its worth getting) https://www.timeextension.com/features/fpga-vs-software-emulation-which-is-best-we-asked-four-experts-to-find-out https://www.youtube.com/watch?v=sMMiBEhnizE&ab_channel=What%27sKenMaking So I get why it can be beneficial. I just feel the last few posts are debating about how do we get to the last 5% (at most) to 100% Amiga 1 to 1 system in modern solution, which to me seem nuts, but maybe there a case for it.

Most of the problems are "solved" (!) by WHDLoad, but not all games have WHDLoad slaves, unfortunately.

@AmigaBlitter

After the bankruptcy of Commodore, the tendency all these years has been
to divide into even more smaller groups over time, not to unite.
So, no "join the forces" in the near future.
(i'm not against it, i can't see it...)

Last edited by amigagr on 10-May-2025 at 08:05 AM.
Last edited by amigagr on 10-May-2025 at 08:03 AM.

cdimauro Quote:

You can reach a similar situation on WinUAE by: - bounding the WinUAE's process and its threads to specific cores/hardware threads; - raise their priority to real-time; - change their memory pages to non-pageable (so that the OS can't swap them); - enable huge pages (e.g. 1GB) to nullify the page translation hits (e.g.: page not in the TLB). The last two steps require that WinUAE directly uses Windows's APIs for virtual memory de/allocation, to have properly set all memory areas which are relevant by the emulator code (not the GUI & application code: this can continue to use the regular C's malloc/free APIs). Most of the above is performed by many AAA games on Windows to ensure the best fluid gaming experience. Of course, this doesn't give 100% control of system and some glitches might happen from time to time, but they are very rare. Plus, x86/x64 processors have so high performance that likely no user will face them.

I understand the goal and a dedicated core for WinUAE with minimal Windows multitasking should be able to come close but I have experience with Windows and it is no embedded RTOS like the AmigaOS. Too often the drive is accessed randomly for MMU paging leaving the whole computer unusable for minutes or a whole sentence appears after I have typed it into an editor.

cdimauro Quote:

As already stated, it was already implemented: 68000 and OCS/ECS are cycle-exact on the last WinUAE beta versions. AGA is very close (the only problem is that the are no schematics available for Lisa). And the 68020 is partially cycle-exact (because, and usual, no schematics for the processor are available). The problem that WinUAE faces are exactly the same of every FPGA/ASIC project: no schematics -> no perfect emulation. However, WinUAE is currently the only project which offers the most accurate implementation of any Amiga.

Yes, the 68000 and OCS/ECS are about as simple as can be reverse engineered as cycle exact, at least without decapping the chips. Fortunately, cycle exact behavior became less important for later 68k CPUs and software.

cdimauro Quote:

Yes, but then why Motorola implemented the TAS instruction on the 68000?

There was multiprocessing before multicore.

https://en.wikipedia.org/wiki/Multiprocessing (multiple CPUs)
https://en.wikipedia.org/wiki/Multi-core_processor

The 68000 Amiga was multiprocessor.

https://en.wikipedia.org/wiki/Multiprocessor_system_architecture (more than one processor)

The 68000 was very limited in multiprocessing capabilities but the 68020 was multiprocessing capable and an early MPU used in multiprocessing research.

A Lock-Free Multiprocessor OS Kernel
https://cs.uwaterloo.ca/~brecht/servers/readings-new/massalin91lockfree.pdf

From 68000 TAS to 68020 CAS and CAS2 was a night and day difference for multiprocessing support. The 68000 had other issues which made mutliprocessing difficult if it was even possible but primitive multiprocessing support was perhaps the intention of TAS.

cdimauro Quote:

This trick doesn't work. SMP is not easy on Amiga OS, because the OS was Broken-By-Design. AROS already tried to implement the SMP adding A LOT of changes (duplicating the relevant OS structures for each core and changing several parts of the code trying to use mutexes/semaphores, where possible, instead of the nasty Forbid/Disable or the even more nasty Disable/Enable APIs), but it's still unstable. I don't see any possibility to add SMP on an Amiga/-like OS without discarding the compatibility and breaking a lot of things.

AROS x86-64 where Jason McMullan implemented SMP is not a 68k Amiga which is a big handicap as there is no working Disable.

SillySMP An experiment in SMP design for AROS
https://docs.google.com/presentation/d/1q6lq5peXJBluQTQDSCAL-FR2kAoyxTRXWz3htWX0W1s/htmlpresent Quote:

Disable/Forbid: A Tale of Woe Disable() is bad in user space: o Causes all interrupts to stop o No task switching may occur o MUST stop all work on all other CPUs o Expected to be a fast operation - but is not in SMP! Forbid() is bad in user space: o No task switching may occur o MUST stop all work on all other CPUs o May be broken by a number of OS calls o Must be restored when control returns! Disable/Forbid: Exec Cleanup Forbid/Disable ruins performance on SMP o Both go from ‘cheap’ to ‘expensive’ in SMP! We need to eliminate Disable/Forbid in exec.library o Over 60 functions use it in exec.library! Can’t replace them with SignalSemaphores o SignalSemaphore relies on Signal() and Wait().. _o Which rely on Disable!

With a complete 68k Amiga, the chipset contains INTENA, INTENAR, INTREQ, INTREQR.

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0060.html

With a working chipset, there is a working ENABLE/Enable() and DISABLE/Disable() including the macros.

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node007B.html Quote:

;Disable interrupts. Avoid use of DISABLE if at all possible. ;Please realize the danger of this macro! Don't disable for long periods! DISABLE MACRO ; [scratchReg],[NOFETCH] or have ExecBase in A6. IFC '\1','' ;Case 1: Assume A6=ExecBase MOVE.W #$04000,_intena ;(NOT IF_SETCLR)+IF_INTEN ADDQ.B #1,IDNestCnt(A6) MEXIT ENDC IFC '\2','NOFETCH' ;Case 2: Assume \1=ExecBase MOVE.W #$04000,_intena ADDQ.B #1,IDNestCnt(\1) MEXIT ENDC IFNC '\1','' ;Case 3: Use \1 as scratch MOVE.L 4,\1 ;Get ExecBase MOVE.W #$04000,_intena ADDQ.B #1,IDNestCnt(\1) MEXIT ENDC ENDM ;Enable interrupts. Please realize the danger of this macro! ENABLE MACRO ; [scratchReg],[NOFETCH] or have ExecBase in A6. IFC '\1','' ;Case 1: Assume A6=ExecBase SUBQ.B #1,IDNestCnt(A6) BGE.S ENABLE\@ MOVE.W #$0C000,_intena ;IF_SETCLR+IF_INTEN ENABLE\@: MEXIT ENDC IFC '\2','NOFETCH' ;Case 2: Assume \1=ExecBase SUBQ.B #1,IDNestCnt(\1) BGE.S ENABLE\@ MOVE.W #$0C000,_intena ENABLE\@: MEXIT ENDC IFNC '\1','' ;Case 3: Use \1 as scratch MOVE.L 4,\1 ;Get ExecBase SUBQ.B #1,IDNestCnt(\1) BGE.S ENABLE\@ MOVE.W #$0C000,_intena ENABLE\@: MEXIT ENDC ENDM

A working Enable() and Disable() give working SignalSemaphores and working Signal() and Wait(). Much more of the AmigaOS is working without require patching as these are core functions of the AmigaOS. Jason was working with a major handicap and still managed to get SMP working to some extent. Forbid() and Permit() can be patched for SMP but not the FORBID macro. He had this working but it is not efficient to stop all cores. Hardware help can improve this though. With my idea of using the MMU to mark pages as shared, cores that do not access shared data while code on another core has a forbid() could continue to execute and would automatically pause when encountering shared data. All the inter-process communications and manual stopping of the other cores can be avoided with hardware help. With programmable remapping of memory access locations for the FORBID macro, that may be possible too. I believe a large FPGA with 68k Amiga multicore hardware could develop mostly compatible and efficient SMP on the goal to a multicore ASIC. Gunnar believes in a single FPGA CPU core in an affordable FPGA only and other FPGA Amiga hardware is single core retro only.

cdimauro Quote:

It's the same for other modern and desired features (64-bit, virtual memory, isolated tasks execution, properly dynamic stack growth, resource-tracking). IMO it makes no sense insisting on modernizing something which was very badly designed: its wasted time. The solution for me is simple: Amiga OS (as it is) on a sandbox, running on a new, Amiga-inspired, OS (which is, of course, almost completely incompatible with the original one).

It is possible to allow 64-bit code execution simultaneously with 32-bit code execution. If there was a problem, then separate 64-bit and 32-bit AmigaOS builds like RPi OS would work. The 32-bit RPi OS is still the recommended build.

https://www.raspberrypi.com/software/operating-systems/

Partial memory protection, partial process isolation, stack overflow checking/stack growth and resource tracking are possible with a MMU on existing 68k Amiga hardware and with some degree of compatibility. The 68000 AmigaOS only compile shows the 68k AmigaOS devs aim for the lowest common denominator though. Maybe the 68k AmigaOS can not be allowed to compete with PPC AmigaOS 4 which has been designated as the high end AmigaOS even though my prediction is that it will never have working 64-bit or SMP support despite existing 64-bit multicore hardware.

cdimauro Quote:

There are games which were written by complete idiots, that don't work without a cycle-exact 68000 emulation/core.

It was common in the 8-bit CPU era to use CPU timing loops. Some simple hardware did not have timers. The 68k Amiga did not have these limitations but it took a while for programmers to learn the Amiga. The 68000 Atari ST continued to have CPU timing loops for longer than the Amiga. The 68000 consoles are likely to have more timing loops as well. For many 68k systems it was not bad programming practice. I believe the Amiga was one of the earliest to recommend against it.

For others, CPU timing loops only work correctly when the CPU clock speed and all instruction timings are known by the programmer and if the clock speed or CPU changes then the timing is incorrect. Obviously this was a bad assumption as clock speeds started to increase and CPUs with different loop timing were used.

Last edited by matthey on 10-May-2025 at 09:50 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: You can reach a similar situation on WinUAE by: - bounding the WinUAE's process and its threads to specific cores/hardware threads; - raise their priority to real-time; - change their memory pages to non-pageable (so that the OS can't swap them); - enable huge pages (e.g. 1GB) to nullify the page translation hits (e.g.: page not in the TLB). The last two steps require that WinUAE directly uses Windows's APIs for virtual memory de/allocation, to have properly set all memory areas which are relevant by the emulator code (not the GUI & application code: this can continue to use the regular C's malloc/free APIs). Most of the above is performed by many AAA games on Windows to ensure the best fluid gaming experience. Of course, this doesn't give 100% control of system and some glitches might happen from time to time, but they are very rare. Plus, x86/x64 processors have so high performance that likely no user will face them. I understand the goal and a dedicated core for WinUAE with minimal Windows multitasking should be able to come close but I have experience with Windows and it is no embedded RTOS like the AmigaOS. Too often the drive is accessed randomly for MMU paging leaving the whole computer unusable for minutes or a whole sentence appears after I have typed it into an editor.

I don't know which Windows system you have, but the above steps make relatively sure to avoid having bad experiences running critical applications like WinUAE. For example, MMU paging can be completely avoided (having enough physical memory, of course).
Quote:

cdimauro Quote: This trick doesn't work. SMP is not easy on Amiga OS, because the OS was Broken-By-Design. AROS already tried to implement the SMP adding A LOT of changes (duplicating the relevant OS structures for each core and changing several parts of the code trying to use mutexes/semaphores, where possible, instead of the nasty Forbid/Disable or the even more nasty Disable/Enable APIs), but it's still unstable. I don't see any possibility to add SMP on an Amiga/-like OS without discarding the compatibility and breaking a lot of things. AROS x86-64 where Jason McMullan implemented SMP is not a 68k Amiga which is a big handicap as there is no working Disable. SillySMP An experiment in SMP design for AROS https://docs.google.com/presentation/d/1q6lq5peXJBluQTQDSCAL-FR2kAoyxTRXWz3htWX0W1s/htmlpresent Quote: Disable/Forbid: A Tale of Woe Disable() is bad in user space: o Causes all interrupts to stop o No task switching may occur o MUST stop all work on all other CPUs o Expected to be a fast operation - but is not in SMP! Forbid() is bad in user space: o No task switching may occur o MUST stop all work on all other CPUs o May be broken by a number of OS calls o Must be restored when control returns! Disable/Forbid: Exec Cleanup Forbid/Disable ruins performance on SMP o Both go from ‘cheap’ to ‘expensive’ in SMP! We need to eliminate Disable/Forbid in exec.library o Over 60 functions use it in exec.library! Can’t replace them with SignalSemaphores o SignalSemaphore relies on Signal() and Wait().. _o Which rely on Disable! With a complete 68k Amiga, the chipset contains INTENA, INTENAR, INTREQ, INTREQR. http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0060.html With a working chipset, there is a working ENABLE/Enable() and DISABLE/Disable() including the macros. http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node007B.html Quote: ;Disable interrupts. Avoid use of DISABLE if at all possible. ;Please realize the danger of this macro! Don't disable for long periods! DISABLE MACRO ; [scratchReg],[NOFETCH] or have ExecBase in A6. IFC '1','' ;Case 1: Assume A6=ExecBase MOVE.W #$04000,_intena ;(NOT IF_SETCLR)+IF_INTEN ADDQ.B #1,IDNestCnt(A6) MEXIT ENDC IFC '2','NOFETCH' ;Case 2: Assume 1=ExecBase MOVE.W #$04000,_intena ADDQ.B #1,IDNestCnt(1) MEXIT ENDC IFNC '1','' ;Case 3: Use 1 as scratch MOVE.L 4,1 ;Get ExecBase MOVE.W #$04000,_intena ADDQ.B #1,IDNestCnt(1) MEXIT ENDC ENDM ;Enable interrupts. Please realize the danger of this macro! ENABLE MACRO ; [scratchReg],[NOFETCH] or have ExecBase in A6. IFC '1','' ;Case 1: Assume A6=ExecBase SUBQ.B #1,IDNestCnt(A6) BGE.S ENABLE@ MOVE.W #$0C000,_intena ;IF_SETCLR+IF_INTEN ENABLE@: MEXIT ENDC IFC '2','NOFETCH' ;Case 2: Assume 1=ExecBase SUBQ.B #1,IDNestCnt(1) BGE.S ENABLE@ MOVE.W #$0C000,_intena ENABLE@: MEXIT ENDC IFNC '1','' ;Case 3: Use 1 as scratch MOVE.L 4,1 ;Get ExecBase SUBQ.B #1,IDNestCnt(1) BGE.S ENABLE@ MOVE.W #$0C000,_intena ENABLE@: MEXIT ENDC ENDM

So, your idea is to have special hardware support added to the ASIC to help on the Amiga OS SMP design, right?
Quote:

A working Enable() and Disable() give working SignalSemaphores and working Signal() and Wait(). Much more of the AmigaOS is working without require patching as these are core functions of the AmigaOS. Jason was working with a major handicap and still managed to get SMP working to some extent. Forbid() and Permit() can be patched for SMP but not the FORBID macro. He had this working but it is not efficient to stop all cores. Hardware help can improve this though. With my idea of using the MMU to mark pages as shared, cores that do not access shared data while code on another core has a forbid() could continue to execute and would automatically pause when encountering shared data. All the inter-process communications and manual stopping of the other cores can be avoided with hardware help. With programmable remapping of memory access locations for the FORBID macro, that may be possible too. I believe a large FPGA with 68k Amiga multicore hardware could develop mostly compatible and efficient SMP on the goal to a multicore ASIC.

OK, this answer my previous question. However, and as I've reported before, it's not enough to have such APIs working thanks to the hardware support. There are other things which are missing. For example, how to implement the list of ready and blocked tasks per each single core?
Quote:

Gunnar believes in a single FPGA CPU core in an affordable FPGA only and other FPGA Amiga hardware is single core retro only.

It makes sense, because that's what you can do actually on a Amiga hardware emulator.
Quote:

cdimauro Quote: It's the same for other modern and desired features (64-bit, virtual memory, isolated tasks execution, properly dynamic stack growth, resource-tracking). IMO it makes no sense insisting on modernizing something which was very badly designed: its wasted time. The solution for me is simple: Amiga OS (as it is) on a sandbox, running on a new, Amiga-inspired, OS (which is, of course, almost completely incompatible with the original one). It is possible to allow 64-bit code execution simultaneously with 32-bit code execution.

Not when resources are shared.
Quote:

If there was a problem, then separate 64-bit and 32-bit AmigaOS builds like RPi OS would work. The 32-bit RPi OS is still the recommended build. https://www.raspberrypi.com/software/operating-systems/

RISCOS has its own problems as well.
Quote:

Partial memory protection, partial process isolation, stack overflow checking/stack growth and resource tracking are possible with a MMU on existing 68k Amiga hardware and with some degree of compatibility. The 68000 AmigaOS only compile shows the 68k AmigaOS devs aim for the lowest common denominator though. Maybe the 68k AmigaOS can not be allowed to compete with PPC AmigaOS 4 which has been designated as the high end AmigaOS even though my prediction is that it will never have working 64-bit or SMP support despite existing 64-bit multicore hardware.

They share the same problems, and OS4 has very very limited improvements regarding the above statements.

Let's face the reality: the Amiga OS was never designed for such modern features, and getting them is almost impossible (without dropping the backward compatibility).

Then why insisting on modernizing it?
Quote:

cdimauro Quote: There are games which were written by complete idiots, that don't work without a cycle-exact 68000 emulation/core. It was common in the 8-bit CPU era to use CPU timing loops. Some simple hardware did not have timers. The 68k Amiga did not have these limitations but it took a while for programmers to learn the Amiga. The 68000 Atari ST continued to have CPU timing loops for longer than the Amiga. The 68000 consoles are likely to have more timing loops as well. For many 68k systems it was not bad programming practice. I believe the Amiga was one of the earliest to recommend against it. For others, CPU timing loops only work correctly when the CPU clock speed and all instruction timings are known by the programmer and if the clock speed or CPU changes then the timing is incorrect. Obviously this was a bad assumption as clock speeds started to increase and CPUs with different loop timing were used.

Systems without timers are justified to do CPU-based loop for timing (because there's no other way).
Consoles as well, because their hardware is set into the stone and doesn't change.

But it's not justified, at all, in all other cases. Especially if you've the vendor guidelines on how to develop the software. Which was Amiga's case.
So, those who haven't followed such guidelines were idiots. Ignorants, at best.

cdimauro Quote:

I don't know which Windows system you have, but the above steps make relatively sure to avoid having bad experiences running critical applications like WinUAE. For example, MMU paging can be completely avoided (having enough physical memory, of course).

I looked into turning paging off at one time as there are times when I would rather have out of memory errors than paging timeouts. However, Windows is designed to use paging including its caching systems, some programs depend on paging to be turned on for memory mapped files (https://en.wikipedia.org/wiki/Memory-mapped_file), low and out of memory Windows handling is bad because paging is almost always turned on and Windows and Windows programs are such memory hogs that it is prohibitively expensive to buy enough memory for it not to run out. I decided not to try turning paging off after reading articles online. AI from such articles discourages it.

Google AI Overview Quote:

Turning off Windows paging, also known as disabling the page file, can impact system performance and stability. While disabling it might seem like a good idea for SSDs, it's generally not recommended as it can lead to system crashes or "Out of Memory" errors. Here's a breakdown of the process and considerations: Why Disable Paging? o SSD longevity: Some users believe disabling paging can prolong the lifespan of SSDs by reducing the amount of writing to the drive. o Potential for increased RAM usage: Disabling paging might allow your system to utilize RAM more fully, potentially improving performance if you have enough RAM. Why Not Disable Paging? o System instability: Windows relies on the page file to manage memory, and disabling it can lead to system crashes or "Out of Memory" errors when RAM is fully utilized. o Performance issues: While disabling paging might seem like it could improve RAM utilization, it can also lead to delays and slowdowns when tasks are swapped to the drive.

Once you go fat, you never go back.

cdimauro Quote:

So, your idea is to have special hardware support added to the ASIC to help on the Amiga OS SMP design, right?

Yes. The logic is relatively simple and partially builds on existing hardware.

Proposed new hardware support for 68k SMP

1. MMU pages gain a new "shared" attribute that roughly corresponds to the Amiga old MEMF_PUBLIC and new MEMF_SHARED memory allocation attribute.

MEMF_PRIVATE: Memory allocated with this flag is private for this task only. No other task can access it and any attempt to do so will result in a DSI exception.

MEMF_SHARED: Memory of this type is sharable between tasks. See the discussion below for details.

MEMF_PUBLIC: (Deprecated in AmigaOS 4) This indicates that the memory should be accessible to other tasks. MEMF_PUBLIC memory can never be paged out. See the discussion below why you should avoid it.

Both MEMF_SHARED and MEMF_PUBLIC would be marked shared but see the following page for differences.

https://wiki.amigaos.net/wiki/Obsolete_Exec_Memory_Allocation

MMU pages often already support adding custom attribute bits but they are not used by the hardware unlike cachability and access permission bits. There is nothing unusual about hardware logic based on the attribute bits and using the bits is optional.

if (access_i && page_nx) MMU_trap // no execute check
if (access_d && access_store && page_ro) MMU_trap // read only check
if (access_d && access_store && page_writethru) access=writethru // cache writethru

if (access_d && access_RMW && page_shared) access=locked // RMW to locked RMW

With this simple hardware support, single core atomic RMW memory accesses become multi-core atomic locked RMW memory accesses in shared memory. Existing AmigaOS programs which used MEMF_PUBLIC and MEMF_SHARED flags correctly would be one step closer to SMP and memory allocation flags are easy to change in AmigaOS programs even with patches as the program size does not change. This hardware help may not be so bad either compared to alternatives like RISC code bloat with load-aquire store-release and sync/fence instructions (PPC still has no working SMP likely with thousands of instructions added to the AmigaOS). The x86(-64) ISA being able to make all RMW instructions locked with a prefix has a decoding overhead and enlarges code too. Coupled with a TSO like memory consistency model, this hardware help may allow smaller footprint SMP systems than the competition.

2. The efficiency of SMP could improve with hardware help as the inter-core communication (ICC) and stopping and restarting all other cores has a high overhead. The shared page attributes can be reused to improve efficiency as non-shared code can continue to execute, most likely until attempting to access shared data. Let us consider potential core states of operation with SMP.

core_run: core executes code normally
core_halt: core is halted
core_halt_shared: core halts before accessing shared instructions or data
core_halt_shared_d: core halts before accessing shared data (enough for SMP?)
core_wait: core halts until other cores transition to requested/required state

Lines between cores could be used for inter-core communication allowing to change states from other cores. A wait mechanism is needed as the ICC would likely require multiple cycles.

if (access_d && page_shared && core_stop_shared_d) core=core_halt // wait for core state change

The logic is more complex but I believe tolerable and manageable. The ICC overhead is reduced and cores are only halted when accessing shared data. The ICC could be useful for debugging cores from other cores and this may be useful for debugging SMP. A core single step through code and monitor features could be useful too. My ICC proposal is somewhat similar to how JTAG debugging works with lines out to chip pins.

3. The 68k AmigaOS uses absolute memory addresses when different addresses are required per core. A MMU resolution may be too course for what the Amiga needs. A per core memory access remapping feature could be useful and would be relatively simple. When an absolute address is accessed, a preset replacement address is accessed instead or a trap can be specified. This feature could be useful for debugging and retro support as well.

With the ability to customize the hardware, there is a lot that can be done. It is a game changer for SMP support instead of being handicapped like Jason trying to implement SMP in x86-64 AROS. He did an amazing job just getting SMP working even with changes to existing Amiga programs. The PPC AmigaOS 4 devs have failed to get that far as they have the same problem of needing to change AmigaOS programs due to not changing PPC AmigaOS 4 adequately for SMP on commodity hardware.

cdimauro Quote:

OK, this answer my previous question. However, and as I've reported before, it's not enough to have such APIs working thanks to the hardware support. There are other things which are missing. For example, how to implement the list of ready and blocked tasks per each single core?

I do not have all the specifics figured out and do not know them anyway but the hardware tools I suggest should make 68k AmigaOS SMP support much easier. A 68k Amiga multi-core system should be implemented in a large FPGA in cooperation with software devs working on AmigaOS SMP support. The Amiga problem is lack of cooperation and closed development that suppresses innovation and proliferation. Just another lost Trevor decade and PPC AmigaOS 4 SMP should be working as promised a decade ago. The necessary changes can be made to AmigaOS 4 for commodity hardware SMP when switching architectures to x86-64 or ARM64 but MorphOS will likely do so first and 68k Amiga programs will be incompatible with commodity hardware SMP missing the large retro 68k Amiga market anyway.

cdimauro Quote:

It makes sense, because that's what you can do actually on a Amiga hardware emulator.

The Natami/Vamp/AC was supposed to be about more than retro compatibility. It was about recreating, enhancing and moving the 68k Amiga forward before sloppy Gunnar shortcuts and FPGA only limitations. This is in contrast to retro Amiga emulators and most FPGA Amiga/universal hardware.

cdimauro Quote:

Not when resources are shared.

Early 64-bit support should be for exec.library memory allocations. A new MEMF_64bit memory allocation flag could continue to allow 32-bit allocations for compatibility when the flag is missing. There would be a little additional overhead of a branch and additional code. Some libraries could be 64-bit only or 32-bit only and 64-bit programs would open the 64-bit version while 32-bit programs would open the 32-bit version. The ability for 64-bit and 32-bit programs to execute simultaneously is required instead of for example, PPC cores with a 64-bit mode and 32-bit backward compatible mode selected at startup only. A 64-bit only AmigaOS is possible but compatibility seems to be more important for the Amiga with its retro 68k Amiga appeal.

cdimauro Quote:

They share the same problems, and OS4 has very very limited improvements regarding the above statements. Let's face the reality: the Amiga OS was never designed for such modern features, and getting them is almost impossible (without dropping the backward compatibility). Then why insisting on modernizing it?

The 68k AmigaOS could already have as good of memory protection as AmigaOS 4 using optional MMU support, optional code protection from tooltypes and prefs and new hunk flag types. Optional stack overflow protection with a MMU could also be added. The problem is that the 68k AmigaOS is designated as a lower/poor class citizen to the expensive upper/rich/elitist class citizen PPC AmigaOS 4 but the lack of meaningful improvements means the 68k AmigaOS has to be sabotaged so it does not compete.

cdimauro Quote:

Systems without timers are justified to do CPU-based loop for timing (because there's no other way). Consoles as well, because their hardware is set into the stone and doesn't change. But it's not justified, at all, in all other cases. Especially if you've the vendor guidelines on how to develop the software. Which was Amiga's case. So, those who haven't followed such guidelines were idiots. Ignorants, at best.

In 1985, CPU timing loops were likely the most common method for MPU timing. The 68k Amiga was very different from 8-bit hardware, there was not much Amiga documentation, and it was difficult to get everything right for such new and different hardware, especially for 8-bit programmers new to the Amiga. The situation for the Amiga improved quickly over the next several years and CPU timing loops were rare by 1987 as new higher clocked 68k accelerators punished holdouts. Ignorant assumptions about memory were more of a problem after that.

Last edited by matthey on 13-May-2025 at 03:19 PM.

@matthey

Quote:

Windows can not maintain timing. A bare metal system like emu68 or a RTOS can. A cycle exact 68000 in Windows may be a goal but it is not obtainable.

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setpriorityclass

Windows 11 has real-time priority mode i.e. SetPriorityClass API (REALTIME_PRIORITY_CLASS).

Process that has the highest possible priority. The threads of the process preempt the threads of all other processes, including operating system processes performing important tasks.


Using "real-time" priority level should be done by experienced programmers since this level can gimp user's input process.

If MS gets mass reports of badly behaving software, MS will delete/refuse to run the offending software from the system via Microsoft Defender enforcement e.g. Sony's DRM rootkits for Windows.



-------------------

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setprocessaffinitymask
A program being run can set its affinity with a specific CPU core via the SetProcessAffinityMask() and GetProcessAffinityMask () APIs.

For end users, refer to the 3rd-party Process Lasso tool to automate this feature.

AMD and Intel have CPU drivers to push PC games into the fastest gaming CPU cores. With multi-CPU setups, this reduces CPU core hops and landing on less-gaming CPU cores.

Combined with CPU drivers, Windows 11 is aware of PC gaming use cases.

-------------------

The RPCS3 emulator has "physical page mode". RPCS3 uses these page tables more accurately, reflecting how the PS3 handles memory allocation and mapping.


How it works:
Instead of directly mapping virtual memory addresses to physical memory, the emulator uses page tables to translate virtual addresses to physical ones, which can lead to better performance and compatibility.

Benefits:
Improved performance: Physical page mode can often result in faster game loading times and smoother gameplay, especially for games that rely heavily on the PS3's Cell processor.

Enhanced stability: This mode can also lead to fewer crashes and errors, as it allows the emulator to better handle the complex memory management of the PS3.

Better compatibility: Some games that struggle with virtual mode may run more smoothly or reliably in physical page mode.


Combined with lower-level DirectX12 or Vulkan graphics API, some of the above features are used in leading-edge PC games.

Last edited by Hammer on 13-May-2025 at 04:08 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

I understand the goal and a dedicated core for WinUAE with minimal Windows multitasking should be able to come close but I have experience with Windows and it is no embedded RTOS like the AmigaOS. Too often the drive is accessed randomly for MMU paging leaving the whole computer unusable for minutes or a whole sentence appears after I have typed it into an editor.

Your editor wasn't designed with a physical page mode enabled. General-purpose editors wouldn't be designed like the RPCS3 emulator's extreme needs.

With Windows NT, it's up to the software provider to explicitly design software that needs physical page mode or other extreme needs. It defaults to general-purpose behavior.

"Virtual memory" with mass storage is just insurance when running low on physical memory.

-------------------------------
With 68030's MMU, I run my 6MB RAM equipped A3000 with 3rd party virtual memory software, but this luxury is limited to several 10,000s Amiga owners with a full 68K MMUs.

Full 68030 works fine with Shapeshifter's MacOS MMU usage.

MMU is a premium feature with Motorola's business plan, while it's standard on the 32-bit X86 world.

MIPS R3050 has a reduced-cost embedded MMU at a very competitive price.

This is a business case issue, not a technical issue.

From A3000/030 @ 25MHz, a bare-bones A1200 with 68EC020 is not enough for my usage.

I prefer an AGA motherboard upgrade for my A3000 in Xmas 1992. A4000/030 being released later in 1993 wasn't a good idea, but understand Commodore wanted to get rid of unsold ECS A3000s, a mistake caused by Commodore management.

My family doesn't have a budget to buy A4000/040 except for the A4000/030 level i.e. my family's budget for computer purchase is in the middle of barebone A1200 and A4000/040 price segments.

Commodore Canada/Amitech's unreleased A2200-1 and A2200-2 SKUs attracted my interest.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@amigagr

That what I see as well.
With the numerically strongest faction being those only interested in nostalgia and retro-gaming, and who are more than satisfied with the large number of emulators and emulations to choose from.
Nothing wrong with that, just saying.

I have an old A4000, laying dormant for almost 30 years. Only lately I tried to retrieve some files and data from this machine.
But I was never much into gaming, and can't see any productivity field where any Amiga incarnation can hold up against current machines. So why paying many times over for a quite mediocre performance ?

@matthey

Quote:

matthey wrote: cdimauro Quote: I don't know which Windows system you have, but the above steps make relatively sure to avoid having bad experiences running critical applications like WinUAE. For example, MMU paging can be completely avoided (having enough physical memory, of course). I looked into turning paging off at one time as there are times when I would rather have out of memory errors than paging timeouts. However, Windows is designed to use paging including its caching systems, some programs depend on paging to be turned on for memory mapped files (https://en.wikipedia.org/wiki/Memory-mapped_file), low and out of memory Windows handling is bad because paging is almost always turned on and Windows and Windows programs are such memory hogs that it is prohibitively expensive to buy enough memory for it not to run out. I decided not to try turning paging off after reading articles online. AI from such articles discourages it. Google AI Overview Quote: Turning off Windows paging, also known as disabling the page file, can impact system performance and stability. While disabling it might seem like a good idea for SSDs, it's generally not recommended as it can lead to system crashes or "Out of Memory" errors. Here's a breakdown of the process and considerations: Why Disable Paging? o SSD longevity: Some users believe disabling paging can prolong the lifespan of SSDs by reducing the amount of writing to the drive. o Potential for increased RAM usage: Disabling paging might allow your system to utilize RAM more fully, potentially improving performance if you have enough RAM. Why Not Disable Paging? o System instability: Windows relies on the page file to manage memory, and disabling it can lead to system crashes or "Out of Memory" errors when RAM is fully utilized. o Performance issues: While disabling paging might seem like it could improve RAM utilization, it can also lead to delays and slowdowns when tasks are swapped to the drive. Once you go fat, you never go back.

There are ways, but you need to know them. In fact, you don't need to disable paging neither memory mapping (the two things are different, BTW) on modern systems (which more or less offer the same functionalities), rather to use the proper APIs.

Spefically, for Windows you need to use:
- VirtualAlloc ( https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc ) for manually allocating pages;
- VirtualLock ( https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtuallock ) for locking a range of pages so that they aren't swapped out.

There are constraints on using them, which require attention and proper coding, but you can set memory regions which guarantee no page faults by carefully & properly combining both APIs.

This, united with the real-time priority and setting the process/thread affinity, is the way to reach close to real-time OSes performance.

In short, yes: you can go back slim at memory handling even on "pachyderm" OSes.
Quote:

cdimauro Quote: So, your idea is to have special hardware support added to the ASIC to help on the Amiga OS SMP design, right? Yes. The logic is relatively simple and partially builds on existing hardware. Proposed new hardware support for 68k SMP 1. MMU pages gain a new "shared" attribute that roughly corresponds to the Amiga old MEMF_PUBLIC and new MEMF_SHARED memory allocation attribute. MEMF_PRIVATE: Memory allocated with this flag is private for this task only. No other task can access it and any attempt to do so will result in a DSI exception. MEMF_SHARED: Memory of this type is sharable between tasks. See the discussion below for details. MEMF_PUBLIC: (Deprecated in AmigaOS 4) This indicates that the memory should be accessible to other tasks. MEMF_PUBLIC memory can never be paged out. See the discussion below why you should avoid it. Both MEMF_SHARED and MEMF_PUBLIC would be marked shared but see the following page for differences. https://wiki.amigaos.net/wiki/Obsolete_Exec_Memory_Allocation MMU pages often already support adding custom attribute bits but they are not used by the hardware unlike cachability and access permission bits. There is nothing unusual about hardware logic based on the attribute bits and using the bits is optional. if (access_i && page_nx) MMU_trap // no execute check if (access_d && access_store && page_ro) MMU_trap // read only check if (access_d && access_store && page_writethru) access=writethru // cache writethru if (access_d && access_RMW && page_shared) access=locked // RMW to locked RMW With this simple hardware support, single core atomic RMW memory accesses become multi-core atomic locked RMW memory accesses in shared memory.

But this isn't "68k SMP": this is "trying to introduce the SMP on the Amiga OS" (which can't have it because it's very badly designed).

As already discussed, the 68k have already "SMP" support since the 68000, thanks to the TAS instruction, which allows to implement some simple locking primitives (in hardware).
The 68020 added CAS and CAS2 to make it more easy to implement some more advanced locking primitives.

So, the problem isn't about the 68k processor family which is lacking something which prevents OSes to implement the SMP, rather trying to support only Amiga OS because, as it was designed, it can't do it.

Am I wrong?

Besides that clarification, I would leave MEMF_SHARED for the same behavior as OS4, and introduce MEMF_ATOMIC for such automatic locking of all RMW instructions running on those pages.

However, I think that this is overengineering, if the only purpose of such new mechanism is to lock any modification to the respective counters (bytes) for the Forbid/Permit and Enable/Disable APIs.
If this is the case, then it's enough to introduce a couple of new registers which hold the address of such counters, which force a locked RMW cycle for the specific byte being modified. Another (byte) register controls which one of the two locations are being monitored.
So, and only for the Amiga OS, the location of the two bytes are put on those two new registers, and the their respective bits set on the new monitor-enable register. And that's it: you don't have to introduce a big complication on the existing software and APIs.
Quote:

Existing AmigaOS programs which used MEMF_PUBLIC and MEMF_SHARED flags correctly would be one step closer to SMP and memory allocation flags are easy to change in AmigaOS programs even with patches as the program size does not change.

If it had been possible, existing Amiga applications would already have been patched to change MEMF_PUBLIC to MEM_SHARED, so that MorphOS and AmigaOS4 could take full advantage of memory virtualisation and, above all, resource tracking.

Most applications have no sources anymore (that's also the reason why AROS is the ugly duckling of the post-Amiga OSes: because it supports a very small software pool), and reverse-engineering the existing ones AND understanding how they used the memory which they allocate AND patching according their binaries is a Gargantuan task.

That's also because many of them are written in C, and they allocate memory using C's malloc(), which by default sets MEMF_PUBLIC (to be 100% sure that it can be used for any scenario. Which makes sense), and here patching the binary isn't straightforward, at all!
Quote:

This hardware help may not be so bad either compared to alternatives like RISC code bloat with load-aquire store-release and sync/fence instructions (PPC still has no working SMP likely with thousands of instructions added to the AmigaOS).

See above: the problem isn't RISCs neither PowerPCs. The problem was/is AmigaOS, which was Broken-By-Design by the absurd decisions of its engineers, which crippled the platform since the very beginning, giving it no chance (at all!) to evolve according to the more moderne needs.

No sane OS should publicly expose its internals, and even more important was exposing APIs like Forbid/Permit, Disable/Enable (and I would put also Supervisor, at least) to the public.

A properly written OS uses Getters, Setters, and Enumerators to fully control what the applications can do and carefully arbitrate how they access to sensible information (e.g.: the list of running tasks, the signals, the available memory, etc. etc. etc.).

It's not the modern OSes which are bloated: it's AmigaOS which was written with feet by hackers who killed any possibility of its evolution.

Now you want to dirty the processor architecture and introduce more complexity to the SoC solely to try to make up for their inability and bad design, solely to try (because that's all you can do. In fact, there is no guarantee of success in the endeavour) to modernise Amiga OS in SOME aspect. Do you think that it makes sense?
Quote:

The x86(-64) ISA being able to make all RMW instructions locked with a prefix has a decoding overhead and enlarges code too.

It's just one byte added on rarely used instructions (e.g.: not relevant for the code density) and there's no decoding overhead (x86 processors can handle 2-3 prefixes without incurring in performance penalities). The performance overhead happens solely because of the instructions' implementation (which require more cycles due to the more complex logic).
Quote:

Coupled with a TSO like memory consistency model, this hardware help may allow smaller footprint SMP systems than the competition.

A 68k OS, which is NOT Amiga OS, can implement a lightweight SMP without all the overcomplication required only to patch the horrible job which was made with the Amiga OS.

So, the problem is solely the Amiga OS. Certainly not the 68k processors.
Quote:

2. The efficiency of SMP could improve with hardware help as the inter-core communication (ICC) and stopping and restarting all other cores has a high overhead. The shared page attributes can be reused to improve efficiency as non-shared code can continue to execute, most likely until attempting to access shared data. Let us consider potential core states of operation with SMP. core_run: core executes code normally core_halt: core is halted core_halt_shared: core halts before accessing shared instructions or data core_halt_shared_d: core halts before accessing shared data (enough for SMP?) core_wait: core halts until other cores transition to requested/required state Lines between cores could be used for inter-core communication allowing to change states from other cores. A wait mechanism is needed as the ICC would likely require multiple cycles. if (access_d && page_shared && core_stop_shared_d) core=halt // wait for core state change The logic is more complex but I believe tolerable and manageable. The ICC overhead is reduced and cores are only stopped when accessing shared data. The ICC could be useful for debugging cores from other cores and this may be useful for debugging SMP. A core single step through code and monitor features could be useful too. My ICC proposal is somewhat similar to how JTAG works with lines out to chip pins. https://en.wikipedia.org/wiki/JTAG

I know JTAG, but see above: my monitoring proposal should be enough (and much simpler), and avoids arbitrarily stopping the cores (and introducing more complication on the SoC for implementing it via those specially marked pages).
As long as a task has acquired the counter, it owns the access to the OS' resources, while all other tasks can continue running without any interruption (it would be the new code in Forbid/Permit/Disable/Enable which takes care of stopping & restarting all other codes, only IF/WHEN it's needed).
All of this maintaining full compatibility with the existing applications.

However, there might still be issues (deadlocks) if the applications aren't fully respecting the OS guidelines, or "simply" because they don't properly call the related API after that they have acquired the privilege to access the OS' resources. This isn't something which can be avoided adding more hardware complication: they are bugs, which require patching to the original software.

Another problem is that the two counters are just 8-bit, so only up to 255 tasks can try to acquire them. It's a big number, but on modern OSes there are several thousands processes/threads which are running. It might be unlikely to get an overflow, but it's possible. And this is another problem which can't be solved (it requires changing the OS and recompiling all applications which depends on that).

Again, it's a problem of who the Amiga OS was very badly designed...
Quote:

3. The 68k AmigaOS uses absolute memory addresses when different addresses are required per core. A MMU resolution may be too course for what the Amiga needs. A per core memory access remapping feature could be useful and would be relatively simple. When an absolute address is accessed, a preset replacement address is accessed instead or a trap can be specified. This feature could be useful for debugging and retro support as well.

The Amiga OS has a single, common, and shared address space for all its task. So, all 68k cores which are running should implement the same memory mapping...
Quote:

With the ability to customize the hardware, there is a lot that can be done. It is a game changer for SMP support instead of being handicapped like Jason trying to implement SMP in x86-64 AROS. He did an amazing job just getting SMP working even with changes to existing Amiga programs. The PPC AmigaOS 4 devs have failed to get that far as they have the same problem of needing to change AmigaOS programs due to not changing PPC AmigaOS 4 adequately for SMP on commodity hardware.

See above: all such failures are only caused by the Amiga OS which was very badly written.

AROS and OS4 (and I assume the same is for MorhOS) tried, but they haven't succeed solely because of that. So, not because people aren't gifted-enough, neither because the architectures were bad: the only culprit of this situation is the team of engineers which have realized an OS which is Broken-By-Design for implementing many modern features.

Now, and as I've said, you want to TRY to resolve this mess adding horrible patches to the SoC. Doesn't is sound similar to the horrible patch of x86 (286, 386, x86-64) or PowerPC (prefix...) processors? To me yes. And, frankly speaking (as usual!), I don't like it (as I don't like the horrible patch of AGA on ECS).
Quote:

cdimauro Quote: OK, this answer my previous question. However, and as I've reported before, it's not enough to have such APIs working thanks to the hardware support. There are other things which are missing. For example, how to implement the list of ready and blocked tasks per each single core? I do not have all the specifics figured out and do not know them anyway but the hardware tools I suggest should make 68k AmigaOS SMP support much easier. A 68k Amiga multi-core system should be implemented in a large FPGA in cooperation with software devs working on AmigaOS SMP support.

So, from a generic 68k SoC with a small embedded FPGA to target multiple 68k systems, now the target become a 68k Amiga SoC with a large FPGA and SMP patches solely for the Amiga OS? Why?
Quote:

The Amiga problem is lack of cooperation and closed development that suppresses innovation and proliferation. Just another lost Trevor decade and PPC AmigaOS 4 SMP should be working as promised a decade ago. The necessary changes can be made to AmigaOS 4 for commodity hardware SMP when switching architectures to x86-64 or ARM64 but MorphOS will likely do so first and 68k Amiga programs will be incompatible with commodity hardware SMP missing the large retro 68k Amiga market anyway.

That's because of what I've explained above: Amiga OS was very badly designed by its engineers and this crippled the platform. This is the exactly the reason of the current situation.

Now, do you think that adding dirty patches to a SoC/architecture exclusively for trying to fix the big mess that the Amiga OS engineers made could be classified as "innovation"?
Quote:

cdimauro Quote: It makes sense, because that's what you can do actually on a Amiga hardware emulator. The Natami/Vamp/AC was supposed to be about more than retro compatibility. It was about recreating, enhancing and moving the 68k Amiga forward before sloppy Gunnar shortcuts and FPGA only limitations. This is in contrast to retro Amiga emulators and most FPGA Amiga/universal hardware.

The primary, biggest, problem is the original platform, unfortunately.

Evolving the hardware is possible, and some relevant modern things that can be added.

Evolving the software... no comment (already commented above).
Quote:

cdimauro Quote: Not when resources are shared. Early 64-bit support should be for exec.library memory allocations. A new MEMF_64bit memory allocation flag could continue to allow 32-bit allocations for compatibility when the flag is missing. There would be a little additional overhead of a branch and additional code. Some libraries could be 64-bit only or 32-bit only and 64-bit programs would open the 64-bit version while 32-bit programs would open the 32-bit version. The ability for 64-bit and 32-bit programs to execute simultaneously is required instead of for example, PPC cores with a 64-bit mode and 32-bit backward compatible mode selected at startup only.

This looks exactly like MacOS X "Tiger", where 32-bit applications were first-class citizens, and 64-bit applications were additional commodities can can only be used for calculations (because nothing else was available in this user space: no GUI, no drivers, etc.).

A so limited system which was quickly phased out by the next, full 64 bit, OS version.
Quote:

A 64-bit only AmigaOS is possible but compatibility seems to be more important for the Amiga with its retro 68k Amiga appeal.

As already suggested, the Amiga OS should run on a sandbox, whereas the new, Amiga-inspired, 64-bit OS will run everything else.

The Amiga OS platform is too old and too badly designed: it's better to leave it as it is, because enhancing it and not moving to something new (like it happened to other mainstream OSes) would only means preventing (real) innovations.

Let the Amiga platform die as it is, and think about the next big thing (which means: welcome to the modernity).
Quote:

cdimauro Quote: They share the same problems, and OS4 has very very limited improvements regarding the above statements. Let's face the reality: the Amiga OS was never designed for such modern features, and getting them is almost impossible (without dropping the backward compatibility). Then why insisting on modernizing it? The 68k AmigaOS could already have as good of memory protection as AmigaOS 4 using optional MMU support, optional code protection from tooltypes and prefs and new hunk flag types.

The problem is that even OS doesn't offer a good memory protection: it offers a very very limited one, due to the intrinsic very bad design inherited by the Amiga OS.
Quote:

Optional stack overflow protection with a MMU could also be added.

Right. But not a dynamic stack, unless you want to waste a lot of memory (space). The stack will still be limited to a certain size, set by the icon or the shell --> a very bad situation for applications.
Quote:

The problem is that the 68k AmigaOS is designated as a lower/poor class citizen to the expensive upper/rich/elitist class citizen PPC AmigaOS 4 but the lack of meaningful improvements means the 68k AmigaOS has to be sabotaged so it does not compete.

No, the real problem is that the Amiga OS was very badly designed by hackers with their restricted mindset, which completely crippled the platform and its future innovation.

If we've to talk about sabotage, then it's certainly coming from the original authors of the platform.

Who followed was doomed by decisions that were made by others, and that cannot be fixed or overcome without compromising the existing software base (which is the only thing which is left... almost all in binary format -> very very difficult to fix).
Quote:

cdimauro Quote: Systems without timers are justified to do CPU-based loop for timing (because there's no other way). Consoles as well, because their hardware is set into the stone and doesn't change. But it's not justified, at all, in all other cases. Especially if you've the vendor guidelines on how to develop the software. Which was Amiga's case. So, those who haven't followed such guidelines were idiots. Ignorants, at best. In 1985, CPU timing loops were likely the most common method for MPU timing. The 68k Amiga was very different from 8-bit hardware, there was not much Amiga documentation, and it was difficult to get everything right for such new and different hardware, especially for 8-bit programmers new to the Amiga. The situation for the Amiga improved quickly over the next several years and CPU timing loops were rare by 1987 as new higher clocked 68k accelerators punished holdouts. Ignorant assumptions about memory were more of a problem after that.

Even the Commodore Vic 20, released on 1980, had... timers!

And the Amiga documentation was already released to the developers BEFORE that the Amiga was first presented, as I've explored and reported on one of my articles which talked about bad programming practices & official guidelines.

Let's bring the curtain down, which is better....

cdimauro Quote:

There are ways, but you need to know them. In fact, you don't need to disable paging neither memory mapping (the two things are different, BTW) on modern systems (which more or less offer the same functionalities), rather to use the proper APIs. Spefically, for Windows you need to use: - VirtualAlloc ( https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc ) for manually allocating pages; - VirtualLock ( https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtuallock ) for locking a range of pages so that they aren't swapped out. There are constraints on using them, which require attention and proper coding, but you can set memory regions which guarantee no page faults by carefully & properly combining both APIs. This, united with the real-time priority and setting the process/thread affinity, is the way to reach close to real-time OSes performance. In short, yes: you can go back slim at memory handling even on "pachyderm" OSes.

I do not have similar real time responsiveness issues on a 68k Amiga with a fraction of the CPU clock speed and memory. I do not appear to be the only one either.

https://news.ycombinator.com/item?id=6792425 mnw21cam Quote:

Yes, the Amiga had proper honest multitasking. A normal boot of an Amiga system would typically result in over twenty processes running in the background. In fact, its particular style of multitasking (static absolute priorities) was well-suited to real-time operation. Back in the days when CD writers could create coasters from buffer under-runs, I had more success writing CDs using my 25MHz Amiga than my 400MHz PC. Also, it was a microkernel system with things like device drivers and filesystems as separate processes, which had some fairly nifty consequences. For instance, it took Linux ages to lose its single kernel spinlock, which was a problem because of the huge amount of stuff done in kernel space. The thing the Amiga didn't have (mostly because of lack of hardware capability) was memory protection.

The AmigaOS had preemptive multitasking in 256kiB of memory while the thread mentions the 68k Sinclair QDOS which had preemptive multitasking earlier and used less memory.

https://news.ycombinator.com/item?id=6792425 huxley Quote:

Sinclair QDOS which ran on the Sinclair QL did preemptive multitasking on a 128KB machine (buggy as heck when it came out but it did precede the Amiga by almost a year and half).

Of course QDOS inspired Linus Torvald to develop Linux with a monolithic kernel and the "single kernel spinlock" problem mentioned in the first quote above. So how did QDOS provide preemptive multitasking?

http://qdos.free.fr/QDOS.html Quote:

QDOS: The QDOS is the Sinclair QL operating system (QDOS = Ql Disk Operating System, nothing to do with the "Quick and Dirty Operating System" !). Its main characteristics are: o True preemptive multi-tasking (the programs running in memory are called "jobs"). o No use of any semaphore for shared ressources access. The critical ressources (hardware/shared data structures) are accessed through "atomic" (i.e. not interruptible by another job) system calls. This guarantees that the system cannot suffer from "deadlocks", the main flaw of most (if not all) other multitasking systems. o Dynamic memory allocation to the jobs, no inter-job memory protection mecanism (very flexible but very dangerous too...). o "Channels" oriented inputs/outputs (the jobs access to the peripherals they need through channels). This allows to access peripherals with peripheral independant system calls (for instance "PRINT" and "INPUT" may be used with all the QL peripherals). o All the directory device drivers (mass storage device drivers) benefit from the free memory as a cache (no disk cache software needed and the cache is dynamically allocated). o 100% 68000 assembly written OS (it uses only 48Kb of ROM, BASIC interpreter included !) thus very fast. o The command interpreter is the "SuperBASIC", a structured (Pascal like) BASIC. This is much more flexible and powerful than any classical shell. o Very little memory demanding OS; the basic QL only got 128 Kb of RAM and only 85 Kb were actually available for the jobs (32 Kb of RAM being used by the screen memory)... o High expandability (adding new device drivers to QDOS and new SuperBASIC extensions is actually very easy). o QDOS is a "Plug'n Play" OS. The add-ons cards may have their own ROM which contents (device driver, SuperBASIC extensions) is automatically linked into the system at startup. The ROM address may also be automatically attributed. Among the different QDOS ROM versions (FB, PM, AH, JM, JS, MG), only JS (which equiped English QLs) and MG (which equiped QLs sold in non-English speaking countries) are still in use nowadays, albeit there could still be some antediluvian QLs with a JM or even an AH ROM around... Because of the very limited ROM space, some useful system management extensions were missing from SuperBASIC. The Toolkit II (either held in a ROM cartridge, in an extension file to be loaded in RAM or in some add-ons on board ROMs) fills these gaps. As you can see Micro$oft did not invent anything and a "plug and play 32 bits preemptive multitasking operating system for personal computers" was already available 11 years before Windoze 95; the previous Windoze versions were using the 16 bits addressing mode of the x86 (which is much less efficient than the 32 bits addressing mode of the 680x0 or 486/Pentium), and were not preemptive (but cooperative: i.e. the responsability of the task switching initiative is left to the application instead of the OS: many crashes guaranteed !).

"No use of any semaphore for shared resources access" and "atomic" "not interruptible" code sounds like the AmigaOS.

1981 MS-DOS - no multitasking until limited and abandoned 1986 4.0, 16-bit limitations
1983 Lisa OS - cooperative multitasking
1984 QDOS - preemptive multitasking
1984 Mac OS - no multitasking until 1987 System 5 introduced cooperative multitasking
1985 Atari TOS - no multitasking until 1990 with Mint/MultiTOS
1985 AmigaOS - preemptive multitasking
1985 Windows - cooperative multitasking until Windows (19)95, not full OS, 16-bit limitations
1987 RISC OS - cooperative multitasking

Unix was around from the 1970s but it was not a PC OS where backward compatibility was important so the fact that it did not originally support multitasking, was not portable and had 16-bit limitations was less of a problem. The major reason it was not used for PCs was that Unix was expensive, required expensive hardware and was a resource hog. OS-9 had preemptive multitasking from inception, was cheaper than Unix and was an optional OS for several PCs but was not used as the default OS for any PC that I am aware of.

So which PC OS from the 1980s that maintained compatibility was better than the "very badly designed" AmigaOS?

cdimauro Quote:

But this isn't "68k SMP": this is "trying to introduce the SMP on the Amiga OS" (which can't have it because it's very badly designed).

The 68k SMP tools I propose would likely be useful at getting the Sinclair QDOS working with SMP too. It would not help all the retro cooperative multitasking OSs which are very "very badly designed" or the non multitasking OSs which are very very "very badly designed".

The x86 CPUs had hardware support to maintain MS-DOS and Windows compatibility with real mode, unreal mode, virtual 8086 mode, 16-bit protected mode, 32-bit protected mode, compatibility mode, 64-bit mode, system management mode, virtualized I/O, multiple memory models including segmented (address bank switching) with and without MMU and 32-bit/64-bit flat address space, protection rings, etc. Much of this support is complex and kludgy but Intel avoided the disaster of losing the desktop market to the 68k which has a single mode and 32-bit address space from inception. Ironically, Motorola started stripping out 68k compatibility and desktop features for the embedded market before surrendering the desktop market with the AIM Alliance agreement. In comparison to all the x86 compatibility baggage, the 68k hardware compatibility support I propose is relatively simple. I would also connect the necessary lines from 68k CPU cores to the chipset for locked instructions like TAS, CAS and CAS2 to work reliably as the AC68080 does. Do you consider this hardware support a hack/kludge that could aid in getting SMP working too?

cdimauro Quote:

As already discussed, the 68k have already "SMP" support since the 68000, thanks to the TAS instruction, which allows to implement some simple locking primitives (in hardware). The 68020 added CAS and CAS2 to make it more easy to implement some more advanced locking primitives. So, the problem isn't about the 68k processor family which is lacking something which prevents OSes to implement the SMP, rather trying to support only Amiga OS because, as it was designed, it can't do it. Am I wrong?

TAS alone was lame for multiprocessing support which is likely why the Amiga developers did not consider the loss of it due to how the Amiga chipset works as much of an issue. The loss of CAS and CAS2 with a 68020 was a bigger deal but I can not say they should have foreseen the issue. Semaphores and other locking means were added to the AmigaOS anyway although the work was not complete enough for multiprocessing. AmigaOS 4 added mutexes and more locking support but still does not support SMP. The 68020+ Mac OS uses CAS and CAS2 but does not even support preemptive multitasking. I believe it would be easier to get the 68k AmigaOS and QDOS with preemptive multitasking working with SMP than the 68020+ Mac OS using CAS and CAS2. A working CAS and CAS2 with AmigaOS may allow semaphores, mutexes and locks to work without Forbid/Permit and Disable/Enable though (SignalSemaphores rely on Disable which depends on hardware support). A lowest common denominator 68000 AmigaOS ensures 68k AmigaOS SMP would never be a threat to PPC AmigaOS 4 without SMP. An emulation only 68k virtual machine ensures 68k SMP will never happen also.

I wish I had input from developers like Carl Sassenrath, Jason McMullan, etc. We have this huge retro 68k Amiga surge in popularity and Amiga development is practically dead, killed by Amiga IP squatters and thieves holding the Amiga hostage.

cdimauro Quote:

Besides that clarification, I would leave MEMF_SHARED for the same behavior as OS4, and introduce MEMF_ATOMIC for such automatic locking of all RMW instructions running on those pages. However, I think that this is overengineering, if the only purpose of such new mechanism is to lock any modification to the respective counters (bytes) for the Forbid/Permit and Enable/Disable APIs. If this is the case, then it's enough to introduce a couple of new registers which hold the address of such counters, which force a locked RMW cycle for the specific byte being modified. Another (byte) register controls which one of the two locations are being monitored. So, and only for the Amiga OS, the location of the two bytes are put on those two new registers, and the their respective bits set on the new monitor-enable register. And that's it: you don't have to introduce a big complication on the existing software and APIs.

My MMU page attribute suggestion has dual use.

1. pages marked as shared change RMW to locked RMW memory accesses
2. SMP cores wait when accessing shared data during a Forbid on another core

Other uses and optimizations are possible too as it is can be advantageous to know if code and data is shared.

cdimauro Quote:

If it had been possible, existing Amiga applications would already have been patched to change MEMF_PUBLIC to MEM_SHARED, so that MorphOS and AmigaOS4 could take full advantage of memory virtualisation and, above all, resource tracking. Most applications have no sources anymore (that's also the reason why AROS is the ugly duckling of the post-Amiga OSes: because it supports a very small software pool), and reverse-engineering the existing ones AND understanding how they used the memory which they allocate AND patching according their binaries is a Gargantuan task. That's also because many of them are written in C, and they allocate memory using C's malloc(), which by default sets MEMF_PUBLIC (to be 100% sure that it can be used for any scenario. Which makes sense), and here patching the binary isn't straightforward, at all!

Problematic programs would be slower but would still work like MEMF_PUBLIC memory is disadvantaged vs MEMF_SHARED memory but still works. Memory flags are easy to change with sources and patching is not difficult although there are cases where memory may be used for multiple purposes as per your example.

cdimauro Quote:

See above: the problem isn't RISCs neither PowerPCs. The problem was/is AmigaOS, which was Broken-By-Design by the absurd decisions of its engineers, which crippled the platform since the very beginning, giving it no chance (at all!) to evolve according to the more modern needs. No sane OS should publicly expose its internals, and even more important was exposing APIs like Forbid/Permit, Disable/Enable (and I would put also Supervisor, at least) to the public. A properly written OS uses Getters, Setters, and Enumerators to fully control what the applications can do and carefully arbitrate how they access to sensible information (e.g.: the list of running tasks, the signals, the available memory, etc. etc. etc.). It's not the modern OSes which are bloated: it's AmigaOS which was written with feet by hackers who killed any possibility of its evolution. Now you want to dirty the processor architecture and introduce more complexity to the SoC solely to try to make up for their inability and bad design, solely to try (because that's all you can do. In fact, there is no guarantee of success in the endeavour) to modernise Amiga OS in SOME aspect. Do you think that it makes sense?

Unix/Linux and Windows were worse OSs initially than the AmigaOS. They evolved tremendously while the AmigaOS has evolved minimally. Windows received hardware support from the x86(-64) architectures for compatibility as I described above. Unix/Linux breaks compatibility and users are forces to recompile their software. RISC architectures often remove hardware compatibility too like ARM 26-bit address space support, extended precision FPU (yes, early ARM FPUs were extended precision like 68k and x86 FPUs), AArch32 support in ARMv9, etc.

https://www.riscosopen.org/wiki/documentation/show/Addressing the end-of-life of AArch32#TOC1 Quote:

1. Background The release in 2011 of architecture ARMv8 added a whole new instruction set called AArch64 with wider 64b register bank, and renamed what was previously referred to as the ARM instruction set (which RISC OS uses) as AArch32. The AArch64 instructions are not binary compatible with the older ones. Until very recently, the ARMv8 targets we would like RISC OS to support have fortunately still contained an implementation of AArch32 for backwards compatibility, allowing RISC OS to run and entirely ignoring the AArch64 aspects. As at 2020 it was becoming clear that Arm intended to wind down ARMv7 and earlier (fewer than 50% of the cores available to license would run that way) to focus on their ARMv8 offerings, of which many dropped AArch32 support entirely. In April 2021 the ARMv9 architecture was announced with AArch32 relegated to being a license option, in much the same way that 26 bit mode became an option in ARMv4 rarely taken up. At the end of September 2023, Raspberry Pi announced their new Raspberry Pi 5, with a 64-bit quad-core Arm Cortex-A76 processor. While this still supports 32 bit instructions, crucially only in ‘user’ mode. RISC OS makes heavy use of ‘supervisor’ mode, which this processor doesn’t implement. As such, there is no straightforward way to port RISC OS to the Pi 5. This proposal identifies aspects of RISC OS that will require attention in order to migrate away from AArch32, to help making design decisions, and ultimately a route to implementing changes to ensure there are chips in future to run on.

Some people say ARM won but it is not the original ARM. The new ARM is becoming incompatible with the previous 3 ARM ISAs. Maybe ARM thinks it is necessary to eject their legacy support to better compete with x86-64 with their compatibility baggage. It may work for the embedded market but likely not for the desktop market where compatibility is as important as performance.

I think the AmigaOS is not nearly as bad as you make it out to be. It is very good in some ways and was a compromise in other ways. It needs to evolve and I believe it is good enough to be worthwhile to evolve. It will not evolve without enough compatibility though. The once standard and backward compatible 68k AmigaOS is fracturing and dividing into incompatible camps. I do not see a problem with simple hardware support that retains the 68k AmigaOS standard and compatibility. At first you said 68k Amiga SMP was not possible with software compatibility and now you say it is a bad idea because the AmigaOS is "very badly designed" and "Broken-By-Design". I would like to hear more developer's opinions. I believe the 68k Amiga SMP efficiency with my ideas would be better than AROS x86-64 SMP efficiency and PPC AmigaOS 4 SMP efficiency if it was working and both of those are likely incompatible with existing software. I do not hear many devs saying it would not be worthwhile implementing SMP which it may be. At least if some existing software is compatible, I believe it is worthwhile to try to implement SMP.

cdimauro Quote:

It's just one byte added on rarely used instructions (e.g.: not relevant for the code density) and there's no decoding overhead (x86 processors can handle 2-3 prefixes without incurring in performance penalities). The performance overhead happens solely because of the instructions' implementation (which require more cycles due to the more complex logic).

The lock overhead for x86(-64) is less than RISC due to locked RMW instructions but x86(-64) encodings are far from desirable.

cdimauro Quote:

A 68k OS, which is NOT Amiga OS, can implement a lightweight SMP without all the overcomplication required only to patch the horrible job which was made with the Amiga OS. So, the problem is solely the Amiga OS. Certainly not the 68k processors.

Yes, 68k SMP may be possible with Linux using multiple CPUs already. Recompiling pre-SMP 68k Linux programs may be required though. Throw away compatibility and SMP is a lot easier.

cdimauro Quote:

See above: all such failures are only caused by the Amiga OS which was very badly written. AROS and OS4 (and I assume the same is for MorhOS) tried, but they haven't succeed solely because of that. So, not because people aren't gifted-enough, neither because the architectures were bad: the only culprit of this situation is the team of engineers which have realized an OS which is Broken-By-Design for implementing many modern features. Now, and as I've said, you want to TRY to resolve this mess adding horrible patches to the SoC. Doesn't is sound similar to the horrible patch of x86 (286, 386, x86-64) or PowerPC (prefix...) processors? To me yes. And, frankly speaking (as usual!), I don't like it (as I don't like the horrible patch of AGA on ECS).

Was the x86-64 ISA worse than staying with the Itanium or x86 ISA? Was AGA worse than staying with the ECS chipset? At least you would make suggestions for better upgrades but you can not make a suggestion for better 68k SMP compatibility other than to throw the "very badly designed" AmigaOS away.

cdimauro Quote:

So, from a generic 68k SoC with a small embedded FPGA to target multiple 68k systems, now the target become a 68k Amiga SoC with a large FPGA and SMP patches solely for the Amiga OS? Why?

A large FPGA with multiple CPU cores is how a SoC ASIC is developed. SMP for the 68k AmigaOS with compatibility is not a requirement for multi-system retro 68k hardware as AMP is good enough but SMP is important to system value and future opportunities with more than 2 cores.

cdimauro Quote:

That's because of what I've explained above: Amiga OS was very badly designed by its engineers and this crippled the platform. This is the exactly the reason of the current situation. Now, do you think that adding dirty patches to a SoC/architecture exclusively for trying to fix the big mess that the Amiga OS engineers made could be classified as "innovation"?

The camps breaking 68k Amiga compatibility should be able to add the necessary changes for SMP. They just break all their existing software and recompile but that misses the large retro 68k Amiga market and even the small PPC AmigaOS 4 market. Maybe it will work for AROS x86-64 or MorphOS x86-64/ARM but they will still miss the large retro 68k Amiga market. I believe for any Amiga product to succeed that it should target the large retro 68k Amiga market. Simple hardware changes that could much improve value and preserve compatibility should be considered. What makes a hardware patch/change dirty? Being different than mainstream which would make the whole 68k Amiga a dirty patch?

cdimauro Quote:

This looks exactly like MacOS X "Tiger", where 32-bit applications were first-class citizens, and 64-bit applications were additional commodities can can only be used for calculations (because nothing else was available in this user space: no GUI, no drivers, etc.). A so limited system which was quickly phased out by the next, full 64 bit, OS version.

There are different implementations and different 32-bit and 64-bit compatibilities of architectures. Maybe separate 32-bit and 64-bit AmigaOS versions with dual booting would be more optimal. Maybe the 64-bit AmigaOS would drop 32-bit compatibility and add SMP with major AmigaOS changes. Why are there not 2 versions of the PPC AmigaOS 4 with the 32-bit version without SMP for compatibility and a 64-bit version created with SMP and used for porting to other architectures? How many AmigaOS 4 users would use the SMP capable 64-bit AmigaOS with less software and no 68k emulation in the kernel?

cdimauro Quote:

As already suggested, the Amiga OS should run on a sandbox, whereas the new, Amiga-inspired, 64-bit OS will run everything else. The Amiga OS platform is too old and too badly designed: it's better to leave it as it is, because enhancing it and not moving to something new (like it happened to other mainstream OSes) would only means preventing (real) innovations. Let the Amiga platform die as it is, and think about the next big thing (which means: welcome to the modernity).

I believe multiple options should be explored but major AmigaOS changes likely would result in a sandbox for old software. It would likely be possible to boot the old versions of the AmigaOS for better compatibility on the same hardware.

cdimauro Quote:

The problem is that even OS doesn't offer a good memory protection: it offers a very very limited one, due to the intrinsic very bad design inherited by the Amiga OS.

I believe Commodore considered the lack of AmigaOS MMU use to be a very good design as they saved money by not providing 68k MMUs. Ironically, the bridgeboard could make use of a MMU for caches, 68030 accelerators used the MMU to fix a bug, the early Amiga 3000 used the MMU to protect the kickstart in memory and Enforcer made use of a MMU for debugging which also saved the system from crashing sometimes.

cdimauro Quote:

Right. But not a dynamic stack, unless you want to waste a lot of memory (space). The stack will still be limited to a certain size, set by the icon or the shell --> a very bad situation for applications.

If stopping a program with a stack overflow is a "very bad situation", what do you call crashing?

A MMU may more easily provide stack extension where at least VBCC only exits with -stack-check for the AmigaOS.

http://www.ibaug.de/vbcc/doc/vbcc.pdf Quote:

-stack-check Insert code for dynamic stack checking/extending if the backend and the environment support this feature. ... If the -stack-check option is specified when compiling, the library will check for a stack overflow and abort the program, if the stack overflows. Note, however, that only code compiled with this option will be checked. Calls to libraries which have not been compiled with -stack-check or calls to OS function may cause a stack overflow which is not noticed.

It may be possible to extend the stack without a MMU but would require careful coding.

cdimauro Quote:

No, the real problem is that the Amiga OS was very badly designed by hackers with their restricted mindset, which completely crippled the platform and its future innovation. If we've to talk about sabotage, then it's certainly coming from the original authors of the platform. Who followed was doomed by decisions that were made by others, and that cannot be fixed or overcome without compromising the existing software base (which is the only thing which is left... almost all in binary format -> very very difficult to fix).

The AmigaOS "was very badly designed by hackers", even though it was better than most other OSs of the 1980s as I showed above, and fixing the hardware for compatibility is a dirty hack. Windows using dirtier hardware hacks to maintain compatibility should have been thrown away too then but instead it became the most popular desktop OS. They should have made the necessary software changes breaking compatibility like Unix/Linux instead, even though the lack of standardization only gained 4% of the desktop market despite Linux becoming free on the same x86(-64) hardware compared to Windows with 71% of the desktop market.

@codis

more or less same here. except 68k i have and some next gen machines
but i'm not in to gaming too. productivity software is ancient and useless
these days. browsers don't cut it. so, here we are...

Quote:

AmigaBlitter wrote: Dudes, it's time to join the forces #??

It would help if applications or libraries (SDL2 + 3D) where available for all Amigaoid flavors.

@amigagr

Quote:

amigagr wrote: @codis ... productivity software is ancient and useless these days. browsers don't cut it. so, here we are...

Being relatively new on this forum, I didn't want to put it so bluntly.
But yes, that's how I see it.

@cdimauro

Quote:

kolla might know which ones.

Yeah, they can be summed up as “some atari ST games�.

I don’t know of any Amiga game or software that require “cycle exact� CPU… heck, not like one 68000 is “cycle exact� to the next one, from what I’ve gathered there’s variety between the various 68000 variants.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

1981 MS-DOS - no multitasking until limited and abandoned 1986 4.0, 16-bit limitations 1983 Lisa OS - cooperative multitasking 1984 QDOS - preemptive multitasking 1984 Mac OS - no multitasking until 1987 System 5 introduced cooperative multitasking 1985 Atari TOS - no multitasking until 1990 with Mint/MultiTOS 1985 AmigaOS - preemptive multitasking 1985 Windows - cooperative multitasking until Windows (19)95, not full OS, 16-bit limitations 1987 RISC OS - cooperative multitasking Unix was around from the 1970s but it was not a PC OS where backward compatibility was important so the fact that it did not originally support multitasking, was not portable and had 16-bit limitations was less of a problem. The major reason it was not used for PCs was that Unix was expensive, required expensive hardware and was a resource hog. OS-9 had preemptive multitasking from inception, was cheaper than Unix and was an optional OS for several PCs but was not used as the default OS for any PC that I am aware of. So which PC OS from the 1980s that maintained compatibility was better than the "very badly designed" AmigaOS?

For business customers, MS had Xenix, which Windows NT displaced. My Dad's work IBM PS/2 Model 55SX had a copy of OS/2 1.x, which wasn't used due to MS-DOS/Windows 3.0 and its apps. Fancy OS is nothing without desirable "killer apps".

https://apple.fandom.com/wiki/Apple_Lisa
Lisa OS featured protected memory and pre-emptive multitasking. Don't use Google AI results.

Lower-cost Mac's 128K RAM made multitasking impractical.

Windows 3.x 386 mode runs in 32-bit protected mode virtual machine running Windows 3.x standard mode (286). The same 32-bit protected mode virtual machine runs Win32S, which communicates (thunking) with Windows 3.1 standard mode 16-bit kernel.


Quote:

Was the x86-64 ISA worse than staying with the Itanium or x86 ISA? Was AGA worse than staying with the ECS chipset? At least you would make suggestions for better upgrades but you can not make a suggestion for better 68k SMP compatibility other than to throw the "very badly designed" AmigaOS away.

X86-64 won gaming PC grassroots e.g. Crysis X64 with Windows XP X64 and NVIDIA GPU driver support. Laptop PCs, office PCs, and gaming PC's larger economies of scale killed Itanium.

Before AMD purchased ATI, AMD had a close partnership with NVIDIA. Hector Ruiz's ego didn't allow AMD to merge with NVIDIA since Jen-Hsun Huang made a condition that the merged AMD-NVIDIA company's CEO would be Jen-Hsun Huang. AMD later hired Lisa Su (from IBM's microelectronics division i.e. game consoles business) as its CEO, who is a distant relative of Jen-Hsun Huang. AMD hiring Lisa Su also moved the Xbox and PlayStation game consoles business towards AMD.

Lisa Su and Nvidia co-founder and CEO Jensen Huang are first cousins, once removed. Su's maternal grandfather is the eldest brother of Huang's mother.

The ex-Motorola Hector Ruiz couldn't run a proper CPU business since he allowed Bulldozer architecture to depart from the core gaming PC market and focus on server PC's high thread count.

Ex-Motorola Hector Ruiz doesn't understand gaming PC's larger economies of scale when compared to the PC server market.

Hector Ruiz is from the Motorola Semiconductor division i.e. the same crapshow with 68K adventure. Pure embedded play arguments, this reminds me of Motorola. My argument is high-performance gaming 1st or bust. I wonder who is following the original Amiga vision.


PS; I extremely dislike Hector Ruiz.


Quote:

Unix/Linux breaks compatibility and users are forces to recompile their software.

Not with Linux's Proton layer, which encapsulates WINE and DXVK. Linux desktop's cloned Windows environment enforced closed-source compatibility.

SteamOS's direction is governed by Valve's CEO Gabe Newell, a former Microsoft employee responsible for Doom for Windows ports, DirectDraw. Newell spent 13 years at Microsoft as a programmer and technical executive, and produced the first three releases of the operating system Windows. At Microsoft, Newell led development on a port of Doom for Windows 95, which is credited with helping make Windows a viable game platform.

Under Gabe Newell's leadership, SteamOS is like Xenix for games, but with the Linux foundation instead.

Pure Linux with GNU middleware wouldn't defeat Windows i.e. it would take another Windows to defeat Windows.

Last edited by Hammer on 18-May-2025 at 03:51 AM.
Last edited by Hammer on 18-May-2025 at 03:45 AM.
Last edited by Hammer on 18-May-2025 at 03:40 AM.
Last edited by Hammer on 18-May-2025 at 03:38 AM.
Last edited by Hammer on 18-May-2025 at 03:19 AM.
Last edited by Hammer on 18-May-2025 at 03:14 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

amigagr Quote:

more or less same here. except 68k i have and some next gen machines but i'm not in to gaming too. productivity software is ancient and useless these days. browsers don't cut it. so, here we are...

Some 68k Amiga productivity software has aged well and others are useless. Quality paint programs, graphics processing programs, text editors, word processors, DTP programs, spreadsheets, databases, etc. are more usable with higher resolutions, more colors, more memory, solid state drives, etc. They would use less power today with real hardware but not with inefficient emulation. There are programs which have not aged well like web browsers but standards changed and this applies to all retro web browsers including Netscape on the 68k Mac which was THE standard.

OneTimer1 Quote:

It would help if applications or libraries (SDL2 + 3D) where available for all Amigaoid flavors.

If the Amiga was unified like in the 68k Amiga days, there would be no Amigaoid flavors to support.

kolla Quote:

Yeah, they can be summed up as “some atari ST games�. I don’t know of any Amiga game or software that require “cycle exact� CPU… heck, not like one 68000 is “cycle exact� to the next one, from what I’ve gathered there’s variety between the various 68000 variants.

The Amiga games that had the most problems due to CPU timing loops were ported games usually from the 8-bit world to the Atari ST and Amiga. The ski game Downhill Challenge is one I recall as playing way too fast on my 68030 Amiga 3000. Some other games played too fast and were partially playable but not this one. It reminds me of a Frogger clone someone brought up in a video with WinUAE recently without limiting the speed and was impossible to play. There are plenty of these types of games around but patches like WHDLoad and emulator configurations are more likely to fix the games since they are not being used from floppy.

Motorola 68000 CPUs I am aware of were cycle exact despite later changes. They still required the original clock speed for CPU timing loops to work where later ones often had a higher max clock rating and were lower power. There were at least 2 versions of the 68000 core that Motorola used irregardless of the chip process (originally NMOS, later CMOS). The early versions of the 68000 which were used by the Amiga had a user mode MOVE SR,EA and no BKPT instruction. The later embedded 68HC001 and 68EC000 made the MOVE SR,EA supervisor mode only, added BKPT and added a statically selectable 16-bit or 8-bit data bus so the 68008 could be discontinued. These chips used a new EC000 core that was a static CMOS design to support a wider range of clock speeds (down to zero if fully static) and 3.3V or 5V operation to reduce power (15mA@3.3V in the mid 1990s). It looks like the instruction timing was unchanged on this new EC000 core unlike the EXD 68000 core Motorola licensed which reduced most instruction latencies to 1/4 of 68000 timing and they may have exclusive licensed to kill the competition or maybe the EC000 core was lower power and better compatibility since they had less compatible higher performance options with the 68020+. This was at a time Motorola was neglecting if not sabotaging 68k development for PPC development.

Small feature changes can make a large difference to a CPU. If the original 68000 had a 16-bit or 8-bit selectable data bus, it likely would have achieved economies of scale sooner as 8-bit memory was very popular early in the life of the 68000. With a lower price for the 68000 CPU, memory and a board, IBM may have been compelled to buy the 68000 for the IBM PC. Motorola would have saved the time and cost of producing the short lived 68008 which may have allowed the 68020 to be released sooner. The 68008 used 70,000 transistors to the 68000 68,000 transistors which is a ~3% increase and likely acceptable although constraints in the late 1970s were severe. I find it odd that the MOVE SR,EA instruction was not selectable user/supervisor mode with a bit in the SR register or some other means. This would allow the EC000 core chips to be used for retro use today and may have allowed the continued production. The addition of the BKPT instruction is highly compatible so it is surprising there were not other instruction additions with the static design like LPSTOP which was first added to a CPU32 core and later to the 68060. The ColdFire MVS, MVZ, BYTEREV and BITREV instructions would have been great additions to increase code density and improve compiler support and embedded support without increasing complexity (they are all base 16-bit instructions). These were likely not developed in time for early versions of the EC000 though. Motorola was slow and inconsistent in developing ISA improvements for their 68k cores that could have made them more competitive. I am not so sure the EXD core made sense without ISA enhancements as a single cycle throughput CPU32 core makes more sense and later versions of it should have received the ColdFire instructions mentioned above. A more modern CPU32 core was not only a better choice for embedded use than ColdFire but it would have been compatible enough for retro use. Unfortunately, it was still too much 68k and threatened PPC.

Hammer Quote:

https://apple.fandom.com/wiki/Apple_Lisa Lisa OS featured protected memory and pre-emptive multitasking. Don't use Google AI results.

Google AI says the Lisa had pre-emptive multitasking. I did more than Google the Lisa OS but there were conflicting claims of cooperative and pre-emptive multitasking. I believe the claims against are stronger.

https://en.wikipedia.org/wiki/Talk%3AApple_Lisa Quote:

The Lisa OS provided non-preemptive multitasking. It is a common misconception that it had preemptive multitasking, but that was only avaiable on the Lisa if you ran one of the Unix ports, such as Unisoft. --Brouhaha 21:50, 20 Nov 2004 (UTC) Blakespot: How is it that you claim that it is "easily verified" that the Lisa had preemptive multitasking? The Lisa operating system documentation very definitely claims otherwise; Lisa applications have to periodically yield the CPU just as was historically the case on the Macintosh. But assuming that the application is written correctly, this is transparent to the user. This is also explicitly stated to have been a deliberate design decision in the invited paper "Architecture of the Lisa Personal Computer" by Bruce Daniels, published in Proceedings of the IEEE, Vol. 72 No. 3, March 1984, page 335: Quote: The CPU is multiplexed among the runnable processes by using a priority based nonpreemptive scheduling algorithm. This nonpreemptive scheduling policy guarantees correct access to shared resources, such as the bit-mapped display, by interactive processes without the performance penalty of having to explicitly lock and unlock these resources for each access. Since Bruce Daniels was one of the developers, I consider this to be an authoritative reference in the absence of more details on your "easily verified" claim. Are you possibly confusing "preemptive multitasking" with some other concept? I'm inclined to revert your change unless you can explain why the IEEE article and the Lisa OS documentation are wrong. --Brouhaha 02:17, 18 Dec 2004 (UTC)

The problem is people that blindly copy and paste information may spread misinformation.

Ron Nicholson said Amiga Corporation had an Apple II, ordered and were on the waiting list for an Apple Lisa and later bought a multi-user Sage workstation (Commodore bought a NeXT workstation for more Steve Jobs influence). The Lisa would have been an influence while designing the AmigaOS and the AmigaOS was likely an improvement from cooperative to preemptive multitasking. This may not seem important but it could be important for the Amiga as pre-emptive multitasking requires guarantees for the operating environment that changed from a single core to a multi-core environment but it may be possible to restore the guarantees in a multi-core environment like I suggested (cooperative multitasking has no guarantees). Whether the hardware changes are a dirty hack or should be patented is up for debate but unfortunately the corruption around the Amiga has a suppressive sabotaging non-intellectual aura about it. There will be no Amiga enlightenment or Amiga golden age until there is leadership change.

Hammer Quote:

Lower-cost Mac's 128K RAM made multitasking impractical.

The GUI was optional in other OSs like the Amiga. Multitasking is useful from a CLI. The Sinclair QDOS was a small footprint 68k OS: "Very little memory demanding OS; the basic QL only got 128 Kb of RAM and only 85 Kb were actually available for the jobs (32 Kb of RAM being used by the screen memory)..." QDOS was: "100% 68000 assembly written OS (it uses only 48Kb of ROM, BASIC interpreter included !) thus very fast."

http://qdos.free.fr/QDOS.html

The AmigaOS likely could have worked in 128kiB of memory with more time to optimize code and more of the code mature enough for a ROM. It may have been limited to 4 colors instead of 32, 64 or 4096 colors which would have been much less impressive considering the hardware.

Last edited by matthey on 18-May-2025 at 12:55 PM.
Last edited by matthey on 18-May-2025 at 07:45 AM.