| Electronics > Repair |
| Vintage chip Programmer : " Micropross ROM 3000U " |
| << < (35/38) > >> |
| Vince:
Thanks for the suggestion, will give it a try. |
| m k:
You must have a hex editor, without it you can't see what you can't see. And then edition is just a copy/paste thing. Also, leave those first checksum and file number 8 bytes there. It seems that all of it is needed for correct positioning. Flipped bits I must take back. They are something to do with text but maybe not exactly it. Some are possibly extra letters, those out of basic Latin set. Many places have C1 C2 C2 C2 C2 C2 C2 C3 as a first text part. Latest character sets are based on DEC Multinational, no good. Old DOS was IBM graphics, no good either. Maybe it's HP something, but flipped bits are >======<. |
| m k:
First two below are relocated from 0x8b000 to 0x4000. There 0x400b and 0x400d have jump addresses in ROM when 0x400f has a jump to nowhere. Then 0x4049 has a code modifying code example. The latter two are from the boot section. There 0x942a and 0x942e can easily be some text stuff. But 0x9472 and knowledge of the use of the code is telling different, what? (it's already around here somewhere, not far) Seems that some sections are using illegal instruction. Found also one JAM so maybe it's something else. E, seems that text is early version of Roman-8 where Ax and Bx are used for controls. --- Code: --- 4008 4c 27 40 JMP LAB_4027 WORD_400b+1 XREF[1,1]: 4049(R), 404f(R) WORD_400b 400b 68 ef dw EF68h WORD_400d+1 XREF[1,1]: 405f(R), 4065(R) WORD_400d 400d 5c ef dw EF5Ch ************************************************************** * FUNCTION * ************************************************************** undefined FUN_400f() undefined A:1 <RETURN> FUN_400f+1 XREF[1,4]: FUN_4301:4312(c), 404c(W), FUN_400f+2 4052(W), 4062(W), 4068(W) FUN_400f 400f 4c 00 00 JMP PORTA --- End code --- --- Code: --- 4049 ad 0b 40 LDA WORD_400b = EF68h 404c 8d 10 40 STA FUN_400f+1 404f ad 0c 40 LDA WORD_400b+1 = null 4052 8d 11 40 STA FUN_400f+2 --- End code --- Just some separation for clarity. --- Code: --- s_=60_942b XREF[1,1]: 9472(R), 9472(R) s_.=60_942a 942a 2e 3d 36 30 ds ".=60" s_!"#_942f XREF[1,1]: 947f(R), 947f(R) s__!"#_942e 942e 20 21 22 23 ds " !\"#" --- End code --- --- Code: --- LAB_9472 XREF[1]: 947d(j) 9472 bd 2a 94 LDA s_.=60_942a,X = ".=60" 9475 cd 3d 86 CMP DAT_863d 9478 f0 05 BEQ LAB_947f 947a e8 INX 947b e0 04 CPX #0x4 947d d0 f3 BNE LAB_9472 LAB_947f XREF[1]: 9478(j) 947f bd 2e 94 LDA 0x942e,X=>s_!"#_942e+1 = "!\"#" --- End code --- |
| Vince:
Thanks for your work ! ;D Sadly I am nowhere near being able to put that to practice. But that's fine... that's the point of having a dedicated thread... all the info people give is safe / archived, one can always scroll back to dig out older info. As for code being data or vice versa, I guess it's fairly easy to figure out ? I mean, if it's data, the "code" will look weird, all over the shop, but if it's actually code, I guess one should be able to recognize it. I mean, I am hardly an assembly guru, the only assembly I wrote were a couple programs, 500 lines each tops, for school projects 25+ years ago, and it was for an Intel 8051 CPU not a 6502... but still, I have recollections... and I guess every CPU has similar instructions and similar ways of naming the mnemonics... So looking at the code in the boot section, it looks like : - Load some variable - compare it with whatever - test the result and branch - increment something - compare it with whatever - test the result and branch So looks like typical code for a loop inside another loop, no ? |
| m k:
Back in the day 6502 text code was cool. Above text stuff can be accepted input something and 60 thing a secret special parameter. But no, location 863d seems to be a file number and the code a renumbering thing for those late file numbers. If you want most out of the disassembler you should include boot section and ROM to all file parts. File part is loaded to 0x4000-0x7fff, 0x8000-8fff then is its RAM space. But it is also jumping and calling stuff from 0x9000-0xffff. One source directory thing in zip is blocking ROM area so it should be available somehow somewhere. |
| Navigation |
| Message Index |
| Next page |
| Previous page |