General > General Technical Chat
Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
RJSV:
Hi folks, here is one suggested way, to PORT your C-64 ready hi-res graphics. Sorry if a bit raw, but essence, of the C-64, comes straight out of old 'home brew' magazines.
First, is a primative CELL, so on a Gigatron you need 4 consecutive bytes...That's going to come from your vintage file, starting as a byte. For brevity I can't get into all details, C-64 stuff.
So, my start is in hardware, for Gigatron 'Double' processor. Simply, (or not), the concept has two CPU cores, each at the same 6 Mhz...
Process 1 will start generating a series of 16 bit adds, and quickly finishes a list of 8 pointers, for the Gigatron to do raster type scans.
Each pointer is into a bank of four regular Gigatron single-pixels.
Further, this 'first process' can set a flag, as first add occurs, so my so-called second process can start right
up, creating a primative pipeline.
Each Gigatron Tile can be 8 pixels across, that's 8 bytes.
Then, in proper style, you have 16 pointers in downward set of rows.
Hope somebody (more clever) wants to make it easy to view C-64 screens.
(Sorry, but I want to code a 'dual cpu' mutation.
RJSV:
To add to this info: The purpose of the code, for a regular single cpu, would be a first sub-routine, or just in-line and that builds up a short list of 8 pointers, for a CELL and then a more direct routine can then perform a sort of stamp, to any screen buffer. Although not sure exact details of Gigatron raster business.
For the C-64 lovers, the magazines described how each 'tile' can be a rather complex list of four CELLs !
Doing that, is nicely done, with 6502
at one Mhz. The possible tile shapes, on C64 is huge, I believe 256 X 256 X 256 X 256 !
OR, you could use a tile direct, with a set or BANK of tile images, for quick copy, and using that pre-computed pile of pointers.
That way you still can get 200 tiles, or whatever is tolerable.
It's really a job of bunches of data moves, with forethought around speed-up methods.
RJSV:
For more clarity: The discussion is on the Destination. The 'source' often is easy list of sequential bytes, but the destination is more convoluted, being separated by rows.
In essence you are building in Gigatron code, is what the C-64 does natively, the 4 X 8 CELL.
Plus, with animation the pile of 8 pointers help for repair / redraw of background.
That includes nice scrolling, line down or up.
Of course, and, the color substitution is fairly easy, this time.
RJSV:
For a Gigatron 'Virtual' Screen:
The source of bytes to output is 4 bytes, horizontally,and then 2 bytes of 'time'.
That means after the 4 pixels, is a link, to be loaded, into the 'X' register. So, first the new index is read, into Accumulator. Next, the 'X' register is over-written with a 'new' index; of course often the identical value.
So, in time measured as '160' byte actions, I figured 26 bursts, of 4 (actual) pixels, at 6 bytes each...or 5 bytes. I kind of hesitate to have to track stuff, such as 6 bytes worth of (video) time, but actual 5 real bytes of substance (per burst of 4 pixels).
My question, not an expert, is it possible, as two pixel times are default 'blank' or no output; Can the two instructions, to load new index to ACC. Plus save the ACC. to X. Can that also output some default, like
light grey, during each horiz 'neglected' 2 pixels.
At any rate: Exciting part is, you get 100 bytes, up top, for SPRITES, animated at 16 X 16.
By messing with the links, you can 'link' the playback for interrupting expected flow, if that makes sense.
The SPRITE itself, holds control of how many bursts of 4 pixels are the movable SPRITE raster for immediate video output.
The mapping, of Virtual Screen, is each ROW at 256.
(Not 160).
RJSV:
The thing I noticed right away, is that the actual Screen Pixels go un-touched. AND: any pointers, i.e. 'Links' in a sequence are very easy to repair.
You could consider the screen itself to be 'Read-Only' which then means no messy regeneration of backgrounds. You just simply ignore the sprites and regenerate the sequential pointers.
By the way of more detail:
With 26 bursts, 6 bytes each, 1 of those is unused byte. So when that uses 26x6= 156, then that nicely leaves 100 bytes, for storage on same page.
Each Sprite row, of 16 takes 20 bytes, but that's at 5 per burst. Gets confusing, sorry.
Anyway, figure 5 Sprite source bit-maps, of one slice or raster row. (The complete SPRITE is stored across the 16 display rows).
Navigation
[0] Message Index
[#] Next page
Go to full version