Well, I haven't read the documentation of the TI-68k series' Flash chips for years - but yeah, I'm referring to a mode, not used by AMS for writing to archive and FlashApp sectors, which allows programming chunks of more than two bytes, IIRC

Here's a nice new little feature I added yesterday: 4-level grayscale!

OK, so I added it really quick and dirty, and there's still some code that writes directly to the LCD and not to the gray planes, but I updated the primary glyph set (font) so it's now anti-aliased! The glyph set is still usable in monochrome mode (in fact it looks exactly the same as it did before).


(I'm not 100% satisfied with my anti-aliasing job, but it'll do for now.)

It took me only a couple hours to get grayscale working and then a couple more to make the terminal code work with it. I modeled the code after TIGCC's grayscale code, but I wrote mine in C instead of assembly (except for the fast copy routine).

I'm also planning to add grayscale and monochrome with double-buffering. To control all these LCD modes from userspace, I'm going to add a few ioctl() calls. An application only has to open /dev/lcd and use ioctl() to control it. Once the last file descriptor for /dev/lcd is closed, the LCD will revert to the default monochrome mode (so if a grayscale program is killed or crashes, the screen mode will automatically become monochrome before you return to the shell). I'm debating whether to make grayscale the default mode instead; graphical programs would have to explicitly set the mode if they want monochrome graphics. On HW2 (which is my main target), grayscale adds about 4% CPU overhead, which is not too bad to keep it active all the time. On HW1 (if I got it working) it would add even less than that. What's more, audio still works great with grayscale enabled! My biggest concern with grayscale was its interaction with audio, but it turns out to work well after all.

The Punix grayscale API will actually be much simpler than TIGCC's grayscale API (so it'll be more difficult to use it wrong, at least in theory ). Some of the TIGC calls mine won't have are the Gray*Set*AMSPlane routines (for obvious reasons), Gray(Set|Get)Int1Handler (that's privileged kernel functionality), and GrayDBufGet(Active|Hidden)Idx (not needed; use the "get planes" call). All in all, I'll add only 5 calls: get-mode, set-mode, get-planes, flip, and flip-and-sync. (Of course, a userspace library could emulate parts of the TIGCC grayscale API using combinations of those 5 calls, which might make it easier to port TI-AMS grayscale programs to Punix.) I'll also add ioctl calls to get/set/increment/decrement the contrast, but those are orthogonal to the grayscale calls.

EDIT 2012-03-06: scaled screenshot to 100%

I somehow missed that topic yesterday evening...

Good job, as usual

Very nice indeed. It looks a tad odd on a PC monitor, but that's probably because the image is much larger that it is.

* AHelper wonders how well it looks on-calc...

Yeah, the screen is somewhere between 1x and 2x in size when viewed on most monitors, but it just looks bad at a fractional size, so I just made it 2x so it's easier to see (the TI-8x calcs are closer to 2x so it's less of a problem with those screenshots). Then again, the anti-aliasing does improve the readability quite a bit....

You might be surprised to hear this, but I have not tried Punix on a real TI-92+ yet. I guess I'm just afraid of bricking it or something.

As you probably know, the only way to rally brick a TI-68k is corrupting the certificate memory. This is quite hard, even if with extreme bad luck, crashes can disable the Protection and might wreck all kinds of havoc.

That's good to know, and I suspected that was the case. I suppose the base code installer is also in a protected region?

I think the bigger reason I haven't installed it to a real calculator yet is that by the time I felt that Punix was mature enough to test on a real calculator, I didn't have the time to do so. The emulator is so much quicker and easier for testing, after all.

The boot code is in a permanently write-protected area (unless, as described in the datasheet, one of the pins of the NOR Flash memory chip is forcibly grounded); all other areas are R/W if the Protection is disabled.


Definitely

I'm happy to report that Punix handles leap days correctly!

That is all.

Good
It's easy to get them wrong, multiple large vendors have done high-profile screwups it in the past few years...

Indeed. Then there's the Sony PS3 which thought that 2010 was a leap year.

I just used a common BSD-licensed version of gmtime() to convert a *nix timestamp to a struct tm. Why does everyone think they have to reinvent this kind of basic functionality badly?

I thought of a somewhat crazy idea recently. How about I add a PS/2 keyboard driver so you can plug in a keyboard and type away on it instead of the smaller keypad? I was reading the PS/2 protocol recently and figured it shouldn't be too hard to implement. Ben Ryves has already done it for both keyboard and mouse on the TI-83 series.

Lionel, you can probably help me with this, since you're probably the most knowledgable about it, and you've already been very helpful so far. If I set $60000C bit 2 (trigger Int 4 on any link activity), will that trigger Int 4 whenever one of the two link signals changes state or only when one is pulled low? Will $60000D bit 3 or bit 2 tell me that is what triggered the interrupt? I want to avoid polling the PS/2 hardware many times a second; I'd rather be interrupted only when there is some actual activity on the link.

