gwyn@smoke.brl.mil (Doug Gwyn) (01/12/91)
I finally acquired Apple's Video Overlay Card and am now interested in locating sources for programs that exploit it, e.g. a 640x400 image display utility. If GENIE or AOL has these, where are they? Thanks! - Gwyn@BRL.MIL
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/12/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >I finally acquired Apple's Video Overlay Card and am now interested >in locating sources for programs that exploit it, e.g. a 640x400 >image display utility. If GENIE or AOL has these, where are they? I don't know of any commercial software that supports the 400 line mode. Getting QuickDraw to support it properly is very nontrivial. For a quick cheap Prodos-8 only demo, FTP to tybalt.caltech.edu [131.215.139.100], login anonymous / any password, cd pub/apple2/demos and grab voc400linedemo.bsq. Don't even have GS/OS loaded when you run it or bad things will happen. I can type up my current programming notes on the VOC if you want them. More useful software that exploits the VOC 400 line mode is coming soon (the program that comes with the Lord High Giffer will be able to display pictures using the VOC 400 line mode). Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.brl.mil (Doug Gwyn) (01/13/91)
In article <1991Jan12.082747.18566@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >I don't know of any commercial software that supports the 400 line mode. >Getting QuickDraw to support it properly is very nontrivial. But some work toward that must have already occurred, because at so-called KansasFest an Apple employee demonstrated a 640x400 version of Finder (with a few remaining glitches, but mostly functional). Completion of this work would be very nice, or I would even be happy to obtain the preliminary hack. >For a quick cheap Prodos-8 only demo, FTP to tybalt.caltech.edu >[131.215.139.100], login anonymous / any password, cd pub/apple2/demos >and grab voc400linedemo.bsq. Don't even have GS/OS loaded when you run >it or bad things will happen. Thanks. When launched from GS/OS it worked but didn't return properly after termination. A nice demonstation of the capability, though. >I can type up my current programming notes on the VOC if you want them. If it's not too much trouble, I'd appreciate it. Is there some published work giving programming information? The manual accompanying the card is Apple's typical dumb-user guide and gives no useful information at all, apart from how to install the card and run VideoMix, which needed no explanation. (Well, actually, the requirement that the card be installed in slot 3 in a IIGS surprised me. Is this a deficiency in the support software or does the card rely on something magical about the slot 3 signals? I had to move my FPE to slot 6, which was the least bad of the options I had available. I guess this is my last Apple II bus peripheral!) >More useful software that exploits the VOC 400 line mode is coming soon >(the program that comes with the Lord High Giffer will be able to display >pictures using the VOC 400 line mode). That would be nice, since MANY GIF images have more than 200 lines.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/13/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >KansasFest an Apple employee demonstrated a 640x400 version of Finder (with >a few remaining glitches, but mostly functional). Sorry, but what you saw was a program that did what the voc400linedemo did -- it simply displays a 400 line screen and then waits for the system to crash. I was a summer intern at Apple and talked to Dan Hitchens (the Apple employee) and he told me the truth. >>For a quick cheap Prodos-8 only demo, FTP to tybalt.caltech.edu >Thanks. When launched from GS/OS it worked but didn't return properly >after termination. A nice demonstation of the capability, though. I warned you not to have GS/OS loaded. Why it crashes: the extra video memory is an exact copy (scbs & palettes too) -- a SHR page two -- in bank $e0. Unfortunately, GS/OS allocates space for handle structures at $e0/6000 (right in the middle of the screen) early on in the boot process (i.e. before any inits are loaded). I have a P8 program that allocates a fixed non-purgable 16K block at $e0/6000 and manually changes its user ID to zero (this is illegal, but otherwise the block will be nuked when the O/S boots). It must be run before booting GS/OS. (Thanks to John MacLean for the tip! I told Dan, hopefully he'll rail on the GS/OS people about it. 5.0.4 still puts handles at $e0/6000.) >>I can type up my current programming notes on the VOC if you want them. >If it's not too much trouble, I'd appreciate it. Is there some published >work giving programming information? The manual accompanying the card is There's a tech book from APDA but according to Dan it doesn't mention any of the neat registers on the card or the 400 line stuff. > Well, actually, the requirement that the card be installed >in slot 3 in a IIGS surprised me. Is this a deficiency in the support >software or does the card rely on something magical about the slot 3 The M2B0 signal is only available in slot 3. It's necessary because the bank address isn't reliably available on the data bus during an expansion slot access (mistake! but it's too late now). Todd Whitesel toddpw @ tybalt.caltech.edu
bazyar@ernie (Jawaid Bazyar) (01/14/91)
In article <1991Jan13.062844.26145@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >Why it crashes: the extra video memory is an exact copy (scbs & palettes too) >-- a SHR page two -- in bank $e0. Unfortunately, GS/OS allocates space for >handle structures at $e0/6000 (right in the middle of the screen) early on >in the boot process (i.e. before any inits are loaded). I have a P8 program >that allocates a fixed non-purgable 16K block at $e0/6000 and manually changes >its user ID to zero (this is illegal, but otherwise the block will be nuked >when the O/S boots). It must be run before booting GS/OS. (Thanks to John >MacLean for the tip! I told Dan, hopefully he'll rail on the GS/OS people about >it. 5.0.4 still puts handles at $e0/6000.) It always bugged me severely that Apple chose to put memory management data structures in SLOW RAM. And chose to put the super hi res buffers in slow ram. And other, seemingly brain dead design decisions. Not the way to build a computer, in my book. Someone will just have to do it better ;-) -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry bazyar@cs.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
gwyn@smoke.brl.mil (Doug Gwyn) (01/15/91)
In article <1991Jan13.062844.26145@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >Unfortunately, GS/OS allocates space for handle structures at $e0/6000 (right >in the middle of the screen) early on in the boot process Oh, ugh. Is that why the thermometer box's upper left corner changes to light-blue background color partway through GS/OS booting? >I have a P8 program that allocates a fixed non-purgable 16K block at $e0/6000 >and manually changes its user ID to zero (this is illegal, but otherwise the >block will be nuked when the O/S boots). It must be run before booting GS/OS. Is there some way to automate this fix? >>I told Dan, hopefully he'll rail on the GS/OS people about it. Sounds like GS/OS should at its very beginning tell the memory-manager tools about all the areas with reserved uses, such as display pages.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/15/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes (quoting some stuff I wrote): >>Unfortunately, GS/OS allocates space for handle structures at $e0/6000 (right >>in the middle of the screen) early on in the boot process >Oh, ugh. Is that why the thermometer box's upper left corner changes to >light-blue background color partway through GS/OS booting? No, that's a little debug indicator they left in. I believe it indicates that the system is finished loading and that the startup application is being run. When I said 'middle of the screen' I meant the middle of the second screen that provides the extra 200 lines of graphics to the VOC, not the primary screen everyone is used to. >Is there some way to automate this fix? There is. It requires running a little P8 program before starting GS/OS. I'm debating the best way to implement it (currently I have to run something from my P8 selector and then run GS/OS). It will be released in a few days with the initial LHG beta so people can use the VOC modes to display GIFs. >Sounds like GS/OS should at its very beginning tell the memory-manager tools >about all the areas with reserved uses, such as display pages. It does. The secondary SHR page (which is what's in question here) is specific to the VOC, and GS/OS currently does not check for it. By the time the VOC inits and such are run, it's too late anyway because the memory has been used for handles (which can't move once they are allocated). Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.brl.mil (Doug Gwyn) (01/15/91)
In article <1991Jan14.214626.4775@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >>Sounds like GS/OS should at its very beginning tell the memory-manager tools >>about all the areas with reserved uses, such as display pages. >It does. The secondary SHR page (which is what's in question here) is specific >to the VOC, and GS/OS currently does not check for it. By the time the VOC >inits and such are run, it's too late anyway because the memory has been used >for handles (which can't move once they are allocated). Yes, but what I had in mind was the GS/OS kernel, not a VOC init, reserving the secondary SHR page along with the other areas it already knows about, avoiding the fixed-handle-in-important-location problem. I understand why it wouldn't have done that before the VOC card was released, but I don't see why it wouldn't be taken care of in recent IIGS System Disk releases (e.g. 5.0.4), simply as part of support for their own product (VOC). I've been having a lot of fun playing with my VOC. I notice that the top of the NSTC-video display tends to tear a bit (playing a VHS tape); is there a fix for this or do I have to buy a better VCR?