Yes, but with the Kestrel, you could easily create an EEPROM programmer off of your VIA. You could use the same IPL circuit to program an EEPROM. EPROM would not be much harder, other than having a switch to change to programming voltage.

In fact, if we use the three chip memory scheme from my previous post, you could also place an EEPROM in the second RAM socket and burn it quite easily. I have the code already built into my SBC monitor. Other's could do that too.


This is the glory of my suggestion.... depending upon the make-up of the daughter board, you can do it many ways.... again, the daughter board designer will be responsible for providing the necessary driver routines.

For my text video, pc keyboard, I would have PA be the output for the video, and PB the input for the keyboard. I would use the C1 & C2 handshake line for both.

However, if multiple daughter boards are used, then I can see where some structure would be needed. Purhaps restricting the system to one daughter board is a better (read simpler) idea.

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

umm, modern EEPROMs program themselves generating all the voltages
on chip, you just write them more or less like static ram. (writing eeprom
takes longer of course and I think they only program a block at a time
even if they allow you to change just one byte)

You're right about using a 65c02 rather than a 65c816 - keep it simple at first, leave the fancy stuff for V2. And Garth, I'm sorry if I offended you with my flippant remark about blinkenlights.

One thing I would like to ask is that you guys explain the design decisions you make. Stuff that may seem trivial or obvious to an old hand may very well be complete news to us newbs. Case in point: I cheerfully started designing my SBC a few weeks ago, but I'm currently completely bogged down trying to make timing diagrams fit (getting the diagrams of more than 2 or 3 chips to line up, after factoring in propagation delays, is a lot like playing tetris!) and trying to wrap my head around transmission line theory so that I can calculate the proper values for the bus terminating resistors I'll need to add. I thought googling would help my design, but all it shows me is how unprepared I am. PLEASE, do a small write up saying things like "because the traces here are less than 5 inches long, we can get away with not using bus termination" or "In a sub-5MHz design like this one, we don't need to worry about propagation delays if we use HCT parts" or "don't EVER do this even though it looks easier"

With all the "You just need XYZ" to program EEPROMs, I've found an awful lot of "conditions" to go with them. Those conditions are precisely what I wanted to avoid. The IPL circuitry works universally with RAM. I don't have to worry about write cycles either. For supporting EEPROMs, it'd be a bit more complex perhaps, but not much. For EPROMs, complexity increases significantly due to changing voltages.

However, one thing remains consistent -- the need to drive the device with a specific protocol. And, I believe, depending on the manufacturer of the (E)EPROM, you also must take ROM protocol into consideration too (e.g., programming whole blocks, etc). I understand many devices have pretty stringent timing requirements for programming.

Well, there really isn't much to explain outside of basic math. Let's look at the microprocessor's timing diagrams. When Phi2 goes low, the processor can put the address of the next cycle on the address bus no sooner than 10ns later. If we're working with a 4MHz part, that means that, the rest of the circuitry has only 105ns to respond to that address. Why 105ns?

* With 4MHz, the total CPU access cycle is 250ns. Each half-cycle is, therefore, 125ns.
* The CPU updates the address bus no earlier than 10ns; that leaves us with 115ns.
* A peripheral may require, say, 10ns of setup time before phi2 goes high for proper operation. Therefore, that leaves us with 105ns.

What this is telling us is that your address decoder has to have a propegation delay of 105 ns or less to function correctly. If it does not satisfy this design criteria, the odds of it working out for you are negligable.

Note that during phi2 high, we don't really care about anything, since the magic that occurs during this phase is internal to the peripheral or to the CPU. But some parts must be gated externally (e.g., parts designed for the Intel bus standard, for example, including asynchronous RAMs). Here, the same kind of math applies, but in a different sense. If you RAM has a 70ns access time, for example, you must make sure that your CPU's phi2 high period never falls below 70ns. This implies a 140ns total period maximum, or put another way, about 7MHz. You must also consider propegation delays of the gating logic as well (usually 5ns for the 74ACT00 NAND gate).

And that's the magic, really. It's all just ordinary accounting.

The other thing to consider is this: although these parts are usually used in sub-10MHz speeds, they generate such fast signal transitions that you must design your circuit as if they were running at at least 20MHz. This means, of course, keeping signal lengths as short as possible, and use plenty of filter capacitors. I did find, however, using too many filter capacitors in the Kestrel 1 resulted in substantial increase in operating noise, and therefore, flakey operation. How did I narrow the circuit down to a good operating condition? How do I know what chips to put the caps next to, and which ones to skip? Good old fashioned elbow grease: Add some caps, test, remove some caps, test. Whatever seems to work best, continue in that direction until you can't go any further. Studying the "Taguchi Method" on engineering quality control methods would be helpful in understanding the thought process a bit more, but the gist is simple: "hack away", but record your results and be scientific in your work. Or play, as the case may be. Choose the best middle ground.

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

