[A83] Re: something to talk about
[Prev][Next][Index][Thread]
[A83] Re: something to talk about
Patai Gergely writes:
> 1. I know I'm badly informed, but what do you mean by this shift table
> method?
There are different variations of the method. I think Crashman's uses some
tricks to use less memory, but it ends up allowing fewer map tiles. For
specifics on his routine, check out the source. There is a fair amount of
documentation included.
The method used by Kirk Meyer uses two 2048 byte lookup tables. Each table
is actually eight separate tables. Each of the eight tables contains all
256 bytes, shifted the correct number of times for that table. One table is
for the left byte of the tile and the other is for the right byte.
When a map is drawn from scratch, each tile must be shifted between zero and
seven times. It is much faster to simply lookup the correct byte in the
table than it is to actually shift each byte that many times. Every byte
will be shifted the same number of times during a single redraw. Thus, only
two tables, one for the left and right bytes, are needed. Because the
tables are aligned, the high bytes can be set at the beginning of the
redraw. To lookup a value, it is only necessary to substitute the low byte
with the input value.
Map sprites are stored differently than normal. Map sprites must take up
2048 bytes (for black and white or one grayscale plane), since all 256
sprites must be used. The data for all of the sprites is interleaved. i.e.
The first 256 bytes contains the first byte for all sprites. This allows
the same lookup table method to be used to access the sprite data.
The following is an example of an inner loop using this method. It would be
unrolled for all bytes except the first and the last. Those are special
cased and not shown here. Depending on how the map is stored, the second
instruction could be changed to an eight bit increment:
; b = msb of map sprites for row
; hl = tile map start
; b' = msb of left shift table for map
; de' = video buffer
; h' = msb of right shift table for map
ld c,(hl) ; load map tile
inc hl ; next map tile
ld a,(bc) ; load map sprite
exx
ld l,a ; point to right shifted byte
ld a,(bc) ; load left shifted byte from previous tile
ld c,l ; point to this byte in left shift table for next time
or (hl) ; combine with right shifted byte
ld (de),a ; write left byte to video buffer
inc e ; next video buffer position
exx
> 2. Is LCD handling on the 86 just as annoying as on the 83 and the
> like,
> or it costs less time (compared to 50k cycles for a complete screen)?
No, the 86 doesn't suck :) The 85 and 86 use a memory mapped display.
Writing a byte to display memory immediately changes the pixel on screen.
The address of the display memory can also be changed through a port. This
is how grayscale works. An interrupt handler simply flips between two
display buffers.
Imho, it is much more enjoyable to program for the 86 than the 83.
--
David Phillips <david@acz.org>
http://david.acz.org/
References: