6502.org

Hi again! Sorry for the thread necromancy I've been busy lately... but at the bench, actually giving birth to my first (working) 6502 computer! I'll better open a new thread about my creation, but certainly I have learned a lot and I want to thank you all for your help!

Just for future reference of newcomers, I'd like to reply some unanswered questions:
Most respectable, indeed. However, I find the 65C22 quite convenient to use, even with its known quirks... About the 65C51, while certainly not the best ACIA/UART out there, I think it's able to perform decently as long as:

• No speeds over the "classic" ones (up to 19200 kb/s) are needed
• The CMOS version is used
• Some kind of interrupt-based receiving buffer is implemented
• The hardware handshake lines (RTS/CTS) are used

My (future) systems will include it, with all of those criteria met. I currently have a 65C51 driver stub for my growing OS (that's due another thread!), but that could be easily replaced when the time to use a better chip (say, 16C550) comes
You're right. Currently, I'm not using RDY and it goes to Vcc thru a 4K7 resistor. Next "scheduled" device will use an HC74 to generate the RDY signal when interfacing to some slow peripherals... not sure if that would be safe in case of an unexpected WAI instruction
An exception-like mechanism, still to be fully implemented... whenever an dangerous instruction (SEI, write directly to I/O addresses and/or system variables...) is executed outside kernel space, the offending process would be sweetly terminated - although (except for SEI) needs some extra logic to actually prevent it writing before NMI is acknowledged.

(That would be for the 65C02; I understand the 65C816 makes this much easier with its ABORT input, but I conceive my system as generic as possible)
AC certainly is. But as far as I know, ABT is a BiCMOS technology -- an hybrid between Bipolar and CMOS, with "considerable" static power consumption.

I aim to battery-powered systems with as low as possible power requirements... but I understand that there's always a tradeoff between speed and low-power design
I think AC will serve well, at least below 10 MHz.
I plan to do a similar thing, in order to (temporarily) disconnect some power hungry parts of the circuit when not needed. I had a hard time finding a suitable P-channel MOSFET with very low voltage drop...

Once again, many thanks to all for your help! Now, time to open a new thread to introduce my system

All the best,

No need to apologize. You did it the right way. If you had started another thread, we would have to refer back to this one anyway to re-establish the background and see where we had come from, ie, what had been discussed before.
I have not shopped for can oscillators in years, but I remember them being pretty power-hungry. One 65c02 design I did for a commercial product usually took less than 2mA for the entire computer. It ran on battery power, and putting a can oscillator in there would have been a killer.
Quirks? It has one bug (serial port shifting in under control of an external clock), and nothing I would call a quirk.
You can go at least six times that fast-- just not with the 1.8432MHz crystal being used to get the baud rate. I've used an 500kHz 65c22 PB7 output (automatically generated from a free-running T1), run into the RxC input (pin 5 of the DIP) to get the 31.25kbps for MIDI input and output on the 65c51. The bit rate will be 1/16 of the RxC input clock.
I've also used it without RTS & CTS, in situations where there was no danger of overruns.
Thanks to Ed for this link for buying wire-wrap PLCC sockets:
http://uk.rs-online.com/web/c/?searchTe ... ra=oss&r=t

You'll want to drive both directions with interrupts and use a transmit FIFO as well as a receive one.

• Pedantic computer science note: the data structures you would use with a UART are actually FIFOs, not buffers. I know: picky, picky.

For short data bursts, a fully interrupt-driven scheme reduces the tendency for the foreground program to stall during transmission when the UART is on a slow link—the UART will only demand service when the transmitter is ready to accept a byte (you'd set a flag in this case if the transmit FIFO is empty so you can restart the transmit IRQ after the next byte is loaded). This model is very easy to implement and requires on average no more than 256 bytes for each FIFO. You may be able to get away with smaller FIFOs if you want (I use 128 bytes in my POC unit and it'll run at 115.2Kbps CBAT on both channels), provided your receive interrupt service routine performs well.

Generally speaking, I consider the 6551 a lame design due to its programming model (some control features are merged in a clumsy way) and its lack of an on-chip FIFO, something that is a feature in almost all modern UART designs, such as the 16550/16560 and 2692A/2698. The presence of an on-chip FIFO can do a lot to prevent receive overruns when the host system is real busy or has less than ideal interrupt latency. Garth's interrupt primer discusses an interrupt-driven serial I/O scheme. Although it only talks about the receive side, the transmit side works in a similar fashion.

• NOTE: In the interrupt primer, code such as LDA #00011110B would be written as LDA #%00011110 using WDC official syntax.

You can isolate the output of the 'AC74 flop (not 'HC74—probably not fast enough for a 10 MHz system in which wait-states are to be implemented) from RDY with a Schottky diode, with the anode of the diode connected to RDY. If RDY goes low due to a WAI instruction the diode will be reverse-biased and the '816 will not try to sink the output of the flop. Better that the 4.7K resistor be 3.3K (it's required due to the diode). Also, the connection from the diode to RDY should be as short and direct as possible.


