Was anyone else disappointed with the A1200?

[Bruce Abbott]

Originally Posted by grond

Did you code for ARM32 or Thumb? I thought that ARM32 took a lot of the good stuff from 68k (I'm certain 68k was one inspiration for the ARM ISA) and left away a lot of the awkward stuff. Of course, there are some typical RISC things which can be great (3-operands) or not so great (I never was convinced the link register was a good idea, the 26-bits PC register certainly wasn't). I wrote pure assembly code (only ARM32, no Thumb), and used GNU AS for generating executable files.

STM32F3 is 'thumb-2' which includes both 16 and 32 bit instructions.

According to this article, the inspiration for ARM was IBM's research into RISC. They needed a CPU architecture that was very simple (because they had very limited limited development resources) but also fast - and ARM was the result. Some of its functionality was probably inspired by the 6502, which is almost RISC itself though not very efficient. But its main advantage over other CPUs was very low power draw, which happened 'accidentally' as a result of the minimalist design. That's why you see ARM in so much embedded stuff. The vast majority of MCUs made today are ARM based.

[Thomas Richter]

Originally Posted by Bruce Abbott

The non-documented BCPL interface? We are talking about 'application' (aka game) developers here, not Commodore's system programmers.

It was available to the BCPL compiler, obviously, just that CBM decided not to publish it.

Originally Posted by Bruce Abbott

It's rather fortunate for us that DOS functions were given a 'standard' interface with asm calling conventions.

What's exactly "asm" to that I do not know. In that sense, the Mac also had an "asm" interface because you had to use Line-A traps to call the system, and that's not a C primitive at all. Putting arguments in the stack is neither a C interface. It is just an implementation decision.

Originally Posted by Bruce Abbott

The Amiga was designed to be programmed 'bare metal' from the start.

Which is why we have all the nice system libraries to ignore, right?

Originally Posted by Bruce Abbott

In fact during the first demonstrations (including the 'boing ball' demo) it didn't have an operating system.

Ehem. BoingBall is working on top of the Os. Actually, what became the graphics.library is a collection of graphic primitives that were considered useful.

Originally Posted by Bruce Abbott

The Amiga's multitasking OS got in the way of that, so many developers shut it down completely to avoid problems.

Ah, so it was designed to be ignored? Contradiction in terms. It was there to be used, and not by the average game hackers. It was unfortunately misunderstood as a toy...

Originally Posted by Bruce Abbott

One could argue that this was an outdated practice, but the OS didn't provide enough support for developers to get the best out of the machine and was buggy and difficult to handle, so I can understand why they did it.

Actually, it was easier to handle than that of the competitors, just that the system attracted the wrong people that were more hackers and hobby programmers than software engineers. Try to work with Mac resources, just to give you ideas what's hard to handle.

Originally Posted by Bruce Abbott

For example, would you recommend using gels instead of taking over the blitter etc. to get the best performance?

It doesn't do anything different than the average bob drawing engine of your game - it also fires off the blitter on the graphics to draw.

Originally Posted by Bruce Abbott

Real game devs would laugh at that suggestion and say that you had no idea how to create software.

Actually, average game programmers had no idea on the Os in first place. The toy system attitude killed the system.

[Thorham]

Originally Posted by Bruce Abbott

The Amiga was designed to be programmed 'bare metal' from the start.

Mostly games hit the hardware, applications are usually well behaved programs that run under the OS, and thank goodness for that.


The Amiga wasn't aimed at just games and was sold with an OS right from the start, so you're obviously wrong.

[hammer]

Originally Posted by Thomas Richter

Actually, average game programmers had no idea on the Os in first place. The toy system attitude killed the system.

Dread/Grind C2P "hits the metal" since AmigaOS's WriteChunkyPixels function is slow.

Would AmigaOS 3.2 function calls deliver games like Reshoot Proxima 3?

[hammer]

Originally Posted by Thorham

Mostly games hit the hardware, applications are usually well behaved programs that run under the OS, and thank goodness for that.


The Amiga wasn't aimed at just games and was sold with an OS right from the start, so you're obviously wrong.

Deluxe Music 2 doesn't work on AmigaOS 4.1 FE on classic.

[Thorham]

Originally Posted by hammer

Deluxe Music 2 doesn't work on AmigaOS 4.1 FE on classic.

That's just one program, though

[grelbfarlk]

I mean, you can buy a TF1230 today for 189,89 € tax incl.
Features:
• Compatible with all Amiga 1200 PCB revisions (including Re-Amiga 1200)
• Increase a 780% the speed of your Amiga 1200
• Motorola 68030/50Mhz CPU with MMU
• RAM memory: 64 or 128MB of FAST RAM memory on-board
• Fast IDE controller for Hard Disks or CF/SD cards (*)

