Author Topic: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)  (Read 59647 times)

0 Members and 1 Guest are viewing this topic.

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #375 on: February 27, 2021, 06:19:31 pm »
Running the symbolic debugger I am able to single step the simple program, disassemble and what not.  I need to take the time to fully read the manual but the one problem I am seeing is ^C will not exit the program.   

Shown is single stepping (or trace as they refer to it) the wiki example. 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
After a lot of trial and error, I finally have the basic tools working.   Don't use "_" in file names and keep them to the 8.3 format.   The also try to help you by embedding a jump at the start and moving the code so it will run on the CPM computer that they were targeting.  To get around this, don't enable support for the linker's Intel HEX format.   

Starting with a single file,  I can now assemble, link, split it into the two PROMs, verify them against the original PROMS, then load the images into my old EPROM emulator.  This unit supports two devices, perfect for the Fluke.  I made a couple of cables to plug it into the controller board.   Getting close.

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
It's a tight fit without the extender but doable. 

Shown running the meter from the assembled code loaded into the simulated PROMs.   With the tool chain now working, the next step is to get the logic analyzer on it and see if I can sort out the area of code I am after.   

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
That is looking pretty impressive!  - so you actually have an assembly listing that can be used to build the original PROMs with no differences encountered?  - that must count as a small miracle!  :D


I've had my head buried in Diptrace all weekend, trying to get to grips with it by building a brushless motor driver board.  I thought that sounded like a fairly simple project that couldn't possibly take more than a few hours...    :-DD
« Last Edit: March 01, 2021, 05:41:21 am by SilverSolder »
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
...
 so you actually have an assembly listing that can be used to build the original PROMs with no differences encountered? 
...
Yes but keep in mind, the assembly code could be completely made up of an ORG, several DBs and an END. 

The MicroSoft assembler will support the standard 8080 format from that time so the syntax has not been a problem.   The MicroSoft linker will also output symbolic data for the Digital Research debugger. 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Spent a little time looking over the controller, serial and display hardware.   After incrementing the two version numbers, the meter will show Error 8.  Controller module is fault.   I suspect I need to add a CRC or checksum to one or both ROMs.  Getting closer to a working setup.     

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
I think they implemented a timeout interrupt to detect failed backplane transactions. The typical code looks like this:

MOV H,...          backplane address (L = don*t care)
ORA A               reset carry
MVI M,#$0xFF  touch backplane address
RC                     exit on carry set by timeout interrupt
 ...                      continue with module present

I think this is used  for module detection. There are four 0-terminated lists in ROM of backplane addresses to check in a sequence. The presence of modules is saved in flag bytes, e.g. at 0x4052 (8 bits) and 0x4181 (bits 0x01 and 0x02).
One PROM check i saw was a check for 0x3800 = 0x55.
Remember this is for the 8502A version 3.0.3. Hope it helps.

Regards, DIeter
 
The following users thanked this post: SilverSolder

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
I think they implemented a timeout interrupt to detect failed backplane transactions. The typical code looks like this:

MOV H,...          backplane address (L = don*t care)
ORA A               reset carry
MVI M,#$0xFF  touch backplane address
RC                     exit on carry set by timeout interrupt
 ...                      continue with module present

I think this is used  for module detection. There are four 0-terminated lists in ROM of backplane addresses to check in a sequence. The presence of modules is saved in flag bytes, e.g. at 0x4052 (8 bits) and 0x4181 (bits 0x01 and 0x02).
One PROM check i saw was a check for 0x3800 = 0x55.
Remember this is for the 8502A version 3.0.3. Hope it helps.

Regards, DIeter
That's four different sets, all the same.  So just a simple  modulo 100 checksum for the whole thing, then split it.   

I have no idea where their original tool is storing it.  There are a few FFs at the end of the file, so I appended it as the last byte, which I know is not correct as every file I have looked at was set to FF.   Thinking it's unused area and it appears to work correctly.   

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
The code for the checksum calculation starts with instruction LXI H,#$0x0000 (unique in my disassembly). It contains the check for 0x3800 = 0x55 i mentioned to determine whether the checksum calculation runs up to 0x2FFF (fourth ROM not present) or to 0x3FFF (fourth ROM detected). The calculated checksum gets output to port 0x52, maybe for debugging purposes (one of two OUT instructions).
Yes, it doesn't matter which unused byte you make an adjustment byte.
Maybe in the end we will know which ROM byte is unused except for the checksum calculation..

Regards, Dieter
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Odd they would hard code the firmware regarding the checksum in the middle of the code.    The tool used to modify the file would have to know the location so they must locate that section of code in the same place.  Maybe they had another way.  As you suggest, dump it to a debug port, mod the code, rebuild, reload and try again.  Really odd but I have seen stranger things.  I would have just expected them to have a tool that runs on the binary and appends it to the end so the routine always checks for zero.  I like simple approaches.   Can you post the section of code you are referring  to.  I'll see if I can hunt it down and make some sense of it. 

I ran several builds last night using the appended checksum and it seems to be working fine.   No ill effects from changing the last byte.   

My first attempts using brute force, trial and error, divide and concur to hunt down the section I am looking for yielded some interesting results.  I think I now know a little more about the structure of the code.  I really wish the manuals had dove into more details about the inner workings.   I had hoped to be able to located the section without the logic analyzer but it's taking too much time.   That meter is just so compact its going to take some more custom adapters to instrument it.   :-DD

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Good old DOSBox.  Here's the current setup.   

https://www.youtube.com/watch?v=CA-wbjTBMYk&feature=youtu.be

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
OK, appended the checksum calculation of the Fluke 8502A firmware 3.0.0.
Meanwhile i checked in that EPROM set the first three give a zero remainder as well, so the fourth EPROM is kind of add-on and there are two unused adjustment bytes, one for 0x0000 .. 0x2FFF and one for 0x3000 .. 0x3FFF.

Regards, Dieter
 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
[...]  That meter is just so compact its going to take some more custom adapters to instrument it.   :-DD

You could always run it without the I/O card at the back, to get some space "over" the controller board?  It runs fine without any I/O card at all.

 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
OK, appended the checksum calculation of the Fluke 8502A firmware 3.0.0.
Meanwhile i checked in that EPROM set the first three give a zero remainder as well, so the fourth EPROM is kind of add-on and there are two unused adjustment bytes, one for 0x0000 .. 0x2FFF and one for 0x3000 .. 0x3FFF.

Regards, Dieter

Thank you very much.   It's very similar in the 8506A but there isn't an embedded port call.  It's too bad the 8502A's controller is so different from the 8505/6.  It looks like you have made a lot of progress sorting out the firmware.  I don't understand enough about the hardware yet to make sense of it.   It may not seem like much but all these little bread crumbs of yours have been a big help.     

You could always run it without the I/O card at the back, to get some space "over" the controller board?  It runs fine without any I/O card at all.

The card in the back is the serial communications board.  The plan is to modify the firmware to take advantage of the higher BAUD rate after modifying the clock generator circuit. 

An extender board would be nice but I think I have an easier way to do it. 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
It appears that the serial communications is not done in the foreground.  I knew the receive side of the board supported interrupts but it appears they use interrupts for the transmit as well.    It seems interrupt 0x20 (RST4) is the one being used which is running from RAM.     

Have you sorted out where the copy from PROM to RAM happens?   Mapped out the different sections?   

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00

No, I haven't dug that deep - I have been resisting that particular rabbit hole, but all the other rabbits are starting to push me in!  :D
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
OK, here is how the RAM code initiates in the 8502A.

Meanwhile i also tried to bring the disassembly to a format that assembles successfully.
When looking at gaps in the disassembly that appeared like unreferenced machine code, i found jump tables with about 60 more code references, implementing switch statements (computed jumps and computed calls). Appears like a state machine. Did not find p-code until now, but there are more code gaps and a lot more ROM data to look at.

Regards, Dieter
 
The following users thanked this post: SilverSolder

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Thanks.   

