What spec would the A1200 had launched with if it was up to YOU

[Bruce Abbott]

Originally Posted by Gorf

A software abstraction layer is something, that needs to be affordable in terms of speed and at the same time have a good level of completeness in terms of features. Graphics library on AA was largely considered to lack both by game developers. So the only thing Commodore achieved by holding back documentation, was slowing down development and hurt the platform.

It wasn't just that graphics library was inadequate, many developers preferred to take over the machine so they didn't have to consider the OS at all. That meant they had to be intimately familiar with the hardware and have the correct code to work on all variations - which many did not do. Instead they just got it working on a stock A500 and if you had a different model that didn't work too bad. AGA was a good time to start weaning developers off that practice.

Another reason not to give out hardware information was that Commodore themselves didn't know exactly how it would turn out until final production. It would be foolish to publish detailed specs only to have to change them later. The OS hides a number of peculiarities of AGA (and earlier) chipsets that are a pain to deal with, so why not let it do the work for you?

Developers should have welcomed being able to just eg. open a screen without having to handle all the niggly details. But many didn't because they were stuck back in the days of 8 bitters that had no OS to speak of and required banging the metal for everything. They had painstakingly developed code for doing that on the Amiga, and would rather add to it than use an OS they had less control over and would have to 'play nice' with.

But that didn't apply to all developers. I don't mind giving up the freedom to do anything I feel like with the hardware in exchange for keeping very useful features of the OS. You can still bang the metal by telling the OS what resources you want exclusive access to. It just takes a different mindset to work with the OS instead of kicking it out and doing everything yourself.

If you must have the best possible technical operation in an action game then banging the metal might be the only way. But some excellent games have been produced for the Amiga that are totally system friendly. OS3 added a number of functions which make it easier to do game stuff, including double-buffering, attached screens and extended sprite control.

Well - so we are back now to the rather meager speed of an 14MHz 68020 with ChipRAM-only in the 1200. There the speed is clearly not enough for such an abstraction. At least not for games.

Depends on what sort of abstraction you are talking about. If you can blit images, move sprites around etc. without having to write to hardware registers then it's abstracted. Unless you really need every last CPU cycle the OS functions are generally fast enough.

I am not saying Commodore should not have delivered a sensible RTG system on its own and supported gfx-cards on big box amigas, but a low end machine as the A1200 (or the CD32) was still relying on direct hardware access to be competitive speedwise.

Was it though, or was it more that developers just never tried doing it through the OS? Don't forget that the A1200's ROM is full speed with no wait states. A lot of the OS was 'down-coded' into asm and optimized too, making it much faster than earlier systems. You can do a lot with system-friendly code!

[grond]

On the aspect of OS-friendly games programming: ironically the OS becomes more adequate for games-programming the more PC-gaming-like the game becomes. If you just need a framebuffer (FPV-shooters and the like), you can easily set it up through the OS and then let the user decide which c2p-engine to use, direct-render, quickcopy, WriteChunkyPixelArray(), custom c2p, blitter-assisted c2p, whatever. If you want to program a strategy program or adventure, even less of a problem to do it through the OS. The stuff that is difficult to impossible to achieve through the OS are fast-paced 2D games, i.e. classic Amiga and by 1992 increasingly outdated material. If you are really worried about some CPU cycles lost to the OS, you can define a tooltype with the games icon that allows the user to turn off multitasking. Your code then simply checks for the tooltype and calls Forbid() if set. I have done all this through the OS coding in assembly language and didn't see any penalty at all. It's just a slightly different skillset to do the same stuff through the OS.

[pandy71]

Originally Posted by grond

On the aspect of OS-friendly games programming: ironically the OS becomes more adequate for games-programming the more PC-gaming-like the game becomes.
(...)
If you are really worried about some CPU cycles lost to the OS, you can define a tooltype with the games icon that allows the user to turn off multitasking. Your code then simply checks for the tooltype and calls Forbid() if set. I have done all this through the OS coding in assembly language and didn't see any penalty at all. It's just a slightly different skillset to do the same stuff through the OS.

Well, obviously it was not so easy - i recall discussion with Meynaf about how impossible is/was to provide MIDI smooth operation by turning off multitasking or even by creating some form of primitive Real Time OS on top of Amiga OS. Eventually this lead to conclusion that Amiga is inappropriate to deal with MIDI (possibility to loose MIDI message at the Rx from other MIDI sources). So we talking about perfect situation where using OS is impossible to provide satisfactory results not for demanding graphics but application. Of course this could be workaround or by HW or by SW but finally Amiga never get attention from companies like Steinberg even if adding MIDI to Amiga serial port was inexpensive and can be standard part of software package.

[grond]

Originally Posted by pandy71

Well, obviously it was not so easy - i recall discussion with Meynaf about how impossible is/was to provide MIDI smooth operation by turning off multitasking or even by creating some form of primitive Real Time OS on top of Amiga OS. Eventually this lead to conclusion that Amiga is inappropriate to deal with MIDI (possibility to loose MIDI message at the Rx from other MIDI sources). So we talking about perfect situation where using OS is impossible to provide satisfactory results not for demanding graphics but application. Of course this could be workaround or by HW or by SW but finally Amiga never get attention from companies like Steinberg even if adding MIDI to Amiga serial port was inexpensive and can be standard part of software package.

In my opinion MIDI has very little to do with games on the Amiga. The Amiga has a working sound subsystem that should have been enhanced with AGA but certainly not by using anything like MIDI.

IIRC the MIDI problem on the Amiga comes from the fact that the order of IRQs is "wrong" for MIDI timing and the serial port isn't buffered. I'm not even sure this would really affect a game using a MIDI sequencer for audio. It's not like you are really paying attention to the timing of notes when playing a game.

[pandy71]

Originally Posted by grond

In my opinion MIDI has very little to do with games on the Amiga. The Amiga has a working sound subsystem that should have been enhanced with AGA but certainly not by using anything like MIDI.

IIRC the MIDI problem on the Amiga comes from the fact that the order of IRQs is "wrong" for MIDI timing and the serial port isn't buffered. I'm not even sure this would really affect a game using a MIDI sequencer for audio. It's not like you are really paying attention to the timing of notes when playing a game.

MIDI used by applications is not different than games - this is about reacting for real time events and problem is not about timing of notes but possibility to loose note (games using MIDI should be not effected as this is issue with response to incoming MIDI events).

MIDI is illustration of problem where OS layer is unable to provide functionality - worse - OS itself can be a problem.
So if OS layer is unable to provide expected functionality then OS must be substituted by direct HW banging.
Of course you can modify HW to hide OS issues but still at some point if you go for solutions like those in 16550 and other modern UART's some OS may not work for you.

[AestheticDebris]

Originally Posted by pandy71

MIDI is illustration of problem where OS layer is unable to provide functionality - worse - OS itself can be a problem.
So if OS layer is unable to provide expected functionality then OS must be substituted by direct HW banging.

But the issue with MIDI on the Amiga is basically a hardware issue, no amount of bit-banging can really solve it. I don't think you can really class that as a deficiency of the OS design.

[pandy71]

Originally Posted by AestheticDebris

But the issue with MIDI on the Amiga is basically a hardware issue, no amount of bit-banging can really solve it. I don't think you can really class that as a deficiency of the OS design.

I would never say that this is HW issue (UART interrupt level is 5 so quite high) and of course you can perform pooling so no problem and working MIDI.
And every multitasking OS suffer same problem with real time events so yes, Amiga OS is not the isolated problem, it is common with every multitasking OS unless you do RTOS. Atari ST is not multitasking OS and it is quite responsive so able to deal with real time events better.

But once again - MIDI was example that at some point software layer can't provide desired functionality and you are forced to do bit banging.

[grond]

Originally Posted by pandy71

But once again - MIDI was example that at some point software layer can't provide desired functionality and you are forced to do bit banging.

Yes, and fast-paced 2D games are a (more relevant) example for the Amiga and OS-abstraction in the beginning 1990s. With faster processors most of these problems become less of a problem. And, as I pointed out, for the more PC-type games (FPV, strategy and adventure games) OS-abstraction on the Amiga is in fact less of a problem.

[pandy71]

Or perhaps i was wrong and Amiga HW with OS will not prevent possibility to deal with external event with relatively high time accuracy - digged a bit yesterday and i've found interesting paper: "Amiga 1000 hardware timing and reaction-time key interfacing"

[Bruce Abbott]

Originally Posted by grond

The stuff that is difficult to impossible to achieve through the OS are fast-paced 2D games, i.e. classic Amiga and by 1992 increasingly outdated material.

That depends on the platform. The most popular genres were largely self-selected by the hardware. In 1992 the best selling 'home video games were Sonic the Hedgehog 2 on the Mega Drive (~2 million sold in the US and another 2 million in Europe), Street Fighter 2 on the SNES (with similar sales numbers), and The Legend of Zelda: A Link to the Past also on the SNES (~1 million sold in the US).

According this chart of commercial game sales, in 1992 'fighting' games pushed out 'action' games, but 'platform' games were still popular. These genres required 'fast paced' 2D graphics.



But this was not so on the PC, for the simple reason that it wasn't well suited to fast-paced 2D graphics. Another reason was that PCs were much more expensive and so more used by adults who had different tastes. This explains why 'role playing' games appeared in the early 80's, and why 'strategy' games became popular in the early 90's.

The Amiga sat in the middle, with good 2D graphics for fighting and platform games, as well the extra stuff needed for strategy, simulation and adventure games (keyboard, mouse etc.) while being affordable enough to attract a wider audience. It wasn't until the late 90's that 3D games became dominant, as a result of hardware that was suited to them.

Being suitable for a wide variety of genres meant that many games could be produced that didn't have to kick out the OS to get acceptable performance. But many did anyway because developers were familiar with that programming model.

