Tempest Posted April 13, 2022 Author Share Posted April 13, 2022 2 minutes ago, RevEng said: Looking at ST Writer some more, I'm pretty sure it's a bad dump. Here's some embedded text strings, which have missing characters: 00000450 20 20 20 20 20 20 20 20 20 20 20 20 00 4C 65 73 .Les 00000460 73 6F 6E 20 4F 6E 65 3A 20 54 65 61 63 68 65 73 son One: Teaches 00000470 20 74 68 65 20 75 73 65 20 6F 66 20 20 20 20 68 the use of h 00000480 6F 6D 65 20 72 6F 77 20 6B 65 79 73 2C 20 61 73 ome row keys, as 00000490 64 66 20 6A 6B 6C 3B 20 67 68 20 20 20 54 79 70 df jkl; gh Typ 000004A0 6F 6D 65 20 72 6F 77 20 6B 65 79 73 2C 20 61 73 ome row keys, as 000004B0 64 65 79 20 61 70 70 65 61 72 2E 20 20 20 20 20 dey appear. 000004C0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 000004D0 20 20 20 20 20 20 20 20 20 20 20 20 20 00 4C 65 .Le 000004E0 20 20 6F 6E 20 54 77 6F 3A 20 54 65 61 63 68 65 on Two: Teache 000004F0 73 20 74 68 65 20 75 73 65 20 6F 66 20 20 20 75 s the use of u 00000500 70 70 65 72 20 72 6F 77 20 6B 65 79 73 2C 20 71 pper row keys, q 00000510 77 65 72 20 75 69 6F 70 20 74 79 20 20 20 54 79 wer uiop ty Ty 00000520 70 70 65 72 20 72 6F 77 20 6B 65 79 73 2C 20 71 pper row keys, q 00000530 74 68 65 79 20 61 70 70 65 61 72 2E 20 20 20 20 they appear. That loop I mentioned before that never exits looks like it makes sense generally, but the "nop" at the top is likely a corrupted opcode... DC2B: nop $4a DC2D: bcs $dc33 DC2F: dey DC30: bne $dc2d DC32: dex DC33: cpy #$17 DC35: bne $dc2b That, coupled with a slightly off 6502 reset vector, makes me pretty sure we're seeing bitrot. Both versions? Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 13, 2022 Share Posted April 13, 2022 The first version is missing half of the rom - including the area where the reset vector points to. It has the same text corruption though. Quote Link to comment Share on other sites More sharing options...
Tempest Posted April 13, 2022 Author Share Posted April 13, 2022 4 minutes ago, RevEng said: The first version is missing half of the rom - including the area where the reset vector points to. It has the same text corruption though. Darn. Maybe I can Marty if he knows where Curt got these from. 1 Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 13, 2022 Share Posted April 13, 2022 17 minutes ago, Tempest said: Darn. Maybe I can Marty if he knows where Curt got these from. I wonder if John Hardie has a copy. I know he has a keyboard. Mitch Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 13, 2022 Share Posted April 13, 2022 25 minutes ago, RevEng said: The first version is missing half of the rom - including the area where the reset vector points to. It has the same text corruption though. Can you see what is going on with the joystick code on the temperature module? Mitch Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 13, 2022 Share Posted April 13, 2022 1 hour ago, RevEng said: @Danjovic is there any regular init routine in the disassembly? Well, I am not familiar enough with the 7800 software to be able to tell that, lol!! I was trying to track the accesses to the SWCHA and INPTx to try to understand the protocol, but the dissassembled code still have many blocks marked as data but still with relevant code for instance: LDFB8: .byte $A9,$08,$8D,$81,$02,$20,$F6,$DF,$90,$24,$85,$93,$20,$F6,$DF,$90 .byte $1D,$0A,$0A,$0A,$05,$93,$85,$93,$20,$F6,$DF,$90,$11,$6A,$6A,$6A .byte $29,$C0,$05,$93,$85,$93,$A9,$0F,$90,$24,$85,$93,$93,$38,$60 * = $0000 DFB8 A9 08 LDA #$08 DFBA 8D 81 02 STA $0281 -> SWACNT DFBD 20 F6 DF JSR $DFF6 DFC0 90 24 BCC LDFE6 DFC2 85 93 STA $93 DFC4 20 F6 DF JSR $DFF6 DFC7 90 1D BCC LDFE6 DFC9 0A ASL A DFCA 0A ASL A DFCB 0A ASL A DFCC 05 93 ORA $93 DFCE 85 93 STA $93 DFD0 20 F6 DF JSR $DFF6 DFD3 90 11 BCC LDFE6 DFD5 6A ROR A DFD6 6A ROR A DFD7 6A ROR A DFD8 29 C0 AND #$C0 DFDA 05 93 ORA $93 DFDC 85 93 STA $93 DFDE A9 0F LDA #$0F DFE0 90 24 BCC $E006 DFE2 85 93 STA $93 DFE4 93 ??? DFE5 38 SEC DFE6 60 LDFE6 RTS and furthermore, I did not understand why the dissassembler haven't decoded the LDA $90. Maybe I am using the wrong option (-pafs7) ? LDFF6: .byte $A5,$90 -> LDA $90 LDFF8: STA SWCHA ;4 EOR #$08 ;2 STA $90 ;3 LDFFF: LDA INPT5 ;3 AND #$80 ;2 CMP $91 ;3 BEQ LDFFF ;2 STA $91 ;3 LDA SWCHA ;4 AND #$07 ;2 SEC ;2 RTS ;6 Quote Link to comment Share on other sites More sharing options...
Tempest Posted April 13, 2022 Author Share Posted April 13, 2022 12 minutes ago, Mitch said: I wonder if John Hardie has a copy. I know he has a keyboard. I can ask. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 13, 2022 Share Posted April 13, 2022 1 minute ago, Danjovic said: I was trying to track the accesses to the SWCHA and INPTx to try to understand the protocol, but the dissassembled code still have many blocks marked as data but still with relevant code for instance: [...] and furthermore, I did not understand why the dissassembler haven't decoded the LDA $90. Maybe I am using the wrong option (-pafs7) ? Try using a distella config file containing the text "CODE C000 FFFF". The LDA $90 wasn't used because distella is only marking reachable stuff as code. (reachable here means that 6502 vectors reach it, or some other disassembled reachable region jumps/branches there) Marking everything as code should help, but it runs the risk of data in the middle of the code messing up the instruction alignment. Modifying the distella config file iteratively, as you discover these regions, is part of the normal process. 10 minutes ago, Mitch said: Can you see what is going on with the joystick code on the temperature module? I'll have a look tonight. Gotta get back to the 9-5. 1 Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 13, 2022 Share Posted April 13, 2022 (edited) I was more happy with option -kad7 Seven references to SWCHA, either to read and write. I start to suspect that SWCHA bits 0,1,2 are being used for data while bits 3 is being used for signaling along with INPT5 (ack?) styper-kad7c.asm Edited April 13, 2022 by Danjovic Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 13, 2022 Share Posted April 13, 2022 6 hours ago, Karl G said: Sounds super cool to me, at least! I'd been playing around with making a simple BASIC interpreter, with a big challenge being the input portion. I had played with creating my own driver in a7800 that uses the 31 combinations of joystick/fire button inputs to use as keyboard input (with a shift-lock to access more characters), but I had no way to implement it on the hardware end. If someone figures out the original protocol, I'd happily change my code to use it instead. So - count me as interested in your project, and the possibility of hooking up a USB keyboard to the 7800. ? I wonder if the keyboard could run off the paddle lines: 2x228 possible combinations there. Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 13, 2022 Share Posted April 13, 2022 (edited) Some more code snippets. I think I figured out the protocol at a lower level. Most of it at least !! It really looks like the sequence for reading the keys is write saved value of line 'up' ($90) on bit 3 flip and save bit 3 line 'up' on ($90) wait until keyboard acks by flipping the line 'fire' read 3 bits [CBA] write saved value of line 'up' ($90) on bit 3 flip and save bit 3 line 'up' on ($90) wait until keyboard acks by flipping the line 'fire' read 3 bits [FED] combine bits read into a byte at $93 [00FEDCBA] write saved value of line 'up' ($90) on bit 3 flip and save bit 3 line 'up' on ($90) wait until keyboard acks by flipping the line 'fire' read 3 bits again (and return with carry set) [IHG] rotate bits right 3 times so you have after return and mask upper bits and add to the remaining bits to have the final 2 bits. [HG][FED][CBA] LDFB8: LDA #$08 ; bit 3 (right U) as output, bits 210 (right DLR) as inputs STA SWACNT JSR LDFF6 ; Read bits 210 BCC LDFE6 ; ret if bit clear - should never happen STA $93 ; save JSR LDFF6 ; Read bits 543 BCC LDFE6 ; ret if bit clear - should never happen ASL ASL ASL ORA $93 ; $93 = 6 bits read [543][210] STA $93 JSR LDFF6 ; read 3 bits more [876] BCC LDFE6 ; ret if bit clear - should never happen ROR ROR ROR AND #$C0 ; 76xxxxxx ORA $93 ; 76543210 -> completed a byte received STA $93 LDA #$0F BCC LE006 STA $93 .byte $93 ;.SHA SEC LDFE6: RTS LDFF6: LDA $90 ; get last value LDFF8: STA SWCHA ; write on joystick port EOR #$08 ; toggle bit 3 (right UP) STA $90 ; save for next round LDFFF: LDA INPT5 ; read fire AND #$80 CMP $91 ; compare with last BEQ LDFFF ; repeat until fire button signal flipped STA $91 ; save this state (of fire button) LDA SWCHA ; read value from joystick port AND #$07 ; clear unneccesary bits SEC ; set carry flag RTS return Edited April 13, 2022 by Danjovic 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted April 13, 2022 Share Posted April 13, 2022 I am glad to hear it sends a full byte. In fact it appears to be expandable to send up to 9 bits, so perhaps that upper bit is how it multiplexes the SIO port and the keyboard. The BCC $E006 appears to branch/not branch based on the state of the 9th bit. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 13, 2022 Share Posted April 13, 2022 4 hours ago, Mitch said: Can you see what is going on with the joystick code on the temperature module? So.... after running this in the debugger and trapping on reads of the SWCHA joystick direction bits and the INPT# TIA button bits, It's actually reading for a single-button joystick press in the second port, but it just doesn't seem to be doing a heck of a lot with it. I don't see any reads from the joystick direction bits, so it's not like it's trying to read from a module and failing, nor does it seem to be trying to read the keyboard. (which would involve a read from SWCHA) Best guess is this module was a WIP, and not actually completed. Quote Link to comment Share on other sites More sharing options...
+batari Posted April 13, 2022 Share Posted April 13, 2022 31 minutes ago, RevEng said: So.... after running this in the debugger and trapping on reads of the SWCHA joystick direction bits and the INPT# TIA button bits, It's actually reading for a single-button joystick press in the second port, but it just doesn't seem to be doing a heck of a lot with it. I don't see any reads from the joystick direction bits, so it's not like it's trying to read from a module and failing, nor does it seem to be trying to read the keyboard. (which would involve a read from SWCHA) Best guess is this module was a WIP, and not actually completed. If I had to guess (without seeing the code, of course), maybe the temperature sensor is an analog device that waits for a cap discharge, like a paddle port, so whatever value is being sent is determined by how long it takes for the fire button going low, or something? Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 13, 2022 Share Posted April 13, 2022 55 minutes ago, batari said: I am glad to hear it sends a full byte. In fact it appears to be expandable to send up to 9 bits, so perhaps that upper bit is how it multiplexes the SIO port and the keyboard. The BCC $E006 appears to branch/not branch based on the state of the 9th bit. Indeed! After the rotates the bit 2 of the last read remains on carry!! Well noticed!!! Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 13, 2022 Share Posted April 13, 2022 24 minutes ago, batari said: If I had to guess (without seeing the code, of course), maybe the temperature sensor is an analog device that waits for a cap discharge, like a paddle port, so whatever value is being sent is determined by how long it takes for the fire button going low, or something? Yeah, you'd think so. I haven't disassembled it and worked through it to add context, but I did trap reads from $08-$0D (INPT0-INPT5) and $280. (SWCHA) The only hit I ever get is the $0D (INPT5) fire button test, even after triggering that fire button press. Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 13, 2022 Share Posted April 13, 2022 (edited) Speaking of dead code I think I found some too on the star typer. What I am missing is some kind of sync on the protocol, to make sure that we have the right bits every call of the $dff6 subroutine. I think I found one place where bits are being written to the port but I have to confess that the code is getting way above my knowledge of 6502 assembly. LDE21: a9 0f 8d 80 02 8d 81 02 A9 E0 20 1E DE24 A9 0F LDA #$0F DE26 8D 80 02 STA SWCHA DE29 8D 81 02 STA SWACNT DE2C A9 E0 LDA #$E0 LDE22: 0f 8d 80 02 8d 81 02 A9 E0 20 1E DE22 0F ??? DE23 8D 80 02 STA $0280 DE26 8D 81 02 STA $0281 DE29 A9 E0 LDA #$E0 LDE24: 80 02 8D 81 02 A9 E0 20 1E DE24 80 ??? DE25 02 ??? DE26 8D 81 02 STA SWACNT DE29 A9 E0 LDA #$E0 LDE21: ; not referenced Dead code? LDA #$0F LDE23: STA SWCHA STA SWACNT LDA #$E0 JSR LE01E BCC LDE18 ; -> sample current trigger state, save on #91, return with DEY BNE LDE24 ; ? makes no sense DEC $69 BNE LDE22 ; ? makes no sense LDA #$00 JMP LDFE7 ; write 3 bits then return ; sync ? LDE3C: LDA #$00 JSR LDFE7 ; write 3 bits in 0 then flip bit 3 JSR LDFB8 ; read a byte BCC LDE5E ; return if carry clear - should never happen STA $93 ; save byte read LDA $95 ; BNE LDE5F ; ?? LDX $93 ; BEQ LDE5E ; return if zero LDA LDEA0,X ; table index ? BCC LDE5E ; return if carry clear LDE55: STA $94 ; table return (scan code translation ?) JSR LDE8D LDA #$1E STA $95 LDE5E: RTS LDE5F: ?? Edited April 14, 2022 by Danjovic Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 14, 2022 Share Posted April 14, 2022 1 hour ago, Danjovic said: Speaking of dead code I think I found some too on the star typer. I think you're seeing bitrot. The frequency of weird stuff sprinkled around otherwise sensible looking code was pretty high. You should focus on the Light Module program instead, since that appears to be fine. Based on a quick search I did for hex sequences, it has pretty much the same keyboard driver code inside. 1 Quote Link to comment Share on other sites More sharing options...
+sramirez2008 Posted April 14, 2022 Share Posted April 14, 2022 The forensic analysis taking place within this thread is really cool to see. You guys really are magicians.? 6 Quote Link to comment Share on other sites More sharing options...
Tempest Posted April 14, 2022 Author Share Posted April 14, 2022 I really do appreciate everyone looking into these roms. I just wish I had know the Star Typer ones were bad before Curt passed so maybe he could have redumped them. I'm trying to find out where the prototypes are now. I believe I may have a lead on that. 1 Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 14, 2022 Share Posted April 14, 2022 A couple of pics from Curt's old website. Mitch 2 Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 14, 2022 Share Posted April 14, 2022 At this point I think it is safe to tell the pinout of the keyboard. The data lines are visible wired or, which means that they can float or they can be held at zero, which makes plain sense given the datasheet of the pic microcontroller used on the keyboard. Pin Name Direction (keyboard centric) 1 Data0 bidirectional 2 Data1 bidirectional 3 Data2 bidirectional 4 Strobe 7800->Keyboard (input) 5 n.c. 6 Ack Keyboard->7800 (output) 7 Vcc 8 Gnd 9 n.c. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 14, 2022 Share Posted April 14, 2022 After looking at the sticker on the Temperature Module eprom... 8 hours ago, Mitch said: ...I had another look at the temperature module code, and I see the hex that corresponds to @Danjovic's disassembled keyboard driver. (hence the attempted read from INPT5 I was seeing in the debugger) So true to the sticker, the Temperature Module does seem to be a WIP that only has the keyboard driver implemented. Quote Link to comment Share on other sites More sharing options...
Danjovic Posted April 14, 2022 Share Posted April 14, 2022 2 hours ago, RevEng said: You should focus on the Light Module program instead, since that appears to be fine. Based on a quick search I did for hex sequences, it has pretty much the same keyboard driver code inside. Indeed, the code looks more polished. The clear flag is used to indicate failure by timeout. Some code simply decrement a variable as a countermeasure to timeout, but other subroutines use a value at $bc that I suppose it is decremented by a timer. Nevertheless I did some annotation on the code for the light module. lightmodule.asm 2 Quote Link to comment Share on other sites More sharing options...
Tempest Posted April 14, 2022 Author Share Posted April 14, 2022 Same Curt didn't give me the Video Writer or BASIC roms. I wonder what that non-booting prototype was? I can't read the labels very well but it looks like some sort of code/part number. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.