Hello,

I am just working on the Sound Engine now, and so far it's coming along nicely.
I also added Text using the C64 character set.

This may sound strange, but I have decided to make the schematics and BIT files freely available, but do not plan on releasing my HDL source.
I will however, but adding a COMPLETE tutorial on how to get started on this kind of thing and how to carve out a working FPGA project.
Code examples will be presented in segments, showing how it all works, for example; VGA generation, 6502 Interface, SRAM interfacing, etc.

My reasons...
- I want "Fusion-6502" to be all about the 6502, and NOT the FPGA. The FPGA is just a black box chip-set to do video and sound.
- My methods of coding Verilog are so far beyond the accepted standards that I simply don't want the drama. And there would be a LOT!

Some of my own personal HDL rules...
- Never use simulations, debuggers, or test-benches. Ever.
- Never use modules. All code is on one SINGLE @always edge block only.
- Never us IP, cores, or pre-made code. All code is made 100% from scratch.
- Never learn from others code examples. Datasheets vs trial and error only.
- All values in code are represented as decimal. No HEX, Octal, or Binary.
- Designs to be stable without requiring an external reset. Use of "Initial Begin" required.
- Define all states, and never waste a bit.

My design rules work extremely well personally, but would get you fired professionally!
Just sayin'... hackers like myself are not generally welcome in most FPGA / HDL forums.
If you intend to work professionally or collaborate, then it would be better to follow standards.

Last time I shared some HDL, I had all the experts in such a tizzy that the thread exploded for 2 weeks describing possible reason why my project would fail to ever work, and why everything I did was completely ridiculous. By the time the storm subdued, I was already into V3 of my board and code, which by the way is now used in a commercial touch screen product!

Anyhow, I will certainly put a lot of effort into teaching what I have learned about graphics and Verilog when I have the chance, but it will be more of a step by step tutorial on VGA basics, SRAM interfacing, and getting speed out of an FPGA design. My LucidScience site is in dire need of a complete redo, as all my projects are dated, and this will be one of the new ones.

From here on, I will be focusing on this project with the 6502 in mind, as the FPGA is nothing more than a powerslave.

Brad

Yep, I'll confirm that does sound strange to me. I've been doodling on a music project for a while (on paper - logic design instead of sudoku) and I've thought about using VHDL to document the thing as it comes into focus with actual hardware. Not so much for design as for being able to remember what is hooked up to what once there's more than a few ICs.

Seemed like a good idea since you were doing video. Then you had to go and start a sound project, so now I have to do it, and preferably make it better too. Or at least different. :-)


I have to admit this argument makes perfect sense. People can get worked up over seemingly trivial things like coding style.

Besides, Jack Tramiel would flail me if I gave away the source code for the latest 6502 based project!
... shhhh... I hear footsteps coming down the hall.
... the smell of cigar smoke... best get back to work!

Obviously, I am a bit of a Commodore fan boy!...



Brad

In order to keep the Vulcan-74 thread on topic, I have started a new thread for my spin-off project, Fusion-6502...

http://forum.6502.org/viewtopic.php?f=4&t=4258

When the deep freeze returns, I will come back to this project.

Brad

SYS 64738...

REBOOT!

Winter is creeping in fast now, so within a week or two I shall be back to working in my basement lab on Vulcan-74.

The Fusion-6502 project has allowed me to tune up my 6502 coding skills quite nicely, and I have a very deep understanding of the timing requirements of the 6502, and where it can be pushed.

When I left off, I had started a new version of the huge breadboard project to take the form of a retro synthesizer. This project will still happen, but I realize that it will be a work in progress for several years. In order to get back into rapid development, I am going to allow that project to continue on its own, and reboot Vulcan-74 in its original "Game System" form.

Recently, I had the chance to try out some ideas on the breadboard, and managed to take the Graphic System to a level that I would have though completely impossible, considering it is all made from 74 Logic components. Here are the new specs I hope to achieve with Vulcan-74 Reloaded...

- 100% driven by only a 6502 running at 8Mhz.
- 640 x 480 VGA followed exactly to the published specification.
- 12 bit Video Bus to display true 4096 colors (all at once).
- Double speed Sprite System capable of 10 million pixels per second!
- 16 bit addition, subtraction, and 8x8 multiplication on-board.
- Uses any keyboard by directly connecting to the matrix.
- Built in 6502 assembler at the press of a button.
- Support for any external storage device for use as a "cartridge"

Now these may seem like impossible goals for a breadboard using ONLY 7400 logic and a 6502, but most of these functions have already been tested on the board over the last few months. The increase form 256 colors to 4096 colors was really just a matter of doubling up all the graphics SRAMs (dual 8 bit SRAMs with the address line tied together to create a single 512k x 16 bit SRAM) to go from 8 bits to 12 bits. Actually, the SRAMs are now 16 bit, but I decided that the DAC would be best as 12 bits setup as 4x4x4 (4 bits red, 4 bits green, 4 bits blue).

The "spare" 4 bits are utilized to speed up the Sprite Generator!

The original Sprite Generator used a 688 comparator to check for the alpha (invisible) color, as well as where the X and Y counters needed to wrap. This was the bottleneck in the original design, as the path through the comparator and inverter added about 20ns of propagation.

Now the Sprite Generator will use the spare bits in the Graphics Memory to determine alpha color as well as the wrapping points. To achieve this, my Sprite Maker software will just use the bits as flags...

Bit 12 : Alpha Color not to be drawn to the Back Buffer.
Bit 13 : Wrap the X counter when drawing a Sprite.
Bit 14 : End of Sprite Data. Signal the 6502.
Bit 15 : Not used yet. Will probably be for Sound Data EOF Flag

So instead of checking for these conditions with a comparator, the bit will be connected directly to the function.
I have not tested this yet, but I am figuring that 10MHz should be achievable!
If this works, I will wrap the Playfield system right in with the Sprite system and double the memory.

Here is something interesting to note...

Vulcan-74, even made with nothing but 7400 logic, will outperform Fusion-6502 by a large margin, even though it is made form the most state of the art components I could find. In fact, it would be almost impossible to recreate my breadboard in an FPGA as it has so many dedicated address and bus lines. An FPGA with something like 400+ available IO and a boat-load of slices would be needed. Such an FPGA would probably cost more than all of my 7400 chips and all of the boards put together!

As for the "built in assembler" part, this is also exactly what it claims.
Since I am now going to support a real keyboard, I plan to do all coding right on the system.
The Assembler will actually be more of an Operating System, and it will be stored on ROM (most likely flash).
One press of the "System" button, and the OS will be loaded into the 64k program memory.
At that point, an IDE similar to the Kowalski Assembler will be presented to the user.
Load and save functions will be available to support whatever external memory device is mounted.

Vulcan-74 : 6502 Game System and Game Development System!

OK, so those are my goals for this winter's deep freeze.
I have recently ripped up every last wire and chip, so I am truly starting over now.

.... bring it on!

Radical Brad

Wow, it was 18 degrees out here yesterday, and will be even warmer today, so my weekend is going to yard work.
I did take an hour to rip up 90% of the two breadboards for my Vulcan-74 Reboot.
The only thing I left was the original VGA Frame Generator, which has been reconfigured to 640 x 480 timing...


This circuit generates both Sync Pulses, and the Blanking Periods.

Being made of self contained modules, each section of the circuitry is able to run independently.
So, the VGA Monitor still thinks it's getting a valid signal, even with only this section remaining...


With a valid Horizontal and Vertical Sync, the monitor is happy to display a blank picture.

The original Vulcan-74 design called for 400 x 300 resolution, but I found a way to get 640 x 480.
This pushes the breadboard timing about as far as I believe it can go, which calls for the maximum propagation delay to be under 40 nanoseconds through any path. To make this magic happen, I have made several changes to how the VGA Generator works.

Originally, there were four 590 counters driving both the comparators and frame memory. Two counters were used for X (400 pixels) and two for Y (300 lines). To switch between the dual buffers, the counters were fed through dual banks of 74HC574s, cross-wired to act as a large address switch. The VGA Generator had one bank, while the GPU had the other.

in order to meet the insane 40ns maximum delay, I had to remove the address switch and come up with another alternative.
Interestingly, the result was a much cleaner pathway, and one less IC required.

instead of switching the counters through the buffers, I just used the OE lines on the 590 counters, and added 8 more of them!
So now the VGA Frame Generator has its own X/Y counters, and so does each of the Video Buffers.
Sound confusing?? here is how it works...

VGA Frame Generator : X/Y counters always running, and driving the comparators directly.
VGA Buffer One : X/Y counters enabled while GPU has control of Buffer Two.
VGA Buffer Two : Input Buffers enabled while X/Y counters have control of Buffer One.
Buffer Switch : Invert the state of Buffer One and Two during the next Blanking Period.

All counters share a single reset line for X/Y wrap, so they are always in sync.
A schematic will show this when i have time to make one up.

So here is what I am starting (again) with...


Getting ready to insert the Dual Buffer Memory into the design.

Notice that I now require four 512K 10ns SRAM chips for the VGA Generator.
Since 1024 x 480 x 2 x 2 requires 1,966,080 bytes, I need 2 megs of RAM for dual buffers.

Explanation of 1024 x 480 x 2 x 2...

Since the X/Y counters are bit based, to count to 640, that requires 10 bits, which is actually 1024 bytes.
So the SRAM is setup as 10 bits for X and 9 bits for Y.
Because I am now sending 12 bit color with 4 special bits, I need double the SRAM for a 16 bit data bus.

I plan to connect this all up and then stuff a 640 x 480 image with 4096 colors into the Memory using an AVR for testing.
If the image is clean and stable, I will proceed with the rest of the design.
This is really going to push the realm of the breadboards to a new level if it works.
The "slowest" signal that will be used will be 25.175Mhz in this design!

Photos and a video of the first image test coming soon.

Cheers,
Radical Brad

Intriguing and impressive! But how is it feasible to implement multiplication with 74-series IC's? It would have to be an iterative operation, right? Otherwise the chip count would be prohibitive. You'd need an eight-input adder. Hmmm....

Sounds like that worked out well, then. Nice when a roadblock morphs into a shortcut! But here's a reminder for next time:

You mentioned how tri-state outputs can be bussed together to perform a switch (ie, multiplexer) function. And of course another option is to use an actual multiplexer such as 74HC257. Remember that nowadays you can get 257's (and other multiplexers) that feature a propagation delay that's virtually zero, such as 74CBT3257. They use transmission gates to directly connect the selected input to the output, almost like the contacts of an electromechanical relay. Sometimes these are just the trick you need when the timing budget gets tight!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I assume a 64kB memory is involved.

Um... This is Brad we're talking about.

_________________
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?

Indeed... I do not fear chip count!

Actually, I am using SRAM lookup tables for the math.
The address bus is split into dual 8 bit input values, and then set in parallel to another SRAM.
The result is a 16 bit output. Actually, the same deal as my Graphics Memories now.

I will be able to store addition, subtraction, multiplication, and sine in a single SRAM.

For more info on using lookup tables like this, check our Garth's excellent tutorial and report here..

http://wilsonminesco.com/16bitMathTables/

Brad

Real-time decompression!

Yep, you read the correctly. Vulcan-74 now does image decompression in real-time using 7400 logic.
Using some X/Y wrapping trickery and the extra 4 bits, I managed to get Sprite decompression.

Typical gains for single sprites are between 5% and 25%, and for sprite sequences it ranges between 25% and 50%!
A 50% compression ratio is really good, and this method is completely lossless.

I will post the details as soon as I get the new 4096 color VGA generator documented and tuned.
What can be done with basic logic gates continues to amaze me each time I make a mod and flip the ON switch!

Brad

Real-time decompression for sprites, that's pretty amazing.
Looking forward to watching the progress of this project.

;---

Now just my two cents on math:

Since screen resolution is bigger than 256*256, question is if an 8*8Bit multiplication will do in the long run.
16*16 Bit multiplication can be done by using a 128kLongwords lookup table and a polynomial trick from The Fridge.

Started to remember the 80C517, which had a peripheral function block labeled MDU (Multiply Divide Unit),
the sequence in which the registers were written triggered a specific operation.
Siemens 80C517 manual, page 128.
Would be nice to have something like that in the zero page.

Functions like 16 Bit min(a,b) and max(a,b) also might be useful...
maybe for things that are supposed to stay in a certain area of the screen.

The compression is actually very basic, and almost a side-effect of the new alpha control system.

When I decided to use one of the spare bits to wrap the X-Source counter, I realized that it could be used to wrap the X counter early if what remains was only alpha pixels.

And since most Sprites have a large number of alpha pixels around the center (think of a ball in a square), then wrapping at the end of the last visible pixel simply saves that number of useless pixel clock cycles. In a series of animated Sprites (like the checker balls), this is a significant savings.

I have had no lab time, but much time to consider the new re-design, and have made a few more design goals...

There will be only a single HUGE graphics memory, and the function of Sprite Generator and Playfield Generator will now combine.
This will now be called simply "The Graphics Memory", and it will be a whopping 4 Megabytes in size (512K x 8).
I know... 4MB??? that ain't even the size of a two word PDF file, but in this case, it is a goodly amount of memory!

I also intend to address this memory in an X/Y fasion, having 11 bits for X and Y. The result will be a massive 2048 x 2048 bitmap.
Sprites and scrolling screens will just be address as blocks of memory.

Still hoping for a speed increase as well, perhaps 10MHz pixel bandwidth.

Can't wait until I get another free day to try out some ideas.

Brad

Sometimes being away from the hands-on part of a project is good, as it offers time to really consider all options.
I have added one more goal to the redesign, which should start next week when the snow drives me indoors again.

Might as well go all the way.... 24 Bit Color!

This might sound far-fetched for a logic based VGA Generator, but all I really have to do is add afew more ICs (SRAM and 7400 logic) and a bunch of resistors in order to achieve a display capable of 16,777,216 colors.

Instead of doubling up all of the graphics memory to get 12 bit color, I am instead going to have 8 bits internally feeding a 24 bit Palette lookup SRAM. The Palette memory will be three fast SRAMs with their first 8 address lines tied together to produce a 24 bit wide, 256 Byte SRAM. Being SRAM, the Palette will be fully programmable by the 6502 so that 256 colors from a palette of 16 million can be displayed at once.

There are several reasons this is better than using a 12 bit (4096 colors) palette all the way around internally...

- Graphics memory usage is cut in half. So 8 SRAMs becomes 4MB rather than only 2MB.
- Palette can be made uniform for color swapping. 16 sets of 16 colors, 8 sets of 32, etc.
- Antialiasing will be much better with 16 million available colors.
- Single pixel operations from the 6502 will be many times faster.

For the triple SRAM Palette Generator, I may even be able to get away with some 32K 15ns DIP SRAMs I have sitting around.
I will have to add 2 more levels to the output pipeline, but that has no effect on the VGA generator, which is 3 levels deep already.

Ok, that's it for my features list until I wire this all up to see if it's going to work.
My next report will include photos of messy wiring and screenshots of the results.

Cheers!
Radical Brad