Is flush-ata-cache even needed? Reading the ATA 5 spec more closely, it
looks like it's only required by ATAPI devices! (Packet Interface is what
the 'PI' stands for!) And it's unclear if my driver actually supports ATAPI
at the moment.
Mu's keyboard handling is currently a bit of a mess, and this commit might
be a bad idea.
Ideally keyboards would return Unicode. Currently Mu returns single bytes.
Mostly ASCII. No support for international keyboards yet.
ASCII and Unicode have some keyboard scancodes grandfathered in, that don't
really make sense for data transmission. Like backspace and delete. However,
other keyboard scancodes don't have any place in Unicode. Including arrow keys.
So Mu carves out an exception to Unicode for arrow keys. We'll place the
arrow keys in a part of Unicode that is set aside for implementation-defined
behavior (https://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_controls):
0x80: left arrow
0x81: down arrow
0x82: up arrow
0x83: right arrow
The order is same as hjkl for mnemonic convenience. I'd _really_ to follow
someone else's cannibalization here. If I find one later, I'll switch to
it.
Applications that blindly assume the keyboard generates Unicode will have
a bad time. Events like backspace, delete and arrow keys are intended to
be processed early and should not be in text.
With a little luck I won't need to modify this convention when I support
international keyboards.
I spent a while building a little keyboard scancode printer:
$ ./translate ex1.mu && qemu-system-i386 disk.img
..and wondering why up-arrow was 0x48 in hex but 724 in decimal. I ended
up paranoidly poking at a bunch of crap (though there _is_ a cool chromatography-based
debugging technique in 126write-int-decimal.subx) before I realized:
- 724 just has one extra digit over the correct answer
- the 0xe0 scan code is a 3-digit number in decimal -- and the final digit is '4'
There's nothing actually wrong.
https://wiki.osdev.org/ATA_PIO_Mode#IDENTIFY_command recommends the straight-and-narrow
way, but the LBA bit shouldn't matter in drive-select during IDENTIFY command,
according to the ATA 3 spec. And it works in Qemu and bochs. It'll slightly
simplify drive parameter management.
Tested by inserting a call into the shell, but we can't leave it in because
every test ends up clobbering the disk. So it's now time to think about
a testable interface for the disk.
dd if=/dev/zero of=data.img count=20160
echo '(+ 1 1)' |dd of=data.img conv=notrunc
./translate ex2.mu && qemu-system-i386 -hda disk.img -hdb data.img
Compare output with `xxd data.img |head`.
This works because primary and secondary drives on the primary bus share
the same ports. All we have to do is select the right drive by flipping
a bit.
Both LBA and CHS coordinates are now working for the primary disk on the
primary bus.
Failure modes I ran into:
- ATA ports are 16-bit values. Using instructions with 8-bit immediates
will yield strange results. (I had to debug this twice because I missed
poll-ata-primary-bus-primary-drive-regular-status-word the first time
around.)
Mu's toolchain has been found out here. bootstrap has good
errors but doesn't support the instructions I need in boot.subx. The
self-hosted phases support the instructions but provide no error-checking.
Might be worth starting to add error-checking as I encounter the need.
In this case, a vote for validating metadata sizes even if we don't
validate that instructions pass in the right metadata sizes.
- Can't poll readiness first thing. Maybe we need to always select the
drive first.
- Reading 8-bit values from a 16-bit port (data port 0x1f0) returns garbage.
Reading 32-bit values however works totally fine; go figure. (Maybe
it won't work on real hardware?)
https://forum.osdev.org/viewtopic.php?t=36415
- Passing in a 0 segment will never return data.
Requires the following commands:
dd if=/dev/zero of=data.img count=20160
./translate life.mu
qemu-system-i386 -hda disk.img -hdb data.img
Before running Qemu, data.img will contain all 0s.
After quitting Qemu, data.img will contain the first 512 bytes of disk.img.
Kartik K. Agaram