Issue with graphics.h library?

[Amiga1992]

Originally Posted by bebbo

make clean
make v date=2020-07-31

maybe you should use different PREFIX then

make v

returns to the latest versions.
and maybe even

make clean
make all NDK=3.9

could help you, since at that time the NDK 3.9 *with patches* was used.
(now NDK 3.2 only having the timeval patch is used by default)

Well I tried these:

make v

this gives error: "make: *** No rule to make target 'v'. Stop."

Then:

make all NDK=3.9

And that gave the exact same error on gfxbase.h

[Docent]

Originally Posted by Amiga1992

But I already have those as shown in the error I posted above. It's erroring on the 1.3 includes. Please read again the error code I posted above.

[edit] I did exactly what you said just to be thorough, i copied the files from that exact CD to where you said , and I have even more errors now, also noticed there's far less folders of H headers there than in the old folder. this is not a solution.

This was already explained by others - the directory ndk13-include contains includes that were built from the includes for later version of kickstart and contain some files that have definitions for newer version of includes. That is also the reason why you also have more directories than in the original includes for 1.3.
Post the log with errors you got while compiling with these 1.3 includes from cd - it wil be easier to solve the problem.
You can also try to replace gfxbase.h in original ndk13-include directory with the version from cd.

[Amiga1992]

Originally Posted by Docent

Post the log with errors you got while compiling with these 1.3 includes from cd - it wil be easier to solve the problem.

I already posted the error I got several times, it just that one error where it stops, about Monitor Vblank.

You can also try to replace gfxbase.h in original ndk13-include directory with the version from cd.

I already did that and it got worse.

[Olaf Barthel]

Originally Posted by Amiga1992

I already posted the error I got several times, it just that one error where it stops, about Monitor Vblank.

I already did that and it got worse.

I am sorry for asking this question, but why exactly are you using the 1.3 variant of the operating system header files which were generated from the NDK 3.9 header files? Which problem would they, ideally, solve for you, if they worked robustly?

[Amiga1992]

Originally Posted by Olaf Barthel

I am sorry for asking this question, but why exactly are you using the 1.3 variant of the operating system header files which were generated from the NDK 3.9 header files? Which problem would they, ideally, solve for you, if they worked robustly?

I did not create the NDK files, I just installed bebbo's GCC environment as instructed.

As to why 1.3, because I need 1.3 compatibility?

[Olaf Barthel]

Originally Posted by Amiga1992

I did not create the NDK files, I just installed bebbo's GCC environment as instructed.

As to why 1.3, because I need 1.3 compatibility?

Yes, and it is not delivering on this promise yet

Whenever you build a program for the Amiga, the compiler's runtime library also includes startup code which allows it to be launched from the shell and the Workbench. This startup code is different for Stefan Franke's gcc if you build it for Kickstart/Workbench 1.x or Kickstart/Workbench 2.x and beyond. The startup code for Kickstart/Workbench 2.x is not necessarily compatible with older operating system versions.

But the choice of header files you can make use of is not as restrictive as the choice of startup code implied by the operating system version to build for (1.x vs 2.x/3.x). The NDK 2.0, 3.1, 3.5 and 3.9 header files are supersets of the 1.1, 1.2 and 1.3 header files. Put another way, you can build 1.x compatible software if you use the 3.1, etc. header files instead of the (currently not entirely usable) 1.3 header files provided for Stefan Franke's gcc.

You might want to give this a shot by backing up your gcc installation first and then replacing the 1.3 header files with the 3.9, etc. header files. If your code restricts itself to Kickstart/Workbench 1.x functionality, it should build just fine. There is no mechanism implemented in the 3.9, etc. header files which "converts" operating system function calls into the "proper 3.9 way", thus rendering the code generated unusable on Kickstart 1.x. These header files are designed to be 100% compatible to what came before and to let you build even old 1.x code in the same way it would have been built with the original 1.3 header files.

[Amiga1992]

Originally Posted by Olaf Barthel

