rosenman@godot.radonc.unc.edu (Julian Rosenman) (11/16/89)
I want to thank all of you who answered the questions under "Problems for a new IIGS user." However, one of the questions apparently confused a lot of you. I asked if the "frame" (the area that surrounds the text area) could be changed (i.e. written to) OTHER THAN THE BACKGROUND COLOR. Most of you wrote to tell me that I could change the color via the control panel. We all know that. Some answered that the frame could not be changed, that it was "cast in stone" (I assume this means in hardware), "cast in ROM" (does this mean that with a change in ROM this area might be accessible in the future?) or "requires tricky interrupt handeling" (does this mean that we could write into the frame if we were very clever?). It seems to me that part of the fun of the Apple II line is finding ways to make the machine do things that Apple never intended it to do. Writing into the frame would be in the spirit of the thing, as well as providing lot of extra pixels which are always in short supply. Julian
dseah@wpi.wpi.edu (David I Seah) (11/17/89)
In article <1137@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >I want to thank all of you who answered the questions under "Problems >for a new IIGS user." However, one of the questions apparently >confused a lot of you. I asked if the "frame" (the area that surrounds >the text area) could be changed (i.e. written to) OTHER THAN THE >BACKGROUND COLOR. Most of you wrote to tell me that I could change the >color via the control panel. We all know that. Some answered that the >frame could not be changed, that it was "cast in stone" (I assume this >means in hardware), "cast in ROM" (does this mean that with a change >in ROM this area might be accessible in the future?) or "requires >tricky interrupt handeling" (does this mean that we could write into >the frame if we were very clever?). Oops, sorry for the misunderstanding. I guess when I saw the subject title, I assumed the worst :-) Anyway, let me say that as far as I know, the screen border can not be changed to a color other than those defined in the control panel. The color of the background, border, and text is definable through a (couple of?) hardware register(s) whos addresses I don't have handy at the moment. There are only a limited number of settings possible. I don't know if the colors are hardcoded into the VGC or lurking somewhere in ROM. You can't write into "the frame", but some games have done some tricks with it, most notably Tomahawk GS. There is a register that contains the number of the current scanline being written. One could conceivably watch this register very closely and change the border color on an arbitrary scanline. The result would be a two-color border split horizontally across the screen. If you are using Super Hires Graphics, you can also set a scanline control byte to generate an interrupt whenever a particular scanline is drawn. Your interrrupt handler could change the border color. So, you have limited control over the border, but you would have to choose SHR colors that matched a border color to get that glorious wide-screen effect. Since there is no memory associated with the border color, you wouldn't be able to draw in the border. My impression is that the border color is a VGC bonus function (more exciting than blanking the edges, I suppose). I can feel Dave Lyons ready to clarify/correct these points with a hearty quote from Tech Note #something 8-) >It seems to me that part of the fun of the Apple II line is finding >ways to make the machine do things that Apple never intended it to do. >Writing into the frame would be in the spirit of the thing, as well as >providing lot of extra pixels which are always in short supply. I agree! Like survive for ten+ years! (a joke! a joke!) BTW, there's this chip called the TMS34070 Color Pallete chip which duplicates an awful lot of the IIGS's graphics modes (it's uncanny...16/4096, even supports fill mode!). It uses video RAM and supports some overlaying capability. -- Dave Seah | O M N I D Y N E S Y S T E M S - M | Internet: dseah@wpi.wpi.edu | User Friendly Killing Machines | America Online: AFC DaveS "MY GOD! I HAVE POCKETS!!! I CAN'T BELIEVE IT! I HAVE POCKETS!!" - Tick
krb20699@uxa.cso.uiuc.edu (11/18/89)
There is, in fact, a demo out that draws on the frame, with animation,
16 levels of color, flicker-free, fast, and in sync with the main screen,
all in SHR mode. It is definitely possible to 'draw' on the frame in many
colors and animate. BUT, because the GS does not directly support it, it's
a real hard thing to program.
By the way, the demo I'm talking about is the _ACS Demo_ mentioned on
this feed awhile back.
Ken.
ken-b@uiuc.edulunatic@ucscb.UCSC.EDU (Lunatic) (11/19/89)
In article <113300158@uxa.cso.uiuc.edu> krb20699@uxa.cso.uiuc.edu writes: > > There is, in fact, a demo out that draws on the frame, with animation, >16 levels of color, flicker-free, fast, and in sync with the main screen, >all in SHR mode. It is definitely possible to 'draw' on the frame in many >colors and animate. BUT, because the GS does not directly support it, it's >a real hard thing to program. ][ think you are going to end up confusing people again with those statements. It is NOT possible to actually DRAW on the border! It *IS* possible, however, to manipulate the border by changing its colour very quickly in conjunction with the interrupts to give the APPEARANCE of multi-coloured horizontal lines. They can even be animated so that they will appear to move up or down, but that's all. I don't think there is any way that the ROMs could be changed to give us anything more than that. Now could we please drop this? (At least no one ever mentioned "overscan..." :) > > Ken. > ken-b@uiuc.edu -- ___________________________________________________________________________ ___________ ARPA: lunatic@uscsb.UCSC.EDU / ________/ Internet: lunatic%ucscb@ucscc.edu / ____// _ ___ _ UUCP: ...!ucscc!ucscb!lunatic / ___///__ {_} |\| /-\ | ][ {_ GEnie: L.BRUCE (Lunatic Bruce) / __________________________________________________________________/ (:
pa1017@sdcc13.ucsd.edu (Nick Lenz) (11/20/89)
David I. Seah (dseah@wpi.wpi.edu) writes... > You can't write into "the frame", but some games have done some tricks with > it, most notably Tomahawk GS. There is a register that contains the number of > the current scanline being written. One could conceivably watch this register > very closely and change the border color on an arbitrary scanline. The result > would be a two-color border split horizontally across the screen. If you are Well I don't remember Tomahawk doing any of those things, but theoretically you could implement something like overscan video given enough speed. Sure, you'd spend a LOT of processor time keeping track of the softswitches at $C02E AND $C02F. Right now it is possible to check the softswitch at $C02E to find out (within 2 scan lines) which line of the screen is being updated and modify the text, border or background colors as you wish thus creating a type of overscan video (at least vertically). My guess is that, given a sufficiently fast GS you can also keep track of the horizontal counter at $C02F and also know exactly which scanline is being redrawn (one of the bits of the vertical location is stored in $C02E so that's why you can get within two line accuracy using $C02E). Using this info you could (theoretically, of course) get overscan video using the 16 colors available for text, border and background. Anyways, my point in this lengthy (and first) posting to the net is to say that it would be possible to do overscan if you could read the aforementioned softswitches with time to act on what is in them before they change again. Processor-intensive? Yes, but neato-keen, too. Nick Lenz "How would you feel about life if Death was your older sister?" -- _Sandman_ #11 Internet: nlenz@ucsd.edu or
throoph@jacobs.CS.ORST.EDU (Henry Throop) (11/20/89)
In article <5256@sdcc6.ucsd.edu> pa1017@sdcc13.ucsd.edu (Nick Lenz) writes:
[...]
<theoretically you could implement something like overscan video
<given enough speed. Sure, you'd spend a LOT of processor time
<keeping track of the softswitches at $C02E AND $C02F. Right now it
<is possible to check the softswitch at $C02E to find out (within 2
<scan lines) which line of the screen is being updated and modify the
<text, border or background colors as you wish thus creating a type
<of overscan video (at least vertically). My guess is that, given a
<sufficiently fast GS you can also keep track of the horizontal
<counter at $C02F and also know exactly which scanline is being
<redrawn (one of the bits of the vertical location is stored in $C02E
<so that's why you can get within two line accuracy using $C02E).
<Using this info you could (theoretically, of course) get overscan
<video using the 16 colors available for text, border and background.
<Anyways, my point in this lengthy (and first) posting to the net is
<to say that it would be possible to do overscan if you could read
<the aforementioned softswitches with time to act on what is in them
<before they change again. Processor-intensive? Yes, but neato-keen,
<too.
<
<Nick Lenz "How would you feel about life if Death was
Rather than watching $c02e and $c02f, it should be faster (but harder to
program) to just count the cycles, maybe with scan-line interrupts turned
on every couple of lines so that other interrupts don't get the timing too
badly off. One hitch is that the border color is in the low nibble of $c022;
I don't think it's a real good idea to mess around with the clock register in
the upper nibble (but maybe it's ok). For just incrementing one nibble it takes
around 25 cycles, which means that you can only change the border color once
or possibly twice over the length on the side of the screen. If you don't need
to worry about the clock register, it only takes a few cycles to change the
border color.
Someone mentioned that 'drawing' on the border was done in the ACS demo, which
I haven't seen - has that been posted, or could someone mail it to me?
Henry
---
Henry Throop
Internet: throoph@jacobs.cs.orst.edunicholaA@batman.moravian.EDU (Andy Nicholas) (11/22/89)
In article <113300158@uxa.cso.uiuc.edu>, krb20699@uxa.cso.uiuc.edu writes: > There is, in fact, a demo out that draws on the frame, with animation, > 16 levels of color, flicker-free, fast, and in sync with the main screen, > all in SHR mode. It is definitely possible to 'draw' on the frame in many > colors and animate. BUT, because the GS does not directly support it, it's > a real hard thing to program. > By the way, the demo I'm talking about is the _ACS Demo_ mentioned on > this feed awhile back. Uh, not really. The only way that you can change the border color is to momentarily change the border color register (bits 0-3 of $00/C022). If you leave the color in the background color register set at a certain value (a certain color in other words) for at least 1/60th of a second, that color will show up on the screen. This would only work if you wanted to make the entire line of background a certain color. Alternately, you could watch the Mega II register, HORCNT, to see when the value changes to being in the border. The only problem with try to do that is that horcnt (at $00/C02F) changes it's values to cycle through $00,$40,$41, $42,...,$7E,$7F,$00,$40,$41.. and so on.. every 980 nanoseconds with the active video time being 40 one microsecond clock cycles starting with $58 and ending with $7F. All you'd have to do is see when the video register is in the border area of a single side and then change the border color. The main problem with this is that it happens rather fast... > Ken. If I missed something, let me know. andy -- Andy Nicholas GEnie, AM-Online: shrinkit Box 435, Moravian College CompuServe: 70771,2615 Bethlehem, PA 18018 InterNET: shrinkit@moravian.edu
krb20699@uxa.cso.uiuc.edu (11/28/89)
You're all right. The demo I saw moved colors up and down by changing
the color of the border as the scan went along. It's one of the demos on
the ACS DEMO disk I just uploaded to comp.binaries.apple2.
It's a bit offensive as far as tools and language are concerned. In
other words, this is a disclaimer. It's enjoyable _anyway_.
Ken.
ken-b@uiuc.edudtroup@carroll1.UUCP (David C. Troup - Skunk Works : 2600hz) (11/29/89)
In article <113300184@uxa.cso.uiuc.edu> krb20699@uxa.cso.uiuc.edu writes: > The demo I saw moved colors up and down by changing >the color of the border as the scan went along. Scrolling border, screen and text colors is easily accomplished in one line of AppleSoft BASIC. No tool calls required. I'll dig around my hard drive for my demo and post it. Realy easy, and kinda need when you get moving text with it (for some VERY interesting results.) BTW-For those of you who were interested in my sound generator, there were quite a few of you(remember the post- I was resonating my dorm with my Apple @ 109/121hz.), and I lost the mail. So, if you guys want, Ill post it on the Net(wide) forum. Later... -- We got computers, we're tapping phone lines, I know that that ain't allowed_ _______ _______________ |David C. Troup / Surf Rat_2600 hz__________ _______)(______ | |dtroup@carroll1.cc.edu : mail______________ ________________________________|414-524-6809(dorm)/7343(work)______________