undefined | Better HN

0 pointscmrdporcupine8mo ago0 comments

I was not a big Amiga user, but on the Atari ST we had a graphics abstraction API (VDI) from day one. Had the notion of a virtual device and drawing surface. All done through a proper syscall TRAP system, too. I am given to understand that the AmigaOS syscall API was in the form of JMPs.

So when the Falcon and TT Etc came along with full 16-bit 256 colour SVGA-like graphics, anything properly written GUI "just worked"

Games and the like, yes, had to fall back to a video compat mode.

0 comments

actionfromafar8mo ago

It used JMP, but you looked up the API base addresses from a fixed address, ($4 IIRC) so it worked basically the same. But only like some turned based games, and like some chess games etc used that API. The rest maybe used the APIs to allocate a screen but they were banging hardware after that. Most didn't even use the OS even to read the keyboard, which became an annoyance on the A600 which lacked some of the keys.

cmrdporcupineOP8mo ago

I mean the advantage of the TRAP approach is more amenable to supervisor/user mode switch and memory protection and the like?

Separate topic from graphics and device independence though

zozbot2348mo ago

The original Amiga platform had no MMU, hence no support for memory protection or virtual memory addressing. Some Motorola processors included it (the 68030 and up) but these were only used on high-end Amigas that were not the most common platform, and are more comparable to contemporary workstations. The AmigaOS just used the single address space approach, that's not necessarily incompatible with protected memory.

The Intel 80386 and its successors were quite exceptional in being "killer micros" with a workstation-class feature set for the time.

actionfromafar8mo ago

Memory protection was basically impossible or at least "Research Level Hard" on the Amiga, because of how the OS was designed with linked lists and message passing of pointers. This was what made it so fast, but at a cost. (They would have needed something like Rust to balance that.)

Everything could have been fixed with the March of Moore. The OS could have gotten a hypervisor and been running each program in its own "VM" thinking it was the only program on the machine.

2 more replies

zozbot2348mo ago

> So when the Falcon and TT Etc came along with full 16-bit 256 colour SVGA-like graphics, anything properly written GUI "just worked"

> Games and the like, yes, had to fall back to a video compat mode.

The Amiga had retargetable graphics too. No real difference there.

j / k navigate · click thread line to collapse

0 pointscmrdporcupine8mo ago0 comments

So when the Falcon and TT Etc came along with full 16-bit 256 colour SVGA-like graphics, anything properly written GUI "just worked"

Games and the like, yes, had to fall back to a video compat mode.

0 comments

actionfromafar8mo ago

cmrdporcupineOP8mo ago

I mean the advantage of the TRAP approach is more amenable to supervisor/user mode switch and memory protection and the like?

Separate topic from graphics and device independence though

zozbot2348mo ago

The Intel 80386 and its successors were quite exceptional in being "killer micros" with a workstation-class feature set for the time.

actionfromafar8mo ago

Everything could have been fixed with the March of Moore. The OS could have gotten a hypervisor and been running each program in its own "VM" thinking it was the only program on the machine.

2 more replies

zozbot2348mo ago

> So when the Falcon and TT Etc came along with full 16-bit 256 colour SVGA-like graphics, anything properly written GUI "just worked"

> Games and the like, yes, had to fall back to a video compat mode.

The Amiga had retargetable graphics too. No real difference there.

j / k navigate · click thread line to collapse