This project is dedicated to the memory of William Morris (aka Frags), who was the main contributor to the bounty but was unable to see the final result.

Monday, May 2, 2011

Is it alive, Igor?

While I had my expectations for setting up the cross-compiling environment, I failed to fulfill my own agenda: it just doesn't want to work. I have tried to set up a Cygwin environment, but the configuration script behaves odd and fooling around a few hours I lost the battle. Not a big issue yet, since I wasn't able to set up net connection on the Amiga anyway and transferring files on a flash drive isn't exactly comfortable.

So, instead of wasting more time on that, I rather started to create the test environment for the JIT.
To limit the scope of the must-be-implemented instructions, I figured out that I can prepare a spoofed Kickstart ROM file that contains exactly what I want to test at the moment. After a while I found my age old Mandelbrot test that fancies only Motorola 68000 instructions and prepared in sufficiently hardware-banging fashion - best candidate.
The development environment for the test code: PhxAss for compiling, vlink (from the ominous VBCC package) for linking.

You might ask why vlink was necessary when PhxAss is able to do the linking. The answer lies in the Kickstart ROM file format: it is a plain raw binary dump, that starts from $FFF80000 in memory. This format can be manufactured by a number of ways, but PhxAss is not exactly prepared for it.
I have never tried to create a raw binary from a relocate-able Amiga executable before, so I had to tinker with the linker script first a little while, but finally managed it.
E-UAE has some restrictions on the size of the ROM file, it must match one of the legitimate sizes from the real hardware: either 256 or 512 KB sized. (There are other special sizes for Amiga 1000, or the CD-32, but generally these wouldn't help much.)

Finally, the ROM file was ready. I knew that it gets loaded to that high memory address ($FFF80000), and I slightly remember that it gets overlaid to the CHIP RAM (to the zero address of the memory address space, actually) with a hardware trickery right after reset.
The reason is quite simple: the Motorola processor takes the first two longwords from the memory for the initial program counter (PC) and the supervisor stack pointer (SSP) right after start-up. To put some meaningful data into these addresses either the ROM should start from the beginning of the address space (technically that would be address $00000000), or some hardware magic has to be done. The latter is the case of the Amiga systems. When the ROM started from the real address, the overlay goes away by setting some of the custom registers... But which register exactly? It is not a common code to start-up an Amiga right from clean reset... Luckily, others already done the hard work: check out this link from the section "A Quick explanation of what happens and why".

Everything seemed nice, however I never came around figuring out how to turn on AGA chipset after a plain reset. Until you start the SetPatch command, the system behaves as OCS chipset does, and now I don't even have the SetPatch command since I don't have any part of the system without the actual ROM. Not good, not good!

I have spent a whole day finding out the answer. Well spent time indeed, by the way: I refreshed my memory about Amiga hardware and coding for the legacy machines. The result is included in the sources, in case you are curious. (The "magic" FMODE register.)

You can download this initial test package from here from the SourceForge page of the project, it comes handy if you would like to start writing your own Amiga emulator (haha).
Please note again: you will need the PhxAss and the VBCC package for 68k target if you would like to rebuild. To do the compiling and linking just type: "build mandel_hw" into the command line and here we go. (If you have the compiling tools in your path somewhere, of course.)
Before you are rushing to shovel it into E-UAE: while WinUAE won't bother checking the Kickstart ROM, and you can basically load anything into it, E-UAE is trying to do checksum on the binary image. I was too lazy to create the proper checksum, I rather modified the E-UAE sources to skip the checksums. (Meaning: you won't be able to load the test into the usual E-UAE or derivatives for now.)

I have to add that I don't know exactly who created this Mandelbrot set calculation. It wasn't me, I got the source from a magazine some time ago. I guess the author won't be bothered that I published his/her(?) work again. So, let's say these sources are Public Domain for now.

How to proceed... Well, I still wasn't able to manage to prepare the poor man's JIT compiling. It is not working yet, there are some issues with it. This is coming on the way next.


  1. Just so you know you can get a newer version of vlink from here:

    Also vasm (the vbcc assembler) is written by the same person (Frank Wille) who wrote phxass (it even has a phxass compatibility mode):

  2. whats going on ???. how is the dev at this time,
    hope to see a new report soon...

  3. Unfortunately, there was only a very little development. I have too many things going on in my life recently, but I am trying to make some time for it.
    I promise I will post the news when something useful is ready.

  4. Is it alive, Igor? :)

  5. Have you considered using both PhxAss and the accompanying linker PhxLnk? Or both vlink and the accompanying assembler vasm? The choice of using one from each suite seems odd.