English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 12 June 2021, 13:14   #1
tverrbjelke
Registered User

 
Join Date: May 2019
Location: Germany
Posts: 8
New on developing for the Amiga, too

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).
tverrbjelke is offline  
Old 12 June 2021, 14:44   #2
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,030
Quote:
Originally Posted by tverrbjelke View Post
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.

Quote:
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.

Quote:
(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).
phx is offline  
Old 12 June 2021, 15:18   #3
tverrbjelke
Registered User

 
Join Date: May 2019
Location: Germany
Posts: 8
Compatible C best practices...

This is from my project header file:

Code:
/* 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:

Code:
/* 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...!
tverrbjelke is offline  
Old 12 June 2021, 20:30   #4
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,030
Quote:
Originally Posted by tverrbjelke View Post
/* Idea is to have ONE global thing to hold all Data
- is this stupid?
Not at all.

Quote:
And: is xxx_ptr naming convention also dumb?
You can name them whatever you like, if it helps you.

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

also stupid with Amiga SAS C compiller?
No.

Quote:
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.

Quote:
Code:
  /* 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:
Code:
if ((data.gfx_ptr = (struct GfxBase *) OpenLibrary("graphics.library",0)) == 0)
phx is offline  
Old 23 June 2021, 16:27   #5
tverrbjelke
Registered User

 
Join Date: May 2019
Location: Germany
Posts: 8
Best practices for simple logging in C

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:
Code:
#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)

Last edited by tverrbjelke; 23 June 2021 at 16:51. Reason: proper example of my LOG_TXT makro
tverrbjelke is offline  
Old 23 June 2021, 20:29   #6
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 1,133
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.

Last edited by nogginthenog; 23 June 2021 at 20:30. Reason: Clarification
nogginthenog is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
New on developing for the Amiga dlsa Coders. C/C++ 23 17 April 2021 21:51
Double barrel Amiga Future article series: Demoscene + Developing Demo Effects Photon News 3 30 December 2015 00:04
Dave Haynie Talks About Developing The Commodore Amiga pandy71 Nostalgia & memories 2 23 April 2014 21:38
First doubts for game developing nandius_c Coders. Asm / Hardware 21 25 October 2013 13:21
Who are developing games for Amiga platform at the moment? oldpx Amiga scene 65 06 October 2002 18:41

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:32.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.07367 seconds with 15 queries