The Big X on the Map

Just a very quick update: things are slowly evolving, so DON'T PANIC.

Some more words about what has happened recently: I had some trouble with my Amiga, turned out as a PSU problem. Luckily it is already fixed with a "new" case for the poor girl.

I am fighting with the rather chaotic E-UAE sources, so I made a few steps to make it easier to edit the whole project: I managed to put together a cross-compiling environment from Windows. *booo-booo*

Compiling is much faster on the muscle x86 processor (*booo-booo*) and there are some advanced tools to do some heavy lifting when it comes to source code editing. I must also admit that since I use source version control at work, I barely can go on without it.

With the help of Cygwin, Eclipse CDT, TortoiseSVN, VisualSVN Server, FileZilla Server and a simple script on the Amiga side I was able to assemble a semi-automatic build and test deployment environment.

Thanks to Zerohero for the detailed cross-compiling setup description.

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.

Rainy Day with Copper-rendered Rainbows

The sky is cloudy, sometimes sudden showers are soaking the insanely green grass and I am forced into the shabby unit we rented half a year ago. Time to move - popping into my mind quite often these days, but that is a completely different matter.

There are only a few things distracting me from working on E-UAE, I tried to concentrate working on it with a great strength. (Apage Satanas: Facebook! I clearly miss the times when I was developing Flamingo. I was sitting in my curtained flat all day, no internet, no phone, no tv: the best environment for creating your own little pet creature and take over the world, MUHAHAH...)

I was trying to compile E-UAE since my last post, but I am clearly not really fond of the multi-platform environment. Configure script is a bad dog: never behaves. (Linux developers must have an insane amount of time and patience.)

Finally, after running into the never-ending circle of deleting all, copy back, adjusting, configuring and do the make for the hundredth time: I was able to compile E-UAE sources, and the binary is even working. YAY! \o/

I am happy that I can start on tinkering with the JIT implementation, but I have to admit that my Amiga developer skills became a bit rusty in the last three years, since I hardly had time to spend on development.

I fought big time with the path of include files, still getting flooded with complaints about missing prototypes for the AOS functions, but at least that is only a warning. (Not that I can live with compile-time warnings for my code, but I really don't have enough strength to find what minor thing needs fine tuning in the compiling to get rid of these warnings safely.)

It took me an hour today to find out that TimeDelay function is part of the (obsolete) libamiga and this is why the linking failed every time. There was an easy fix for that: just remove the check for AOS4 from the sources and let it fall back to the DOS/Delay() function. Not a proper solution, because Delay() is badly inaccurate, but at least I was able to compile and fire it up.

The compiling on the uA1 is awesomely slow and eating up all the memory, so I had to turn on the swapping. I seriously considering the cross-compiling from my windows laptop, and let the A1 do the testing functionality only. It was a very long time since I tried cross-compiling for the OS kernel, back in the days when it was impossible to compile it on AOS4. It was painful, I had to use Cygwin and a number of tricks to get it working. Then copied the compiled binary to my Amiga 4000 on a floppy disk for testing... *Sigh* I was soo patient, I am amazed now. ;)

Speaking of which: I still need net connection for the uA1, that would be essential for the cross-compiling.

Anyway, let's go back to experimenting. The first test will be implementing a very-very simple form of the poor-man's JIT, which will do nothing more than "compiling" the executed code into series of calls to the interpretive instruction implementation functions. The outcome will be an environment, where I still have all the already implemented instructions, but I can replace them one-by-one with the real JIT instructions. Something what I needed when developed Petunia, but there was no interpretive emulator to back up the missing instructions.