romdisk 0.1 released

Recently, I was thinking about a minimal Amiga emulation setup that is required to run Exec and Dos from a Kickstart ROM image. Think of a reference platform for vamos. I soon came to the conclusion that all kinds of boot types result in accessing a device that provides the requested file system blocks. As a consequence the emulation also needs to emulate some kind of device accesses next to the essential CPU, memory, and CIA (timer, serial) emulation we will need at least. Trackdisk device needs custom chip support for track reading, while scsi.device needs some IDE host emulation.

If you compare a classic Amiga with modern embedded devices (like a Raspi or a Beagleboard) you see a difference: the modern devices often allow to boot directly their filesystem of the on-board flash. “Why not create a ROM bootable device for Amigas?” was the next question that came to my mind. With such a device it is sufficient to emulate CPU and memory and the Amiga can already boot…

The result of this initial idea is a small project called romdisk: It offers a romdisk.device that can auto-boot a modern classic Amiga (OS 2.x or 3.x) and also a tool to embed disk images into an ext. ROM image. Without compression you get ultra fast data access, but with compression you can even fit a complete Workbench floppy disk image (880 KiB) into your 512 KiB ext. ROM.

The first public release is now available and can be found on my new romdisk project page!

While it started as a helper project for my emulation tests, I am sure you can think of new uses for romdisks, too. E.g. some diagnosis tools that do not need external devices to run, or a rom disk stub that loads non-rommable modules and then heads over to full boot from hard disk, or a small network boot disk that loads the main file system via network…

Have Fun!

A lua shell for FS-UAE

While FS-UAE recently added a scripting interface with a Lua scripting binding, it only provides capabilities to write scripts with hooks that will be called on certain emulator events. I  hacked this scripting interface and added a Lua remote shell. With this shell you can connect while the emulator is running and issue commands. I also started to add disk image related functions to the Lua binding. With these features combined I could show off the power of a scripting shell by writing a tool to insert floppy and cd-rom disk images while the emulator is running – a long awaited and missing feature… Continue reading

fbTFT Setup on modern Raspbian

I am a big fan of those small TFT displays in the size of the Raspi. They even come with a resistive touch panel and allow you to realize small applications with full UI control. With the fine fbtft drivers from notro you can access them as regular framebuffers and use all software that runs otherwise only on “big screens” via HDMI.

While setting up the TFT support in a Raspbian system was quite complex and includes compiling an own patched kernel, nowadays things got really simple. In this post I’ll give you a overview on the setup and how easy it has become…

(And it works for good ol’ Model A/B, A+/B+, and shiny new Model B2!)

Continue reading

plipbox 0.5 released

Release 0.5 of plipbox is now available and contains a software-only update that ships both a new Amiga plipbox.device driver and a new AVR firmware.

New features are:

  • Most important change is the handling of the MAC address. While in previous versions you had to set the correct MAC in both the Amiga driver and the AVR firmware, the new version automatically transmits the MAC address from the driver to the firmware. Inside the driver you can alter the address with SANA-II commands (if your TCP/IP stack supports it). This allows you to set different MACs that are required if multiple plipboxes are running on the same network.
  • I also added some features of the Ethernet chip to be enabled by firmware parameters: Namely full duplex mode and flow control are new options you can play with to tune the performance.
  • The new firmware also tracks the online/offline state of the driver and enables or disables the Ethernet module accordingly.
  • On the firmware’s command console I improved the device statistics output by adding the number of filtered, dropped or erroneous packets. Furthermore a new error log shows you if errors were found on the parallel transfer.
  • Under the hood quite a lot changed: I re-wrote the whole parallel protocol to use a client (Amiga device) server (AVR firmware) model. That better fits our application as the old MagPLIP way assumed a peer to peer protocol on the parallel line. This driver driven approach simplifies the protocol significantly and obsoletes collision handling…

Now grab your copy of the new release on the plipbox page and have fun!!

Networking on the Minimig with PPP and Roadshow

