Hoping for a few hours to work on the project this weekend... time will tell!

After the great success of the Sprite Generator, I decided to increase the power a little more, and will be adding a new level to the GPU.

The new subsystem will be called "The Playfield Generator".

This system will also have its own independent 20 bit address bus and 1024k of 10ns SRAM.
The purpose of the Playfield Generator is to overlay a full 400x300 screen onto the backbuffer at high speed.
Since the address bus will be split into 10 bits for X and 10 bits for Y, this allows for a massive 1024x1024 bitmap to be stored.
This bitmap will be able to offset anywhere in the XY field, so it will also become a giant scrollable game screen.

The idea here is to pre-compute the giant bitmap in the 1024x1024 playfield SRAM, and then tell the GPU where to draw it on the backbuffer.
This will greatly speed up game logic, as the CPU won't have to spend time drawing the game screen, or resort to wimpy tile mapping!

So the game logic will go something like this...

1) Predraw a giant 1024x1024 game screen in the Playfield memory.
2) Main game loop start.
3) Tell the GPU where to draw the Playfield on the Backbuffer, offsetting X & Y form 0 to 1023.
3) Tell the GPU where to draw the sprites from the Sprite Memory to the Backbuffer.
4) Do some game logic, scores, movement, etc.
5) Tell the GPU to flip the Backbuffers (this happens on the next VSync).
6) Go back to the main game loop and do it all again.

Originally, I was just going to add a "Fast Clear" subsystem to wipe the backbuffer, and then let the GPU draw the background, but since the Sprite Processor is setup to deal with transparent pixels, this is not needed for a background image, and it also means slower pixel processing. Simply blasting an image from one memory to the backbuffer can probably happen at 20MHz, so that will be my goal for the Playfield Generator.

If this works, then Vulcan-74 will have some serious juice!

Imagine a 6502 being able to scroll a 1024x1024 bitmap image with 256 colors while at the same time moving 50 giant sprites around the 400x300 screen.
It will do this and barely have to work hard at it thanks to the $25.00 worth of logic chips I now have on the board.
Ironically, the cost of silicon is still less than using an FPGA! An FPGA needs several regulators, a config memory, and glue logic.

Also funny... I am running out of breadboard space!
With most of the chips for the Playfield Generator placed, I have only one column of 6 breadboards left... just enough room for the 6502 and decode logic.
I guess I will have to tie in my old cookie-sheet breadboard to test the Sound Generator logic.
I should have made this breadboard twice the size (about the size of a coffee table).

Ok, off to jam another batch of 200+ wires.

Radical Brad

Took today off, and so far things are looking good for Vulcan-74.
With the counter section of the new Playfield Generator working, screen clearing is now done in hardware.
This saves the AVR more than 500,000 cycles, and speeds up the system by 60% or more!!

Vulcan-74 can now generate double the number of sprites!


You can never have a large enough breadboard!

The new chips added to the board are in the lower right corner.
The lowest row is the X/Y counters that generate the 400x300 addressing to the back buffer.
The row above that is another dedicated megabyte of SRAM that will hold the giant 1024x1024 Playfield Screen.

Currently, only the counters are wired, so the Playfied is just a single color (hard wired to blue for testing).
Setting the single color effectively clears the screen to blue at the start of a new frame.


40MHz on a breadboard? Damn right it can be done!

Did I mention that the Playfield Generator is clocked at 40MHz?!
Yes indeed, 40MHz through that mess of new white wiring I have not even cleaned up yet!
It ran at 50MHz as well, but I will be lowering the clock back to 20MHz once the SRAM is connected.

Since the final goal of the Playfield Generator is to send a scrollable 1024x1024 bitmap to the back buffer, I will be lowering the clock back to 20MHz to deal with the propagation from the chained counters to the Playfield SRAM aand then through the 28 bit bus switch. I may try it at 40MHz just to see if a "two in the pipe" mode might work here.


25 huge rotationg sprites bouncing around the screen.

Seeing 25 huge (80x80) sprites fly around the screen at 60 frames per second was very impressive!
I can't wait to see the same amount of power with the addition of a 256 color background image scrolling as well.

My poor AVR now has only 1 free pin out of the 32 available, so I may have to start adding the multiplexing hardware.
The 6502 will be even more of a challenge to connect up to the system since it isn't nearly as flexible as an AVR when it comes to IO.

The next step will be to connect the Playfield memory and see if my giant scrollable 1024x1024 bitmap idea works.
From there I will start working on the 6502 part of the logic, as the AVR will have done its job.
The last part of the project will be another 80+ chips to make the 4 voice digital sound generator.

Here is a quick video showing the current system working...



https://www.youtube.com/watch?v=VDsEUw1m-bo


Ok... back to breaking all the rules of bread-boarding, I have another dozen chips to connect!

Cheers!
Radical Brad

Quick question Brad - how are you doing the sprite animation? That is, the rotation of the balls. Do you have a selection of sprite images to map, or do you update the sprite from the MPU, or perhaps some colour palette cycling trick?

The animation is just stored frames.
I decided early on that this system would have a huge amount of storage space for game graphics, making it much faster.

Sprite memory is 1024K and the new PLayfield memory is also 1024K.
The sound generator will also have 1024K.
The 6502 will have its own dedicated 64K (I may bank switch and increase this).

In this simple ball test, there are 16 ball sprites, each 80x80 in size.
This only takes 102K out of the 1024K Sprite Memory (10%).

The other interesting thing about my final design is that all 4 dedicated memories will be boot loaded from a cartridge.
This way, the game will start as soon as the unit is powered on.
Logic will be built in to boot load the entire 3,211,264 bytes from a serial EEPROM on startup.
So a game "Cartridge" will be nothing but a cheap 4MB serial memory (perhaps FPGA config PROM).

Here is the code that generates the Ball Demo from an AVR-1284...



The C program calls simple ASM routines I wrote that twiddle bits in the Vulcan logic.

Soon this will all be under 6502 control!
I am working out the IO decoding now, since IO lines are growing in number.

Brad

Thanks - I like the cartridge idea!

Thanks, just need to decide how the "Loader will work.
The 2 options I have on the drawing board...

1) Pure logic - loads the memories and then gives the 6502 control.
2) Software - 6502 does the read from cart and stuffs the memory.

Option 2 needs less logic, but will require some support routines, like a "kernal".
I like option 1 better, since it will be more challenging to implement!
Looking at the SPI memories, it seems you can just issue the command E8h, then read non stop.
I could have the logic fire out the value of 232 through a shift-reg, and then clock the next 4MB in.
The logic would send the serialized data as bytes to the appropriate SRAMs on the board.
Sounds easy enough, no?

I guess it will depend on how much effort it is to make logic to read whatever EEPROM I chose.
SD would probably be too difficult, but 2 wire serial may be ok.
I want the cheapest 4MB memory I can find, something like the Atmel serial data flash looks nice.
Speed is not important, as loading only happens on power up.

Brad

I have decided to add some of the IO logic to the board now that I have run out of IO pins on the test AVR.
Using this simple IO logic, the 6502 will be able to toggle 64 single bit IO lines, just enough to control the subsystems...


IO Mapping from the 6502 to the Vulcan Systems.

Since the only thing connected to the 6502 will be a 10ns 64K SRAM, this decode logic will not interfere.
All communication through these 64 IO bits will be as writes, so 64 bits will be lost (shadowed) in SRAM.

The decoder is simple, it just looks for a hi byte through the 688, and then splits nibbles to sets of 138 decoders.
This way, I can map any 256 IO lines to any segment. The 6502 just thinks it's writing as usual.

I will test this with the AVR, and then drop the 6502 in for a sanity check soon.


Here are the utilization of these 64 bits (expandable to 256 bits) so far...



Brad

Hi again, Brad. Just a reminder to include Phase2 as one of the inputs to your decoder array. Maybe this is implicit in your drawing. To avoid glitches, the decoders must activate only when Phase2 is high.

Also, an interesting thought struck me. Instead of eight 1-of-8 decoders (74HC138) you could use four 1-of-16 decoders (74HC154). This would:

