Commander X16

On 1/20/2021 at 8:33 PM, Stefan said:

Yes, I think Windows and Linux users have trouble at least with Ctrl+R, that resets the emulator instead of the intended function, reading a file. On MacOS reset is Cmd+R, which is not a problem for X16 Edit.

After turning the problem in many ways, I simply realize there is no way for the emulator to use the keyboard without affecting the emulated machine.

Pretty obvious afterwards..... Not enough coffee, I presume ;oD

Therefore, I did what other emulators are doing, I enhanced the UI to handle buttons.

On 1/20/2021 at 11:33 AM, Stefan said:

Yes, I think Windows and Linux users have trouble at least with Ctrl+R, that resets the emulator instead of the intended function, reading a file. On MacOS reset is Cmd+R, which is not a problem for X16 Edit.

It sure would be nice if we could get any CONTROL hotkeys removed and switch them to either Control-Alt keystrokes, or put them in a menu bar.

I really like kktos's solution, since that space is dead anyway on most systems. We could enhance that area quite a bit, with buttons to dismount and mount a disk image, reset the emulator, break into the debugger, trigger an NMI (Run/Stop-Restore), and see the state of the registers and critical system variables in real time. 

 

I think I will have to do a proper post here but meanwhile, if you wanna try the slightly enhanced version of the debugger, I've uploaded the binaries. You can also compile it, of course.

Here are the windows binaries: Release 20210122

ps: that's the 64bits version so you'll need the 64bits version of SDL2.dll

On 1/21/2021 at 6:26 PM, Stefan said:

However, the special characters in cc64, such as { and }, are not mapped to the ASCII values of those characters. So it will not work to just change character mode in the editor.

Actually, it's only  {|}~ where there's a problem, \^_ are at their usual ASCII codes for cc64. And even {|}~ get printed correctly under their usual ASCII code. The problem comes from the duplication of $60-$7f at $c0-$df in the PETSCII charset, or rather, the other way around, because shift-A on the C64 keyboard will give you $c1, not $61, and shift-plus (that's where { lives) will give you $db, not $7b, though both print as { (with my patched charset).

I could change the mapping in my ascii2petscii and petscii2ascii tools such that {|}~ are left at $7b-$7e (just like []^_ are left at $5b-$5f) instead of mapping them to $db-$de, and for me who writes most code on Linux in ASCII, everything would work, and { would look like {, but natively on a C64 no-one could type { anymore.

It's a bit of a catch.

On 1/21/2021 at 6:26 PM, Stefan said:

To make this more user friendly, either cc64 can be changed to support ISO character mode (I don't know how hard that would be). Or X16 Edit could be changed to support a special cc64 mode (I don't know how hard that would be either).

An ISO cc64 version would certainly be a good thing. For that an ISO X16 VolksForth would be needed, built on an ISO or ASCII target compiler. Playing around with other VolksForth platforms (Z80 or MSDOS or AtariST or generic 6502, all of which are ASCII-based) is one of my plans for the future, anyway, so I'll see what is possible.

Incidentally, I have now also made a tool for easy patching of an X16 ROM: https://github.com/pzembrod/cc64/blob/master/Usage.md#patch-c-charset

I'm in the process of cleaning the X16 Edit code. I still have some work to do, but I think it's very stable now.

I couldn't resist implementing a new feature, as this was only about 20 lines of assembly - a prompt to execute DOS commands, for instance if you would like to rename or delete a file or create or rename a directory. This feature is not, however, not yet published.

There are two issues that are a bit more complicated to solve

• 
  One is the keyboard repeat rate. X16 Edit uses the Kernal keyboard routines, and it's sometimes painfully slow to wait for the cursor to move while you hold down an arrow key. The speed is the same as in the built-in BASIC editor, I would say. Is there anything you could do? If not, I might have to include more cursor movement features, maybe move one word back or forth.
  


• 
  The other is the word-wrap feature. It is very simplified at the moment, and the feature I'm least satisfied with. Making it better is a large undertaking, though. Any thoughts on how to make it better without complicating the code base too much would be very appreciated.
  

I vaguely recall that the C64 had a memory location that influenced the cursor movement (and blink) rate. I don't know if this is a variable in memory for the Cx16

1 hour ago, desertfish said:

I vaguely recall that the C64 had a memory location that influenced the cursor movement (and blink) rate. I don't know if this is a variable in memory for the Cx16

I think you're right about that. This is said about the KOUNT variable ($028B) on https://www.pagetable.com/c64ref/c64mem/

Quote

 



Counter for Timing the Delay Between Key Repeats 

This location is used as a delay counter to determine how long to wait while a key is being held down until the next repeat printing of that key.

The value here starts at 6. If location 652 ($028C) contains a 0, the value in this location is counted down once every 1/60 second, so long as the same key is held down. When this counter gets to 0, and if the repeat flag at 650 ($028A) allows that key to repeat, its ASCII equivalent will once again be placed in the keyboard buffer. A value of 4 is then placed in location 651, allowing subsequent repeats to occur at a rate of 15 per second.



 

I can't find that the KOUNT variable or any other similar variable is used by the X16 Kernal. Of coarse it could be there anyway.

I have read somewhere that PS/2 keyboards managed key repeats themselves (generating multiple key down/up events I guess). Maybe the X16 Kernal is expecting that, which would make the keyboard repeat rate untweakable on the computer side.

EDIT:

I now realized that if you change the keyboard repeat settings in the host system, that also affects the repeat rating in the emulator. At least on MacOS.

Am I right to assume that keyboard repeat rate is not handled by the Kernal?

How would you set the repeat rate on the real machine? I searched a little for PS/2 keyboard hardware repeat rate, and found that there seems to be commands that you can send to the keyboard to change its default repeat rate setting. Maybe that's the answer.

15 hours ago, Stefan said:

One is the keyboard repeat rate. X16 Edit uses the Kernal keyboard routines, and it's sometimes painfully slow to wait for the cursor to move while you hold down an arrow key. The speed is the same as in the built-in BASIC editor, I would say. Is there anything you could do? If not, I might have to include more cursor movement features, maybe move one word back or forth.

I know that jump to the next word is often done is find the next white space, then find the next non-white space, but I kind of liked the hop I had in my ANS Forth file editor, which looked to see if the current and next positions where both white space. If not, it went to the next white space, while if it was, it went to the last white space in the string of white space (and similar going back looking at the cursor location and the previous location).

I've been trying to adjust X16 Edit for the upcoming R39 Emulator+Kernal.

As far as I can see, there are no issues whatsoever. I attach my R39-test (sources on Github in branch "prepare-for-R39"). 

https://github.com/stefan-b-jakobsson/x16-edit/tree/prepare-for-R39

Running it requires you to download and compile both the emulator and the Kernal from Github.

If you haven't noticed, @Michael Steil merged most pending pull request for the Kernal during the end of last week and the weekend. I guess he is actively working towards R39. Happy times!


X16EDIT-R39-TEST.PRG