When working with an Amiga running on a Minimig platform then data transfer is not as convenient as one might think: You have an SD Card connected and copying files around with SD Card is not the biggest deal, but unfortunately your Amiga is currently running from a system drive stored on this card :/ Each copy operation therefore essentially requires a reboot of your Amiga and that’s not the productive work flow I had in mind…

That’s the reason why I always prefer having network access on all my machines for truly covenient file handling (e.g. with FTP, wget…).

In my last post I showed you how to add a SilverSurfer high speed serial port to your Minimig running on the Turbo Chameleon 64. Now we will use this serial port that is running up to 115200 Baud with ease for something useful: networking! Old farts remember the times when home network access was done with PPP and a serial modem gateway. We’ll go that road but replace the modem and gateway with a small and cheap Linux machine, here the all hyped Rpi and a direct serial “null modem” link via an USB-to-serial adapter.

TC64 with SilverSurfer attached to Raspi

TC64 with SilverSurfer attached to Raspi

Read on to find out all the glory details, starting with a pure “virtual” simulation running on a Mac on to the real thing…

[You can use this approach to bring other classic Amigas to the network, too. But for all machines with a parallel port available I’d suggest to use my plipbox project: Its far easier to setup, a lot faster (4-5x ), and even cheaper :)]

Continue reading

Added SegTracker in FS-UAE’s Debugger

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!

Continue reading

Building AROS hosted for Raspbian

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…

Continue reading

plipbox 0.3 released

It took quite a while but now a shiny new release of plibbox is available: The new version 0.3 is an AVR firmware and Amiga driver update and works on the same hardware as presented in 0.1 and 0.2.

The major change in this release was motivated by Nitz76, one of my commenters in the blog: plipbox firmware now implements a MAC bridge and no IP NAT gateway anymore (see this technical introduction for details on the differences). In short: While with the old firmware you created a point-to-point IP link from the Amiga to your plipbox and from there the traffic was NATed and routed to your local ethernet, the new approach directly presents an Ethernet card on the Amiga side and passes the Ethernet frames generated from the Amiga TCP/IP stack directly via PLIP to your local Ethernet.

This approach is much more compatible in your local network infrastructure as the NAT is avoided. The change required a larger rewrite of the SANA II driver and therefore I heavily modified the original MagPLIP implementation and renamed the new driver to plipbox.device (the new source code is now also hosted in the plipbox source repository). Please see the updated Amiga Setup guide for installing this driver on the popular TCP/IP stacks including AmiTCP, Genesis, MiamiDX, and Roadshow.

The new MAC bridge made a lot of the TCP/IP code of plipbox obsolete and allowed me to shrink the firmware size considerably. Furthermore, setting up the firmware is zero-conf now, i.e. you don’t have to adjust any parameters for default operation.

This release now hosts all the docs on GitHub right next to the source. It is more convenient there to keep the docs in sync with the implementation and writing markdown is really fun! Another goodie in this release is the plipbox Emulator written in Python that allows to emulate a plipbox setup in FS-UAE. Its esoteric but really helpful for development: see my previous log post for details…

Enjoy!

Emulating plipbox with FS-UAE

Recently, I had some time to spend and wanted to work on the plipbox project’s Amiga driver. Unfortunately, I only had my MacBook Pro with me and no Amiga or plipbox hardware.

What does a SW developer do if the real hardware is not at hand?

Yes, you write an emulator that represents the missing HW in SW on a machine you have access to…

Continue reading

Adding touch support for the MI0283QT* displays

In my last posts I showed how to integrate Watterott’s MI0283QT-2 and the newer -9 displays as a frame buffer device in Raspberry Pi’s Linux kernel. Now I will focus on adding support for the touch controller found on the display boards.

The touch controller is an ADS7846 chip that already has a device driver in the Linux kernel. User dronus has patched the vanilla driver to make it work with the MI0283QT displays and the Raspberry Pi.

Fine, we already have everything in place now to give it a try!

