Aw yes, I have used Supercharge and know what you mean. It was kind of cool to see the screen show the building of the bytes of machine code as colored pixels.tofro wrote: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.
Choice window manager for ICE
Re: Choice window manager for ICE
Re: Choice window manager for ICE
It was possible with the first versions of the PE, I know this because I knew a programmer who wanted to write a paint program back then, but gave up after the change. It is possible that the buffers were connected in chains at the time. In old history texts it was mentioned that from a certain version the secondaries must be within the primary. I don't know the exact reason, though, as TT didn't explain it when asked.tofro wrote: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.
7000 4E75
-
stevepoole
- Aurora
- Posts: 889
- Joined: Mon Nov 24, 2014 2:03 pm
Re: Choice window manager for ICE
Hi Tofro,
You wrote <<Turbo has never done anything like that. It was Supercharge (its predecessor) that used screen memory as scratch space on unexpanded machines.>>
Yes Turbo did offload data to microdrive tape while running on my JM 128QL. But Digital Precision had warned me of this and wrote that I should get extra memory, which I did in the form of a SuperGoldCard. That they get Turbo into 128ko at all was in itself quite an achievement ! I still have that Turbo cassette in its original box !
As for saving partial screen areas for reloading, that is made complicated by the QL's bizarre way of pixel addressing. (Memory block moving in itself is simple).
PEEKING into windows has always been a bit of a nightmare.... which is probably why few QL people have done any complicated graphics handling.
How many QL programmers have attempted texture wrapping onto 3D surfaces, for example ?
Regards, Steve.
_____________________
You wrote <<Turbo has never done anything like that. It was Supercharge (its predecessor) that used screen memory as scratch space on unexpanded machines.>>
Yes Turbo did offload data to microdrive tape while running on my JM 128QL. But Digital Precision had warned me of this and wrote that I should get extra memory, which I did in the form of a SuperGoldCard. That they get Turbo into 128ko at all was in itself quite an achievement ! I still have that Turbo cassette in its original box !
As for saving partial screen areas for reloading, that is made complicated by the QL's bizarre way of pixel addressing. (Memory block moving in itself is simple).
PEEKING into windows has always been a bit of a nightmare.... which is probably why few QL people have done any complicated graphics handling.
How many QL programmers have attempted texture wrapping onto 3D surfaces, for example ?
Regards, Steve.
_____________________
Re: Choice window manager for ICE
So I created a Psion task file (Exchange_TSK) using Choice with each of the 4 Psion programs as a task and each reserving 32K for screen on a RAM expanded QL. I guessed at the memory usage (gave each 20K which was enough for 640K RAM)
It works pretty well to switch quickly between each app. You can even get rid of Choice as all you need is the TSK file which itself is a 3K executable (I think it needs ICE to run). But a neat way to package the Psion suite and switch between them without corrupting the screen. Pretty cool...one can only imagine if the QL had persevered and ICE turned into PE, the TSK mechanism would have been a cool way to package software with multiple executable.
It works pretty well to switch quickly between each app. You can even get rid of Choice as all you need is the TSK file which itself is a 3K executable (I think it needs ICE to run). But a neat way to package the Psion suite and switch between them without corrupting the screen. Pretty cool...one can only imagine if the QL had persevered and ICE turned into PE, the TSK mechanism would have been a cool way to package software with multiple executable.
Re: Choice window manager for ICE
I got Choice configured to run Digital Precision's Conqueror....twice. I used my 512K Expanderam and Kempston Disk Interface card hooked to a single floppy. Configured both copies for 200K of RAM and no screen save. They both booted up, and using the "CTRL" key selection to pick a floppy (it releases the other), was able to boot one instance off of floppy 2 and the other instance is looking for floppy 1. Unfortunately I only have 1 floppy drive so I can't complete getting the other instance to boot, but I'm 99.9% sure it will since it's asking for the floppy, looking for the boot sector.
Pretty cool. This is JSU QDOS with ICE and Choice configured TSK file, which reserves RAM and zeros out job priority when tasked out (as far as I can tell). This kind of stuff is why I love the QL, just some cool tinkering you can do on the software side.
Pretty cool. This is JSU QDOS with ICE and Choice configured TSK file, which reserves RAM and zeros out job priority when tasked out (as far as I can tell). This kind of stuff is why I love the QL, just some cool tinkering you can do on the software side.