GloriousCow
The Tandy 1000 will need its own OSD since the tandy keyboard differs from the Model F in significant ways. You'll notice that if you type shift-backslash on the current model-F based OSD you'll get a 7 instead of the expected |. Because backslash is on numpad 7 on the Tandy.
Dealing with this stuff is tons of fun
If you have a CGA card, you're stuck with the code page of the ROM your card came with, which in most cases was code page 437, although a few variants were made.
EGA/VGA had software fonts so other code pages could be loaded.
The combination of these two decisions means its inadvisable to type while your floppy drive is transferring data
believe it or not I didn't tailor it for the HN meta
I was trying to Run Back To The Future, so I figured I'd call my emulator either Marty or McFly.
Unfortunately I found out about the FM Towns later, so I renamed it from Marty to MartyPC so you could google "MartyPC Emulator" properly.
I have to make all new pixel-art for a Tandy 1000 keyboard and PCjr keyboard. Fun
But honestly I wanted to learn the Rust programming language and I thought writing an emulator was a good a project to learn as any.
I have been working on a emulator in C++ in collaboration with a friend, it is also cycle-accurate. It is called XTCE-Blue.
It is insane because IBM wanted a wireless keyboard. If you're not familiar with the PCjr keyboard, it has two IR transmitters (they are electrically the same, just having two gives you a better transmission path). The PCjr system has an IR receiver.
Now, a normal keyboard cable is a standard two-wire serial protocol with clock and data. Being wireless, you have no clock, so you have to synchronize clocks, or have clock recovery built into the protocol. The PCjr does the former, using the 8253 timer chip.
The keyboard has no way of knowing if the system has received a keystroke, so the system must receive every keystroke - they can't be stored in a fifo, they can't be resent if the CPU missed it.
This rules out the possibility of using system interrupts - so when you type a key on the CPU and the IR receiver gets the start bit - the NMI line is raised, the 8253 is programmed to time the clock bursts from the IR receiver, and the CPU reads out every bit of the scancode.
In software.
By mentioning Rust people have been able to more easily find MartyPC as an example of how (or how not to) write an emulator in Rust.
Perhaps the tag as outlived its usefulness, especially if people find it pompous or something. I'm not trying to be Rust cultist, I swear.
I've heard the comments here loud and clear :) You all don't think Rust is novel anymore and I should lose that bit.
Are you using DVORAK? If you are willing to help, please open a Github issue with some info about your keyboard, and I'll build support for it.
I've uploaded all the binaries to GitHub if you're struggling with copy & paste. There's also a new example in Braille.
I think blogpspot unfortunately mucks with the emoji.
It's less to do with browser versions and more to do with websites. Mastodon and unfortunately blogspot seem to mess up the emoji. Fortunately you can click on the disassembly links that go to my disassembler and copy them from there.
That language can then be translated into Verilog, and has been.
Other instructions like PUSHA and POPA are implemented as loops that iterate by incrementing the fields corresponding to registers - and we know in what order they operate.
Bit by bit, relation by relation, you can puzzle out the format of the microcode. Of course, this is glossing over the enormous added complexity of protected-mode operations. This was a herculean effort by reenigne, and I don't think it is hyperbole to call it one of the more impressive human achievements I have witnessed in my lifetime.
Documentation from the NEC vs Intel lawsuit ended up documenting the microcode word format for both the 8088 and NEC V20 CPUs, but unfortunately, we were on our own for the 386. But we could take educated guesses - working off the 8088 field format, what additional microcode fields would a 386 add? What fields would expand and how many bits would they need?
We used a lot of python scripts to decode the microcode array into 37-pixel wide, very long bitmaps, in different permutations, to see if any vertical patterns emerged that would hint to us the boundaries of microcode word fields. And some did emerge!
Then you have to classify them as 0's or 1's. Each is visually distinct, a 1 being encoded by the presence of a transistor and a gap in the polysilicon. We didn't have to guess which is which is by the nature of Intel microcode we could assume 0's were much more frequent, so a transistor meant a 1.
There are some automatic tools designed to perform this work via color thresholding, but they didn't work very well here because some of the mosaic was blurry, and a lot of dust had crept in which created false 1 bits.
Instead, we trained a convolutional neural network to classify the extracted bit regions into 0's and 1's. This was overlaid back onto the original mosaic as white or black squares at 50% opacity.
Then we spent several long, tedious days just checking the results for errors. Finally we had the raw 2d array of bits - the next step is to extract the microcode words from the bit array.