@matthey

Quote:

matthey wrote: cdimauro Quote: @matthey: a 68020 based Amiga at the time was out of question. The Amiga 1000 was already quite expensive. However, at least properly considering the data structures for this "full" 32-bit processor should have been made. I wasn't suggesting the Amiga should have been introduced with 68020 but rather that a minimum 68020@14MHz standard could have come much earlier for the high end and earlier for the low end.

That should have happened with the A2000, while keeping the A500 as it was (but WITHOUT the crappy Slow RAM).

A 68020 for the low-end could have been a possibility with the introduction of the EC version.
Quote:

It wouldn't have been a huge memory savings but I expect a 68020 with chipset changes to reduce memory could have saved 5%-10% of memory.

Which chipset changes and which memory (bandwidth, I assume) savings?
Quote:

Much of the ROM and AmigaOS are code. Further code density improvements are possible.

Moving to assembly, which wasn't the case. However, the 512kB ROM had enough space for the most important libraries.
Quote:

The memory saving chipset improvements would have been nearly free by ECS release and practically free by AGA release.

Some details? I'm curious to know.
Quote:

cdimauro Quote: Regarding the AmigaBASIC, the two patches solve some problems, but unfortunately not the most important one: the 24-bit pointers + 8-bit metadata. This is the major CRAP which Microsoft did with this very nice IDE (because it was a revolution from this point of view: a modern environment for programming). The first patch was for the earlier Metacompco ABasic and is more complete while the latter is for the Microsoft AmigaBasic and minimal. I recall seeing a patched version of AmigaBasic with dirty pointers supposedly fixed but the problem is prevalent throughout and difficult to reliably fix without source code and a recompile. AmigaBasic also had very poor performance so it was best to toss it without a bug fixed version from CBM/M$. There were later options with some level of compatibility like GFA Basic as I recall.

In fact, I've used GFA Basic after that I've kicked out AmigaBasic: it was a great replacement. And FAST!
Quote:

There is AQB today includes integrated IDE as "An experiment in alternate history: what AmigaBASIC could have looked like, had it been developed further tailored to the Amiga OS." https://aminet.net/package/dev/basic/aqb-0.8.2 The source code is available if any later incompatibilities arise.

=== Requirements

* 3 MB RAM
* OS 2.0 (V36) or newer


That's nothing as specs for nowadays, and looks really nice.
Quote:

bhabbott Quote: Exactly what would 'standard MMU use' do for the end user? Nothing. I expect more than a few poor developers did not have access to a MMU for software testing and debugging considering CBM didn't even consistently provide a MMU for their supposedly high end hardware. Also, more end users with a MMU would have provided more software testers. Zero page and out of bounds illegal access monitoring are already a big improvement even without more traditional memory protection.

How can you achieve it without an MMU?
Quote:

CBM could have easily optionally supported protection and monitoring of hunks in a backward compatible way too.

It should have split the memory pools in at least two types: code and data. And grouping them in MMU pages, trying to "merge" what was coming from different hunks (even of different programs) to save space, due to the larger alignment which is required for the MMU pages.
Quote:

bhabbott Quote: You can blame Jay Miner for that - he didn't want Commodore producing a 'games machine' (despite that being the original plan for it). The A1000 was very expensive to produce so the price was too high, but if they had made it much cheaper it would compete against their other products - as well being seriously compromised to get the price down. To make matters worse Jack Tramiel had previously screwed their dealer network so bad that nobody wanted to stock it, while he competed against them with the cheaper Atari ST. Mind you he initially made the same mistake they did, thinking he could get enough sales in the US. The ST didn't make it big until entering Europe - where the Amiga should have been from the start too. From listening to Jay Miner's speeches, I believe he was supportive of a console as long as compatibility was maintained across all models which he was proud of for all existing Amiga models. My understanding is that it was the 1983 video game crash that scared CBM and many other computer game businesses off. Nintendo was practically the only console business left and they had to be creative and innovative to bring the market back.

Not only that. You can't compete with Nintendo which was selling its console for $199 ('til the GameCube. Starting from the Wii it stated to increase the price for its crappy and obsolete hardware).
Quote:

cdimauro Quote: They provided the necessary documentation for bare metal coding: what else was needed? It may have been possible to create standard code and an environment to safely shut down the AmigaOS for games. Something kind of like what WHDLoad provides today. Tell programmers to not kick out the AmigaOS unless they absolutely need to but provide a consistent and safer way of doing so.

That's more or less the topic of the article which I'm writing after the one which I've almost completed (on bare metal programming).
It was on the backlog from some time, but the comments from Randell Jesup and Mike Sinz on my posts on FB told me that it's time to face this argument.
Quote:

cdimauro Quote: Do it in Python and it'll take 1/100 of the time to achieve the same. And it may use 100 times the memory and have 1/10 the performance which may be important on less than bloated desktop computers.

Usually it's 1/100 the performance and 1/10 the memory, but anyway: not really important nowadays with the plenty of resources which we have.

However, you've to take a look at the scope: such resourcers/reassemblers tools are needed for experts, and not to the average Joe. And they do NOT need to be executed on the original machines.

That's why Python, with its super rich libraries and, especially, third-party libraries, is the best solution for implementing such tool.

Some example: https://www.capstone-engine.org
Capstone is a lightweight multi-platform, multi-architecture disassembly framework.
Our target is to make Capstone the ultimate disassembly engine for binary analysis and reversing in the security community.


Or: https://pypi.org/project/keystone-engine/
Keystone is a lightweight multi-platform, multi-architecture assembler framework. It offers some unparalleled features:


Or: https://pypi.org/project/unicorn/
Unicorn is a lightweight, multi-platform, multi-architecture CPU emulator framework based on QEMU.


Developers needs cool tool to boost their productivity. It's not time anymore to write everything in assembly, or C.

cdimauro Quote:

A 68020 for the low-end could have been a possibility with the introduction of the EC version.

The 68EC020 was and 68EC030 would have been an acceptable standard for the low end Amiga.

cdimauro Quote:

Which chipset changes and which memory (bandwidth, I assume) savings?

Most of what the chipset does improves performance, reduces system cost and saves memory. This is the point of the chipset over using the CPU and a screen buffer. CBM eventually used and planned upgrades and your chipset enhancement suggestions have mentioned some like chunky support (reduced buffers for c2p), sprite/BoB flipping, upgraded audio (larger audio samples, no CPU mixing), better multi-playfield/clipping support, etc. I was talking about memory savings to reduce cost but what reduces memory used usually reduces memory bandwidth used as well.

cdimauro Quote:

Some details? I'm curious to know.

It's just a comment about the cost of transistors at the time ECS and AGA were developed. The OCS chipset squeezed about as much as possible onto 3 affordable custom chips. Really, they were probably limited more by pins than transistors which likely could have been increased already using a more modern chip process. The process was old even for the MOS/CSG fabs. Too old of process at introduction is bad as the fab may be held up from modernizing or the fab may modernize and no longer support the old process. Also, an older process produces fewer parts due to the larger die size and smaller wafers. Newer chip processes and transistors were already very affordable by the 1990s yet CBM was still using 3 chips and 2/3 were still outdated NMOS for AGA. AGA should have never existed and AA+ should have been out before AGA.

Sometimes transistors came free on a chip earlier than the Amiga OCS.

https://archive.computerhistory.org/resources/access/text/2012/04/102658164-05-01-acc.pdf Quote:

House: So the 68000 was single level metal? Walker: Yes. House: 68010? Gunter: Yes. House: 68020? Walker: 20 is the one I think we moved to double level then, but it started out single with silicide. Gunter: That's right, but it was silicide. We had to have— Shahan: No, it was single metal with silicide on poly to get it down to 10 ohms per square. House: Something like that, yes. Shahan: Most people in the business today would go, “Single metal, are you out of your mind?� House: Yes, right. Shahan: Can't be done. Gunter: It can be done. Shahan: With lots of creativity, because in those days we would say, “Hey, sometimes transistors are free because the routing—“ House: Covers them up. Shahan: Covers them up. But routing is never free. It wasn't until in the 68000 family, the 68040 was the first two-layer metal design, still with silicide on the poly. We never did a 68000 that was triple metal. House: Is that right? Shahan: Our first triple metal design was the 88110. House: So you must have had die sizes that were quite a bit larger than Intel's. Gunter: I think so. All I remember is when the 68000 came out it was as much a fluke as anything, and I used to tell people we planned it that way. When the 68000 came out, it came out at 68000 square mills. At the time Motorola as a corporation had 68,000 people working for them. Was that kind of a fluke. I was trying to put that back into microns and so on. We didn't even have microns that'd go—we had motrons. We had our own definition of a micron.

The Amiga OCS chipset used an older 5000nm NMOS process than the 68000 3500nm NMOS process. This handicap was retained for 2/3 of the chipset until CBM committed financial suicide in 1994. Restrictive routing due to single layer metal was more likely to give free transistors but resulted in larger more expensive dies which were laid out by hand in the case of the 68000 and Amiga OCS. This makes it easier to understand why HAM mode was left in the OCS chipset after the upgrade to RGB. Fortunately, the 68000 pioneered and powered the workstations for the first generation of software chip production tools as mentioned in the article above. Unfortunately, the 68k and Amiga chipset were slow to adopt them.

cdimauro Quote:

In fact, I've used GFA Basic after that I've kicked out AmigaBasic: it was a great replacement. And FAST!

As I recall, it had a few bugs too but it was a big upgrade. CBM wanted M$ Basic though because it was the gold standard for "business" computers.

cdimauro Quote:

=== Requirements * 3 MB RAM * OS 2.0 (V36) or newer That's nothing as specs for nowadays, and looks really nice.

Much too high of spec for back then but probably could be reduced. It takes some effort to Amigatize programs by changing large executables into using lots of dynamic libraries.

cdimauro Quote:

How can you achieve it without an MMU?

I was saying a MMU would provide a significant benefit even without major changes to the AmigaOS to provide traditional demand paging MMU usage.

cdimauro Quote:

It should have split the memory pools in at least two types: code and data. And grouping them in MMU pages, trying to "merge" what was coming from different hunks (even of different programs) to save space, due to the larger alignment which is required for the MMU pages.

I have read the docs on memory pools but they lack an adequate explanation of the concept behind them, the direction planed for them and argument use for them. There are some good ideas but not enough info for most programmers. It is kind of like the MEMF_PUBLIC memory allocation flag which was good in concept and would be very useful today if programs used it correctly but it was not adequately explained and used by programs. Existing memory pools may be upgradeable enough though. The memory attributes flags for CreatePool() can be specified. AmigaOS 4 adds MEMF_EXECUTABLE and MEMF_HWALIGNED flags that would be useful for code.

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

AmigaOS 4 uses memory pools and introduced item pools to go with generic memory pools. The tag based memory allocation functions are likely slow, especially on RISC CPUs with load-to-use penalties but that was the RISCy future chosen for the Amiga along with a weak memory consistency model that has made SMP impossible.

cdimauro Quote:

Not only that. You can't compete with Nintendo which was selling its console for $199 ('til the GameCube. Starting from the Wii it stated to increase the price for its crappy and obsolete hardware).

It certainly would have been more difficult to sell a higher priced Amiga console in the aftermath of the 1983 video game crash than a cheap Nintendo console. More recently, the Nintendo Switch competes at the low end of the console market. The ARM based hardware is very much inferior in spec but the lower power offers versatility increasing the value. It was an interesting decision instead of a microconsole at maybe 1/3 of the price.

cdimauro Quote:

That's more or less the topic of the article which I'm writing after the one which I've almost completed (on bare metal programming). It was on the backlog from some time, but the comments from Randell Jesup and Mike Sinz on my posts on FB told me that it's time to face this argument.

Sounds interesting.

cdimauro Quote:

Usually it's 1/100 the performance and 1/10 the memory, but anyway: not really important nowadays with the plenty of resources which we have. However, you've to take a look at the scope: such resourcers/reassemblers tools are needed for experts, and not to the average Joe. And they do NOT need to be executed on the original machines. That's why Python, with its super rich libraries and, especially, third-party libraries, is the best solution for implementing such tool. Some example: https://www.capstone-engine.org Capstone is a lightweight multi-platform, multi-architecture disassembly framework. Our target is to make Capstone the ultimate disassembly engine for binary analysis and reversing in the security community. Or: https://pypi.org/project/keystone-engine/ Keystone is a lightweight multi-platform, multi-architecture assembler framework. It offers some unparalleled features: Or: https://pypi.org/project/unicorn/ Unicorn is a lightweight, multi-platform, multi-architecture CPU emulator framework based on QEMU. Developers needs cool tool to boost their productivity. It's not time anymore to write everything in assembly, or C.

Python just needs Amigatizing too. There is not much motivation without real Amiga hardware though. If the $4 RPi Pico can do it then Amiga could if it was as popular as this embedded hardware that doesn't even have a video output.

Last edited by matthey on 08-Oct-2024 at 08:15 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Some details? I'm curious to know. It's just a comment about the cost of transistors at the time ECS and AGA were developed. The OCS chipset squeezed about as much as possible onto 3 affordable custom chips. Really, they were probably limited more by pins than transistors

Hum. I recall that Ron Nicholson talked about how he was carefully checking what features were to be introduced in the chips, because he was taking count of the transistor budget.

So, they had severe constraints, likely caused by the very old process which MOS was using.
Quote:

which likely could have been increased already using a more modern chip process. The process was old even for the MOS/CSG fabs. Too old of process at introduction is bad as the fab may be held up from modernizing or the fab may modernize and no longer support the old process. Also, an older process produces fewer parts due to the larger die size and smaller wafers.

Exactly. Commodore should have moved to a newer process already several years before the introduction of the Amiga, bringing A LOT of gains in terms of packed transistors AND operating frequencies.
Quote:

Newer chip processes and transistors were already very affordable by the 1990s yet CBM was still using 3 chips and 2/3 were still outdated NMOS for AGA.

Well, Commodore introduced a process already one year after the release of OCS / Amiga 1000, for the 65CE02. With HUGE benefits in the terms that I've reported here above.

So, the thing to do should have been: use it for a shrink of the three chips. Even just doing that it would have reduced the chips size, hence the productions costs. And Agnus and Paula could have been already combined in one chip, since the don't require so many transistors compared to Denise -> other costs savings.

At Commodore worked blind people, in ALL areas...
Quote:

AGA should have never existed and AA+ should have been out before AGA.

Right. But I've already shared my vision & timeline.
Quote:

Sometimes transistors came free on a chip earlier than the Amiga OCS. https://archive.computerhistory.org/resources/access/text/2012/04/102658164-05-01-acc.pdf Quote: House: So the 68000 was single level metal? Walker: Yes. House: 68010? Gunter: Yes. House: 68020? Walker: 20 is the one I think we moved to double level then, but it started out single with silicide. Gunter: That's right, but it was silicide. We had to have— Shahan: No, it was single metal with silicide on poly to get it down to 10 ohms per square. House: Something like that, yes. Shahan: Most people in the business today would go, “Single metal, are you out of your mind?� House: Yes, right. Shahan: Can't be done. Gunter: It can be done. Shahan: With lots of creativity, because in those days we would say, “Hey, sometimes transistors are free because the routing—“ House: Covers them up. Shahan: Covers them up. But routing is never free. It wasn't until in the 68000 family, the 68040 was the first two-layer metal design, still with silicide on the poly. We never did a 68000 that was triple metal. House: Is that right? Shahan: Our first triple metal design was the 88110. House: So you must have had die sizes that were quite a bit larger than Intel's. Gunter: I think so. All I remember is when the 68000 came out it was as much a fluke as anything, and I used to tell people we planned it that way. When the 68000 came out, it came out at 68000 square mills. At the time Motorola as a corporation had 68,000 people working for them. Was that kind of a fluke. I was trying to put that back into microns and so on. We didn't even have microns that'd go—we had motrons. We had our own definition of a micron. The Amiga OCS chipset used an older 5000nm NMOS process than the 68000 3500nm NMOS process. This handicap was retained for 2/3 of the chipset until CBM committed financial suicide in 1994. Restrictive routing due to single layer metal was more likely to give free transistors but resulted in larger more expensive dies which were laid out by hand in the case of the 68000 and Amiga OCS. This makes it easier to understand why HAM mode was left in the OCS chipset after the upgrade to RGB. Fortunately, the 68000 pioneered and powered the workstations for the first generation of software chip production tools as mentioned in the article above. Unfortunately, the 68k and Amiga chipset were slow to adopt them.

Yes, this is another factor, but see also above: Commodore already had new processes, but it never used for the Amiga chipset! That was the first and big mistake: do NOT take advantage of the new processes! Something which, instead, other silicon companies were doing, because of the obvious (not for Commodore!) advantages.
Quote:

cdimauro Quote: In fact, I've used GFA Basic after that I've kicked out AmigaBasic: it was a great replacement. And FAST! As I recall, it had a few bugs too but it was a big upgrade.

Yes, but bugs can be fixed because the product was actively developed.
Quote:

CBM wanted M$ Basic though because it was the gold standard for "business" computers.

I assume that it was a good $$ deal, but it should have imposed its guidelines to Microsoft as well, to get a better and future-proof product.
Quote:

cdimauro Quote: === Requirements * 3 MB RAM * OS 2.0 (V36) or newer That's nothing as specs for nowadays, and looks really nice. Much too high of spec for back then

Sure, but this is a new product. It's quite young compared to the Amiga Age.
Quote:

but probably could be reduced. It takes some effort to Amigatize programs by changing large executables into using lots of dynamic libraries.

The main problem is taking advantage of the Amiga's built-in libraries, which already offer several functionalities, whereas ports from alien system have to reinvent the wheel by using also other alien libraries.
Quote:

cdimauro Quote: How can you achieve it without an MMU? I was saying a MMU would provide a significant benefit even without major changes to the AmigaOS to provide traditional demand paging MMU usage.

Ah, ok. Got it now.

I was wondering before, because I've submitted an idea when I was working at Intel, which would have helped catching illegal memory accesses without using a regular (P)MMU. And with the advantage of checking them with a byte granularity.
Quote:

cdimauro Quote: It should have split the memory pools in at least two types: code and data. And grouping them in MMU pages, trying to "merge" what was coming from different hunks (even of different programs) to save space, due to the larger alignment which is required for the MMU pages. I have read the docs on memory pools but they lack an adequate explanation of the concept behind them, the direction planed for them and argument use for them. There are some good ideas but not enough info for most programmers. It is kind of like the MEMF_PUBLIC memory allocation flag which was good in concept and would be very useful today if programs used it correctly but it was not adequately explained and used by programs. Existing memory pools may be upgradeable enough though. The memory attributes flags for CreatePool() can be specified. AmigaOS 4 adds MEMF_EXECUTABLE and MEMF_HWALIGNED flags that would be useful for code. https://wiki.amigaos.net/wiki/Obsolete_Exec_Memory_Allocation https://wiki.amigaos.net/wiki/Exec_Memory_Allocation AmigaOS 4 uses memory pools and introduced item pools to go with generic memory pools.

That's different from what I was suggesting before. Pool was not the Amiga pool concept, rather just splitting the memory handling into two different arenas (maybe it's a better term): one which is serving the requests for code segments/sections, and one for all other (data) requests.

Regular OS pools / slabs can be used to manage those two different arenas, trying to group together as much as possible such requests, to better use the space on single memory/MMU pages.
Quote:

The tag based memory allocation functions are likely slow, especially on RISC CPUs with load-to-use penalties but that was the RISCy future chosen for the Amiga along with a weak memory consistency model that has made SMP impossible.

Absolutely. Tags were future-proof with their flexibility, but really slow to handle.
Quote:

cdimauro Quote: Usually it's 1/100 the performance and 1/10 the memory, but anyway: not really important nowadays with the plenty of resources which we have. However, you've to take a look at the scope: such resourcers/reassemblers tools are needed for experts, and not to the average Joe. And they do NOT need to be executed on the original machines. That's why Python, with its super rich libraries and, especially, third-party libraries, is the best solution for implementing such tool. Some example: https://www.capstone-engine.org Capstone is a lightweight multi-platform, multi-architecture disassembly framework. Our target is to make Capstone the ultimate disassembly engine for binary analysis and reversing in the security community. Or: https://pypi.org/project/keystone-engine/ Keystone is a lightweight multi-platform, multi-architecture assembler framework. It offers some unparalleled features: Or: https://pypi.org/project/unicorn/ Unicorn is a lightweight, multi-platform, multi-architecture CPU emulator framework based on QEMU. Developers needs cool tool to boost their productivity. It's not time anymore to write everything in assembly, or C. Python just needs Amigatizing too.

Yes, the same thing which I've shared before should apply. But it requires a lot of effort.

Fortunately, Python isn't a so big project, and the areas where there's overlapping / reinventing the wheel are limited. Yet, it requires quite some time to have a proper Amiga versiom.
Quote:

There is not much motivation without real Amiga hardware though. If the $4 RPi Pico can do it then Amiga could if it was as popular as this embedded hardware that doesn't even have a video output.

RPi wasn't popular, yet it's a very well known and used now.

The problem with the Amiga was the usual one: lack of people with the right vision AND the money to give it a second life.

@cdimauro

Funny. A friend posted your article to my Amiga club Facebook group. Then I see it here.

So the image is rather quirky. It looks as if a C compiler wrote ASM to an absolute location. It starts with linking A6 and pulling strings off the stack. It doesn't check the pointers. Somehow it finds a null byte terminator almost by accident. It really does look like it pulled a Homer.

EAB is popular. And that thread does highlight the attitude which broke a lot of software on anything other than the exact A500 the game targeted. To which Commodore took a lot of blame for when they did update and upgrade the Amiga. In this day and age, modern code should really be clean. Not just because Amigaland has been more than a bog standard A500 the last 30 years, but because a lot of these coders became professional programmers and their code should be clean at work and at home. Aside from that, gloating about doing it the wrong way on purpose, looks immature from someone who likely is approaching middle age.

I made a late reply.

https://eab.abime.net/showpost.php?p=1679516&postcount=5

Your article focused on games. But the problem also existed with OS software. A lot would have written to planes directly. Other software did things like poking around in undocumented data like AllocVec() returned. I recall OS4 had an early issue because the private data didn't replicate the 68K function, so bad 68K code hacking the data acted faulty. This highlights a similar problem as the OS4 routine needed to be patched because so many people peeked around there. I don't know why any software needed to peek around memory it had allocated and it looks faulty to me if software doesn't know the details of memory it allocated itself if it needs snoop around it.

Even OS friendly games were hacky. Take Gloom 3. So when I began writing CIAgent on OS4 I used Gloom 3 to test it a lot. Yes, it could actually run on OS4. But I found I had to insert a kludge. Gloom 3 hacks the keyboard.device interrupt in the CIA resource structure. So it in effect hacks into my own CIAgent resources. Which I have to check for when updating internal serial keyboard register. I have no idea why an "OS friendly" game needs to hack the OS. The CIA resources must only be opened at all for it to hack because it must have pulled a Homer.

There are some OS quirks that can be easily missed. I know because I somehow misread the API. Functions like OpenFromLock() have quirks that don't seem logical but can be catastrophic if missed. So it opens a file handle from a lock. But the Catch 22 is it also releases the lock! I've used this function in code decades ago but only late this century did I find out about an important detail. That, for whatever reason it destroys the lock, even though the sole purpose is to simply open from a lock. I've also come across other people who missed it as well, and when I could see it in source code after knowing about it, I would notify them. This would be the case of an innocent mistake. Even though it would have been in the 68K API for a long time, it's only on OS4 I found out about it. Depending on underlying filesystem, reusing the dead lock will either crash or freeze. I've found, when testing or programming things on OS4 on my A1/XE way back when, that OS4 was the best debugger for testing 68K code! One thing OS4 was good at was finding faulty code. It was annoying at the time but it was good at highlighting bad 68K code. You just couldn't single step through it.

https://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0197.html

I found out first hand about "spurious software" when I did a porting of MED replayer to AHI. MED is considered to be a clean module format with note data layout. Compared to PT which squeezed note data into nibbles and had to extend beyond 15 instruments. But, PT is a reverse engineered hack after all. However, I found the MED replayer did some weird stuff. My method was to cache all audio writes until end of interrupt, check and verify of any changes, then send any update including sample triggering to AHI. For obvious reasons, live audio writes cannot be immediately sent to AHI, since it is a driver API and not hardware. I found that the AHI player had some faults because of what the player was doing. When a sample was started it didn't cleanly start it on that interrupt. It would set volume to zero, set frequency to some random value (usually $FF00 which was real low), start DMA then set volume and frequency to correct values a few interrupts down the track! It made no sense! So I then had to check for these faulty values. I had wondered if Tenjo actually tested his code in a debugger at all. It may run as an interrupt but you don't need to test it in one.

There are also accepted solutions. Again audio. Module replayers commonly set sample loop or silence loop by starting audio DMA, then waiting for it to settle before setting loop, by busy waiting in the interrupt! Usually by waiting two screen lines. To me this just looks dirty, and so what if it's checking vertical screen position, it's busy waiting inside an interrupt! I also didn't see why. For one thing, why couldn't it start DMA in one interrupt and set loop the next? The average PT interrupt run at 50 FPS. Is it really changing to another sample faster than 50 FPS on average? How could anyone hear that fast!? Given the MED routine takes a few interrupts, writing spurious data in the meantime, it is certainly possible. Newer routines use two timers, one for main player and secondary for loops. But again, given the average length of a sample, how soon did it need to be?

Well, that's a summary of things I've noticed. There would be more. But before too long I'll stop short.

@Hypex

Quote:

Hypex wrote: @cdimauro Funny. A friend posted your article to my Amiga club Facebook group. Then I see it here.

Could you please share the link to your group? I'm interested on the comments.
Quote:

So the image is rather quirky. It looks as if a C compiler wrote ASM to an absolute location. It starts with linking A6 and pulling strings off the stack. It doesn't check the pointers. Somehow it finds a null byte terminator almost by accident. It really does look like it pulled a Homer.

I've carefully assembled it putting Homer at the center of attention, for obvious reasons (if someone has seen that specific episode, of course).
Quote:

EAB is popular. And that thread does highlight the attitude which broke a lot of software on anything other than the exact A500 the game targeted. To which Commodore took a lot of blame for when they did update and upgrade the Amiga.

Indeed. At least in this case it had no responsibilities at all, since it was entirely on the shoulders of the idiots that haven't followed its guidelines.
Quote:

In this day and age, modern code should really be clean. Not just because Amigaland has been more than a bog standard A500 the last 30 years, but because a lot of these coders became professional programmers and their code should be clean at work and at home. Aside from that, gloating about doing it the wrong way on purpose, looks immature from someone who likely is approaching middle age. I made a late reply. https://eab.abime.net/showpost.php?p=1679516&postcount=5

I don't expect changes: they haven't done in 30-40 years, and they'll continue with their bugged mindset. Bugs aren't only on software...
Quote:

Your article focused on games. But the problem also existed with OS software. A lot would have written to planes directly. [...] Well, that's a summary of things I've noticed. There would be more. But before too long I'll stop short.

Yes, I know that OS-friendly software suffered of similar issues.

However, games and demos were number 1s when talking about very very bad coding practices, which have shown their nefarious effects. You inserted the floppy and... BOOM! You know it...

That's the reason why I've focused on them.

But yes: idiots are found also on products which were supposed to be OS... "friendly".

In Italy there's a sentence which is roughly translated as: "the mother of idiots is always pregnant".