I don't want to rain on your parade, but it's unlikely that you could implement the required logic using discrete devices and achieve sufficiently fast operation to actually stop a memory or I/O access from occurring.

What you are trying to accomplish in the case of the 'C02 is something like what the '816's abort interrupt does. Despite the name, an abort interrupt doesn't actually abort the instruction. However, when asserted, the '816's ABORTB input does behave somewhat like an NMI, but pushes the address of the aborted instruction instead of PB and PC, and inhibits any changes to registers or memory, which would prevent an illegal access on memory or I/O. Even with the '816's ABORTB input it takes additional—and very fast—logic to determine if an illegal access has been attempted, key word being attempted.

There are two steps to this process: detection of illegal opcodes (BTW, how do you plan to deal with STP?) and detection of improper addresses. The first comes during the opcode fetch cycle, indicated with SYNC on the 'C02 and VDA & VPA on the '816. That's the easy part.

The second part isn't quite as simple. The '816 provides a distinct signal for that purpose: VDA—the expression VDA & !VPA indicates that the effective read/write address is on the bus. No such equivalent exists with the 'C02.


My POC unit was designed with 74AC logic and is stable at 12.5 MHz without the SCSI host adapter and would be operable at 15 MHz or higher if it weren't for that pesky I/O stuff getting in the way. Bus loading forces a speed reduction to 10 MHz with the host adapter installed. The next iteration will use 74ABT bus drivers...in my case, power consumption will take a back seat to performance.

Edit: read/write address was rear/write address.

The thriftiest ones I found were 1 MHz, half-size, about 4 mA, which is one third of the entire computer's power consumption... another third went on a diode-based logic gate
But then you lose the flexibility of software-selected baud rate, unless some extra circuitry is added... incidentally, the 115200 kb/s usual on "modern" PCs is exactly 1/16 of 1.8432 MHz.
At the more-or-less standard speed of 9600 b/s, one character takes roughly 1 ms to transmit. If there's a human being typing on a keyboard what is transmitted, you'll surely do well without RTC/CTS... and even without FIFO!

IIRC, MS-DOS recommended not disabling interrupts for longer than 1 ms, which fits well the above scenary.
However, I think those pins are like the pin-header ones, of square section... it seems they won't fit a breadboard (at least, not mine)

Pedantic notes are welcome and encouraged FIFO is certainly the name I chose for the corresponding kernel functions...

I'm not fond of diodes on digital lines I designed an OR logic gate around a couple of diodes plus a 1 K resistor (trying to get it as fast as possible), everything tightly connected... it drew of course "a lot" of power (4 mA), but high-to-low transitions (this was OR with pull-down resistor, the opposite you mention) were painfully slow: a whopping 100 nS And I think RDY would be much more sensitive to a sluggish low-to-high transition (when a pull-up resistor is used) than, say, IRQ\ – which has quite a few cycles to settle.

Anyway... my current 65C02's in DIP-40 are GTE and Rockwell, thus no WAI instruction

The key here is that I won't prevent illegal accesses, but only illegal writes. Since such operations are qualified (typically by ø2), I've got some time for it I'm aware that some reads to peripheral devices may be dengerous (like clearing interrupts, etc) but they're usually harmless...

Can't tell for sure because I haven't build this circuit yet, but... a picture is worth a thousand words: The only specific signals here are:

• KERNEL\ is active (low) when the current address is in kernel space -- can't really talk about user/supervisor modes on a 6502. Instructions fetched when this signal is active, have no restrictions at all.
• PROT\ is active (low) when the current address is in protected space -- maybe I/O devices, system variables of whatever zone must be protected from direct user alterations.

Both signals may be easily derived from the address decoding logic. This circuit generates two internal signals (SEI\ and WD\, more on them later) but the rest is regular 6502 stuff.

First of all, for each fetched instruction it's decided whether it has full privileges or not -- by latching the state of KERNEL\. Clocking the flip-flop by SYNC alone won't work, because this one changes more-or-less at the same time as the address lines, and KERNEL\ derives from these -- after the delay from decoding logic. Thus, SYNC is gated thru ø2, when all addresses and decoding are expected to be stable.

Whenever an instruction in user space is fetched, the protection devices get enabled... for the illegal instructions, it may be as simple as a '688 comparator: one side of it goes to the data bus, the other is hardwired to the desired "illegal" opcode -- for instance, $78 for SEI, which would ruin preemptive multi-tasking if accidentally executed. However, as soon as this comparator is enabled, data may not be correct: that's only guaranteed a bit before the end of the cycle. That's why I put another flip-flop at the comparator's output, getting updated by ø1 -- in other words, when ø2 goes down; data will be hold a slight time after that, more with propagation delays.

The "problem" with this second FF, is that the NMI will be triggered just at the beginning of the following cycle, being acknowledged after that second instruction ends... but that's not much of an issue, because the process will be throw off anyway -- or that should do the NMI task! The AND gate before this second FF allows for several NMI sources to be latched this way; some other "illegal" opcodes (WAI, STP...) could be detected as well with more '688s in parallel, each output to its corresponding AND input.

Then, the illegal write protection is actually simpler than expected! You can see, tinted green, the typical write-validation circuit... but instead of using the first NAND as a simple inverter, it's actually used to disable writes via the internal signal WD\. This signal comes from the OR gate, and goes active when all of the following is happening:

• The current instruction was outside kernel space
• The address being accessed is considered protected
• The CPU wants to write something

The first condition is indicated by the first flip-flop, possibly several cycles ago... the second one may be somewhat indefinite while the address lines are changing, but it'll definitely settle by the time ø2 goes up. The last one comes directly from CPU, and was stable even earlier.

While WD\ is asserted, no write operations into memory can take place, but the NMI must be issued. First I thought about the circuit in red, which blocks this NMI source until ø2 goes up (or ø1 goes down, actually). However, I think it isn't necessary: this WD\ could take one AND input (see dotted line) just like another illegal opcode, with the usual drawback... an extra instruction will be executed before the NMI is called, but this is rarely an issue.

Now that I think about it, this circuit prevents unauthorized writes to memory, but not to a I/O device like the 65C22... but it is possible to connect the VIA's CS2 line to WB\ for the same effect. Or maybe disabling the whole I/O decoding.

An interesting improvement to this circuit would be latching the cause of interruption: from the state of WD\, SEI\ or whatever opcode is protected. Then the NMI could check this protection device register and take appropiate measures, according to the "exception" origin This could even help with the STP instruction... yes, it certainly cannot be aborted and the computer will be halted. But after restarting, if the RESET routine looks for a 'STP interrupt' on the cause-register ASAP, it could just go straight to the NMI handler, instead of the usual (destructive) initialization. That would kill the offending process, resuming normal operation of the system after a few seconds of inactivity...

There's still some time to go, before I actually implement this -- both hardware and software. But I'm doing all this just for fun, and there's no need to put a brake to imagination... only time will tell how far can I go

You can use PB7 of a 6522, set to run off a free-running T1, all set up in software and then not requiring any further attention from the µP to keep it going, to get the higher rates. Admittedly, the granularity is poor at the faster rates.
A system that can't have an interrupt rate faster than 1ms is pretty lame though. In situations where I've had to live with it (mainly meaning in non-6502 systems), I slowed the data down to a rate that could be handled without overruns.
They fit in standard prototyping board that has the holes on .100" centers-- otherwise it wouldn't really be any good for wire-wrapping. I have some here, and grabbed a tiny scrap of cheap prototyping board to take these pictures:

For the 65c22's free-running T1 to put out a high enough frequency on PB7 to get the 115200bps on a '51 or the 2691 whose data sheet I was looking at for the '51 topic, the phase-2 rate would have to be at least 7.3728MHz (which is a standard crystal/oscillator frequency), with storing 0 in T1CL and T1CH. (I had to try it, since I was not sure if you could go all the way down to 0, or if that would stop the automatic toggling.) So with that clock speed, I get: So with the x16 RxC clock input, you still get all these data rates under software control with a '51 or a 2691, with no added circuitry, and the speeds are exact.

With my pedantic computer science hat on I would have said a circular or double ended queue (or deque) was an even better term for it.

If you want to be pedantic then FIFO is the way you access your buffer.
If you're not being pedantic then an FIFO is a buffer.

Hello, zuiko21, and (belated) welcome! Regarding your protection scheme for the 'C02, it's clear you have an imaginative approach to hardware design! The project you describe is one which will put your skills to the test.
A word of warning about SYNC. This pin is not 100% reliable as an indicator of what instruction is about to be executed. An exceptional circumstance arises when the CPU begins an interrupt sequence. SYNC will be high but the instruction being fetched will not execute. More details on that behavior are here, and (as part of a larger circuit) an XOR arrangement that detects the beginning of an interrupt sequence is here. Will the false SYNC be a potential problem for you? The interrupt sequence will try to push some stuff to stack and then jump via the interrupt vector. Your hardware must allow this (regardless of any protection associated with the instruction that was fetched and discarded).

As for opcodes such as SEI, there's an alternative to your approach of taking corrective action (via an NMI) after the deed is done. The alternative is to re-map SEI (and any other opcodes of interest) before they execute, and turn them into BRK instructions. There's a circuit for re-mapping instructions here. It leverages the power of programmable logic (as suggested by BigDumbDinosaur) but the device used is merely an EPROM. In your case you need to turn the re-mapping on and off, and that could be done with one of the unused address lines. The scheme is nice and simple but the access delay of the EPROM needs to be considered. (Unless the EPROM is a fast one, you may need to compensate with a slower CPU clock, faster RAM, or a wait state.)

cheers,
Jeff

ps- also relating to hardware that modifies 6502 instructions, you may be interested in Radar Controller hacks 6502 illegal instructions and the KimKlone: a Radical 6502 Redesign.

While they're great (and intended!) for wire-wrapping, I'm afraid they won't fit solderless breadboards, neither turned-pin sockets Pins are too thick for them!
Stardard frequencies exist for a reason.
Thanks for pointing this, I wasn't sure if zero was an OK value for T1 counters, either!
When the diode pulls the line down, like in the RDY-protecting circuit, the Shottky's low drop is essential, although it won't help with the RC time constant problem (but the short connection will). A heavily loaded CMOS output (because of the strong pull-up resistor required for speed) no longer goes down to the rails; if you add the 0.6 V from a regular silicon diode, the line could be over the 0.8 V limit of a guaranteed "low".

On the other hand, what I implemented was a "positive" OR gate (the so called "wired OR" for IRQ\ lines are actually wired AND) where the diodes pulled the line up over a 1K resistor. Even with that heavy load and forward drop of a 1N4148, voltage is pretty near 4 V, more than enough for a CMOS-compatible "high". And the low-to-high transitions were pretty quick, their 4 ns recovery time is not an issue at the intended speed (1 MHz)
Not a very nice thing, although it's just a performance issue that won't prevent "proper" device operation...
They do, that was standard back in the NMOS 6502 days... Even WDC's 65C02S have it (but its use deprecated), only was removed from the C816 (AFAIK)
They certainly aren't... I was thinking about memory reads, though. Anyway, my circuit (which still has a couple of issues thet I'll discuss later) could be easily modified to prevent illegal accesses (read or write) to protected addresses -- just remove the R/W line hitting the 3-input OR gate (now a 2-input gate).
Intel-style I/O chips (16550, 8255, 6445...) use RD\ and WR\ lines which should be qualified with ø2 anyway.

65xx-68xx style hardware has already a ø2 (aka Enable) input for that matter; however, since their R/W line cannot be qualified with ø2 (must be stable some time before) it's best to deselect them -- thru the 6522's CS2 line tied to my WD\, or simply disbling the I/O decoding (the originally intended protection) altogether. Since the CPU, unaware of my protection circuit, will write to the bus, the peripheral inteface can't just get it's R/W toggled to read, beacuse it will put its own data on the bus, causing contention.

Although SRAM is usually interfaced more like the Intel-style, the use of this circuit won't allow the simple design of tying OE\ to ground -- see bus contention issue above. Either the SRAM gets deselected when WD\ goes active, or OE\ gets qualified with ø2 and negated R/W (most recommended)
Consider it a design exercise Seriously, I should learn about the programmable logic devices, complex circuits will definitely thank them... although I'm a bit disappointed by the large static power consumption of such CMOS devices Anyway, they seem a must when speed is needed, thus some thrift must be sacrificed...

Still several interesting posts to reply remain in this thread, but now I'm off to a family gathering. I'll continue later. Stay tuned!

Hmm, I'd be careful with that kind of thinking: there are setup and hold constraints to be met. Violate those and you could have some difficult to debug misbehaviour. (Which is to say, it's not an asynchronous input: tPCS and tPCH constraints apply; see page 29/30 of the current datasheet.)

Cheers
Ed

Hi all! I'm back again...

I've noticed some errors in my circuit: While this part of the circuit is OK for the I/O & protected memory access section, it's not for the illegal opcode detection -- it'll keep checking all the bytes of any instruction in user space, thus things as innocent as:will trigger the SEI warning Fortunately this is very easy to fix: the ENABLE\ pins on the '688s shouldn't be driven by the aforementioned flip-flop, but from a NAND gate taking SYNC & KERNEL\ as inputs.

Originally, I had the WD\ (Write Disable) signal to inhibit the WE\ (Write Enabled) signal to RAM, which should work for Intel-style interfaces too. 65xx I/O hardware shold not just have their R/W lines disabled, because bus contention would happen. And while some of them have alternative Chip Select lines for full disabling (like CS1 on a 6522 VIA, CS0 on the 6551 ACIA), some others (2651 ACIA) may not. I think it's best to just generate a generic DIS\ (Disable) signal and let the computer's glue logic to inhibit devices as convenient -- maybe just disabling the decoders, but then make sure that the PROT\ signal stays valid, or let the circuit generate it from the address bus.
Thanks for the warning! I have drawn some timing diagrams, and it seems that it won't be an issue...

Well, there is actually a suspicious case: when the opcode following the illegal instruction is yet another privileged opcode... on the first cycle of the interrupt sequence (with SYNC anomalously active) this will be on the databus, being detected by the corresponding '688 and triggering a second NMI pulse during the second cycle of the sequence

I don't know what the response of the CPU about this second NMI will be in such an early stage of the interrupt sequence... if it's just ingnored, great! If not, the worst case scenario I can think is that a second NMI is executed over the first and pending call; that second call will manage the "exception" and clear the appropiate register (indicanting the cause of interrupt). And then, just after killing the offending process and giving control back to the rest of the system, the pending NMI gets executed -- as it will find the "exception register" clear, it would likely assume that it was an user-generated NMI (the button was pressed!). Then it would be just a matter of issuing the debugger command for returning to system -- provided that a human being is at the computer
That's simple: stack space cannot be considered protected by my circuit. Otherwise, ther would be no way to call subroutines, including kernel calls!
It's a really elegant and simple solution! And could be particularly versatile in some applications.

However, as you already mentioned, it could be a speed-limiting factor, even with state-of-the-art (E)EPROMS. Plus, it really has to be integrated in the design, while my circuit could be used as an optional add-on -- it just sniffs on the busses and supply the NMI\ (usual) and DIS\ signal. The latter must be considered by the system, but could be something as simple as hooking it to an active-high Enable signal (with a pull-up). My next computer in the road-map, designed more for versatility and reliability than speed (2 MHz) uses a '138 for qualifying all signals; could use that for disabling devices.

Cheers,