Apple II "tile based graphics" ?
aiia...@gmail.com
graphics are stored as "tiles", and put onto the screen by
hardware... the CPU doesn't have to load graphics from
RAM and store to the display RAM.
We have something similar with apple II: the text screen + character
ROM. characters are stored as bitmaps on the ROM chips,
the video circuits on the motherboard show ?7X8? pixels on screen
for one byte in RAM:
$400 is text screen area
lda #01
sta $400
one byte changed in RAM modifies the
equivalent of 8 bytes on graphics screen.
this is FAST graphics, and takes 1/8 the
ammount of memory that HGR takes...
If a character ROM was actually a RAM chip that got it's data
off disk during boot, you could store "preshifted" graphics on
disk, and load them into the character "ROM" area at any time.
the character rom contains letters a-z
these come in inverse, normal, and lowercase
a-z
----------
inverse
normal
lowercase
0-10
!-)
26 * 3 + 20 = 98
on each "rom" there would be room enough for at least 98 ?8X7? pixel
tiles...
you could animate things on the text screen at high speeds.
What do you think about the idea?
instead of all this code to draw to the hires screen:
DRWSHAPE LDA #100
STA YLOC
SHAPE EQU $6000
LDA #<SHAPE
STA BLOCK1D+1 ;MODIFY CODE FOR SPEED
ADC #>SHAPE
STA BLOCK1D+2
LDX #0 ;POINT TO START SHAPE
LOOP1D LDA WIDTH ;# OF HORIZONTAL BYTES
STA XCOUNT
LDY YLOC
CPY #$C0 ;CHECK IF OFF SCREEN
BCC YTABLED
LDY #$29
BCS LOOP2D ;OFF SCREEN SO END HORIZ LINE
YTABLED LDA TLO,Y
STA SLO
LDA THI,Y
STA SHI
LDY XBYTE
LOOP2D CPY #$28 ;CHECK IF OFF SCREEN
BCS CONT
BLOCK1D LDA SHAPE,X ;THIS CODE GETS MODIFIED
;
; LDA #255 FOR TESTING LIGHT COLLISION DET
STA (SLO),Y ;PUT IT ON SCREEN
CONT INX ; NEXT SHAPE BYTE
INY ;NEXT SCREEN LOCATION
DEC XCOUNT ;KEEP TRACK OF WIDTH
BNE LOOP2D ;IF NOT AT LIMIT OF WIDTH, CONTINUE WITH WIDTH
;OTHERWISE DO NEXT BYTE IN HEIGHT
INC YLOC ;NEXT Y
DEC HEIGHT ;KEEP TRACK OF HEIGHT
BNE LOOP1D
RTS
you would have to:
1)have x,y
2)have a shape number
3)lookup table for the text screen
4)PRINT (or STA) the appropriate byte (tile)
to the x,y specified.
it would be limited on y resolution (move 8 pixels each time)
unless you preshifted horizontally AND vertically, taking more
space in the character ROM.
Rich
joseph...@gmail.com
aiia...@gmail.com wrote:
> NES video game system has a hardware sprite controller..
>
> graphics are stored as "tiles", and put onto the screen by
> hardware... the CPU doesn't have to load graphics from
> RAM and store to the display RAM.
>
> We have something similar with apple II: the text screen + character
> ROM. characters are stored as bitmaps on the ROM chips,
> the video circuits on the motherboard show ?7X8? pixels on screen
> for one byte in RAM:
Are you familiar with HRCG, the "Hi-res Character Generator"?
It was part of the Applesoft Toolkit, by Apple, which pretty much did
what you suggest.
heuser...@freenet.de
Undoubtedly, see Atari & C64 etc. Combined with scrolling hardware its
practically the only way to do (really) smooth scrolling with 50 or 60
Hz over big maps.
But as far as standard Apples go they simply don't have the feature of
a custom character set. And if they had they probably won't have
colored text. Not to speak of hardware scrolling...
So for games scratch that approach and use a software tile engine.
This way you not only have color but also much more flexibility, too:
You can display as many tiles as you want and even combine them with
"normal" graphics likes lines or whatever.
Ultima IV for example uses more than 256 tile definititions ("measured"
in 8x8 characters) to build the 16x16 (14x16 on the Apple) tiles. This
is one of the reasons why the Atari and C64 versions are running in
hires graphics and not in a text mode. I assume that the easy porting
is the main reason.
The C64 port of Ultima II did indeed run in text mode with custom
characters - very fast - but on the other hand the graphics were not as
varied as in laters Ultimas.
There are tricks to display more than 128 of 256 different characters
on screen with the Atari or the C64 (display list or raster line
interrupts), of course, but these use processor time, also.
If you wan't a software tile engine you can relatively easy write one
yourself - its basically nothing more than a memory move routine. And
you can tailor it to your specific needs.
However, there are several advantages in the "weird" memory
organization of the standard Apple hires mode you can take advantage
of. For example a horizontal line never crosses a page boundary (runs
faster). And you can mix high resolution with color - with certain
restrictions, as most people here know.
On the other hand the even and odd bytes of the screen memory do cost
either speed (bit shifting) and/or memory (pre-shifted data) if you
want to work with more than a 2-byte horizontal tile resolution. This
is exactly the reason why so many role playing or strategy games use
2-byte wide tiles on the Apple.
I suggest that you build or get an optimized tile engine if you want a
*fast* mapped display and not a "PRINT"-replacement routine if you want
to put "lots" of tiles on screen.
Take for example this approach:
Step 1: Create a map, large enough to comfortably move in - say 64x40
bytes (I have a working routine with these values... ;-)
Step 2: Copy a rectangular "window" to a buffer (say 13x11 bytes),
depending on your x,y position in the map.
If you want a larger window - fine. With 14x16 pixel tiles you can have
a maximum of 240 tiles on sceen (resolution of 20x12 tiles) - which
nicely fits into a single memory page... ;-)
Step 3: Put the following things according to the game logic as byte
codes into the buffer:
The player character (in most games in the exact middle), NPCs and
other creatures, vehicles, projectiles and whatnot (a cursor for
targetting if you want one...)
Step 4: Modify this buffer to your hearts content!
My favourite example: Put the player in the middle of this 13x11 matrix
and let him see only the parts he can actually see from that point and
not through walls - simply zero the parts of the buffer you wan't to be
black on the hires screen.
There are more possibilities: Night cycles or foggy climate (with
limited visibility), a "drugged" player with a ring of weird graphics
around him.
Step 5: The actual drawing: Get the bytes of the buffer, choose the
appropriate tile (the byte is the index, of course) and copy its data
to the hires screen.
This routine should use brute force: as dumb as possible but very fast.
Use selfmodifying code, unrolled loops and tables as much as possible.
If you wan't to give the player the feeling that he actually has a
snappy program at his hands you should use a routine which is fast than
a quarter second - remember that the game logic takes its toll, too!
But you can write even faster routines. 1/10 second for a 13x11 window
is not unrealistic - nobody hinders you to draw more than one shape at
a time...
Why all the hassle?
Simply put: Speed.
And flexibility.
This way you always copy the same memory locations to a predefined
screen space - which results in faster drawing and gives the game logic
more cycles.
On the other hand you are very flexible with your buffer - and you
don't "destroy" your map (with big explosions or flying fireballs, for
example...). If you wan't to program a Boulder Dash clone maybe you
should't use a buffer, though ;-)
bye
Marcus
aiia...@gmail.com
>a custom character set. And if they had they probably won't have
>colored text. Not to speak of hardware scrolling...
Custom character set isn't available, but burning new ROMS isn't a
problem,
and I was thinking of a hardware solution... A circuit that plugs into
the character
ROM socket, and the contents could be modified by the apple II...
How is the ROM connected to the bus? Does a fetch by the video
circuits
use the data bus to talk to the ROM, or is it a seperate bus? I know
that the video
gets sent OUT over the data bus, but I don't think you can see the
contents
of the character ROM with the CPU... Perhaps the modifiable character
?SRAM?
would have to be connected to the data bus through a peripheral card?
ribbon cable
from the card to the ROM socket... SRAM on board, buffer/latch to
interface to
the ROM socket, and buffer/latch to interface to the data and address
bus?
hardware scrolling: wouldn't be needed, if preshifted shapes are
stored into
the character ROM.
the tiles would be stored in the ROM, preshifted. It would be the
program's
responsibility to modify the text screen RAM to reflect which tiles are
being
displayed....
I'm going to look into it more.. It seems like a neat way to get fast
animation
done with the IIe
Rich
David Wilson
> How is the ROM connected to the bus? Does a fetch by the video
> circuits
> use the data bus to talk to the ROM, or is it a seperate bus? I know
> that the video
> gets sent OUT over the data bus, but I don't think you can see the
> contents
> of the character ROM with the CPU... Perhaps the modifiable character
> ?SRAM?
> would have to be connected to the data bus through a peripheral card?
In the case of the IIe, the video data bus is fed (slightly modifed by
the IOU chip) into the address pins of the Video ROM and the data pins
only connect to the 74LS166 shift register. There is no way to read (or
write) the Video ROM with out substantial modifications.
> ribbon cable
> from the card to the ROM socket... SRAM on board, buffer/latch to
> interface to
> the ROM socket, and buffer/latch to interface to the data and address
> bus?
Yes, that would be feasible.
>
> hardware scrolling: wouldn't be needed, if preshifted shapes are
> stored into
> the character ROM.
To shift a 7x8 pixel "sprite" in 1 pixel increments
up/down/left/right/etc would require something like 56 versions of the
image in all possible shifted states. The PCG would run out of cells
very quickly.
I have seen computers that used this method - an Australian computer
called the Microbee only had character mapped graphics and simulated
bit mapped graphics by generating PCG entries on the fly. It could run
out of characters if the screen got too complex.
If you want sprites on a IIe, the logical way to do it is a sprite card
plugged into the Aux slot as it can enable and disable the motherboard
video output and replace it with its own graphic bit stream (pin 29 of
the Aux slot when pulled high tri-states the Video ROM while pulling
pin 27 low will force a white point on the screen).
Mark McDougall
> In the case of the IIe, the video data bus is fed (slightly modifed by
> the IOU chip) into the address pins of the Video ROM and the data pins
> only connect to the 74LS166 shift register. There is no way to read (or
> write) the Video ROM with out substantial modifications.
The TRS-80 Model I had an after-market Programmable Character Generator kit
which my father had installed in his machine. Hitting a register remapped
TRS-80 video RAM to the PCG RAM to program your characters.
Its best use was to produce really nice lower-case, with descenders, rather
than the crappy CG we had at the time.
Other than that, there was very little commercial support for it. Because of
the lack of scrolling support it really wasn't very useful for games.
> To shift a 7x8 pixel "sprite" in 1 pixel increments
> up/down/left/right/etc would require something like 56 versions of the
> image in all possible shifted states. The PCG would run out of cells
> very quickly.
Yes, you'll only get 256 cells in all. On the TRS-80 IIRC there was an
enhanced BASIC that allowed you to 'plot' bit-mapped graphics by updating
the PCG on-the-fly (like the Microbee). On the TRS-80, 256 characters is
only 1/4 of the screen.
> If you want sprites on a IIe, the logical way to do it is a sprite card
> plugged into the Aux slot as it can enable and disable the motherboard
> video output and replace it with its own graphic bit stream (pin 29 of
> the Aux slot when pulled high tri-states the Video ROM while pulling
> pin 27 low will force a white point on the screen).
This is something that could easily be added/prototyped in an FPGA
implementation of an Apple II ;)
Regards,
--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
Kevin Greene
David Wilson wrote:
> If you want sprites on a IIe, the logical way to do it is a sprite card
> plugged into the Aux slot as it can enable and disable the motherboard
> video output and replace it with its own graphic bit stream (pin 29 of
> the Aux slot when pulled high tri-states the Video ROM while pulling
> pin 27 low will force a white point on the screen).
>
There was a sprite board called the supersprite that plugged into slot 7
that supported sprites layered on top of the regular video output.
I got one a long time ago used but I was never able to find any docs or
software for it so I don't know anything more than what's in the faq and
an advertisement for it.
hmmm, here's an article:
http://www.atarimagazines.com/creative/v10n2/40_A_new_way_to_do_graphics_.php
ano...@netscape.net
Kevin Greene wrote:
> There was a sprite board called the supersprite that plugged into slot 7
> that supported sprites layered on top of the regular video output.
>
> I got one a long time ago used but I was never able to find any docs or
> software for it so I don't know anything more than what's in the faq and
> an advertisement for it.
>
> hmmm, here's an article:
>
> http://www.atarimagazines.com/creative/v10n2/40_A_new_way_to_do_graphics_.php
Hmm. Based on the TMS9918(A). Your best bet would be to talk to TIers
or MSXers.
It does a lot more than sprites!
Specs:
Has own VDP RAM, accessible via ports on the host CPU. Max 16k RAM.
Background color of 15+transparent with external video capability.
32 single-color sprites with priority, collision detection (4 max on a
line, 5th on a line detection).
32x24 Graphics mode, 256 user-defineable characters in groups of 8,
each group with a foreground/background color (of 15+transparent).
Sprites available.
40x24 Text mode, 2 color. No Sprites.
64x48 Multi-color mode (like GR mode). Sprites available.
32x24 Graphics mode, 768 user-defineable, each character line (8x1)
having a foreground/background color (of 15+transparent). Sprites
available. Only available on TMS9918A.
Every mode is tile-based, even Multi-Color, which uses the Pattern
Table to select the 4 "pixel" colors within each "character" cell on
the display.
As for tile graphics on the Apple, I remember Home Computer Magazine
had an assembly routine to add tile graphics to Basic programs on the
Apple.
heuser...@freenet.de
>
>Hmm. Based on the TMS9918(A). Your best bet would be to talk to TIers
>or MSXers.
Or Coleco'ers ;-)
>It does a lot more than sprites!
I read about this board several times, but does (commercial) software
actually exist for it?
bye
Marcus
ano...@netscape.net
heuser...@freenet.de wrote:
> >> http://www.atarimagazines.com/creative/v10n2/40_A_new_way_to_do_graph...
> >
> >Hmm. Based on the TMS9918(A). Your best bet would be to talk to TIers
> >or MSXers.
>
> Or Coleco'ers ;-)
>
Shame on me! I knew about the Coleco! I have one sitting on my desk!!!
As for commercial software, it is probably like many devices.
Programming for add-ons like this board is considered "limiting your
audience". I really _hate_ that excuse.