Also, do any of the libti* libraries provide a way to communicate with TiEmu or with a real calculator by toggling the line levels directly? For the latter I could probably hack up my own serial or parallel cable and bit bang it with custom software, but I'm not sure if TiEmu even exposes its link port at the signal level. It'd be great to use it to write some other link drivers too, like CALCnet.

Probably. But I've never used the link port beyond the highly incomplete port of CALCnet, and the TV-Noise 128-byte demo, where hardware assist is disabled.

I'd say "yes".

Sure

As TIEmu doesn't emulate the USB hardware, link transfers through the libti* framework work, on the TIEmu side, by bit-banging the line levels.
Assuming the drivers work (nowadays, they're admittedly not tested much by anyone, as DB9 & DB25 ports have been scarce on computers for several years), TIEmu ought to be able to communicate with a real calculator through the BlackLink / $4 cable, GrayLink, and Parallel ($5 cable).

I looked at j89hw.txt more closely, and it says that $60000c bit 6 (disable byte sender/receiver) also disables interrupts, so I might not get notified when the link changes state after all. I'll have to experiment with it later.

Anywho, tonight I just added 2nd-ON and Ctrl-ON to shut off the screen and CPU. That's pretty important functionality for a real calculator. Next in this vein will be Auto Power Down (APD) so it will shut down automatically after a few minutes of inactivity.

Indeed

On HW2 calculators, TI uses a timeout of ~311 s (300s when an interrupt assumed to run at 20 Hz exactly actually runs at (2^19/2^9)/53 ~19.32 Hz).

Nothing that an XACTO knife and a soldering iron couldn't fix. Actually, BenRyves has been asking me for quite some time to try slicing the RST pin on a TI-83+'s z80, to see if we can prevent the ASIC from resetting the z80 when execution goes onto a privileged RAM address such as $C000-$FFFF.

Woopsy, I combined the TI-9x and Punix modifier names in my last post (2nd-ON should be Alt-ON, or Ctrl-ON should be Diamond-ON). No biggie.


I always shake my head at TI's decision to have a timer that's approximately 20Hz. Why didn't they make it exactly 32Hz or something similar? I think that would be more useful. Whatever. It doesn't affect me at all. Int5 isn't available for user programs in Punix anyway. It's used for drivers currently. Only Int1 (256Hz) is used for timing purposes, and even with that user programs can only set timers using setitimer with microsecond resolution (though it's limited to 3906 microseconds at the minimum).


So I re-thought how a process should get/set the grayscale mode. Instead of calling ioctl() on /dev/lcd, a program will call ioctl() on /dev/tty. This device file is the process's controlling terminal, which is equivalent to /dev/console for programs started on the console. This way, only programs running directly on the console (ie, not via a remote login) can query or change the LCD grayscale mode (well, root can always open /dev/console even from a remote session and fiddle with grayscale).

I'm thinking of using ioctl() on /dev/tty also to get/set the APD timeout, which means that only console users can modify the APD. But APD is not only a console function; it shuts off the processor's clock so that nothing can run until ON is pressed. So I need some opinions on this. Should I use sysctl or ioctl on /dev/tty to get/set the APD timeout? What types of activities should reset the APD timeout? Obviously there's keyboard activity, but what about link activity? Should a running program (ie, not waiting for input/output) also inhibit APD? This last one might be tricky because background programs (ie, daemons) might run ocassionally and would reset the timeout, making the APD seem erratic or unpredictable.

EDIT: I should clarify: I meant that the APD would seem unpredictable to the user if the APD timer were reset any time a background process ran. But this just occurred to me: what if APD was only a screensaver? The CPU clock already shuts off whenever all processes are idle (ie, there are no runnable processes). The only big difference between a full power down and a screensaver is that processes can wake up the system with a screensaver, even if the screen stays off when that happens. To truly shut off the calculator like TI-AMS (which is really more like a standby mode), the user would have to press alt- or ctrl-ON (aka 2nd- or diamond-ON). Any opinions on having a screensaver?

Maybe combine both. I am assuming that you would turn off the LCD on a screensaver and that turning it off will suspend running processes. For ex., activate the screen saver in 150s in case the user is using the calc but is afk (keypad, w/e) for a bit. After the full ~300s, the calc can then go and turn off to save battery power.

Yes, the screensaver would turn off the LCD, and turning off the calc shuts off the LCD and suspends all processes.

I like the idea of having two power-save modes. I was thinking about that too after I posted. For the screensaver, I will keep it simple and have it based on keyboard activity only. Any key will exit the screensaver. I suppose the power off mode can be activated the same way, but only ON will wake it up.

I'm trying to accommodate useful but unforeseen use cases, such as running the calculator as a kind of server for other calculators. This use case would benefit from the screensaver but not the power off mode, so I want to make each mode easy to disable/enable from within a program.

When the calculator goes to suspend (power off, not screensaver), you could send each process a signal, like SIGSTOP (I thought that there was one specifically for suspend...). If a server process is running or something that cannot stop is active, it can refuse to stop. The screensaver will stay active until all processes are stopped.