Screenshot goodness

Because I've made significant changes to the user process for testing, I feel it's appropriate to post a screenshot of the latest revision, currently r132 r141. This screenshot shows tests of the uname(2) system call, the tty (/dev/vt), the random device (/dev/random), the link device (/dev/link), and the audio device (/dev/audio). All of these features are working in this revision. Additionally, there's a demo of a simple version of the "top" utility, and most of the statistics in there are real.

In the test of the /dev/link device, I used another instance of TiEmu running PedroM to send a variable to this calculator. This could also be done with the "Send file to TiEmu..." menu option in TiEmu itself, but that blocks the use of the calculator while the variable is transferring (remember that Punix is a multi-tasking operating system, so that is kind of annoying).

For the test of /dev/audio, headphones or speakers are required, but only if you want to hear the stereo test tones. :)



I still just need to work on getting the filesystem and binary execution working, and then we'll be very close to a working system!

/dev/link works now

Since last post I've been trying to make the /dev/link device driver work properly.

To assist me in testing I wrote a simple version of the variable receiver function getcalc(), which implements part of the TI linking protocol and runs entirely in userspace (except for the read() and write() system calls themselves). For the most part the link device worked fine. When a byte comes in and the read queue is full, the driver disables receiving until the user program drains the queue (at least by one byte). However, I discovered that no additional interrupts were being triggered to indicate that a byte is available in the hardware's receive buffer, even after those interrupts were re-enabled.

I finally fixed this today by setting a flag to indicate overflow of the read queue and then, in the system call (non-interrupt) code, read from the hardware receive buffer if overflow is flagged. Then interrupts are enabled again at this point and receiving bytes continues as normal, until the read queue becomes full again of course.

You can check out this working code with demos from revision 132. Ok, I lied. I forgot to commit all of my local changes in this revision! You can get working code (hopefully) at least from r141.

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.