A.D.A. Amiga Demoscene Archive

Hi - I've been spitting through the available topics and even though I'm admittedly bad at searching stuff I couldn't really find the information I need.

I'd like to set up an UAE/MSVC-based environment. A C compiler (VBCC?) and an assembler compiler (?) hooked into MSVC seems easy enough as soon as I get the right ones. If I then would make an UAE config. (I know how to set it up right for 060 et cetera) with a virtual HD that points to the directory on my PC where I put my build products (executable + content files) and boot it with the KS 3.1 ROM, would that work?

I'll get my hands on the actual machine a bit later I guess.

Hope some of you have some quick useful pointers for me.

thnx,
- Niels

(oh and btw -- lots of nice topics about the HW already here, useful!)

Niels, thats a good plan and it will work. I would recommend having a booting system on a HDF and integrating the toolchain from a shared WinUAE/Windows directory which is backed up by SVN or the like.

VBCC comes paired with VASM and VLINK. Those three programs, together with GNU make, are basically all you need to get your sources compiled for the Amiga. Make sure to use assembly for time-critical stuff like c2p or texture mappers once things start to appear on screen. VBCC allows you to define inlineable assembly functions, so the compiler can try inlining your hand-written code in the optimization stage.

For Prototype 1 we have additionally used Devpac in the makefile for certain sources, but there was no real need for it and it complicated and prolongued the build process significantly in the end. To put it straight: Devpac is the best assembler on Amiga, but using it meant that we had to assemble on Amiga! Next time we would cross assemble using VASM to get much quicker turn around times. If you decided to use VBCC/VASM/VLINK I would recommend using Frank Wille's official version. You might have a quicker start with Hitchhikr's distro, and it is surely worth a look, but in the end Frank is the guy who does all the heavy lifting anyway, and using his distro might secure you his support when you need it.

Finally, try to debug under Windows. The above toolchain doesn't really lean towards debugging and MSVC is a great tool.

Thanks a lot - I'm going to try and set that up! I'll post about my progress or any troubles I might run into.


Can you please elaborate on this a bit more?

What I meant was that I have a fully self-contained harddiskfile (HDF) to boot from as one device (say dh0:), and another device (say dh1:) created from the directory that is shared with the PC. In my case the HDF was just a copy of my A4000 boot partition. Thinking about it again, you might probably just as well boot WinUAE from a shared directory, but I have actually never tried this.

I think that Focus Design will also walk the c path in the future. The timecritical stuff written in asm and the other stuff written in c.

@noname: percentage wise, how much from your last demo is C and how much is asm?

50:50

@Corial: I wish I had done it that way in the DOS days (that's where I hail from) instead of programming lots and lots of ubiquitous logic in assembly; would've saved me a lot of time or at least yielded better results. Can't imagine this being much different on the Ami, except if the compiler is *so* horrible... But I guess not.

But firstly let's find some time to set it all up :)

This VBCC thing has passed me by it seems. Seems neat. Although I cant see the big point of cross-compiling of you do OS3+ stuff. WinUAE is fast enough. Unless you could cross-compile with a modern variant of GCC. Anyone investigated the option? That might improve the code significantly. Unless VBCC has some good 68060 knowledge/tricks that the behemoth cant beat.

Anyone have thoughts on debugging? Back in the day, my code used to have a special mode and I could use AsmOne's debugger. With C/Asm mix its not that easy, though. SASC has the cpr tool but with demo-systems its somewhat unpractical. I tried and failed to use the UAE debugger on occasion. Its too difficult to use and I havent had patience enough to find proper documentation for it.

I suppose spending a little time coding a test/debug mode and/or having some kind of custom accumulative debug buffer controlled some neat macros or something. Well.. with system friendly startup and main
flow-control is done from C one might be able to printf the bugs away.

Sorry for "kicking" the topic but it's been a while and due to some circumstances I haven't gotten around to setting things up. But I still kinda want to :)


This meaning that one would defer the actual compilation/linkage to the Ami (or in this case emulator) itself? Would make some sense I guess as long as the project's complexity is contained. Which might be a bit of a given considering the specs of the whole thing.

I'm also interested about the debugging issue you bring up. I can debug manually like in the old days but I guess we all know a reasonably functional debugger can all save us a lot of time every now and then.

Also, as said in another topic, thanks to Kusma for his crossdev. tools package.

(and by project's complexity I of course mean the runtime.. dataconversion/tools will be done on PC "obviously" :) )