Choice window manager for ICE

[bwinkel67]

Does anyone have the Choice software that comes with ICE? I have it on microcartridge of it but need no re-felt and then try to copy the software off of it. Presently I don't have my vDrive so I'd have to copy it to another microcartridge . Would be easier if someone had a ZIP of it. I own ICE as I bought it back in '91 and can show a picture of the manual if that helps.

[Tesla]

Can it help?

Best regards
Marco

[bwinkel67]

Can it help?

Best regards
Marco

Thank you Marco. That seems to be the Choice code on the Choice MDF. I'm actually trying to recover the entire MDV:

Code: Select all

BOOT
BOOT2
CHOICE_CDE
CLICK_HLP
CLONE_BAS
COLOUR_BAS
CUSTOM_HLP
DBASE
DCLICK
EXTEN1
EXTEN2
FORMAT_HLP
INFO_HLP
MERGE
RAMBO
RAM_RD_BIN
RENAME_HLP
SYSTEM_HLP
TASKGEN
VIEW_HLP

[dilwyn]

PM sent.

[bwinkel67]

So Choice works pretty well. I was able to get it to work on an unexpanded QL...with one caveat, I couldn't quite use the 32K screen buffer for one program as the other didn't have enough memory left...both were pretty small to begin with. The two modes it offers are either a key-combo that the program running concurrently supports for a screen refresh, or a 32K buffer if not. Either works because the Choice will suspend any background programs and remove it visually from the display, removing any possibility of screen corruption by a background task.

If I recall correctly, the Mac OS didn't actually do screen buffering. I think there was a screen refresh event that was sent out when a program was brought back to the foreground and you could also use the idle event to keep the windows up-to-date. When MultiFinder was added in the late 80's, though it still did that, programs could run in the background but wouldn't overwrite foreground windows. I don't recall how that was done, but it happened at the OS level, not application level. I think the OS kept screen areas of windows and would calculate if a window was partly covered and I suppose any output to the screen was masked out for a covered window.

In the Pointer Environment, how does it handle screen refresh for each window? Does it keep a buffer around for each or force the program to refresh its screen when put in the foreground. How does it handle concurrently running programs with one on top of the other? It must take care of the window drawing so it can avoid one program from outputting its content over another like a normal QL does.

[tofro]

If I recall correctly, the Mac OS didn't actually do screen buffering. I think there was a screen refresh event that was sent out when a program was brought back to the foreground and you could also use the idle event to keep the windows up-to-date. When MultiFinder was added in the late 80's, though it still did that, programs could run in the background but wouldn't overwrite foreground windows.

On the Mac (or on most classical window systems), the windowing system just tells the application what of its window areas were just invalidated and need a redraw. Then its the task of the application to "fix the damage".

In the Pointer Environment, how does it handle screen refresh for each window? Does it keep a buffer around for each or force the program to refresh its screen when put in the foreground. How does it handle concurrently running programs with one on top of the other? It must take care of the window drawing so it can avoid one program from outputting its content over another like a normal QL does.

PE is different in this respect from other window systems: Here it's the task of the window manager to store the contents of a job's window before it is buried by another window. You tell the window manager what window area to watch and save by setting the Outline whenn you're opening your initial program window.
When the window manager puts something else on top, it first saves the primary window area of the buried job, then draws the new screen contents on top. When a window is partially or fully un-buried, the window manager will restore the original contents. This obviously has (rather: had) the downside that the buried job can no longer output anything to the screen (because its screen is currently living fully or partially in a save buffer). Early versions of the window manager thus suspended background jobs and any jobs with fully or partially buried windows, so effectively suspending multitasking. Later enhancements today allow background updates: Modern versions of the extended environment let applications transparently continue, even if they have buried screen areas, and redirect their screen output into the saved buffers instead of directly to the screen.

Even if this concept is absolute luxury for the application programmer (no need to do redraw yourselves), there is the (small, in my opinion) downside that, because there is only one save buffer per job, sub-windows are restricted to the area of the primary window and can't live everywhere on the screen.

[bwinkel67]