Way back when, something like this would cost about $200 in 1994 dollars.

[TEG]

Originally Posted by Bruce Abbott

The Amiga was designed to be programmed 'bare metal' from the start

The problem with your sentence is that it implies that this was done by drawing which is crossing the Rubicon. It would be fairer to say, due to the circumstances, the option was available and even essential taking into account 1985 hardware power and lack of time to provide an OS with all in it at Amiga launch.

So it was something necessary and inevitable but not a design per se.

[Thomas Richter]

Originally Posted by hammer

Dread/Grind C2P "hits the metal" since AmigaOS's WriteChunkyPixels function is slow.

Would AmigaOS 3.2 function calls deliver games like Reshoot Proxima 3?

The problem is designing the game such that C2P is even necessary - it is usually better to "blit" entire graphics. This said, the C2P speed certainly did improve in 3.1.4 already, and if you have RTG graphics, the replacement function (for copying chunky pixels to a chunky frame buffer) is again much faster.

[Thomas Richter]

Originally Posted by Thorham

That's just one program, though

DMusic goes through the audio.device (as it should), so the question is to which degree the audio.device is workable under Os 4. Given that Paula has adjustable sampling rates, though most "standard hardware" is nailed to 48kHz sampling frequency, bets are that any implementation of this device on PPC hardware is limited.

[Thorham]

Originally Posted by Thomas Richter

The problem is designing the game such that C2P is even necessary - it is usually better to "blit" entire graphics.

Dread and Grind are 2.5D like Doom, and work on a standard A500.

[hammer]

Originally Posted by grelbfarlk

I mean, you can buy a TF1230 today for 189,89 € tax incl.
Features:
• Compatible with all Amiga 1200 PCB revisions (including Re-Amiga 1200)
• Increase a 780% the speed of your Amiga 1200
• Motorola 68030/50Mhz CPU with MMU
• RAM memory: 64 or 128MB of FAST RAM memory on-board
• Fast IDE controller for Hard Disks or CF/SD cards (*)

Way back when, something like this would cost about $200 in 1994 dollars.

From https://amigastore.eu/868-terrible-f...128mb-ide.html
TF1230 has 169.90 € tax included.

https://www.amibay.com/threads/tf123.../#post-2495161
AlenPPC sells TF1232 from $135 USD to $220 USD. TF1232 model has 68882 FPU socket

[hammer]

Originally Posted by Thomas Richter

The problem is designing the game such that C2P is even necessary - it is usually better to "blit" entire graphics. This said, the C2P speed certainly did improve in 3.1.4 already, and if you have RTG graphics, the replacement function (for copying chunky pixels to a chunky frame buffer) is again much faster.

Grind and Dread is designed to run on stock A500 with 1MB RAM. It's an alternative "What IF" for stock A500 with 1 MB and A1200 with 2MB.

[hammer]

Originally Posted by Thorham

That's just one program, though

It's an example.

Aegis Spectra Color doesn't work.

Shapeshifter doesn't work.

Fusion doesn't work.

SysInfo doesn't work.

CU Amiga 1994-12's XCad Designer disk expander crashed.

I have many full applications from British Amiga magazines.

I prefer A1200 with PiStorm-RPi 4B-Emu68 (retro with power) over WinUAE 5.3's A4000/CyberStormPPC/GREX/Voodoo 3/AmigaOS 4.1 FE. I also have QEmu8's SAM460/AmigaOS 4.1 FE.

If a healthy PC platform took about six years from Windows 95/98's transition to Windows XP, it's worst on PowerAmiga NG.

[hammer]

Originally Posted by Thorham

Mostly games hit the hardware, applications are usually well behaved programs that run under the OS, and thank goodness for that.

The Amiga wasn't aimed at just games and was sold with an OS right from the start, so you're obviously wrong.

When Amiga's gaming scene dropped out, it took out most of the Amiga's non-gaming scene along with Commodore itself.

Bernd "we don't care about games" Meyer's Amithlon doesn't address the A500 gaming majority. The remaining non-gaming Amiga users remained with the platform e.g. purchased 68060s, classic PowerAmiga, and PowerAmiga NG. These are numbered in a few thousand which is not enough to sustain a Commodore size company.

Has Amiga Technologies GmBH/Phase 5 rivaled TheA500mini's return to mainstream shops? Escom era has 20,000 A1200s.

When Escom went bust, Amiga Technologies GmBH couldn't sustain itself without the aid from Gateway 2000.

Again, Amiga is not a Mac. The key word is "mostly".

A500's Batman Pack can't be ignored.

[AestheticDebris]

Originally Posted by Thomas Richter

Actually, average game programmers had no idea on the Os in first place. The toy system attitude killed the system.

Amiga games programmers weren't doing anything coders on other systems such as the PC, everyone just hit the hardware back in the day on order to get the most performance out of limited hardware.

Microsoft worked with those developers to produce a strategy that moved them away from hitting the hardware, it took many years and several missteps before getting to DirectX. Commodore might have done similar if they'd stuck around, they were clearly reluctant to document AGA mostly because they knew getting developers to use the OS instead was the way to go, they just didn't have a clear strategy on how that transition would work.

[paraj]

Originally Posted by AestheticDebris

Amiga games programmers weren't doing anything coders on other systems such as the PC, everyone just hit the hardware back in the day on order to get the most performance out of limited hardware.

Microsoft worked with those developers to produce a strategy that moved them away from hitting the hardware, it took many years and several missteps before getting to DirectX. Commodore might have done similar if they'd stuck around, they were clearly reluctant to document AGA mostly because they knew getting developers to use the OS instead was the way to go, they just didn't have a clear strategy on how that transition would work.

Yes, and they were right to do so, anything else would be financial suicide. Luckily it's been a while since I was in the game biz, but you (the dev, not the publisher) only really make money for the first X months (where X is low, but don't remember the number and it was likely different back then). You have to make something that's competitive, appealing, and works on the HW you expect buying users to have when it's released. Having it being slower but more compatible with future hardware/OS versions is not an option (not to speak of the fact that if you can't test it, it likely won't work anyway or will have bugs).


I'll also guess that many developers were aware of what the OS could do, and found it too slow for what they were trying to accomplish. Even in 2024 people (rightly) forgo the OS for time critical parts if they're not targeting RTG.

[Thorham]

Originally Posted by paraj

Even in 2024 people (rightly) forgo the OS for time critical parts if they're not targeting RTG.

For games that's perfectly acceptable.

[hammer]

Originally Posted by Thomas Richter

The problem is designing the game such that C2P is even necessary - it is usually better to "blit" entire graphics. This said, the C2P speed certainly did improve in 3.1.4 already, and if you have RTG graphics, the replacement function (for copying chunky pixels to a chunky frame buffer) is again much faster.

AmigaOS 3.0 APIs wouldn't deliver "Elf Mania" level quality on A500.

API has overheads on the CPU side.

AmigaOS 3.1.4 will consume 512 KB of RAM, hence it's a dead duck for stock A500 with 1 MB RAM i.e. leaving about 413608 bytes free via Install3.1.4 boot disk. KickStart ROM seems to be copied into RAM, making the available memory situation worse than KickStart 3.1. I don't generally don't use the shadow ROM speed-up methods when I had my A3000 (with 4MB Fast RAM, 2MB Chip RAM).

AmigaOS 3.1.4 needs at least 512KB Fast RAM to maximize Chip RAM availability.

Modern game consoles like PS5 and X1X have guaranteed memory for games i.e. 12.5 GB and 13.5 GB memory respectively from a 16 GB GDDR6 memory pool. PS5 has an additional 512 MB DDR4 memory for other OS-related workloads. OS reserve has its fixed memory allocation from the 16 GB GDDR6 memory pool.

Commodore didn't equip the baseline A1200 with enough memory that is contemporary with the PC's 4MB memory target for 1993/1994 era PC games and the 3DO/PS1/Saturn group has 3MB RAM and you're arguing for OS usage for action games?

Is "Shadow of the Beast" possible with AmigaOS 3.1's abstraction layer?

The Amiga is not Mac.

[hammer]

Originally Posted by AestheticDebris

Amiga games programmers weren't doing anything coders on other systems such as the PC, everyone just hit the hardware back in the day on order to get the most performance out of limited hardware.

Microsoft worked with those developers to produce a strategy that moved them away from hitting the hardware, it took many years and several missteps before getting to DirectX. Commodore might have done similar if they'd stuck around, they were clearly reluctant to document AGA mostly because they knew getting developers to use the OS instead was the way to go, they just didn't have a clear strategy on how that transition would work.

Windows 95/DirectX was released with rapid Pentium class and DirectDraw/Direct3D hardware evolution that switched the PC from hit-the-metal protected mode DOS games into an SGI OpenGL API-like environment i.e. MS's Direct3D.

The PC evolved into or assimilated SGI-like workstation with 3D acceleration, MIPS R4000 riving workstation-class CPU power via Pentium/Pentium Pro/Pentium II/Celeron, memory protection, multi-user, and SMP (multi-CPU) support.

The SGI Indigo workstation has a lot of compute power for its time.

The PC world targeted DEC Alpha and SGI as their R&D road maps.

[ Show youtube player ]
Running Quake and Doom inside a window on a Silicon Graphics Indy R4400 from July 1993 era hardware.

When WinQuake was released in Jan 1997, I have Pentium 166 class PC