6502.org

Relax; /VP is useless for the vast majority of designs. I'm a "feature creep" kind of guy myself -- have always been that way! -- and even I have trouble dreaming up a reason to use /VP! I suggest you simply leave that pin unconnected.


VDA (and, to a lesser extent, VPA) are more tangibly valuable.

VPA is always high when Program bytes -- actual opcodes and operands -- are fetched. VDA is always high when Data accesses (including stack, general memory and I/O) occur. VDA and VPA can be used to prevent rare but nasty problems involving two groups of I/O chips:

• chips not from the 65xx family, which may have problematic timing restrictions
• any chip which includes registers whose status gets altered when the register is read.

A common example of the latter is the Interrupt Flag Register, as found in the 6522 VIA. Reading the IFR causes its bits to get reset. It's built that way, in order to streamline interrupt service routines. If your computer doesn't include I/O chips from these groups then you can safely ignore VDA and VPA. [see note]

The potential problem has to do with "dead" or unused bus cycles which all 65xx CPU's occasionally produce. During an unused cycle, the address bus isn't necessarily valid and meaningful, which results in a risk that the dead cycle could read an I/O device. Luckily, the invalid addresses are predictable. Some workaround solutions involve a change in programming (for example, avoiding the use of indexed address modes to access I/O). Changes to the system memory map (ie, changing the address where I/O resides) can also help.

Those workaround fixes don't require the use of VDA or VPA. There are two other alternatives:

• If you ignore VPA but do use VDA to qualify I/O accesses then data accesses can touch I/O but dead cycles and operand accesses cannot. This simple solution is usually the most desirable. (The 6522 VIA is especially easy, as it has two Chip-Select inputs. Just run the address-decode signal to the VIA's active-low CS, and drive the active-high CS directly from VDA! )
• Somewhat slower and more complex is OR'ing together VDA and VPA, and using the result as the qualifying signal. I can only think of one reason you'd do this [can anyone else suggest reasons?], and that's when the plan is to use that signal to enable a decoder IC which is responsible for selecting both I/O and memory. It's the shared decoder that makes the OR gate necessary. The decoder needs to be active when code is fetched (from memory); therefore the qualifying signal must account for VPA.

Hope that helps! Cheers,

Jeff

Note: I don't have EEPROM experience, but it occurs to me that spurious reads may be an issue (reads may play a role in the programming procedure). Best to review the programming procedure with that in mind, and if necessary protect the EEPROM from spurious reads.

> Some workaround solutions involve a change in programming

I think this is the key: almost always the software can avoid having stray reads interfere with correct operation. It's true to say this is a potential gotcha for the writer of the lowest level software. But it's also true that millions of 6502 systems worked fine without the benefit of validating addresses. It's a little bit of added value that WDC put in, at the cost of a pin, but it's still not absolutely necessary to use it in most cases.

Sorry, this is a bit of a hobby horse of mine... it feels like one or people are forever advising that every design needs VPA and VDA, and I feel like I must make the counterpoint that it's optional, very optional, to do that. If WDC had never added these pins, we'd all have been fine.

Perhaps WDC had to add these signals to gain an (extra) level of security for critical systems - wasn't there some pacemakers based on a 6502?

Hmm, I think the pacemakers came much later, although I see what you mean about safety-critical designs.

I'm not saying WDC were wrong to add the signals - for one thing, the idea that the 6502 makes unexpected memory accesses might be seen as a misfeature, especially to someone used to read strobe and write strobe. The signals can be useful. But, I think, they are only needed in exceptional situations, and building them into a design which doesn't need them is added work. Suggesting that designs should use them even when they don't need them is raising the bar to adoption. In this case, the new signals are the misfeature.

The data sheet specifically suggests these can be used for dual cache and for cycle-steal DMA. I haven't heard if anyone actually ever did this though.

So, I think that I just realized I fried my brain last night by staying up way too long, and I don't need to use VPA to qualify IO access at all. I was using it in a 3 to 8 decoder that doesn't interact with memory at all, it only interacts with IO devices, somehow I was thinking about loading program data from an EEPROM as loading operands and opcodes which is not the case. I'd simply be loading bytes from an IO device into memory and setting the PC to point to the starting area.

This removes the need for the OR gate that fully qualifies using VPA and VDA. I should mention, what had me thinking about all of this was the circuit in the 28L92 documentation for full address qualification. I don't think that VPA is ever needed for an IO access, although I may be wrong.

So I can get rid of the quad or chip now. I'm going to look through and see if I can get rid of some other logic chips by reorganizing gate usage.

I'll probably see about integrating the RTC today, does anyone have ideas on integrating the one with the multiplexed data/address bus? I'd prefer to use it because it's an all in one package, although it plus the circuitry to integrate it may be more expensive than a chip that is SPI addressable but requires a battery and oscillator.

I'm still looking at the cartridge stuff too, hopefully with fresh eyes I'll be able to figure them out. I ended up reading about ZIF sockets last night (was related to the page on card edge connectors on wikipedia) I remember seeing someone talk about them here, should I opt for them? or are they a waste of space/money.

I plan to offer an I2C-6 RTC module using the Microchip MCP7940N. I don't expect you to wait for me to supply the module, but I think you'll be interested in the 8-pin RTC IC. It has an onboard oscillator (although the tiny 32kHz crystal is outboard), an alarm interrupt output, and the option to back it up with a hearing-aid battery (which apparently you don't need).
ZIF sockets are for when you want to be able to remove and re-insert an (E)EPROM many times for external programming. They're valuable for that, but I have never heard of anyone using one for something like game cartridges. The latter need to be pretty tough; but ICs with their delicate pins sticking out would get damaged much too easily, both mechanically and with static discharge.

I'd like to have the full RTC function (including backup) so I may look at that chip. I2C is fine, but since I've got a lot of SPI already on board, I may look for one that interfaces that way (I've not built an I2C interface on the board yet, but I probably should). As far as zif sockets go, I was talking for the ICs themselves, which it sounds like the only ones that I need to worry about are the eeprom chips that may be getting removed to be program elsewhere.

While I'm in limbo over the cartridge slot (Still haven't been able to figure out the "standard" on it or exactly how to design with them) I've been looking at the connections for the planned audio and video daughterboards. I'll probably just use pin headers, because that's easiest and won't require more cartridge slots. One thing I was thinking about doing is, including the composite output RCA jack, audio RCA out and 3.5mm out, on the motherboard, and wiring them to the pin headers. This way, I can have the motherboard mounted towards the edge of the case with all the sockets in one spot, and the board location of both the video and audio cards doesn't matter much (except for maintaining signal integrity).

On this note, I've been revisiting my plans for audio and video, with VLSI chips for both. The chips are very small, and I think I'd probably have to use a stencil and solder paste paired with an oven to actually solder them correctly, also, the VS1000 audio chip playes ogg files. This means I need some sort of file system on storage for my cartridges, which will carry audio data for games. This also means if I want any "standard" sounds that live on board I need a file system for them too. I could potentially just straight byte copy files onto the storage, and keep track of where they start and end, but that seems like a headache waiting to happen. I think this is one of the many "gotcha"s I'm going to run into with audio/video output. I'd almost rather look for a sound generation chip, but finding just the right ics is proving difficult (especially since I'd really prefer THT).

At any rate, all that matters is that I know what pins I need for the audio/video cards so I can make pin headers that have all the required pins. I'm thinking I may use some VIA pins to help ease integration. (I wired all via pins like the ones in your schematic for the simple computer, so they're expandable, and only one of them is actually doing anything right now (powering the display))

I just realized I left out the keyboard setup that I was going to do, so let me ask a couple questions about this.

I've been looking at Daryl Rictor's keyboard circuits, one using an attiny and the other using a VIA.

Will doing it on the VIA provide significant overhead for the CPU having to handle keyboard input?

Is the attiny worth including to help alleviate the previous issue?

I've only ever programmed Atmel chips through the arduino IDE, I know that there's another way to program them, would it be difficult or trivial to program the attiny with Daryl's code?

I've been staying away from micro controllers because I was hoping to handle all the hardware requirements with discrete chips dedicated to do the job that I'm trying to do, but if it's really just the easiest way to handle keyboard input, I don't think it will be so bad.

I've always liked the idea of off-loading IO processing from the main CPU to give it more time to do other tasks. It's been a long time since I wrote the VIA keyboard code, so this may be less than accurate. If I recall, the CPU is in charge of clocking the keyboard, so it does not need to be super quick to respond to a key press. However, if you wait too long, you will miss keystrokes. The processing overhead is not great... but if you have a lot of software-driven peripherals, I think you'll see a slowdown in your system.

I still offer programming service for the devices in my projects for free, so if you feel uneasy or don't want to bother with setting up a programmer, then just send me you chip(s) and return postage and I'll program them up for you. I've coded and programmed several custom Lattice 22V10's for others also. I cannot program the Atmel 22V10's, but if you can get Lattice parts, I should be able to do those. I can also do 5V Xilinx 95xx CPLD's and many ATMega chips as well.

Good luck with your project!

Daryl

Thanks for the info.

So far, I only have 1 software driven perihperal, the character LCD, all other peripherals are either memory mapped and can handle some of their on function (like the DUART) or are behind a 65SPI (garth is sending me 2 of them, I'll only be using one on this board though). Honestly, I'm thinking about setting up a keyboard interface on a VIA (possibly adding a 3rd via) to get me going and then later I may be able to make a daughterboard that does it with the attiny. I would probably set up a programmer myself for the attiny because I really do want to learn every aspect of this, but I'll keep in mind your programming service.

If I set it up on the VIA, I can always change to the attiny later, whereas if I set it up on the attiny now, I'm adding complexity and cost that I can potentially avoid. Hopefully, the overhead added by the VIA keyboard control is not too great.

For the cartridge I've settled on this one that has 16 pins total, which should be more than enough for the cartridges I want to do. Since many PCB fabs will probably get upset about having pads right on the edge of a board, I've been thinking that I may make the cartridges myself with my CNC, since their boards are bound to be way less complex than the computer board. The one issue is the contacts won't be gold plated, but I don't think it will cause a huge problem.

If I get it up and running well, I may make some documentation on it, and make some standardization for it for the community in case someone else wants to use cartridge slots for one thing or another. The cartridge slots I linked are through hole, and look very easy to solder, so I think they're a good choice (they also have plenty of documentation and drawings).

In the mid 1990's I did a few boards where the copper ground plane came right to the edge of the board, meaning they had to mill on the copper; but they didn't mind. And if they did, they could have easily added a small margin at the edge in the gerber files; but they never did. Later I started adding a margin of .005" to .015" between the copper ground plane and the edge of the board. I also keep the edges of pads at least .010"-.015" from the edge of the board. They certainly don't mind board-edge connectors either.

My previous statement was based on experience with OSHPark iirc. I may be misremembering, but I think they run DRC on uploaded files, and they don't want pads too close to the edge, it may've been an entirely different issue though, I've not had a board made with them in over a year.

On an unrelated note, I think I've about tied everything together (except the RTC, still working on that part) and I'm about to get started on layout. I'm checking over the processor pins once more to make sure I've not missed anything and I have a few questions.

Can I use E output (emulation mode) to drive a small LED to show if it's in 6502 or 65816 mode?

Do I need to hold the ABORT pin high? is there a good use for this pin?

I assume ML\ VP\ and MX can be left floated since they're outputs, right?

Sure. Put a resistor in series to control the current.
Yes, hold it high. It is an active-low input. The data sheet is not super clear; but ABORT\ seems to be intended to take care of cases where you accidentally address an area of the memory map that has nothing installed. Maybe you can generate an error message and ask the user what he wants to do, rather than crashing.
Yes.