For most classic Amiga developers Michael Sinz’ Enforcer is a valuable tool for debugging. Especially the contained tools SegTracker and FindHit are very helpful when analyzing bugs in your compiled code: SegTracker patches AmigaDOS’ functions for loading and unloading binary files and then tracks where the (code/data/bss) segments of each binary are located in memory. If a crash occurs then you can locate which binary caused it. To get more detailed information then FindHit comes into play: If the segment associated with a crash location is identified then FindHit loads the debugging info stored in an executable and then can match these infos to your location and gives you the source code file and line that was used to generate the faulty code…
I do most of my Amiga development now in a cross-dev environment on my Mac and then the FS-UAE emulator is the runtime environment to test and debug code. While it is possible to use the same Enforcer setup inside FS-UAE I really like the built-in debugger of the emulator: It allows to freeze the whole Amiga and inspect the full state. Furthermore, memory watchpoints and breakpoints are available, too. The only thing that was missing: a SegTracker feature that tells me where my application/driver code is loaded and a FindHit feature to get detailed infos on the associated source.
Thanks to open source of both FS-UAE and Enforcer I was able to add both features without too many effort: In the following I present you an extended FS-UAE that adds SegTracker and FindHit right inside the built-in debugger!
The Raspberry Pi platform really looks very suitable for running AROS. I wanted to play with this setup and build a Raspbian (armhf) release from source (so I can hack on if I like to). I chose the Linux hosted version of AROS as it is already available in the source tree and Raspi’s Linux kernel is a very good hardware abstraction layer for all Raspi peripherals. (The native Raspi AROS version exactly suffers from this: It has to implement all peripheral drivers that are already available in Linux – and that is a daunting task).
I had a look at the AROS Raspberry Pi Docs,Â but unfortunately the compilation details given there didn’t work for me. I have a xubuntu 12.04 VM running here on my Mac and it seems that this version does not support the multiarch compile given in the docs not very well… (I even had a quick check with the fresh release 13.04 but that one does not work either… so things don’t look good with this approach): The problem I encountered was that the multiarch setup does not allow to install libpng-dev for i386 and libx11-dev/libsdl-dev for armhf simulatenously. But both are required for a full compile of AROS…
I played around with the build process and found an own way to perform the build on my system. This post gives you the details…
Notro has added a generic frame buffer driver called flexfb in his fbtft driver framework. This driver resulted from the observation that most small TFT driver chips share a lot in common like data transfer scheme, pushing pixels, and setting the update window. The only major difference is found in the initialization sequence required to setup the connected TFT panel on your specific board. Therefore, the flexfb driver user needs only select some generic option (e.g. bus width, type of update window command) and a transcription of the init sequence found in the driver code during runtime. Then the driver can control the display.
The big advantage of this approach is that you only need to ship this one generic driver and you can support a large set of displays without actually coding them. Also adding a new device requires only extracting the init sequence from the display’s data sheet and you can test it on the command line without any driver code development!
I gave this nice approach a quick try with Watterott’sÂ MI0283QT-9 display (that’s already fully supported in the ili9341fb driver of fbtft, but nevertheless the generic approach might be the future :)…
Huh? Yet another plipbox release in such a short time, you might ask. While last time it was a software only update this time its a hardware update! I found such a nice new HW platform for the plipbox project that is really worth an immediate release…
While browsing ebay for some interesting hacking hardware last week, I stumbled across an Ethernet shield for the Arduino Nano that uses the ENC28J60 chip I need for the plipbox project in a very compact package… Combined with an off-the-shelve Arduino Nano v3 (clone from ebay that is) you get a very very nice packaging for the plipbox project. I call itÂ the plipbox nano:
The release 0.4 now adds all you need to build your own plipbox nano:
- A new firmware image for the nano (some parallel pins need to be changed due to collision with the Ethernet shield)
- A schematic and board design for the plipbox nano base board. This board combines the parallel port connector and pin headers for the Ethernet shield. With the base board your can connect the plipbox nano directly to your Amiga and it really fits well without hiding the other connectors. See the plipbox gallery page for snapshots of an A1200 with attached plipbox nano. The board is a single layer PCB so you can build one yourself without much hassle. As an alternative you can simply use a small prototype board and solder the connector and pin headers there.
Grab your copy now on the plipbox project page and have fun building your own plipbox nano!