VIC-20 JetPack [split from: VICE Build and Mods]

[orion70]

It's one of the most ambitious and complex projects I've ever read about in the field of 8-bit mods; it's all done with components from the 80s; and it's run by a VIC. What else should we dream about? Now, this really reminds me of the V-GER (I know it was already proposed, but still, the danger of a self-conscious VIC for our world is real. I am writing to warn you ).

[Mike]

I'd estimate something just a tad bit short of 0.001 MFLOPS. [...]

Huge difference indeed.

I wonder what performance the VIC will end up with when my giant breadboard is up and running?

Well, you answered your question by yourself already ...

My system will have 16 bit math (Add, Sub, Mul, Div, Sin), all working as single cycle lookup tables.
So the VIC will be able to do things like 234/23 or SIN(143) in one machine cycle.

Get real! Even with giant tables, the computation time will be dominated by transfers of arguments and results, and table lookup needs at least 4 cycles per byte of everything that is handled by the 6502 CPU. *)

...

Making just one part "super-efficient" is of no value - it's the slowest part of the system that holds back everything else. What you want is a balanced system, with no apparent weaknesses in the comparative speed/features of the respective components.

That also was the main philosophy of Mr. Seymour Cray when he designed those supercomputers.



*) For a rough estimate: you'll need 8 cycles to transfer an argument byte from RAM to an I/O register, 32 cycles in total for two 16-bit arguments, another 16 cycles to transfer the result back into RAM. That gives 48 cycles for a single operation, not only 1 cycle.

[Radical Brad]

Thanks Orion, VGER was really just my attempt at learning to talk back and forth between the VIC cartridge port and an FPGA. It worked well, and I learned a lot. The real magic started for me when I put away all the moder tech, and went back to the 80's, using 74 logic and TV display!

Come on now Mike, did you really just ask me... "what's the point"?
You really don't understand the point of doing this project??

...hmmm.
Neither do I, so I can't come firing back at you!

But really, I have wanted to make the ultimate 8 bit computer since I was 12 years old, sitting behind that old tube TV trying to write games on my VIC-20. So besides completing a 37 year old dream, there really is no point.

I prefer to do all my enjoyable computing on a VIC-20, so that is why I chose it as the host platform, and why I am using only parts that were possible in 1982 when I first came up with the crazy idea. The entire OS will be running on the VIC; compiler, debugger, sprite and music editor, etc. I am not planning to allow any assistance from modern hardware. This is going to be "real" VIC flavored retro all the way.

Why do you switch on your VIC-20?
Surely, you could make a quicker Mandelbrot plotter or graphics application on a modern PC?
Why not just here a student to code it for you in visual basic and spend your time on more productive things?

... same reason I am building a 400 IC hand wired VIC-20 super charged expander, that's why.

And another thing dude, I have to disagree that a balanced system really matters here.
My goal is a multimedia enhancement, so I put the power where it matters.

I will certainly be able to make the Amiga look bad with this kind of power, and I will certainly be able to do it with instructions being issued from a 1MHz 6502. I have done it before, and I am doing it bigger this time around. I am also implementing a type of pipelining for several of the hardware functions, so I may be able to do math on every cycle. One write to a special function register may trigger a series of calculations that operate directly on a sprite while the VIC moves on to other tasks.

At less than 1MHz (due to my bad implementation of 6502 at the time), there was no problem at all doing this...

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

300 individual lines moved while at the same time drawing a 2048 x 2048 bitmap and sprites.
I didn't even have math lookup tables yet. Not bad for a perfectly "unbalanced" system.

I have no rules on chip count, cost, or complexity in this project, only that it is all 80's era logic and completely controlled by a VIC-20, including the creation and execution of all code. Only a 1702 monitor, 1541 drive, and standard joystick will be used as well.

This project is my version of a HotRod, since I have no interest in mucking with rusty cars!

PS...
Mike... did you just edit out most of your post? I enjoyed responding to... "what's the point"!
Brad

[Mike]

O.K. - no full quote this time.