@kc5tja

Thank you, that's the sort of thing I'm talking about. So from your description I guess that you start out by drawing up the circuit diagram, assuming that all parts are "perfect" (0ns propagation delay, etc); next you fill in the "real" parameters on the parts that you have no control over and then you go outwards from there, trace by trace, adjusting values until every trace has a (min ns;max ns) annotation and you can pick the remaining parts based on that? There's a software algorithm for calculating optimal flow in pipes that's sortof like that. It definitely sounds easier than juggling a bunch of timing diagrams with arrows going all over the place, which is what I was doing. Even a simple change to the circuit diagram resulted in having to erase and redraw a bunch of arrows linking raising edges on one chip's timing diagrams to falling edges on another's, what a nightmare!


@GARTHWILSON

Thank you! that laser printer toner thing does look somewhat intriguing. I'll read the remaining notes tomorrow.

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

Oops, I read the wrong post (the one below yours, that talks about using a laser printer to prepare blank PCBs for etching). I've had a looong day

When I started with my SBC-1, I did not have a programmer. I designed a parallel port programmer, on a solderless breadboard, using four 74LS373's to program 32kx8 EEPROM's. What I've found is that some EEPROM's come with the software write protect enabled. I wrote a routine to unlock it (unlock and lock protocol was in the chip's data sheet). After that, I just wrote an address, read it back and waited for the data read to match the data written (polling method). It worked flawlessly... and I based my SBC-2 EEPROM programmer on that same design. I've burned several 32kx8's from various makers using the same code. I bought a EPROM UV eraser long ago but never tried to build a programmer, mostly because I didn't want deal with the variable voltage requirements.

In any case, I now have an EPROM/EEPROM programmer and can help burn the initial ROM's as well as the GAL16V8 for decoding (if we decide to use it). As long as those ROM's contain code to load programs into RAM (via X-modem, text, or Intel-Hex, or other methods) , the whole "built-in EEPROM programmer" becomes icing for those who want it.

If the majority decides the IPL method is better, I'm good with that too.

Daryl

I can set up a wiki on my personal website in lieu of 6502.org. The wiki will be authenticated, so you'll need to log in to write new content. But anyone would be able to read it.

This way, anyone who has signed up for an account may freely contribute content.

I will assume perfect gates only if evaluating different overall designs. For example, for the Kestrel-2, I'm assuming 0ns propegation delays, because I'm going to be using an FPGA to implement it. However, in the real world, there will still be propegation delays -- I just don't have any knowledge of how much.

I will also assume a perfect address decoder when evaluating address layouts from a programming perspective as well. Of course, software ultimately won't care one way or the other, but some address layouts makes coding easier than others. Consider the case where, for example, you access a graphics framebuffer via a dedicated I/O register (a la Texas Instruments 9918A VDP chip) or directly in RAM (a la Commodore's VIC series of chips). They both have equivalent bandwidths from a raw I/O performance point of view. But when it comes to updating the framebuffer, you must fundamentally use different algorithms. Having direct access to RAM allows random-access to the frame buffer. Using the I/O port technique requires a more strip-based blitting algorithm. These make different things easier (the random-access approach is great for games; the strip-based approach is great for GUIs).

However, as a rule, I assume 4.5ns of propegation delay for each piece of external logic I add, based on experience from playing with ACT-logic.



This is overly complex. When designing a circuit, you almost never need to concern yourself with minimum timings. The only time you do is when (A) you can afford products that don't work a certain percentage of the time, and (B) you are *really* strapped for performance, and no other products fulfill your needs. This is the kind of stuff NASA runs into. It's generally not the kind of stuff that we run into. If the 6502/65816 doesn't meet your timing requirements, maybe a 68000 or 8086 would be more useful, assuming you can still find these parts.

However, what goes on during phi2 low is definitely the critical factor determining not only the circuit architecture, but also the maximum speed of the processor. The only factor influencing things when phi2 is high is device access times.

One thing that you learn very quickly, and it really helps to have some background in algebra here, is to parallelize as much as possible.

For example, _RD and _WR signals, which need to be generated to talk to Intel-bus I/O chips and RAM (_RD is _OE and _WR is _WE; same logic, different names). These signals don't have to be generated in response to an address decoder. Hence, it can be generated in parallel with the RAM or I/O chip's _CS signal. Quite often, this allows you to "swallow" its propegation delays inside the delays of some other piece of the address decoder. Indeed, most decoders have 3 or 4 layers of logic in my experience. So the 2 layers (worst-case) of logic for generating _RD and _WR is insignificant.

