Development Tools

[mcgeezer]

I've long been an advocate of using Devpac for Amiga development.

However the short stint I had working for a developer decades ago had me writing 6502 code on an Atari ST which I was then able to compile and pump down a serial cable from the ST to a C64. the C64 had some sort of memory resident boot strap that just waited for code to come from the ST and it would magically execute it.

Obviously the nice thing about it was that the dev environment wasn't running on the C64 so it wouldn't matter memory got trashed.

Although I love Devpac, it does have it's limitations as an IDE and after my current project I'd like to move onto something a bit better.

Does the Amiga have anything similar, perhaps something virtual that can be used between WinUAE and Windows / Notepad++ etc.

I'm sure this must be a common thing but I'm really out of touch on this sort of stuff so would like to get up to speed.

Any help is really appreciated.

Thanks,
Graeme

[DanScott]

Try our WinUAE demo tool-chain:

http://www.pouet.net/prod.php?which=65625

[kamelito]

You Beat me I was in a tunnel

[phx]

Originally Posted by DanScott

Try our WinUAE demo tool-chain:

As it is based on vbcc/vasm I should mention that they improved a lot since 2015...

To answer the original question: It's really not difficult to set up a cross assembler like vasm (which is nearly 100% Devpac compatible) to compile on any host OS you want. Just let the assembler write its output into a directory mounted by UAE as an Amiga-disk.

My cross development environment includes some portable tools in C for graphic- (bmp to raw), sample- (wav to raw), map- (TilEd tmx to game-internal) conversion, and a Makefile which directly creates a working ADF to test in UAE.

[clenched]

This post outlines a way to use VASM to talk to various emulators. Here is a little 7 sec. video (wmv) using similar method with WinUAE. This example starts itself. WinUAE window never gets focus to load, type or anything else.

What was changed:

;  Section Cube2,code_c ; original
    org    $40000       ; change to absolute code
start

... rest of code

    org    $64          ; divert this interrupt
    dc.l   start        ; don't care about returning

[ross]

Originally Posted by phx

My cross development environment includes some portable tools in C for graphic- (bmp to raw),

Hi phx, which ones do you use?

[Tigerskunk]

I use VASM (which is maintened by our PHX here in this forum and thread ) which assembles into a file that is in a folder that I configured as an HD in UAE.

So I just have an A500 running in UAE with this HD, edit and assemble my asm code in Mac OS X (should be the same in Windows), and test it in UAE immediately..

If the Amiga crashes, I just reload a state just before pressing "Return" in the shell I opened up in the Amiga environment with the name of my program already entered in there.

Works like a charm, and is super fast.

[phx]

Originally Posted by ross

Hi phx, which ones do you use?

I'm not sure what you mean. The cross development environment is usually a good shell (so Windows is no option for me) and a Makefile.

I wrote all the conversion tools myself (some are included in the public Solid Gold source release), so they are really portable ISO-C99 and don't depend on lots of other bloated, mostly useless, libs. All tools, game graphics/sounds/sources and the resulting ADF are built with a single "make" on any host OS.

[ross]

Originally Posted by phx

I'm not sure what you mean. The cross development environment is usually a good shell (so Windows is no option for me) and a Makefile.

I wrote all the conversion tools myself (some are included in the public Solid Gold source release), so they are really portable ISO-C99 and don't depend on lots of other bloated, mostly useless, libs. All tools, game graphics/sounds/sources and the resulting ADF are built with a single "make" on any host OS.

Sorry, I asked a too concise question (I was interested in the bmp/image->raw conversion).
You have satisfied my request, I'll dig into Solid Gold sources.
Thanks.

[Toni Wilen]

Originally Posted by phx

I'm not sure what you mean. The cross development environment is usually a good shell (so Windows is no option for me) and a Makefile.

WSL (Windows subsystem for Linux) works really nicely for this purpose. I have been using it to compile pfs3aio.

[ross]

Originally Posted by Toni Wilen

WSL (Windows subsystem for Linux) works really nicely for this purpose. I have been using it to compile pfs3aio.

Interesting, i'll take a look.

I usually use cygwin or code::blocks/mingw on windows (only support tools and not direct Amiga dev, but i've a cross gcc working system..).

EDIT: well, actually only asm on Amiga, is much more fun (and for some strange masochistic reason I also use devpac most of the time )

[Leffmann]

I use vbcc, vasm, vlink and a good editor, Atom or Sublime Text usually.

I build the program with a makefile and a single key-press in the editor (usually no need for Bash or other shells) then swipe to the other desktop where the emulator is set up to run the program automatically. If I need some little tool I usually write it in Python.

Easy to set up, and very comfortable.

[WayneK]

Originally Posted by ross

Sorry, I asked a too concise question (I was interested in the bmp/image->raw conversion).
You have satisfied my request, I'll dig into Solid Gold sources.
Thanks.

I have used "KingCon" from the WinUAEDemoToolchain Dan linked earlier - very configurable and seemed to produce valid data for most uses I had (although I remember having a problem with sprites once, but that was possibly user error!).

However like you, I'm a masochist and 99% of the time use "IFF Converter" under emulation, and code/assemble in Asm-One :P

[Tigerskunk]

if you use bmptoraw, this is a typical command line for a masked asset in mac os x....

./tools/bmptoraw innviya/graphics/assets/src/walkerbomb.bmp 192 32 3 MASK >innviya/graphics/assets/walkerbomb.bin

This is 192 pixels wide, 32 high, and uses 3 bitplanes (8 colors), plus is masked.
You can find the mask-bob starting at byte (192/8)*32*3 ..

If you want to create a sprite from a bmp
./tools/bmptoraw innviya/graphics/assets/src/fancySpaceShip.bmp 16 32 2 SPRITE >innviya/graphics/assets/fancySpaceShip1.bin

->attached<-:
./tools/bmptoraw innviya/graphics/assets/src/fancySpaceShip.bmp 16 32 4 SPRITE innviya/graphics/assets/fancySpaceShip1.bin innviya/graphics/assets/fancySpaceShip2.bin

..would do the trick.. Please notice there is no ">" when creating attached sprites..

[emiespo]

Hi all, just stumbled upon this thread. I would really like to move on (ie complete) with a game I am porting. I wonder what you people use under OSX for:

1) editing 68k asm code. I've found Atom has some basic support, but something with autocompletion would be much better.
2) debugging the executables. FS-UAE has a pretty decent debugger, but I couldn't manage to keep debug info in the executables. This would make debugging waaay simpler (and faster) than what I'm doing now (breakpoint on weird memory locations accesses).

Any info / help would be greatly appreciated, thank you!

[prb28]

You can try Visual Studio Code with this extension.
It's available for Windows, osx and linux.
You can:

1. Write the code in an modern ide (with hardware documentation)
2. Build with VASM and VLINK
3. Run / debug in fs-uae
4. Build an ADF disk to try on your old amiga
5. and more ...

[Hewitson]

Originally Posted by emiespo

1) editing 68k asm code. I've found Atom has some basic support, but something with autocompletion would be much better.

Nothing beats vim!

[zero]

I wonder if you could use the serial/parallel bootloader system with WinUAE. Instead of restarting WinUAE or having to boot from a virtual floppy every time, just have a ROM based loader and send the binary over a virtual serial port from the host. Might be a bit faster.

[Leffmann]

Originally Posted by zero

I wonder if you could use the serial/parallel bootloader system with WinUAE. Instead of restarting WinUAE or having to boot from a virtual floppy every time, just have a ROM based loader and send the binary over a virtual serial port from the host. Might be a bit faster.

If you want something really fast then look at Clenched's method further up in the thread.

If you want something simpler to set up, but not quite as fast, then build to a directory-based drive, and use a small script on the emulator side to poll and run the incoming program.

No need to restart the emulator between each run.