Denial

Thanks again for the info.
When I get to the final design, I will definitely be reviewing this thread to make the best choice for the PCB.
So far, it looks like I will get by just fine for prototyping with the LVC buffers, and they are breadboard friendly.

It's amazing how many links I found to carious PET / VIC / Atari / BBC / TRS projects connecting to a 3.3v FPGA or uC, and all of them chose the 74LVC buffers. I guess they just work fine, so nobody dug deep into the differences!

Brad

eslapion wrote:

Radical Brad wrote:I will have a close look at the LVT to see what differs from the LVC I have now.

The logic threshold level... which seems to totally elude MCes...

The Low Voltage to TTL buffers considers anything above 1.3V to be a logic high on the TTL side. The Low Voltage to CMOS buffers considers anything above 2.5V to be a logic high. Same difference as 74HC vs 74HCT. The 74HCT/74LVT has the same logic threshold level as 74LS family of logic ICs.

That's why GandALF which uses a XC9572XL absolutely requires a 74HCT74 (or 74LS which consumes more power), since one of the inputs is attached to the output of an analog op-amp, the logic threshold must be exactly the right level for proper operation.

See: https://www.fairchildsemi.com/applicati ... AN-368.pdf

Since I have such minimal time in my basement hacking lab lately, this project has been a good way to keep an iron in the fire. I have been coding the Multimedia Engine in Verilog and then uploading it to the FPGA when I am home. So far, a decent amount of progress has been made.

The VIC-20 communication routine needs some work, as the FPGA is so fast that I am getting some commands running more than once. For instance, drawing a pixel can happen 40 times during a single VIC-20 cycle! I am working on a more robust Command / Control routine now that does not fire the command until the VIC releases the IO2 line, where all IO is currently mapped.

I also have several "Status Registers" inside the FPGA that the VIC can peek at before issuing a new command. This allows the VIC to issue a command and then do something else rather than waiting around for the Multimedia Engine to complete. An example of this may be drawing a 400 x 300 background bitmap from the Media Memory to the Draw Page. This operation will take the FPGA 2 cycles per pixel, so at 40MHz, it will take 6 milliseconds to complete. During that time, the VIC could render something to its own NTSC screen, or send some game music to the Sound Processor and then come back and peek at the GPU Status Register to see if the last command is complete. There is also a Status Register for Sound Commands, and even one to let the VIC see the Vertical Sync Pulse.

At this point, the FPGA is only 14% filled, but the VIC can do the following...

- Clear the Draw Screen (400x300 VGA)
- Flip the Draw Screen with the Live Screen
- Plot pixels to the Draw Screen
- 32 Bit Math (16 operands) : Add, Subtract, Multiply, and Divide
- 1024 position Sine Lookup Table
- Draw Sprites from Graphics Memory (4MB) to the Draw Screen
- Set the Sprite Alpha (transparent) color
- Change the 256 color indexed palette to any of the 32,768 colors

Sprites are Alpha Aware, meaning that any selected color can be invisible.
Because of this, masking is completely automatic.
I also plan to add real-time Sprite Rotations so games with rotating graphics only need to load one image.

I will try to get some photos and vids of this working soon.

Later,
Radical Brad

This looks like an interesting project but I'm curious as to what the main objective is. Will this be for running a separate VGA monitor in addition to the CRT VIC-20?

Is it to enhance the VIC-20 or is the VIC-20 going to be off to the sidelines?

Thanks

Greets CB, I enjoy seeing your projects as well. I find your posts all over the retro-hood when I wander.

The goals for this project are the same as for my other project "VIC-2000".
Here is the short version...

- To use my VIC-20 once again as my main computer.
- To code 6502 assembly demos and "revamp" some old VIC classic games.
- Dual displays, with all dev /coding done on the VIC screen, and results on the VGA screen.
- No other processors. The original 6502 in the VIC will have to do everything.
- The VIC-20 must remain 100% original. Only the Expansion Port may be used.

Basically, the FPGA is just a Multimedia Expansion Cartridge.
It can only do what the VIC tells it to do.

