I've been building and testing a Py65 device model for my M65C02A core. With some help from Mike N. and Big Ed, the command line parameter for changing the model was fixed. There is an issue in running Py65 Monitor within the IDLE environment: if the interactive assembler is used, the screen fills up with an extended character that appears to be decoded as 255. That issue occurs only with the interactive assembler feature, and occurs on both Windows 7 Pro and Windows 10 Pro. Has anyone experienced this problem, and come up with a solution. If not a solution, perhaps a clue on how to correct the problem.

In Windows 7 Pro, the Py65 Monitor runs just fine within a DOS/CMD box. The interactive assembler works great, and I've been able to modify it to support most of my extended instructions and support 16-bit immediate values. In Windows 10, the interactive assembler in a DOS/CMD window generates extra spaces between each character, so the interactive assembler only generates ?Syntax and your unable to exit from it. Does anyone have a fix for this, or some suggestions for me to try to resolve this issue.

_________________
Michael A.

Perhaps s.th. related to characters not necessarily have byte size and/or UTF-8 ?

Just a guess.

I am by no means an expert on the subject at hand, but a naive search tries to steer me in the direction of a UTF-16 issue, e.g.

https://stackoverflow.com/questions/111 ... -in-output

Mike B.

I have suspect you guys are correct, but everything that I've tried in the console.py module, especially the line_input() has failed to work. I have shown the in the DOS/CMD window, the msvcrt.getch(), in console.input(), appears to return 0x00 when there's no character instead of blocking as expected. So in the console.line_input(), I added a check to ignore that return value; that fixed running monitor.py in the Windows 10 DOS/CMD window.

For IDLE (agreed that it is a GUI), I even set the shortcut parameters to run it as a Windows XP SP 3 application. Instead of returning a 0x00, msvcrt.getch() returns a 0xFF when no character is present. Again, the expected block behavior is not taking place. Adding another check for that character in console.line_input() fixes the issue of characters filling the screen. But the line does not appear to be returned. I can only exit the line input function by using a Cntl-C, which until I added the check for 0xFF did not break out of the line_input().

In the meantime, I found that my edit to extend the immediate mode of the assembler to support 16-bit values broke the 8-bit mode. So I've spent the last hour or so tracking that down. I think I've got it so that both the 8-bit and 16-bit immediate constants can now be parsed. The disassembler has not been modified to deal with 16-bit immediate values.

I'll keep working on this as time permits. Any other thoughts / suggestions are welcome.

_________________
Michael A.

I've been running py65mon in a command window in Windows 10 and don't recall seeing any of these problems. Which version of Python are you running?

The problem occurs in IDLE in both Windows 10 and Windows 7 for me. On Windows 10, Python 3.6.4, and on Windows 7, Python 3.6.3.

In neither OS does the problem occur when running in a Cmd window. I suspect that it has to do with the GUI interface, and how the console streams are being handled/generated in IDLE. I don't know enough about the GUI interfaces to get a handle on how to get the py65 monitor.py stdin/stdout streams to work correctly.

_________________
Michael A.

I don't have Windows, and I think perhaps Mike doesn't either. Just possibly I could try to help if you could give me access - PM me if that seems attractive.

Are these Python applications built from source, or downloaded from somewhere? I'm familiar (in the ever more distant past) with using python from Activestate and from Cygwin. Have you tried the Cygwin environment? Or perhaps the new developer-mode bash shell in Windows will work better for you?

(It seems likely to be utf16, and if you're seeing doubled characters, that python is speaking two-bytes-per-char where the shell isn't.)

This question was posed to simply see if there was a solution available that would allow py65 to be used within the IDLE environment that ships with the Windows python distributions. It's not a particularly great editor, but it is convenient and easy to use.

I don't have any problems whatsoever with the command line environment in either Windows or Linux. I've not tried to run py65 out of the Eclipse python development environment so I can't say if that environment is free of the issue.

It's not a big enough issue to spend a lot of time on. From what I've read on several sites, the problem appears to stem from the way the GUI environment of IDLE handles stdin / stdout. In short, not well. The emulation of those standard interfaces does not do a particularly good job of providing the behaviors for stdin / stdout that occur in a Cmd window.

For the applications that I'm working with at the moment, using IDLE is convenient, but I can just as easily use the command line. In fact, the command line interface allows me to process command line arguments; I've yet to find a way to take advantage of that python feature in the IDLE environment.

_________________
Michael A.