Yes, I agree.
In fact, I am ripping down the VGA Generator a bit to see if I can remove a few of the latches, so in reality... I am starting completely over!
My next post will be from a new thread.

When I do, can this one be locked with a final message to see the new thread for Chapter Two?

Thanks,
Brad

It's certainly helpful to leave a link in both of two related threads, to help people find one from the other. But we don't usually lock threads. It means, if someone has a question three years later, they have a good place to ask it.

True, but once I start the now one, I intend to not come back to the old one, and if the link is buried behind 20 unanswered questions, then the flow is lost.

Brad

Another friendly thing to do if there are two related threads is to edit the head post to out in a link.

I will just keep posting here until I have time to sort the 200+ photos and put some real schematics up on Vulcan74.com.

I redid most of the VGA Generator wiring today just to clean up the placement of a few components and get a break from weeding the greenhouse! At this point, I have only the bare-bones VGA Generator, which gives a clean 640x480 with 256 colors with dual Video Buffers. Each Buffer is a 512K SRAM, addressed as 10x9 bits for 640x480. Buffer switching happens automatically on the Vertical Sync so that the CPU can draw on the "Back Buffer" while the "Front Buffer" is drawn to the screen. The CPU is not aware of this, since it is all controlled by the Logic.

Before I bolt down my 6502 again, I am doing the Video Testing with an AVR, since it has plenty of room to store images.
When the 6502 takes over, all the User Interface images will be drawn programmatically.
There will be fonts and icons stored in the limited 32k ROM area, but most images will be computed.
3D buttons, gauges, sliders, and rendering of waveforms will all happen in code.

Here is the final test, showing that the Video Generator is working perfectly at 25.175MHz for a clean 640x480 display...


640x480 with 256 Colors... all done by 7400 Logic Chips!

Made a quick video as well...

https://youtu.be/Ad_75NOXblI

The only other part of Vulcan-74 that will involve Video is the new Blitter, which I will make next.
Since 640x480 is a lot of pixels to hurl 60 frames per second, the Blitter will offload the 6502 a lot.
I plan to use a 19 bit serial counter stream to read images from a dedicated 512K SRAM.
Images will be written to the Back Buffer at a specified destination as a block.
This is similar to my original system, but there will be no transparent pixels, so it is not a Sprite Engine.

If everything works as planned, I may get 10MHz or better out of the Blitter. The old one could do 6MHz.

After the AVR tests the Blitter, I will be switching to 6502 control for final Video Testing.
Once all Video Tests are passed, I will start the monumental task of laying out the 8 Sound Generator channels.

More to come when my next wave of chores are done.
Hope all these photos and mods aren't getting too boring!

Radical Brad

Wow, an impressive project. I haven't done any low level computer projects since the 70's and the S-100's, just controllers and things that plug into them or a computer port. I loved my Atari computers and the Amigas. I saw the Mycpu project and liked it, except the video, so I went looking around the net and found your project. Computers need a blitter. Would there be any chance of you posting a schematic of where the first project ended?

I understand your frustration. On a modern PC writing a bootable asm program is still a thing you can do, but you can't really access any of the newer functions of the hardware with out going through windows. Every thing seems that way. I dug out a bunch of my old S-100 projects and electronic projects to show my girlfriend last night. Stepper drivers and control switches, usless on a modern computer with only a usb and net port. My newest cnc uses an uno and stepper shield, with a usb going to a laptop. Guess that's why I would like to put together a 6502 (ish) system that can go places the Amiga couldn't. To many projects that are just plugging things together and not enough building. An "Atari 130XE" with more ram and video/audio that out preforms the Amiga, built of 74** chips would just be a cool project.

On your ram/rom programming thing. Not sure how well it would work on modern sram, but a trick we use to use, to not have to reprogram rom all the time and have a faster system, was to mount a two or three small batteries in a chip socket, wired to the power and ground pins, then you mount the ram on top of the socket. You put the socket in a system and program it, take it out and plug it in as a really fast rom in the target. Thanks!

Just wanted to drop in and throw out some greetings to the 6502 crowd!

Since my free time is sparse during the summer months, I have not had much time to work on my 6502 project, but today I gave myself a break from the homestead and did some hacking.

Today, I decided to revive the Video Game version of Vulcan-74, but made it "portable" so I could work on it when I am away for work on road trips.
Yeah, since I am often stuck for a day or two in some remote hotel, I wanted a project that would fit into a shoebox.

So the plan was to hack together an FPGA emulator version of the giant breadboard, and I managed to do it one one day!
Now this is cool since I am somewhat new to Verilog, but it does prove that knowing the hardware makes one into a better HDL coder.

The target is a Spartn-6 FPGA, and the "donor" board was once a Mojo-FPGA Board. I say donor because I hacked it all to hell.
I needed a meg of SRAM, so I dead-bugged a pair of 512K SRAMs to the board, and then replaced the oscillator with a 20MHz clock.
The FPGA is clocked at 40MHz, and does some real trickery when it comes to sharing the SRAM with 6502, Video, Sound, and GPU.

The 6502 thinks it is just connected to a super fast 64K SRAM, and the FPGA does all the boot load stuffing and IO magic.
I am also working on some SD Card code to load everything on startup, but for now it is all done via SB cable.

The FPGA version actually has more power than the breadboard version, since it is easy to add features in code.
Some of the extra features include...

- 4096 color programmable palette that can display 256 colors at once.
- Single cycle 32 bit math accessible by the 6502.
- Graphics functions such as line, box, circle, fill, and text (C64 Font) built in.
- Sprite rotations for every 90 degrees, including mirror image.
- Horizontal and Vertical image sheering for ultra fast Wolfenstien-like ray trace games.
- Built in math stuff like Sin, Cos, Collision Detection, etc.
- Polygon fill routine.

I also plan to emulate my unfinished Sound Engine, which will be like an 8 channel Amiga.

This quick hack turned out so well that I decided to give it an official title... "Fusion-6502".
It's basically a chipset for a real 6502! Sound graphics and IO from a single FPGA.

Ok, here is the obligatory eye candy....


This was once a MOJO Fpga board.

To gain the required 98 IO pins, I desoldered all of the onboard LEDs and made a new IO map.
I also ripped up the oscillator and added a new 20MHz version.
This is doubled internally by the PLL to meet the 40MHz timing for 800x600 VGA.


A pair of 512K 10ns SRAMs added.

Everything is shared by the 1 meg of onboard memory, arbitrated by the FPGA.
Zero page and IO live internally in code, but everything else is in SRAM.
Graphics Data, Sound Data, 6502 Code, and dual Video Buffers all take tuns!


6502 and Video DAC

The 6502 has no idea that it is connected to an FPGA!
I have tested the 6502 up to 8MHz, which is the "legal" top speed for 3.3v operation.
As you can see by the resulting videos, this is plenty fast to womp an Amiga for graphics power!

The Video DAC is 12 bits, for a total of 4096 colors. Only 256 are displayed at once.
To allow for more color control, the palette is fully programmable on the fly.


It's those damn checker balls again!!

Yeah, what can I say... I like watching those checker balls fly around the screen!
This time they are multi-colored thanks to the abilty to rotate the color palette on the fly.
I only have to store one 32 color ball sequence, and can rotate the dark panels 16 times.

These ar 80x80 sprites with 256 color depth, and one invisible "alpha" color.
Fusion-6502 can hurl over 30 of these around the screen at 60 frames per second!
For comparison "Boing" on the Amiga only did one ball, and it was only color cycled.

I started this project at 8:00am this morning, but did not complete the Sound System yet.
Not too bad for a day's work, and I will complete the Sound System on the next free rainy day!

Here is a video of it working...

https://youtu.be/CNVghL233FI

Anyone interested in a board for this project? It's a great platform to test 6502 assembly on!
I would probably provide it with everything minus the 65C02, which would drop into a DIP socket.

OK, back to my farm until the next rain or snow day.
Thanks again for this website!

Cheers,
Radical Brad

So glad to see a 6502 driving the GPU at last!

Good job mate ! , very impresive . I can't wait to put my hands on it .

Awesome! Don't suppose you could share your vhdl?

With regards to the oscillator, could you have used the clock wizard to derive your desired clock? these FPGAs have clock managers that can synthesize the required frequency from the input clock from what I understand.

Thanks for the comments!

Yeah, I have grown to enjoy 6502 assembly so much that I really just want a fun platform to code with.
For me, it has to be a real DIP 6502 as well. Not sure why, just seems "right" somehow!

Yes, I actually use the DCM to multiply the clock internally, but things do work out well with the 20MHz input clock.
The FPGA runs at 40MHz internally, and also feeds the 6502 up to 8MHz.

The 6502 is fully controlled and even single stepped at some points in order to optimize speed and SRAM sharing.
There is even some "caching" in the works so that the 6502 memory space is buffered while the GPU does its work.

So far, my 1024K SRAM arbitration works like this (based on a 31.5Khz line frequency of 1056 cycles)...