But the choice of header files you can make use of is not as restrictive as the choice of startup code implied by the operating system version to build for (1.x vs 2.x/3.x). The NDK 2.0, 3.1, 3.5 and 3.9 header files are supersets of the 1.1, 1.2 and 1.3 header files. Put another way, you can build 1.x compatible software if you use the 3.1, etc. header files instead of the (currently not entirely usable) 1.3 header files provided for Stefan Franke's gcc.

Thanks for explaining that so well, I know it's not easy to muster up the patience to explain things to someone that's not up to your level of proficiency.

You might want to give this a shot by backing up your gcc installation first and then replacing the 1.3 header files with the 3.9, etc. header files. If your code restricts itself to Kickstart/Workbench 1.x functionality, it should build just fine. There is no mechanism implemented in the 3.9, etc. header files which "converts" operating system function calls into the "proper 3.9 way", thus rendering the code generated unusable on Kickstart 1.x. These header files are designed to be 100% compatible to what came before and to let you build even old 1.x code in the same way it would have been built with the original 1.3 header files.

Well that's what I said I tried before, and I got a plethora of issues. Maybe I need to try again. I swapped gfxbase.h from the 2.1 developer CD that was suggested before, and it did not work

I know this is a weird and annoying situation and believe me I don't want to be in it myself but I have been basically fucked over and left with this code without any possibility to get help in making it compile so I appreciate everyone's help working with me with the limited information I can provide and my limited skills.

[Olaf Barthel]

Originally Posted by Amiga1992

Thanks for explaining that so well, I know it's not easy to muster up the patience to explain things to someone that's not up to your level of proficiency.

I'm trying. If one struggles to explain something, one may not have understood it sufficiently well enough just yet. There is also the matter of making Amiga software development easier to get into and to subsequently become more proficient.

The days when Amiga software development was still evolving and sustained by a multitude of parties following commercial interests are long gone. What was available in terms of documentation how to use the development tools, and how one would develop software that makes use of the operating system, was adequate and became better. Today even obtaining this kind of information is (from the point of somebody who has been around for a while) not really satisfying.