The reason I said that it helps to have algebra experience is because of how precision in notation can be beneficial. You've no doubt seen things like this in algebra texts before:



We know that i(x) will rely on f, g, and h(x) as well. That's not really the most important part. Look beyond algebraic definitions, and instead concentrate on the algebra itself.

Consider that i(x) depends on the evaluation of g, h, and f. It doesn't matter which one comes first; all it cares about is that f(2x), g(x), and h(x) have results. Then, and only then, can i(x) produce a meaningful result of its own.

In other words, algebraic definitions are combinatorial, just like logic circuits. And what that means is, you should look out for dependencies.

If f(x) makes no reference to g(x) or h(x), then it's clear that f(x) must be able to be evaluated completely in parallel with the other two functions.

If, for example, g(x) is defined in terms of h(x), then it's clear that the output of h(x) is needed before g(x); a circuit path from h to g is required.

The goal, therefore, is to try and identify what the Haskell programmers call "supercombinators" -- a fancy word for as many inherently parallelizable pieces of code as you can possibly find. By identifying and isolating each "super-combinator," you can really cut down on your logic processing time!

And this is where the term "layer of logic" comes from. If you've identified all the possible supercombinators for a given logic function and implemented them so they all run in parallel, you'll still find that you'll have other functions left over, which do depend on those values. So, repeat the process again, until you finally have your results.

Taking this to extremes, and assuming you have access to a semiconductor fabrication plant (;)), you'll find that three layers are the minimum: AND, OR, INVERT, though not necessarily in that order. And, if you look at programmable logic chips, you'll see that that's precisely how they're implemented. Lots of ANDs, ORs, and inverters, composed in discrete layers of logic.



Sometimes this is necessary, especially for particularly tricky circuits. However, in a fully synchronous design like what the 6502/65816 puts out, it's rarely needed.

I might like to add that this is one of the reasons why fully synchronous logic is the method of choice for implementing FPGA logic. EVERYTHING is based on "the clock," which makes circuit design much simpler, and allows timing analysis of the simulators. If everything were asynchronous, the level of circuit complexity goes up substantially. While the latter offers potentially much faster circuitry, the fact that simulating it and analyzing the timings is essentially an NP-complete problem has forced a lot of developers to shy away from it.



Yeah. Use the period of the clock signal as your guide. Treat those clock transitions as fence walls that are impenetrable. Of course, in the "real world," it's not necessarily true. But from a beginner's standpoint, and indeed most advanced applications too, it's essentially true that everything is synchronized against the clock. It just makes so many things that much simpler.

You mentioned programming PALs this way as well. How is this done? It's always bothered me that I could never find the low-level details needed to program one of these things.

With regards to EEPROM, the IPL method is absolutely not suitable for use with the Kestrel-2. It's just too complex of a circuit design, and I do rely on DMA of peripherals for their proper operation. Hence, I'll be needing an EEPROM.

I will definitely research EEPROM programmability for the Kestrel-2 design.

@kc5tja



OK, now I know I'm doing something wrong, because I can't seem to find more than a handful of devices that have compatible timings with these CPUs. For example, for my initial design, I was going to use a 65C816 with 32KB RAM (to get the new opcodes but not have to deal with the multiplexed bank byte) and I thought it would be neat to have a graphic LCD for a display, so I got the datasheets for a 320x240 intelligent module from www.crystalfontz.com (http://www.crystalfontz.com/products/320240cx/CFAG320240CX-TFH-T_v1.1.pdf). However, when I looked at the timing diagrams in the datasheet, even the module's "6800 mode" (using phi2 as E) cannot be used with a 65C816 because if I run the '816 in 1MHz which is required to meet one timing parameter (the minumum time E can be high is 500ns) then the maximum hold times are too small (it requires between 2-55ns hold when reading, and at 1MHz the 816's setup and hold times at 1MHz would be, extrapolating from the datasheet, 80ns). The only solution in my mind to fix the problem was to add a state machine using flipflops or a CPLD, and I'm frankly not ready for that complexity yet. Considering that there's even a diagram in the datasheet showing the LCD controller connected directly to a 6800 and that the 6800 and 65xx families are supposed to be very similar, that doesn't seem right to me. I've encountered the same sort of problems with pretty much all non-65xx family chips I've looked at - I either need to run the CPU at a really low speed (sub MHz) or some parameters match but others don't. Judging from your comment above, I shouldn't be getting anywhere near hitting these sort of problems though. What am I doing wrong?