# HG changeset patch # User David Douard # Date 1518713926 -3600 # Node ID 9e6170316dbe196b818644f87d4ede377c492187 # Parent 9ba7fe3d0a226c1a4e047e309b25886afce1df73 [eip545b] part 4 diff -r 9ba7fe3d0a22 -r 9e6170316dbe content/eip545b_4.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/content/eip545b_4.rst Thu Feb 15 17:58:46 2018 +0100 @@ -0,0 +1,111 @@ +======================================== + 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 stays zero. The gating is not modified. Not very useful as is... +More digging required!