mega65 / mega65-rom-public Goto Github PK

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 2f545d1

Describe the bug
BASIC 65's CHAR "XXX" writes a string of characters to a graphics screen. If any of the characters are in the PETSCII range $60-$7F (uppercase letters or glyphs), they get printed as $20-$3F (numbers, punctuation). They should instead be converted to screen $40-$5F.

This looks like a bug is in the petpok routine, which currently converts all of PETSCII $40-$7F to screen codes by subtracting $40. This just needs a few more lines to handle this range separately.

I don't yet have an explanation for this: CHAR ..., CHR$(115) writes "3" (incorrect, explained by petpok), but CHAR ..., "{shift-S}" writes a heart symbol (correct).

To Reproduce

10 SCREEN 320,200,1
20 CHAR 3,3,1,1,2,"HI "+CHR$(115)+" HI {shift-s}",$2D000
30 GETKEY A$
40 SCREEN CLOSE

Expected behavior
This should write "HI {heart} HI {heart}" to the graphics screen. Instead it writes "HI 3 HI {heart}".

Screenshots

Additional context
c65.char -> kg65.char ... nxtchr -> petpok

• Platform: MEGA65
• ROM Release: 920376
• Core Commit: f555316

Describe the bug
CHARDEF takes a character set index as its first argument. It only supports a byte value from 0 to 255. There are 512 characters in a character set, with the upper 256 being lowercase mode characters. CHARDEF 256,... throws an ?ILLEGAL QUANTITY ERROR

To Reproduce
CHARDEF 256,$01,$02,$04,$08,$10,$20,$40,$80

Expected behavior
This should change the @ character in lowercase mode only to a thin diagonal line.

Is your feature request related to a problem? Please describe.
Too often, I accidentally hit the HOME key when reaching for the DEL key. I then have to struggle with cursor movements to get back to what I was doing. This feels especially fragile with a long un-entered line. (And for what it's worth, I have the same problem on Commodores. MEGA is just in a position to do something about it.)

Describe the solution you'd like
When I press HOME in the BASIC editor while not in quote mode, MEGA remembers the previous cursor position, then homes the cursor. If I press ESC then HOME, the cursor moves to the previously stored position.

Describe alternatives you've considered
A small general purpose undo-typing buffer could be interesting. I would expect it to clear after pressing Return because it can't undo commands. There might be too much state to track, and too little utility for the cost.

A home-to-bottom keystroke might reduce some of the pain of re-finding the location, without fully solving the problem if a full solution is impractical.

I briefly considered whether stored cursor positions could be more generally useful, like a cursor home ring buffer or something. Given the nature of the screen editor, I think this would have limited usefulness. But maybe just the single stored position could be used in ways other than an "undo HOME": I home the cursor to store a position, move the cursor somewhere else to do something, then ESC + HOME to restore. Again, the nature of the screen editor limits the usefulness. But it's a natural consequence of the feature as I described it.

I'm grateful for all of the BASIC 10 and BASIC 65 cursor movement options and I haven't memorized them all yet, so maybe restoring my position manually just takes some practice.

The 80x50 BASIC editor mode (in ROM 990003, being considered for promotion to 92xxxx) uses the BASIC 65 graphics subsystem when in 80x50 mode. I think it makes sense that, while in 80x50 mode, there is less graphics memory available for SCREENs. However, it is less intuitive that once 80x50 mode is selected, the graphics memory remains allocated even if the user switches back to 80x25 or 40x25 mode. Ideally, switching back would free graphics memory for use by programs, undoing the major effects of switching to 80x50 mode that affect program execution.

For example, Intro Disk #1 has two programs that attempt to open a 640x400 screen: FBBS demo and Vector Clock. These programs succeed when started after a reset, in 80x25 mode. If I switch to 80x50 mode (ESC+5), switch back to 80x25 mode (ESC+8), then start either of these demos, they fail with "out of memory error."

(Note for repro'ing: there's a bug in ROM 990003 that prevents Intro Disk #1's menu from starting. This bug will be reverted in a later version. When using ROM 990003 specifically, you can load these demo programs directly from MEGA65.D81.)

I don't think this is a big enough issue to withhold 80x50 mode from promotion to beta. It would be a valuable improvement to 80x50 if it would free unused screen memory.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 93d55f0

Describe the bug
If the CIA timers used for the SLEEP command are about to wrap, and you issue a SLEEP command that would extend beyond the wrap time, the SLEEP command never ends. This normally happens ~72 minutes after the computer was started. This is because the 32-bit timer at $dd04 (actually two timers working together, timer A and timer B) wrap after 2^32 microseconds, or ~4300 seconds. (I found this by reading the source code of the ROM)

To Reproduce
Steps to reproduce the behavior:
Run this:

10 print int(ti)
20 sleep 10
30 goto 10

If you run this when the computer starts, it will keep printing a number every ten seconds, until it reaches ~4300. Then it stops.

Expected behavior
SLEEP should finish normally after the number of seconds specified.

Screenshots

Additional context

@ruesch repoted this as MEGA65/mega65-core#563

The following bugs have been noticed (80Column Mode). I used the original 1351 Mouse and a USB Mouse with Micromys V5.

The results are the same:

• If i use the "MOUSE ON,1" Command in Basic Programs, its impossible to abort with RUNSTOP, only RUNSTOP/RESTORE works.

• The Sprite jumps over some pixels in all directions. its difficult to reach a special position.

• The x and y coordinates in RMOUSE seems not correct. If i move exact 64 pixels in x-coordinate RMOUSE shows only a difference about 31 pixels.

the x,y parameter in MOUSE ON doesn't work.

in direct mode i can reactivate the machine only with RUNSTOP/RESTORE.

See also: https://www.forum64.de/index.php?thread/126476-bugs-in-mouse-command/

Is your feature request related to a problem? Please describe.
The BASIC 10 CHAR command writes a character glyph to a graphics screen. It accepts a pixel coordinate for the Y location (row), but only accepts a character coordinate for the X location (column).

Describe the solution you'd like
To reuse the CHAR keyword, we'd need an argument syntax, ideally in line with the rest of the BASIC API, to differentiate between the variants. We should do a holistic review of the API to decide the style, but one option may be a letter prefix:

rem X/Y prefix indicates pixel coordinate
CHAR X251,Y183,1,1,2,"STRING TO PRINT",$29000

rem Absent a prefix, use the default: char for X, pixel for Y
CHAR 31,183,1,1,2,"STRING TO PRINT",$29000

The implementation would be inherently slower when using an X coordinate that is not a multiple of 8. It may not be noticeable enough to notice.

Describe alternatives you've considered
Alternate syntaxes:

• New keyword, probably easiest to implement: CHARXY 251,183,1,1,2,"STRING TO PRINT",$29000
• Alternate argument syntax for a coordinate, maybe useful elsewhere in the API: CHAR (251,183),1,1,2,"STRING TO PRINT",$29000
• Also support C and R prefixes for "column" and "row" for API symmetry, i.e. allow char coords for the row as well as the column: CHAR C31,R22,...
• Use P for pixel and C for char coordinates: CHAR P31,P183,... The default prefixes are C for the column and P for the row.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 93d55f0

Describe the bug
The BASIC 65 POT() function (borrowed from BASIC 7) is described in the manual as taking a paddle controller number 1-4 and returning a BASIC number with the paddle turn position in the lower byte from 0 for full clockwise to 255 for full counterclockwise, and "a value greater than 255" (a bit set in the upper byte) to indicate the fire button is pressed.

A previous ROM maintainer described paddle support as "incomplete," and this can be seen through simple testing of the four POT() return values. Actual behavior:

• When paddles are connected to port 1, POT(1) and POT(3) both show turn position for paddle X, and POT(2) and POT(4) show turn position for paddle Y. Fire buttons set bit 8 (+256) correctly in only POT(1) and POT(2).
• When paddles are connected to port 2, turn position is 255 (no paddle connected) for all four POT() values. Fire buttons set bit 8 (+256) correctly in only POT(3) and POT(4).

Also: Paddle turn range is 0-180 for Commodore paddles and 0-255 for Atari paddles. Atari paddles also have a bit of rotation beyond 255 that is not reported. This is not a bug but a classic known difference: Commodore paddles use a potentiometer 2x the resistance of Atari paddles. This is worth mentioning in the manual for POT(). (I don't think it's practical to account for this in code. Paddle games can "calibrate" by asking the user to turn all the way in both directions and press fire to read the max value.)

To Reproduce

10 PRINT POT(1),POT(2),POT(3),POT(4)
20 GOTO 10

Connect paddles to port 1 and try turns and button presses on both paddles. Connect paddles to port 2 and try turns and button presses.

Expected behavior
To meet the description in the manual, two sets of paddles connected to both ports should report as 1X, 1Y, 2X, and 2Y on POT(1), POT(2), POT(3), POT(4) respectively.

I don't believe ROM code should account for Atari vs. Commodore paddle types, and instead the manual should be updated with information about the paddle type differences.

There was some work done in 2022 to implement D64 disk image support for the MEGA65. This October 2022 commit to the development branch appears to have been an attempt to fully enable this feature, but it had to be held back when it was noticed to cause read errors with the physical floppy drive in some machines: https://github.com/MEGA65/mega65-rom/commit/0581a9cae253961789b193b825a9cf8a141b156b

I am creating this issue to gather intel on what work is left to do for this feature, and to track it to completion.

Bit Shifter's comment from September 2022:

Commodores command BACKUP was implemented on dual floppy drives only, for example 3040, 4040, 8050, 8250. CBDOS handles two drives too, so it is implemented in a similar way. The fact, that the two CBDOS drives are mapped to different units (default 8 and 9) for the user but are used like the two drives of a dual drive unit internally, confuses many users and developers, but that's the way, the C65 developers decided to do it. So currently the BACKUP command can only backup between the two internal drives, which can be the real floppy drive or a mounted D81 image on the SD card. And even then it works only reliable, if the BASIC mount command was usedfor unit assignment, freezer mounts do not work in many cases. I planned to extend the BACKUP command for D64 and 1541 IEC drives, butfor that case I need a working D64 protocol between ROM and hyppo. The COPY command is a similar case. Commodores COPY command could not copy amongst different units. I implemented an extension, which can now copy files among IEC drives and internal drives too.

This is already implemented in the ROM, track, sector layout, BAM position and layout, header, directory, all of it. What is missing: A return value from the hyppo mount call, which tells, whether a D81 or a D64 image was mounted and an agreement with the hyppo maintainer, whether tracks and sectors of a D64 image are are treated in raw form or translated to the D81 layout.

Reply from lydon:

GS $D68A.6 SDFDC:D0D64 F011 drive 0 disk image is D64 mega image if set (otherwise 800KiB 1581 or D65 image) GS $D68A.7 SDFDC:D1D64 F011 drive 1 disk image is D64 image if set (otherwise 800KiB 1581 or D65 image)

Since ROM Release 920315 there are issues with the U1 & U2 commands.

I used this program

10 open 15,8,15
20 open 5,8,5,"#"
30 for i=0 to 4
40 for t=0 to 255
50 print#5,chr$(i+65);
60 next
70 print#15,"u2";5;0;1;i
80 next
90 for i=0 to 4
100 print#15,"u1";5;0;1;i
110 for t=0 to 255
120 get#5,a$:if a$<>chr$(i+65) then print"error":stop
130 next
140 next
150 close 5
160 close 15

and used vice tools to convert it.

petcat -w2 -o test.prg -- test.txt
c1541.exe -format "test,tst" d81 test.d81 -write test.prg

Up to ROM 920314, sector 0 will have A written 256 times, sector 1 will have B written 256 times, etc up to sector 4 which will have E written 256 times. This is the expected behavior and matches a commodore IEC drive hooked up to a c64.

In 920315 and later, the write and read appear to be skipped and the get#5 just returns what is in the buffer. In this test program A$ will contain E when it expects an A, but I was getting the disk header when I first noticed the issue.

I have only been able to test it in xemu (I'm using latest commit on next branch lgblgblgb/xemu@4b62b10)

I originally noticed the issue in c64 mode, but I have run this test in basic 65 and it shows the same behavior.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65 and xemu (same result on both)
• ROM Release: (i.e. 920376)
• Core Commit: f555316

Describe the bug
An assembler program that opens a new SEQ file for writing, writes n bytes to it and then closes it, in C64 mode on the MEGA65 core, creates a file of n - 1 bytes, where the last written byte is missing.

To Reproduce
Steps to reproduce the behavior:

1. Mount the included disk image.
2. go 64
3. load "*",8,1
4. sys 49152
5. Look at the code at $c000, or read the enclosed source code
6. Examine the new seq file "test"
7. The program clearly writes "abc" to the file, but the file only contains "ab".

rombug.zip

Expected behavior
The file should contain "abc"

Screenshots

Additional context
Running the same program in VICE C64 (x64) results in all the values being written to the file.

Approximately 25% of r3 boards to date have issues with the internal Real Time Clock (RTC) not working. We've sunk quite a few resources into fixing or working around this issue and do not yet have a complete solution. No software depends on this feature.

The attached patch removes the date and time display from the BASIC welcome header, which is the most visible manifestation of RTC issues on affected machines. The RTC setting (working or otherwise) is still available via the TI$ and DT$ BASIC 65 variables, and is still visible in the Onboarding and Configuration interfaces. (I recommend we keep all other RTC features intact.)

disable_datetime_header.diff.txt

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920365
• Core Commit: 899cf4f (with unreleased DVI fix)

Describe the bug
String concatenation of a non-string (i.e. a string, the + operator, and non-string) should result in a type mismatch error. Instead, it generates a string of undefined characters.

To Reproduce
If you use the addition operator on a number and a string, it correctly results in a type mismatch error:

READY.
? 3 + "HI"

?TYPE MISMATCH ERROR
READY.
_

If you use the string concatenation operator on a string and a number, it generates a string of garbage characters:

READY.
? "HI" + 3
(... stuff ...)

X$ = "HI" + 3

READY.
? X$
(... stuff ...)

Expected behavior
The Commodore 128 raises a type mismatch error in this case. This is what MEGA65 should do.

Screenshots

Test Environment (required)
You can use MEGA65INFO to retrieve this.

Platform: MEGA65
ROM Release: 920377
Core Commit: 93d55f0

Describe the bug
Trying to save a program (save or dsave) which requires more space on disk than is available, makes the system crash/hang and leaves a non-closed file on the disk.

To Reproduce

• Attach mega65.d81 floppy image (131 blocks of free space).
• Load autoboot.c65 resp. menu (148 blocks).
• Use save or dsave to save with a different name (e.g. save "test")

Expected behavior
save/dsave should fail with an error message and give control back to the kernal.

Additional context
I have tried this with two floppy images, but not with a physical disk.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: xemu; also verified on MEGA65
• ROM Release: 920376; also verified in 920383

Describe the bug
PEN hangs if a graphics screen isn't active, but was before.

To Reproduce

1. PEN 3. Nothing happens.
2. SCREEN 320,200,2:SCREEN CLOSE. Screen opens then immediately closes.
3. PEN 3. Computer hangs.

Expected behavior
PEN and all other graphics system commands that operate on an open screen should throw ?SCREEN NOT OPEN ERROR when a screen is not open. Most screen commands do this already. This includes both PEN cases described above.

Additional context
Original forum64.de report.

It may not be worth trying to understand why PEN fails the way it does with a missing precondition. For what it's worth, the hang is in a loop near $A2DA in 920383, which is a junk location (a text message in the C64 kernel).

From Snoopy:

After adding "jsr CheckGraphicMode" right after "c65.setpen: " in line 18527 in b65.src will fix this issue.

We should vet the other graphics commands for similar behavior and make the implementation consistent. Most of the graphics system is implemented in c65.* and kg65.* routines in a sensible layout.

The development branch ROM currently contains a proposed feature to initialize the BASIC 65 sprite data on boot. There are two goals for this feature:

1. Initialize sprite 0 to a mouse cursor, such that MOUSE ON immediately shows a usable default mouse cursor sprite.
2. Initialize sprites 1-7 to someone non-transparent and non-garbage, so BASIC programmers experimenting with sprites can get an immediate result without loading sprite data.

SteerCo supports these goals and believes this feature is worth some ROM space. However, I'm concerned that the current implementation consumes 160+ bytes of ROM in a region where only 618 bytes remain.

This issue is to track an alternate implementation that consumes less ROM space, with a target of < 80 bytes. There's potential for a 16x16 mouse cursor (32 bytes) and algorithmically painted default data (e.g. a checkerboard pattern). I don't mind retaining the Forum64 Easter Egg if we can do it cheaply, e.g. make the cactus 16x16 and keep the init routine < 16 bytes (!).

Just like doing a DLOAD "$$" and then LISTP then it would be really great to have a DIRP possibility doing the exact same thing :-) This makes it easier for people and no need to type in two commands.

Even if this could be default when pressing F3, this would be nice, as a directory listing with many entries scrolls too fast with the normal DIR, but not pushing for it ;-) I am not sure, but think I have heard that it could be possible to substitute the function keys commands somehow, so guess this could be tweaked by myself?

I know of the alternative DIRW, but it is not possible to easily load files from the second or third column in this mode.

I know there are many other and more important things to take before this, but just wanted to have it visible in the potential future queue for new cool features :-)

Could USING be enhanced to support the zero-prepend option found in C?
For example, the BASIC command PRINT USING "%03d";7 would print 007 on the console.

I also think it would be useful if USING could also be leveraged independently of PRINT for assigning formatted values to a string variable.
For example, HX$="$%4X":A$=USING HX$;65000: REM A$="$FDE8"

Test Environment (required)

• Platform: MEGA65
• ROM Release: 990003
• Core Commit: 93d55f0

Describe the bug
Ozmoo fails to start with ROM 990003. I have narrowed this to the changes in the ioinit routine. As far as I can tell, the ROM functions without this change, so it can probably be rolled back. I have not found any cross-dependencies on this change in other development branch changes.

To Reproduce
Steps to reproduce the behavior:

1. Install and boot to 990003.
2. Mount and run an Ozmoo text adventure game disk.

We want to change the displayed name from
THE MEGA65 DEVELOPMENT SYSTEM
to something else, so it becomes clearer that this is the stable ROM.

Also the copyright notice needs to be changed to 2022.

Current contenders are:
THE MEGA65 PERSONAL COMPUTER SYSTEM (like C64C)
THE MEGA65 MICRO COMPUTER SYSTEM
THE MEGA65 HOME COMPUTER SYSTEM

Problem
On MEGA65, RUN-STOP+RESTORE does not reset anything related to the character glyphs set by CHARDEF. If a BASIC program replaces character graphics in a way that makes immediate mode commands difficult to enter then exits abnormally, the user may expect RUN-STOP+RESTORE to return the editor to a usable state (colors, clear screen, modes). With replaced glyphs, the user would have to know to type FONT C—possibly blindly—to fully restore the screen.

A user might especially expect the font to reset if they're used to a C64, which resets custom fonts by resetting the ROM bank switching used for custom characters. Notably, the C64 retains the custom font in RAM in this case.

Modest solution: Automatic FONT C
One solution is for RUN-STOP+RESTORE to perform the equivalent of FONT C as one of its reset behaviors.

It is possible that a user might be using FONT A or FONT B as a way to set the font of their editor experience, and not just within a program. These users would have to re-type FONT A or FONT B after RUN-STOP+RESTORE. A possible improvement: remember the most recent FONT command, and use that font as the reset font for RUN-STOP+RESTORE.

It is possible that a user might be using CHARSET to define a custom font for their editor experience, e.g. from an AUTOBOOT.C65 file. We may be able to leave this use case aside. Or we can consider a more ambitious solution.