Hardware

First, we need to add two additional wires in our hardware setup to connect the touch controller (see old wiring in last post) with the RPi:

Signal     Raspi      Display   Comment
T_IRQ      GPIO25       13       Interrupt line from ADS7846
T_CS       SPI0_CE0_N   11       SPI chip select 0

Software

I assume you already have a patched Linux kernel with the tft driver patches applied. Here is quick list with the next steps:

  • (Manually) apply dronus small patch to your kernel tree. This adds the necessary modifications of the ADS driver.
  • Note: I had to replace the invert_x with the invert_y entry in the ADS configuration to match the display orientation we use in the frame buffer driver
  • Your SPI config for the display now should look like this (for the newer *-9 display): linux/file arch/arm/mach-bcm2708/bcm2708.c
static struct ads7846_platform_data ads7846_config = {
  .x_max      = 0x0fff,
  .y_max      = 0x0fff,
  .x_plate_ohms    = 180,
  .pressure_max    = 255,
  .debounce_max    = 10,
  .debounce_tol    = 3,
  .debounce_rep    = 1,
  .gpio_pendown    = 25,
  .keep_vref_on    = 1,
  .swap_xy     = true,
  .invert_y    = true
};

static struct spi_board_info bcm2708_spi_devices[] = {
        {
                // ads7846 touchscreen on chipsel=0 device
                .modalias    = "ads7846",
                .bus_num    = 0,
                .chip_select    = 0,
                .max_speed_hz           = 500000,
                .irq      = GPIO_IRQ_START+25,
                .platform_data    = &ads7846_config,
                .mode = SPI_MODE_0
        }, {
                // display on chipsel=1 device
                .modalias = "ili9341fb",
                .max_speed_hz = 16000000,
                .bus_num = 0,
                .chip_select = 1,
                .mode = SPI_MODE_0,
                .platform_data = &(struct fbtft_platform_data) {
                        .gpios = (const struct fbtft_gpio []) {
                                { "reset", 23 },
                                { "led", 24 },
                                {},
                        },
                        .fps = 10
                }
        }
};
  • I use GPIO 25 for the touch IRQ (mainly because wiring was easier this way 🙂 and had to change the relevant entries. dronus used GPIO 17 instead.
  • I reduced the SPI rate of the display to 16 MHz and the frame rate to 10 fps. This proved to be more stable with activated touch controller.
  • The older -2 display works similarly. You only have to exchange the second block with the one of the r61505u driver. See old post for details
  • Open the configuration of the kernel and select the ADS driver:
> make menuconfig
Select "Device Drivers -> Input Device Support -> [*] Touchscreens -> [*] ADS7846..."
  • Make sure to include the ADS driver directly into the kernel and NOT in a module
  • Ok, thats it! (Re-)compile kernel and install it on your RPi…

Test

After a reboot your system shows a new input device in /dev/input/*. If no other USB mouse or keyboard is connected then the devices found there are all created by the touch controller.

You can use the evtest utility to check the touch operation (Install with ‘apt-get install evtest’ first!):

> evtest /dev/input/event0

When you tap on the display you will see the incoming events. Note the x and y coordinates mapping if you tap on different corners of the display.

Now with the basic operation tested you can start X11 on your display (see last post) and use your fingers or a stylus to navigate the mouse cursor!

Open Topic

While touch operation with this driver is rock solid and works very precisely I have found one little nuisance: I can’t move the X11 cursor into the border regions of the display 🙁 Approx 5 mm at the border of the visibile display area my touch movements are not recognized anymore and I can’t move the pointer there… I am not sure if this is a limitation of the display, of the ADS driver or the parameter set for the driver… If you find a workaround for this then please post a comment!

[Update: 21.4.2013] Pre-compiled Kernel

A pre-compiled Raspbian Wheezy Kernel 3.6.11+ with both ili9341 display and ads7846 touch driver (i.e. supporting all devices on the MI0283QT-9 board) is available for download here: