I just thought that this code may be interesting to other people who did not attend this conference.

The demo code includes mainly x86 specific stuff and it is truly demo code, so don’t just copy it into another project. Even if it works at first sight, it it is highly likely to break sooner or later

The code contains samples for:

• A small “Hello World” bootsector in realmode
• A sample how to enable the A20 gate. This works at least in QEMU
• Loading a barebone-kernel written in C by GRUB
• Switching to protected mode and writing to the textmode framebuffer
• Handling interrupts in protected mode using the old PIC
• Configuring and using the old PIT (Timer)
• Switching to longmode (64 Bit)
• A multitasking demo how to do context switching

The first two samples are completely written in Assembly and are loaded directly by the BIOS from a floppy drive. All other samples are mainly written in C spiced with some Assembly and are loaded from a FAT formatted floppy disk by a GRUB bootloader.

For those of you who speak german, here are the slides of the conference:
Talk
Workshop

If you do anything with this demo code, I would appreciate to hear about your project or experiences. Also, If there are specific questions or problems about/with this code which are not easily resolvable by Googling and using your brain, feel free to ask in the comments.

Feel free to Flattr this post at flattr.com, if you like it.

Als ich so schräg auf den Nadeldrucker in der Ecke schielte und fragte ob der noch funktioniere, wollte ich drucken. Nunja, das nächste anstehende Event war also die SigInt. Wenn man etwas zusammenhackt will man das auch dem breiten Publikum präsentieren können. Nach einiger Zeit hatten wir dann die Idee eine Longcat zu drucken.

Nur der Bauch sieht dann doch etwas leer aus, wenn wir nur den Kopf und dann den “Körper” in Form von Strichen links und rechts am Papierrand drucken. Also was pappen wir da rein? Es gibt da doch dieses Twitter. Also gehen wir flott an die Twitter Suche und schieben alles was mit der SigInt zu tun hat in den Bauch.

Spaß!

Es waren Blödeleien und wir hatten beim Basteln viel Spaß. Deswegen machen wir das.

Als wir dann auf dem Event selbst waren lief das Teil natürlich noch nicht. Die übliche Vorgehensweise: Man hat vorher Monate Zeit und tut nichts. Wenn man dann auf dem Event sitzt fängt man richtig an zu hacken.

Was konnten wir zu dem Zeitpunkt? Unser Mikrocontroller konnte mit dem Drucker reden und hat den Kopf und den Bauch gedruckt. Per serieller Schnittstelle nahm er Text an, der in den Bauch gedruckt wurde. Über diese Schnittstelle sollten über ein Script die Tweets zur SigInt an die Katze geschickt werden.

Durch die üblichen Fuckups funktionierte genau das natürlich nicht.
Irgendwann in der Nacht, als es auf die Party zuging auf die wir auch noch wollten, hatten wir keine Lust mehr. Die Longcat war aber immernoch leer.

Aber… da gibts doch noch ASCII-Art. “Kennt wohl jeder hier”, dachten wir uns und was liegt da näher als was hübsches und historisches zu drucken?
Hey, guck mal. Ein ASCII-Bild einer Frau. Drucken wir das doch.
Nachdem wir dann endlich die ersten Zeichen im Bauch der Katze hatten machten wir den Drucker aus und gingen feiern. Den Rest machen wir dann morgen.

Und da nahm die Katastrophe ihren Lauf…

Am nächsten Tag war dann das Genderpanel. 5 Frauen die über die Probleme der Gleichberechtigung von Frauen in der Hackerszene diskutieren (sic!) wollten.

Wie sich dann im Laufe des Tages herausstellte, haben sie auch über unser ASCII-Bild geredet. Ich selbst war nicht im Genderpanel, deswegen habe ich das auch nur über dritte Personen gehört. Zuerst dachte ich, dass das ganze ein Scherz sei, bis mir immer mehr Leute darüber berichteten.

Was zum Teufel?

Es kam aber auch keiner zu uns und versuchte mit uns einen Dialog anzufangen. Wenn jemand gesagt hätte, das ihn/sie (OMG, jetzt fang ich hier schon an Texte zu gendern…) das stört, hätte ich wahrscheinlich erstmal wegen gewisser Unverständnis wie ein Auto geguckt und etwas gestutzt, aber wir fressen unseren Gegenüber wegen sowas ja nicht, solange wir nicht persönlich angegriffen werden.

Als ich dann später erfuhr, das wir wohl mehr oder weniger im selben Atemzug mit Hardcore Pornografie genannt wurden, wurde ich auch leicht pissig. Ich bin der Meinung diese Frauen im Genderpanel haben uns dazu benutzt zu provozieren. Erstmal nichts schlimmes. Sollen sie doch. Das bringt die Diskussion in Wallung, was auch definitiv passiert ist.
Allerdings bitte ich doch darum, das wir nicht als Sexisten oder Frauenfeinde hingestellt werden, denn genau so kam das rüber.

Sie hatten einfach kein besseres Beispiel dazu. Ich glaube nicht, das das wirklich jemanden gestört hat. Sie brauchten nur irgendwas, um Leute zu denunzieren und aus einer Mücke einen Elefanten zu machen.
Sie haben zwar nicht unsere Namen genannt, es war aber unvermeidlich, das jeder wusste wer wir waren, da wir den ganzen Tag neben dieser gedruckten Katze saßen.

Und was hat das mit Behandlung von Frauen zu tun? Nur, weil ich/wir ein ASCII-Bild einer Frau gedruckt haben, heißt das nicht das wir Frauen anders behandeln oder sie gar zu einem Sexobjekt degradieren. Es war ein ASCII-Bild. Nichtmal eine reale Fotografie einer Frau. Deswegen ist es so unverständlich für mich, wie sich da jemand angegriffen fühlen kann.
Zumal die Frauen ja Gleichberechtigung wollen. Wenn wir also wegen den anwesenden Frauen kein Bild drucken, ist das dann noch Gleichberechtigung?

Um dann aber sicher zu gehen, das sich die Frauen nicht benachteiligt fühlten, haben wir uns dann doch ans Herz gefasst und auch einen Mann gedruckt. Sie appellierten ja wie gesagt auch, das wir sie gleich behandeln sollen.

So viel zu meiner persönlichen Sichtweise zu der ganzen Sache.

Als zweites will ich hier noch kurz betonen, das dieses ASCII-Art seit Urzeiten zu unserer (Hacker-/Nerd-)Kultur gehört. MSPro hat das sehr schön in seinem Post über Plattformneutralität dargestellt.
Und wer sich in solchen Kreisen bewegt, hat das nunmal zu akzeptieren. Selbst, wenn da Frauen gedruckt werden.

… und wenn das Farbband hält, dann drucken sie noch heute.

Feel free to Flattr this post at flattr.com, if you like it.

Doing this with real hardware is kinda risky and complex.
But what about virtual machines like VMware? They have a BIOS, but how can we get our hands on it?
As I’m using Mac OS X for all my daily work, I’m using VMware Fusion as a virtualization program.

The BIOS seems to be hidden inside the virtual machine monitor executable itself.
To make our lifes easier, we are going to extract only the x86_64 part out of the universal binary with the following command:

lipo /Libary/Application\ Support/VMware\ Fusion/vmware-vmx -thin x86_64 -output /Users/user/Desktop/vm64

Now, we have a Mach-O file with only one architecture, which is x86_64.
It doesn’t matter if you are dumping the BIOS out of the i386 or x86_64 version of the binary. It should be the same for both architectures.

After that, we can extract the appropriate section in the Mach-O file which contains the BIOS itself:

segedit /Users/user/Desktop/vm64 -extract __VMWARE bios440 /Users/user/Desktop/bios440.rom

And here, you go: bios440.rom contains your VMware BIOS.

After you modified it to your wishes, you can use a handy VMware feature which lets you specify a custom BIOS for a virtual machine inside its vmx-file.
Just add this line to the vmx-file of the machine you want a custom BIOS for and place the rom file in the proper folder:

bios440.filename = "bios.rom"

Happy BIOS modding!

Feel free to Flattr this post at flattr.com, if you like it.

Now, that there are much fancier phones out there, like the Nexus One and Motorola Milestone, there must be a reason for people to buy them. The consequence about that is that they are holding back any updates to Android 2.0 or 2.1 for older phones. At least that’s my impression.

I also ever wanted to build and run my own Android since it is open source. At least that’s what Google says.
My first steps were quite disappointing since there was no device specific package for my G2 in the source tree. There was only one for the HTC Dream (G1).

Yesterday I wanted to give it another try and it was a success. I will post my steps here which are especially for the HTC Magic (or G2, HTC Sapphire, MyTouch 3G, Google IO – they are all the same) but it should be possible to do this with other phones as long as you have all the device specific blobs like the GSM Baseband layer or low level hardware drivers for your specific device.
Also keep in mind that this won’t be a normal guide like “How can I root this phone?” I assume that you more or less know what you are doing. So don’t blame me when you brick your phone: Shit happens and I’m not going to fix it.

Also, be careful what phone you have. There are 2 versions of the HTC Magic. One is the PVT32A and the other is PVT32B.
The A version has more RAM compared to B. The phone sold by HTC on their own is the A version. Almost all others are B versions. My phone is a B variant.
Check this site for any further information.

The SPL

The SPL is the Secondary Program Loader. The Initial Program Loader, which runs before the SPL is responsible for the basic bootstrapping of the processor inside the phone. Most of the time it is located on some on-die ROM and loads the SPL from flash.

