|
Post by Nomen Nescio on Oct 31, 2006 22:48:50 GMT -5
A program I remember from the late '80s was a nice CBM character set editor. Unfortunately, I don't remember the name of it and I no longer have my Commodore software library (or hardware for that matter.) I'd looked around a bit these past few weeks trying to locate that character set editor again but I'd not had any luck. I found several others, but I really didn't like how they felt or looked. So, about a week ago I figured I'd clone the one I remember from my memory of how it worked, plus add a few improvements. Here is a current snapshot of the program: nomen.nfshost.com/cbm06/chared64-06a.prgI've been developing in VICE so I'm not 100% sure it will work correctly on actual hardware. It's only got these basics at the moment: Currently, it only works with monochrome fonts (but will add multicolor fonts later.) Cursor keys move the cursor in pixel increments. (I'll add character increments later.) L and S load and save (but currently it only loads and saves to the file "CHARSET.CHR" and does no error checking). Space bar toggles the pixel under the cursor. M mirrors the character under the cursor. The I key inverts the character under the cursor. C copies the image of the character under the cursor to a clipboard. V pastes the image from the clipboard to the character under the cursor. I'm using a raster interrupt to do a split-screen effect, and I call the KERNAL's IRQ handler to play nice with the machine, but this tends to make for very unstable rasterlines. I'll probably end up turning off IRQs and scanning the keyboard myself, but I'd rather not do that if I don't have to. Any tips for making rasters stable yet playing nice with the KERNAL? I'd appreciate some people trying it out and giving me feedback. Feature suggestions are welcome, of course.
|
|
|
Post by tlr on Nov 18, 2006 6:38:59 GMT -5
Looks very much like Ultrafont [csdb]. About the raster splits. There is nothing preventing you using kernals keyscanning with stable interrupts. The keyscanner takes a fair amount of rastertime though. Just call $ff9f (SCNKEY) from one of the interrupts with enough free time and it'll be fine.
|
|
|
Post by Nomen Nescio on Nov 18, 2006 7:50:05 GMT -5
Cool! I think Ultrafont may be the one as it is very close (but not exact) to what I remember. Thanks!
I examined the KERNAL's IRQ handler and saw it was just doing an update of jiffies and scanning the keyboard. Turns out the key debounce loops are taking many cycles. I've since bypassed the KERNAL's IRQ handler and changed my IRQ handler to update jiffies. I haven't written any keyscan code yet, but I did see the SCNKEY routine. My plan now is to call SCNKEY at the start of my program just to get a pointer to the keyboard decode tables and do the keyboard scanning myself. Originally I was going to just call SCNKEY before checking the keyboard buffer, but I figure if I do keyboard scanning myself I can treat the CTRL, C=, and both shift keys as regular keys. This will allow more flexible keyboard command handling since I plan on letting the user remap all functions to what ever key combinations the user wants.
|
|
|
Post by tlr on Nov 18, 2006 8:03:23 GMT -5
Cool! I think Ultrafont may be the one as it is very close (but not exact) to what I remember. Thanks! I examined the KERNAL's IRQ handler and saw it was just doing an update of jiffies and scanning the keyboard. Turns out the key debounce loops are taking many cycles. I've since bypassed the KERNAL's IRQ handler and changed my IRQ handler to update jiffies. I haven't written any keyscan code yet, but I did see the SCNKEY routine. My plan now is to call SCNKEY at the start of my program just to get a pointer to the keyboard decode tables and do the keyboard scanning myself. Originally I was going to just call SCNKEY before checking the keyboard buffer, but I figure if I do keyboard scanning myself I can treat the CTRL, C=, and both shift keys as regular keys. This will allow more flexible keyboard command handling since I plan on letting the user remap all functions to what ever key combinations the user wants. This can be useful, but the kernal already allows this aswell. It sets the key pressed in zp $c5, and the shift/ctrl/etc... modifiers in $028d. Unless you have very strict requirements on rastertime or can not have kernal present, $ff9f will suffice. I did a quick scanner for testing the keymapping of the DTV, here. No debouncing though. Feel free to borrow from it if you like. EDIT: $c5 as Nomen wrote ofcourse. Corrected.
|
|
|
Post by Nomen Nescio on Nov 18, 2006 11:19:32 GMT -5
This can be useful, but the kernal already allows this aswell. It sets the key pressed in zp $c7, and the shift/ctrl/etc... modifiers in $028d. Unless you have very strict requirements on rastertime or can not have kernal present, $ff9f will suffice. I did a quick scanner for testing the keymapping of the DTV, here. No debouncing though. Feel free to borrow from it if you like. I only took a superficial look at the KERNAL SCNKEY code to get an overview of how it works so I might be mistaken but my impression was that only the last key scanned was stored at $c5, any other keys scanned before were thrown out (or the values overwritten, actually.) I figure I'll use the scan row/column as a position into an array to set a flag to siginify a keypress. This way, multiple key presses will not be lost. Thanks for the keyjoy info. I'll take a look at it.
|
|
|
Post by tlr on Nov 18, 2006 12:03:48 GMT -5
I only took a superficial look at the KERNAL SCNKEY code to get an overview of how it works so I might be mistaken but my impression was that only the last key scanned was stored at $c5, any other keys scanned before were thrown out (or the values overwritten, actually.) Correct. It only allows one key + an arbitrary set of modifiers. I figure I'll use the scan row/column as a position into an array to set a flag to siginify a keypress. This way, multiple key presses will not be lost. This is how my keyscanner does it. Note that you cannot reliably detect an arbitrary amount of keys simultaneously pressed due to how the keyboard is constructed. This applies to most keyboard matrices.
|
|