New on developing for the Amiga, too

[tverrbjelke]

cheers to dlsa, similar story slightly different goal.

My side quest ist to re-unite with the old coding skills that I once had and be able to compile old and new sourcecode (C asm maybe C++)

I was thinking that it could be fun to start by tinkering around and have toolchain and code that would compile/run:

• in emulation (host is linux, hence: FS-UAE): I gladly managed to setup harddrive installations
  • A2000 ocs WB1.3 with SAS C 6.50 - no patches
  • A2000 ocs with SAS C 5.10 and AsmOne1.20 for KS1.2/1.3
  • A1200 WB3.1 with SAS C 6.58+ scy2kpatch

• cross-code: I already managed to setup vbcc + vasm alas with the NDK3.9 - and a working amiga.lib (which version I dunno)

• Final fantasy is get my code also compiling / running on a (hopefully then my own) real amiga A2000/A1200/A3000/A4000 (I still have my old SAS/C Compiler suite in there on my shelf, not sure if the disks are OK...)

All with classic original workbenches.
Maybe I start with "sytem-conform" Intuition Programms that have a screen / Window with some basic menu and there start some simple examples and demos and land safely back to the Workbench when quit.

For a start: I find it difficult to try to have a linux Makefile for vbcc, and keep that in sync with the .uaem / icon / SMakefile for SAS C inside AmigaOS. I am feeling like reinventing everything from scratch - a very inefficient brute force manner like "inject_to_emulation" or "extract_sources_form_emulation" makefile targets that copy stuff from/to shared folders of the project.

I really would be able to have ONE sourcecode basis that would build inside and outside emulation. But even any inlining / linking of some assembly code for the demos seem very non-compatible over the different tools.


Since I am starting, feeling very clumsy, I hope for some simple 1st step hints so I can skill me up on the road.



I feel like in need of best practices or howtos. Help!
(Alone the old C-Style "all declararions first" vs modern C-Style, not even entered any C++ and assembly thoughts).

[phx]

Originally Posted by tverrbjelke

I really would be able to have ONE sourcecode basis that would build inside and outside emulation

Usually UAE has the option to emulate a hard drive on any directory of your host system. You can use that for development from both sides.

I'm not sure if smakefiles are compatible enough to standard makefiles, but you can probably also call SAS/C from a standard makefile. Then do a small main-makefile, which defines CC, COPTS, AS, LD, etc. for your development environment and use these variables in a common sub-makefile (which can be included). Although your makefiles shouldn't be very large, when using patterns like

%.o: %.c

, so you could also do it without.

But even any inlining / linking of some assembly code for the demos seem very non-compatible over the different tools.

SAS/C and vbcc are quite compatible. They can use the same object files and libraries, and even the linkers have common linker-symbols.

Assembler inlines and register arguments are different though. I would recommend to have a look at http://aminet.net/dev/c/SDI_headers.lha which defines macros for compiler-independent register arguments, varargs, hooks, etc.

For calling OS-functions always include

<proto/xyz.h>

, which makes sure you are using the best compiler-specific pragmas or inlines.

(Alone the old C-Style "all declararions first" vs modern C-Style, not even entered any C++ and assembly thoughts).

SAS/C is C90, so you should also avoid C99 syntax and functions. And SAS/C doesn't support 64-bit arithmetics (long long).

[tverrbjelke]

This is from my project header file:

/* Kickstart 1.2 */
 #define EXEC_LIBRARY_MIN_VERSION (33L)
#define GFX__LIBRARY_MIN_VERSION (33L)
#define INTUITION_LIBRARY_MIN_VERSION (33L)

 /* Idea is to have ONE global thing to hold all Data
   - is this stupid? 
 
    And: is xxx_ptr naming convention also dumb? 

*/
 typedef struct _demo_data
{
  struct GfxBase        *gfx_ptr;
  struct IntuitionBase  *intuition_ptr;
  struct RastPort       *rast_port_ptr;
  struct NewScreen      *new_screen_ptr;
  struct Screen         *screen_ptr;
} demo_data_t;

