Although so much time has passed, direct hardware programming continues to be considered a bad programming practice that would have been best avoided even when, in the Amiga days, it was so often a necessity dictated by project goals. This is clearly a purely ideological and short-sighted position, which deserves to be investigated and, then, stigmatised.

English: https://www.appuntidigitali.it/23936/directly-programming-the-amiga-hardware-was-not-a-bad-practice/

Nonostante sia passato così tanto tempo, la programmazione diretta dell'hardware continua a essere considerata una cattivissima pratica di programmazione che sarebbe stato meglio evitare anche quando, ai tempi dell'Amiga, era tante volte una necessità dettata dagli obiettivi di progetto. Si tratta chiaramente di una posizione puramente ideologica e miope, che merita di essere approfondita e, poi, stigmatizzata.

Italian: https://www.appuntidigitali.it/23810/programmare-direttamente-lhardware-dellamiga-non-era-una-cattiva-pratica/

@cdimauro

Back in the 80s, sure, but certainly not something that should have been the practice later.


There is one feature I really like about the Windows ecosystem: compatibility (especially video games). I'm an avid gamer and many of my favourite games are from the late 1990s, most of them work well directly or via wrappers and other "dark magic".

@cdimauro

So, the right way to do this be a game engine, the engine is abstraction between the game and hardware. This is the way of doing it works on A500. If you replace the game engine, you get game work with newer hardware, then as gradually the hardware becomes faster, you introduce the system friendly game engine.

Games can be divided into categories, moving objects, and the map. The parallax, sound and audio, the game engine is the OS, for the game. This way the game is hardware agnostic.

Some of the best games run in ScumVM.

Last edited by NutsAboutAmiga on 13-Oct-2024 at 10:26 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@pavlor

Quote:

pavlor wrote: @cdimauro Back in the 80s, sure, but certainly not something that should have been the practice later. There is one feature I really like about the Windows ecosystem: compatibility (especially video games). I'm an avid gamer and many of my favourite games are from the late 1990s, most of them work well directly or via wrappers and other "dark magic".

Let's say starting from mid 90s. After that the OS should have been the only way to program videogames.

So, basically when 3D was then primary type of video games.

3D = variable frame rate -> you don't need to do the best to reach 60/50 or 30/25 FPS.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro So, the right way to do this be a game engine, the engine is abstraction between the game and hardware. This is the way of doing it works on A500.

And A1200 as well.
Quote:

If you replace the game engine, you get game work with newer hardware, then as gradually the hardware becomes faster, you introduce the system friendly game engine.

Exactly. Once you've a lot more resources and you're not so constrained like with the A500 and A1200, you can think about using the OS.

Plus, the 3D direction which games were taking, as explained before.
Quote:

Games can be divided into categories, moving objects, and the map. The parallax, sound and audio, the game engine is the OS, for the game.

Well, parallax with the OS... you need the resources for doing it.

On Fightin' Spirit I've experimented adding the parallex to the bottom 64 lines of the screen, entirely using the Blitter for drawing the graphics but the CPU had to do a lot of calculations as well, and it was very demanding.
Quote:

This way the game is hardware agnostic.

You don't need the OS, in reality: you need good gaming libraries, which not all OSes provide.
Quote:

Some of the best games run in ScumVM.

Which are... adventures. That you likely could handle with the OS also on A500 and A1200.

@cdimauro

Quote:

entirely using the Blitter for drawing the graphics but the CPU had to do a lot of calculations as well, and it was very demanding.

Not demanding on a fast CPU.

Amos Kittens can run most of the AMOS games and programs, it uses chunky. Not planar,

Even this works:

https://www.youtube.com/watch?v=K5dOTx_JIwA

Last edited by NutsAboutAmiga on 13-Oct-2024 at 02:43 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 10:54 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: entirely using the Blitter for drawing the graphics but the CPU had to do a lot of calculations as well, and it was very demanding. Not demanding on a fast CPU.

Which wasn't the option with the A500 or A1200.
Quote:

Amos Kittens can run most of AMOS games and programs, it uses chunky. Not planar, Even this works: https://www.youtube.com/watch?v=K5dOTx_JIwA

The frame rate isn't fluid, and the graphic is very poor.

I expect WAY MORE from an OS4 machine. That's even subpar of A500 games using parallax.

@cdimauro

The video is not on AmigaOS4, I expect UAE on windows or something...

Amos Kittens is fast, so I decided throw in lots artifact emulation on top of, for CRT scanlines etc.

LOL, not everyone like that.

In any case, your right games are made for a particular farme rate like 25 fps, or 30 fps, if the game runs at 60 fps, the game will run too fast.

It will be unplayable, Amos Kittens does suffer from this some places like “Castle AMOS�, its like when you play a snake game made for a 386 on Pentium 70Mhz.

Perhaps engines can be optimized more for speed, but the issue is the old games are too low resolution. It looks ugly no matter what. Of course, if I wanted to optimize graphics for speed their stuff that can be done to reduce the data transferee. Redrawing complete display is not efficient to display graphics.

