ttlworks wrote:
Cray Ze wrote:
This is already the plan, though not limited to any particular resolution.
The "limit" is the visible part of the raster line when generating the video signal.
PAL: raster line = 64us, visible part is 52us.
NTSC: raster line = 63.6us, visible part is 52.7us.
Obviously you have to keep the timing at that which the display/monitor is expecting, but that's not what I meant by
"not limited to any particular resolution", I mean I'm not limiting the screen expansion to a fixed value, 52*32 might be good
for some things, others things might be better with 50*30, and an initial port of say, a VIC-20 game, might be better with
22×23, at least during the beginning of conversion work.
Quote:
Cray Ze wrote:
To remain VIC-II compatible you could use a parallel 1Kb ram at a screen address and bank
in the second portion of the screen as needed.
Yes, that's obious... but what if you have old software which uses 40*25 text as a ca. 1kB block in memory,
and you would like to add some status text stuff _around_ that 40*25 text, but at a different place in memory ?
Adding stuff to old software sort of makes it new software, and any screen layout changes would mean changing
the same area of code that you'd already be changing for the additional info display.
Quote:
Color RAM starts at $D800, Kernal starts at $E000, so 2kB of color RAM would be possible.
Hmm... C65 did some odd memory mapping for the color RAM.
I haven't had a close look at C65, are they mapping different memory to color RAM for different modes/functions?
Quote:
Cray Ze wrote:
There might be a way around it if the design targets scan doubled VGA for video output.
A scanline buffer could be held in an SRAM (just storage, not mapped to the address space).
While a line is being output from the linebuffer, the rest of the system would be free to access sprite data.
Please elaborate this a bit more into detail, I think you had lost me there.
Imagine you are targeting 800x600 SVGA as a display output, 640x400 pixels in the center as the 'screen', the rest being the' border'.
Mapping 200 VIC-II lines onto 400 display lines means either sending every line twice, or just not sending a second line for 'scanline' style display.
In either case, there should be time to do other things during every second SVGA line, like loading any sprite data to be shown on the next line.
Quote:
IMHO the bottleneck is where the VIC-II connects to the bus,
and fetching sprite data a lot of rasterlines ahead would complicate sprite multiplexing
(displaying more sprites than the VIC has be re_writing the sprite registers in the right moment).
We only need to buffer one rasterline in this case, and sprite data would be read during the previous double/blank (linedoubled/scanline mode) line.
This causes no issues for mid-screen sprite register re-writes.
Quote:
We already had the idea of using SRAM as line buffer for "caching" an entire text screen.
When using it for sprite data too, then fetching text from memory at even frames and sprite data
at odd frames probably would generate some other problems...
with sprite multiplexing, when using "line crunching tricks" etc.
I think the 'caching the entire screen' discussion was mainly to do with allowing rotation and zoom in a TTL implementation,
but that's not all that practical for most people that might decide to build a TTL video design anyway.
Quote:
A buffer at the output at the VIC-II (after the bottleneck) probably won't be too helpful.
I agree, but we're not just "tacking a scan doubler onto the output of a VIC-II" in this case.
Quote:
// Another option would be having two 64kB blocks as video memory, or running the bus at twice the speed.
Looking forward to see your trick for generating hardware windows in a text screen.
This sure would simplify that 40*25 versus 52*32 text problem.
It effectively makes it a non issue. The original VIC chip (as in VIC-20) had a lot more control than the VIC-II in this area as well (not windowing but variable sized display matrix).
Quote:
From the VIC_II timing diagrams, I think that sprite 3 and 4 could work with 52*32 text without pulling any odd tricks.
Odd tricks?