Ambitious solution: font banks!
A font bank is a character set in memory assigned to a label. The current font bank is the one actively used to render characters. FONT <b> switches the current font bank to the font bank with that label.

A font bank with a single raw letter name is a read-only system font, such as A, B, or C. D-Z are reserved for future system expansion. A font bank with a numeric label is an allocated writeable font. All numeric labels begin uninitialized, with no memory allocated. When the current font switches to a writeable font bank that has not been initialized, it is allocated and initialized with the contents of the previously selected font bank. An allocated writeable bank remains in memory when the current font is changed.

CHARSET writes to the currently selected font bank. If the current font bank is a read-only bank, it copies the current bank to bank 0, switches to bank 0, then makes its update. (This is for backwards compatibility. Alternatively, it could just throw an error if the current bank is not writeable.)

FONT CLR deallocates the current font bank (if writeable) then switches to bank C. FONT LOAD <filename> [,D<drive>] [,U<unit>] loads font data from a file into the current bank. FONT SAVE <filename> saves font data from the current bank to a file. (Maybe FONT LOAD and FONT SAVE accept a [,B<bank>] parameter. Maybe LOAD when the current bank is read-only switches to bank 0 first.)

FONT COPY <b1> TO <b2> [,<n>...] copies the contents of one font bank to another; b2 must be writeable. If one or more screen codes n are provided, only those screen codes are copied.

All commands that accept a bank parameter also accept a parenthesized expression that evaluates to the bank label. (Only for numbers? Numbers and strings?)

In this solution, RUN-STOP+RESTORE switches to font bank C without loss of data. The user can restore any active font bank with the FONT command.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920353
• Core Commit: bdeeb15

Sometimes F9/F11 produce gibberish instead of scrolling through the Basic listing. Ctrl-P and Ctrl-V still work

To Reproduce
Steps to reproduce the behavior:

1. Type/paste in the full colour sprite mode example program in sprite appendix of the MEGA65 book.
2. Type LIST
3. Press F9

Expected behavior
The screen should scroll through the program listing.

Screenshots

Test Environment (required)

• Platform: MEGA65
• ROM Release: 990003
• Core Commit: 93d55f0

Describe the bug
With the 990003 experimental ROM, the demo disk menu breaks to the Monitor on the first screen.

To Reproduce

1. Install and boot to 990003 ROM.
2. Mount MEGA65.D81.
3. BOOT

Additional context
I narrowed this to an innocuous looking change to the SYS command:

Before (works):

***
sys
***
    jsr poke_sub     ;get 32 bit address lupo
    lda lupo         ;set up arg's for call to 'long jsr'
    sta _pclo
    lda lupo+1
    sta _pchi
    lda lupo+2
    sta _bank
...