The SPL itself is responsible for all kinds of boot services like booting from flash or receiving and handling data from the USB port with the fastboot protocol, which can be used for several maintenance tasks.

Usually, if you buy an OEM phone, you will get a shipment bootloader. Development phones will have an engineering bootloader.
The difference between those two is that with the shipment bootloader, you will not be able to write the flash directly from your computer over the fastboot protocol, which you definitely want if you compile/develop your own Android. So the first step is to install an engineering loader.
You can get several SPLs here. I installed the Crios  loader.
Just put the zip file on your SD-Card, boot a modified recovery image via fastboot and apply the zip file from your SD:

fastboot boot cm-recovery-1.4.img

The fastboot utility is available here or from your compiled Android in the out/host/<platform>/bin/ subdirectory.
To get your phone into fastboot mode, turn it off and hold the “back”-key while turning it on.

After flashing the new SPL you will have the engineering bootloader with security turned off.

Getting the Android sourcecode

If you want to build your own Android you obviously need to get the sourcecode. I did all the work on a Gentoo Linux. I don’t know how to do it under Windows or Mac OS.

First I thought to take the CyanogenMod repositories but they won’t check out completely because there seems to be missing at least one repository on github.

To get the official Google tree, just follow this guide.

Essentially you just install the required packages, get the repo client, do the repo init, repo sync and you should be done.

Get the binary blobs

For the Sapphire board package, you will need to get some binary blobs for the camera, WLAN, baseband and several other things.

You can download them on the HTC page for the Google IO. Just download the recovery image for Android 1.6 and put it into the root of your Android source tree.
After that you need to change the directory to vendor/htc/sapphire-open and execute the unzip-files.sh which extracts the blobs from the downloaded zipfile and puts them into the appropriate places.

Building it

After you prepared your environment, get back to the root of the source tree and do a

source build/envsetup.sh
lunch

to setup several environment variables and select the build target, which will be aosp_sapphire_eu-userdebug in our case.

After that you can just execute a

make -j3

to start the build. You can adjust the number behind the -j parameter to your machine. If you have n cores, the number you normally use is n+1. This is not essential for a successful build, but if you have 2 or more cores, you should use them for the build.
Now it’s time to ge some beautiful delicious black coffee or a cold bootle of Club-Mate, go for a walk or take a nap. This will take quite some time.

Common errors during the build

I ran into several erros while buildng. All of them were specific to my environment.

