content/eip545b_4.rst@d2632122f838
content/eip545b_4.rst
Fri, 02 Mar 2018 01:12:57 +0100
- author
- David Douard <david.douard@logilab.fr>
- date
- Fri, 02 Mar 2018 01:12:57 +0100
- changeset 91
- d2632122f838
- parent 90
- 3a2040f53c9f
- child 115
- 6b6e13653348
- permissions
- -rw-r--r--
add src to hgignore
======================================== EIP 545B RF Frequency Counter - Part 4 ======================================== :author: David Douard :Category: Electronics :Tags: test equipment, RF, EIP, 545, 545A, 545B, 575A, 578A, counter :series: EIP545B Frequency Counter :series_index: 4 This part is about my attempt to modify the firmware to "fix" the problem of weird intial setup: a -160MHz offset and a resolution set to 5 digits. In the `previous part <{filename}/eip545b_3.rst>`_, we figured some probable spots in the firware where these default setup configurations might be set. EPROM checksums =============== In order to be able to modify the content od the firmware without generating an error at startup, we must understand how checksum are computed. The Service Manual for the 578B does not explain how it is computed. The one for the 545A gives a clue but is not valid for the 545B: in the Option 2 (power meter) calibration procedure, since the "power vs. power" and "power vs. frequency" calibration tables are stored in the EPROM, the checksum must be computed when a calibration is performed. For this unit, the value at address 0x02F6 must be set so that the sum modulo 256 of all bytes of the EPROM is equal to 0xFF. So the checksum is just a matter of sum modulo 256, but on the 545B, each EPROM chip has its content verified, as can be deduced by the fact there are 3 error codes (31, 32 and 33), one for each EPROM chip. I found the part of the initialisation code that compute this checksum:: ; Test PROM bank i (i in 1,2,3); ; M000C: start address ; M000E: i 6041 Z6041 CLRA ;4F 6042 LDY #Z4000 ;10 8E 40 00 6046 LDX Z000C ;9E 0C 6048 Z6048 ADDA ,X+ ;AB 80 604A LEAY -$01,Y ;31 3F 604C BNE Z6048 ;26 FA 604E STX >Z000C ;BF 00 0C 6051 LDB >Z000E ;F6 00 0E 6054 CMPB #$03 ;C1 03 6056 BEQ Z605E ;27 06 6058 DECB ;5A 6059 LDX #MFFEA ;8E FF EA 605C ADDA B,X ;AB 85 605E Z605E COMA ;43 605F RTS ;39 This chunck of code is called with the start address in 0x000C (set to 0x4000 on normal initial execution), and EPROM 'bank' in byte 0x000E (can be 1, 2 or 3). Once again, during normal init execution, this function is called with the value 1 in this memory cell. So when i = 1 or 2, the sum if computed (in register A), and the result is compared to the value stored at 0xFFEA (first EPROM) and 0xFFEB (second EPROM). For the third one (in which those checksum values are), no comparison is made, the sum is expected to be 0xFF, which can be achieved by modifying the value of byte 0xFFEC. Frequency Offset ================ As explained before, the frequency offset initial value seems to be set in the chunck of code around 0x6118-0x6125:: 6118 LDX #M0276 ;8E 02 76 611B LDA #$01 ;86 01 611D STA ,X ;A7 84 611F STA $02,X ;A7 02 6121 LDA #$60 ;86 60 6123 STA $03,X ;A7 03 So the easiest way to remove this is to replace this code by NOPs. I've tried this, computed the checksums and burnt a pair of EPROMs (only bank 1 and 3 are modified). And it worked! Mostly. The offset set to 0 as expected, but the "Offset" indicator remains on. I can live with that, but I'll try to figure out how to fix this also, if possible. Digits Resolution ================= The chuck of initialisation code related to this setup is:: 6125 LDX #M005D ;8E 00 5D 6128 LDA #$0D ;86 0D 612A STA $01,X ;A7 01 612C LDA #$05 ;86 05 612E STA >M0045 ;B7 00 45 At least the last 3 lines are directly related to this resolutin setup. So I've tried to replace these few opcodes with NOPs. And the result is a partial success: all the digits are displayed when I power the device on, but the frequency counter still computes only 5 digits, the other ones stay zero. The gating is not modified. Not very useful as is... More digging required!
