Brad, I like your wiring, there is some inherent\intrinsic beauty about how those bundles of wires
are distributed on the breadboards.

When I did wiring, I had learned to stick with the resistor color code when it came to bus systems,
like D0 = black, D1 = brown, D2 = red, D3 = yellow (because I had no orange wire on stock), D4 = black again...
Green and blue was reserved for control lines like chip select, clock and reset.
To me, this had simplified debugging.



But in a design like yours with a lot of different bus systems, I think my approach would just add to the confusion.

;---

Some time ago, we had a discussion about how to build something like a VIC-II from TTL chips.
Don't know, if the sprite logic in this thread would be helpful for your project, but maybe it's worth a look.
We also had a dissection of an old 8 Bit ECL video DAC in this thread.

6kB is a bit big for a diode or CTL ROM.
Would it be possible to compress a lot of the binary stuff before putting it into the ROM,
and to deflate it in 6502 memory during the boot process ?

Have you thought about making some of this stuff into modules? Once the breadboard is working well you could make a PCB with edge connector, and a backplane system, and eventually build up your own complete modular computer. A special interface PCB would allow you to keep doing new modules on breadboard.

Another amazing TTL CPU build, no small accomplishment with all of that hand wiring and p2p soldering!
When I do the final board (also hand wired), I still plan to use CAT-5 wire.
It bends nicely and keeps its shape, which is how I make my breadboards look clean.

A TTL VIC-II would be a cool project for sure. I have been working on a 6560-101 FPGA implementation for some time, and that lone has been a lot of work. VIC-II would be a massive undertaking, but fun.

My JetPack sprite generator will have access to 16 megabytes of ultra-fast (10 ns) SRAM, and clock in at over 10MHz, so my VIC-20 will probably have a "small" advantage over the C64 when it comes to sprites! JP Sprites are also variable in size, so it would be possible to define a 4000 x 4000 pixel sprite and lay it down as a massive game screen, then layer 100 more game sprites on top of that, all at 30 FPS.

I don't think compressing the Kernal Boot ROM will work now, since 4K of it is just a large bitmap that displays a color "VIC-20 JetPack" logo on startup. RLE might gain me a few bytes at most.

No problem, I actually like the idea of being able to upgrade the Boot ROM when necessary anyhow.

Brad

My final design is going to be "dead bugged" onto a huge X/Y matrix of copper lines, laid out as a half circle standing about 20 inches tall. Imagine something that looks similar to a Cray computer, but with all of the ICs and wiring back-lit with LEDs to show off the internals. I will show some 3D models later.

The only IO ports will be the connector that runs form the JetPack system to the VIC-20, and a small port to insert the mini JetPack Cartridges on the top of the unit.

Brad

Now that chips and wires are being placed, I took some time to adjust the schematic.
Here is the small segment than I am now building on the breadboard.


JetPack Expansion Port Switch

Larger version...
http://lucidscience.com/temp/JetPack%20-%20Port%20Switch%20L.jpg

This basic part of JetPack does the following...

- Buffers logic levels between 5V TTL and 5V CMOS
- Decodes and combines the address bus into a 32K segment
- Switches / combines 3 different data streams based on microcode
- Controls counters and to create a virtual synced video frame
- Signals JetPack when it is safe to swap video screen buffers
- Loads the Boot / Kernal memory and displays the JetPack logo

This part of the board will now be wired and tested.
The milestone will be VIC booting and then displaying the welcome screen.
I can't foresee any issues in this part of the design, as it is very basic.

Later,
Radical Brad

Hmm...
When assigning the Frame Control "commands" a bit different for being able
to load the Frame Pixel Counters and the Color Memory Counters,
and connecting the Frame Instruction RAM to the counter inputs,
you probably could do split screen.

Absolutely, I could essentially have 176 individual horizontal screens all scrolling as a massive parallax background!

Considering the following timing (VIC with GPU)...



At 340K cycles per frame, the GPU could draw a background (from a massive stored bitmap), and then continue to hurl out more than a thousand decent sized sprites.

Sprites data also includes an alpha channel as well as microcode for the Sprite Generator X/Y system, so speed is going to be unreal in this version.

I also plan to include 16 bit math lookup tables for ADD,SUB,MUL,DIV,SIN and a few other functions.

Brad

Aha: this almost sounds like you are out to use a "custom" TTL CPU as a GPU.

Gigatron wasn't fast when drawing fractals.
Hmm... any chance that your system supports something like stereoscopy ?
"Diving" through fractals in real time, color and 3D probably would be fun... just kidding.

Interesting read, I like that unit under glass, proudly showing off its internals.

Although JetPack will contain 300-400 ICs, and the most complex (insane) 6502 bank switching system ever conceived, it does not replace any of the VIC-20 functions such as CPU, Sound, Audio, Joystick, Keybaord. JetPack is a massive augmentation for a stock VIC-20, made using only components that were available during the VIC era.

Having said that, the user/programmer is able to use whatever logic/cpu they like inside the cartridge that plugs into the JetPack Cartridge Port. The JP Cart Port is a direct bus to the logic system, and has the job of calling on routines and loading bitmap data into the Media Memory for use by the JP GPU and VIC-20.

In short, JetPack has not CPU, but the external cartridge can have anything from a 6502 to an ARM inside.
Using an external CPU / uC to deliver game logic was something that I tried in 2006, and it worked well.
The programmer is also able to code in whatever language they prefer.

Here is an AVR being used as a simple cartridge on a very crude VGA Game System I made...

https://www.youtube.com/watch?v=IyQP5MmQR7w
The other killer feature of JetPack is the Dual Bank Bit Splitting Video Buffer, a system that allows the programmer to draw VIC-20 screens as true 8 bit X * Y bitmaps, doing away with the packed storage of pixels or slow requirement of reading a byte first in order to alter pixels.
It would certainly be cool to later build a self-contained unit based on the amazing TTL 6502, and have only the 64K ROM as the external cartridge.

Brad

"Gigatron was inspired by (among others) the Vulcan-74 project and Dieter's notes": we are getting referenced there.

;---

My point is, that there isn't a clear border between "microprogrammed TTL graphics controller" and "custom TTL CPU".
For instance, Gigatron does 280*192 color with 34 TTL chips.
Building something like a 6545 CRT controller plus a "demonstrator" for monochrome text took me ca. 116 TTL chips.

Gigatron block diagram:



Of course, without having a block diagram (doesn't need to be nice and clean) of your project,
I can't tell which approach would take less chips:
"microprogrammed TTL graphics controller" or "custom TTL CPU".

When not aiming for compatibility, building a TTL CPU isn't any more difficult than building a TTL graphics controller...
except for the debugging maybe.

Pleace don't take me wrong: I'm not trying to talk you into building a complete TTL CPU from scratch here,
I'm just trying to ask if building something like a "custom TTL CPU" generating a VGA signal would take less chips.


Pretty compact hardware, nice video, liked those (Amiga styled) bouncing balls.


Oh, the amazing TTL 6502 is supposed to be a "plug in replacement" for the 6502\W65C02 (and 6510).
You only would have to build an external cartridge for a W65C02, and maybe to include connectors for the TTL 6502 for getting around using flat cables at 20MHz.
It's just "plug and play".

;---

There is a 6561 dissection at the Denial forum.
There had been an experimental TTL 6522 (with some issues, maybe).
There is Drass's 6502 TTL CPU.

In theory, if somebody would be willing to invest a few years of work, building a TTL implementation of an entire VIC-20 might be possible.

I actually considered a complete VIC-20 made of 74HC logic at one point!
In fact, to get a better understanding of the 6560, I started an FPGA implementation meant as a drop in replacement. Actually got it as far as showing text in a real VIC-20.

For now, all of my efforts (and previous project experience) shall be funnelled into JetPack.
This should take me a few years, ending in the hand wired, dead-bugged cray-like final design!

The GPU section is going to be massive to the point of making Vulcan-74 look small!
I may even require a 3rd MOAB section to complete it all. Will also need a larger desk!

Hope to get back to some wiring very soon.
VIC is almost ready to boot and show my welcome screen.

Brad

We dream about building something like an entire C64 from TTL chips someday, but I don't know if we ever are going to make it:
just building the CPU already gives us enough of a headache.

Looking forward to watching, how the GPU comes to life.
Go, Brad, go.

Thanks!
JetPack actually said "Hello World" today, in it's own kind of way.

Brad

It went from 25 degrees yesterday to -10 and snow today with 60Km/hr wind, so I am stuck in my basement lab working on JetPack... woop!

Progress was good this morning, and JetPack can now boot up and say hello...


Raster synced parallax scroll bars

Here is a video of the parallax scroll bar test...

https://youtu.be/n__TAgQwedM

The code that does the scrolling runs from Block-5, so the VIC thinks it is running a cartridge basically.
The routine waits for the raster beam to pass the fist line, and then draws the bars at 30 frames per second.

It is not much yet, but does show that my IO buffers and Boot ROM Loader are functioning.
I will now move onto a more technical part of the circuit... the Frame Switching system.

Cheers!
Radical Brad

One more test, this time a basic color screen to check the 184x176 format...



Brad