[GOODIE] A2Emulator

David P. Harris dpharris at telus.net
Fri Nov 23 02:30:12 UTC 2001


I wrote a 4x8 character display routine in assembler for the Apple II for Forth, so we could get a reasonable char/line.  It worked ok, but had to use a lot of tricks and that addressing is mighty messy!  A lot of work to cram the bits into the display memory.
David

"Andrew C. Greenberg" wrote:

> On Tuesday, November 20, 2001, at 01:38 PM, Duane Maxwell wrote:
>
>           Upon trying HGR mode -- before I realized that the A2Morph leaves HiRes as
>           an exercise for the reader -- I hit upon an undocumented instruction ($FF
>           at PC $F5BA and $F5CA) when issuing a HPLOT 10,10 TO 20,20.
>
>      Yeah, I didn't get around to hires graphics - not sure anyone wanted to wait
>      around for anything to show up on the display, plus I couldn't find
>      *definitively correct* documentation of the rather bizarre mapping of
>      scanlines and colors. Lores graphics work fine, though.
>
> Here's the poop. From some old notes I found in my archives:
>
> Hires mode is 280 pixels horizontal by 192 pixels vertical, memory mapped from one of two "pages," located beginning at addresses $2000 and $4000, respectively (yes, leaving about 512 bytes per page unused).
>
> Graphics can be presented either in mixed mode (showing text and graphics) or full mode, by use of memory mapped flags, for example
>
> LDA $C050 Set graphics mode
> LDA $C053 Set mixed text and graphics mode
> LDA $C057 Set hires graphics
>
> And the screen can be toggled between pages likewise. The key flags are as follows:
>
> C050 Graphics Mode
> C051 Text Mode
> C052 Full Screen (if graphics mode)
> C053 Mixed Text and Graphics (if graphics mode)
> C054 Page 1
> C055 Page 2
> C056 Lores mode
> C057 Hires Mode
>
> In theory, hires graphics provided six colors, but this is a sleight of hand, requiring trickery to do correctly. the colors are black, white, violet, green, blue and orange, but this isn't really quite accurate. In practice, pairs of byte mapped to 14 bits, as folows (best viewed in a monospace font)
>
> +=+=+=+=+=+=+=++=+=+=+=+=+=+=+
> |V|G|V|G|V|G|V||G|V|G|V|G|V|G|
> +-+-+-+-+-+-+-++-+-+-+-+-+-+-+
> +0+1+2+3+4+5+6++0+1+2+3+4+5+6+
> +-+-+-+-+-+-+-++-+-+-+-+-+-+-+
> + even byte ++ odd byte +
> +=+=+=+=+=+=+=++=+=+=+=+=+=+=+
>
> Where 0 corresponds to the low order bit of a byte. ANY two adjacent pixels make a white pixel, stand-alone pixels take their corresponding color. The high order bit of each byte will shift the colors from violet and green to blue and orange, respectively. Thus, certain color combinations cannot occur in the same byte, of course. And obvious sub-pixel rendering effects were routine "hacks" in early computer games. And if we are being anal about replicating the Apple screen, note that the blue/orange pixels are shifted roughly one-half pixel to the right of violet/green pixels. Thus, if you are color-indifferent, you can model hires as a 560 subpixels wide.
>
> All that remains is to describe the memory mapping, which is odd, but straightforward. Each horizontal row of 280 pixels comprises 40 bytes of data, or 20 even/odd byte pairs. Unsurprisingly, addresses $2000 through $2027 represent the zero-th row. That is where straightforwardness ends. Byte $2028 corresponds to row 64. The correspondence is summarized below:
>
> Row Offset
> 0 $2000
> 8 $2080
> 16 $2100
> 24 $2180
> 32 $2200
> 40 $2280
> 48 $2300
> 56 $2380
> 64 $2028
> 72 $20A8
> 80 $2128
> 88 $21A8
> 96 $2228
> 104 $22A8
> 112 $2328
> 120 $23A8
> 128 $2050
> 136 $20D0
> 144 $2150
> 152 $21D0
> 160 $2250
> 168 $22D0
> 176 $2350
> 184 $23D0
>
> For each "block", the offset for the rows are as follows:
>
> Block Row Offset
> 0 Block offset + $0000
> 1 Block offset + $0400
> 2 Block offset + $0800
> 3 Block offset + $0c00
> 4 Block offset + $1000
> 5 Block offset + $1400
> 6 Block offset + $1800
> 7 Block offset + $1C00
>
> Thus, the 83rd row begins at memory address $2128 + $0C00, or $2D28. In practice, the trick for an Apple emulator isn't so much getting graphics to work consistently, its sound and disk access.





More information about the Squeak-dev mailing list