PE is different in this respect from other window systems: Here it's the task of the window manager to store the contents of a job's window before it is buried by another window. You tell the window manager what window area to watch and save by setting the Outline when you're opening your initial program window.
When the window manager puts something else on top, it first saves the primary window area of the buried job, then draws the new screen contents on top. When a window is partially or fully un-buried, the window manager will restore the original contents. This obviously has (rather: had) the downside that the buried job can no longer output anything to the screen (because its screen is currently living fully or partially in a save buffer). Early versions of the window manager thus suspended background jobs and any jobs with fully or partially buried windows, so effectively suspending multitasking. Later enhancements today allow background updates: Modern versions of the extended environment let applications transparently continue, even if they have buried screen areas, and redirect their screen output into the saved buffers instead of directly to the screen.

Even if this concept is absolute luxury for the application programmer (no need to do redraw yourselves), there is the (small, in my opinion) downside that, because there is only one save buffer per job, sub-windows are restricted to the area of the primary window and can't live everywhere on the screen.

Thanks for the detailed breakdown. So other than hiding paused programs, it looks like Choice did the same thing that PE did in earlier versions, though it didn't put it in a movable window and just takes up the entire screen, thus taking up 32K of memory for each task that didn't do its own refresh...I guess that's not too big a penalty if you had an extra 512K of memory.

[stevepoole]

Hi Bwinkel,

I seem to recall that on at least one early QL program, Windows would be swapped via Microcassete storage... a very sluggish method indeed !

With the added disadvantage that in the case of a (frequent in those days) power glitch, you would lose the entire screen...

For example Turbo would run on 128ko, but only just, by unloading parts of its working memory onto microcartridge too....

In any case you needed a fresh tape, as they could only hold just three screens at best, so it was easy to lose vital data if there were no spare cartridges left....

After spending an entire day entering my wife and daughter's portrait into Talent's GraphiQL using cursor keys... A power surge zapped the lot forever during a SAVE !

So I am not particularly nostalgic about 1984 screen buffering ! Steve.
______________________________________________

[bwinkel67]

I seem to recall that on at least one early QL program, Windows would be swapped via Microcassete storage... a very sluggish method indeed ! With the added disadvantage that in the case of a (frequent in those days) power glitch, you would lose the entire screen. For example Turbo would run on 128ko, but only just, by unloading parts of its working memory onto microcartridge too. In any case you needed a fresh tape, as they could only hold just three screens at best, so it was easy to lose vital data if there were no spare cartridges left. After spending an entire day entering my wife and daughter's portrait into Talent's GraphiQL using cursor keys... A power surge zapped the lot forever during a SAVE !

So I am not particularly nostalgic about 1984 screen buffering ! Steve.

That, IMHO, is just terrible software design. The thing I like about many QL products is that they understood the shortcomings of the default media (i.e. microdrives) and spent considerably efforts to work around them. Even the original QDOS implements dynamic file caching similar to what you find on a modern OS, whereas systems like the Mac or Amiga just used a simple static file cache i.e. you specified a small amount of memory and that was it, while the QL could use the entirety of its available 84K when reading files...I think those systems felt that hitting the floppy more frequently wasn't all that bad. One nice thing about ICE is that it's completely memory (ROM with a little RAM) based and doesn't hit the media (microdrives) up for any GUI element.

It sounds like Turbo was trying to do it's own virtual memory handling, and though admirable, not a good idea with a tape-based system. That generally only works on hard drive systems that are fast enough to make it usable. It doesn't sound like Talent's GraphicQL was doing anything weird with caching to microdrive, just that it took a long time for you to draw the image and while saving, you hit an unfortunate power outage.

I would be interested in investigating the technique Turbo used (even if a bad idea). Which product are you specifically referring to?

[tofro]

Turbo has never done anything like that. It was Supercharge (its predecessor) that used screen memory as scratch space on unexpanded machines. You could watch SC compile your program into screen memory in various passes, once the program was compiled, it was slowly piped from screen to drive, and the screen was cleared. And that was fine, IMHO, as long as it cleaned up properly after messing with the screen, which it did.

The only programs I recall that actually "swapped" to microdrives was Quill. But it didn't swap the screen, but rather the text you entered (into darn def_tmp files). Which still meant you lost your text when something bad happened on the drives or even only when the drive was full.