Good news, the 6502 has now passed the 24 hour 10MHz marathon.
To pass this test, the 6502 had to continually fill the entire 400x300 screen with pixels, drawing them the slow way (one at a time directly).
Every pixel is then read back and verified for color value. After that, the 6502 draws a scrolling PlayField and then flips the Video Buffers.
If anything goes wrong with RW timing, then the system would lock up.
I started running the test program Sunday, and it was still working this morning.

I have also verified that the 6502 will run stable at 20Mhz using my 2 gate RW-CLK circuit.
The Boot Loading hardware does not affect performance as it goes invisible once the 6502 is taken out of reset.

Where I may have issues beyond 10MHz is the reading of registers on the Vulcan Video Board.
My IO system decodes IO lines at address 512, using a series of 74HC138's triggered by a 74HC688.
For writing to IO, 20MHz works fine, but during a read, the additional propagation of 16ns will put my timing out of the safety zone.

I am considering adding a 74HC74 that will hold the 6502 clock back a cycle when it encounters a read sequence.
Since reads only account for maybe 1 out of 100 cycles, this would still allow me to claim 20MHz operation.

I will post a few IO schematics soon, and continue testing to figure out how far I can push up the 6502 clock.
My goal is not to exceed what should work properly, but I do intend to stand at the very edge of the cliff.

I am very much enjoying coding in 6502 Assembly, and the Kowalski Assembler feels good so far!
6502 Assembly feels native to me now, as it is so similar to AVR Assembly. No learning curve.
http://www.exifpro.com/utils.html

With the Visual Basic conversion program, I just save the Binary Image from the Assembler, press convert, and then press the "Program" button on AVR Studio. Within 10 seconds, Vulcan-74 then loads the 6502 Program memory and I see the results on the screen.

Once I get the 6502 clock speed set to the maximum, I will do some coding, and show the full extent of what a 6502 is capable of when it commands a Video Game System comprised of nothing but 7400 Logic and a few SRAMs.

Even at 40 years of age, the 6502 can still kick some ass!

Cheers!
Radical Brad

Perhaps this would be the time to consider making a switch from 74HC to 74AC logic. Dunno if that is in keeping with the ground rules you set for this project, but if it is, you will substantially reduce prop delays through your gates, especially the 74HC138s, which are inherently slow devices.

Also, as a reminder, the most recent version of the Kowalski simulator can be gotten at http://www.exifpro.com/downloads/6502_1.2.12.zip.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I did grapple with the AC logic at the beginning, but found that many devices are either hard to find, single sourced, or SMD only.
For this reason, I decided that the extreme power of the GPU would offset any reduction in 6502 speed (if required).
To be honest, even running the 6502 at 4MHz here (ack!), Vulcan-74 can make an Amiga look like a turtle.

This is also the reason I will not use a VIA or any other custom IC with a single source.
The 65C02 is the exception of course, since the entire goal of this project was to give it a deserving home!
Everything on the entire board with the exception of the SOJ package SRAM is only 74HC readily available DIP Logic.
Being eccentric (crazy, off-the-wall, wonky, etc), when I set rules at the beginning of a project like this, they are set in stone.
This project would have been scrapped instantly if any goal could not have been met. I am glad I am past that point now!

I am not doing all that bad with the 74HC138's so far. I have actually exploited the propagation delay through the 74HC688 that decodes the high address bits so that the IO chain (10 x 74HC138) is not "fired" until after the entire 16 bit address and 8 bits of data sent from the 6502 have stabilized. Because of this, and the fact that the next address read from the 6502 will be program memory, RW is not needed in the equation. After toggling an IO, the following program memory read flips the bit back up as the 688 comparator lets go.

With an IO read cycle hold-back hack, I expect to reach between 16MHz and 20MHz using only HC logic.
If this fails, I will register the output with a 74HC574, and allow it to propagate as the 6502 chews on the next program memory read....

6502 : "Hey Vulcan, here is an IO request, but I don't think you can fulfill it before my next read cycle"
Vulcan : "Dude, don't worry about me, you just keep on readin' and I will be ready next time you need me"!
6502 : "OK Bro, here it is; trip the Page Flip Bit at address 567, and swap out those video buffers".

I will show this in more detail soon, with some schematics and videos to back up my outlandish claims!

Ps,
I have been enjoying your projects Dino... great source of inspiration and information!
Keep it coming!

Cheers!
Radical Brad

I still think switching to AC logic (on a breadboard) would cause a lot more problems than it would solve.

I don't know whether Brad considers advanced HC logic (AHC) within his ground rules, but it would be a much safer choice on a breadboard. I have a feeling he'll exceed most of our expectations while keeping it 100% old-fashioned HC logic anyway.

