You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem to solve
MEGA65 machine code programs can call hyppo_serial_monitor_wait_and_write and hyppo_serial_monitor_write to send ASCII characters to the serial monitor, displayed by a connected JTAG/UART serial terminal and the built-in Matrix Mode terminal. It would be useful for BASIC programs to be able to send debugging messages to this as well.
Proposed solution
Reserve device 30 as an output-only device, such that a BASIC program can open an I/O channel to this device and use PRINT# to emit messages. Output would use hyppo_serial_monitor_wait_and_write to send the characters sent to the device.
10 OPEN 14,30
20 XP=0:YP=0:REM PLAYER PROPERTIES
...
1000 PRINT#14,"CURRENT PLAYER POS: X="+XP+" Y="+YP
...
Considerations Wikipedia lists IEC device numbers from 0 to 31, with well-known reservations for keyboard, screen, datasette, RS-232, printers and plotters, and disk drives, with 31 reserved for command broadcasts to all devices. C64 Wiki implies that, in theory, device numbers 8-30 could be assigned to disk drives, but Wikipedia refers to 16-30 as "unknown." Device 30 is a guess at a device number that we can reserve that won't interfere with common tasks. I'm wary of trying to take printer, plotter, or RAMDisk device IDs, which might be uncommonly used with a MEGA65 but seem more likely than a disk with device 30.
This wouldn't be used for sending commands to the serial debugger, which is not currently offered by Hyppo APIs. Nor is there a way to treat it as an input device. If these were possible in the future, we could use the Secondary Address to establish those connections, e.g. OPEN 14,30,2 : PRINT#14,"F1700 17FF 00" : CLOSE 14 Maybe there are reasons to not do this even if it were an option.
This would mostly be useful for debugging BASIC programs, especially games that take up the full screen. ML programs are best left to write their own routines that call the Hyppo trap directly. (I'm always copy-pasting my routines for printing messages and hexadecimal numbers to all my programs—which is the correct solution in this case. The KERNAL is not in the business of hosting libraries of routines it doesn't itself use. 😅) Implemented as a device like this, ML programs could use KERNAL serial operations to emit debug messages, but it's probably easier to just call Hyppo directly.
I considered not making this a device and just introducing a new DEBUG keyword that behaved like PRINT to the screen. I would want to retain some degree of data formatting, either by assembling a string expression or re-using all of the capabilities of PRINT (with some minor conversions like converting PRINT's use of right-cursor chars to spaces). Treating this like an output device allows it to take advantage of PRINT# as it is currently implemented, without having to instrument outch with some kind of target flag.
The text was updated successfully, but these errors were encountered:
Problem to solve
MEGA65 machine code programs can call
hyppo_serial_monitor_wait_and_write
andhyppo_serial_monitor_write
to send ASCII characters to the serial monitor, displayed by a connected JTAG/UART serial terminal and the built-in Matrix Mode terminal. It would be useful for BASIC programs to be able to send debugging messages to this as well.Proposed solution
Reserve device 30 as an output-only device, such that a BASIC program can open an I/O channel to this device and use
PRINT#
to emit messages. Output would usehyppo_serial_monitor_wait_and_write
to send the characters sent to the device.Considerations
Wikipedia lists IEC device numbers from 0 to 31, with well-known reservations for keyboard, screen, datasette, RS-232, printers and plotters, and disk drives, with 31 reserved for command broadcasts to all devices. C64 Wiki implies that, in theory, device numbers 8-30 could be assigned to disk drives, but Wikipedia refers to 16-30 as "unknown." Device 30 is a guess at a device number that we can reserve that won't interfere with common tasks. I'm wary of trying to take printer, plotter, or RAMDisk device IDs, which might be uncommonly used with a MEGA65 but seem more likely than a disk with device 30.
This wouldn't be used for sending commands to the serial debugger, which is not currently offered by Hyppo APIs. Nor is there a way to treat it as an input device. If these were possible in the future, we could use the Secondary Address to establish those connections, e.g.
OPEN 14,30,2 : PRINT#14,"F1700 17FF 00" : CLOSE 14
Maybe there are reasons to not do this even if it were an option.This would mostly be useful for debugging BASIC programs, especially games that take up the full screen. ML programs are best left to write their own routines that call the Hyppo trap directly. (I'm always copy-pasting my routines for printing messages and hexadecimal numbers to all my programs—which is the correct solution in this case. The KERNAL is not in the business of hosting libraries of routines it doesn't itself use. 😅) Implemented as a device like this, ML programs could use KERNAL serial operations to emit debug messages, but it's probably easier to just call Hyppo directly.
I considered not making this a device and just introducing a new
DEBUG
keyword that behaved likePRINT
to the screen. I would want to retain some degree of data formatting, either by assembling a string expression or re-using all of the capabilities ofPRINT
(with some minor conversions like convertingPRINT
's use of right-cursor chars to spaces). Treating this like an output device allows it to take advantage ofPRINT#
as it is currently implemented, without having to instrumentoutch
with some kind of target flag.The text was updated successfully, but these errors were encountered: