开云体育

On Fri, Nov 26, 2021 at 9:13 PM Mark Litwack <mlitwack@...>
wrote:

I looked at the address decoding about 3 years ago. The goal was clearly
to be able to access all the RAM. But, as you point out, if they did it
would overlay the I/O address space. I think the easiest path was to make
the full 8k of RAM appear elsewhere. This would have had advantages in
minimizing design changes to the hardware moving from the 2445/2465 base
design and options, and also minimizing changes to driver code when ported
from the 2445/2465.

Ah - somehow I totally overlooked the fact that the 2465A/2467 et al have
8K of RAM, whereas the original address mapping only allotted 2K of address
space. So the answer was staring me in the face the whole time :).
I believe option boards also have ROM, so maybe the existing option boards
rely on the location of the IO range?

On Wed, Nov 24, 2021 at 2:14 PM Jeff Dutky <jeff.dutky@...> wrote:

do the locations 0x8000-0x9FFFF contain interrupt vectors which may need
to be modified? That would be the main reason that I would expect random
bits of memory to be remapped from ROM to RAM.

I'm not deep into this yet, as first I needed to fix Ghidra's 6800
disassembler. The one that comes with it seems to be incomplete to plain
wrong, and so the disassembly it yielded didn't make much sense. Thankfully
there's a quite good 6809 disassembler I could water down to get most of
the 6800 op codes, then add back the handful of op codes that are different
in the 6809.

The 2465 was introduced in 1984, and I assume that much of the code I'm
looking at dates back to the original 2465. Maybe it even dates back
further to earlier microcontroller-driven scopes?
The TekWiki page on the 2465 () names
some of the engineers that worked on the hardware, I wonder if the same
people also worked on the firmware.

I haven't looked at anything like this before and I wonder what sort of
development environment the engineers had. It looks like the calling
conventions used are all over the map, which probably means this was all
hand-coded assembly. The A/B/X registers are used to pass arguments, though
not in any consistent order. Most functions seem to set a global that's
then tested or retrieved by the caller, but there are at least some utility
functions that return values through registers.
The instruction set on the 6800 is pretty minimal, and the register layout
is absolutely minimal. As a case in point, there's no way to store or load
from the upper or lower bytes of the X (or S) register, so the only way to
e.g. do 8+16 bit addition is by storing the 16 bit value to memory and
doing the sum from there.

In any case, the couple of uses of this alternate RAM mapping that I've
found so far seem quite curious. Ghidra's support for memory banking
seems fairly minimal, and it's a hassle to trace the control flow when
it crosses banks, so I haven't traced more than one or two cases. I'm
tempted to backtrace and look at the 2465, as it has a simpler memory
layout without any banking.
Maybe the original design of the 2465A/B had assumed more RAM was needed
and slotted it into that part of the address space, rather than to move the
IO Register space, which abuts the RAM in the original design. Maybe there
were features planned that never made it to production, that would have
required more RAM. Maybe this was a case where it was easier to modify the
hardware to fit an existing piece of firmware, than to rewrite or patch up
the firmware. The address mapping in question is under the PAL's control so
it's a trivial hardware change to add this mapping.
Wouldn't it be fun to know...

Where can I fid the schematic and pats layout for my HV power supply it
doesn't agree with older ones found on BAMA etc. built around 1980?
I have a focus issue on the bench scope that i have used many years the
FOCUS PRESET nor the screwdriver focus have any effect.
I checked HV power supply and I have correct voltage -2975.

Joe wa9cgz