开云体育

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...

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 Fri, Nov 26, 2021 at 9:13 PM Mark Litwack <mlitwack@...>
wrote:

I was going to write a Tek-specific disassembler that understood the later
model banking natively, but hadn't gotten around to it. Maybe IDA can do
it?

I'm using Ghidra, which almost certainly will allow automating the task of
resolving function references through bank switching. The problem is that
I'm a total Ghidra n00b :).
It looks like the 6800 disassembler I ginned up (
) is correctly
lifting the instructions to P-code, and from there it should be possible to
script up something that creates the right references.

It's a bit of a complication that a call through a bank switch is typically
done through a thunking routine that sits across the two banks, something
like:

SERVICE_FUNCTION_IN_BANK1_THUNK:
Bank0: JSR SWITCH_BANK1
Bank1: JSR ACTUAL_SERVICE_FUNCTION
Bank1: JMP SWITCH_BANK0

where the successive instructions above are on back-to-back addresses, but
in alternate ROM banks.

A call from bank0 to bank1 is then as simple as:
Bank0: JSR SERVICE_FUNCTION_IN_BANK1_THUNK

I think it would be ideal if the notion and particulars of the bank
switching could be plugged into Ghidras existing analysis mplementation, as
that way it would seamlessly trace control flow across the bank switching.
After thinking on it a little bit, I think it'd be reasonably
straightforward to abuse the processor description by adding a banking
register (BR) to the processor, and change all PC addressing to reference
BR+PC. This would make it possible to describe the ROM layout in an
extended, flat address space.

Another way to crack this would be to write an emulator. Mame has a 6800
CPU implementation, and the 2400 memory map and registers are sufficiently
documented that emulating them should be feasible. This would at least
expose all instructions and control flow for features that are exercised in
the emulator run.

Ah, that's cool. Did you reverse the full definition of the PAL?