After (doesn't work):

***
sys
***
    jsr poke_sub     ;get 32 bit address lupo
    ldq farptr       ;load SYS address
    sta _pclo
    stx _pchi
    sty _bank
...

There might be related changes to farptr handling in 990003. However, the full 990003 ROM exhibits this behavior, so it doesn't contain a fix. Reverting this change fixes it.

Test Environment (required)

• Platform: xemu
• ROM Release: 920370

Describe the bug
I just ran an really "ancient" test program of mine (still for the C65 emulator) on the current ROM and always got an error.

I was able to isolate the error: It occurs when you try to convert a string with VAL, which throws an OVERFLOW ERROR because the number in the string is too big. So far, so good and correct.

However, after that no command is accepted anymore, but only SYNTAX ERROR is output, no matter for which command.

To Reproduce

As a test you can simply use the direct mode A$="1234567890123456789012345678901234567890" (press four times the kieys from 1 to 0!), then a PRINT VAL(A$), which outputs the overflow error. After that no command works anymore.

As a comparison the same on the C65 emulator with the original C65 ROM 911210, where it continues without problems after the overflow error.

Screenshots

https://www.forum64.de/index.php?thread/127057-bug-report-val-overflow-error/

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 93d55f0

Describe the bug
If you issue the renumber command and supply the range argument, and this range of line number holds more than one line and the first line in the range isn't the first line of the program, you often get a Can't continue error.

To Reproduce
Enter this:

10 print 1
20 print 2
30 print 3
40 print 4

renumber 100,10,20

or:

renumber 100,10,20-30

However, this works:

renumber 100,10,15

Expected behavior
The lines I asked to be renumbered should be renumbered, and no error should occur.

Additional context
I haven't yet managed to pin down exactly which conditions make it fail.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 93d55f0

Describe the bug
The BASIC command reference documents the EDMA command as supporting two optional arguments. It is unclear from this documentation, but these populate the "command MSB" and "modulo LSB" fields of the DMA job. The actual implementation also accepts a third optional argument for "modulo MSB," and does not yet accept the modulus as a 16-bit value.

At minimum, the implementation should be improved to accept a 16-bit modulus as a single argument instead of two byte arguments. This would match the documentation. The documentation can be improved to describe these arguments more clearly.

The "command MSB" currently documented as the "sub-command" sets the addressing mode of the source and destination for a copy. This value is bit-packed: 00=linear, 01=modulo, 10=hold; source as bits 0 and 1 (of command MSB), destination as bits 2 and 3. This is not particularly user friendly compared to other BASIC commands, and might be better as separate arguments for source and destination addressing modes 0, 1, and 2.

The source and destination address arguments correctly support 28-bit addresses. Technically, they also support setting four additional bits directly on the address for further addressing configuration: 4=hold, 5=modulo, 6=direction, 7=I/O registers. These flags are not documented for EDMA, nor are they exposed as arguments. I'm guessing that hold and modulo are redundant with command MSB (but I could be wrong).

Proposed fix
Re-specify the EDMA command as:

EDMA command, length, source, target [,sourcemode, destmode [,modulus]]

sourcemode and destmode would accept byte values in the form of a bit pack that combines addressing mode (00=linear, 01=modulo, 10=hold) and remaining addressing flags (direction, I/O register enable). modulo would accept a 16-bit value. To be thorough, source and target should ignore bits 24-27.

This is technically backwards incompatible with what's currently written in the manual, but what's in the manual is already incorrect, so I don't think it meaningfully violates a contract. We can skim existing BASIC software on Filehost for uses of EDMA to be sure.

Alternatives considered
Re-specify the EDMA command to drop support for "sub command" and "modifier" (sic). Only support copy and fill with linear addressing (forward direction), no I/O registers.

Instead of (or in addition to?) numbers for commands and flags, accept string values in an extensible format. E.g. EDMA "C:M:HI",$200,$1800,$D020,$80 would copy the first $80 values starting at $1800 four times ($200/$80) into I/O register $D020 ("hold" addressing, I/O enabled).

Other questions
It is unclear whether and how EDMA should be prepared to support the "mix" command, given that it is not yet implemented. The current spec has MINTERM arguments in the command LSB, which is technically available today because EDMA does not mask bits of the command argument.

It is unclear whether and how EDMA should support MEGA65 job list tokens. The current implementation uses job list tokens internally for 28-bit addresses and selecting the F011B DMA list format. I'm comfortable omitting these features from BASIC, as a BASIC program can always write its own DMA job data to memory and invoke it via registers.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920356
• Core Commit: bdeeb15

Describe the bug
When making a program with exactly 23 lines and PAUSED LISTING it. The top line will not be listed as the ready prompt scrolls the screen.

To Reproduce
Steps to reproduce the behavior:

1. Make a program with 23 lines
2. LIST P

Expected behavior
Listing pause to show the first line

Screenshots
https://cdn.discordapp.com/attachments/805252939593416705/980001482831200276/unknown.png
https://cdn.discordapp.com/attachments/805252939593416705/980001637995262002/unknown.png

When POKE is used in conjunction with variable names that begin with B or W, mostly undesirable side effects occur.

The problem came to the attention of a user by chance, because he wondered why PRINT BF(BZ) works in his program and outputs 2594, but a POKE BF(BZ),1 does not put a 1 in the place of 2594. However, a POKE 2594,1 does work.

https://www.forum64.de/index.php?thread/118911-der-mega65-laber-stammtisch/&postID=1843717#post1843717

The reason is that POKE interprets the B of BF as a "POKE byte" and thus undesirably executes POKEB F(BZ),1.

The problem also occurs with variable names that begin with W because of POKE W.

The line POKE WF,65 lets crash the system!

For most people it will be not clear, why line 40 sends a syntax error, but line 20 not?

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 2f545d1

Describe the bug
When the initial value expression of a FOR statement is an array element, BASIC 65 throws a syntax error.

To Reproduce

10 DIM AB(10)
20 AB(0)=5
30 FOR X=AB(0) TO 10
40 PRINT X
50 NEXT

Expected behavior
Example should count from 5 to 10. Instead, it's a syntax error on line 30.

Additional context

• The breakage begins at ROM 920279.
• Same result for single-letter (fast) or double-letter array name
• Same result if the array reference is part of an expression: (AB(0)), or 3*AB(0), or AB(0)*3
• Same result regardless of the index
• Same result for integer array vs. number array: A%(0)
• Does not happen if the array reference is only in the final value expression: FOR X=1 TO AB(0)

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920376
• Core Commit: 80fc1c0

Describe the bug
Renumbering a basic program with THEN keyword will remove any whitespace that comes after THEN.

To Reproduce

1. Create a basic program like this:

10 IF I=0 THEN PRINT "HI"

3. Then run RENUMBER10,10
4. List the program and you'll see the removed whitespace between THEN AND PRINT.

10 IF I=0 THENPRINT "HI"

Expected behavior
It would be nice if the whitespace were preserved as it appears to be for other keywords

Additional context
It behaves the same whether it's a logical or numeric expression after the THEN keyword. I consider this low priority but wanted to document it.

Using the PLAY command causes issues if you send a new sequence to the same SID before the old sequence fully played through. To improve the practical value of PLAY it would be great if it could gracefully handle getting new requests for a SID before the previous sequence completed.

The preferred behavior should be to cancel the ongoing sequence and replace it with the new one

Alternatively there could be a way to detect if a SID is still playing so that a basic program could decide when to send a new sequence. The drawback would be that this does not provide the ability to cancel a running sequence and immediately play something else on the same SID.

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920355
• Core Commit: bdeeb15

Describe the bug
The "Enhanced" (sound enabled) DVI video mode does not work with DVI-only displays, which is why it is an option in the configuration. However, it appears that several of the pre-config menus, including the Hypervisor, core menu, and the config menu itself use "Enhanced" mode. This breaks these screens on DVI-only displays, and prevents the user from accessing the config menu to change it for the rest of the machine.

As I understand it, DVI-only mode should show a correct picture on all displays using the DVI output, including modern HDMI displays that otherwise support sound. Hypervisor et al should use DVI-only mode.

To Reproduce
Steps to reproduce the behavior:

1. Connect a DVI-only display. I'm using a Dell 2001FP and an HDMI-to-DVI video cable.
2. Hold Alt, then turn on the MEGA65.

Expected behavior
The Hypervisor Alt menu should display correctly. Instead, it behaves as if in "Enhanced" video mode.

The only workaround I know is to connect a VGA display to access these menus. It so happens that the Dell 2001FP has both VGA and DVI inputs, so I keep both connected and switch between them as needed. I now realize that this would not be necessary if these menus used DVI-only mode.

Is your feature request related to a problem? Please describe.
When experimenting with the PLAY command casually, it is too easy to accidentally leave voice parameters in an unwanted state, and too difficult to reset them. Directives like note duration persist across play calls, even after calling PLAY without arguments to silence all voices.

In a program, maybe it makes sense to say that the code should be defensive against inconsistent start states and always set all voice and play-system parameters, even when using what would be the BASIC default. If that's the advice, then it shouldn't impact programs to introduce a way to reset all parameters to defaults.

Without an easy way to restore defaults, the only reliable method is to reset the machine, which seems extreme. But I don't even know offhand what the string would be that resets all of the voice parameters, or the values of the default system parameters. "O2T0U9X0M0P0QR"?

Describe the solution you'd like
Introduce a new PLAY string voice directive "Z" that resets all voice parameters to BASIC defaults when encountered. PLAY "Z","Z","Z","Z","Z","Z" would reset all voices.

For similar purposes, introduce TEMPO and VOL variants that when given no parameters reset the PLAY system parameters to defaults. ENVELOPE env and FILTER sid should also reset to defaults (do they already?).

Describe alternatives you've considered
It might be nice for PLAY without arguments to also reset all voice parameters for all voices, but I'm not sure if some people are already used to it not doing that when experimenting with PLAY strings. If this isn't intrusive for current users, this might be worth doing. A "Z" directive might still be useful as a shorthand for resetting all parameters in the middle of a string.

I wonder if it would be intuitive to reset all parameters at the beginning of every string! Require every string to either assume the power-on defaults or set the parameters explicitly. This is more aggressive but possibly encourages good coding practice.

Additional context
This came up when testing example PLAY commands in documentation. An example command isn't likely to include every parameter, and the reader might not know how to reset previously changed parameters and get confused when later commands misbehave (e.g. use whole notes because the last example ended on a whole note).

Is your feature request related to a problem? Please describe.
There is currently a feature of the RENUMBER utility command where you can request that it remove space characters before line numbers in the BASIC source as part of its transformation of the code. (Technically it is removing trailing spaces after the keywords that can be succeeded by line numbers.) The user activates this "optimisation mode" by omitting the space between the RENUMBER keyword and its first argument: RENUMBER100,10 (optimisation mode) vs. RENUMBER 100,10 (non-optimisation mode).

No other BASIC command uses omitting a space after the keyword to request a change in behavior. Many people like to minimize keystrokes when entering commands and assume they can omit this space in general. At least two people have said they activated RENUMBER "optimisation mode" accidentally.

(Ironically, the "optimisation" of removing whitespace after keywords is only possible because whitespace is mostly insignificant in BASIC syntax. Introducing a command where whitespace is significant contradicts this general principle.)

Describe the solution you'd like
Replace the RENUMBER100,10 calling syntax with a named flag parameter. Per other commands that have introduced one-character flags (such as LIST P 1000-2000), introduce a C option (for "crunch") that appears before the optional RENUMBER parameters:

RENUMBER C 100,10

The default is to not delete whitespace during processing. The previous syntax is no longer supported. RENUMBER100,10 is equivalent to RENUMBER 100,10.

Describe alternatives you've considered
C for "crunch" is just a first suggestion. O for "optimise" might be ok, though I'm not fond of implying that this mode actually optimises anything. O might be easily confused with 0 (zero).

Crunching BASIC programs is a popular idea regardless of its effectiveness. I wonder if BASIC 65 would benefit from a dedicated CRUNCH command that knows how to remove all non-syntactic whitespace from a program. It's a destructive enough action that it deserves an ARE YOU SURE? prompt. If we had such a command, maybe there'd be less interest in a crunch mode for RENUMBER.

Additional context
The justification provided in the manual is to make the BASIC code more time and space efficient, but this has no practical impact running at 40 MHz, especially considering that this feature only removes a few of the spaces in the code and not all of them. One justification that occurs to me, but doesn't seem to be the documented motivation of the feature, is that RENUMBER can potentially cause a line to be rewritten longer than 160 characters. Asking it to remove a bit of whitespace reduces (but does not eliminate) the chance of this happening.

I had casually suggested in the Discord that we remove this feature, but several people who were around when this feature was implemented said it was requested and hard-won at the time. So far I haven't heard that anyone is particularly wedded to the "omit the space" calling syntax. It's an immediate mode-only command so changing it won't break programs.

Flag parameters are a new API convention introduced to BASIC 65 by MEGA65 (IIRC), and are not rigorously specified. For example, they are separate from optional positional arguments indicated by commas. This may be sufficient as a sort of API style spec:

<command> [<subcommand>] [<flag> [<flag>...]] [<arg> [,<arg>...]]

... where <flag> is a single letter, and <arg> can in some cases be a "keyword" argument that begins with a single letter. There is already a rare inconsistency in the API where a "keyword" argument without a value acts like a flag, and there are even cases where a flag and a valueless arg use the same letter, e.g. DIR W vs. DIR "...",W In the implementation, it's up to the keyword to parse its own arguments and handle ambiguities, and many arg parsing behaviors are not generalized.

There's no point in changing any existing commands, and we're unlikely to add many new ones. It's just something to consider if we make any more API clarifications, such as RENUMBER C ...

Test Environment (required)

• ROM Release: 920377

Describe the bug
BASIC 65 RENUMBER doesn't take COLLISION into account.

Reported by Snoopy here:
https://www.forum64.de/index.php?thread/133806-bug-report-renumber-mit-collision/

Bitmap graphics modes accessible with BASIC commands are great, but pose a disadvantage for beginners when graphics and text cannot appear on the same display, because it is difficult to experiment with drawing commands in immediate mode. Vintage microcomputers including the Commodore 128, 16, and Plus/4 accommodate this use case (and others) with a spilt screen display mode.

On the 128, the BASIC 7 command GRAPHIC <n>[,<clear>[,<line>]] selects between 40-col text, standard bitmap, split standard bitmap + 40-col text, multi-color bitmap, split multi-color bitmap + 40-col text, and 80-col text display modes. clear=1 would clear the bitmap screen (default 0). line would set the split point at a given text row (default 20, leaving five text lines). Only one vertical split is possible and the graphics mode is always on top. There's also a separate SCNCLR for clearing one of the screens without changing modes. GRAPHIC CLR and BASIC errors revert to 40-col text mode.

BASIC 65 has a more sophisticated screen system managed by the SCREEN commands, with up to four bitmap graphics screens in any of the supported resolutions and color bit depths. It does not yet support a graphics + text split screen mode or the BASIC 7 GRAPHIC <n> commands. (GRAPHIC CLR and SCNCLR are implemented.)

Proposal

Supplement the M65 screen system with a graphics+text split capability. Implement a similar GRAPHIC command to control it. The bitmap region would be the current bitmap viewscreen. If there isn't a current bitmap viewscreen, screen 0 would be allocated with sensible defaults similar to the SCREEN command. I imagine that horizontal screen resolution cannot be changed mid-frame, so a M65 split screen mode would use the text mode (40/80 col) that corresponds with the current viewscreen.

GRAPHIC <n>[,<clear>[,<line>]] would retain its C128 syntax, with a different mode list: 1) 40 col text, 2) 80 col text, 3) split 320-wide bitmap + 40 text, 4) split 640-wide bitmap + 80 text. Modes 3 and 4 would defer to the active bitmap viewscreen resolution if there is one.