The VIC will get a new Operating System (booting as a cartridge).
The new OS will contain an IDE, assembler and many utilities such as a graphics editor, music editor, 6502 assembly reference, and a new File System to deal with 4GB external storage.

All demos and games will be completely created and assembled on the VIC using the original NTSC display. The second VGA display is only active when a program is assembled and running. At this time, the VIC will simply call the GPU / SPU using memory mapped commands at IO2.

So far, here are all of the commands (by type) that I have coded into the FPGA.
I will expand on what these all do soon, but they are fairly obvious...
The number after the command name is the offset from memory location 38912 (IO2).
All command either accept or send back an 8 bit value.

The GPU has 4 Megabytes of 10ns SRAM, and can move alpha aware images (Sprites) from one area of memory to another at 20MHz bandwidth. Since the VIC-20 CPU has do do all of the work, it's a good thing that the blitter subsystem is fast!

Sprites can be any size up to 2048 x 2048 pixels, and have 256 colors.
The GPU displays 256 colors, with a programmable palette of 32,768 colors.

Sound is 4 independent sample channels, mixed into stereo with 2 channels per side, just like the Amiga. Samples are stored in the Multimedia memory just like the Sprites and Bitmaps.

The VIC tells the SPU where a sample starts, where it ends, how load it is, what frequency to play it at, and how many times to loop. I may also add some effects if I have room.

The VIC-20 can make use of the VGER-20 in assembly or even basic, since it is just an area of 256 bytes mapped at location 38912. I will probably test all the above commands this weekend by just poking around in un-expanded basic!

So my VIC-20 is definitely not going to be on the sidelines, it's just getting a new appendage.
The VIC is the best 8 Bit computer ever made, and soon it will become the most powerful as well!

On a side note, I guess this hardware could work on any 8 bit computer that can map 256 bytes to some external location.

Cheers!
Radical Brad

cbmeeks wrote:This looks like an interesting project but I'm curious as to what the main objective is. Will this be for running a separate VGA monitor in addition to the CRT VIC-20?

Is it to enhance the VIC-20 or is the VIC-20 going to be off to the sidelines?

Thanks

I have a mental image of a cable going from the VIC-20 to a NEO GEO.

I look forward to seeing it in action.

I had a similar idea (although, much more down to VIC-20 standards) for a project a while back. It was basically a small soundcard (using emulation) that the VIC-20 could control. Something along the lines of two SID's or maybe a YM3812. Just not sure how popular it would be. But the idea would be for games such as VIC-Doom would just send a few commands and it would play some music in the background.

But I didn't want to put a 100 polyphony orchestra in a VIC-20. I like the idea of keeping the expansions somewhat on-par with what would have been available during its peak.

Alas...just not sure if I could drum up the interest or motivation to finish it.

Thanks.

I think I seen your project idea posted over on Lemon64 at one time.
Sounds like a fun project... yeah, you should finish it for sure!

I know what you mean about going so far that the soul of the machine may get buried.
This is why I decided to put down these rules for this project...

- VIC-20 remains stock. Opening the case is not allowed.
- Only one CPU, and that is the Mostek 6502 inside the VIC.
- All development and control is done on the VIC using its display.
- Any created games are controlled by the VIC keyboard or Joystick.
- The entire OS and all Dev Tools run on the VIC in its own memory.

So I will be tapping 6502 instructions out on the VIC-20 keyboard, looking at my code listing as generated by the 6560 and sent out on the NTSC signal.

Even the new file system (which will support 4GB), has to run on the stock VIC.
So this project does not hide the VIC-20, it instead celebrates its magnificence.
This is what VGER represents in the movie as well.

All of this "could" have been done in 1981 with access to a NASA-like budget and team!
I wonder what 4 megs of 10ns SRAM would have been worth back then?
I know there were gates available (ECL) that actually ran with sub-nanosecond delays.

Oh well, it's certainly within my budget now, and I am only 37 years late.
Jack Tramiel would have been pissed by that release date!

Brad

cbmeeks wrote:I have a mental image of a cable going from the VIC-20 to a NEO GEO.

I look forward to seeing it in action.

I had a similar idea (although, much more down to VIC-20 standards) for a project a while back. It was basically a small soundcard (using emulation) that the VIC-20 could control. Something along the lines of two SID's or maybe a YM3812. Just not sure how popular it would be. But the idea would be for games such as VIC-Doom would just send a few commands and it would play some music in the background.

But I didn't want to put a 100 polyphony orchestra in a VIC-20. I like the idea of keeping the expansions somewhat on-par with what would have been available during its peak.

Alas...just not sure if I could drum up the interest or motivation to finish it.

My Verilog code is now over 3000 lines long, and I have yet to test any of it!
It synthesizes just fine, but the real test is seeing the VIC control it.

Added Sprite Rotations, a 40MHz Bressenham Line Draw, Random Numbers, and a Serial Interface.
Hope to get some Basement Lab time very soon so I can test all of the commands one by one.

I also started on the PCB and case for VGER-20.
Not much done yet but the bottom shell and the male end of the PCB.
The PCB will fill the case once the FPGA and SRAMS are layed down on the board.



I decided to make the VGA and Audio port come out from the right side of the case.
This way, the cable won't have to make a sharp bend to get the VIC closer to the monitor base.
I may move the connectors to the top right and see how that works as well.
Not sure if I will require a separate power supply for the unit just yet, but most likely not.

Another mod I made to the VGA Generator code is the ability to do all 32,768 colors onscreen at once.
This of course, takes 25% of the free cycle time from the VIC as I now have to fetch 2 bytes per pixel at 40MHz.

It might be a good idea to have the dual color mod though. Startup screens could have 32K colors,
and the fast game or demo main loop would just run at 256 indexed colors.
That's for a later date. For now I need to test what I have done so far.

Later,
Radical Brad

Love the looks of that cart. Can't wait to see it all fit in there. Keep up the great work.

Thanks!

Yeah, it's going to feel good when it all comes together. I know my VIC is looking forward to it.
I may machine the initial case from a billet of aluminum.
Overkill for sure, but I am sitting next to several 5 axis CNC machines right now!

The other other hardware that will fit through the case will be...

- USB connector to access 4GB of external memory and update the OS if required.
- RGB LED to show different system functions / status.
- Push-button switch to start VGER-20 in several different operating modes.

The push-button works like this...

Press Once : Reboot and start The VGER-20 Operating System (LED is RED)
Press and Hold for 2 seconds : VIC-20 Basic Boot in Un-expanded Mode (LED is GREEN)
Press and Hold for 4 seconds : VIC-20 Basic Boot in 32K Expanded Mode (LED is Blue)

I may also add an Espresso Maker and Flux Capacitor if there is room!
... ok, maybe just the basics.

Brad

cobracon wrote:Love the looks of that cart. Can't wait to see it all fit in there. Keep up the great work.

Radical Brad wrote:I may also add an Espresso Maker and Flux Capacitor if there is room!

Wait a minute... for that Flux Capacitor to work, you would need 1.21 gigawatts of electricity provided by a Mr. Fusion reactor! Then you'd have to accelerate the VIC-20 to 88 miles per hour! The mind boggles...!

Merry Christmas,
Robert Bernardo
Fresno Commodore User Group
http://www.dickestel.com/fcug.htm

Ground control to VGER... VGER, can you hear me?
Yes, we now have rock solid communication between the VIC-20 and the FPGA through the Expansion Port.
The 74LVC245 Buffers are working perfectly.


Cycling through 256 colors by clearing the VGA Screen.

I have been running the Clear / Flip program for 4 hours now, and there has not been any glitches.
Any glitches on the Expansion Port would result in the VIC-20 program locking up.

This certainly doesn't look like much yet, but it is a large milestone in the development.
The Basic program checks the Command Status Register (CSR), then issues a Clear Screen Command (with color).
After that, the CSR is checked again, and the Draw Page is swapped for the Live Page.

All Graphics Commands only operate on the Draw Page while the Live Page is being displayed.
Once the screen is ready, a "Flip" command reverses the pages.
This is known as Double Buffering and offers a seamless animation between frames.

I am now testing all of my commands one by one, and will then make some kind of simple demo.
From here it should be smooth sailing. I will continue to wear a life jacket just in case.

Cheers!
Radical Brad

I put some mileage on my VIC-20, letting it run a battery of tests overnight.
Didn't want to leave it running for so long, but VIC insisted.
It's also only 58 degrees in the basement, so it ran nice and cool.

Since the success of this project depends on communication from the VIC-20 to the Expansion System, it was vital to know that my timing was going to hold up. I wrote a program loop that clears the screen, writes some pixels, reads them back, and then does some 16 x 16 math to check the results. The program was still running correctly this morning. Win!

It's kind of ironic that using such a fast FPGA made talking to the vic more challenging than simply bolting down some SRAM on the expansion port. Timing between the 40MHz FPGA and 1.02MHz VIC was very critical.

I could have also included CR/W and PH2 in my design, but I know with proper timing, it would be possible to get away with only using IO2, VR/W, Address (0-7), and Data (0-7).

I "qualify" my data by waiting for IO2 to drop, and then start a timer that waits until all expansion port signals are ready. This is a value I worked out by testing FPGA clock cycles between 0 and 20. Since there are about 39 FPGA clock cycles for every VIC-20 6502 cycle, I knew there would be a magic "read now" time after IO2 has dropped. I found that magic value to be Cycle 18 of 40 on the FPGA. This is almost ner the end of the VIC cycle. That was what I expected when I started trials.

Here is the small bit of Verilog Code inside the FPGA that grabs the Address and Data from the Expansion Port at the optimal time...


This routine also makes sure that a command completes before a new one can begin.
Rather than using interrupts to hold back the VIC-20, I let it poll the "Command Register".
When the Command Register is zero, the FPGA is ready to accept a new command.

Reading from the FPGA is much easier, as the VIC-20 knows when it expects data to be ready.
Since the FPGA is 39 times faster than the VIC, the data is always ready.

Sending data from the FPGA to the VIC-20 is just a matter of...


The code above just checks the status of IO2 and VR/W then spits out the current running Command number back to the VIC so that it can tell what the FPGA is doing before issuing another command.
If IO2 is low (active), and VR/W is high (read), then the FPGA sends data to the Data Bus.
Since the VIC-20 controls the Data Bus direction directly, data will always be valid on time.

Here is a shot of the small corner of my basement now dedicated to VIC-20 research...



It's always fun to see where people do their hacking.
As you can see... I am a die hard Commodore Fan Boy!

And some good reading...




Next few hours in the lab, I will begin coding up some kind of demo to test the functions I have written.
Until then, Holiday Greets to all Retro Freaks!

Radical Brad

I'm not surprised that you have a copy of the Cheap Video Cookbook. I've had my eye on that one for a while. At some point I'll get hold of a copy.

It's a great read for sure.

It's a funny story how I ended up with an original copy.
After a lot of video generation experimentation using AVRs, I tried some of my bit banged video using a 6502. It was actually quite easy to get a 6502 to generate video on the fly. I did both VGA and NTSC (with some extra gates for chroma delays).

I posted some of this on another forum, and someone mentioned that the same technique was mentioned in that book, so I just had to seek one out and add it to my collection. An yes, Mr. Lancaster used the same technique I did, but he did it decades earlier!

There is a lot of other great info in that book as well.

Brad

lance.ewing wrote:I'm not surprised that you have a copy of the Cheap Video Cookbook. I've had my eye on that one for a while. At some point I'll get hold of a copy.

The Holiday madness ended an hour ago, so I retired to my lab to continue testing the new GPU Commands.
Everything was ticking along perfectly until my Dell 2007FPb monitor failed. Cheap power switch!

Now I am dead in the water, as it was my only NTSC display.
Funny how new technology failed me, but I have never had a failure with my VIC, C64, or PET 4016!
In fact, I plugged in my 4016 an hour ago to show my guests what a real computer looked like.

I will now spend days prying apart the monitor to get at the power switch.
No doubt, I will have to dismantle it to the board level, which should prove to be fun.

Wish I had access to a nice 1084 monitor instead.
Oh well, until I get this working, I will continue with some wiring cleanup/

Later,
Brad