The development tools are also much more complex than they used to be, because back in the day one would use tools ('C' compilers, for example) which ran on the Amiga which you developed the software for. The "simpler" tools of the day would use less memory than gcc (they had to: Amigas did not ship with 16 MBytes of memory until the early 1990'ies) and therefore permit faster turnarounds for building, testing, bug fixing, etc.

That's quite the boulder one needs to push up the hill there, with gcc today. And until one has advanced further in the craft, the benefits of using gcc may for a time remain out of reach.

Well that's what I said I tried before, and I got a plethora of issues. Maybe I need to try again. I swapped gfxbase.h from the 2.1 developer CD that was suggested before, and it did not work

Yes, and this attempt likely failed to improve matters because the header files you chose as a replacement are from a different operating system release time frame. They do not necessarily fit in.

For example, you can almost assume that swapping the Kickstart/Workbench 2.0 era header files for audio.device and serial.device with the 2.1, 3.0, 3.1, 3.5, 3.9 and 3.2 versions will work because they are practically unchanged since 1985. But operating system components which saw great change invariably have different dependencies on other header files from their respective release version. The graphics.library certainly qualifies there: it went from supporting TV sets to multiscan monitors in Kickstart 2.0, then to supporting 256 colours in 24 bits on a screen in Kickstart 3.0. The operating system header files expanded and changed with every step.

Hence, you should try to swap out the entirety of the header files instead of trying to replace parts (if this is feasible). While replacing parts is doable if you also adapt the replacement to its new environment, it will invariably become a huge time sink.

I know this is a weird and annoying situation and believe me I don't want to be in it myself but I have been basically fucked over and left with this code without any possibility to get help in making it compile so I appreciate everyone's help working with me with the limited information I can provide and my limited skills.

I view the use of gcc as a cross-compiler with some concern because of the turnaround times involved in building, testing, bug fixing and restarting the cycle. If you already come from a background which involves this kind of cycle, you will likely do fine. But if not, then the obstacles to pile up in your way will start looming over you.

Couple of postings back I tried to put the avalanche of errors messages produced by the compiler into context. This is something 'C' developers need to learn at some point, as early as possible, because otherwise the whole exercise will seem futile.

All of this has to be easier to get into. 'C' is a challenging programming language which requires considerable attention to what appear to be mostly pointless details, as well as dealing with what the compiler "helpfully" tells you is wrong with your code. Trouble is, what's "wrong" is that the compiler stopped processing because of some minute typo, then tried to get back on track, skipping over instructions which then lead it to complain about something missing (the stuff it skipped), "fantasizing" about what might be wrong.

Getting the hang of this is part of the learning experience

Work on AmigaOS 68k is ongoing, and part of that is offering a better software development kit, with better, more comprehensive documentation than there used to be before. It seems likely to me that we also need to cover how one would install and use an Amiga 'C' compiler. A practical introduction with examples and advice. Tall order

[Amiga1992]

now that the source has been made public without my consent maybe at least someone can look at it and see exactly how the fuck to compile it and I can finally get something positive out of this situation and put it to rest.
Anyone willing to have a look please click here.

[pipper]

I have successfully built https://github.com/djh0ffman/PT1210 on Linux with Bebbo's toolchain.

It came with build instructions and a CMake script. I had to use the djh0ffman repository as the fork you pointed to did not have tags and the cmake script needs at least one tag to be present to succeed (it generates a version string from it).

AMIGA_GCC=/home/matze/amigatoolchain/amiga-gcc-out ./generate_projects.sh

`/home/matze/amigatoolchain/amiga-gcc-out` being my personal prefix where I built the toolchain to.

Created two directories with Makefiles in them:
build-debug/
build-release/

Running 'make' in build-release yielded:

...
[ 50%] Building C object CMakeFiles/pt1210.dir/src/filesystem.c.obj
/home/matze/PT1210/src/filesystem.c: In function 'read_error':
/home/matze/PT1210/src/filesystem.c:52:68: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'LONG {aka int}' [-Werror=format=]
  snprintf(error_buf, FS_WIDTH_CHARS, "I/O ERROR, DOS RETURN CODE %ld", IoErr());

with an easy fix in filesystem.c:52

snprintf(error_buf, FS_WIDTH_CHARS, "I/O ERROR, DOS RETURN CODE %d", IoErr());

The compilation succeeded:

?  build-release git:(v1.1) make
[  5%] Generating version information using git
[  5%] Built target version
[ 20%] Built target legacy
Consolidate compiler generated dependencies of target pt1210
[ 25%] Building C object CMakeFiles/pt1210.dir/src/filesystem.c.obj
[ 30%] Building C object CMakeFiles/pt1210.dir/src/gameport.c.obj
[ 35%] Building C object CMakeFiles/pt1210.dir/src/graphics.c.obj
[ 40%] Building C object CMakeFiles/pt1210.dir/src/input.c.obj
[ 45%] Building C object CMakeFiles/pt1210.dir/src/inputdevice.c.obj
[ 50%] Building C object CMakeFiles/pt1210.dir/src/keyboard.c.obj
[ 55%] Building C object CMakeFiles/pt1210.dir/src/main.c.obj
[ 60%] Building C object CMakeFiles/pt1210.dir/src/pt1210.c.obj
[ 65%] Building C object CMakeFiles/pt1210.dir/src/timerdevice.c.obj
[ 70%] Building C object CMakeFiles/pt1210.dir/version.c.obj
[ 75%] Linking C executable ../bin/pt1210.exe
[100%] Built target pt1210

Unfortunately, the resulting executable just creates a grey screen. I do not know what to expect - I tried running it on an A3000/060/OS3.2.1

[Amiga1992]

That's really odd, I didn't do anything out of the ordinary to install bebbo's tools, I folowed all the instructions.
I try to compile this version and it says that it can't find the AMIGA_GCC environment variable, even though I have it set (and the cmake script works on my version)



As to why it doesn't work, I will assume since you are in the US that your machine is NTSC. Switch it to PAL and it might show up. if not that, 3.2.x could be a problem.