tag:blogger.com,1999:blog-90312651101290210922012-01-13T08:08:38.636-07:00The official blog of Punix, a Unix®-like operating system for the TI-92+ graphing calculatorChristopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.comBlogger281100tag:blogger.com,1999:blog-9031265110129021092.post-74166348685020145872011-07-02T22:29:00.001-07:002011-07-02T22:32:16.563-07:00

Ok, so I didn't get my file system completed on my trip a few months ago. In fact, I didn't work on it at all during the trip. (I don't know why I thought I would) I am now, however, working in earnest on getting the file system to work. This involves removing a lot of old code and rewriting some of the code. I'm basing my file system interfaces on Linux, which stores pointers to functions for

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-70692806372010358062011-03-27T20:05:00.002-07:002011-03-28T18:48:27.374-07:00

I will be leaving out of state for awhile in a couple of days, so I will probably not be updating this blog much during the trip. I will be bringing my dino-laptop with me, however, so I can continue developing Punix as time permits. Right now I am trying to compile and install GCC4TI onto it. It's taking a long time because the CPU runs at only 300MHz.... I already have TiEmu installed, which

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-20023680731416038442011-03-17T20:23:00.002-07:002011-03-24T21:30:47.585-07:00

Up til now I have been either faking the statistics in top, or pulling statistics directly from the kernel (by reading kernel variables). Since top runs in user space, it can't really get information directly from the kernel, so it needs to get it another way. In Linux (and not in FreeBSD), top uses the /proc filesystem. Punix doesn't have so much as a filesystem working, let alone a /proc

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com3tag:blogger.com,1999:blog-9031265110129021092.post-18613275163613532832011-03-11T23:38:00.001-07:002011-03-11T23:40:26.433-07:00

I just released Beta 4 on Sourceforge. Read the release notes here. This release includes initial support for the TI-89 (as I posted about previously), remote terminal (using the "uterm" program), and a user login. Check out the screenshot below to see the user login in action:

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-75351049714542546022011-03-10T13:38:00.000-07:002011-03-10T13:38:29.358-07:00

I fixed the display and keyboard input to work on the TI-89. There wasn't much to change since I already had key translation tables in place. I basically had to add one more translation table for the Alpha key, and change the existing translation table for the 2nd key so it works for both the 92+ and the 89. For the display I removed the separator line at the bottom, changed the status line to 4

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-81285985256852343862011-03-09T16:22:00.001-07:002011-03-09T16:24:08.137-07:00

Here's my first compile for the TI-89: I had to fix a few screen alignment issues, but there wasn't too much work to make it look ok. The key scanning needs some work to work with the 89's different layout, though. I plan to work almost exclusively with the TI-92+ since it has a larger screen. Most of the pieces I need to write from now on will work the same on both calculators. Once I have a

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-61208300100064102202011-03-09T13:34:00.000-07:002011-03-09T13:34:33.648-07:00

I got vfork() working well now, and exit() and execve() play nicely too. There were initially some memory leaks when doing a vfork() and then execve(), but those are all plugged now. I also fixed a few other bugs (one in heap.c, the memory manager) along the way. I just released beta 3 demonstrating these awesome (in my mind at least) features. Download it now. Also read the release notes.

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-68855758744361411622011-03-07T20:43:00.001-07:002011-03-08T00:08:27.295-07:00

I just added a busy indicator to the status line at the bottom. This indicator shows when the CPU is running a user program (or running in kernel mode on behalf of a user program). I shifted the other status indicators (shift, 2nd, diamond, etc) to put it next to the battery indicator: It's not the best-looking status icon, but can you do better? (Really, if you can draw a better-looking one,

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-91073888135103413412011-03-07T19:26:00.000-07:002011-03-07T19:26:42.389-07:00

I finally got vfork() working. It's about time... There is no screenshot this time, since it won't show much, but I know it's working because when I first got it working, init (process 1) was taking up about 100% cpu time while the shell (process 2) waited for user input. I could tell init was running in the background because the activity indicators were running full steam. What this means is

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-38988876227128464652011-03-07T02:06:00.000-07:002011-03-07T02:06:32.224-07:00

Here's a new animated screenshot showing what I've completed up to this point.

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-42260988536545410672011-03-05T20:34:00.001-07:002011-03-06T01:43:08.734-07:00

A couple days ago I discovered a somewhat serious bug in the kernel in which it throws an address error exception. The top of the stack frame at the beginning of the exception handler looked like this: 0015 0000 002f The stack frames for most of the exception and trap handlers on the M68K contain the saved Status Register and saved Program Counter at the top. If this were the case with the

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-14650862115856230522011-03-03T01:47:00.000-07:002011-03-03T01:47:03.340-07:00

I know what it looks like: Punix is dead. I swear it's not! In fact I have just released the first Punix beta! You can download that at SourceForge Recently I started work on a floating-point unit (FPU) emulator to add support for floating-point instructions, such as fadd, fneg, fsqrt, and more. So far instruction decoding (to get the destination, the source, and the operation) works for the

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-9030800952133394332010-03-27T11:31:00.004-07:002010-04-16T19:54:26.533-07:00

Yay, I got gcc4ti compiled and installed on my PowerMac. It wasn't as painful as I thought it might be (though it required running as root just to compile). It did take quite awhile to finish, since this machine runs at only 400 MHz...Anyway, I also have TiEmu running on this box; I compiled that a few months ago. So what this all means is that I can continue writing Punix!I was also pleasantly

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com1tag:blogger.com,1999:blog-9031265110129021092.post-48588982169058372732010-03-22T13:30:00.003-07:002010-03-22T13:46:11.440-07:00

I know it's been several months since the last real update. I've been really busy with school, work, and taking care of my pregnant wife. I'm trying to get back into developing Punix, particularly the filesystem, and I've been studying how the VFS works in Linux (it's much more straight-forward than the VFS implementations in BSD systems).My only working computer right now is an old PowerMac

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-82069490059947228612009-10-24T15:08:00.005-07:002009-10-27T12:39:01.327-07:00

I removed or commented out most of the tainted code and re-wrote a lot of them, and the system is working about the same as before the branch. I still need to implement the low-level filesystem functions and vfork()/execv() functions to make a working Punix File System.I also took the liberty of improving the tty driver. Previously this was based on crufty old code from V6 and V7, and it didn't

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com1tag:blogger.com,1999:blog-9031265110129021092.post-45370988687585963922009-10-20T16:38:00.002-07:002009-10-20T17:19:28.958-07:00

First of all, I want everyone to know that I'm still working on Punix, just at a near-glacial pace.Secondly, several months ago I decided to clean up the license issue in Punix. The issue is that I'm releasing Punix under the GNU GPLv2—both by my own choice and because I'm using bits of code that are already under the GPLv2 (mostly from PedroM)—but some code is derived from UNIX V6, V7, or

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-28455488140028884232009-04-09T11:21:00.010-07:002009-09-28T23:07:06.417-07:00

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,

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-53526798596202021902009-04-08T09:38:00.004-07:002009-04-24T18:29:50.963-07:00

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

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-63184176330864645652009-04-06T11:20:00.002-07:002009-04-06T12:15:36.422-07:00

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

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-85323750576394405102008-11-12T22:40:00.008-07:002008-11-12T23:20:56.557-07:00

The last time I posted, I had written a basic memory allocator. Since then, I've debugged it and integrated it more into the rest of the system. For example, I converted the proc[] array from an array of struct proc to an array of pointers to struct proc, which means 1) process structures are allocated when they are needed, 2) it takes a lot less static memory.Each proc structure took up 902

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-58687264699755033252008-10-20T02:05:00.005-07:002008-11-18T23:49:50.711-07:00

Here are a few more animated screenshots demonstrating the virtual terminal in Punix.This one demonstrates some escape codes for clearing parts of the current line or screen:This demonstrates scrolling the screen up and down:This demonstrates the use of the graphics character set, invoked with the Shift In (SI) character, or Ctrl-N:This last screenshot demonstrates the compose key feature, which

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-90466654860528601362008-10-16T17:56:00.004-07:002008-10-16T18:12:04.171-07:00

Today I got the terminal emulator in a usable state. On the input side of it, the modifier keys—shift, diamond, and 2nd—work, and most of the keys translate correctly with these modifiers (the mechanisms are in place, but the translation table needs to be tweaked). On the output side, the terminal correctly parses nearly all of the common escape codes of the VT-100 (upon which I based my terminal

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-44317602572122126682008-10-12T12:01:00.009-07:002008-10-13T13:13:23.917-07:00

Recently I've phased out the old text rendering code in favor of the newer "vt" virtual terminal emulator. This character device driver supports almost every VT-100 escape code. I tested the snot out of it, even running things like "links" (a text-only web browser) on it, to make sure it handles the codes correctly. The following screenshot shows the new terminal emulator in action. It doesn't

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-83963100538060866142008-09-10T12:46:00.002-07:002008-09-10T13:01:26.853-07:00

I've been meaning to change the layout of the kernel source for a long time now, but I was reluctant to change it for fear of breaking the build process (and also because CVS isn't very good when it comes to renaming or moving files and directories). However, today I finally changed the names of the kernel source directories:sys is now known as hkern is now known as sysThis naming convention is

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-85928388293428725882008-08-23T20:07:00.002-07:002008-08-23T21:00:05.343-07:00

It's been a while since I first designed a version of the file system for Punix. It first started out with the block translation occurring in the flash device driver; the file system driver would not know where in Flash ROM the blocks would be stored. Recently I considered moving this process into the file system driver and keeping the flash device driver simple; this would mean that the flash

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-35314570028767419642008-08-23T12:59:00.003-07:002008-08-23T19:43:46.383-07:00

A couple days ago I finally put the Punix source code into the Subversion repository on SourceForge. I figured it was about time that I used Subversion instead of the older CVS. This also means that the CVS repository is deprecated and will not be maintained. It will exist only for looking at code history.Also, during the past couple of days I have been working on fixing the scheduler. To do this

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-62302514799533772022008-01-23T23:33:00.000-07:002008-01-24T00:40:56.310-07:00

Despite the lack of a memory allocator and a working file system, I decided to start working on the execve() system call. In its current state, it doesn't load the text and data sections from a file; instead, it uses a hard-coded location for the program code, and it doesn't have a data section. Also, the stack pointer points to a global array variable with a fixed size. However, execve() has

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0tag:blogger.com,1999:blog-9031265110129021092.post-9329810060920055452008-01-19T14:12:00.000-07:002008-01-19T14:54:51.351-07:00

The development of Punix is still hobbling along. It still needs a few things implemented before it can boot up completely; the three major components it needs are a memory allocator, a file system, and a Flash ROM block device driver. It already has most of the upper and middle layers of the file system written, but it lacks the low-level code to read and write an actual file system on a block

Christopherhttp://www.blogger.com/profile/16414323982129709470noreply@blogger.com0