• no rule to make target `run-java-tool’ during build
  Solution: Just execute a export PATH=$(java-config -O)/bin:$PATH and the error you should be gone
• Java 1.6 is installed.
  Solution: Do an ACCEPT_LICENSE=”*” emerge =sun-jdk-1.5.0.22 and select the 1.5 JDK with eselect.
• Building the emulator fails with something like prebuilt/linux-x86/sdl/include/SDL/SDL_syswm.h:55:22: error: X11/Xlib.h: No such file or directory
  Solution: Do an emerge libX11

Installing the built images on your phone

After the build finished successful you will have everything in the out subdirectory.

Thanks to the engineering SPL, you can now install the built images using fastboot:

export ANDROID_PRODUCT_OUT="/path/to/android/root/out/target/product/sapphire-open"
fastboot flashall

Be sure your phone is in fastboot mode.

After you flashed the images you should boot the recovery image, mentioned in the SPL section, again and wipe the userdata partition.
This will cause a data loss. Anyway, you should have done a backup with nandroid in the modified recory image before messing around with your phone’s firmware

The result

Next steps

As you can see from the images above, all of the Google applications are missing. The next step would be to take them from an official Google image and put them on your phone. I think cyanogen already wrote a script for doing this for his builds. I haven’t checked this out yet.

Anyway, we have our very own Android 2.1 running.
If you want to use it on a daily basis you should consider building a stable branch and using this instead of the master branch.

If you’ve got any questions or problems, just leave them in the comments and we will try to figure them out.

Update: The cyanogenmod repositories do check out. I just used the wrong manifest repository.
If you want to give it a try, just do a

repo init -u git://github.com/cyanogen/android.git -b eclair
repo sync

instead of using the Google repository. Have a look here for more information.

General useful information, like adding your own target, creating keys for signing etc. can be found here.

Feel free to Flattr this post at flattr.com, if you like it.

I ordered this switch (a TP-Link TL-SG1008D) for just about 30€ including shipping and today I got my package. I opened it, checked if the switch works and voided the warranty.
After opening the device it was clear that I got some other hardware compared to tmbinc. I don’t have this monster heat sink on top of a BGA chip. Instead there are two smaller LQFP-Chips with one heat sink each.

A closer look at my and tmbinc’s images relieve that my switch is actually revision 1.1 and tmbinc’s is revision 2.0.

I tried to remove the heat sinks with pliers but I didn’t want to damage my new toy.
Also, I wanted to know how warm these chips get while using the device, so I took some ethernet cables, made some loops and inserted one cable into the ethernet jack into my laptop. As soon as Mac OS detected an active connection it broadcasted at least one package onto the line that was looping happily from one switch port to the next
I let this thing running for about 10 minutes and the chips didn’t get very warm. I hoped that the glue would get a bit less sticky due to the heat, but there was just no heat. Seems that the heat sinks did a good job there. So I tried the exact opposite and put this thing into my freezer for a few minutes. After it got cooled down a few degrees I took my pliers and applied some force and look: They came off.

As you can see there are two Realtek chips on this board. The right chip is an RTL8214. The Realtek Website says that this chip is just a quad-port gigabit ethernet transceiver.
The other chip is an RTL8368S. Here the Realtek Website tells us, that this chip is actually the switch controller for 8 ports, but it has only 4 transceivers, hence the second transceiver chip. On the pictures you can clearly see some bus between the two ICs.
And look at the features: Per port-ACLs on Layer 2, 3 and 4, VLAN, Spanning Tree, 802.1x, QoS and several statistic counters.
Unfortunately the datasheets for both chips don’t seem to be publicly available.
<rant>I absolutely hate all this NDA crap… Those fscking ethernet chips are no rocket science that needs to be protected in such a way. SRSLY!</rant>

On the upper side of the image above you can see a small IC with part number 24C08, which is an 8KBit I2C EEPROM. I haven’t looked at the contents yet, but I suspect that this EEPROM contains the configuration for the switch controller, but I doubt that the contents will be of any help without a datasheet

Some closeups of the chips:

Update: I found some datasheets for several Realtek Chips. There is no datasheet for the RTL8368, but for the RTL8369. It seems that the only difference between those two chips are that the latter doesn’t have any transceivers on-die, but only some SGMII ports for all 8 Ethernet ports. I think I’m going to dump the EEPROM and try to get some information out of it with the 8369 datasheet.

Feel free to Flattr this post at flattr.com, if you like it.

Draufgegangen ist das unter anderem für dieses hübsche, aber leider teure FPGA-Board mit einem Xilinx Spartan 3 FPGA:

Wie man sieht, sieht man ein A auf dem LCD Display. Viel mehr habe ich damit noch nicht zustande gebracht. Besonders einfach wirds einem aber sowieso nicht gemacht. Das Ding ist halt kein Prozessor, mit dem man sequentielle Abläufe durch das Ausführen eines Programms abbilden kann, sondern pure Digitaltechnik.
Durch VHDL wird einem das Beschreiben etwas einfacher gemacht, die Vorgänge laufen aber alle parallel in diesem Chip ab. Signale warten nicht einfach so auf ein Ereignis.

Signalabläufe wie sie von einem Displaycontroller erwartet werden können auch nur über eine Statemachine modelliert werden. Man hüpft also von einem Zustand in den anderen und legt die passenden Signale an die Leitungen. Danach springt man meistens wieder in eine Warteschleife, weil der LCD-Controller üblicherweise langsamer ist als so ein FPGA.

Da man das ganze äußerst schlecht debuggen kann, simuliert man im Vorfeld die Abläufe. Man schreibt also erstmal sein Modul in VHDL und darf sich dann auch noch darum kümmern einen Sogenannten Testbench zu schreiben. Dieser Testbench ist dann dafür zuständig die passenden Signale, die normalerweise durch externe Quellen erzeugt werden, an das Modul zu legen, um das alles in Software abbilden zu können.

Nachdem man dann die Simulation für einige Milisekunden ausgeführt hat, sieht das so aus:

Auf diesem Bild sieht man die Simulation eines RS232 Moduls. Die Länge eines Bits ist hier 8,6µs, was eine Baudrate von 115200 pro Sekunde ergibt.
Als erstes wird in tx_data das Byte abgelegt, welches üertragen werden soll. Dann zieht man tx_start kurz auf High, was man hier nicht sieht, da es bereits 40ns nach dem Start passiert, und die Übertragung startet. Erst kommt das Startbit auf der TXD-Leitung, dann eine 0, dann eine 1 usw. bis das Stopbit kommt und die Leitung wieder auf “Standby” geht und somit 0xAA übertragen wurde. RS232 überträgt das niederwertigste Bit zuerst.

Analog läuft das mit dem Empfangen ab.

In VHDL sieht das ganze dann so aus:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity RS232 is
    Generic ( Clockrate : integer   := 50000000;  -- Hertz
              Baudrate  : integer   :=  9600      -- Bits/Sec
             );
    Port ( RXD      : in   STD_LOGIC;
           RX_Data  : out  STD_LOGIC_VECTOR (7 downto 0);
           RX_Busy  : out  STD_LOGIC;
           TXD      : out  STD_LOGIC;
           TX_Data  : in   STD_LOGIC_VECTOR (7 downto 0);
           TX_Start : in   STD_LOGIC;
           TX_Busy  : out  STD_LOGIC;
           CLK      : in   STD_LOGIC
           );
end RS232;

architecture Behavioral of RS232 is
signal txstart : std_logic := '0';
signal txsr    : std_logic_vector  (9 downto 0) := "1111111111";
signal txbitcnt : integer range 0 to 10 := 10;
signal txcnt    : integer range 0 to (Clockrate/Baudrate)-1;

signal rxd_sr  : std_logic_vector (3 downto 0) := "1111";
signal rxsr    : std_logic_vector (7 downto 0) := "00000000";
signal rxbitcnt : integer range 0 to 9 := 9;
signal rxcnt   : integer range 0 to (Clockrate/Baudrate)-1; 

begin
   send: process(CLK)
   begin
      if rising_edge(CLK) then
         txstart <= TX_Start;
         if (TX_Start = '1' and txstart = '0') then
            txcnt    <= 0;
            txbitcnt <= 0;
            txsr     <= '1' & TX_Data & '0';
         else
            if(txcnt<(Clockrate/Baudrate)-1) then
               txcnt <= txcnt + 1;
            else
               if (txbitcnt < 10) then
                  txcnt    <= 0;
                  txbitcnt <= txbitcnt + 1;
                  txsr     <= '1' & txsr(txsr'left downto 1);
               end if;
            end if;
         end if;
      end if;
   end process;
   TXD     <= txsr(0);
   TX_Busy <= '1' when (txbitcnt < 10) else '0';

   receive: process(CLK)
   begin
      if rising_edge(CLK) then
         rxd_sr <= rxd_sr(rxd_sr'left - 1 downto 0) & RXD;
         if (rxbitcnt < 9) then
            if(rxcnt < (Clockrate / Baudrate) - 1) then
               rxcnt    <= rxcnt + 1;
            else
               rxcnt    <= 0;
               rxbitcnt <= rxbitcnt + 1;
               rxsr     <= rxd_sr(rxd_sr'left - 1) & rxsr(rxsr'left downto 1);
            end if;
         else
            if (rxd_sr(3 downto 2) = "10") then
               rxcnt    <= ((Clockrate / Baudrate) - 1) / 2;
               rxbitcnt <= 0;
            end if;
         end if;
      end if;
   end process;
   RX_Data <= rxsr;
   RX_Busy <= '1' when (rxbitcnt < 9) else '0';

end Behavioral;

Mit einer “entity” beschreibt man, dass es irgendein Modul mit entsprechendem Namen gibt und welche Leitungen da rein und rausgehen.
Im “Behaviour” beschreibt man dann, wie sich das Modul verhält und welche internen Signale oder Variablen es gibt. Wir haben in diesem Fall 2 Prozesse. Einen zum Senden und einen zum Emmpfangen. Jeder dieser Prozesse kann gleichzeitig ausgeführt werden.

Der passende Testbench zu diesem RS232 Modul sieht dann so aus:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.ALL;

ENTITY rs232_tb IS
END rs232_tb;

ARCHITECTURE behavior OF rs232_tb IS 

    -- Component Declaration for the Unit Under Test (UUT)

    COMPONENT RS232
   GENERIC ( Clockrate : integer := 50000000;
             Baudrate : integer := 115200);
    PORT(
         RXD : IN  std_logic;
         RX_Data : OUT  std_logic_vector(7 downto 0);
         RX_Busy : OUT  std_logic;
         TXD : OUT  std_logic;
         TX_Data : IN  std_logic_vector(7 downto 0);
         TX_Start : IN  std_logic;
         TX_Busy : OUT  std_logic;
         CLK : IN  std_logic
        );
    END COMPONENT;

   --Inputs
   signal RXD : std_logic := '0';
   signal TX_Data : std_logic_vector(7 downto 0) := (others => '0');
   signal TX_Start : std_logic := '0';
   signal CLK : std_logic := '0';

   --Outputs
   signal RX_Data : std_logic_vector(7 downto 0);
   signal RX_Busy : std_logic;
   signal TXD : std_logic;
   signal TX_Busy : std_logic;

  constant clk_period : time := 20 ns;

BEGIN

  -- Instantiate the Unit Under Test (UUT)
   uut: RS232 PORT MAP (
          RXD => RXD,
          RX_Data => RX_Data,
          RX_Busy => RX_Busy,
          TXD => TXD,
          TX_Data => TX_Data,
          TX_Start => TX_Start,
          TX_Busy => TX_Busy,
          CLK => CLK
        );

   clk_process :process
   begin
      CLK <= '0';
      wait for clk_period/2;
      CLK <= '1';
      wait for clk_period/2;
   end process;

   -- Stimulus process
   stim_proc: process
   begin
      RXD <= '1';            --idle
      wait for clk_period*2;

      TX_Data <= "10101010";
      TX_Start <= '1';

      wait for clk_period*5;
      TX_Start <= '0';

      wait for clk_period*5000;

      --startbit
      RXD <= '0';
      --435 clock cycles by 20ns each = 8,7us = length of bit with 115200 baud
      wait for clk_period*435;

      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;
      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;
      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;
      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;

      --stopbit and idle
      RXD <= '1';

      wait;
   end process;

end;

Der Aufbau ist ähnlich wie vorhin. Die Entity hier enthält jedoch keine Ein- oder Ausgabesignale, da hier später nur die internen Signale dieses Testbenches im Simulator betrachtet werden. Natürlich kann man später in der Waveform noch weitere Signale hinzufügen. Zum Beispiel interne Signale aus dem getesteten Modul.
Im Behaviour wird dann als erses die Komponente RS232 definiert. Es gibt also irgendwo ein solches Modul, das später hier genutzt werden kann. Darauf folgend kommen wieder einige Signale, denen man später in Prozessen Werte zuweisen kann oder von denen man Werte auf den Leitungen abgreifen kann.
Danach wird ein RS232 Modul mit dem Namen uut (“unit under test”) instanziert und die Ports des Moduls werden mit den internen Signalen verknüpft.
Dann folgen wieder Prozesse. Der erste generiert das Clocksignal und der zweite ist für den eigentlichen Ablauf des Test verantwortlich. Das Senden ist hier relativ einfach: Wert in tx_data schreiben, für kurze Zeit an tx_start ziehen und dann beginnt die Übertragung.

Der Empfangstest ist dahingehend schwieriger, dass jedes Bit für eine bestimmte Zeit anliegen muss, wie es in Wirklichkeit auf einem Kabel auch der Fall wäre.
clk_period*435 entspricht hier exakt 8,7µs, was wiederrum ungefähr 115200 Baud/s entspricht: 20ns*435 = 8700ns = 8,7µs

Als nächstes werde ich mich mal an den VGA Ausgang setzen und probieren ein Bild zu zaubern. Danach ist allerdings auch schon der DDR2-Speichercontroller dran: Für ein 12 Bit VGA-Bild bei einer Auflösung von 640×480 Pixeln sind schon 450KB Video RAM nötig. Mit double buffering sind wir dann bei 900KB.

Update: Das RS232 Modul stammt im übrigen von hier. Lediglich den Testbench habe ich mir dann noch dazugeschrieben.

Feel free to Flattr this post at flattr.com, if you like it.

Nachdem ich dann auch irgendwann mal raushatte, wie ich das vierstufige (!) Paging mit 4KB großen Pages beim Booten zusammenbauen konnte, um so einen Prozessor in den Long Mode zu bekommen, hab ich mich mal an die Virtualisierung machen wollen.
Zu diesem Zeitpunkt saß ich allerdings schon im Hackcenter.

Wie ich dann, mal wieder, feststellen musste, hat so ein Low Level Zeug einen unglaublichen Rattenschwanz, den man immer wieder hinter sich herzieht. In diesem konrekten Fall brauchte ich also ein vernünftiges Interrupthandling. Ist ja schnell implementiert, dachte ich mir und kopier mir meinen Code aus meinen anderen Projekten fröhlich zusammen.

Interrupts konnte ich dann handlen. Problem war jetzt nur, dass 2 Instruktionen nach dem Aktivieren der Interrupts sofort der Interrupt #8 auftrat, was nach Dokumentation ein Double Fault gewesen sein müsste. Dieser tritt aber nur nach einer fatalen, vorhergegangenen Exception auf, wovon ich aber nichts mitbekommen habe. Wieso fliegt da also ein Double Fault? Nichtmal die 2 Instruktionen, die nach dem setzen des Interrupt Enable Flags ausgeführt wurden konnten einen solchen Interrupt auslösen, weil es Sprünge zu sich selbst waren, um die CPU in einer Endlosschleife zu halten.

Kommen wir zurück zum Rattenschwanz: Nachdem ich dann die Interrupt Handler und die Verwaltung der IDT hatte, habe ich noch Routinen zur Verwaltung der GDT implementiert. Es funktionierte immernoch nicht, was allerdings zu erwarten war, da es mehr eine Verzweifelungstat war als ein richtiger Lösungsansatz. Wir sind zu diesem Zeitpunkt bei Tag 3 des Kongresses.
Allerdings war das ja auch nicht das Einzige, was ich da gemacht habe. Gab ja noch Vorträge.

Danach gings ans Debuggen. Ich habe VMware probiert, um zu sehen, was das Ding sagt. Wie erwartet: nichts. Es fehlen einfach die Debuggingmöglichkeiten unter Mac OS mit VMware.
Dann gibts noch Qemu, an den man einen GDB klemmen kann. Gesagt getan. Nach wie vor nichts gefunden.
Als letztes bin ich mit dem integrierten Debugger in Bochs dem Kram zu Leibe gerückt, mit dem man seinen Code auf Assemblerebene Debuggen konnte. Auch hier habe ich wieder nichts gefunden.

Was war das Ende vom Lied? Es gibt einen extra Chip auf x86 Systemem, der externe Interrupts handlet. Früher war das der PIC (Programmable Interrupt Controller) und heute ist es der APIC (Advanced Programmable Interrupt Controller), der auch Mehrprozessorsysteme ohne Gefrickel unterstützt.
Diese Chips kann man so konfigurieren, dass jeder externe Interrupt (Tastatur, Floppy, Timer etc) auf einen der 256 Interrupts der CPU gemappt werden kann.

Irgendein Stück Software vor meinem Kernel hat genau das anscheinend mit dem Timerinterrupt gemacht und ihn auf Interrupt #8 gelegt.
Das würde dann auch erklären, warum bei einem Double Fault eigentlich ein Errorcode auf den Stack gepusht werden sollte, was bei mir aber nie passiert ist. Es war schlicht und ergreifend kein Double Fault.

Also hab ich dann doch, entgegen meiner vorherigen “Brauchste eh nich”-Meinung, auch noch Code hinzugefügt, der den PIC (eigentlich sind es 2 PICs) entsprechend konfiguriert und die 16 Interrupts, die er verwalten kann, hinter die Exceptions mappt.

Was ist? Es funktioniert endlich.

Und so kann man sich wunderschön auf die Fresse legen und Zeit verbraten.
Ich will nicht sagen ich hab nichts gelernt, genervt hat es aber doch schon ziemlich. Gedauert hat der ganze Prozess jetzt 6 Tage. Und ich hab immernoch keinen virtualisierten Code laufen.

Feel free to Flattr this post at flattr.com, if you like it.

Seit seiner Einmottung verstaubte dieses schöne Stück Computergeschichte auf unserem Dachboden und ich habe dieses Gerät nie vorher angefasst… Bis letztes Wochenende.

Ich hole das Teil also vom Speicher, schließe den UHF-Konverter an den Antennenausgang meines Fernsehers und schalte ihn ein. Man hört ein “MIEP” und das Floppy rattert kurz.
Nachdem ich dann versuchte ein lesbares Bild auf meinem Fernseher zu bekommen und es nach 15 Minuten immernoch Schatten warf und krisselig war, sodass man es kaum lesen konnte, gab ich auf und fand mich damit ab. Bunt kam da auch nichts raus Also kein “hochauflösender Grafikmodus”.

Im Laufe des Abends/der Nacht blätterte ich also durch ein, ebenfalls vom Speicher gekramtes, Buch, in dem die Nutzung dieser schönen Maschine beschrieben war und irgendwann hab ich dann auch mal ein kleines Basic Programm auf eine, sogar noch leere, Diskette gespeichert.

Am nächsten Tag habe ich mir dann auch mal ein Chinch-Kabel und einen Scart-Adapter gesucht, um endlich mal ein vernünftiges Bild (hoffentlich auch mit Farbe) zu bekommen. Hinten am Apple fällt nämlich sowieso Composite raus, das man direkt in einen heutigen Fernseher schieben kann. Die UHF-Konverter waren vor 20 Jahren nur nötig, weil kein Fernseher Composite Signale verarbeiten konnte. Das konnten damals halt nur Monitore – und die waren teuer.
Also Flux angeklemmt und man bekam ein extrem cooles und um Welten besseres 40×25 Zeichen großes Bild zu Gesicht. Die Color-Demos auf der Apple DOS 3.3 Master Disk blieben allerdings schwarz/weiß:

Weil ich weitere Informationen über den Computer gesucht habe, bin ich auch über die Software ADTPro gestolpert. Mit ihr ist es Möglich Diskettenimages, die man auch im Netz findet, per Audio-Interface des Apples, an den man normalerweile einen Kasettenrekorder anschließt, zu übertragen und auch auf eine reale Diskette zu schreiben. Getestet habe ich das mangels Klinkenkabel noch nicht. Die Videos sehen aber sehr vielversprechend aus.

Genauso fand ich das FAQ der Usenetgruppe comp.sys.apple2, um überhaupt erstmal rauszufinden, was das denn nun genau für ein Apple 2 war, da es einige verschiedene gab: Apple II, Apple II+, Apple IIe(uro), Apple IIe(uro)+ etc.
Was hier vor mir stand war also dann ein Nachbau eines Apple IIe oder IIe+, mit Apple II+-Tastatur und Apple IIe+ Roms.
Wieso? Der Apple hat seit II+ hat einen sogenannten Autostart-Monitor, der einen nach dem Einschalten nicht direkt auf den Monitor-Prompt wirft, sondern, falls eine Floppy- oder SCSI-Karte installiert ist wird versucht ein DOS zu laden.
Zusätzlich muss man, damit der “Reset”-Knopf auf der Tastatur seine Wirkung zeigt gleichzeitig Control drücken. Der Apple II (ohne +) hatte das noch nicht.
Laut Originalrechnung ist das aber kein richtiger Apple IIe+ von Apple, sondern ein MEWA II, den ich im Netz nur auf einer Webseite mit der Bezeichnung MEWA-48 gefunden habe.

Später habe ich dann das Buch “Understanding the Apple 2″ gefunden. Sehr interessant. Der komplette Computer ist erklärt. Jedes einzelne Teil vom Taktgenerator bis hin zur Adressdekodierung am Bus. Das schöne ist, dass man bei diesen alten Computern wirklich noch alles nachvollziehen kann. Keine hochwissenschaftlichen, mit Marketing-Buzzwords gespickten und bis unter die Zähne patentierte Bussysteme oder generische Chips, über die es keine Information gibt.

Das Problem an diesem Gerät ist nur, dass es wahrscheinlich ein IIe+ ist. Steve Wozniak hat damals, um das Composite Signal PAL-Kompatibel zu bekommen einiges am Videogenerator ändern müssen. Leider fiel diesen Änderungen auch der Farbmodus zum Opfer. Es gibt PAL-Karten, die man einstecken kann, um Farbe als PAL-Signal zu bekommen, nach denen ich aber bisher nicht gesucht habe.
Ich bin mir da nicht sicher, weil ich nicht wirklich weiß, was da jetzt für ein Signal rauskommt. NTSC kann dieser kleine Billigfernseher aber höchstwahrscheinlich nicht anzeigen. Ich geh also mal von einem IIe+ aus, der PAL rauswirft.

Was ich mir noch für Extension Karten besorgen möchte sind die PAL-Karte und eine Serial-Karte für eine serielle Schnittstelle. PAL-Karte für ein buntes Bild und Serial kann man immer brauchen, wenn man mit der “mordernen Welt” einigermaßen kommunizieren möchte.

Auf jeden Fall macht das Teil Spaß!

Update: Es ist doch kein IIe. Wie ich grade im Buch “Understanding the Apple IIe” gelesen habe, besitzt der einen “Auxiliary Slot”. Den hat mein Apple definitiv nicht. Das heißt entweder spuckt der wirklich NTSC aus oder es ist ein II+ mit angepasstem Videosignalgenerator. Die Möglichkeit besteht, weil das ja swieso ein Klon ist, den man ja dann entsprechend anpassen könnte.

Feel free to Flattr this post at flattr.com, if you like it.

Die alte Rails Webseite ist nie wirklich fertig geworden. Mit Rails selber konnte ich mich auch nie so wirklich anfreunden. Und die Lust zum Webdevelopment fehlte auch gänzlich.

Also schnell ein WordPress Template umgehackt und hier ist es. Sieht doch ganz gut aus.
Jetzt fehlt wie immer der Content.

Feel free to Flattr this post at flattr.com, if you like it.

Also… Es geht um KiCAD. KiCAD ist eine Suite, mit der man Schaltpläne und Platinen Zeichnen und Layouten kann. Von irgendsonem Franzosen an irgendsonem “Laboratoire des bla….” entwickelt. Im Prinzip wie EAGLE, nur mit dem kleinen aber feinen Unterschied, dass es komplett Open Source ist.

Die Bedienung ist etwas gewöhnungsbedürftig, aber verdammt schnell, wenn mans drauf hat. Es gibt einige verbesserungswürdige Punkte, aber die gibts immer. Mit einigen Buchstaben auf der Tastatur hat man sofort ein Bauteil unter Kontrolle. Nichtmal klicken muss man. Maus drüber, “m” drücken und Bauteil verschieben. Einmal klicken oder nochmal “m” drücken und fertig. Dasselbe gilt für “r” beim rotieren, “w” beim Wire verlegen usw.

Erste Ergebnisse nach 2 bis 3 Stunden Arbeit sieht man hier:

Eine geniale Anlaufstelle ist das Wiki mit seinem Schnelleinsteiger-Howto. Für Umsteiger von EAGLE gibts hier noch eine Sammlung konvertierter Libraries. Eigene EAGLE Libraries kann man wohl auch relativ easy importieren. Weiteres gibts hier im FAQ. Das ganze habe ich bisher aber noch nicht getestet.

Nachtrag: Die ULPs für EAGLE gibts alle hier: Sourceforge

Feel free to Flattr this post at flattr.com, if you like it.