The rules for parts on this project are simple...
If I can't it in 3 major online suppliers (in stock) like Digikey, Mouser, Allied, etc, then they are off the list.
Currently, the 65C02 is the only single sourced component, but I trust Mr. Mencsh for future supply!

Brad

The only DIP available was non-stock.
It was worse with the other parts I looked for a while back.

http://www.digikey.ca/product-search/en?vendor=0&keywords=74ac138&stock=1

No problem, I made HC logic work up to 32MHz in the rest of the board!
The magic bullet is 74HC574... just latch it up when you exceed your propagation delay limits!

Pixel Bit : "I don't think I can run all that way in that short amount of time!"

Vulcan-74 : "No problem dude, take a break at the next 574 station before the gate closes, and then run to the finish line when it reopens. Just make sure you get there before the guy running behind you!"

Brad

You referred to a 74AC138, not a 74AHC138.

Digikey has the 74AHC138 in stock: http://www.digikey.com/product-search/en?lang=en&site=us&vendor=0&WT.z_cid=ref_findchips0311_dkc_buynow&mpart=SN74AHC138N

So do many other major suppliers, for that matter.

Nothing wrong with doing it 100% in HC logic if you want, but according to the rules you stated, the 74AHC138 is admissible. Then again, maybe you just enjoy adding pipeline stages to the design?

P.S. There is a HUGE difference between the 74AHC familly and the 74AC family. The 74AC family is a nightmare to use on breadboard because of switching transients. The 74AHC works fine, and may even be cleaner than 74HC while at the same time being considerably faster (slew rates on the 74AHC family are slower than on the 74HC family).

WDC seems to be just as committed to the VIA as to the 65c02 (even though the '02 is the focus of the business), so I think the VIA is just as stable, and a safe bet.

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

Thanks for the comments!

For me, using a VIA had no attraction for several reasons....

- Not counting the 6502,it would be the only custom IC on my board.
- I need 80 IO lines, so that would add up to 5 VIAs.
- Price for 5 VIAs = $40.00 / Price for my IO logic = $3.25.
- Like ROM chips, they seem klunky when there are other options.
- It was much more fun do do the same thing with all logic.
- My all logic solution is most likely much faster.

I guess it's kind of like the 65C816... I just couldn't get into using it, even though it would have been a lot easier in this project.

At this point, I am totally satisfied with the hardware, and being able to claim that it is 100% commonly available HC logic is a bonus.
And yes indeed... it is way more fun to do it the hard way even though much easier solutions are available.
This may sound odd (sad? scary? banal?), but I actually had ALL of the ICs used so far on hand in my parts trays!!
I don't have any AHC floured chips though, only plan HC chips. I do have some Barbequed chips from previous work!

If I hit a performance brick wall for some reason, I will certainly consider the AHC as a possible solution, so thanks for the advice!
Getting a solid 10MHz out of the 6502 right now, and will try reaching 16MHz this weekend.
I want to get more 6502 code tested before I mess with the hardware though!
Currently converting all of the routines to 6502 assembly for some real testing.

Say, does the Kowalski MacroAssembler have the ability to #Include a file?

Cheers!
Radical Brad

That's the only one I can argue with, if you're comparing to discrete logic. The VIA

• allows data-direction control of individual bits
• can do open-drain outputs, like for I2C
• can do automatic handshaking, like for parallel-printer interfacing
• has two timer/counters with several modes of operation
• has a shift register with seven modes of operation
• lets you enable or disable individual interrupt sources within the VIA

Its name really is quite appropriate. The circuit potpourri section of the 6502 primer has a lot of applications for it.

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

At this stage, I like that option better than using AHC logic, and I would certainly defend your claim.

I agree on that. The only device currently being produced by WDC that probably shouldn't be considered for a from-scratch design is the 65C21. That device seems to exist only to give retrofitters a viable path from the 6520 or the Motorola equivalent.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes. The syntax is:

Code:

.include "path\to\file"

For example, from my POC firmware source code:

Code:

.include "include\calendrics\atomic.asm"

If a relative path is specified, as I did in my example, it is relative to the subdirectory from which the file that is doing the INCLUDEing has been loaded. Like all Kowalski assembler pseudo-ops, INCLUDE is not case-sensitive.

Incidentally, when you save a new source file it is saved with .65s appended to the filename, unless you specify differently when you save the file, such as atomic.asm.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for the info.
Must not like something about the filename, because I have yet to make it include a file.
Included file is just a NOP for testing purposes. Path is correct. Statement is .INCLUDE "Vulcan-74.65s"



Thanks,
Brad