I think I have to write this down so I don't forget it:
- Improve Patch for NIE Modem and Serial Support
- Generic Package installer for Inbox (part of IrOBEX?): check.
- New UI for MAD Max
- Fix MAD Max truncated playback bug (schedule shorter sounds?): check.
- SMS sending transport to be used with Nitro
- Delay automatic disconnect on no IAS activity in Nitro
- MasterCook MX2 file reader: check.
- C++-based HTTP library for improved streaming
- Reverse engineer full C++ codec interface to schedule sounds from C++
- Reverse engineer AIFtoNTK to use ARM tools
- Use ARM tools to compile MAD Newton
- Port faac (AAC decoder) and Tremor (Ogg Vorbis decoder)
- Fast HTML renderer plugin for NetHopper: check (Courier)
- Speaker dependent speech recognition using EARS
- Bluetooth CommTool driver for RFCOMM
- Time and position dependent application scripter
- FAT/FAT32 file reading in MAD Max via ATA support
- Buy lots of chocolate and/or beer
... well, not really. But I took a closer look at the latest ARM compilers to find out how to make them work with the Newton tools. The advantage of using the ARM compilers are probably better code generation and definitely the support for StrongARM specific opcodes. The most interesting case are the 64 bit multiplication operations and support for 64 bit integers which are more or less required for optimized MP3 and Ogg decoding (you see where I'm getting at...)
Turns out that it is not impossible to use the new compilers, but also not trivial. The first hurdle is of course how to get the compilers. Thankfully, I can play with the latest tools at work, including the ADS tools. But the next step is a bit more challenging. The ARM tools are a distinct relative of the Norcroft tools used by the NCT. They differ however in the file formats they use. The ARM tools are nowadays ELF-based, whereas the Norcroft tools used AIF and AOF as object formats. This requires that the complete compilation and linking process has to be done with the same tool chain. Switching file formats in between stages doesn't really work that well...
The last step in that process is the conversion from an AIF image to the format used by the NTK. This step is done by the AIFtoNTK tool that unfortunately does not like the AIF image created by the new ARMLink and FromELF tools. Add the different debugging symbols to the mix and you end up with a total mess. But all is not lost, the AIFtoNTK tool might be easy to reverse engineer (it is only a couple of dozen kilobytes large). It takes the code, relocation and debugging symbol areas from the AIF and puts them in an NTK wrapper. That shouldn't be too hard to reimplement...
However, there are still quite a few other projects I'd like to improve before I get back to this.
Since I've got the GPRS settings for my Nokia 3650 correct, I was able to use Nitro a bit more extensively. This included using Raissa, SimpleMail, Nethopper and NewtScape. Overall, it went quite smoothly, no crashes and more or less acceptable speed (the 115kbps figure for IrDA is just theoretical, the protocol overhead is quite big).
It seems that at least for me, the combination of a Newton and a cell phone covers most use cases. It is actually strange that the situation has gotten better recently with the rise of RSS. It allows me to fetch information in a compact way, without having to visit huge, feature-laden web sites... but I still have to put together a package with some sample RSS channels.
[if you looking for a tutorial about using Nitro and IC/VC, here it is.]
With the release of IC/VC (the iCalendar/vCard route layer), some explanation of the used mechanisms might be helpful. The button with the little envelope which you see in your Newton applications is actually a very powerful tool. It is a system wide context menu that allows to perform actions based on the type of data currently displayed. The actions are either application defined or available throughout the system. The latter ones are clearly more interesting.
Most Newton applications follow the same principle. They display a list of items which are stored in a soup and can be modified individually. Every item is contained in a frame and typed via the 'class slot. The system wide actions are available based on this type. The most common use for these system wide actions is to send the current item via a transport to somewhere else. Other actions are possible as well (e.g. reading an item via MacInTalk), but they are also based on the item's type.
I'll cover the transport case here. A transport advertises which data types it can handle. The most common data types are 'text and 'frame, but there can also be others. Indeed, if you look at the Names or Dates soup, you'll notice that there are 'person, 'company and 'meeting types. Does the transport have to know about all of these? Not at all. It would be quite difficult to implement for example an email transport that would have to translate every possible data type on the Newton into an email message.
Instead, route scripts are used. They provide the translation between the application specific data types and the more general "transportable" data types. IC/VC is an example of such a route script. It registers as a handler for the data types used by Names and Dates and provides them in a form Nitro can handle them. The OBEX part of Nitro declares that it will handle the 'text datatype, so that's what IC/VC provides. With a little twist: types on the Newton can have subtypes, and IC/VC does not provide an object of the type 'text, but instead 'text/calendar or 'text/directory. The neat thing about that is that it is still text and can be send via any transport that handles text. Nitro takes the subtype into account and sets the appropriate OBEX headers according to that.
So what happens now when a user taps the action button? First, the system adds all the application defined actions to the popup menu. Then, it identifies the type of the current object (I'll spare you the details what happens in an app's overview). Based on that type, it constructs a list of route scripts that can handle the data type. The final step is to then determine which data type each route script will provide and compile a list of transports that will handle these data types. These transports will be added to the popup menu.
The double indirection of route scripts and transports is really well done and is one of the things that puts the Newton OS still so much ahead of the rest of the PDA world. And that five years after is discontinuation...
Windows is again driving me crazy. First is the stupid default usage of OBEX:IrXfer instead of OBEX, including undocumented error codes, and now it's the timing when sending items to the Newton. Well, the Newton IrDA stack has some flaws too, but only with Windows it's so tricky. The issue is receiving items which works now a bit differently than the standard procedure (at least on Windows 2000). The problem is that the Newton listens for an incoming connection, accepts it, waits for some action and disconnects if nothing happens.
Turns out that the way that Windows was designed to work clashes with this. If you initiate reception on the Newton, the IrDA activity icon is shown on the Windows task bar. Only then the option to send an item will be added to the context menu in the Explorer. By the time you have waited for that and activated it, the Newton as already disconnected, thinking the peer fell asleep.
The workaround is to open the wireless file transfer panel on the Windows side before that, navigating to the file to be transferred, initiating the reception on the Newton and then sending the item from Windows... not nice, but it works - besides the fact that there is probably still a protocol error in Nitro that I have to fix.
... you are hearing are bugs being eliminated. One by one, but going forward steadily. I just uploaded Nitro 0.2.2 which should be more robust and compatible. The most important change in the Nitro core is that no more out-of-band TinyTP and IrCOMM packets are sent. This might complicate matters in those cases where the peer runs out of packets or wants to use the simulated modem lines, but it prevents Nitro from crashing peer devices due to malformed packets. I might have to look into that later and re-enable these packets, but for now, I can reliably use my 3650 as a cell phone modem.
The second bigger change was the addition of the OBEX:IrXfer option for sending and receiving data. It is needed because the Newton can only advertise one IrDA class when listening, and in some cases, there is a mismatch between the class the peer device expects and the class the Newton advertises (e.g. when sending from Windows 98). The correct behaviour on the Newton side would be to allow more classes but there seems to be a hardcoded logic that only the class that has actually been set via the NewtonScript endpoint interface will be accepted. Other classes and attributes can be added to the IAS server, but they are ignored for the LSAP selector (which determines the class).
Some bugs have been fixed regarding handling of OBEX data, hopefully increasing compatibility...
One very nice thing about the Newton OS is that it is fully Unicode-based. Unfortunately, this raises some issues when communicating with other devices which are not Unicode-aware... in addition to that, Unicode comes in different flavors which all want to be dealt with.
Handling Unicode in IrOBEX transactions requires actions when sending and receiving data that has a textual representation. This includes plain text, HTML, iCalendar and vCard data. My initial strategy for the sending part is that all text based routing data (e.g. all the textual representations generated by the standard route scripts) will be sent as Unicode, to be more specific, UTF-16 Big Endian. This is the native format on the Newton. Other routing formats such as vCard and iCalendar will most likely be UTF-8. Hopefully the receiving end of this will handle that accordingly...
Receiving data is probably a bit easier, I have already implemented a function to recognize and convert ISO8859, UTF-16LE and UTF-16BE for text data. Memory consumption is however a concern, that is not optimized yet.