TTL VIC-II, some ideas

[ttlworks]

Cray Ze wrote:

In either case, it looks like expansion based around colour RAM is a good starting point.

Certainly yes !

Cray Ze wrote:

[TTL 6845]Hmm, that's a mountain of chips, not quite as scary as the Lorraine project (Amiga) prototypes,
but still more than enough to make the Spock eyebrow thing happen.

"Fascinating", you probably wanted to say.

Cray Ze wrote:

Likewise, it's a good thought exercise, and someone may have an interest in implementing some of the ideas,
but personally, I'll be keeping any video chip designs well within the realms of VHDL.

Ja, but the IDE software bloat... the impractical chip packages etc., let's just say that some guys might prefer tinkering
with technology that's a little bit more... "autochthonous" or such instead.
// Had to look up this word in a dictionary.

[Cray Ze]

ttlworks wrote:

John West wrote:

I have no idea how to do hardware windowing either. I did think about it many years ago, but I can't remember any of the details.
I never came up with something that would work nicely anyway.

Looking forward to see that idea from Cray Ze...

Firstly lets assume that a window in this case, is the visible screen, and it's a window to a larger rectangular plane in memory.

First, the way it probably should be done.
I'd imagine using something similar to the modulo features of the Amiga.

(0,0) of the window (screen) will start at: Y offset in plane * plane width + X offset in plane
When you reach the last location on the right, skip plane width - window width and start the new line.
The multiply can be converted to a shift if plane width is a power of 2.


Now for something a little more 'Cray Ze'.

When playing about with hardware rotozoom algorithms a few years back, I noticed that under certain configurations it seems to do the whole 'viewport into a plane' thing automagically. If you don't need to rotate, you can set a fixed zoom, and all the complex math goes away leaving just addition and subtraction. I haven't specifically used it for screen memory locations, but it should work.

I don't have any videos of a zoomed in state, only zoomed out, but I was able to do both. I'll have to resurrect the project and see if I can apply it to text and other modes.
A couple of videos I posted when messing the rotozoom hardware, it feels like a long time ago.
https://www.youtube.com/watch?v=C1QNrXE7Q6M
https://www.youtube.com/watch?v=RLm2oiaGVYI

There's a verilog version on fpga4fun.com - it doesn't take to much hardware.
http://www.fpga4fun.com/GraphicLCDpanel3.html


I'm really not sure which method would use more hardware in TTL, or which would be faster.

[Cray Ze]

ttlworks wrote:

Cray Ze wrote:

Likewise, it's a good thought exercise, and someone may have an interest in implementing some of the ideas,
but personally, I'll be keeping any video chip designs well within the realms of VHDL.

Ja, but the IDE software bloat... the impractical chip packages etc., let's just say that some guys might prefer tinkering
with technology that's a little bit more... "autochthonous" or such instead.
// Had to look up this word in a dictionary.

I wholeheartedly agree on the IDE software bloat, that is also proprietary and somewhat glitchy.
hmm, "autochthonous", I had to look that one up too. I was around in tail end of the valve days and cut my teeth on transistors and 4000 series chips.
I've played with TTL designs in the past and still might use it for small things or in certain areas, but really,
it's probably more about available time (and sometimes laziness) that led me down the FPGA path.

I like logic boxes however they're packaged.

Now I'm off to feed some Lizards.

[ttlworks]

Pictures on youtube look nice, could you please elaborate that rotozoom a bit more in detail ?

That's a nice collection of projects at fpga4fun.com, I like that Ethernet project.

Quote:

I wholeheartedly agree on the IDE software bloat, that is also proprietary and somewhat glitchy.

Or to put it this way: after replacing the light bulbs in the headlights of a state_of_the_art BMW,
you probably are going to appreciate/like cars with tail fins...

Quote:

I've played with TTL designs in the past and still might use it for small things or in certain areas, but really,
it's probably more about available time (and sometimes laziness) that led me down the FPGA path.

I had tinkered with chips like 6845, EF9367, EF9345, HD63484 etc. in the past, but at some point they all went out of production.
Did build a monochrome video display with two Lattice ispLSI1016 and a RAM back in 1998...
but at some point the ispLSI1016 went out of production and was replaced by the ispLSI1016E.
The old IDE wasn't able to generate binaries for the new ispLSI1016E, and the new IDE refused to open the old project files.
Tried to generate monochrome video signals with 8031 and PIC16C65 too, but back in 2000, microcontrollers were a bit too slow for this.

My point is: if I would have built a TTL based display controller from the start,
I wouldn't have been caught into constantly re_inventing the wheel for non_technical reasons...
and by now, we probably would have a graphical TTL workstation or such.

Anyhow, unfortunately availability and quality of TTL chips became a topic, too.
And that's what had brought me into tinkering a little bit with transistors at some point.

Quote:

Now I'm off to feed some Lizards.

Hmm... how big are those Lizards ?

[ttlworks]

Just another thought:

While looking at the graphical LCD at fpga4fun.com, I remembered that my D04 TTL CRT controller
(mentioned somewhere way up in this thread) was able to generate an analog video signal
while at the same time working as a LCD controller driving a 320*200 graphics LCD.

Whad had brought me to the idea of building a graphics card controlling a CRT and a LCD "in parallel"
was flipping through datasheets of LCD controller chips. One of those chips (don't remember which one)
seemed to be built around a 6845 core... and from there, I knew what to do.

Ok, so D04 doesn't _exactly_ meet the display timing specs for TV and LCD,
but it gives a nice and stable picture on both.

The picture above shows D03, the predecessor of D04.
D03 was a sandwich of two PCBs, in the picture it's plugged near the top end of the backplane.
D04 only had one PCB with a more dense layout and less chips.

;...

But back on topic:
It's a pity, that it became pretty hard to buy LCDs _without_ a LCD controller chip already integrated.
Else, one could try to pull a similar trick when trying to build a TTL implementation of the VIC-II.

[ttlworks]

Since we are at it:

D04 passively snooped the 6502 bus for write cycles into the address range $0400..$07FF
(it internally had 32kB of display RAM).
If there was such a CPU write, it kept data and address from the 6502 bus in latches,
then updated the D04 internal display RAM in the right moment (1MB/sec write throughput).

The 6502 only does consecutive write cycles when responding to an interrupt, and does this to $01xx.
// For the 65816, it's different.

For the 6502 the worst case scenario outside the stack area would be code like:
STA $0400
STA $0401
What causes three CPU read cycles followed by one CPU write cycle.

So it was possible to run the 6502 at 3 MHz. (At 4 MHz, some characters didn't make it from CPU to display memory.)
CPU and D04 were running at different clock speeds, generated from different oscillators.

(The D04 bus interface was sort of a kludge, because back then I didn't know as much about 6502
bus timing as I know now. You better build that part different.)

Unfortunately, for the C64 this trick won't work, because it causes a compatibility problem
if the VIC-II can't read $0000..$01FF. I think I had mentioned this somewhere at the start
of the thread when talking about system integration.
So in a C64 this means there would be consecutive write cycles to the display memory,
and to compensate for this one would have to us more than one set of latches between CPU and display RAM...
or FIFOs... or to use dual port RAM as display RAM.

;---

D04 was monochrome, but it was able to display 40*25 text and something like 320*200 hires
at the same time, pixels were mixed together by using XOR gates.

BTW: in theory, it would be possible to have more than just one display controller of that sort on a 6502 bus.

...But enough of these old stories. Will be back next Monday.

[Cray Ze]

ttlworks wrote:

Pictures on youtube look nice, could you please elaborate that rotozoom a bit more in detail ?

I will, but need to check that I'm remembering how to feed the various parameters to it correctly,
then I'll post code and an explanation of how it works.

Quote:

That's a nice collection of projects at fpga4fun.com, I like that Ethernet project.

Quote:

I wholeheartedly agree on the IDE software bloat, that is also proprietary and somewhat glitchy.

Or to put it this way: after replacing the light bulbs in the headlights of a state_of_the_art BMW,
you probably are going to appreciate/like cars with tail fins...

Or perhaps develop a lack of appreciation toward high price replacement parts

Quote:

Quote:

I've played with TTL designs in the past and still might use it for small things or in certain areas, but really,
it's probably more about available time (and sometimes laziness) that led me down the FPGA path.

I had tinkered with chips like 6845, EF9367, EF9345, HD63484 etc. in the past, but at some point they all went out of production.
Did build a monochrome video display with two Lattice ispLSI1016 and a RAM back in 1998...
but at some point the ispLSI1016 went out of production and was replaced by the ispLSI1016E.
The old IDE wasn't able to generate binaries for the new ispLSI1016E, and the new IDE refused to open the old project files.
Tried to generate monochrome video signals with 8031 and PIC16C65 too, but back in 2000, microcontrollers were a bit too slow for this.

I just checked an old box of parts and found 4 x 6845's, a TMS4500A and a bunch of other goodies that I desoldered from boards 30 years ago.

Quote:

My point is: if I would have built a TTL based display controller from the start,
I wouldn't have been caught into constantly re_inventing the wheel for non_technical reasons...
and by now, we probably would have a graphical TTL workstation or such.

Anyhow, unfortunately availability and quality of TTL chips became a topic, too.
And that's what had brought me into tinkering a little bit with transistors at some point.

All in the name of progress they say. Gone are the days where you could go to your local electronics store an find all the TTL chips you needed.

Quote:

The obligatory Commodore keyboard in use I see. I also see that I'm not the only one who's been know to use spools of wire as spacers.
Is that a standard BUS on the green backplane board, I'm sure I've seen it in a few systems.

Quote:

Quote:

Now I'm off to feed some Lizards.

Hmm... how big are those Lizards ?

Ranging from Bynoe's geckos (Heteronotia binoei) at about 2 inches to land mullets(bellatorias major) at around 2 feet.
And many, many in between. The mentioned geckos are interesting, a species of all female individuals, with triple helix DNA, that clone themselves to reproduce.
Still have some mouths feed, and some to feed again, so there may be delays but I will get to your next two posts soon.

[ttlworks]

Cray Ze wrote:

I will, but need to check that I'm remembering how to feed the various parameters to it correctly,
then I'll post code and an explanation of how it works.

Looking forward to seeing that nice trick explained.

Cray Ze wrote:

Or perhaps develop a lack of appreciation toward high price replacement parts

...Or to put it this way: when you are spending more time with fighting with the design tools instead with your design,
something went wrong.

Cray Ze wrote:

All in the name of progress they say.
Gone are the days where you could go to your local electronics store an find all the TTL chips you needed.

The owner of a local electronics store told me, that they don't have GALs, EPROMs etc. on stock because nobody would be going to buy them.
And if a drawer in the shop containing TTL parts would go empty, it will stay empty.

To put it this way: nowaday, if you want to build something simple, something reliable, something that lasts...
then there seems to be an incompatibility between you and Zeitgeist.

Cray Ze wrote:

The obligatory Commodore keyboard in use I see. I also see that I'm not the only one who's been know to use
spools of wire as spacers. Is that a standard BUS on the green backplane board, I'm sure I've seen it in a few systems.

That was a standard backplane board, and that sort of backplane boards isn't too reliable.
To save time and effort, I just had re_used the peripherals from the previous CPU project.
About those spools of wire used as spacers: one has to be creative...

Cray Ze wrote:

Ranging from Bynoe's geckos (Heteronotia binoei) at about 2 inches to land mullets(bellatorias major) at around 2 feet.

Ah... and I've already expected something like an alligator farm.

[ttlworks]

Spent some thoughts on vertically increasing the size of the sprites.
// Vertically increasing the size ain't "rocket science", but horizontally increasing the size probably is.

First, the sprite address counter Mcnt needs to be 8 Bit instead of 6 Bit.
The simplest way of address generating seems to be taking the two uppermost Bits from the now 8 Bit Mcnt
and to OR them with the two lowest Bits from the pointer that tells the VIC-II at which 64 Bytes Block
in memory a sprite starts.

Second, we would have to terminate displaying the sprite somewhere in the last raster line to be displayed
to prevent it from warping around the screen.
If one would be using two 74163 counters for implemening Mcnt, a good approach would be loading them with
the end count value. For a 24*21 sized sprite, the end count value is 63 (21 * 3 Bytes).

In the VIC-II, we seem have a 6 input NAND gate, if the counter reached 63 Mactive goes 0,
indicating that displaying this sprite is no longer active.

When having bigger sprites, two approaches which use a 74688 identity comparator instead of the NAND come to mind.
First approach compares 8 Bit Mcnt with an 8 Bit register, but since there are 8 sprites, this would take 8 registers.
Second approach uses two Bits, labeled vsiz1..0, for switching between 4 different vertical sprite sizes.

Code: Select all

vsiz1 vsiz0| Mcnt end value | Binary Mcnt end value
-----------|----------------|-----------------------
  0     0  | 1*21*3 =  63   | 0011.1111
  0     1  | 2*21*3 = 126   | 0111.1110
  1     0  | 3*21*3 = 189   | 1011.1101
  1     1  | 4*21*3 = 252   | 1111.1100

BTW: one also could use SRAM and an adder instead of counters for implementing the sprite address counters,
but it would have to run at twice the PHI2 speed.
Interesting question then would be, if the ROW and COLUMN counters and the refresh counter also could be
put into that RAM.

[ttlworks]

Slightly offtopic:

Just for the fun of it, I dug out some old schematics from 1994, showing some obscure circuitry.
It increases horizontal resolution of a (PAL) C64 from 320 to 640, but there are some issues to it:
You would be going to need a monitor with enough signal bandwidth, and it better should have Y\C input.
It only works with graphics, but not with text.

In vertival interlaced mode, we have two fields, and the scan lines from the second field are placed
between the scan lines of the first field.

The circuitry is somewhat inspired by this, but it does apply a similar concept horizontally instead:
The analog video signal is chopped with the dot clock.
For the first field, the right half of the pixels is turned black.
For the second field, the left half of the pixels is turned black.
The result is flickering a little bit, of course.

Propagation delay of nowadays logic gates might be different from the logic gates in 1994,
you better give that dot clock an adjustable delay or such...

Hmm... in the schematics, there also are potentiometers for selecting a rectangular area on the screen.
In that area (or outside that area) which btw. is marked with sort of a cursor, the CPU can be
slowed down or stopped.
That was just sort of a "gimmick", maybe for playing one or other video game, ignore this.

1994_obscurity.zip

(3.6 MiB) Downloaded 119 times

And with this, I think I'm now through with posting in this thread what I had on stock about the VIC-II.

[Cray Ze]

ttlworks wrote:

Slightly offtopic:

Just for the fun of it, I dug out some old schematics from 1994, showing some obscure circuitry.
It increases horizontal resolution of a (PAL) C64 from 320 to 640, but there are some issues to it:
You would be going to need a monitor with enough signal bandwidth, and it better should have Y\C input.
It only works with graphics, but not with text.
...
...

Obscure indeed, I like it. That's a whole lot of analog circuitry to flash a cursor, one could be forgiven
for thinking they were looking at a small section of an 80's era TV schematic.

ttlworks wrote:

Cray Ze wrote:

I will, but need to check that I'm remembering how to feed the various parameters to it correctly,
then I'll post code and an explanation of how it works.

Looking forward to seeing that nice trick explained.

Yesterday was the fist time I could set aside a suitable enough chunk of time to have a look at this,
but after looking at weird and wonderful patterns of abstraction for a few minutes, decided I'd do a simpler
6545\6845 horizontal/vertical scroll style window as a warm-up and perhaps refresh a few neural pathways.

For the warm-up design, I decided on something similar to the C64's 40x25 text mode, but acting as a scrollable
window into an 80x50 character screen. Doing this is as simple as adding an X and Y offset to the screen memory lookup.
I used a non power of 2 multiplication of 80 here, but 64 or 128 would be much easier in a TTL design.

Code: Select all

ScreenMemAddr <= std_logic_vector((Ychar+Yoffset)*80+Xchar+Xoffset)

This works fine and would be a nice ingredient in a retro 8Bit mode.
Source is quite simple as far as character displays go, but easy to understand.
If it's of interest to anyone, I can start a thread in 'Programmable Logic' and post it there.

I guess the warm-up is done, stay tuned........

[ttlworks]

Cray Ze wrote:

Obscure indeed, I like it. That's a whole lot of analog circuitry to flash a cursor, one could be forgiven
for thinking they were looking at a small section of an 80's era TV schematic.

Many years ago, when I did TV repairs for a living...

Well, chopping an analog video signal at 8 MHz by using BC847\BC857 low frequency transistors sure isn't for beginners...
But that part of the circuitry was "the great-grandfather" of the CTL gates used in the MT15 transistor CPU.

Cray Ze wrote:

but after looking at weird and wonderful patterns of abstraction for a few minutes

"stack overflow", I know that this feels like.

Cray Ze wrote:

I used a non power of 2 multiplication of 80 here, but 64 or 128 would be much easier in a TTL design.

(Ychar+Yoffset)*(64+16)

That's 2*74283 for calculating Ychar+Yoffset.
Creatively wiring the result to 3*74283 (for generating a 12 Bit video RAM address) then would give you *80.

Cray Ze wrote:

I guess the warm-up is done, stay tuned........

We are not in a hurry.

[Cray Ze]

ttlworks wrote:

Cray Ze wrote:

I used a non power of 2 multiplication of 80 here, but 64 or 128 would be much easier in a TTL design.

(Ychar+Yoffset)*(64+16)

That's 2*74283 for calculating Ychar+Yoffset.
Creatively wiring the result to 3*74283 (for generating a 12 Bit video RAM address) then would give you *80.

I thought of something along the lines of ((Ychar+Yoffset)<<6)+((Ychar+Yoffset)<<4) when writing the quoted post.
The synth tool spotted the simplification as it didn't opt for the use of a hardware mult.

Quote:

Cray Ze wrote:

I guess the warm-up is done, stay tuned........

We are not in a hurry.

Your 1994 design post prompted me to think about a hardware cursor, though sorry to disappoint, it's not analog.
I added a hardware cursor with variable blink rate and both block and line modes.

Decided I'm not quite done with this first design yet. I'll add an attribute bank for implementing
X-Flip, Y-Flip, Rotation and Inverse, then I'll look at the other screen window idea again.
Everything other than rotation will translate easily to TTL. Rotation would require very fast SRAMS and either TDMA or double buffering.

It'll probably take longer to draw the demo screens in PETSCII, than to add the functions to the design, I'm no artist.

[ttlworks]

Cray Ze wrote:

Your 1994 design post prompted me to think about a hardware cursor, though sorry to disappoint, it's not analog.
I added a hardware cursor with variable blink rate and both block and line modes.

Too bad, that the A\D converters for an analog joystick are in the SID.
Else, one could have been able to build something like a crosshair cursor controlled by an analog joystick
which triggers the light pen input at the right screen position when pressing the button...
Just kidding, most of the end users certainly won't need this feature.

Cray Ze wrote:

Rotation would require very fast SRAMS and either TDMA or double buffering.

If you would be starting to fetch the video data etc. from memory 8 raster lines before fetching normally starts,
and just use double buffering for 40 8*8 Blocks, maybe this would do for rotating individual 8*8 blocks.

Cray Ze wrote:

I'm no artist.

The mightiest design tools are paper and pencil... unfortunately, they also are the slowest design tools.
Hey, with just a little bit of practice maybe everybody could be able to draw some artwork.
You don't have to beat Picasso when just making technical drawings, you know...

[Cray Ze]

I'll put this design down for a while and go investigate my original idea.
Current result bellow.