Was anyone else disappointed with the A1200?

[Thorham]

Originally Posted by Bruce Abbott

the Blizzard 1230 (you'll pry mine out of my cold dead hands)

Indeed

[grond]

Originally Posted by Bruce Abbott

Which wasn't anything to get upset about. 68k has a wonderful instruction set that makes programming in asm a joy. Those of us who had started out coding in asm from the early days appreciated that. RISC architectures like PPC and ARM are a pain, and x86 isn't great either.

Have you coded in ASM for PPC or ARM? I did quite a bit of ARM coding and found it very convenient for ASM programming. I actually think that, due to its orthogonality, ARM has some advantages over 68k. I never did any actual programming for PPC but learned PPC assembly and found it quite impressive as well. Nothing very reduced about it. Admittedly the mnemonics for PPC were very hard to memorise.

[Karlos]

The mnemonics for PPC are awful and so is the fact it enumerates bits the opposite way around. But it does have some nice features, like the ability to skip modifying flags for an instruction if you want to do some reordering but still depend on some outcome from an earlier operation.

[Dunny]

Originally Posted by Bruce Abbott

Blizzard 1230 was produced 30 years ago. I doubt the RPi will be around in 30 years time either (at least not as we know it).

Wait, are Phase V making new Blizzard 1230 cards? I didn't know that. Of course, if not then I suspect that the Pi4 will be about as available in 30 years as the 1230 is now.

[Thomas Richter]

Originally Posted by Karlos

...and so is the fact it enumerates bits the opposite way around.

Courtesy of IBM.

[Karlos]

Originally Posted by Thomas Richter

Courtesy of IBM.

I call this layout "bellendian"

[AestheticDebris]

Originally Posted by TCD

I don't frequent any other retro communities, so I am really curious how it is elsewhere.

All I know is that the Amiga 'community' has bickered about the right way to Amiga ever since the PPC showed up. Then there was OS4, the Vampire cards, and right now as seen in this thread PiStorm (I'm sure I missed a lot of other things).

I just think it would be much more pleasant and productive if people would just accept that there many different ways to use an 'Amiga'. You don't have to use all of them, but you don't have to shout 'this is wrong!' all the time either.

Honestly, it's probably much worse in many cases - particularly where the original machines weren't typically upgradable. You'll always get people who come up with hardware designs that add enormous amounts of RAM or ridiculous modern graphics capabilities to machines without the CPU power to utilise them and then bemoan anyone not interested in their designs. Likewise you'll see folks who'll militantly insist anything even vaguely different to a stock experience is committing some form of heresy.

From my experience, mostly in the 8 bit world, the kinds of hardware that is successful is that which offers minor quality of life improvements without materially changing the whole experience. So things like disk/tape emulators for faster or more reliable loading.

Whereas hardware that aims to far from the stock in terms of what the machines were capable of is always going to end up largely on the fringes - too much of the appeal of retro hardware is the limited capability of the machines. I can't say I'm surprised that, for many, turning an Amiga into something that tries to rival a modern PC generates a "So what?" type of response. It can be done, but it's never going to feel the way the old machine used to and that's mostly what people crave.

Now that doesn't mean people shouldn't do that if they want to, everyone should enjoy the machines in the way they prefer. I just think you probably have to accept that's always going to be the niche approach.

[Octopus66]

Originally Posted by karlos

i call this layout "bellendian"

lol

[hammer]

Originally Posted by Bruce Abbott

My A3000 used to do most stuff about as fast as the Pentium 75 PC I had.

Run AROS X86 for zero memory protection and single-user OS.

Originally Posted by Bruce Abbott

But for some reason Clickboom's Quake ran really slow on my machine. If I still had it today I would track down the cause, but I sold it around 2001 so...

[ Show youtube player ]
A4000TX, BFG9060 with 68060 rev 6 @ 100Mhz, CyberVision 64, Quake demo1 320x200p RTG result is 21.27 fps

From https://thandor.net/benchmark/33
Intel Pentium @ 75 Mhz has 20 fps.
AMD K5 (SSA5 core) PR100 @ 100Mhz has 20.40 fps
Cyrix 6x86 PR166 @ 133Mhz has 21.40 fps

AMD K5 PR166 (5k86 core) @ 116 Mhz has 24.40 fps
Intel Pentium @ 90 Mhz has 24.30 fps

Due to Quake, Cyrix had the worst IPC and was culled from the market.

Originally Posted by Bruce Abbott

I can believe that. Problem is after Apple went PPC they had no market for desktop 68k CPUs. If Commodore had still been alive it might have been different.

It wouldn't make any difference when Commodore's 68K model selection for >500,000 AGA unit mass production is mostly low-end. Big box A4000's numbers are in few thousand units production.

Commodore didn't have plans to mass produce 68040 class machines like Apple's. Without mass production of 68040 socket infrastructure, 68060 would also struggle on the Amiga platform.

Lew's compute boost for mass-produced low end AA+ Amiga models is via AT&T's $20 DSP3210.

Commodore's mass production of wedge-shaped Amigas acts closer to a game console with a desktop use case instead of a Mac.

Amiga is not a Mac.

Originally Posted by Bruce Abbott

Intel tried very hard to stop AMD from doing that. That's why they renamed the 586 to Pentium, because they couldn't trademark a number. But the PC market was big enough to allow (and encourage) that. The 68k market wasn't.

AMD didn't use "586" i.e. the closest is "Am5x86".

Originally Posted by Bruce Abbott

Which wasn't anything to get upset about. 68k has a wonderful instruction set that makes programming in asm a joy. Those of us who had started out coding in asm from the early days appreciated that. RISC architectures like PPC and ARM are a pain, and x86 isn't great either. Amiga OS had good support for asm coding too (at least before KS2). We didn't care if other CPUs were faster or had more features, it was the 68k's elegant ISA and ease of producing efficient code that attracted us to it.

Motorola Inc. has a rot from the inside and couldn't duplicate 68000's success.

68010 has the instruction set correction and should have priced out 68000.

The focus on assembly is due to the below-par C++ compilers for 68K.

Motorola doesn't respect full backward compatibility, hence many close source platform vendors like Sega (with 30 million install base for Mega Drive) effectively told Motorola to jump the lake. Commodore's Pentium-level machines would be powered by "big-endian" PA-RISC clones e.g. $40 Amiga Hombre. Commodore is on the "cheap RISC" camp. Again, Amiga is not a Mac.

https://segaretro.org/History_of_the...rn/Development
For Sega's Saturn, 68030 was in consideration and it was rejected for Hitachi's SuperH-2. Sega is in the "cheap RISC" camp and SuperH-2 is big-endian.

Sony and Nintendo selected MIPS R-series CPU family for their post 16-bit CPU selection. Sony and Nintendo are on the "cheap RISC" camp.

The original Amiga engineers-led 3DO (ARM60) didn't select Motorola and are in the "cheap RISC" camp.

On price vs performance, Motorola should have recognized it didn't have market dominance for their "full 32bit" 68K CPUs and still acted like Intel.


IBM tried to address "cheap RISC" with PowerPC 602 for 3DO M2, PowerPC 750CXe Gekko for GameCube, PPE for Xbox 360/PS3, and PowerPC A2 as the successor to PPE. AMD Jaguar defeated IBM PowerPC A2 for desktop game console contracts. ARM's Cortex A57 won a game console contract for a hybrid handheld/desktop for the Nintendo Switch.

Motorola started strong in the PDA market with the 68000-based Dragon Ball VZ series but they were pushed out by ARMv4T based CPUs e.g. PalmOS V dumped Dragon Ball VZ(scales to 66Mhz, crap IPC) for ARMv4T-based ARM925 (120 to 144 Mhz).

[Bruce Abbott]

Originally Posted by grond

Have you coded in ASM for PPC or ARM?

Not PPC, but I have done ARM on MCUs. Not a nice experience. Some of that could have been due to the platforms I was coding for, mostly STM32 where STMicro don't want you to code in asm, and their peripherals are hard to understand and the library code they provided was ridiculously convoluted and full of bugs. That combined with ARM peculiarities made it quite frustrating.

[grond]

Originally Posted by Bruce Abbott

Not PPC, but I have done ARM on MCUs. Not a nice experience. Some of that could have been due to the platforms I was coding for, mostly STM32 where STMicro don't want you to code in asm, and their peripherals are hard to understand and the library code they provided was ridiculously convoluted and full of bugs. That combined with ARM peculiarities made it quite frustrating.

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.

[Bruce Abbott]

Originally Posted by hammer

Run AROS X86 for zero memory protection and single-user OS.

Why?

[ Show youtube player ]
A4000TX, BFG9060 with 68060 rev 6 @ 100Mhz, CyberVision 64, Quake demo1 320x200p RTG result is 21.27 fps

From https://thandor.net/benchmark/33
Intel Pentium @ 75 Mhz has 20 fps.
AMD K5 (SSA5 core) PR100 @ 100Mhz has 20.40 fps
Cyrix 6x86 PR166 @ 133Mhz has 21.40 fps

It's starting to make sense now. Seems I had an 'optimistic' idea of how well Quake ran on contemporary PCs. If a Pentium 75 only got 20 fps then a 50MHz 060 should get ~13 fps.

According to a thread on Amiga.org, an 060 setup the same as mine should get 10-15 fps at 50MHz and 17-20 fps at 66MHz. I'm sure mine was slower than that though. It may be that I didn't have the best CPU and/or math libraries installed.

Due to Quake, Cyrix had the worst IPC and was culled from the market.

Yeah, Cyrix sucked. But apparently not as badly as I thought.

Commodore didn't have plans to mass produce 68040 class machines like Apple's.

Apple's plans didn't turn out that well either. The Quadra 605 was discontinued after only one year due to poor sales. The low cost Mac experiment was a failure.

Lew's compute boost for mass-produced low end AA+ Amiga models is via AT&T's $20 DSP3210.

Thankfully that didn't happen.

AMD didn't use "586" i.e. the closest is "Am5x86".

Another silly nitpick.

Intel was intending to use the numbers 586 on its latest CPU, just like they had used 386 and 486 on previous ones. Some early Pentium PCs were even marketed as being '586' machines. Then Intel sued AMD for putting '386' on their AM386 CPUs, and lost the court case because the judge deemed the number 386 as generic and therefore not trademarkable.

AMD was understandably very nervous about being sued a again, so they sensibly broke up the number to make it less able to be challenged. Meanwhile Intel came up with their own solution, which was to trademark the distinctly unique 'Pentium' name for current 586 and future CPUs.

Motorola Inc. has a rot from the inside and couldn't duplicate 68000's success.

Before accusing Motorola of 'rot' I suggest you try making your own 16/32 bit CPU from the ground up, using 1978 technology.

The focus on assembly is due to the below-par C++ compilers for 68K.

More lies.

The focus on asm stems from its use in earlier home computers, most of which used CPUs poorly suited to high level languages like C, and needed all the efficiency they could get. The 68000 was an outgrowth of the 6809, which was based on the 6800 but with a far more powerful instruction set. Unlike popular 8-bit CPUs like the 6502, Z80 and 8088, the 68000 has a 'mainframe' architecture that is a good match to C, but also good for asm coders who appreciate the orthogonal instruction set, large number of registers and flat memory model. Furthermore the Amiga was designed for asm coding from the start, partly because the exec kernel was written in asm.

C++ didn't exist when the focus on asm began on the Amiga. The A1000 was released in July 1985, while the first commercial C++ compiler was released in October 1985. But it didn't make its way to personal computers until much later (Microsoft released their first C++ compiler in 1992) and wasn't officially standardized until 1998.

Those of us who still code in asm today do it mostly because we are familiar with it and have built up a good collection of code over the years. It wouldn't matter to me if C++ were more or less efficient because I have no intention of using it. When I need to use C (mostly for porting from other platforms) I use SASC, which I am reasonably familiar with and provides the retro experience I desire.

Motorola doesn't respect full backward compatibility, hence many close source platform vendors like Sega (with 30 million install base for Mega Drive) effectively told Motorola to jump the lake.

The BS just keeps rolling in!

Console makers were always looking for ways to make them cheaper. Developing a customized CPU was a popular solution. Sega wanted to make the Saturn backwards compatible but in the end dropped this goal in favor of lower cost. While they may initially have been looking at using a 68030, this would not provide the performance they desired or a low enough price. It had nothing to do with "Motorola doesn't respect full backward compatibility".

Sega Saturn

In 1993, Sega and the Japanese electronics company Hitachi formed a joint venture to develop a new CPU for the Saturn, which resulted in the creation of the "SuperH RISC Engine" (or SH-2) later that year. The Saturn was designed around a dual-SH2 configuration. According to Kazuhiro Hamada, Sega's section chief for Saturn development during the system's conception, "the SH-2 was chosen for reasons of cost and efficiency. The chip has a calculation system similar to a DSP [digital signal processor], but we realized that a single CPU would not be enough to calculate a 3D world."

[Thomas Richter]

Originally Posted by Bruce Abbott

Furthermore the Amiga was designed for asm coding from the start, partly because the exec kernel was written in asm.

Not so. AmigaOs is really a mixture of assembler, C and BCPL, and depending on the module we talk about, it is more the one or the other. Exec is in assembler, yes, but that goes for every micro kernel. The next layer (AmigaDOS) was in BCPL, and that language was selected to be as portable as possible as AmigaDOS was just one incarnation of Tripos, the portable operating system. graphics is in assembler and C, and some of its interfaces still show the "stack based" C interface, such as the GELs collision system which is very much bound to what C compilers could do. Some stuff is in assembler, but most code was initially C and was then ported to assembler in v36 or so. Intuition is entirely in C, and uses even a different compiler than the rest of the kickstart.



MacOs was built similarly, except that the participating languages were assembler and Pascal. So there surely wasn't a particular language the Amiga was "designed for". It was "designed for whatever works to solve the problem".

[Thorham]

Originally Posted by Bruce Abbott

Furthermore the Amiga was designed for asm coding from the start

Computers are usually designed to run machine language. You can write software in whatever language, so long as it gets compiled to machine language.

But you know that, of course.

[Dunny]

Originally Posted by Bruce Abbott

Yeah, Cyrix sucked. But apparently not as badly as I thought.

My first PC was a Cyrix 166Mhz, which I upgraded to from an A1200+Blizzard 1230/IV + 4MB Fast, and was a straight swap. Probably around late 1998 as it was considered a low-end CPU at the time.

It ran Quake without any issues, Doom obviously and more - I spent a very happy year or so checking out DOS games like Terminal Velocity et al on it.

It soon started to show its age though, and it couldn't hold a candle to literally any pentium.

[Bruce Abbott]

Originally Posted by Thomas Richter

Not so. AmigaOs is really a mixture of assembler, C and BCPL, and depending on the module we talk about, it is more the one or the other.

So? I didn't say otherwise (why would I, when I have examined the OS source code many times?)

The important thing is not what language the OS is written in, but the interface. Amiga OS was designed to make access from asm easy, with parameters passed via registers rather than on the stack. Furthermore the include files had asm versions to make life easier for us.

Exec is in assembler, yes, but that goes for every micro kernel.

That may have been true when the Amiga was created (Wikipedia says it was one of the first platforms to have one), but so what?

Microsoft Windows was originally written in a mixture of C and asm, but used the Pascal calling convention where you had to push parameters onto the stack and clean up afterwards. Stack-based variables are a bit painful in asm, as well as producing generally slower code. Mac OS was mostly the same because it was almost entirely written in Pascal, except for some core OS functions that had parameters passed in registers.

But many game programmers eschewed the OS as much as possible. The Amiga Hardware Reference Manual was orientated towards asm programmers, with most of its example code being pure asm. This suited developers moving from other home computers that were generally programmed in asm with perhaps a minimum amount of BASIC to get it running, and which also had a bare minimum of useful OS functions.

some of its interfaces still show the "stack based" C interface, such as the GELs collision system

That explains why nobody uses gels.

Later additions bothered me more, like the tags that have to be generated with macros, and complicated callback mechanisms. But these are only minor speedbumps, nothing compared to the shenanigans involved when coding in x86 asm for Windows.

[Thomas Richter]

Originally Posted by Bruce Abbott

The important thing is not what language the OS is written in, but the interface. Amiga OS was designed to make access from asm easy, with parameters passed via registers rather than on the stack. Furthermore the include files had asm versions to make life easier for us.

I'm not sure what this is supposed to mean. The .fd files were there to automatically generate prototypes for the compiler vendors, or automatically create stub functions. AmigaOs started with exec which defined an interface, and (luckely) all other system components adopted this interface, with the exception of Tripos (or AmigaOs) which uses an inverse-stack based calling convention that is only hidden away by the (partial) interface the dos.library provides to Tripos.


In that sense, you could also argue that AmigaOs was very much designed to be programmed in BCPL because the BCPL interface via its GlobVec was richer and more powerful than the (cut down) interface the dos.library offered to non-BCPL system components.

Originally Posted by Bruce Abbott

But many game programmers eschewed the OS as much as possible.

Which demonstrates exactly what? That game programmers had no idea how to create software, possibly?

Originally Posted by Bruce Abbott

The Amiga Hardware Reference Manual was orientated towards asm programmers, with most of its example code being pure asm.

The RKRM Libraries and Devices volumes are oriented towards C programmers, with most of their examples being in C. Now what?

Originally Posted by Bruce Abbott

That explains why nobody uses gels.

Same issue with monitors and the VecInfo structure for monitor drivers... It is really a very mixed bag.

Originally Posted by Bruce Abbott

Later additions bothered me more, like the tags that have to be generated with macros, and complicated callback mechanisms. But these are only minor speedbumps, nothing compared to the shenanigans involved when coding in x86 asm for Windows.

Not sure why you need macros for tags, though they are handy, and Hooks are a very handy interface method as well as it allows "trampoline" functions for multiple calling conventions. Tags are probably one of the better inventions, allowing extensible interfaces - actually independent of the language.

[Bruce Abbott]

Originally Posted by Thorham

Computers are usually designed to run machine language.

Actually that's not quite true. In most cases the CPU executes machine code, but the instructions are designed for efficient execution of compiled code and are not well suited to writing hand-crafted asm, let alone bare machine code.

But that was not true of most early MPUs and MCUs (despite Microchip's claims to the contrary). One of the reasons few developers used C on 6502 and Z80 based home computers was the appallingly inefficient code produced compared to well crafted asm. This wasn't just because they didn't have good compilers back then. C is inherently 16-bit (at least) and an 8-bit CPU with few registers and few or no 16-bit operations and perhaps a tiny or even nonexistent stack was not a good match. A small memory addressing range with bank switching to access more was also very inefficient and difficult for compilers to handle.

[Bruce Abbott]

Originally Posted by Thomas Richter

In that sense, you could also argue that AmigaOs was very much designed to be programmed in BCPL because the BCPL interface via its GlobVec was richer and more powerful than the (cut down) interface the dos.library offered to non-BCPL system components.

The non-documented BCPL interface? We are talking about 'application' (aka game) developers here, not Commodore's system programmers. It's rather fortunate for us that DOS functions were given a 'standard' interface with asm calling conventions. Just have to watch out for those BPTRs.

But yes, if you were programming in BCPL it would be a big advantage to have a BCPL interface.

Which demonstrates exactly what? That game programmers had no idea how to create software, possibly?

Nope.

The Amiga was designed to be programmed 'bare metal' from the start. In fact during the first demonstrations (including the 'boing ball' demo) it didn't have an operating system. This was not unusual - the vast majority of home computer games only used what little OS the system had to start loading the game, then took over. The Amiga's multitasking OS got in the way of that, so many developers shut it down completely to avoid problems.

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. For example, would you recommend using gels instead of taking over the blitter etc. to get the best performance? Real game devs would laugh at that suggestion and say that you had no idea how to create software.

[lionagony]

Originally Posted by Gilbert

I do have a CD32 now, but it's not very impressive from a technical point of view, even the mighty Banshee is bettered on both the SNES and Megadrive.

In 7 years I don't think this has ever been addressed, what vertical shooter on the SNES looks and plays better than Banshee? For the Megadrive I don't think it's even worth asking. I can't think of a console game that had that level of detail besides maybe Metal Slug on the Neo Geo.