Announce: Inverted-T Cursor Keys for System 6+ Macs (INIT)

[Frobozz]

Somebody call up the University of Michigan FTP admin -- new INIT inbound!

For anyone who uses Mac 128 or Mac Plus keyboards, and just wants cursor keys, or for anyone with a say a IIGS style keyboard who wants cursors that aren't in a straight line, or for anyone who uses MacWrite as their Daily Driver and thinks it would be nice to have any cursor keys at all... I have the INIT for you!

Grab a copy, drop one or both into your System Folder, restart, and enjoy the magic of finger-friendly cursor layouts on your classic Mac. I wrote this for myself and my Mac Plus with 128 keyboard, but there may be at least 1, possible 2 other individuals who would find this helpful.

I am including both =[]\ and IJKL variants: pick the one you want or use both.

I also have an older project I could update if anyone wants it, which uses the CapsLock key instead of the Option key.

Features:
- remaps keys when Option held down
- Icon
- Icon shown on startup
- Help doc in MacWrite format

ToDo:
- period-appropriate PC user bashing and/or pity
- shareware with my street address and telephone number and maybe social security thrown in for good measure
- post to CompuServe

GitHub - WartyMN/68k-mac-cursor-keys-on-opt: Extension for Mac System 6-9 that adds alternate cursor keys when Option key is held

Extension for Mac System 6-9 that adds alternate cursor keys when Option key is held - WartyMN/68k-mac-cursor-keys-on-opt

github.com

If you try it out, please let me know if you run into any problems. Also, I haven't tested it extensively, so I'm not sure what all systems it would run on. It seemed fine on 7.5.5, and I use it normally on 6.0.8, but it may run on older versions of the OS, to some point.

 

[nathall]

Somebody call up the University of Michigan FTP admin -- new INIT inbound!

This made me laugh. That guy is probably closing in on retirement by now.

This is really cool and potentially really useful, when I get back home I’ll be giving it a shot. Hopefully it works under System 1/2.

 

[Frobozz]

System 1? I'll have to study a bit. I downloaded a Mac 128K build of mini vMac, the ROM, and the 1.1g version of the System, so I have a system to test against. Trying to learn more about how INITs were loaded in early (pre-4.0?) system builds. I got it to show a badge, although the graphic was all wrong, so I don't think it found it. But when it got to the desktop, it was frozen. I think what I'll try first is a bare-bones version that has no icon, doesn't try to display an icon on the screen on load, and knows it is just for pre-Mac Plus ROMs. This is probably the best thing anyway, since it should remove at least 1.5K. Presumably, on a 128k machine, there's not a lot of spare RAM lying around, and for 400K disks, every k probably counts.

No idea if I can make this work, but we'll see...

 

[Frobozz]

ok, well, this works "fine" on a Mac 128K, with system 1.1g. And by "fine", I mean:
- it doesn't crash the system
- it "only" eats 462b.
- it works when GetNextEvent() is used, but it does NOT work (of course), if the software is doing something like polling the keyboard hardware directly (the "notepad" app is doing something like that I imagine, as it is not using GetNextEvent() as far as I can tell).
- The app not only has to use GetNextEvent(), it has to know what to do with the cursor keys. For example, MacWrite 1.0 has no idea what to do with the cursor keys apparently. I can see it's getting them (I subbed normal alpha keys for a test, and it showed those no problem). But it doesn't move the cursor. Word 1.0, by contrast, does exactly what you would expect. Opt-= moves cursor up, etc. Shift-Opt-[ selects 1 character to the left.

Later versions of MacWrite must have added support for cursor keys, because with the version on my Plus, the Option cursory keys work great.

INSTALLING
oof. So what I learned is that INITs you can drop into the System Folder don't show up to something like System 4. Before that, you had to use ResEdit or similar to open the System (object) and copy the "INIT" resource from your compiled project into the INIT [group] already in the system. It's not hard, just not user-friendly.

APPS THAT SUPPORT CURSOR KEYS
MS Word 1.0
WriteNow 2.0

APPS THAT DO NOT SUPPORT CURSOR KEYS
Macwrite 1.0
MacPaint 1.0
Finder 1.1g
Notepad on System 1.1
WriteNow 1.0

I'm attaching a version of =[]\ cursors, built into system 1.1g. (Is it ok to post v1 system disks at this point?)

Please test if you have a chance with your system, and let me know if it works. I'm a little bummed that the Finder can't use the cursors, but it is what it is.

 

[nathall]

That was fast! I am on the road for work, but I’ll be back home this weekend and will give it a shot on real hardware at that time and report back.

 

[joevt]

ok, well, this works "fine" on a Mac 128K, with system 1.1g. And by "fine", I mean:
- it doesn't crash the system
- it "only" eats 462b.
- it works when GetNextEvent() is used, but it does NOT work (of course), if the software is doing something like polling the keyboard hardware directly (the "notepad" app is doing something like that I imagine, as it is not using GetNextEvent() as far as I can tell).
- The app not only has to use GetNextEvent(), it has to know what to do with the cursor keys. For example, MacWrite 1.0 has no idea what to do with the cursor keys apparently. I can see it's getting them (I subbed normal alpha keys for a test, and it showed those no problem). But it doesn't move the cursor. Word 1.0, by contrast, does exactly what you would expect. Opt-= moves cursor up, etc. Shift-Opt-[ selects 1 character to the left.

My keyboard hacking system extension patches the ADB service routines to do its work (messing with the KeyMap of each ADB device, trying to keep them separate so you can play games with multiple keyboards without one keyboard modifying the KeyMap of another).

But the 128K Mac doesn't have ADB. You would have to find the driver that modifies the KeyMap (if it has a KeyMap?) and or posts keyboard events.

 

[Frobozz]

Hacking the keyboard at a lower level might help for notepad (not in a practical sense tho). But MacWrite etc is getting the new keystrokes. That’s not the problem. The problem is that the early versions of the software have no code to deal with cursor keys. It’s like an American in Glasgow being spoken to by a Glaswegian: they see the lips moving and hear sounds coming out but they have no way to do anything useful with that data so they sit there looking dazed. You get the same behavior using the actual cursor keys on the optional 128 numpad.

 

[LaPorta]

Not to be a downer, but other than the original 128k/512k keyboard, why not just map this to the number pad?

 

[Frobozz]

Happy to make a version that maps there. Wasn’t a priority for me because I personally only use the 128 keyboard.

 

[adespoton]

Would it be possible to make one that uses a prefs file where you can enter the keycodes you want to map to?

 

[LaPorta]

Would it be possible to make one that uses a prefs file where you can enter the keycodes you want to map to?

Even better!

 

[greystash]

Very cool! Thank you!

 

[Frobozz]

Would it be possible to make one that uses a prefs file where you can enter the keycodes you want to map to?

Possible: yes. It will eat a lot more memory. Fine if you are on some 10MB monster LCII or something. But awkward if it's a 128K or 512K machine.
3 paths: (feel free to add another)

1. In the resource file, there are 4 bytes you can edit with resedit. This is going to be cheapest option in terms of memory use. Least user-friendly of course. Maybe everyone who is likely to install this is perfectly comfortable with ResEdit?
2. There is a text file, in System Folder, with 4 bytes. e.g, you start with "=[]\", but you open with BBEdit and edit to "ijkl", and now I is up, J is left, etc. Eats considerably more memory, because there has to be code to do file stuff and handle situations where the file doesn't exist. More user-friendly, but not very. Users could think they should enter "IJKL", and that would throw it off, for example.
3. CDEV (control panel). You have the INIT, you also install the control panel. (maybe they can be same, I've never made a CDEV before). LOTS more memory use. But user-friendly. Maybe there are 4 buttons, for up/down/left/right, and you click on the one you want to map, it asks for a key, and Bob's your uncle. Maybe you can choose if you want OPT or CAPSLOCK as the activator. SHIFT and CMD would be bad, so won't be available. CTRL doesn't exist, so you can't have that either. This solution would not work for systems less than 4 as CDEV wasn't a thing yet.

 

[adespoton]

Possible: yes. It will eat a lot more memory. Fine if you are on some 10MB monster LCII or something. But awkward if it's a 128K or 512K machine.
3 paths: (feel free to add another)

1. In the resource file, there are 4 bytes you can edit with resedit. This is going to be cheapest option in terms of memory use. Least user-friendly of course. Maybe everyone who is likely to install this is perfectly comfortable with ResEdit?
2. There is a text file, in System Folder, with 4 bytes. e.g, you start with "=[]\", but you open with BBEdit and edit to "ijkl", and now I is up, J is left, etc. Eats considerably more memory, because there has to be code to do file stuff and handle situations where the file doesn't exist. More user-friendly, but not very. Users could think they should enter "IJKL", and that would throw it off, for example.
3. CDEV (control panel). You have the INIT, you also install the control panel. (maybe they can be same, I've never made a CDEV before). LOTS more memory use. But user-friendly. Maybe there are 4 buttons, for up/down/left/right, and you click on the one you want to map, it asks for a key, and Bob's your uncle. Maybe you can choose if you want OPT or CAPSLOCK as the activator. SHIFT and CMD would be bad, so won't be available. CTRL doesn't exist, so you can't have that either. This solution would not work for systems less than 4 as CDEV wasn't a thing yet.

Hmm... I was reflecting on this further yesterday, and personally landed on #1; anyone putting an INIT into the System file isn't going to have difficulty editing an additional 4 bytes in Resedit. We could even create a ResEdit template file for the thing to make it easier

The other thought I had is that this would be the core INIT, and then the UI goes in an optional CDEV, like you've suggested in #3. In that case, memory constrained systems would have the lightest-weight configuration, and for those with RAM to spare, they can toss in the CDEV to manage it. Or, it doesn't really need to be a CDEV; you could write an app to do it, as all it is really doing is changing 4 bytes in the INIT. The tricky bit here would be that it would have to be able to find the INIT, either in its own stand-alone file (relatively easy) OR in the System file (a bit trickier).

You can bundle the INIT resource right into a CDEV, or run it separately; both work. But depending on the OS version, you'll have different constraints on the CDEV UI (or on early systems, you'll again have to load it directly into the System to see it in the control panel).

So probably best first steps would be: write the optimized INIT with the 4-byte field embedded. Then anyone who wants to can write a UI to manage it after the fact; it wouldn't necessarily have to be you. Plus, there could be different UIs for pre-System 4, System 4-6 and System 7+.

 

[Frobozz]

Ok, how's this for a plan:

• For all versions, the INIT resource (whether in INIT file or in the object you paste into System if OS 1-3) will have 5 bytes set aside, with markers before after. eg, "REMAPKEYS"/4 bytes/CAPS/1byte". So you search in ResEdit for REMAPKEYS and set what you want. I think we can afford 20 or so bytes for padding without breaking the bank even on a 128.
  • the 4 bytes will be in order: up, left, down, right. default will be IJKL I guess.
  • the 5th byte will default to 0, and mean that Option key is the modifier.
  • setting the 5th byte to 1 will get you CAPSLOCK as modifier, with all non-mapped keys getting standard caps lock behavior (e.g, caps+I gets you UP, but caps+H gets you "H" not "h".
  • Setting the 5th byte to 2 will get you CAPSLOCK modifier, but no caps behavior. The idea with this mode is that if you set say numpad 8456 or 5123 as your keys, you have a mode where you always have cursors there, and other than that, it's exactly like normal typing. if you want numpad bad, you unlock caps lock.
• Future optional control panel or standalone app (I'm personally control-panel-curious though, feels like the right thing to do for a Mac) which simply edits those bytes in the INIT for you. This would only work for system 4+, when CDEV and standalone INITs became a thing.
• In all cases you'll need to restart after modification.

Sound good?

 

[nathall]

That sounds good to me!

I’m back home now and I’ll give this thing a try on the real hardware later today.

 

[adespoton]

Ok, how's this for a plan:

• For all versions, the INIT resource (whether in INIT file or in the object you paste into System if OS 1-3) will have 5 bytes set aside, with markers before after. eg, "REMAPKEYS"/4 bytes/CAPS/1byte". So you search in ResEdit for REMAPKEYS and set what you want. I think we can afford 20 or so bytes for padding without breaking the bank even on a 128.
  • the 4 bytes will be in order: up, left, down, right. default will be IJKL I guess.
  • the 5th byte will default to 0, and mean that Option key is the modifier.
  • setting the 5th byte to 1 will get you CAPSLOCK as modifier, with all non-mapped keys getting standard caps lock behavior (e.g, caps+I gets you UP, but caps+H gets you "H" not "h".
  • Setting the 5th byte to 2 will get you CAPSLOCK modifier, but no caps behavior. The idea with this mode is that if you set say numpad 8456 or 5123 as your keys, you have a mode where you always have cursors there, and other than that, it's exactly like normal typing. if you want numpad bad, you unlock caps lock.
• Future optional control panel or standalone app (I'm personally control-panel-curious though, feels like the right thing to do for a Mac) which simply edits those bytes in the INIT for you. This would only work for system 4+, when CDEV and standalone INITs became a thing.
• In all cases you'll need to restart after modification.

Sound good?

Yeah; sounds like the best of all worlds. It's useful knowing the entire OS lifecycle before writing software for it!

 

[nathall]

I got this installed on System 1.1 and 2.0 disks I use on my 512k, and it works great!

Had some stuff to do in Microsoft Works 1.1, and it works in both spreadsheet and WP mode.

 

[Frobozz]

Thanks for testing Nathall. Awesome to hear it works on an actual 512K. I was going to describe how to get it on a 128k or 512k, then realized I had no idea. Magic!

Here is the newest version. I decided to put it into a different GitHub project:

GitHub - WartyMN/68k-mac-custom-cursor-keys: This is a configurable system extension (INIT) for Mac System 1.x through 9.x that remaps 4 keys of your choice to when either Option or CapsLock is down (your choice)

This is a configurable system extension (INIT) for Mac System 1.x through 9.x that remaps 4 keys of your choice to when either Option or CapsLock is down (your choice) - WartyMN/68k-mac-custom-curs...

github.com

Everything above is implemented (not the deluxe editor/CDEV thing, but ability to hack the key map), and works as far as I can tell. I tried hacking the keys and the modifier in ResEdit, and it did the right thing. I also through in instructions in case you want to hack what keys come out (in case you want something besides cursor keys). I didn't test that, but should work.

There is a WriteNow file and PDF with screenshot of ResEdit.

I'm thinking about digging out my IIgs keyboard and SE/30, and using that for a while. I realized this will make the M0116 and IIgs keyboards much more usable keyboards, because numpad can be used for cursors. Doesn't fix the \ key position tho

 

[nathall]

Thanks for testing Nathall. Awesome to hear it works on an actual 512K. I was going to describe how to get it on a 128k or 512k, then realized I had no idea. Magic!

There’s probably a more elegant way to do this, but this was the flow for me:

* download from here on an iMac running OS 10.13.6
* transfer via USB thumb drive to PM 8500/G3 running 10.2.8
* reboot 8500 under 9.2.2 and unzip
* throw extracted .img on a floppy as a file
* copy from floppy to PM C600 running 8.1
* use DiskCopy to create actual disk from .img file
* use disk in 512k, and distribute INIT to other boot disks from there