So I uh.. found this copy of Vistapro 4.0 And I though it would be fun to kick out an animation. At 320×100 this took a whole 8 minutes to render on my laptop.
I though that was cool, but I was mistaken in thinking it was multi-threaded while it rendered. I have access to a machine with 16 processor cores, so I setup a rendering machine, and found out very quickly it was only using one core. I think their final product Vistapro renderer may have used multiple cores although the company that sold it went bankrupt quite some time ago. Anyways I rendered this animation at 1080p and it took about two hours.
For a while this kind of ‘virtual reality’ and desktop rendering of places was quite popular. Although Vistapro originated on the Amiga, but without a numerical coprocessor and fast processor this may have taken weeks or months on a stock 68000. I haven’t tried, and I’m in no hurry to find out.
I didn’t insert any music or audio, so it’s just 48 seconds of the camera going around.
Got to say it’s really cool that it works with hardware 3D acceleration.
I may want to try to do something with it later on, however I’ll need to get it a case.
I have a cold, and yeah sound like crap. I’ll add specs later as I think my fever is kicking back in. Sigh. But yeah basically
P4 board / CPU / RAM $150 HKD
GTX-460 card $180 HKD
Sound Blaster Live! $20 HKD
37GB IDE disk $20 HKD
PS/2 Keyboard $20 HKD
PS/2 Mouse $10 HKD
700 Watt Power Supply $150 HKD
So yeah ~550 HKD or $70 USD. Not bad.
So a little closer look at the hardware. I’m lucky that there is an active used hardware market here in Hong Kong, elsewhere in the world you either have HAM radio events, ‘boot sales’, garage sales, or for the truly desperate, eBay, Yahoo auctions, and AliExpress. My go to place here is of course the Capital Computer Centre, where they at least will test stuff before selling it. I know I’m old fashioned but I like buying in person.
I had originally chosen this board to mess around with Darwin. I wanted something new enough to have a P4, but old enough to still have an older ‘parallel’ EIDE controller port. And the Intel D945GNT, board certainly was up to that task. Like ancient Darwin, AROS works best with either parallel disks, or SATA disks in older parallel emulation. The markings on this board are a little hard to read as the bigger numbers are the product testing/radio compliance numbers, and the model number is a bunch of possible models as I guess they like to make so many variations on a single board.
Here is a close up, and E210882 is *NOT* the mode number. Nothing like confusion.
One of the big reasons for using the Intel board, is that it has an onboard NIC, and Intel of course uses Intel NIC’s so it has the very compatible Intel PRO/100 VE Desktop Adapter.
While you can get these on PCI cards, and use other boards, I figured since I was going to buy a board anyways, and once things get this old the people selling them really don’t care who made the board, but rather that this is an old P4 board, they all sell for the same price.
Another plus about this board is that it is new enough not to have AGP, but rather the new and exciting PCI Express. This board as the Express x16, which of course is perfect for a ‘large’ GPU. AROS has a port of the Gallium3D nouveau driver, making this perfect for a super cheap GTX 460.
I shopped around for a while and I found this accelerator, that although has no apparent labeling at least on the flip side it has the identification. I really don’t know what is the fastest GPU you can get for AROS, but this one seems to work just fine, and it’s what Stephen Jones is using so that is what I went with.
And looking under AROS, this is how the PCI resources show up for the video card.
This was an old card, and it looked like either the OEM didn’t put any stickers on it, or someone had taken them off. Either way I don’t care, and it doesn’t matter as it works just fine. Sure the GTX 1080 is over five times faster, but the open Gallium driver won’t work with it as Nvidia has done their best to break open stuff, and even if it did, you can’t buy a 1080 for less than a pizza. At least not yet.
For some reason, I had begun collecting older and cheap Sound Blaster cards when I see them. I wasn’t going to spend more than $50 HKD ($7 USD) for them, so I don’t have an Audigy cards yet, but I did have this Live card. At the time I didn’t think it was anything special, although the EMU10k chip is desirable, and popular for much older systems.
This card is the CT0100 model. And it works great!
And this is how AROS sees the card
The AROS HCL is a little confusing to me, but it all seems to work. If it weren’t for the Stephen Jones video I wouldn’t have tried as it implies it won’t work.
Yes, I know there are others. Newer versions of GCC too!.. but I was more so curious to see if I could do it. I know there were GCC 1.x ports to the Amiga but I can’t find source anywhere. And for some reason the Amiga and Atari ST seem to have never been mainlined into GCC. I would have thought 1990-1992 they would have had far more users than say SUN-2/SUN-3.
I’ve just tested a hello world type executable. I’m more so amazed that it linked and executed, ‘file’ detects the objects as
x.o: raw G3 data, byte-padded
But at least the executables look right:
hi: AmigaOS loadseg()ble executable/binary
I had to hack all kinds of crap compiling eamiga.c
and eamiga_bss.c as neither generated correctly, and both had all kinds of missing and undefined things. I’m sure on bigger projects it’d just explode, but right now I’m just amazed the linker could pick up my object, plus the 21 year old objects + libraries from that aforementioned ancient GCC port.
To start this fun voyage, I used HCC, the first usable port of Sozobon C to the Amiga I could track down. From it’s description:
Amiga port of Sozobon, Limited’s C Compiler. Can completely compile
itself, supports 32 bit ints, and optimizer can ‘registerize’ variables.
Includes compiler, optimizer, tool for creating interface code for Amiga
system calls, startup code, C library, include files, and library routines
that work with Motorola FFP format. Uses assembler A68k, linker BLink, and
provided run-time shared C library CClib.library.
And isn’t that great? It even supports 32 bit integers! I had to massage things in Visual C++, as there was some weird instances of return codes missing, and the optimizer not actually mallocing it’s memory, but just blindly using pointers. As always if you can see what is going on in a debugger it’s not too hard to make some wild guesses and get it running, and if you get lucky it may even work too…
Running the compiler
With the compiler and optimizer running (it is actually needed to run to further massage the assembly output into something the Amiga a68k assembler can read), it was time to look at an assembler. For the heck of it, I did try a68k, and to my amazement it did actually work, once I had updated the file output call.
hcc\hcc -L hanoi.c
hcc: version 2.0 Copyright (c) 1988,1989,1991 by Sozobon, Limited.
Amiga Version 1.1 by Detlef W³rkner.
top\top -v hanoi.s h2.s
top Version 2.00 Copyright (c) 1988-1991 by Sozobon, Limited.
Amiga Version 1.1 by Detlef W³rkner.
Peephole changes (1): 8
Peephole changes (2): 1
Peephole changes (3): 0
Instructions deleted: 3
Variables registered: 0
Loop rotations : 0
Branch reversals : 0
Branches removed : 4
a68k\a68k -q100 h2.s
68000 Assembler - version 2.61 (January 11, 1990)
Copyright 1985 by Brian R. Anderson
AmigaDOS conversion copyright 1989 by Charlie Gibbs.
PASS 1 line 59
PASS 2 line 59
End of assembly - no errors were found.
Heap usage: -w2047,80
Total hunk sizes: 94 code, 10 data, 0 BSS
wow wasn’t that fun! I haven’t seen the source code to the BLINK linker, so I just end up using a native linker, BLINK.
Much to my amazement, the a68k assembler functions just fine as a cross assembler, and I only had to copy the object file into the emulator, and I could happily link.
The syntax for BLINK was a little strange, mostly because I really don’t know what I’m doing.
BLink LIB:HCC.o+hanoi.o LIB LIB:HCC.lib+LIB:stubs.lib TO hanoi SC SD VERBOSE
Now to try something bigger, like the ancient 1987 vintage InfoTaskForce. I had to add in the include files from the DICE compiler, and surprisingly, in no time, it was all compiled, and assembled the only step remaining was to run the BLINK linker. This time it was slightly different as now we had a bunch of object files:
BLink LIB:HCC.o+fileo.o+funcso.o+infocomo.o+inito.o+inputo.o+interpo.o+ioo.o+jumpo.o+objecto.o+optionso.o+pageo.o+printo.o+propertyo.o+supporto.o+variableo.o LIB LIB:HCC.lib+LIB:stubs.lib TO infocom SC SD VERBOSE
Running that as a single line (or better in a command file) got me my executable.
And it linked without any unresolved externals.
Running under WinUAE
And even better, it worked. Here it is running Planetfall!
I can’t imagine it being all that useful for anyone, as Sozobon C is K&R C, and well this is for the Commodore Amiga, not exactly a mainstay in this day & age.
HCC_Sozobon_win32cross.7z This link will take you to the sourceforge page, and the archive contains both source, and executables. As mentioned I didn’t see any Amiga linker that has source code, it seems everyone use BLINK, and the team that write BLINK went on to re-write all the ‘c’ commands in AmigaDOS from BCPL/asm into C.
I just discovered vlink after writing this, and now I can link a working executable under Windows 10! Since I made zero changes to vlink, and I’m not charging money, I am free to redistribute this so I’ve updated my archive, and included it.
Behind it all is the Scripted Amiga Emulator. What is more interesting is that there has just been a MASSIVE update/rewrite to the project and it is now boasting far more features!
Looking at the features page, there has been quite a number of updates since the last version. The big ones (to me) is that the CPU core has been rewritten, and now supports not only the 68000, but the 68010, 68020, and 68030 (only with fake MMU). OCS, ECS and now AGA as well! Preset models include the 1000,500,2000,500+,600,3000 and 1200. IDE disk files can even be mounted for the 600 & 1200!
WinUAE 3.3.0 (06.06.2016)
- New optional "indirect" UAE expansion trap system, fully compatible
with OS 4.x, virtual memory and some debugging programs.
- PC Bridgeboard disk drive raw image support. (ipf, ext adf,...)
- Monochrome video out emulation, including A1000 color/mono video
out software control (BPLCON0 COLOR bit).
- Dark palette fix option to correct colors of badly ported Atari ST
games (Midnight Resistance etc..)
- Official CSPPC/BPPC flash updater can be used to install full ROM
image without having existing ROM image file.
- Custom input events can execute Amiga-side commands and scripts.
- Windows clipboard to emulated Amiga keyboard paste support.
- Variable refresh rate optimized vsync mode (G-Sync/FreeSync).
- Black frame injection is supported in variable refresh modes.
- IVS Trumpcard Pro/GrandSlam SCSI emulation.
OS4.x supported UAE expansions:
- Directory harddrives, including on the fly insertion/removal.
- CDFS CD mounting.
- Clipboard sharing.
- uaegfx RTG.
- uaehf.device hardfiles.
- Virtual mouse driver/magic mouse/tablet mode.
Thanks to all who donated.
NOTE: Performance is not (and can't be) as fast as with m68k AmigaOS,
especially with directory harddrives, due to slower, much more
complex UAE to/from native code context switch trap system.
- Game Ports panel input customization is finally very intuitive.
- On the fly input device insertion/removal improvements.
- Many input device handling updates and fixes.
- Faster screenshot/capture in after filtering mode.
- Continuous screenshot mode.
- CD32 Akiko chip low level emulation compatibility improved.
- Nero .nrg CD image support.
- Hardware RTG emulation rendered same frame twice in some situations
causing slow performance.
- Amithlon partition type (0x78/0x30) support works again.
- Some storage devices failed to mount as a harddrive.
- AGA subpixel scrolling glitches.
- Miscellaneous custom chipset emulation fixes.
- AGA mode HAM6 colors were not 100% accurate.
- Some programmed custom chipset display modes crashed.
- Direct3D mode DirectX9 not installed warning corrupted memory.
- Fullscreen + paused + enter GUI: GUI was invisible.
- Display panel gamma value calculation fixed.
- CDFS automount didn't mount CDs with empty label.
The procedural terrain generator uses 1D fractional brownian motion (fBm) with random mid-point displacement. Up to 10 curves are displayed on screen.
When a new curve appears at the horizon, 7 vertices are computed. Then mid-point displacement with fBm are applied to thes 7 initial points. This results in a discrete curve of 512 samples.
The random number generator and the fBm Hurst parameter H are adapted according to the current terrain type (flat, canyon…). This gives very different visual landscapes (plains, moutains, desert…).
No more fractal computation is done on the discrete curve. When a curve is drawn, only 256 of the 512 samples are used (according to the position of the Oorxx).
The view is 256 pixels wide, so if the visible part of the curve is larger than the 256 samples, the curve will be drawn zoomed with pixels linearly interpolated between the samples. Otherwise the curve will be drawn shrinked without any interpolation and using only some of the 256 samples.
The raytraced fractal landscape is computed from these 10 curves.
It’s pretty amazing to think that there was that much behind the game.
I played this back in 1988 on the lowly Commodore 64, but the Amiga version was simply amazing. Such was technology back then.
This one should have been much easier to build, it has support for SDL built in, however the include files are a nested mess, and configure fails part of the way in the process leaving the source kinda messy. But a few hours over a couple of days, and here we are.
This version doesn’t run at warp speed, has sound, and is great. It wants a config file though. You can find the specs in the readme, but something like this:
works fine. This later (and seemingly last) branch of UAE incorporates lots from WinUAE, except for the JIT. It’s dated 2008, so it does include support for the 68030, 68040, and the 68881 and 68882. It doesn’t have MMU support, so things like Linux/AMIX/NetBSD/Enforcer are out of the question.
I can’t find any source of the 0.5 versions, and I had issues with 0.6.x but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?). I suppose with this version working I can go back and take a stab at resurrecting 0.6.x
What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.
I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta. So now you can actually use the CLI, and change disks. Double clicking is an impossibility as it simply runs far too fast. I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.
I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast. UAE is from an era where a 100Mhz computer was a luxury item. Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.