I think I found out why the silentype /// bidirectional printing is a little strange. There's a small stretch of code that does some addition on a two byte value, and curiously it adds an extra 1 when the low byte overflows.

You 6502 guys would be able to figure this out. Me, it takes forever. 8-) I had to keep looking at it over and over again to figure out what was happening because it's subtle.

[Linked Image from i.imgur.com]

It calls jsr $4ada which is just a lda #$05, rts. After that returns it clears the carry flag, adds $3e86 and pushes the flags on the stack. Then it adds $3ea2 which is the intercharacter gap, and stores it to $3e86. Then it adjusts $3e87 and increments it if the second addition had a carry flag set, then pulls the flags off the stack and increments $3e87 again if the first addition had the carry flag set.

Before it adds $3ea2 it doesn't clear the carry flag, so when that first addition of #$05 and $3e86 overflows it gets an additional +1.

If the line is 40 characters (starting at a horizontal position of 12 and each character being 5 pixels wide + 1 pixel gap you get an hpos of 6*40+12=252).
If the line is 41 characters the hpos crosses the 255 value and when it adds 6 to 252 it jumps from 252 to 259 with the addition of the carry flag.

So 259=0x103 instead of 258=0x102.

I wonder if this was actually deliberate as the stepper motors were inaccurate and that was empirically determined to compensate for that. Or it could just be a bug. Of course we're not emulating the mass and acceleration of the motors and printhead, but an idealized stepper motor which perfectly and instantaneously jumps from location to location.

So what if we try to patch it?

< 4278: 08       php
< 4279: 6D A2 3E adc $3ea2
< 427C: 8D 86 3E sta $3e86
< 427F: 90 03    bcc $4284
< 4281: EE 87 3E inc $3e87
< 4284: 28       plp
< 4285: 90 03    bcc $428a
< 4287: EE 87 3E inc $3e87
> 4278: 90 03    bcc $427d
> 427A: EE 87 3E inc $3e87
> 427D: 18       clc
> 427E: 6D A2 3E adc $3ea2
> 4281: 8D 86 3E sta $3e86
> 4284: 90 03    bcc $4289
> 4286: EE 87 3E inc $3e87
> 4289: EA       nop

I can get the code in with one byte left over as a nop, and that seems to get the bidirectional lines to line up as expected.

Some other interesting bits from fiddling:

When the silentype is active, you can't read any of the joystick buttons or paddles. Closing the silentype device with CLOSE #1 will make them available again.


[Linked Image from i.imgur.com]

3F4D seems to be the main driver entry so "bp 3f4d" will stop right on entry to the driver.

Executing a source command (eg "source debugcmd1.txt") from the debugger window will only work if the debugger is paused first. Otherwise, it seems to have no effect.

Executing a trace command with the apple /// must be done with the maincpu as an argument (ie 'trace mytrace1.txt,maincpu,,{tracelog "A=%02x X=%02x Y=%02x P=%02x PC=%02x >>> ",a,x,y,p,pc}' otherwise you end up with completely empty trace files.

The history command will blow up the apple3 debugger if you type "history ,5". You need to give it "history maincpu,5". Just plain old "history" works but you don't always want 200 history entries 8-)