[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lo-res/Double lo-res (was: Wacky Game idea)
In article <615340966wnr@klatch.demon.co.uk> john@klatch.demon.co.uk writes:
>I was looking to write some routines to do double lo-res graphics from
>Applesoft (mainly to get myself back into 6502 programming!). Anyway,
>whilst looking at the routines from the II+ autostart ROM listings, I
>decided that all that was needed was to re-write the GBASCALC routine
>to see if the horizontal position byte was odd or even and choose page2
>or page1 accordingly.
Actually, it's a little more complicated than that.
1. You should never leave the aux bank switched in for very long. If an
interrupt should occur while the aux text screen is switched in, the
interrupt handler will get the screen holes in the aux bank instead of the
main bank, which could cause all sorts of problems. So disable interrupts
before switching the aux bank in, and don't leave it switched in very long.
(This isn't much of a problem in the IIe, but on a IIGS, there could be all
sorts of interrupts coming in that your program didn't explicitly enable.)
LDA COLUMN
LSR
TAY ; Get column/2 into Y
PHP ; Save interrupt state
SEI ; Interrupts off
BCS L1
BIT $C055 ; If even column (0, 2, 4, etc.), choose aux bank
L1 (do your drawing here)
BIT $C054 ; Back to main bank
PLP ; Restore interrupt state
2. The mapping of color numbers to colors is different in the aux bank--
for example, if you store "$11" at $400 in the main bank, you get a magenta
block. But if you store "$11" at $400 in the aux bank, you get a different
color (either dark blue or brown--I don't remember which). Some
experimentation will establish the complete table.
>Anyway, I don't know if this would work but whilst looking at the
>listing I found some code which I think is redundant and was
>curious to know if anyone agreed with me (or if it was well known).
>
>This is a snippet from the listing
>
>GBASCALC PHA
> LSR A
> AND #$03
> ORA #$04
> STA GBASH
> PLA
> AND #$18
> BCC GBCALC
> ADC #$7F
>GBCALC STA GBASL
> ASL A
> ASL A
> ORA GBASL
> STA GBASL
> RTS
> LDA COLOR
> CLC
> ADC #$03
>SETCOL AND #$0F
> ...
>
>From what I can tell, the LDA COLOR bit is never executed. I know it's
>only 5 bytes, but does anyone know if it exists in later ROMs?
As far as I know, it exists in all ROMs. In fact, it's an officially
documented entry point ("$F85F NXTCOL Increment color by 3. This adds
3 to the current color used for Low-Res Graphics." --Apple II Reference
Manual).
I have no idea if there's any software out there that actually uses this
entry point, but it's there for anybody who wants it.
>Talking of double lo-res graphics, how well supported is that mode? I
>know the //c had routines for it in ROM, but does the IIgs?
Yes, it's there in the IIGS too. The machine-language entry points have
never been officially published, but it works quite well from BASIC. You
can turn it on like this:
10 D$ = CHR$ (4)
20 PRINT D$;"PR#3": PRINT CHR$ (12)
30 POKE 49246,0
40 GR
Any subsequent PLOT, HLIN, VLIN, or SCRN(x,y) commands will recognize X
coordinates from 0 to 79. But only on the IIc and the IIGS--if you want
to use double lores from BASIC on the IIe, you'll have to call your own
machine language routines to do it (a couple of double lores "&" packages
have been published--Beagle Bros' "Beagle Graphics", for example).
I've never investigated it, but I remember reading somewhere that there's
a bug in the double lores SCRN function.
- Neil Parker
--
Neil Parker | No cute quote, no cute ASCII art, no cute
nparker@cie-2.uoregon.edu | disclaimer, no deposit, no return....
nparker@cie.uoregon.edu | (This space intentionally left blank:
http://cie-2.uoregon.edu/~nparker | )