/* I think about holding this (singleton) data 

   inside a function, accessible with get-function
   instead of global static extern... 

    also stupid with Amiga SAS C compiller? 

*/

demo_data_t *get_data();
demo_data_t *init_all(demo_data_t *data);
void close_all(demo_data_t* data);

Here is the main .c conntent:

/* Amiga system libs and headers from NDK3.9 
   
So I shall prefer to use proto/xyz than exec/xyz ?
 So this is OK? 

*/
 #include <exec/types.h>
#include <proto/exec.h> // OpenLibrary CloseLibrary
#include <intuition/screens.h>  // NewScreen Screen

/* Project stuff */
#include "constants.h"

static demo_data_t data;
data.gfx_ptr = (struct GfxBase *) OpenLibrary("graphics.library", GFX__LIBRARY_MIN_VERSION);
if (data.gfx_ptr == 0)
{ close_all(&data); return NULL; }

 /* this does *not* compile with vbcc on my linux:

   - WHY NOT? 
 
if (data.gfx_ptr = (struct GfxBase *) OpenLibrary("graphics.library",0) == 0)
{ close_all(&data); return NULL; }
*/

Please comment and help improve me...!

[phx]

Originally Posted by tverrbjelke

/* Idea is to have ONE global thing to hold all Data
- is this stupid?

Not at all.

And: is xxx_ptr naming convention also dumb?

You can name them whatever you like, if it helps you.

inside a function, accessible with get-function
instead of global static extern...

also stupid with Amiga SAS C compiller?

No.

So I shall prefer to use proto/xyz than exec/xyz ?

No. You should prefer proto/ instead of a compiler specific pragma/ or inline/. It's also better than clib/, which is very compatible, but requires stub routines from amiga.lib for OS calls.
You will still need exec/xyz for specific Exec structures and definitions.

  /* this does *not* compile with vbcc on my linux:

   - WHY NOT? 
 
 if (data.gfx_ptr = (struct GfxBase *) OpenLibrary("graphics.library",0) == 0)

Look at the error message:

invalid types for assignment

. The

==

is handled before the assignment, so you will assign the boolean (int type) 0 or 1 to your gfx_ptr pointer. vbcc always warns when assigning integers to pointers and vice versa, which points you to a bug here. You need parentheses around the assignment to make it work as intended:

if ((data.gfx_ptr = (struct GfxBase *) OpenLibrary("graphics.library",0)) == 0)

[tverrbjelke]

That was helpful! Thx! I now know, that the library structure pointers HAVE to be global (GfxBase, IntuitionBase etc...) so the calls actually can work. I would prefer to not use auto.linb and do init and cleanup stuff myself.

Here is a question to logging in C:
(using vbcc + amiga KS1.3 target, SASC compatibility as final goal)
I am still into the dumb style of tracing my guru meditaions down like:

#define LOG_STRING(text) ( printf("file=%s:line=%u:%s\n",__FILE__, __LINE__, (text)) )
LOG_STRING("init_all() has nonnull data pointer");
printf("data=%lx", data"(unsigend long) data);

realizing that maybe it is time to skill this part of coding up... I am sure a lot of fancy things are shipping around (fs-.uae-debugger, logging to host via serial/tcp, entering guest amiga and debug within SASC ...) but for now I want to try to print more useful (cointaining more data content, being able to switch it on/off per module) logging to my amiga console window and see stuff.

Are there best practices for logging in C inside amiga? I remember that I was once able to print all this and more stuff neatly using some simple self written logger functions&macros but I don't remember... and I am sure there are best practices for this ...?

only found http://eab.abime.net/showthread.php?t=80894 and http://eab.abime.net/showthread.php?t=82362 so faar (and the complexity is for ... later endeavors)

[nogginthenog]

kprintf() will log output to the serial port. You can use a tool like Sashimi to display this in a window (no good if you visit the Guru!).

kprintf is in debug.lib.

Edit: I see your link already points to kprintf().
From C it's as easy as calling kprint("hello") and linking with debug.lib.