comparison: content/eip545b_4.rst
content/eip545b_4.rst
- changeset 78
- 9e6170316dbe
- child 87
- 9aebe20ab7c0
equal
deleted
inserted
replaced
| 77:9ba7fe3d0a22 | 78:9e6170316dbe |
|---|---|
| 1 ======================================== | |
| 2 EIP 545B RF Frequency Counter - Part 4 | |
| 3 ======================================== | |
| 4 | |
| 5 :author: David Douard | |
| 6 :Category: Electronics | |
| 7 :Tags: test equipment, RF, EIP, 545, 545A, 545B, 575A, 578A, counter | |
| 8 :series: EIP545B Frequency Counter | |
| 9 :series_index: 4 | |
| 10 | |
| 11 | |
| 12 This part is about my attempt to modify the firmware to "fix" the problem of | |
| 13 weird intial setup: a -160MHz offset and a resolution set to 5 digits. | |
| 14 | |
| 15 In the `previous part <{filename}/eip545b_3.rst>`_, we figured some probable | |
| 16 spots in the firware where these default setup configurations might be set. | |
| 17 | |
| 18 EPROM checksums | |
| 19 =============== | |
| 20 | |
| 21 In order to be able to modify the content od the firmware without generating an | |
| 22 error at startup, we must understand how checksum are computed. | |
| 23 | |
| 24 The Service Manual for the 578B does not explain how it is computed. The one | |
| 25 for the 545A gives a clue but is not valid for the 545B: in the Option 2 (power | |
| 26 meter) calibration procedure, since the "power vs. power" and "power vs. | |
| 27 frequency" calibration tables are stored in the EPROM, the checksum must be | |
| 28 computed when a calibration is performed. For this unit, the value at address | |
| 29 0x02F6 must be set so that the sum modulo 256 of all bytes of the EPROM is | |
| 30 equal to 0xFF. | |
| 31 | |
| 32 So the checksum is just a matter of sum modulo 256, but on the 545B, each EPROM | |
| 33 chip has its content verified, as can be deduced by the fact there are 3 error | |
| 34 codes (31, 32 and 33), one for each EPROM chip. | |
| 35 | |
| 36 I found the part of the initialisation code that compute this checksum:: | |
| 37 | |
| 38 ; Test PROM bank i (i in 1,2,3); | |
| 39 ; M000C: start address | |
| 40 ; M000E: i | |
| 41 6041 Z6041 CLRA ;4F | |
| 42 6042 LDY #Z4000 ;10 8E 40 00 | |
| 43 6046 LDX Z000C ;9E 0C | |
| 44 6048 Z6048 ADDA ,X+ ;AB 80 | |
| 45 604A LEAY -$01,Y ;31 3F | |
| 46 604C BNE Z6048 ;26 FA | |
| 47 604E STX >Z000C ;BF 00 0C | |
| 48 6051 LDB >Z000E ;F6 00 0E | |
| 49 6054 CMPB #$03 ;C1 03 | |
| 50 6056 BEQ Z605E ;27 06 | |
| 51 6058 DECB ;5A | |
| 52 6059 LDX #MFFEA ;8E FF EA | |
| 53 605C ADDA B,X ;AB 85 | |
| 54 605E Z605E COMA ;43 | |
| 55 605F RTS ;39 | |
| 56 | |
| 57 | |
| 58 This chunck of code is called with the start address in 0x000C (set to 0x4000 | |
| 59 on normal initial execution), and EPROM 'bank' in byte 0x000E (can be 1, 2 or | |
| 60 3). Once again, during normal init execution, this function is called with the | |
| 61 value 1 in this memory cell. | |
| 62 | |
| 63 So when i = 1 or 2, the sum if computed (in register A), and the result is | |
| 64 compared to the value stored at 0xFFEA (first EPROM) and 0xFFEB (second EPROM). | |
| 65 | |
| 66 For the third one (in which those checksum values are), no comparison is made, | |
| 67 the sum is expected to be 0xFF, which can be achieved by modifying the value of | |
| 68 byte 0xFFEC. | |
| 69 | |
| 70 | |
| 71 Frequency Offset | |
| 72 ================ | |
| 73 | |
| 74 As explained before, the frequency offset initial value seems to be set in the | |
| 75 chunck of code around 0x6118-0x6125:: | |
| 76 | |
| 77 6118 LDX #M0276 ;8E 02 76 | |
| 78 611B LDA #$01 ;86 01 | |
| 79 611D STA ,X ;A7 84 | |
| 80 611F STA $02,X ;A7 02 | |
| 81 6121 LDA #$60 ;86 60 | |
| 82 6123 STA $03,X ;A7 03 | |
| 83 | |
| 84 So the easiest way to remove this is to replace this code by NOPs. I've tried | |
| 85 this, computed the checksums and burnt a pair of EPROMs (only bank 1 and 3 are | |
| 86 modified). | |
| 87 | |
| 88 And it worked! Mostly. The offset set to 0 as expected, but the "Offset" | |
| 89 indicator remains on. I can live with that, but I'll try to figure out how to | |
| 90 fix this also, if possible. | |
| 91 | |
| 92 | |
| 93 Digits Resolution | |
| 94 ================= | |
| 95 | |
| 96 The chuck of initialisation code related to this setup is:: | |
| 97 | |
| 98 6125 LDX #M005D ;8E 00 5D | |
| 99 6128 LDA #$0D ;86 0D | |
| 100 612A STA $01,X ;A7 01 | |
| 101 612C LDA #$05 ;86 05 | |
| 102 612E STA >M0045 ;B7 00 45 | |
| 103 | |
| 104 | |
| 105 At least the last 3 lines are directly related to this resolutin setup. So I've | |
| 106 tried to replace these few opcodes with NOPs. | |
| 107 | |
| 108 And the result is a partial success: all the digits are displayed when I power | |
| 109 the device on, but the frequency counter still computes only 5 digits, the | |
| 110 other ones stays zero. The gating is not modified. Not very useful as is... | |
| 111 More digging required! |
