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.
Make sure to try AmiDevCpp for cross-compiling - it's so EASY to install & use, it is ridiculous. (There is a brief learning curve finding where things are in the GUI, but then that's basically it.)
ReplyDeleteThanks for the tip, I will check out.
ReplyDeleteKeep up the good work Almos, we really need JIT for EUAE!
ReplyDeleteNote that with AMIGFX, AGA will only work on 16bit (or above) screens (perhaps a bug you could fix?) and then only if you have the cybergraphics developer files in your SDK.
ReplyDeleteFigured i'd tell you about this now before you end up spending another hour or more figuring out why something isn't working.
In my build on OS4Depot, I just used -lamiga to get past any errors at the linking stage, along with -D__USE_INLINE__ which was also required. I don't know which method is better, using DOS Delay() or libamiga (I know the latter uses a bit more memory).
@MickJT
ReplyDeleteAh, the use-inline, this is what I had forgotten about! I already added once before, just deleted the files and started from scratch.
IDOS->Delay() only allows delays that are multiples of 1/50 s. If you need better accuracy than this you need to use another method. Some alternatives are:
ReplyDelete1) Using timer.device directly (UNIT_MICROHZ)
2) TimeDelay() from libamiga.a
3) usleep() clib function
Note that the TimeDelay() function opens and closes timer.device every time it is called so it has some extra overhead compared to opening/closing timer.device only once on startup/exit and then reusing the iorequest in your code.
On OS4 there is one more additional possibility: using Timer.device/MicroDelay(), but that is busy waiting, so probably only useful for device drivers.
ReplyDeleteThe best solution would be using timer.device, but I haven't checked what environment this function is called.
Any updates?
ReplyDeleteSoon.
ReplyDelete