As with bitmap screen modes, GRAPHIC CLR, SCREEN CLOSE, and BASIC errors would restore text mode.

If line is provided, GRAPHIC also clears the text screen and relocates the next READY prompt to the first visible text line. This matches the C128 behavior. Note that the C128 neither clears the text screen nor relocates the cursor if line is not provided. The proposed solution is to mimic the C128 behavior for consistency except where it doesn't make sense.

Alternatives

I'm hoping that this can be implemented with a simple raster interrupt and manipulation of the existing VIC-IV screen modes, but I have not tried this myself yet. Perhaps a beginner's tool can implement this as a small ML program that one can load from disk or add to their own programs, with no BASIC extension necessary. Given the way VICE flickers in this mode I'm guessing this is how it is actually implemented on the C128. I would expect other raster interrupt routines (VSYNC?) and RUN/STOP-RESTORE to cancel split screen mode.

We could dispense with multiple modes for GRAPHIC and just use the current bitmap viewscreen or the current text mode (in that order) to determine the mode. A user that wants a specific bitmap resolution and bit depth can call SCREEN before calling GRAPHIC. I like how this turns GRAPHIC without arguments into a simple intuitively named toggle for quickly jumping in and out of split-screen graphics mode.

I assumed that 640 bitmap and 40 col text, or 320 bitmap and 80 col text, cannot coexist on the same display. If I'm wrong, maybe more options (perhaps via numbered GRAPHIC modes) make sense.

