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
Login
Register
FAQ
Search
