It works, it works, it works!

No, Punix still doesn't have a filesystem, but it's getting closer. I've added tests of the various system calls in the user program, especially read() and write() on a few different devices (files under /dev/). This was achieved by modifying the open() system call to recognize those device names specifically, allowing read() and write() to operate as normal. The following is an incomplete list of features that I've tested and verified as working:

• Audio device
• Random device
• TTY
• uname()

The following are features I'm still testing but do not work completely yet:

• Link device

Audio device

The audio device currently lives at /dev/audio in Punix. The driver for this is not very complicated, and the code that I wrote years ago needed only minor tweaks and tuning to make it work well. The audio output is in stereo, but given the limitations of the hardware, the sample rate is limited to 8192 Hz, and the sample size is one bit. Despite this, it can still produce decent sound, like those produced on 70's-era computers. :)

Random device

The random device is just what it sounds like: random. It produces a stream of random bytes that can be read using the standard read() system call. This implementation uses a a simple linear congruential pseudo-random number generator, meaning it should be sufficient for many applications like games but not for any type of cryptography. I suppose you could us it for the insecure type of cryptography, though.

TTY

The TTY is basically a wrapper around the terminal device, in this case the VT device as I've written about in the past. It basically makes terminal input and output "friendlier" to the application by supporting different modes of operation, such as "cooked" mode. "Cooked" mode is the most common mode for simple command-line programs that read input from the terminal. The TTY in Punix is still a little hackish, but it works pretty well now.

On a related note, I finally fixed a little issue with the vt device with regards to interrupts. Whenever a character is sent to the vt output, it would block all level 1 interrupts (by design), but this turned out to be a small problem because the vtoutput() function would often run longer than the duration of an level 1 interrupt. This means some interrupts would be lost, resulting in lost time since level 1 interrupts are used to maintain system time (along with the level 3 interrupt handler).

uname()

Here's an oddball system call that I implemented and tested. It's not oddball per se, but it simply doesn't follow the pattern of the previous features I tested. :D

This call just returns strings describing the system itself, including the name ("Punix"), release, version, and the machine ("m68k"). This isn't the least bit complicated, but I just wanted to make sure it's implemented.

Link device

The link device (/dev/link) is the device used to communicate over the I/O link port (2.5mm stereo jack) of the TI-92+. So far sending data seems to work flawlessly, but receiving data doesn't work at all. I've tested this by running two instances of TiEmu, one running Punix and the other running PedroM (which I know works). The program in Punix attempted to send a file (in the TI-92+ variable packet format) to the PedroM calculator, and the PedroM calculator initiated receiving the variable as soon as the Punix program started writing the data to the link device. However, after several seconds PedroM timed out because Punix was not reading its responses to the packet data. I'll need to figure out why the link device driver isn't receiving data.