I never liked how the cursor is allowed behind the bitmap display. Perhaps a WINDOW could be established automatically. Maybe Home-Home should also exit split screen mode as well as exit the WINDOW.

I have made a mistake and typed the following: "FONT X" that kills the M65, also the Freezer shows only the M65 graphics. Only Reset can help.

Every letter from G to Z used with FONT .... will crash the MEGA65.

See also: https://www.forum64.de/index.php?thread/126501-font-bug-the-ultimate-killer/

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• ROM Release: 920377
• Core Commit: 93d55f0

Describe the bug
The BASIC 65 SYS command appears to have unusual and undocumented limitations to the addresses it can reach. In discussing this on the Discord, we recall that Bit Shifter was trying to improve this but could not find a way to do it in a way that preserved what he deemed an acceptable level of backwards compatibility. We should investigate, and fix the issue and/or document the limitations.

To Reproduce
SYS $FFD2,65 calls the kernel CHROUT routine with the value 65 in the A register, printing the letter A to the screen. With the default BANK setting, this makes sense, because kernel ROM is mapped into $E000-$FFFF.

BANK 0:SYS $FFD2,65 also calls the kernel routine. This isn't documented (as far as I can tell), but it makes sense according to what we remember about the issue: SYS can't use any methods to access Chip RAM at 0.FFD2 because it needs to preserve the kernel ROM in this region to support IRQs.

I used the MONITOR to assemble INC D020, RTS, a routine that changes the border color, to address 0.1800. SYS $1800 calls this routine as expected using both BANK 0 and BANK 128, as expected.

BANK 1:SYS $1800 also calls the routine. This is not expected. It suggests that SYS always uses bank 0 for all 16-bit addresses regardless of the BANK setting.

SYS $11800 also calls the routine, as does SYS $21800, SYS $31800, and so on. This is not expected. Other BASIC commands will accept and use long addresses, bypassing the BANK setting. This suggests that SYS always uses bank 0 even when given a long address. This is true regardless of the BANK setting.

I repeated this experiment at offset $8000 and got the same result, with one expected difference: with BANK 128, $8000 is mapped to ROM at $38000, and BANK 128:SYS $8000 calls that ROM location and not the routine in RAM. However, SYS $38000 does call the routine at 0.8000 and does not call RAM. That might be a hint.

Altogether, this suggests that the SYS command can only access some RAM in bank 0, only uses the lowest 16 bits of the address, and uses BASIC's internal MAP, D030, and 00/01 banking settings to interpret the address. It has expected interactions with BANK 0 and BANK 128 only.

Expected behavior
Ideally, SYS would match the documented and implemented behavior of how BASIC commands use addresses: an address in $0000 - $FFFF honors the BANK setting (0-5, 128), and an address $10000-$5FFFF ignores the BANK setting and goes to that physical address in Chip RAM.

If SYS cannot meet this spec, we should design and document a feasible and intuitive spec. If no changes are feasible, we should research and document the known behavior.

Additional context
There are implementation difficulties involving how the SYS implementation interacts with interrupts that need access to kernel ROM via 16-bit addresses. Unlike other BASIC commands that merely read from and write to memory addresses, SYS must hand control over to the target routine as if JSR'ing to the address. I don't know the full set of requirements or why a fix was considered a backwards incompatible change.

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920382
• Core Commit: 1586ad4

Describe the bug
When in 80x50 text mode in the beta ROM, and running boot without an AUTOBOOT.C65 file, the bottom half of the screen fills with garbage text.

To Reproduce
Steps to reproduce the behavior:

1. Mount a disk without an AUTOBOOT.C65 file.
2. Hit escape+5 to enter 80x50 text mode.
3. Type boot and hit return

Expected behavior
Something like 62,FILE NOT FOUND,00,00 should be displayed.

Is your feature request related to a problem? Please describe.
Like most vintage Commodore PET computers, MEGA has a hard time keeping up with my modern typing speed and keyboard accuracy expectations. It routinely fails to register a key in the middle of a quickly typed sequence.

Describe the solution you'd like
I've searched this topic a few times for the C64 and keep coming back to this 3-key-rollover routine by Craig Bruce (Ctrl+F to find the article lower in the issue). I usually find this via this forum thread. I don't know if that resolves the perceived issue, or perhaps could inspire a MEGA65 version that could be made the default, at least for the BASIC editor. If it's a matter of processor speed, I'm hoping MEGA at 40 MHz can do a better job than a C64. I don't know if keyboard rollover would require changes to the MEGA65 keyboard.

Describe alternatives you've considered
I'd love to code on-machine more, but typing speed constraints compel me to cross-develop on a PC, even for BASIC. I try to consciously reduce my typing speed while on the MEGA.

Test Environment (required)

• Platform: MEGA65, xemu
• ROM Release: 920377
• Core Commit: lydon says "but core does not matter here anyway, this is a ROM problem" He did the test on real hardware.

Describe the bug
As written in title:

Abbreviated form of run - "rU" - returns the error "?missing file name error"

To Reproduce
Steps to reproduce the behavior:

1. Type "rU" and hit enter
2. See error
3. Profit!

Expected behavior
Normally, run the loaded program. In above reproduction steps, should just do nothing.

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65 R3
• ROM Release: 920377
• Core Commit: 93d55r0

Describe the bug
Creating or changing into a partition/subdir on an IEC drive/on a 1581 requires to send disk commands with a leading slash. DISK will make the drive throw a 31,SYNTAX ERROR,00,00, while using OPEN/PRINT# statements with the same command string are working fine.

To Reproduce
Steps to reproduce the behavior:

1. Unit 11 is a 1581 with a plain formatted disk inserted
2. send DISK"/0:SUBDIR,"+CHR$(1)+CHR$(0)+CHR$(200)+CHR$(0)+",C",U11 to create a partition
3. Result: UNIT:11 31,SYNTAX ERROR,00,00

or less complex:

1. Unit 11 is a 1581 with a formatted disk containing a partition/subdirectory SUBDIR
2. send DISK"/0:SUBDIR",U11 to change into SUBDIR
3. Result: UNIT:11 31,SYNTAX ERROR,00,00

Changing back to root:

1. Unit 11 is a 1581 with a formatted disk containing a partition/subdirectory SUBDIR. We are currently in the subdirectory
2. send DISK"/",U11 to change back to the root directory
3. Result: We receive a READY. prompt, but actually did not change the directory (refer to DIR U11)

Expected behavior
Example 1 should create a partition on the disk as correctly does
OPEN 1,11,15,"/0:SUBDIR,"+CHR$(1)+CHR$(0)+CHR$(200)+CHR$(0)+",C" : CLOSE 1

Example 2 should change into partition/subdirectory SUBDIR as correctly does
OPEN 1,11,15,"/0:SUBDIR" : CLOSE 1

Example 3 should change back to the disk's root directory as correctly does
OPEN 1,11,15,"/" : CLOSE 1

Test Environment (required)

• Platform: xmega65
• ROM Release: 920371

Describe the bug
It's not possible to find lines with REM with the FIND command

Screenshots

When a prg that is run in Mega65's C64 mode has the signature of "CBM80" at C64-location $8004 it is impossible anymore to reset the machine. After hitting the reset button, it hangs in an unpredictable state. You can only switch it off and on again. This happens from any place, even from the freezer.

My proposal: before (or while) resetting, clear at least one of the five signature bytes.

I encountered this behavior when running TSB in C64 mode (which works flawlessly).

Arndt

Just alike the Final Cartridge 3 then it would be very easy/beneficial for the user, if the MEGA65 ROM would show the address FROM-TO when doing a DLOAD of a file. This has the benefit of being a one-key approach and it will show valuable information of the file.

It could work like this (same way as FC3):

1. Do a directory listing
2. Go to the line/file you want to load and press F5 - it will now put DLOAD at the beginning of the line and load the file and show the affected FROM-TO memory. No need to set : at the end
3. DLOAD on a blank line (F5) will be the same as LOAD "*",8,1 - it will not RUN the file

E.g. loading music or a charset in to memory, then you easily can see where it loads it in to memory.

I know there are some alternatives - e.g. \ at the beginning of the directory listing file line, but then you also need to press ENTER and it will not show the memory address.

I fully understand this is just another feature request and that it is not on the top of the list, but I really loved that functionality with my FC3 and it was very helpful developing stuff (and easy to use - I am lazy) :-) I also previously have suggested this on Discord, but would rather have the feature request visible here to track if this will ever happen.

Sorry for the bad picture quality from my C64 with FC3, but you get the point:

This was created first as a core bug, but it might be possible that this is a ROM bug instead. I can't see any special NO SCROLL handling while the core is in "default mode".

1. SPEED 1
2. LIST
3. press NO SCROLL while listing
4. press RUN/STOP

after this you can't get out of it except by an RUN/STOP-RESTORE. Does not happen with more speed.

Original Issue: MEGA65/mega65-core#577

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920376
• Core Commit: f55531

Describe the bug
By historical accident of implementation, and despite what datasheets say, the 6502 BRK instruction is treated as two bytes: the PC that gets pushed to the stack by BRK is the address of the BRK instruction plus 2.

• See the MEGA65 Book, Appendix H: 45GS02 & 6502 Instruction Sets
• What are uses of the byte after BRK instruction on 6502?
• Internals of BRK/IRQ/NMI/RESET on a MOS 6502
• That BRK instruction...

I can't quite tell experimentally what the 45GS02 does when it encounters a BRK. It appears that certain parts of the ROM treat BRK as one byte. When I use BRK to enter BS Monitor, the PC appears as the address of BRK plus one. BS Monitor also assembles BRK to one byte.

I can say that ACME assembler assembles BRK to one byte, so any inconsistent handling may need to take third-party tools into account.

!cpu m65
*=$3000

brk
inc $d020
brk

assembles to:

00 ee 20 d0 00

I have not yet experienced a bug related to incorrect brk handling. I'm raising this because modern docs all warn about BRK being two bytes, but this toolchain seems to treat it as one. There appears to be no agreement on how the second byte should be assembled, and there is no conventional way to distinguish between a one-byte BRK and a two-byte BRK emitted from a tool.

We should review the parts of the core and ROM involved in BRK handling, and confirm with the major assemblers that BRK is handled correctly and consistently by the core, assemblers, and BS Monitor. We should decide on a convention, a support strategy, and (if necessary) a migration strategy.

There may not be a perfect solution. For example, maybe we limit support for two-byte BRK to cases where both bytes are 0: if a BRK is followed by a 0, increment the PC by 2, otherwise increment the PC by 1.

Describe the solution you'd like
Hitting F1 or escape+x could toggle to 80x50 text mode in addition to the 80x25 and 40x25 modes it currently toggles.

Describe alternatives you've considered
Remaining satisfied with escape+5 to toggle to 80x50 mode.

Additional context
I mostly bring this up because the functionality and documentation feels incomplete when we say there is an 80x50 text mode, but the button that toggles text modes doesn't include this one. In practice, I probably wouldn't use these buttons to toggle to 80x50 text mode just as I don't use them to toggle to 80x25 or 40x25.

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920376
• Core Commit: f55531

Describe the bug
When my program uses the brk instruction, execution stops and BS Monitor runs. The program counter (PC) register is reporting an address with a page byte of 02, when the code is actually on page 00. This is reported by the register display (R).

    PC   SR AC XR YR ZR BP  SP  NVEBDIZC
; 0220F9 33 13 01 00 00 16 01EF --11--11

Executing the G command without arguments is supposed to jump to the last known program counter value, the address just after the brk instruction, resuming execution of the program. Instead, it jumps to the address with the incorrect high byte (typically hanging the machine).

To Reproduce

1. MONITOR
2. Assemble this three line program to memory using A 3000:

A 3000  00       BRK
A 3001  EE 20 D0 INC  $D020
A 3004  00       BRK
A 3005

3. Execute the program from the beginning: G 3000
4. Attempt to resume the program after the first brk: G

This can also be reproduced with an assembled program containing a brk instruction.

Expected behavior
At step 3, the program executes then immediately re-enters the monitor. It shows the program counter is 003001. Step 4 continues execution at that address, changing the border color then re-entering the monitor.

Actual behavior
At step 3 the monitor shows the program counter as 023001. At step 4, the computer hangs, presumably because it just jumped to 023001 instead of 003001.

Additional information
I can use the monitor to repair the program counter value and continue the program: cursor up to the ; line and change the PC to 003001, press Return, then continue execution with G.

I tried assembling and running a program that sets all registers to 0 and calls map, then brk. This didn't seem to fix it. I also tried the BASIC command BANK 0 before invoking the monitor. These don't seem to be the source of the incorrect 02.

Is your feature request related to a problem? Please describe.
Using TYPE to view a file longer than 25 lines will have the first lines scroll off the screen, so one cannot read them.

Describe the solution you'd like
TYPE should implement a paging mechanism as is implemented for LIST (LIST P "filename").

Describe alternatives you've considered
none.

Additional context
none