Preface: The value of one byte is eight bits. The value of one word is as yet undefined, likely 16 or 32bits. C64 video system - addr/data pair mode ->> External I/O space: 4 bytes location size desc 0 w Mode (see table below) 2 w Data (see table below) Internal I/O space - multisegmented Mode register: bit(s) desc note 15 stat/rsv BLT done (write) reserved 11-14 reserved 11-12 cnt ctl 00=hold 01=up 10=down 11=illegal 9,10 Dev ID Specify which device in the videosys to access 7-0 Address Specify base address to start transfer at Device desc notes 0 BLTer writing to BLT:0 issues power up reset to videosys 1 SYNC Programmable sync generator 2 CLUT special addressing - see CLUT description 3 VMEM Framebuffer access - addressing is a special issue Device 0 - Block Image Transfer unit The BLT unit has the special capability of internally transferring rectangular blocks around in video memory. This is includes onscreen -and- offscreen memory. Design notes: A source -and- destination counter should be used, so that offscreen data doesnt have to be stored in the same manner as onscreen data. A byte mask should be availble during word transfers so blocks of images do not have to have word-aligned boundaries during transfer. Offscreen 'mode' simply increments on a word per word basis for each transfer. Onscreen 'mode' increments on a word per word basis until the 'width' of the block is overflowed. It's cut off at modulus, the internal word re-alignment block is reconfigured, and the display's horizontal_disp register is added. The process continues until the block is complete. Also, note that several modes should be available for transfer: ID mode note 0 opaq Opaque - transfer data as-is 1 trans Transparent - ignore CLUT entry 0 in the source block 2 xor Ex-Or onscreen data with transferred data (half speed, requires pre-read on each word) 3 xor-tr Ex-Or as above, ignoring clut 0 Technically, mode 3 is the same as mode 2, but it's in the list because that's quite literally what it does. ;) If it doesn't add too much logic, make it possible to expand 1-bit image blocks in-line to the display. This would need registers specifying the '0' and '1' color. Also, mind the transfer mode table above. This can be used for high-density font and/or pixmap caching, and can significantly increase the speed of transfers (7/8:1) because only one read is required for each 8 writes. 1 - Programmable Sync Generator Looking at the XF86 modeline setup, I've decided to build a register set similar to it. It should contain entries similar to: Note that each register IS 16 bits wide. reg name desc notes Reg with controls for: osc select divider h/v sync polarity pixel repeat count \ Use remaining bits equally line repeat count / between these two 16bit regs for: hdisp hsyncstart hsyncend htotal vdisp vsyncstart vsyncend vtotal register(s) for vertical raster (important) (read/write: writing sets the high pixel bits) vertical irq -- don't publish writability of vert raster! horiz raster (optional) The rest is obvious. Keep a separate pixel counter, increment ony during the horizontal display phase. Note that horizontal display phase is NOT valid during vertical display phase. 2 - Color Look Up Table This device is simple. It's a 256-entry 16-bit color table, specifying the color for each of the 256 framebuffer values. Color weight is RGB 565. Sadly, this limits us to 32ish greys. Oh well. cant please the whole planet. Maybe include a 'greyscale' bit, where the framebuffer byte will go straight to the DAC instead of having the ramDAC look it up? Hrm. 3 - Video Memory Access The all-important ability to actually write to video memory. Fancy this. There's a somewhat special note about accessing video memory. When you select the video mem access in the 'mode' register, the 'address' half of the register is, in fact, the high address bits (16;23) for your starting address. Specify the lower 16 bits by writing it to the 'data' port FIRST. If you fail to do this, the first two bytes of data will specify where to write to. Ugly, cool, whatever.. Just don't forget ;) Note also that this 'limits' the c64's video subsys to a 'tiny' 16megs of video memory. That gives a LOT of potential room for fun stuff like fontcache, pixmap cache, backing store, etc. At any rate, have at 'er. It's now 5am. I think I can at least attempt to sleep. You konw the only thing left is getting the vicII and/or VDC onto the vga display. Hrm. >:-) There -is- a scandoubler project out that might be modifiable for such a purpose on the vdc, and could be used, stock, on the vicII. Or, even more evilly, it could be designed to read a line of data, and write it directly to video mem via (without?) the BLT'er. That's just a brainstorm. perhaps it'll get done, likely not. G'night.