Author Topic: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able  (Read 1111 times)

0 Members and 1 Guest are viewing this topic.

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
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.
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #1 on: July 15, 2021, 01:12:31 am »
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.
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #2 on: July 15, 2021, 02:42:30 am »
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.
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #3 on: July 16, 2021, 07:38:44 pm »
  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).
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #4 on: July 16, 2021, 08:08:59 pm »
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).
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #5 on: July 17, 2021, 05:47:51 pm »
   For a coding example, the Gigatron code happily spits out the VGA output, and even has that vintage look horizontally. By changing a forward link, the VGA output simply continues, as usual, just in another place.
   In the diagram, you can see how a sprite that needs to start at horiz position 16 will involve changing the link there. So the '22' position link is changed, only once, to '156' (still within 1 byte).
For the end, an index is put in the last burst, in the sprite row of 4 pixels, plus link. I believe that would be 16 plus 24 or '40' would be where the background would resume.
Notice the sprite movement involves another series of active edits, of those single byte links, in current page.
Of course, the horiz movement is chunky, but works for something like a card game animation.
  I'm actually not sure how to do memory to memory copies, but still learning.
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #6 on: July 17, 2021, 05:49:13 pm »
Diagram of VGA source streams
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #7 on: July 17, 2021, 05:51:27 pm »
Diagram of VGA source bursts
 

Offline RJSVTopic starter

  • Super Contributor
  • ***
  • Posts: 2756
  • Country: us
Re: Commodore 64 Screen Tile and Cell system TO. Gigatron Run-able
« Reply #8 on: July 18, 2021, 10:38:46 pm »
OPTIONALLY:
   You could always avoid the horizontal blanks every 4, by using a 'List' of output instructions; Jumping into the list by a counted out pre figured number of pixels output before a new 'link' index is fetched.
   For example, suppose a Sprite is to start at location '32' horizontally. So you want to (jump) into the list at 32 from the end (bottom) of list of background, that way you get 32 reads, ( no care about location, as the X register is index).
  It takes a short couple of ticks, for Sprite start up, taking over the output to video.
  A Sprite row, for a big 16X16 sprite, will have a short index at end, using that list, jumping in, for 16 ticks left, then new burst of pixels.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf