search

MEGA65 / mega65-rom-public

MEGA65 ROM public issue reporting
4 stars 0 forks source link

MONITOR: Fill can't fill Attic RAM properly #141

Closed dansanderson closed 1 week ago

dansanderson commented 1 week ago

MONITOR's Fill command appears to be counting addresses incorrectly when they're up in the Attic RAM range.

MONITOR
>08000000 01 02 03 04 05
M8000000
F8000000 8000010 00
M8000000

... should result in writing 16 bytes from 8000000 to 800000F with 00, but instead only writes a single 00 to 8000000 then stops. (M displays 00 02 03 04 05 ...)

johnwayner commented 1 week ago

I can't reproduce this. However (and I think I saw this mentioned somewhere but not can't find it now) it does write one extra byte:

                      ◤
                   ◤       THE MEGA65 PERSONAL COMPUTER SYSTEM
                ◤
             ◤        (C) 2021 MEGA, 1991 COMMODORE, 1977 MICROSOFT
           ◤
         ◤                BASIC 65 V920402 26-JUN-2024 21:00:22

 READY.
 MONITOR

 BS MONITOR COMMANDS:ABCDEFGHJMRTUX@.>;?$+&%'LSV
     PC   SR AC XR YR ZR BP  SP  NVEBDIZC
 ; 00FFA2 00 00 00 00 00 00 01F8 --------
 M 8000000 8000020
 >08000000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ????????????????
 >08000010 FF 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 ?UUUUUUUUUUUUUUU
 F8000000 8000010 00

 M 8000000 8000020
 >08000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 >08000010 00 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 .UUUUUUUUUUUUUUU

I'm running the latest commit of the rom (40570e8) and this info:

 MEGA65 INFORMATION                                    (C) 2022 MEGA - MUSEUM OF
 ━━━━━━━━━━━━━━━━━━                                       ELECTRONIC GAMES & ART

 MEGA65 MODEL:  MEGA65 R3                SCREEN MODE:  NTSC

 ARTIX VERSION: 0915D2E8  2024-02-06     RTC STATUS:
 MAX10 VERSION: 298C5214  2022-03-23
 KEYBD VERSION: FFFFFFFF  2064-10-05

 HYPPO/HDOS:    1.2 / 1.2                HYPPO STATUS: NORMAL
 ROM VERSION:   M65 V920402

 FREEZER.M65:  240206.09-R0.3.0-18A3C1A  ETHLOAD.M65:  240206.09-683CAR-0915D2E
 MEGAINFO.M65: 240206.09-R0.3.0-18A3C1A  MONITOR.M65:  240206.09-R0.3.0-18A3C1A
 MAKEDISK.M65: 240206.09-R0.3.0-18A3C1A  ROMLOAD.M65:  240206.09-R0.3.0-18A3C1A
 AUDIOMIX.M65: 240206.09-R0.3.0-18A3C1A  SPRITED.M65:  240206.09-R0.3.0-18A3C1A
johnwayner commented 1 week ago

I suppose it should be a separate issue, but I suspect the off-by-one error will effect:

It's an artifact of how the loops around Dec_LCT work. Long_CT is the count (1-based) but Dec_LCT only sets the NEG flag (not ZERO), so all the loops loop down past zero. For example, an LCT of 2 will net you (2, 1, and 0) then the loop ends.

Fixing it for FILL is easy (just decrement it before entering the loop). But something like TRANSFER is more complicated.

An option is to consider this a documentation bug :)

dansanderson commented 1 week ago

huh, now I can't repro. Probably just a mistake. Closing.

Fill is treating its range as inclusive, which I don't consider to be a bug unless it's inconsistent with other behaviors.

johnwayner commented 1 week ago

The documentation says the second parameter is one more than the desired final location. Probably because monitors were usually like that.

It's like that for at least transfer too. Probably others.