But really, I have wanted to make the ultimate 8 bit computer since I was 12 years old, sitting behind that old tube TV trying to write games on my VIC-20. So besides completing a 37 year old dream, there really is no point.

As I wrote in another thread - for sure the capabilities of the VIC-20 left much to be desired in comparison to the arcades, to the C64 that came out just one year later, and to the specialist machines that had been in service for the first CGI in movies and TVs.

Yet we managed to write games and other programs for the VIC-20, with that minuscule amount of RAM available at that time, unexpanded or with RAM expansion. With "just" the capabilities the VIC-I had, regarding video and sound, including those which still were undiscovered at that time. With tape or (gosh!) a disk drive for storage.

You want to make the ultimate 8-Bit computer. Fine. When I "returned home", I foremostly had my share of unfinished projects on my VIC-20 - and each one of them when finished spawned the ideas for at least two new ones. That's why I'm still here, even after nearly 14 years.

The entire OS will be running on the VIC; compiler, debugger, sprite and music editor, etc. I am not planning to allow any assistance from modern hardware. This is going to be "real" VIC flavored retro all the way.

I concur. Even if cross-developing puts us in a very comfortable position to try out all conceivable ideas before hitting real hardware, nothing beats the visible, audible and tactile feedback when the real iron is put to service. Whatever we conceive on the PC, it has to work on the VIC-20 itself. And I have a WIP which is supposed to keep true to that spirit!

Why do you switch on your VIC-20?
Surely, you could make a quicker Mandelbrot plotter or graphics application on a modern PC?

Guess what I did?

Why not just h_i_re a student to code it for you in visual basic and spend your time on more productive things?

It's quite simple. Anything involving the VIC-20 is a spare time activity for me. I do not expect to make any money out of this. For the same reason I do not accept any 'orders'. Whatever comes out of this - when I think it might be of use for someone else here in the forum, I publish it. In a way, so people are actually able to reproduce and use it. If people find a use, fine. It they can't, well, bad luck.

Restricting myself to the base machine, including RAM expansions, any kind of widely available mass storage and other peripherals puts the odds on the better side for this. Exceptions confirm the rule (just mentioning the VFLI mod, my own variant of the S-Video mod and the bug-fixed BASIC ROM which I 'applied' to my VIC-20).

And another thing dude, I have to disagree that a balanced system really matters here.
My goal is a multimedia enhancement, so I put the power where it matters.

I will certainly be able to make the Amiga look bad with this kind of power, [...]

You could have had this already over 25 years ago, with an Acorn Archimedes. And that also was a balanced system, with CPU power, memory bandwidth and video/sound capabilities finely arranged to work together. Again, not just one "super-fast" component.

[...] and I will certainly be able to do it with instructions being issued from a 1MHz 6502. I have done it before, [...]

Having seen quite some of your example YouTube vids, let me tell you that moving graphics is not just done by blitting textured rectangles over a background. If you reproduce something like ELITE like it was implemented on the Archimedes, *then* you'll see me impressed. Chances are that, whatever measures you take to make this project actually reproducible and usable for other people, you'll have to cut down on the chip count quite a lot.


No hard words. We just have different ideas what can still be done with the VIC-20 as base hardware. Otherwise it would be quite boring here, no?

Cheers,

Michael


P.S. and yes - I edited out that part. No point in that, indeed.

[Radical Brad]

I hear ya!
I am glad that you stick to the stock machine in your endeavors.
The thread here on various graphics modes is like gold.

I am more interested in 6502 coding mixed with retro logic, so it just makes sense to drive it all ahead with the very computer that lit the fire for me so many years back. Sitting in front of that glowing glass screen, squinting over shimmering pixels lit up in the form of hex codes for endless hours. Compile, wait, debug, redo... I look forward to doing it all again.

The only difference is that the VIC will speak to multimedia hardware I made with my bare hands. Hardware that could have actually existed during the great 8 bit computer boom of the 80's (ignoring ram costs, of course)! Back then I could only build simple analog electronics projects like guitar pedals and amps, but had no digital knowledge.

