PCMCIA cards
While the internal Bluetooth module in my development Newton is sick with some unknown hardware problem (it doesn’t send, maybe the 3.3V line got loose), I spent some time to see what the problem with the PICO card and Blunt 2 was. Seems like things are actually quite ok, the card uses regular byte I/O, not DMA, and there were just some bugs in the code. The only irritating thing now is that as soon as I try to send some L2CAP packets, it returns a hardware error. Well, time to restructure the code so that I’m able to have a bit more control over timing, maybe add some delays here and there…
Wedgie
Ok, easy solution to the page fault in the interrupt handler: I wedge the interrupt handler code between two functions which will definitely be called before any interrupt occurs. The code is quite small, this is however something to still watch later. At least the symptoms are very easy to interpret, a “Deep Toast Alert” doesn’t happen too often :)
Something Interesting…
… again ;) - I’m currently trying to figure our why the interaction with the TSerialChip crashes when talking to a PCMCIA card as opposed to the internal Bluetooth module. Seems that it’s not the actual interaction with the chip (the functions in the TSerialChip16450 class are quite simple), but it’s a general problem with the interrupts they cause. Something that could as well happen with the internal module. Initializing the chip generates interrupts pretty much right away, and the problem is that accessing my interrupt handling code causes a page fault, probably because it hasn’t been loaded yet. An easy way around that would be to force it to load by referring to it explicitly, but that’s not terribly elegant. I think that Paul has hit the same problem in the ATA driver much earlier than I did, so maybe I’ll check if I can use his workarounds as well. One problem might be however that Blunt 2 is not produced using Packer, instead it’s a regular Newton Toolkit project.
Slowly Progressing
Much of the Blunt code can be now reused, but there are some bigger parts which need to be redesigned completely, e.g. to support multiple active RFCOMM or L2CAP connections. In the end, it should pay off though, having an always-on Bluetooth stack is very handy, especially in the way I use my Newton: during the day it’s always on and running off the AC adaptor, otherwise I’m using rechargeable batteries. nn nnUnder the hood, things are looking quite interesting. Working with tasks, ports and messages seems easier than I thought, and the only thing which is a bit open at the moment is memory management. It’s possible to access data across task boundaries, but maybe shared memory would be the cleaner way to do things.
Serial Problems
Blunt 2 is supposed to be implemented as a standalone task which talks to the serial chip directly. It seems that the warnings in the DDK header files about using TSerialChip are justified… interfacing with the 16450 chip which is usually used for PCMCIA cards fails right in the initialization with a “deep toast” alert. I guess there is some magic happening with the interrupts, supervisor mode and other low level stuff. nn nnThe good news (at least for me) is that it works when talking to the Voyager chipset which is in charge of the internal serial port. That means that my internal Bluetooth modules should work fine. The only requirement is that instead of pain old serial communication with the chip, DMA has to be used. Another fun thing to reverse engineer! But it looks ok now, and besides getting some rudimentary Bluetooth stack up and running, I ‘just’ have to implement the CommTool counterpart which sits between the NewtonScript world and the Bluetooth stack.
Classic - here to stay?
Finally I found some time again to fiddle around with cross compiling for the Newton… my Cube needed hardware and software upgrades, but Tiger running on a dual 1.2GHz G4 is quite nice. The bad news is that GCC in the versions I tried it (2.95.3 and 3.3) generates or assumes virtual tables which are not compatible with what the original NCT compiler generated. This restricts any usage to either plain C code, or classes without virtual functions. In addition to that, the generated code didn’t look particularly efficient, it is also about 50% larger than the Norcroft code. nn nnWell, thanks to Paul’s toolserver, I can at least use Xcode as the development environment. The main problem with Classic is actually not using MPW, but Hammer, which sometimes hangs or crashes the complete Classic process… an RDI compatible replacement for Hammer would definitely be great!
To the Moon
One clearly underestimated programming language is Lua. I’m using it now to transform the ELF output of GCC to a Newton NSOF file. It’s amazing how flexible Lua is, and it would definitely be my first choice for any kind of system to replace the Newton. And it looks at least a bit like NewtonScript. The only thing missing are symbols, but I guess that adding them would mean adding a whole new paradigm or way of programming to Lua. This is where the less flexible NewtonScript is still ahead of most mainstream programming languages.
Distractions
Well, here we go again… instead of working on one thing, something else gets in the way and is way to interesting to not play around with. In this case it all started with the ancient Norcroft compiler crashing and taking MPW with it, just because I created some more complex class structures. So why not use something else instead? Xcode is a half decent IDE, there is a readymade ARM cross compiler for Mac OS X, and the NTK and NCT formats are also all available, e.g. on UNNA. Currently, there are only two things missing for bringing C++ programming for the Newton to this millenium: getting the runtime functions into a stub library, and duming the ELF image the GNU compiler produces into an NSOF formatted file. The runtime library is in principle easy to build, it just requires mapping the function names from the GCC mangled format to the Norcroft format which can be extracted from the debugger images. I guess there’s a way to do that automatically, but for now, I just add each undefined external function manually to the stub library. Some other smaller issues are exception handling and constructors, but I’ll get to that once the first module loads properly.
Moved to WordPress
Hurricane Electric moved my account to a new machine, and it seems that there’s some incompatibility with the Berkeley DB the Mottek data was stored in on the old machine. Well, I don’t really feel like setting up Movable Type again with all that registering stuff now requried, so I just switched to WordPress. Seems to be quite painless so far. The old pages are still available at http://40hz.org/mottek-old/.