This thread sure is getting a bit long... not to mention "creative chaos".

We already had some text about increasing the vertical size of the sprites here.

Since we had mentioned sprites:

The VIC-II uses comparators for turning on the borders.
With a little bit of code it's possible to prevent those comparators from triggering,
what makes it possible to display sprites in the border area.

But turning off the left and right borders by software would take quite some machine cycles,
so it would be worth a thought to have an additional control Bit somewhere to simply turn off the borders.

Or a control bit that simply displays sprites on top of the border, then you get to have whatever background (border) colour you like, unlike the choice of black, black, or black when using VICII tricks.

Now that's a good idea:
Another control Bit that makes sure that the backgound color for the border is taken from Reg. 32
when if the border is turned off, thanks.

;---

Since we are at it:

In theory, when tinkering with the borders and the display logic one might be able to display,
let's say, 52*32 text (or 416*256 graphics).

Might be nice if one wants to add some status info etc. to the display of a 40*25 text editor...
but there are two issues with this:

First: 52*32 test would take 1.625kB of screen memory (plus 1.625kB of color RAM), that's not too compatible to the VIC-II.

Second: the Bytes for the sprites are read from memory in the border area (and during horizontal blanking),
means that there would be less than 8 sprites... but for a text editor, I think one mouse pointer would do.

This is already the plan, though not limited to any particular resolution. The width of both the display window and the
memory mapped screen will be decoupled from each other and be able to have any arbitrary width setting.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.
In reality, it probably doesn't matter if you just map the entire 2Kb. Existing software would only use 40x25 and 1K of screen memory
(the other 1K would work as normal for code/BASIC), and new software using the feature would be designed
not to stomp on the extended screen memory when used. The only trick would be using the extended resolution with BASIC, as the start of BASIC would have to be shifted up slightly.

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.

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.


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 ?

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.


Please elaborate this a bit more into detail, I think you had lost me there.

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 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.

A buffer at the output at the VIC-II (after the bottleneck) probably won't be too helpful.

// 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.

From the VIC_II timing diagrams, I think that sprite 3 and 4 could work with 52*32 text without pulling any odd tricks.

With the VIC-II, the display underneath the border is made up of the last byte of the memory bank. This is sometimes used for additional effects, like image patterns or in one twisted case the horizontal finescroll register is shoved around to make a gap between 2 characters to create a "9th sprite" shape which is max 7 pixels wide or so. Sprites on top of the border would be okay for a solid color or rastersplits there, but there's more possible.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

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.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.
I haven't had a close look at C65, are they mapping different memory to color RAM for different modes/functions?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.
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.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.
I agree, but we're not just "tacking a scan doubler onto the output of a VIC-II" in this case.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).
Odd tricks?

Yes, I shouldn't have said, "black, black and black". I played with the effect years ago so am aware of it, though I couldn't do much other than roll patterns through it.
That 'one twisted case' sounds twisted indeed, guessing it was in a demo/intro, do you have any links?

Right, it would be better to keep this variable.
The _maximum_ we could expect to have seems to be 52*32 text.


Memory in the C65 is two blocks 64kB.

In "C64 mode", the first block seems to be mapped to the CPU like memory like in the C64...
while the color RAM showed up in the CPU memory map like in the C64, but it _physically_ seemed to be located at the top of the second block.


Correct me if I'm wrong: I think in this case the VIC-II would need more bandwidth on the bus, that's my point.


Well, for 40*25 text we need to store 40*12 Bit inside the VIC-II anyway, and for a TTL implementation the best approach for this would be using two SRAMs.
Since the SRAM chips would be at least 32kB in size, this somehow had triggered that 'caching the entire screen' discussion.
...It's just that only _using_ 0.12% or less of those RAM chips feels... odd.

Looking forward to reading more about your "rotation and zoom" ideas.


The 6545\6845 also had a nice set of registers, what for instance made it possible to drive a LCD instead of a CRT.


Without "odd modifications" to the sprite control ciruitry, that is.

Yes, sorry, can't really get around the need for more bandwidth.

Just for completeness, I felt a need to add a list of digital to DVI\HDMI converter chips:

TFP410 (TI)
AD9889 (AD)
TDA19988 (NXP)

Specification for DVI 1.0 can be found here.
But I think that TTL chips probably won't be fast enough for building something like a DVI\HDMI interface from scratch.
Building fast differential line drivers with transistors might be possible.

Given the choice, I think I'd choose one of the converter chips
Then again, you never know what could be cobbled together from a standard differential line driver IC and a stack of potato chips.

Now that's interesting.
Data sheets for the Potato chips look impressive indeed.
It's a pity, that there don't seem to be shift registers and counters on this page.

Of course, a single Potato chip might be in the same price range as a converter chip.

I agree that using a converter chip will give you less of a headache...
...but again, it's hard to tell how long those converter chips will be in production.

Interesting, yes, the internal differential logic design is not something you'd normally associate with a 74 series chip.
With the range/selection being a bit limited, a complex design would still have to keep a close eye on total propagation delay.

Here is a more readable PDF version of the "How Does PotatoSemi Kill inside Noise Of IC ?" document.
http://www.potatosemi.com/potatosemiweb ... le2010.pdf

"No static current" is an interesting feature.