Cycles 000-399 : GPU captures 400 pixels from the active buffer into an internal block RAM. Live Video is drawn later.
Cycles 400-407 : GPU captures 8 sound samples from someplace in the 1MB SRAM (Multimedia memory).

Cycles above 408 are free for either the GPU to perform graphics commands or for the 6502 to read its program space.
When the 6502 requests a graphics command (like DrawSprite), its clock simply stops until the GPU is done.

IO (GPU communication) is mapped to location 512-767, and the GPU captures this address from the 6502.
Hardware stack and zero page is just kept in blockram for maximum speed.

So the 6502 simply runs as though it was connected directly to a 64K SRAM.
I am currently running it at a top end of 8MHz at 3.3v, but may install a level shifter and try for 20MHz.
The GPU is so damn fast at moving pixels though, that the 6502 isn't really working all that hard!

My Verilog code eh?
Well, I may share it, but I must first issue these warnings...

1) I am self taught by trial and error only. Running before I can walk is my preferred method of education, which is why my methods often follow no "recommended" rules, standards, or fads.

2) I never use simulations, debuggers, or test-benches. I write code and build hardware. When something fails, I fix it on the fly. I don't care what a simulator tells me what is possible or not possible.

3) I do not do any of this for a living or in a team environment. For that reason, my code will have sparse commenting, and I do not use modules in HDL. All of my HDL is one GIANT clocked "always" block. As insane as this may sound, I follow my own code with ease, and can get a lot done in a few hours. When I code in HDL, I think in terms of propagation, not program flow. Once you get into this mindset, it seems easy to just code hundreds of working lines in a hurry. At least, I find this to be true. For me, C is the slowest language to code in. Assembly is the quickest, followed by Verilog.

You have been warned!
In order to avoid total shock, I have attached a much smaller Verilog source for an NTSC version of one of my earlier projects. It has sprites and a few graphics commands, but gives you a glimpse into how an insane person may code Verilog. For the record, this took one weekend, and the final project worked perfectly.

http://lucidscience.com/temp/Lazarus-64.txt

If you are still wanting to see the Verilog code for this new project at some point, I will certainly post it, but it is MUCH MUCH longer and complex!
And yes, at 6000+ lines of Verilog, everything is still one top module, all clocked by a single "always" block.

The code posted above did this...

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

Cheers!
Brad

...a man after my own heart in that way! Simulators don't usually simulate the I/O anyway, and that's where it's needed most. I've tried Microchip's PIC simulator (MPSIM) which does simulate the I/O, but it's hopelessly slow for trying to examine and process outputs, and simulate inputs, especially interrupts which are asynchronous events. I found it pretty worthless, and developed the next several products with no simulator at all.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I only picked up an FPGA kit and CPLD last week so I'm still figuratively banging rocks together like a caveman trying to build a simple text based VGA output for my system.

Hoping to someday build something with sprite and blitting capabilities but I get the feeling that is a loooong way off for me

Especially when pushing silicon to its IO limits!
When I did a lot of work comparing AVR to PIC as video generators, I found some of the PICs to have "slow" transitioning IO, resulting in bleeding colors.
Actually, AVR is the top dog when it comes to IO speed it seems, even better than many ARMs.
The XMega gave me a reliable 34MHz IO bandwidth when overclocked to 68MHz. Up there with FPGA!

With HDL, FPGA and CPLD seems most are gonzo about doing these "Test Benches", which is basically code with no synthesis.
For the life of me, I cannot fathom the point. I mean, why write code without a target??? And if you have a target, why not just "run it and see"??

Just imagine all of the real world knowledge that has been wasted on simulation and jibber jabber on why something probably won't work!

It's not uncommon to search the web for a simple answer to a simple question and then realize you just wasted 2 hours reading a heated discussion by two experts on the merits of yellow paint vs green paint on tantalum filter capacitors. When your eyes start to glaze over as Wizard #2 defends his position by clarifying that yes indeed the cadmium sulphide mixture in yellow paint dye does have some ferrous properties, thus creating a small Faraday cage to help shield the capacitor's outer plates from electromagnetic radiation emanating from the overly noisy DC converters found in most modern compact florescent bulbs.

At this point I realized that I could have built another working circuit or coded another 100 lines of assembly!

Damn, where was I going with this?
Seems that I am now guilty of Shaving another Yak!

Brad

Hi Oneironaut ,
I would like to build one of those to play with it . Is there any chance to share the latest verilog and 6502 code with us ? .
Thank you .