loading to $f000 does something weird

jasin commented 5 years ago

I've found a rather weird bug, I can't really explain it but maybe these code segments will help. But loading the same binary file to two different addresses leaves different results. Specifically to $f000 is broke. I've tried $0000, $0100, $f100 with success. It seems to be just $f000 that is causing the issue.

        PC  AC XR YR SP NV-BDIZC
65C02: 0000 00 00 00 ff 00110000
.reset

        PC  AC XR YR SP NV-BDIZC
65C02: 0000 00 00 00 ff 00110000
.load KERNEL.SYS f000
ÿWrote +110 bytes from $f000 to $f06d

        PC  AC XR YR SP NV-BDIZC
65C02: 0000 00 00 00 ff 00110000
.disassemble f000:f0ff
$f000  a2 ff     LDX #$ff
$f002  9a        TXS
$f003  d8        CLD
$f004  00        BRK
$f005  6a        ROR A
$f006  a2 f0     LDX #$f0

notice the weird character before wrote and the weird instruction at $f004:$f005

while any other address i use to load works...


        PC  AC XR YR SP NV-BDIZC
65C02: 0000 00 00 00 ff 00110000
.reset

        PC  AC XR YR SP NV-BDIZC
65C02: 0000 00 00 00 ff 00110000
.load KERNEL.SYS f100
Wrote +110 bytes from $f100 to $f16d

        PC  AC XR YR SP NV-BDIZC
65C02: 0000 00 00 00 ff 00110000
.disassemble f100:f11f
$f100  a2 ff     LDX #$ff
$f102  9a        TXS
$f103  d8        CLD
$f104  a9 6a     LDA #$6a
$f106  a2 f0     LDX #$f0````

jasin commented 5 years ago

It should also be noted that the documentation and the program don't coincide

reset will clear breakpoints, not just labels

       PC  AC XR YR SP NV-BDIZC
6502: f102 00 ff 00 f9 10110100
.reset

       PC  AC XR YR SP NV-BDIZC
6502: 0000 00 00 00 ff 00110000
.show_breakpoints
Breakpoint 0: $F100
Breakpoint 1: $F101
Breakpoint 2: $F102

SamCoVT commented 5 years ago

Jasin,

This is expected behavior for py65mon, as the input and output locations are at $F001 and $F004 by default.

The funny character you see is whatever was written to $F001, while $F004 will read back as a BRK (ASCII value 0) when a key has not been pressed. The input and output is handled at the memory level, so these addresses will respond that way even if it's the monitor loading or reading those addresses.

To solve your problem, see the top of "py65/monitor.py" where it says:

py65mon -- interact with a simulated 6502-based system
Usage: %s [options]
Options:
-h, --help             : Show this message
-m, --mpu <device>     : Choose which MPU device (default is 6502)
-l, --load <file>      : Load a file at address 0
-r, --rom <file>       : Load a rom at the top of address space and reset into it
-g, --goto <address>   : Perform a goto command after loading any files
-i, --input <address>  : define location of getc (default $f004)
-o, --output <address> : define location of putc (default $f001)

If you use the -i and -o options to provide new addresses (that aren't used by your ROM) then it should behave as you are expecting it to.

BigEd commented 5 years ago

Thanks for fielding this @SamCoVT!

mnaberez / py65

loading to $f000 does something weird #53