Hey man, don't get me wrong, I never found your words harsh... I enjoy defending my insanity and warped ideas.
You have always been helpful in the way I prefer... point in the general direction, never spoon feed!

I really don't plan on making anything here that any "sane" person would EVER attempt to reproduce.
My final project will tell a story, perhaps inspire some DIY, and maybe keep some of the dying art of bare metal logic and programming alive.
I intend to write this as a 500+ page online book, explaining every single part of the unit in great detail is it comes together.
That is how I "pay it down", since everything I know came from other hackers and their inspiring work.
Nothing from this will be "for sale". I make a living designing cinematography gear... day job!

This project will certainly take years, and I have not even put an "official" wire in the board yet.
Up to this point, everything I have posted here and on my site was experimentation of various concepts.

I will officially start this project this winter, and much more detailed documentation, schematics, video, and writing will follow.
Hopefully by 2020, I will be using my JetPack Powered VIC-20 exclusively for game and demo design.

I am definitely going to look up "Elite" and the Archimedes for inspiration now that you put that out there!
There will certainly be limits with my "mostly blitter" type design, but there will be a bit more to it as well.

I will most likely have several "helper" 65C02's on the logic board as well doing various tasks that Master VIC commands. I am already thinking of one 6502 doing a MOD-Like music decode while another does some scripted Sprite maneuvering. This edges my design a bit closer to that "balanced" system approach, offloading a lot from the VIC 6502, which can then be used for code development and live debugging of running code. I have not considered any type of 3D GPU, but perhaps a 3rd 65C02 will just sit on the board waiting for VIC to give it a task.

I have over a dozen new 65C02 DIPs sitting here, which is why I am thinking of ways to utilize them in my massive design.
If I do use these, that will be the only allowable tech outside of the 74 logic and SRAM. 6502 is certainly fair game.

Looking forward to the winter so I can get into the board again. For now, the farm calls.

Cheers... keep the spirit alive.
Brad

No hard words. We just have different ideas what can still be done with the VIC-20 as base hardware. Otherwise it would be quite boring here, no?
Cheers,

Michael
P.S. and yes - I edited out that part. No point in that, indeed.

[cbmeeks]

How did you fasten the RAM chip to the socket? Is it just the soldered wires or did you glue it?

Neat idea, BTW. I've seen that done before. Along with stacking several RAM IC's on one socket and separating the chip select signals.

[Radical Brad]

I like the stacks as well, and they are certainly less work.

For this project, I wanted to make future repairs easier, so I decided to socket each SRAM.
In the end, I may have 32+ SRAMs on the board, and plan to stock pile many more so I can keep this unit in service for the rest of my years. Same goes for all of the 74 logic ICs

I will explain how I soldered 25 SRAMs to their sockets with photos.
This took me one 2 day weekend when I was battling a flu...

Shown above, is 12.5 Megabytes of 8 Bit, 10 Nanosecond SRAM.
Or as it will be in my system, 6.25 Megabytes of 16 Bit SRAM.

My Video Bus will have 24 Bits of address space for a total access of 16 MB.
Since I am doubling them up for 16 bit output, I need 4 ICs for aver 1MB of 16 Bit space.
To utilize the entire address space, I would need to solder an additional 30 ICs!

Not sure how many the final design will actually use yet, as they are scattered around for various systems.
Video Buffers, Sprites, Playfield, Sounds, Song Data, ASM Code, Vic Expansion, Compiled Code, etc.

And that's all there is to it.
900 tiny wires, and a bit of patience!

Brad

How did you fasten the RAM chip to the socket? Is it just the soldered wires or did you glue it?
Neat idea, BTW. I've seen that done before. Along with stacking several RAM IC's on one socket and separating the chip select signals.

[Radical Brad]

I actually had a few hours of hackin' time this weekend due to a power outage!
Sitting by the glow of a solar LED light, I worked out the final direction for my JetPack project.

Having tried many solutions from FPGA+HDMI to 1980's NTSC, I have decided on a VIC only solution.

Although it was cool to see 8K colors on NTSC, I am no longer doing any video enhancement.
In fact, JetPack will really just be a continuation of what the original Super Expander was.
Basically a very advanced RAM management unit with a scripting engine.

From this point on, all Video and Sound will ONLY be produced by the VIC-20.
The only connection between JetPack and VIC will be the expansion port.
All code will be native 6502, and no modern tech will be allowed.

Having said that, I still intend this to be something special, and will still produce never before seen VIC games and demos.
The magic will come from synced bank switching, a raster timed 30fps GPU, and much more.

Games like Dragon's Lair, Lemmings, Shadow of the Beast, Turican, etc will still be possible with my proposed design.
Of course, the fun part will be the limitations of the 6560, which will have to do all sound and graphics.
Very careful selection of colors will be required, as well as some fun beam chasing.

The design will still be ONLY 74 logic from the 80's, and probably require a chip count of 300-500 ICs.

I intend to break the GPU into several subsystems, internally working as a dual buffer 184x176 8 bit chunky frame buffer being the target of a massive 4MB of 1 pixel per byte fast blitter. The system will then sync with the VIC on a raster basis to draw the frame as a series of instructions and data, much like the way some of these enhance “video modes” work. Chunky mode (1 pixel per byte) will allow the programmer to use standard X/Y addressing of the screen on a 1:1 basis and not have to worry about reading what is there before writing. The system will have special alpha-aware sprite hardware, massive 30FPs BMP scrolling and much more.

I have tested this theory already, and found that I can do 30 frames per second with zero shearing due to there being 33,930 available cycles of draw time (16,965 per 60 fps). This leaves just enough time to crank out a nice 178x176 bitmap, changing colors on each row, and leaving enough time to update the joystick, keyboard, and 4 channels for sound at 30 frames per second.

As for audio, again the only output will come from the nativ 6560, but the logic will help with things like song patterns, and special effects, all synced to the master 30 FPS engine. If I have cycle time per line leftover, I may even try some special raster times audio effects. I don't plan on using the 4 bit volume DAC sound mode though, as it is just too terrible sounding, and takes away form the true VIC experience.

Layout shall begin in the fall, where I will post details for those interested in retro logic and all things VIC.
To pre-answer the obvious question… “just because I can”.

Cheers!
Radical Brad

[Radical Brad]

Since the only time I have to spend on my JetPack project is over the winter months, I do get a lot of time to think about the final design, which will commence when I am once again buried under a layer of snow.

I have 2 hours of commute time per day to work, so I have been evolving things towards the final design.
All of the prototyping posted here over the last few years has been "smoke testing" of various ideas.
There actually was smoke once, when I plugged an SRAM chip in reverse!

Anyhow, I am getting very close to the final design, which now celebrates all of the functionality of the 6560 rather than hiding it.
The final JetPack design is basically a continuation of the old Super Expander, with a crazy advanced MMU inside.

One feature I decided to add this morning is a tiny Cartridge Port.
Since JetPack itself is a standard sized VIC cartridge, the new top mounted Mini Cart Port will be only a fraction of the size.

The thinking here is that Jetpack plugs in, gives the user access to the advance MMU and scripting engine, and all game / demo code can be loaded or saved to mini cartridges. This allows JetPack to stay connected at all times.

I am not interested in cross emulation or talking to the modern PC world, so SD / FAT is of no interest to me.
What I did find is a nice 16 Megabyte SPI flash for a few bucks...

https://www.digikey.ca/product-detail/e ... ND/7100880

This will make a nice "Micro Cartridge" that will plug into the tiny slot I plan to put in the top of the JetPack cartridge.
16MB should be enough to make a nice size VIC game, including code and graphics.
The SPI may even be quick enough to not require the giant SRAM media buffer.
I will have to test one soon.

I am also working out the most robust video format to use.
So far it looks like 184 x 176 with char and aux color updates on every scan line.
Since my frames are raster synced at 30FPs for zero flicker and shear, there are some limitations.
I also can't stand the look of per scanline frame changing borders, so that is out.
Audio, keyboard, and joystick are also updated per frame, so cycles are not unlimited.

Looks like the JetPack Engine will do...

- 184(92) x 176 with 4 colors + 2 changeable per line, and all changeable per frame.
- 30 Frames per second, raster synced for zero shear and flicker.
- All 4 voices and volume updated several times per frame.

JetPack will be able to lay down a 184 x 176 screen (from a much larger playfield) and then many alpha aware sprites at 30 frames per second, allowing for massive scrolling games with single pixel scrolling capability. A game like Turrican comes to mind.

The cool part will be that all graphics and sound are generated only by the 6560 in the unmodified stock VIC-20.
The real power inside JetPack will be the raster synced MMU, which will shuttle graphics bytes from a larger SPI memory to the VIC in such a way as to eliminate all flicker and offer 30 frames per second multilayered game screens.

Still a lot of beta testing to be done.

Odd... normally "Feature Creep" adds extra, but in my JetPack project, I have gone from HD VGA + stereo sound all the way down to nothing but native VIC-20 sound and graphics.

Until the next rainy (or snowy) day.... Later!
Radical Brad

[Mike]

I am also working out the most robust video format to use.
So far it looks like 184 x 176 [...]

This will most probably require to put the address generating text screen at $0000 or $0200. Take your pick.

[Radical Brad]

I have the VIC setup like this...

Code: Select all

; screenmem = 253 bytes from 512 to 764
; charmem = 4048 bytes from 4096 to 8143
; colormem = 253 bytes from 38400 to 38652

On boot, the system shoves out the Cart Signature as VIC reads Block5.
The system then send a "virtual" kickstart code sets up the 6560, telling the VIC there is no expansion memory.

During this Kickstart, the system is counting cycles so it knows when the program is done.
At that point, the "Virtual Kickstart" is removed, and VIC is told to JMP 40960 again.

From there, a raster wait routine is executed (Virtual Code again), to sync with a frame.
The following code then draws the 184x176 screen at 4096, just behind the raster beam.
By the time the beam is catching up, the first frame has expired, but the draw code finishes before the end of the second frame.
This way, I get a shear free 30 FPS redraw from a "Virtual Double Buffer" residing in the system.

I call the memory "Virtual" because the actual instructions are calculated on the fly, not stored in RAM or ROM.
It's similar to the trickery done ny Don Lancaster, but instead of NOPs, I actually send real "fake" code.

The virtual calculated code for hurling out character data would like this this....

Code: Select all

// INS	VAL			STEP
// LDA	169(A9)		1
// VAL	DATA.8		2
// STA	141(8D)		3
// VAL	ADR.LO		4	
// VAL	ADR.HI		5

Since each byte requires 6 cycles (LDA+STA), several counters in the system are working together.
There is also a counter for the resulting screen address and one for pointing to the frame buffer (internal).

https://www.tinaja.com/ebooks/socv1.pdf

Everything mentioned above is already tested and working perfectly.

I intend to add per line color changes and sound voice updates as well.
Will demonstrate this working next chance I get.
The demo will be full Screen VIC Boing... just like Amiga (well, with lesser resolution of course)!


Brad

I am also working out the most robust video format to use.
So far it looks like 184 x 176 [...]

This will most probably require to put the address generating text screen at $0000 or $0200. Take your pick.

[Mike]

I think we can leave the nitty gritty details out of this.

Point being, you're blocking a substantial part of the lower 1K for your display application. Normally, the input buffer of BASIC resides there (at $0200), also other information relevant to the KERNAL, like file tables, etc.

When you're going to do something alongside a demo which doesn't depend on the BASIC interpreter nor the KERNAL, that's no problem. If you want to do something, that is supposed to interwork with BASIC and KERNAL, it becomes slightly more difficult.


Code in external memory has been used as data pump to the internal RAM in several places here in the forum. Regardless whether it's:

- static code (what tokra and I mainly used to build the overscan bitmaps in 2010 and following),
- banked code (the likes of FE3 or Ultimem can do fast re-writes of the character set for fast scrolling), or
- dynamically generated code (for fast file I/O in excess of 150 KB/s ... missing only a reference implementation).

No harm if you go and reconstruct those findings.