• save space (the '154 is available in .3" DIP, in stock at Mouser)
• reduce the number of interconnections
• avoid heavy capacitive loading on the CPU address lines (ie; the address lines drive the input capacitance of four decoders, not eight), and
• leave you with four decoder-enable inputs to drive instead of eight

The latter point means the "master" 74hc138 (the one on the left) can be eliminated. This gets slightly gnarly. Instead you would have four CPU address lines (A3-A0 in your diagram), each of which attaches directly to the enable input of one of the '154s. I admit the idea seems odd, but there's no downside. If you write to an address for which A3-A0 are $0E, only one '154 will activate -- and likewise with addresses for which A3-A0 are $0D, $0B and $07.

What's really radical is if you write to an address for which A3-A0 are other than $0E, $0D, $0C or $07. In that case multiple '154s will activate simultaneously. It's possible this quirk could be used to advantage, for smaller and faster output routines. I bet there are lots of cases where the software will need to issue multiple pulses.

cheers,
Jeff

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

I like the 4-16 idea, thanks!
Might just have a few of those around.
It does save 16ns to have only the single MUX connected.

Cheers!
Brad

Memory recall... I just remembered why I did not use 154's in my last design.
Digikey no longer has them in DIP, and I received and end of life notice on them last year.

It was a good thought though, but have to keep to my "redily available" parts source rule.

Brad

It's your decision, of course, but aren't you being rather cautious? The '154 has been around for decades, made by multiple sources. It's not "game over" if one manufacturer does the EOL thing. Also I just had a memory recall of my own. On a breadboard the .3" DIP package isn't really a space saver, so you can just as easily use the .6" DIP. This increases your buying options drastically. As for the .3" HC device, 50% of all the suppliers I checked (two ) do presently have it in stock.

Yes and no. Even if you opt for the original idea (two-tier decoding) you still want Phase2 to be part of the qualification -- and Phase2 will be the last signal to go true. So, feed Phase2 to all the second-tier decoders but not to the top tier (the "master").

[Edit: remove reference to 74F154]

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

Yeah, I am being my usual crazy self!

I actually intend to do a 400-500 page E-Book on this completed system and start a dedicated website for it that will include source codes, PCB files, a forum, and parts sources. I will probably even run some boards. If I can't plug the part in Mouser, Digikey, or any of the large suppliers and find multiple suppliers, then the part is off my list.

The exception is of course, the 65C02 with only WDC as the source, but you can't beat their track record for being reliable!

I am sticking to my goals as per the first post, or this project gets canned.
I do not allow myself room for compromise when I take on a crazy project like this!

Currently produced DIP parts only.
Readily available from multiple sources.
No expensive support tools required (ie ROM programmer).
Anyone with similar insanity can make one.

All of the parts I have chosen are in current production, and have multiple suppliers such as NXP, Philips, Fairchild, etc.
By using the most common logic, like 574, 163, 688, etc, I have no fear of any end of life for those.

I want to build something wonderful that I can enjoy for a long time, and replicate or repair for decades without scouring EBay.
Perhaps there will be enough later interest (once the support site is up) to make a run of PCBs.
Like all of my projects on LucidScience.com and AtomicZombie.com, the goal is to give to the community, not make $$$ from the work.

I like the way Dennis Kuschel did "MyCPU", and the supporting documentation and site... this is the end game I am after.

Brad

Fair enough. And if you anticipate other people building their own Vulcans then it especially makes sense.

BTW -- if anyone's interested, the 74HC4514 is another one-of-sixteen decoder. I see the DIP versions are being phased out (as with the '154), but the prospect is much better for SOIC and other surface-mount versions.

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

Zoinks Scoob, Vulcan-74 just received Performance upgrade due to a previous wiring error!

After some rough calculations, I realized that the Playfield Generator was not drawing the entire screen as fast as originally calculated.
Looking over the logic, I found the Y-comparator (688) was set to wrap at 12,000 pixels too many.
Although this did nothing but draw beyond the screen, it did cause a delay in the Ready Flag coming from the GPU.

The result of moving the 3 wrong wires... a 30% gain in Sprite drawing performance!
Nice to have that happen since I was already happy with the speed!

I am now cleaning and testing all the small glue logic before it gets out of hand.
Before I move on, a few more components must be added to allow reading from the Back Buffer and Playfiled memory.
Currently, the CPU can only draw stuff, not read pixels, and although this would still allow for great games, it has some limitations.

For instance, I plan to write a Cannon Volley type game like "Scored Earth", and to generate a nice background with realistic looking trees and scenery, the game logic in the CPU would need to look at pixels to determine things like rock or tree placement on the rolling hills. Since the Playfield Memory is a HUGE bitmap, it would be unrealistic to store points in the CPU memory space rather than just peeking at the current drawing memory. For the Cannon game, the Playfield will be set to 2048x512 pixels for a massive horizontally scrolling background.

Oh yeah, forgot to mention that I made the 1024K Playfield Generator configurable on the fly.
The Playfield, can be scrolled in any direction, any number of pixels, and can be set to the following sizes...

Mode 0: 1024x1024 - Square or static Playfield
Mode 1: 2048x512 - Good for horizontal scrolling games
Mode 2 : 512x2048 - Good for vertical scrolling games

If I get time this weekend, I will post more videos showing the huge amount of performance increase since the last one.

Greets out to Hackaday... thanks for posting this project.

Radical Brad

To clarify a question raised on Hackaday - could you confirm that there are no sprite engines here, but there is a blitter, so the sprites you demonstrate would by some people be called Blitter Objects.

(In the case of a sprite engine, there'd be limits on sprite numbers, and there might be sprite collision detection in hardware.)