Last edited by NutsAboutAmiga on 13-Oct-2024 at 02:42 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 01:05 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 01:04 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 01:03 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 12:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro The video is not on AmigaOS4, I expect UAE on windows or something...

OK
Quote:

Amos Kittens is fast, so I decided throw in lots artifact emulation on top of, for CRT scanlines etc. LOL, not everyone like that.

Their problem: reproducing the scanlines is cool.
Quote:

In any case, your right games are made for a particular farme rate like 25 fps, or 30 fps, if the game runs at 60 fps, the game will run too fast. It will be unplayable, Amos Kittens does suffer from this some places like “Castle AMOS�, its like when you play a snake game made for a 386 on Pentium 70Mhz.

That's why PyGame has a wait to set the FPS to be generated for the game & graphic, and it will always runs at that speed (of course, you need a system which allows to do it).
Quote:

Perhaps engines can be optimized more for speed, but the issue is the old games are too low resolution. It looks ugly no matter what.

Assets can be changed...
Quote:

Of course, if I wanted to optimize graphics for speed their stuff that can be done to reduce the data transferee. Redrawing complete display is not efficient to display graphics.

Unfortunately, this is the modern way to generate graphics.

It looks inefficient compared to the Amiga way, but there's another thing that we have to consider: we have WAY more powerful hardware, which can do much better than the past.

@cdimauro

who claimed other? at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time

@OlafS25

Quote:

OlafS25 wrote: @cdimauro who claimed other?

Several comments on the posts that I've created on some Amiga Facebook's pages for the previous article.

There was a post from one of those guys just a few days ago that has shown how to use the audio.device for playing sound and which used it as an ("obvious"!) example for heavily complaining against who used/use direct hardware programming.

Even here, many times, some people (mostly Hypex and NutsAboutAmiga, which are the more active) finger pointed this "bad coding practice".
Quote:

at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time

But Amiga wasn't a home computer.

@cdimauro

https://www.appuntidigitali.it/23936/directly-programming-the-amiga-hardware-was-not-a-bad-practice/ Quote:

This stratagem makes it possible to achieve a hybrid approach, in fact, partially exploiting the s.o. for the start-up and subsequent launch of the actual code. But it involves some complications (e.g. the first disc would have to serve only that purpose, perhaps loading only the game’s introduction and leaving the other discs in their proprietary format) and does not represent the method popular at the time, i.e. floppies of games or demos that started immediately once inserted in the drive.

It looks like "s.o." should be "OS" judging by the context but OS is used everywhere else in the article in the correct letter ordering and without the acronym periods. My understanding is that English capital letter acronym periods are usually optional and more commonly omitted today than in the past. The acronym should be clear as to what it refers to and consistent use of periods looks better. What is the "s.o."? Perhaps this is some kind of language translation error?

OlafS25 Quote:

who claimed other? at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time

Most home/PC computers at the time barely had an OS. The CBM Pet, Apple II, CBM C64, Atari 400/800, etc. used ROM code from Basic as the OS with most of the memory used for user code. CP/M, MS-DOS, Mac OS, Sinclair QDOS and AmigaOS were more prototypical, dynamic and advanced OSs. Some of the expanding OS no longer fit in ROM and used valuable memory. The primary hardware resources you refer to are likely memory and CPU performance. The AmigaOS was removed too often when just considering the resources, especially with developer time considered where it was easier to retain the AmigaOS. The AmigaOS provided standard, easy to use and future proof hardware configuration and disk functions.

Memory constraints alone rarely justified removing the AmigaOS. The standard Amiga configurations had a low amount of memory and better code optimization and code density improvements could have improved the situation but the Amiga had options including large and fast standard floppy disk storage that exceeded the competition on the Amiga launch and for several years. This allowed dynamic loading and streaming of code and data. The Amiga dynamic libraries used this advantage as well as underutilized hunk overlays.

https://eab.abime.net/showpost.php?p=1665032&postcount=20 Quote:

The overlay feature fell out of favour when Amigas either shipped with more than 512 KBytes of memory, or could be expanded by adding memory plug-in cards (or something like the A590 for the Amiga 500). That was around 1988/1989, if memory (ha!) serves. The feature itself required preplanning, if you followed the original overlay management design (e.g. Lattice 'C' versions 3 & 4 and SAS/C versions 5 & 6). The documentation which covered how you made it work was decent enough, especially for SAS/C. You had to know in advance which portions of your program could be in memory at a time. Not every program could be conveniently broken down into such units, though. Manx Aztec 'C' did away with the minute preparations for keeping an exact subset of a program in memory, by virtue of its custom overlay manager. You could break down the program into units at the linker stage and then later load/unload portions of it as required. This was the method preferred by the industry by 1989/1990. But, as I mentioned, the constraints which required overlay support eventually went away as RAM became cheaper and Amigas became faster with each new iteration of the platform.

https://aminet.net/package/docs/misc/Overlay

There were a few Amiga programs which used hunk overlays including DPaint, EOB2 and Bane of the Cosmic Forge. Lack of documentation, early bugs and memory fragmentation may have been limiting factors. Virtual memory eventually became the standard for advanced OSs although a MMU is required and there are similar disadvantages. The memory limitation shifts to a performance limitation.

Performance limitations were the primary limiting factor for the Amiga. Early limitations were likely lack of documentation and Amiga experience by the developers as the Amiga was ahead of the competition but as Amiga was improving and the user base was expanding faster with the Amiga 500, the competition hardware was catching up and passed the Amiga which was standing still. Developers now understood the Amiga but had to resort to more and more extreme tricks to keep up. Granted, the Amiga had become cheaper than the competition as the next generation C64 that CBM wanted but more expensive competition hardware was exceeding the Amiga already in the late 1980s. CBM finally came out with a 68EC020+AGA@14MHz standard but it was too little too late.

Optimizing the AmigaOS would have improved both performance and reduced memory which would have allowed more games to keep the AmigaOS. However, the Amiga lack of performance competitiveness starting in the late 1980s due to failing to adequately and quickly upgrade the Amiga hardware would have still resulted in Amiga failure. More games using the AmigaOS would have made for an easier upgrade path. Fortunately, WHDLoad, patch programmers and the very easy to use and advanced 68k CPU and chipset saved the day for the 68k Amiga and allow it to move forward with compatibility. The large flat address space of the 68000 Amiga means WHDLoad games are less of a compatibility problem than 8/16 bit 808x/x86 games with Real mode, Unreal mode, System Management Mode, Protected mode, Virtual 8086 mode, Long mode and memory extensions like XMS, SXMS, EMS, EEMS, XMA, UMA, AWE, GEMMIS, etc. PC CGA/EGA/VGA/VESA support is likely not much different than OCS/ECS/AGA support. Amiga "NG" folks thought they could move forward while replacing the 68k Amiga and removing compatibility but compatibility is what allowed the 808x/x86 PC with much more baggage than the Amiga to become what it is today. Even though the 68k Amiga path forward has never been clearer, they persist perpetually actually impeding real attempts to revive the 68k Amiga.

There may have been other reasons to remove the AmigaOS. NDOS disks may have reduced piracy by making the disks more difficult to copy. Some programmers may have been following the trend because they saw more professional programmers remove the OS which some may have needed to do to push the hardware to the very limits. Programmers would turn off multitasking to save a couple of percent of CPU performance due to preemptive interrupts when there is no higher task/process ready to execute. It may have been possible to avoid this interrupt with better integrated hardware rather than using commodity CIA chips. RTOS embedded programmers want similar features that reduce system overhead to a minimum and allow to take over resources without removing the OS. The AmigaOS had some of those features. The AmigaOS is very thin/slim and modular, code sharing is excellent greatly reducing memory requirements, dynamic libraries are efficient, resources can be exclusively allocated and task switching overhead is RTOS like.

https://kgsvr.net/andrew/amiga/amiga.diffnt.html Quote:

AmigaOS is Efficient From: Shireman, Steve I have run control software on the Amiga booting off of a battery-backed SRAM PCMCIA card without a hard drive or floppy using only 4K of the PCMCIA card to boot. Think of the PCMCIA card as replacing the hard drive in a desktop system. The only RAM overhead was about 54K, and with this I have the full color model and mouse control, and fully preemptive multitasking and of the 2 Meg of RAM that comes with the A1200, The Amiga OS has only needed less than 1 / 10,000 of the RAM available. And I know it is using a few of the OO Objects in the Kickstart, but not very many. ... Fast Task Switching michael schulz wrote: A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): o 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 o 71 uS for 100MHz Pentium Linux 1.2.13 o 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 o 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 o 106 uS for 66MHz Snake HP-UX 9.x o 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 o 128 uS for 40MHz Viking SunOS 4.1.3 o 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 o 210 uS for 33MHz 486 386BSD 0.1 o 212 uS for 50MHz RIOS AIX 3.2

Other AmigaOS advantages are mentioned in the document linked above with many being RTOS features. The AmigaOS is good in this regard but it could have been better with better compilers and assembler optimizations where worthwhile and better hardware support (the AmigaOS may have been avoided in some cases due to limited/immature APIs). Programmers deserve some of the blame for jettisoning the AmigaOS too quickly. CBM deserves some of the blame for not upgrading to better hardware standards faster. More modern PPC AmigaOS and emulation of the 68k and chipset moved vastly away from these advantages trying to turn the AmigaOS into a desktop behemoth. The 68k hardware and chipset are an important part of the elegance of the Amiga no matter the level of abstraction used.

Last edited by matthey on 15-Oct-2024 at 01:15 PM.
Last edited by matthey on 15-Oct-2024 at 12:53 AM.
Last edited by matthey on 14-Oct-2024 at 11:57 PM.
Last edited by matthey on 14-Oct-2024 at 09:16 PM.