Vortex PC66 (68 Key) Follow-up

The Vortex PC66 is a retro-ish PCjr keyboard. The PCjr was sold March 1984 to May 1985 and first used a chiclet keyboard that was junk. In 1984, the PCjr was shipped with a new keyboard. The following picture is an original 1984 PCjr keyboard and a Vortex PC66 (68 key) keyboard. The Vortex 66 (66 key) is more like the original without the left Ctrl and Windows/Super key which I do not think would be usable for me. I first saw the PC66 in a YouTube video A Modern IBM PCjr style Mechanical Keyboard! Vortex PC66.

The keyboard can be connected 2.4 wireless via USB dongle, wired via USB cable, and Bluetooth. I had problems using the wireless and wired connections on my desktop, but it did work on my laptop. Just a hazard of running Gentoo, I would need to configure and recompile the desktop kernel. However, I settled for using Bluetooth which was one of the reasons I bought this keyboard. Bluetooth can be paired with three devices, and I can easily switch between the paired systems. I have my desktop and an Intel NUC at my computer desk and connect temporary systems as a third device at times. The following are the connection instructions.

PC66 Connection Instructions

Up to the point of using the keyboard, I worried about the lack of dedicated keys I was used to having. After using the keyboard for a week, I am incredibly happy with the key combinations. What makes the special key usage easy, in my opinion, is having the Fn key in the lower right section of the keyboard. For example, I am already used to dropping my thumb on Fn and tapping Backspace for Delete. Again, the 68 key version of the PC66 has a “Windows” key and it serves as the Super Key to bring up Gnome Overview. The following lists the key combinations for the PC66.

Keyboard Combinations

The keyboard is small, but I have used a Logitech K780 for a few years and I like the small size. The PC66 does not have a number pad, but I rarely if ever use the keyboard number pad. The positive is that without the keypad the actual keys are larger in the same footprint of the K780. I have not used my PC66 on MAC or Windows, but it works well on Linux/Gnome. Finally, while I am not a retro computer collector, I do like the mechanical keyboard click. Enough of my ramblings, interspersed with pictures, here is the condensed list:

  • The price. The PC66 is pricey and for me it was more a want than a need.
  • It is heavy. Heavy enough to be used as a weapon, since I do not carry the keyboard with me it is not a concern.
  • Works with Linux which should not be a real surprise.
  • The PC66 can switch between up to three systems which was big have to have for me.
  • The height is quite a bit taller than any of my other keyboards, but I use a wrist pad that makes this issue unimportant.
  • The Function key (Fn) combinations take a while to get used to, but the placement of the Fn key and combination layout make it much easier.
  • The mechanical click is great, and the key size is perfect for people with fat fingers like me.

I originally thought I would give the PC66 a try and ended up storing the K780, so I think it will be my daily driver.

PC66 in use

Gnome 43

Better put, almost Gnome 43. It was painful but it is and installed.

Linux littleturd 6.0.2-gentoo-hpz820-mgreene #1 SMP PREEMPT Sat Oct 15 14:54:04 EDT 2022 x86_64 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz GenuineIntel GNU/Linux

Gnome 42

I thought I would never reach a stable Gnome 42 install! The big issue was the mouse movement. Everything was fine under xorg, but mouse movement and overall screen image sucked under Wayland. Anyway, the mouse is sync’d to display resolution and my refresh rate was set to something like 24hz, I do not know how that happened. Either way, all fixed now.

Traditionally, GNOME Shell has been compressing pointer motion events so its handling is synchronized to the monitor refresh rate, this means applications would typically see approximately 60 events per second (or 144 if you follow the trends).

https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-instant/

Linux littleturd 5.17.14-gentoo-hpz820-mgreene #2 SMP PREEMPT Thu Jun 9 21:06:34 EDT 2022 x86_64 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz GenuineIntel GNU/Linux

ReactOS as a 32bit Open Watcom Dev Environment

I was having problems with the old Windows XP VM I use to compile Open Watcom (OW) boot projects. This VM is an image of my original XP Desktop install that I have IDA and a lot of unused junk, so I decided to build a barebones VM for just using OW compiling. Initially, I was going to use a Windows 7 install as a lightweight single purpose solution; however, that turned out to be a real pain. Even using a real DVD on Windows 7 seemed to be more trouble than it was worth, so I looked for another option. I finally settled on setting up and giving a ReactOS VM.

ReactOS System About
VirtualBox ReactOS VM

I was incredibly surprised that this worked very well. The VM is lightweight, and I have not had many issues of concern. The VM does not seem to restore correctly from a VirtualBox save, but loading is so fast it really does not matter. My work setup for this project is to code in Visual Studio Code for Linux with the source on a Synology NAS share. The share is mounted (systemd automount) in my home directory. The ReactOS VM shares this directory for access to the source and the VM mounts a FAT16 vdi which is my test image that gets booted using Bochs emulator running from a bash shell on my Linux system.

VS Code About GUI

The workflow is to code in VS Code (on Linux), compile and copy the binary to the FAT16 vdi image using the ReactOS VM, and run the test system using Bochs (Linux) using its internal debugger.

VSCode and ReactOS VM on Gentoo Desktop

MSDOS Booting on a snow day

Anyway, big snow day in southeastern Virginia, so to kill time I was looking around at source on the internet. I had played around with the MSDOS start sequence before, but never looked closely.

The typical start, considering a start from hard drive, is MBR load to 0x7C00, relocate to 0x0600, and the active partition boot sector is loaded at 0x7C00. The boot sector loads either io.sys or ibmbios.com based on the OS flavor at 0x0700. What I had learned some time ago, io.sys or ibmbios.com is about 40K bytes in size. This means the load would overwrite the current boot sector which is currently executing. Being bored, I found the MSDOS 3.3 OAK disks which have a makefile for the bios containing:

copy /b msload.com+msbio.bin io.sys

So, io.sys is the bios file with msload.com grafted to the front end. A closer look at msload seems that it is a small loader. Here is the sequence:

  • Boot sector loads at 0x7C00.
  • Boot sector loads the first few sectors of io.sys which is really msload to 0x0700.
  • The msload module relocates higher in memory with all the needed BPB information.
  • The module then loads the bios portion of io.sys to 0x0700 which overwrites both the original boot sector and the first loaded msload.
  • The msload code jumps into the bios and off we go …

That is a brief sequence that I can figure out, so it is overly simple. I wondered why it was done this way. I looked at the GitHub MSDOS v2.0 source and there was no msload source included. Possibility the older versions of the MSDOS bios file was smaller and did not overwrite the boot sector? Then around V3 it became too large, and this was the work around. Hey, it cannot be discounted that systems back then measured memory in megabytes.

Well, that killed some time on a cold day.

Gnome 40

EDIT 16 May 21: gnome-40.0.ebuild is in portage

emerge –autounmask-write =gnome-40.0 and etc-update should make it available – good luck!

Also – I am having good luck with wayland enabled – so far!

The big gnome change from vertical to horizontal.