14 December 2023, 23:40 | #41 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,658
|
Quote:
Code:
make v Then: Code:
make all NDK=3.9 |
|
15 December 2023, 22:31 | #42 | |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 61
|
Quote:
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. |
|
16 December 2023, 16:28 | #43 | ||
Registered User
Join Date: May 2001
Location: ?
Posts: 19,658
|
Quote:
Quote:
|
||
16 December 2023, 17:36 | #44 |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
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?
|
18 December 2023, 14:51 | #45 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,658
|
Quote:
As to why 1.3, because I need 1.3 compatibility? |
|
19 December 2023, 08:11 | #46 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
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. |
|
19 December 2023, 15:59 | #47 | ||
Registered User
Join Date: May 2001
Location: ?
Posts: 19,658
|
Quote:
Quote:
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. |
||
20 December 2023, 14:04 | #48 | |||
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
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. Quote:
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. Quote:
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 |
|||
22 April 2024, 15:08 | #49 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,658
|
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. |
23 April 2024, 09:34 | #50 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 681
|
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). Code:
AMIGA_GCC=/home/matze/amigatoolchain/amiga-gcc-out ./generate_projects.sh Created two directories with Makefiles in them: build-debug/ build-release/ Running 'make' in build-release yielded: Code:
... [ 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()); Code:
snprintf(error_buf, FS_WIDTH_CHARS, "I/O ERROR, DOS RETURN CODE %d", IoErr()); Code:
? 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 |
23 April 2024, 15:13 | #51 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,658
|
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. Last edited by Amiga1992; 23 April 2024 at 15:29. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Library for loading graphics | sparhawk | Coders. General | 2 | 07 March 2020 20:38 |
Flickering graphics using BltBitMap function of graphics.library | balrogsoft | Coders. C/C++ | 16 | 04 February 2020 14:54 |
Sas/C vs. GCC regarding graphics.library | Steffest | Coders. C/C++ | 7 | 27 October 2017 03:52 |
graphics library v40.25 | Schlachtwerk | request.Apps | 0 | 14 February 2015 20:47 |
Some question about graphics.library lowlevels | Sonic | Coders. General | 3 | 28 July 2010 11:45 |
|
|