开云体育

Hi Chris,

The EPROMS are fully decoded. U2260 goes from 0xc000 to 0xffff.

NMI is generated when the power switch is turned off. It should
be perfectly ok to drop into a halt or loop.

No status information of any kind, we want this to be as easy as
possible to hand load into a prom burner's buffer.

I would like this to be purely machine code, with everything in a
contiguous blob ending at 0xffff, if possible.

We can't assume that everyone using this will have an assembler, or
even know what one is. And we don't want you to be on the hook
forever creating little custom S-Rec blobs.

Ideally, the blob should start with the calibration data, in order
of presentation from EXER 02, which is 0 to 0x1ff, high byte, low
byte... And then it should go right into the executable all the way
to the jump vector at the end.

EXER 02 starts at calibration constant 0, and goes through 0xff.

The constants are displayed as hex words, in high/low byte order.

eg. 0 -> HHLL
1 -> HHLL

In other words, I don't want people to have to put a little code at
this address, and a little data at that address, and something else
else over there...

I want you to be able to tell them to:

1) go to address 0x????
2) enter your EXER 02 data (0, 1, 2, .... FF)
3) enter blah, blah, blah (through to 0xffff).
4) install EPROM in socket U2260.
5) turn on the scope and count to 10.
6) turn off the scope, and put the original EPROM back into U2260.

Your scope is now back to its original calibration.

I don't mean to sound autocratic, but I come from the days when
every computer had a bunch of switches on the front panel, and
entering boot loaders, "fat finger" style was how it was done.

It has to be simple, or it will get done wrong.

-Chuck Harris


On Fri, 12 Apr 2024 08:44:30 -0500 "Chris Elmquist" <chrise@...>
wrote:

Hi Guys,

Give me a few days to research and dig into this-- $DAYJOB in the
way for now but I will do as soon as I can.

The program is very simple. I just need to confirm execution address
and a little more about the vectors that reside at the end of memory.

$FFFE,$FFFF is certainly the reset vector but below that there are NMI
and IRQ vectors too that probably also need to be filled in-- at
the very least, if the system uses NMI for anything, we'll need to
point that at an RTI instruction.

I think the constants can reside anywhere in our PROM, like right at
the end of the copy routine for example, and it is just the
destination address in RAM to which we are copying them that is
important.

The 27128 EPROM is 16K bytes and so does that mean it is fully decoded
from $C000 to $FFFF or ?? If so, then our program could start at
$C000 but this is another detail I need to confirm.

In any case, thanks for the "bootstrap" Chuck and I'll do my best to
get 'er done. I should be able to assemble the code for folks and
provide S-records and listings so you can get them into a device
programmer however you see fit.

If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)

I don't expect to do much for blinking LEDs or anything so I think how
this would work is that you power off the scope, swap out the factory
27128 EPROM with our hack EPROM, power on the scope, count to 10
maybe?, power it back off, swap the EPROMs again, power back on, and
when the scope comes up, go check if your cal constants are in there
correctly using the EXER02 routine that Chuck mentions below. Does
that seem feasible?

Chris N?JCF

On Thursday (04/11/2024 at 11:21PM -0400), Chuck Harris wrote:

Ok, here's the drill.

I think the best/easiest way for Don to get his codes back into his
2467B's pre 50K battery backed RAM would be to burn a little code
snippet into a 27128 EPROM, and run it.

The 6800 starts up at the last 2 addresses in memory space, as far
as I can tell, so 0xfffe and 0xffff should contain a jump into the
start of our code snippet...

The next 512 bytes should be the calibration constants, as were read
using the EXER02 routine, by Don.

Then comes the snippet that gets branched to. It should be a simple
loop that executes 256 times. It reads a word (16bits) from the
calibration constant table, and writes it into the RAM address range
0x7e00 through 0x7fff.

To use this little hack, all of this code, and Don's calibration
constants should be edited into an EPROM burner's buffer, creating
the bootstrap for Don's 2467B.

Remember, the 6800 is a big-endian machine.

I know Chris indicated he could do this.

Fame and goodwill awaits the first person to write and verify
this little code snippet to the tekscopes groups...

-Chuck Harris


On Wed, 10 Apr 2024 09:42:42 -0500 "Chris Elmquist"
<chrise@...> wrote:

On Tuesday (04/09/2024 at 11:47PM -0400), Chuck Harris wrote:

Hi Chris,

It really doesn't matter where you do your development. I
choose linux. I stopped using MS products in the 1990's, after
paying a ton of money for support on an MS development package.
Their support people repeatedly lied to me, I missed several
important deadlines, and lost a very important customer.

Absolutely agree. I just figured for the OPs goal, it might be a
long slog to get Linux up and running before he ever got to the
task at hand, assembling some 68xx code. I didn't want him to
believe that Linux was required. It's a better choice, but not
required for this exercise.

The memory map for the 2465 is shown in figure 3-2 in the
2465B/2467B Service manual.

Excellent. I have not had to look at said manual in many years
so I have likely forgotten it was there. This info will be
needed to know where to copy to and from and the execution
address for where the little bit of code needs to reside.

The calibration constants are the last 256 words in RAM... (eg.
0x1e00 to 0x1fff)

All of the rest of the RAM gets initialized every time the
scope is power cycled... So it just doesn't matter.

So, does that mean there are always 256 bytes of calibration
data? No fewer? The entire 256 byte block is what would be
copied?

Chris