Ah, okay... So when you say sprites, you mean bobs, you are blitting them into a bitmap for display? That makes more sense.

I have yet to find anyone put forward a valid argument that my system is not a Sprite Generator!
Having said that, I welcome the challenge!

Here is my argument in favor of Sprites...

1) My system is 100% independent of the host.

The Sprite Generator even knows how to wrap its own memory counters. Much like the C64 Sprites, the CPU only has to issue the draw command, and the Sprites know their own X/Y dimensions. In fact, on power up, my system will begin displaying Random Sprite graphics even before the 6502 in the VIC is done booting.

2) My Sprites are fully Alpha Aware without CPU intervention.

Unlike Bobs and Blitted graphics, I don't have to waste CPU power to calculate the invisible pixels. With blitted graphics, you are stuck doing a mask or XOR, wich is crazy slow. My System contains Alpha Pixels in the image data, and the hardware itself deals with it in real time, just like a hardware Sprite System does.

3) Sprites will have their own hardware attributes.

Although this function will come later, The Sprite Generator will have its own lookup SRAMs to store Sprite position, sizes, and possibly autonomous paths for complex movement with zero CPU intervention. This takes the term Hardware Sprite even further than most implementations. An example of this working would be a wave of 300 aliens making a complex circular path on screen, all done without any CPU intervention.

Here is a WIKI description of Hardware Sprites that aligns nicely with the hardware I have created...

https://en.wikipedia.org/wiki/Sprite_(computer_graphics)

So at this point I am still calling it a Sprite Generator.
I am open for any discussion to change my mind!

Brad

For me the difference is if you have to do bob management stuff like restore the background under them. Sprites float above the screen bitmap and don't modify it at all.

Often sprites offer other useful features, like pixel accurate and alpha aware collision detection.

Do you broadcast sprite collision?

They're sprites. There are multiple ways of achieving the same effect, but the end result - objects that move independently on the screen - is the same. I don't think sprites have been done the C64 way since the 1980s.

Having to restore the background is not a problem if everything is redrawn from scratch every frame. That's what games do these days, and it sounds like Brad's system is more than powerful enough to work that way.

Sure, it's really down to how they work from a programming point of view, which is why I mentioned bob stuff like having to redraw the background manually when they move.

Brad's system seems similar to the Neo Geo, everything is big sprites including the background.

In my system, I do not have to restore the background under Sprites, nor do I need to mask out invisible Alpha Pixels to draw something like a ball. All of this is done by hardware not under control of the VIC-20 CPU.

Now, somewhat contradictory to that statement, I do in fact redraw the entire screen 60 times per second. In my case, this will be the Back Buffer (non displayed portion of Video Memory). During this time, the Front Buffer is being sent to the NTSC monitor.

The Sprite Generator is so powerfull, that I can use it to clear the screen (or part) by simply telling it to output a single 13 Bit color instead of data from the Media Memory. I can also use a 360x240 Sprite as the background to start a "clean slate". Being able to redraw the entire screen 8-10 times at 60 FPS means that I never have to worry about preserving anything. In fact, I do not even have hardware to allow the VIC to read the Back Buffer. It is a "set and forget" deal only.

Here is an example of the massive power achievable in this type of system...

https://www.youtube.com/watch?v=XuzK2BwvmKQ

In that video, I draw a 400x300 image to the screen using 300 Sprites, each one as a 400x1 pixel Sprite, selected from a much larger (800x300) image stored in Media Memory. The wave is just each Sprite being positioned with a Sine Wave lookup table.

To top it all off, I tossed another 16 Sprites over the other 300 Sprites that make up the background and set them in motion. Even at 4MHz, that system still had more than 50% more free time available at 60FPS to draw more.

It simply makes zippo sense to consider individual hardware per Sprite, constraining yourself to small fixed sized Sprites that would each require multiple circuits. Back in 1982 SRAM was big bucks, which is why they did it that way.

Brad

Did a few concept renders of what will eventually become the final PCB.
All ICs will be completely hand wired to copper bus bars, arranged in a half circle.
This assembly will live in a back-lit glass front round case to show off the insides.
The Cray II computer comes to mind with this circular layout.

Here is a basic concept of the bus-bar PCB and the nylon holder...



Each IC will be soldered to alternating VCC and GND bus-bars.
All signal wires will be done point-to-point under the ICs.



The main cabinet will be made of finished oak with a glass front to keep the retro look.
The mini cartridge port will sit on the top of the case for easy access.
One single cable will connect the unit to the VIC-20 cartridge port.

The final size and number of bus-bars will be determined by the completed prototype.

Brad

So, how do we categorize this.

Performance Art?

Kinetic Sculpture?

Hmm... wait:
When adding some power supplies, it would resemble a tiled stove somehow.

There are flexible PCBs of course...
but for how many years them PCB traces and chips would be staying on a flexible PCB before falling off would be another topic.

It would just seem wrong not to add all 5000+ wires by hand!

I also intend to go retro on the power supply, making it a piece of artwork as well...
Huge TO-3 regulators and a nice gold case transformer crankin' out the amps.

Brad

If you want to start mass production of jet packs, better build a machine that adds the wires.


It's a pity, that new_fashioned low drop regulators like the MIC29751 are not available in TO3 package.
TO220 doesn't look cool.


Toroidal transformers also might be nice: VPM12-20800, 6V\41.6A output.
Maybe Vishay VS-100BGQ015 Schottky diodes would do for building a rectifier.
I think it's better to use several small capacitors instead of one big capacitor.
Inrush current of your power supply during power_on might become a topic...

Maybe it's less fuss to buy a Meanwell switchmode power supply instead.
PSP-600-5, four of them could be wired together.

I looked at replacing the v-regs in my VIC, but I also agree that it spoils the product.

I talked with someone that was making switching supplies that drop right into the TO3 socket, but besides not looking "right", I was told that when they do fail, there is a 50-50 chance of either an open or short condition.

A short condition means the end of your vintage computer!
The original TO3 regs always go open, so they are safer.

I am a stickler for keeping the original look of my retro collection, even under the hood.
I even went as far as to gut the massive old 4700uF cap to put a new smaller on inside the can.

So in my JetPack design, all regulator parts will be only those also used in the VIC-20.

Brad

The IO Buffer / Boot Loader / Expansion RAM segment is now completed.
I moved all the ICs one last time as I wasn't happy with the layout.
Looks much neater now...


Expansion Port IO Buffer

The unit now boots into my JetPack Wedge, which is merged with Commodore Basic...


JetPack Basic OS Wedge

I have some basic commands done, which are called by adding "." before basic commands.
The command .ROM shown above swaps to another 8K segment in IO5 expansion.
In this case, I loaded OmegaRace there, as it is a great VIC game!

As soon as I hit enter, Omega Race instantly boots.


One of my favorite Vic-20 Games.

Later, I will add my own ROM Kernal programs such as the Assembly Editor, Assembler, Sprite Editor, Music Tracker, and many more tools used to create JetPack Enhanced Games. The Kernal routines will become a full fledged OS, all stored as segments in ROM for instant loading.

Now that the basic IO system is working, I will start on testing the NTSC System.

Later!
Radical Brad

You could just build a switch mode power supply... Or even a linear one, but using discrete components.

Back in the day efficient switch mode PSUs were possible, just not common due to cost.