If you are really worried about some CPU cycles lost to the OS, you can define a tooltype with the games icon that allows the user to turn off multitasking. Your code then simply checks for the tooltype and calls Forbid() if set. I have done all this through the OS coding in assembly language and didn't see any penalty at all. It's just a slightly different skillset to do the same stuff through the OS.

Exactly. Commodore even provided tips on how to make games run smoother with the OS active. But many developers eschewed this because the OS was an unknown quantity that got in the way of their desire to max out the hardware. This was understandable on a 512k A500, but less so on the A1200 which had plenty of memory and CPU power to spare. I can understand why they chose to stick with the old ways they were familiar with, but it held back progress at a time when the Amiga could least afford it.

When the CD32 came out it became obvious that things would have to change. You couldn't just load the whole game into RAM and kick out the OS if you wanted CD audio and/or loading stuff on demand. That they tried to do it anyway just shows how entrenched the old ways were.

An interview with Rob Northen

I remember when the CD32 was first launched and most Amiga games up to that point had been using their own disk routines or mine for loading. The CD32 was different and required the developers to change their ways and use the OS to load their games. Up to then they would invariably ditch the OS and hit the hardware directly. I decided to write loader routines for the CD32 and contacted Commodore in the UK and US. They refused to help in any way, so I hacked the OS and wrote my own.

Typical. Imagine that attitude today!

[grond]

Originally Posted by Bruce Abbott

That depends on the platform. The most popular genres were largely self-selected by the hardware. In 1992 the best selling 'home video games were Sonic the Hedgehog 2 on the Mega Drive (~2 million sold in the US and another 2 million in Europe), Street Fighter 2 on the SNES (with similar sales numbers), and The Legend of Zelda: A Link to the Past also on the SNES (~1 million sold in the US).

Yes, I ignored consoles here because of the segmentation of videogames into 2D//console on the one hand and 3D/role-playing/strategy/adventure//PC on the other and my statement that OS-programming was less negatively affecting when dealing with the latter type of games. After all the most common point of view on this whole period is that the Amiga should have been set up to compete with PCs. A requirement to access the hardware through the OS would not have been an obstacle for this in my opinion.

Typical. Imagine that attitude today!

The attitude remains very much the same today when it comes to Amiga programming. I think Amiga c0d3rs often pride themselves of killing the OS but many of them wouldn't know how to do the same thing through the OS.

Back in the day the absolute necessity to maintain hardware-level compatibility unless one wanted to throw away a large portion of the Amiga software pool was another nail in the coffin of the Amiga. Admittedly it was hard to escape from this situation lacking an economically healthy software market for Amiga software.

[PortuguesePilot]

Originally Posted by grond

(...) The attitude remains very much the same today when it comes to Amiga programming. I think Amiga c0d3rs often pride themselves of killing the OS but many of them wouldn't know how to do the same thing through the OS.

Back in the day the absolute necessity to maintain hardware-level compatibility unless one wanted to throw away a large portion of the Amiga software pool was another nail in the coffin of the Amiga. Admittedly it was hard to escape from this situation lacking an economically healthy software market for Amiga software.

Yes. As I said somewhere above, it was a matter of pride indeed. I remember that some 'scene coders' even bragged about writing some demos in pure machine code (i.e., code that runs as-is on the hardware and needs no compiler or interpreter thus being even more low-level than Assembler). Although I have some SERIOUS doubts about those claims, it serves to show just how "l33t" banging the metal was considered because it conveyed the idea that the programmer was very well-versed on that specific hardware, intimately knowing all the instruction sets, all the byte codes, the interrupts, all the CPU opcodes, etc. It was viewed much in the same way as we consider a piano virtuoso, or an expert guitarist, or a prodigious painter. It was as if the coder was 'an artiste'. This mentality going all the way back to the first generation computers, all the way back to 1940s and being very reinforced during the 'hobbyist' period of the late 70's.

When it finally became clear that an abstraction layer was indeed beneficial for post-program compatibility reasons, most of these 'l33t' programmers took some time to "change their chip", which is why I said that "people evolve slower than hardware", and this was particularly true in that specific period of time (the mid 90's). Heck I even had issues with my own programs when I transitioned from Pascal to C back in those days and the need to adjust code to the compilers and finally needing things like digital libraries, this on high-level coding on the PC. So, in the specific case of the Amiga (but also of many other contemporary machines), the abstraction layer - or working through the OS - was not seen as a good thing but as a hindrance, since it significantly raised the needed specs for any intended performance. And in those days and age, when specs were feeble and scarce, every extra bit of speed was sacred and any means of getting it were respected. This meant that going around the OS or killing it altogether was seen as the right way of extracting every bit of speed that was possible, simultaneously lowering the memory and CPU requirements to as little as possible. Only when computers got some extra specs (486 and up and 2MB RAM or more, etc. Oh, what a surprise...) did the abstraction layer suddenly felt like the right idea.