Radar Controller hacks 6502 illegal instructions

[Dr Jefyll]

Readers of this forum will be interested in a post that appeared on Pagetable.com under the topic, "How MOS 6502 Illegal Opcodes really work." On August 1, 2008, Marc Brooks wrote:

Quote:

We used illegal opcodes and a piggy-back board to add instructions to the 6502 processor. When we decoded an illegal opcode, we floated a no-op onto the instruction bus (for a defined number of cycles) and then let our custom PAL decode what really should happen. Doing this, we added a “paging register” for the zero-page and 1xx page (which you know are special). For the 1xx page, we detected when stack overflows and underflows happened and auto-adjusted the 1xx page register. Doing this gave us a 256-byte window into a (essentially) 64K stack. This was instrumental in the Forth interpreter we used to control a custom radar dish (details not available, sorry). We also took advantage of the fact that the 6502 was a DC-clock-safe processor , and essentially stopped the clock while slower RAM was being accessed and over-clocked the processor when it was talking to zero-page stuff. Lots of memories there. BTW, this was 1979-1982 or so…

I had to learn more about this one-of-a-kind project, so I contacted Marc and asked for more detail.

Quote:

Our project was to control the scan-speed of a radar dish in real time based on the return echo density. Simply put, we controlled the rotation of a standard (for the time) dish radar and watched the choes coming back. If we had very little return, we swept fast, if we had a lot of return energy, we slowed the sweep speed down to allow better fine-grained imaging. We decided that the 6502 was the best chip for the project because we both knew it well, loved the DC-safe clock, and knew how to hack the instruction bus float. Bill wanted to use Forth, which was fine with me (I was most comfortable in 02Asm or C at the time, but whatever).

The hacks we made were:

1) Automatic recognition of stack underflow and overflow on page-1 access via stack instructions, allowing a full 64K stack (in separate memory). Basically we watched pushes and pops and incremented/decremented a stack page "register". We added instructions to set/read the SPH (16-bit) and SPL (8-bit).

2) A similar trick with a "current page 0 register offset" that allowed all the 0-page instructions to target a complete 64K ram (in separate VERY FAST ram). No automatic underflow/overflow management, but ZPH and ZPL set/reads.

3) A dynamic clock that sped up the processor clock whenever instructions were accessing either 0-page or 1-page (e.g. stack or scratch) and slowed it down when accessing any other memory (e.g. the rest of the original 64K memory space).

4) Memory-mapped access to the radar controller data in 8000h area, which was "dynamic" and reflected the current radar returns (with simple time-signatures) to allow us to block-read the data and "just keep reading" until we hit the end.

5) Writes to this area would drive a "radial" etch-a-sketch device (high address byte being rotation and low byte being distance from center) with single LED that varied in brightness according to the return density we were seeing. This was originally intended for development, but the display was easier to read quickly than the analog scope that was getting the raw scope-return data... so we built these as "add ons" for the units. The scope used voice-coil drives from a couple Qume Datatrack-8 floppy drives.

As for hardware build, we bought 500 CMOS ceramic packages (instead of plastic for better heat dissipation) and hand picked to find the ones that would run reliably at 2MHz (burst speed when doing 0 or 1 page stuff). We also bought some very fast RAM (for 1979-80).

[Dr Jefyll]

The details above simply whetted my appetite for more, so I invited Marc to post his information here on 6502.org and to host a discussion. I wasn't able to coax him to do that, but he agreed to answer some questions -- a sort of interview which I conducted on the Forum's behalf. I sent him a list, and he interspersed his answers as follows.

> BTW I'm assuming you don't wish to launch this new Forum topic yourself (but just say the word -- you're certainly welcome to do so!).

Quote:

No, I'm so busy these days, I'm not a good candidate to getting it started

The basic idea behind the project was being able to do three things "automatically/digitally":

• First, we could step the dish left or right as desired based on reflections we were getting back. If we didn't get anything for a while in a specific direction we could step faster past that position and if we had identified targets, we could step slower (or even back up for a rescan) to get better detail of that sector. It was even possible, though a bit silly, to not step at all.
• Second, we could adjust the effective range and resolution of a scan by changing the clock rate of the ping timer. This let us scan very near (fast clock) or very far (slow clock) for any sweep.
• Third, by adjusting the gain of the receiver and the floor value, we could decide dynamically what was a significant return and how "detailed" we wanted to be intensity of the return (from On vs Off to fluffy-cloud vs. falling safe). [ "falling safe ?!! -- JL]

> please explain the Time Signatures. My *guess* is that there's a counter clocked at very high speed, and that, as each reflection arrives, the counter value becomes a "time stamp" for that event. So, is the counter value clocked into a FIFO, later to be read out in the area above 8000h? And there's an intensity associated, too?

Quote:

Basically correct. At each output "ping" (we used discrete pulses, not continuous waves and we had two frequencies to allow multiple in-flight pings) we reset a binary counter (timer) and when we received a reflection we pushed the counter (TS) and intensity (I) [the high bit also noted which freq was received] into a giant byte-wise FIFO. Every time we stepped the dish right or left we would strobe a zero for "timer" and the dish direction in the intensity value byte. These were byte-values so each reflection meeting the minimum thresh was latched. We had digital gain control to allow the floor and density to be adjusted by the operator. The binary counter's clock was also digitally controlled to adjust the effective range of the current pulse.

> I just *LOVE* the bit about the radial etch-a-sketch! But you said writes above 8000h serve to output rotation and distance info, whereas the etch-a-sketch would seem to need the X-Y equivalent. Was there a big lookup ROM to translate? Eg: take 7 bits rotation & 8 bits distance, and look up 8 bits each of X & Y? Better yet, store only 1 quadrant in ROM and later flip the signs as required...

Quote:

It was a hack we put together that let us directly visualize the incoming stream of data. It was an old-fashion 10 LED bar-graph (4 of them, I think, so 40 segments) stuck onto the arm of a traditional R/C stepper motor. When a time-signature TS:0 value was seen, we stepped radially left or right using the information in the intensity I:dir. Otherwise the TS:r gave the "radius" length for the reflection, which was binned into one of the 40 LED positions.The intensity I:z value gave the brightness value of the LED. So it basically was a polar-graph that played on persistence-of-vision to generate the scope's view. If we stepped reasonably quickly, you could visualize the incoming data well enough to see what was going on...

> it's not clear why the stack mapping hardware has both SPH (16-bit) and SPL (8-bit). Likewise, why does the zero-page mapping hardware have both ZPH and ZPL?

Quote:

Over-engineering. We were trying to make up the rest of the 64K address space for EACH of the "zero-page" and the 100-page 6502 stack. In actual deployment, we built with 8K of zero-page and 4K of stack. All this was mostly so we could run really fast RAM and really small instructions really fast.

> My hunch is that there's an adder involved which juggles offsets, and that the "essentially" 64K stack shares physical ram with the 64K zero-page.

Quote:

Yes on the adder for the stack page auto-adjusts. No on the sharing... separate banks of RAM with different speed characteristics.

> Of course I could be way off base! My other inference is that SPL replaces the role of the 6502 SP, the latter actually playing absolutely no part in addressing stack ram! How am I doing? ;o)

Quote:

SPL was an error in my original post... no such games... it was the SP value being shadowed in the adder that I was thinking of.

> Was the 64K stack implemented as a precautionary measure, or was there a clear and compelling reason?

Quote:

Overkill on design to ensure we didn't have to rework things later. In real use, we didn't need that much

> For example, did you need to store a large data set on stack?

Quote:

We had several co-routines going all the time... there was a lot of stack use in trading state out for context switching. There was the basic controller logic, there was some automatic gain-control logic, there was the output stuff and there was the analysis logic that was doing the edge-detection of the resulting objects. We were supposed to be outputting "object and position" to another piece of code. We also took inputs of what radial position they were "interested in" at what estimated distance and what target size/reflectivity and we had to "schedule in" the detail sweep in with general scanning for other things. [My need to know was not present, but my assumption was it was some fire-control logic, later assumption is that this might have been part of some Phalanx-like system]

> Or perhaps the code involved recursion. Was it FIG Forth you were running (which use the 6502 machine stack as the Forth Return Stack)?

Quote:

I don't know, honestly. That was Bill's domain... I _think_ it was FIG Forth, but I did the low-level stuff in raw 6502, he did the Forth -- knowing Bill, he did a LOT of tweak to that runtime too

> Congratulations to you & Bill on a deliciously cool hack! -- and thanks in advance for any light you can cast on these questions above. Cheers,

Jeff

[BigDumbDinosaur]

Aah! The things that that old 6502 can be made to do. I wonder what Chuck Peddle and Bill Mensch would think if they were to read of this endeavor.

BTW, the 6502 is closing in on 40 years. Hard to believe it. It seems like just the other day when I first read about this new microprocessor that was cheap, versatile and easy to build a system around. My, I feel old.

[BigEd]

Nice one Jeff - is that the first interview on the forum? Fascinating!