For quite a long time I have a Vampire V2 in my Amiga600, to be honest I never was really satisfied with it. The main purpose was to give RTG to a transportable Amiga and this was back in the days the only reasonable option (besides the BVision card for A1200 with PPC which is way too seldom and expensive). But sadly the Vampire V2 never worked really well, regularly it crashed even after a complete overhaul of the fitting and grounding and so on. Sometimes it wont boot sometimes it will just crash after some minutes. I often let my Amigas play mods with Delitracker, and if that specific Amiga is not able to do that for 2 hours straight (even better whole day of course) without crashing it’s just useless to me. My A1200 with Blizzard 1260/1230 and now TF1260 is perfectly able to do that all day long. My Draco is a bit difficult in that matter. Sometimes it runs a whole day without problems other times it crashes 2 times in a row in an hour. (I guess some AHI problems, because there are also other sound related issues).
But the A600 with the Vampire, that was a complete different story, it never managed to do a half hour Delitracker playing without crashing. After the card and Amiga600 was completely redone, better grounding, some stuff on the Vampire exchanged (or added?) i had the feeling it became a bit better, but just a bit. Still it never managed to make even 2 hours playtime without crashing. That was the main reason the Amiga600 with the Vampire V2 was never used and finally end up in a pile of stuff in the cellar.
Some weeks before I read some interesting articles about PiStorm and that there is a PiStorm hardware to connect a RaspberryPi to an Amiga600 (PiStorm600). I thought that would be a good chance to revive that poor Amiga600, so I took some garlic, a cross and went to the cellar to rescue the Computer.
Luckily I have a lot RasPis laying around (different Versions), bought them when they were cheap and easy to get 😉 sadly I don’t have a RasPi 3A but I have multiple RasPi 3B which should also work, just the USB port is in the way. I use a short extender cable to place the raspi a bit away from the adapter, therefore the additional USB port does not need to be removed. Until now I did not see and negative effects from the cable.
The software installation was quite easy, and after a little bit try and error I got finally the CF card to boot and to crash…. of course I need to de-vampirize the Workbench on there, which was not that difficult.
I bit difficult was the installation of RTG for some reason it did not work the first time I tried only got a nasty crash directly on bootup. Some days later I tried it again and this time it worked. I’m not sure what I did different but now it works. And this is the really good part. PiStorm shows the RTG screen on the HDMI output of the RasPi so you have a VERY clear and stable picture with for example 720p, (something I was never able to setup for the Vampire to work reliably)
It emulates a 68030 and 68881 in the RasPi. It’s not lighting fast or so, it’s around double speed of an 68030/50Mhz I would guess but the RTG is rather fast, so it feels much faster. But the usual Suspects work, so FreePascal and many of my programs, even MUIMapparium the FPU version works nicely.
Network seems to work, but it is rather slow, my PCMCIA card is much faster, but this is also described as still in development, so no surprises there.
Sound AHI via the HDMI from the Raspi, I never got to work, it seems it plays but I do not hear anything, maybe it’s still going to the headphone jack, I did not try. But this AHI is also not very important to me, for me the Amiga Chinch out is enough to play MODs.
And YES I tried it, let play Delitracker several hours random mods from the HD and it worked flawlessly not a single crash, very nice.
Of course it’s not all nice and shine, of course the Bootup needs rather long (around 30 s, it needs to Bootup the RasPi first) and for shutdown, you should shutdown the RasPi first before turning off the Amiga to prevent the sd-card in the Raspi to corrupt.
Also it seems at the moment it has some problems with the ROM mapping, if I use that Kickstart ROM and not the internal ROM, it has big problems rebooting the Amiga, usually it’s easier to shutdown everything and start fresh. Also the Bootmenu is somehow broken and mostly crash. All that do not happen if I use the internal hardware ROM.
At the moment the RasPi inside the Amiga case becomes rather hot and starts to clock down so I will need to a add a heat sink of some sort, but there should be enough space and I should think about additional power to the Raspi because it complains about undervoltage which also causes clocking down of the speed.
But overall not too bad and a good idea to emulate the 68k on the Raspi. I’m rather satisfied.
I got some request for AmiTube for AROS because with the MPEG feature it is nicely possible to download and view videos in AROS. In AOS4 and MorphOS you can easily just use the m68k Version because of the seamless integration of 68k Emulation. But in AROS this is no possbile, therefore I compiled a special version for i386 AROS ABIv0 and ARM AROS.
Don’t forget to set a MPEG as default and a suitable MPEG player like mplayer, in principle a simple downloader would be enough for AROS (and AOS4, MorphOS for that matter) i386/arm should be fast enough to play the original format, so no conversation is needed at all.
Some might wondering what happened to the Free Pascal test result on the Amiga. There are some reasons I did not write about the results. 1. it took much longer than though, especially later tests need much longer to compile and run (more like 30s per test) and 2. some tests crash what leaded to idling computer half of the night until I can let it continue, overall it stopped 8 time, of which it was 3 times a „Guru“ and 4 times the enforcer (of Draco) killed the program before it could crash the computer because the program accessed some memory it’s not supposed to and once the Hard disk went full and it stopped with a Disk full requester (I did not notice that the logs and programs need such big amount of HD).
Overall 326 tests are failing either do not compile or the compiled program does not work correctly + for mentioned 7 that crash, which is much more than the m68k-linux test for this compiler version which should be around 40 or. I guess that must be some implementations are missing for the Amiga. I saw scrolling by some Link LibC or other c library errors, which will not work because we did not implement that. The rest I have to check slowly the next days.
It’s not bad after all, 333 tests give problems means around 5600 tests ran well without problems and my Draco did run 3 days without interruption without any problem, also nice to know. After checking the errors, maybe I can fix some of them and make a test list without the 7 crashing tests that I can run on one go. I should repeat that test with the latest Free Pascal and compiled for FPU, especially some tests which are not working with the qemu setup I’m using atm. (if they really show an FPU compiler error or just an qemu problem)
Again got a crazy idea… after my attempts to run the Free Pascal test suite on a real m68k linux (I’m not sure whats the problem it it just stopped at some point but did not start the actual tests) I looked a bit closer how these test run is designed (with a bit Makefile, which does not work on Amiga even with unix kind shell installed, I tried already) I wrote a little program make the list of tests and I got around 5800 test, not the same amount as the original (which is nearly 9000) but ok for first list creation, later maybe find out where are the other tests hidden.
the „dotest“ util making the actual test (checking if on the right CPU/OS/Version and so on) does not run because it’s only implemented for windows/dos and unix… and full of {ifdef windows}doDOSstuff{$else}doUNIXstuff{$endif} or vice versa… I made some very nasty changes and implemented a little routine for Amiga to make it at least work to run the tests gather the output and check return code and it works.
Next transfer everything to my Amiga (Draco 68060 in this case) and start and press all thumbs it works somehow.
And? Yeah it works, needs around 10s per test hmmm that makes around 16h for the full 5900 tests :-O ok the Draco is very stable, I just hope none of the test let it crash 😉 lets see tomorrow the result, which tests fail and why 😉 (running currently with 3.2)
If that works well I should also make a run with FPU (thats SoftFPU atm.)
A little bit improvement of the raycaster engine, now with simple texture mapping included. I had to invent some fixed point mathematics to make it fast enough on real m68k Amiga but still it works nicely and just a bit slower. I found a little bug in FreePascal when using functions Trunc() or Frac(), but Charlie thankfully saved the day and made a super quick fix of it.
Again a little video on my Amiga 1200 (68030/50Mhz, 68882/50Mhz, 32 color AGA Screen) and it’s still a single source code file of less than 20kb size (many of them are comments 😉 ). and the executable is less than 100k, not bad especially because I did not optimize for size, just for speed
Again the source to download: raycaster with Texture executable for m68k Amiga and FPU with source code.
By random I came across a funny video on youtube showing the basics behind a simple raycaster like Wolfenstein 3D. I know the mathematics behind it for real rayshading and on a real Amiga it’s awefuly slow. So for me it was interesting which short-cuts they take to make it fast. It’s really not complicated to understand (if you know the mathematics already, if not I guess it stays a black box).
I tried to implement that into a FreePascal program (with some tiny changes (block size smaller for example, because of the smaller screens on Amiga)). It runs rather well, I did not want to code hardware, but use OS functions which make it a bit slow of course (especially the line drawing).
For the actual 3D image s I used RectFill but of course on a non-RTG Amiga thats very slow, therefore I changed that to write chunky pixels to a temp buffer and use WriteChunkyPixels to copy that to screen, already much faster but still not max speed. I found a funny patch (Blazewcp), which patches the WriteChunkyPixels function to be much faster, and voila really nice speed of already 12.5 fps, without turning OS of or Assembler/Hardware stuff, in pure FreePascal.
You want to have it? try it? Sure why not: Download (Source and Exe for m68k Amiga OS3.x 68020+ and FPU needed, but can be compiled and run for all Amiga-likes)
Charlie took some time to review the FreePascal 3.2.0 packages, I created. I changed them according to the suggestions. Some of the hints are not possible at the moment, needs some changes in the code, others are easy to change. He also found a bug in vlink, which got solved and we include now also the latest version of vlink.
The biggest change for the users is, that it now installs into a folder called „FPC“ (instead of FreePascal) also the assign created is named „FPC:“ (instead of „FreePascal“). If you did install the old package and install the new one you can afterwards (after the reboot) delete the old „FreePascal“ drawer.
Yesterday I did exchange all links to the new version already, when updating the arm-AROS version. But here are the links again
Downloads: – Amiga 68k OS3.x+ 68020+ SoftFPU – Amiga OS4 OS4.x PowerPC (X5000 not supported) – AROS ARM RasPi 1-4 ABIv0 – AROS i386 ABIv0 – MorphOS OS 3.x Have fun using them!
With it the archives are now also uploaded to the official FPC server and can be downloaded there as well, that means we finally have an official Amiga, MorphOS, AROS release of FPC. Congratulations and thanks to all people involved.
Finally Version 3.2.0 of FreePascal is released. This is the first final release contains the Amiga style systems fully usable. A while before I did some extra work to also create an Amiga-sytle installer, which will be also released with this. Today I will also release the 3.2.0 FreePascal packages for Amiga 68k, Amiga OS4, AROS for ARM, AROS for i386 and MorphOS. So basically all versions except AROS for x86_64 because that’s still too unstable to use (mainly the AROS 64 bit is still a moving target and I was not able to fix that, because AROS is simply not working after the last changes and my last questions about it got just ignored)
Downloads: – Amiga 68k OS3.x+ 68020+ SoftFPU – Amiga OS4 OS4.x PowerPC (X5000 not supported) – AROS ARM RasPi 1-4 ABIv0 – AROS i386 ABIv0 – MorphOS OS 3.x Have fun using them!
You notice, these files are still hosted on my server and not on the official FreePascal Server, as the last release 3.0 as well. I was told because my previous packages did not meet the standards for official FreePascal packages. Which was true, I did not care about and packed a lot additional stuff into, like fpgui or LCL and I did not know there are readme texts to add which are not in the official repository but in an external one.
For that release 3.2 I did a lot of work on finding out what would be a good Amiga style package and which docs/texts should be added. Therefore I created that installer package I release today. I also asked for a review and put on to the official FreePascal server, as an official Amiga FreePascal package or give me feedback on what I should further changed.
Sadly that did not happen, I did not get any feedback and the release archives are still nowhere to be found on the official servers, therefore missed for that release.
That whole story took away my motivation as well over the last month as well, it seems rather futile to continue to work on it, when nobody even really use it, which is still true, unfortunately, I have to admit.
I uploaded some of my sources to my github account. With it also Leu and MUIMapparium. MUIMapparium is 100% written by me, therefore it is now under CC0 License. Leu contains fpspread and some files from LCL therefore it is modified LGPL as the original. Have fun with the code. 😉
I had some interesting and intense discussions the last days. Mainly about my programs and vampire. As you might know I did not want to have my programs on the highly illegal distribution Coffin. You cannot detect Coffin, but it’s a distribution especially made for Vampire, therefore if I block Vampire they will not include my software anymore. Besides the Vampire users could push the Vampire team to condemn this distribution and stop to promote it. All of that did not happen, they still added my stuff, even with the Vampire block and the people became mad about me, not about the Vampire team (or the coffin team). I’m not good at being the bad guy.
Basically the people tell me that I’m an idiot and an asshole because I blocked Vampire, so I give up. The people always told me that Coffin is not illegal because it contains abandon-ware only. Ok, if that’s the case I transform my programs to exactly that and put them all to github, then it is legal and everything is solved.
Don’t get me wrong, I do not have a grudge with the Vampire team. I always hear that, that I’m mad about them because of the FPU issue, which is not true, maybe disappointed, but not more, I use my Vampire mainly as RTG-GFX card for A600, the only one currently available and the FPU I can turn off and use femu (which still works and is rather good).
Again playing with 3D stuff, realtime raytracing, but this time a little bit stripped that it also can work on a real 68k Amiga, like the Draco, so without mirrors and so on. The new improvement by Charlie in the FreePascal compiler seems to work as it should be and also increase the speed a little bit, so it’s almost fast. Ok its still horrible slow, but hey the first version needed around 10s per frame, now it’s under 2s.
Also tested with AROS and because its the new „hot stuff“ of course on AROS64 and even the image is 4 times bigger it moves smoothly. If you make it the same size as the Amiga68k one, it needs around 8ms per frame but the window is very tiny.
It’s still heavy with floating point calculations so the 68060 is very good to use the 68881 will be much too slow. I also tried the Vampire 68080 which have a much faster but not so precise FPU. Good news it works, bad news it looks broken. I only use Singles everywhere and removed all Round() from the source but still it looks completely wrong, no idea why.