Looking at the hardware, the serial board sets ID2 during an interrupt.    On the controller, this routes to U21 priority encoder 14532.   The encoders Q outputs route to U13 inverting driver 74240, which drive the 8080's D3-5.   So when ID2 is set, the encoder puts out a 011 on Q2..0.  This is inverted to 100 on 8080s D5..3, so vector 0x20 (RST4).   So it makes sense that the RST4 certainly plays a big part in the serial communications.   It's always good when things make sense.

If that's right, I believe the external trigger would use RST5 which is also run from RAM.     

I suspect the transmit side polls the status register checking the transfer flag during the timer interrupt.   There is one more test I can run to try and prove this out.

Can you tell I'm avoiding the logic analyzer like the coronavirus.   :-DD  Just trying to make sure I have some idea what I am looking for before diving in.

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Using the cheap programmer to sniff the RAM. 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Appears like a state machine.

It's been a bit of a trip playing with such an old processor.  I had long forgotten just how odd it was.  Just having small sections of interrupt code rather than vectors, and having to force the address onto the databus... just some crazy ideas from the past.     

Looking at the RAM areas containing the interrupt code,  I was hoping that they would just initialize these areas of the RAM and were done with it.  I could then just search for that section of code and focus on the part I am interested in.   

I was guessing they were doing this for speed but now I have a sinking feeling that part of the reason they used this over the ROM was they wanted to be able reprogram the interrupt.  It looks like they reprogram the these areas during runtime.   


Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00

"Just having small sections of interrupt code rather than vectors,"

Than one got me too.  -  On the plus side, it isn't full of weird segment registers etc. - it seems very 'fundamental' in how it works...
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
The segmented memory was something I was used to from my first computer.   It predated the 8080 and the CPU was mostly made of 7400 logic.  You had 2K of core which was shared between the display and programming areas.   To get around the small area, you would have a small program that would load in segments from the floppy and run them.  Jumping back and forth.   :-DD  The 8088 was a big step up. 


Looking at the code in RAM starting at address 0x112 (0x4112), it appears they set the first location to 0xC& (RET 0) or reset.   Interesting is I had noticed if I sent data to the meter over the RS232 port while the meter was booting, it will reset and I could actually hold it in reset forever.   I think I now know why.     

Once the meter boots, they appear to have a mechanism to detect that the RS232 port should be active and then they reprogram this area of RAM.  They can certainly pole the communications board to see if there is incoming data.  This seems to be what triggers the meter to reprogram that area.  Wow ...  The more I look at this vintage hardware, the more I want to hear from the team who designed it.   

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00

Perhaps it is able to do something cool, like load an external program into RAM over the serial port, on startup?  -  like a monitor/manipulator for testing / debugging / special applications?
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
I had wondered about it having a debug mode of sorts that allow them to display/change memory and such.   If there was, I would have thought the commands would all be ASCII and we would see some visible signs glancing through the hex file.   Still, it could be there. 

I keep thinking 1/60Hz * 8 or a 2.08ms interrupt.  In the fast async mode, it averages out to 25.2ms.   I just keep thinking there is a /13 that checks that UART's transfer flag.   

I can tell you that when I initialize the meter, I see the ASCII commands show up a few bytes after the RST4 area in RAM.  It also looks like there is a fair amount of RAM that is not being used, at least in my case.   I wonder if they use this as a very large buffer when sending in the faster modes.   

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
In section 3 of my Fluke 8502A manual they give some technical details about hardware and firmware. There is a detailed explanation of direct and indirect backplane addressing, with the front panel as an example.  Also they explain about the timer interrupt (8 times mains frequency) and how the firmware assigns these interrupts to various tasks in a round-robin pattern. Except the ADC has a higher priority and gets half of the time. It's a sophisticated machine - certainly the 8505/6A even more than the 8502A.

Anybody has the schematic diagrams of the serial and parallel communication interfaces? In my Fluke 8502A manual it says "Page left blank intentionally". I'm having difficulties with the incomplete decoding of backplane addresses (IC0..IC6). There should be a rule to avoid confusion, but until now i didn't catch it.

When wiring up programmers and analyzers to the isolated logic in the DVM, please be aware of a 20 V offset between guard and logic ground. Better leave guard on the front panel unconnected. Otherwise all this may be just a sophisticated way to kill a working instrument..

Regards Dieter
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf