Quote:
Originally Posted by bwinkel67
Oh, I see. Not sure it would be easy to differentiate between taking over the whole screen or circumventing the OS.
|
For the Mac, there is not much hardware to take over, and there is only one screen that sits at a predefined place. (Actually, two for the early Macs, one being reserved for MacsBugs, the system debugger).
For the Amiga, it is quite different. Drawing graphics on the screen is driven by the blitter through the graphics library. The mac didn't have dedicated hardware for that, but the closest equivalent MacOs had was "Quickdraw", the graphics manager of the Os. Bypassing the Os is similar to poking to the screen memory directly on the Mac, with the consequences that window boundaries are not respected.
Quote:
Originally Posted by bwinkel67
Games that took over the whole screen may have needed an escape key to get out (MacOS didn't have an Amiga-M key).
|
CBM-M is not the "screen overriding terminate" key either. The Amiga has just multiple hardware layers (as many as memory allows) on which programs can draw, not just the one (or two) Mac hardware. CBM does not stop programs from drawing onto any screen - not at all. It just loads the display hardware with the address of the next screen to be shown. Programs operate independently of each other - or on the workbench, on their decision.
Quote:
Originally Posted by bwinkel67
But you wouldn't even need to take the whole screen as it's pretty easy to circumvent the MacOS: just don't make the system call GetNextEvent/WaitNextEvent in your code which would keep everyone else away since you are now not cooperating and the kernel is just sitting there hoping you release control.
|
Precisely, but when a program would not use quickdraw to render its graphics, but would poke into screen memory directly, that would also corrupt graphics of other programs. That wasn't the norm on Mac. Applications were pretty much well-behaived.
Quote:
Originally Posted by bwinkel67
My first program on the Mac was a command shell and scripting language and I developed in on the QL which has a preemptive kernel. When I ported it over and compiled it on my Mac and ran a script written in its environment, the entire Mac GUI interface stopped responding because I never released control while the script ran. I had to do some work to get it to multitask (stick in WaitNextEvent calls at various places in the interpreter).
|
I recall that MacOs also had a trap for "Idle" you could call once in a while to allow other applications to regain control.