7800 Keyboard

[Tempest]

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?

[RevEng]

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.

 

 

[Tempest]

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.

[+Mitch]

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

[+Mitch]

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

[Danjovic]

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

 

[Tempest]

12 minutes ago, Mitch said:

I wonder if John Hardie has a copy. I know he has a keyboard.

I can ask.

[RevEng]

 

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.

 

 

[Danjovic]

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

[Synthpopalooza]

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.

[Danjovic]

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

[+batari]

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.

[RevEng]

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.

 

[+batari]

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?

[Danjovic]

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!!!

[RevEng]

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.

[Danjovic]

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

[RevEng]

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.

 

[+sramirez2008]

The forensic analysis taking place within this thread is really cool to see.  You guys really are magicians.?

[Tempest]

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.

[+Mitch]

A couple of pics from Curt's old website.

 

Mitch

 

[Danjovic]

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.

 

[RevEng]

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.

 

[Danjovic]

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

[Tempest]

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.