Please login or register.

Login with username, password and session length
Advanced search  


Created for developers of all Amiga camps

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - magorium

Pages: [1] 2 3 ... 14
E33 (AmigaE) / Re: [E] ERROR: statement out of local/global scope
« on: May 08, 2017, 11:27:18 PM »
This topic is about the original AmigaE not PortablE.
You are of course, correct there. Thanks for the correction.

My objective was more to inform user on how to get attention of a more proficient user that might be able to help out.

With regards to what needs to be placed where exactly: admin lost me ages ago. There are simply too many overlaps and there isn't any logic (at least not one that i am able to follow  :) ).

E33 (AmigaE) / Re: [E] ERROR: statement out of local/global scope
« on: May 08, 2017, 06:37:51 PM »
Hi r-tea,

Just wanted to say that e has a separate sub-board here.

It might be that portablE-developer and expert ChrisH does not pay attention to the general language board so your message might be ignored. e.g. inside the e-board there is a special notice about how to get the attention of ChrisH.

Free Pascal / Re: Intuition window example
« on: April 11, 2017, 12:14:47 AM »
hi Andi,

Thank you for your interest and feedback.

I (still) have seen some copy-paste errors, so i will fix those on the next opportunity. Sorry for the inconvenience as it makes the tutorial a bit incomprehensible (or at least talking about something that is not even even there in the code to begin with ;D )

Please feel free to point out mistakes, or things of which you think could deserve some more explanation(s).

It is always more difficult to figure out what is helpful to show/explain and what is not, simply because we Pascal die-hards already know  :o

Happy coding !,

edit: fixes applied, and hopefully i did not forget anything this time.

Free Pascal / Intuition window example
« on: April 02, 2017, 09:58:34 PM »

Small example for those always wanted to see/ask how one could create a new (Free Pascal) class.

In this case it's all about a smallish wrapper for an intuition window (far from finished e.g. just there to show how one could approach things, and as such could be used as a generic way of accomplishing such task).

The example is accompanied with some explanations here and there and which can be read here and the sources can (also) be found here.

Keep coding !

PS: Please keep in mind that the original c source-code was kindly provided by Thomas Rapp.

AmigaOS 3.x Dev / Re: Hunk symbols
« on: March 23, 2017, 07:04:57 PM »
Ok, i've found my initial culprit.

To summarize what i've done wrong, which led me to post my initial question, is actually quite simple.

Initially i treated pr_SegList and cli_Module as pointing to a "list of segments"   :-[

I over read the part from pr_SegList where it reads: "Array of seg lists used by this process" and interpreted it as "SegList of..." which of course turned up some undesired results at first  ;D

For now that leaves me with one 'why' and/or 'explanation' unanswered which is why the fourth entry in the array of seglist items ? Is that documented anywhere ? Is there any documentation for what each entry in that array points to (or is suppose to point to) ?

I am however (from results found so far) assuming that the "list of segments" itself has a 1 on 1 relation with the hunks as organized in the executable ?
(and with that i meant those hunks from the executable that are actually loaded into memory).


AmigaOS 3.x Dev / Re: Hunk symbols
« on: March 23, 2017, 02:25:30 AM »
Hi SamuraiCrow,

Thank you very much for the links, especially the one on the overlays.

The overlay hunk was also something that raised a load of questions. Most (if not all) of those questions are now answered thanks to that document.

So, also thank you to Thor !

I would settle for grasping the more simple things in life though  :D

fwiw: I'm not creating a debugger or disassembler or the like. I'm simply trying to get a more informative backtrace from the compiler...

At least some victory as i had a look at the sources of scout which answered some of the hows for me.

I still do not fully grasp (all) the why's though and i am still unable to locate any decent documentation other then a few hints here and there (most of which i was able to find in my stock old amigados reference manual).

At least current progress allows me to get rid of the ugly parts in my code that obtains the address of a function that is known to be part of the symbol table, then look for its name in there to end up calculating the base address using the offset of that symbol.

So far, the results (note that the hunk loading is done before main program entry is invoked. The dumps you see are from the executable itself):
Code: [Select]
Processing HUNK_HEADER
Processing HUNK_CODE
Size = 570228
Processing HUNK_RELOC32
Processing HUNK_SYMBOL
reading symbol table (1)
finished symbol table reading
Processing HUNK_END
Processing HUNK_DATA
Size = 161272
Processing HUNK_RELOC32
Processing HUNK_SYMBOL
reading symbol table (2)
finished symbol table reading
Processing HUNK_END
Processing HUNK_BSS
Size = 10128
Processing HUNK_SYMBOL
reading symbol table (3)
finished symbol table reading
Processing HUNK_END
EenyMeenyMinyMoe @ $104342A0
match #0 at index #1664 = AMIGA.HUNK_$$_EENYMEENYMINYMOE @offset: $00054508
Base calculation succeeded
Pre-Initialization finished

HunkDumper 0.07 by MAG (2017)
function AmigaPlay1() @ : $103E034C
...base Address    = $103DFD98
...OffsetToLookFor = $000005B4

TaskName = Shell Process

 #    size     bottom        top
 0  570236  $103DFD98  $1046B10C
 1  161280  $1046B118  $10492710
 2   10136  $103CBCF8  $103CE488

The constructed symbtab which then can be saved to disk. A small excerpt:
Code: [Select]
[1]    3  $00011950  SYSTEM_$$_ROUND$INT64$$INT64
[1]    4  $00024420  fpc_finalize_array
[1]    6  $0001F834  fpc_intf_incr_ref
[2] 3098  $0001BB84  _$RTLCONSTS$_Ld306
[2] 3099  $00010EB4  _$SYSCONST$_Ld255
[2] 3100  $00010964  _$SYSCONST$_Ld214
[2] 3102  $00018C1C  _$RTLCONSTS$_Ld22
[2] 3103  $000077C8  _$SYSUTILS$_Ld242
[2] 3104  $000131D0  VMT_$CLASSES_$$_TSTRINGLIST
[2] 3105  $00022298  RESSTR_$RTLCONSTS_$$_SRANGEERROR
[2] 3107  $00015FD0  RTTI_$CLASSES_$$_DEF1451
[3] 7398  $0000233C  U_$DOS_$$_DOSERROR
[3] 7399  $00001114  U_$SYSTEM_$$_SOFTFLOAT_ROUNDING_MODE
[3] 7400  $00000034  U_$SYSTEM_$$_ERROUTPUT
[3] 7401  $0000269C  U_$CLASSES_$$_REMOVEDATAMODULE
[3] 7402  $0000000C  stackSwap
[3] 7403  $000011B0  U_$SYSTEM_$$_AOS_CONHANDLE
[3] 7404  $00000008  stackPtr
[3] 7405  $000011BC  U_$SYSTEM_$$_ENVP
[3] 7406  $000026BC  U_$CLASSES_$$_GLOBALNAMESPACE
[3] 7407  $00001190  _DOSBase

So, i'm fairly confident with regards to the hunk parser (even though i am aware i still need to add proper support for libraries... and overlays of course  ;) Although the latter might be a bit redundant for currently used compiler/linker).


AmigaOS 3.x Dev / Hunk symbols
« on: March 22, 2017, 01:50:18 AM »

How can i map symbols located in the symbol hunk to my (runtime) program ?

Or perhaps the better question would be (?): how do i figure out at runtime at what memory address my executable (hunk) was loaded so that i can map the relative symbol offsets to absolute offsets.

It might be i'm doing things wrong here but (available online) information seems very scarce or non existent.

Initially i was looking at pr_SegList but that seems to be a dead end or maybe i'm missing something.

Perhaps someone is able to recommend a link and/or good book title on the subject on hunks and how they relate to actual practice ?

The only usable links i was able to find/use so far is inside the OS4 wiki and this page.

The latter link does mention a function named get_hunk_address() but i fail to locate an actual implementation and also fail to come up with something of my own that works.


PortablE / Re: Arrays, Strings and Random string values
« on: March 17, 2017, 06:10:16 PM »
For sure, it should be possible.

In case PortablE does not have native support then you could always try to write a helper module yourself in case ChrisH currently doesn't has time.

There is an example written in c-language here on how to use the clipboard, and indeed it is very lowlevel.

Sorry to say that my experience with portablE is next to none, so i can't help there either but perhaps Zendarion is able to make use of the example.

Aaah, ok  :)

Thank you for the elaboration on that Fastbit66, as it explain a few things i was wondering about ;D

OK, then i case you would like a quick starter refreshment course then you could use the one from tutorialspoint here to get you back into shape.

In case you'd like a crash-course into modern language features then you could use the tutorial from here.

In case you stumbled upon my github then please keep in mind that most of my work expressed therein is aimed to be used with the FPC 3.0 compiler (trunk version which you are currently working with is actually version 3.1).

There are a lot of changes/improvements that are part of trunk that are not present in the official release and therefor FPC 3.0.x is showing its age by now.

That can work pretty confusing if you are not aware, so i thought to mention it.

There is nothing or anyone to blame for the current incompatibilities between versions, and tbh we could use some other extra improvements to go into trunk in order to get those improvements to be part of the next official release of FPC.

Keep in mind that FPC 3.0 was the first official release that supported again all our platforms in the way it currently does thanks to the fantastic work done by Chain-Q and ALB42.

Chain-Q is afaik mostly targeting MorphOS and m68k while ALB42 and me are more AROS oriented tbh ALB42 is supporting all with his work). As long as you do not use platform specific features then your code should be able to compile for all (including Windows/Linux and MacOS targets, to name a few).

Atm i use Windows for cross-compiling to Amiga, AROS and MorphOS but as long as there are no platform specic changes needed i can test my code on Windows first  :D


Thanks a lot for your anwswer and the interesting links.
You're most welcome.

The fpcamigawiki is our main source of information. Please feel free to point out mistakes or better yet, in case you have information you would like to add to actually add it.

As you perhaps can see for yourself there are some things lacking especially when it comes to MorphOS and OS4.

Other interesting links are the official Free Pascal wiki pages, Amiga, AmigaOS4, AROS and MorphOS (even though the AROS wiki links back to ALB42's fpcamigawiki)

And of course there is the main Free Pascal wiki entry here, with a extensive list of topics, examples etc. As a general rule of thumb: google search: "freepascal topic" and you usually end up in either the documentation, the wiki or an example somewhere on the web (to get ahead of things, do a search "freepascal delay" and you understand why we can't name our Dos library function delay also delay).

As a little test I coded an openscreen example from c to pascal:
If you are new to Pascal then taking small steps will help you a lot. You might discover it is not that far from C.

The main difference start when using OOP or modern languages constructs such as advanced records, helpers and last but not least the additional (and extensive list of) Pascal libraries (some of them available in native Pascal (such as json, xml, dbf), others depend on external libraries).

I must admit that I never have done things like that before. But I really would like to learn all the necessary stuff
to achieve the goal one day.
Just take your time, and in case of question then please feel free to ask. In case you prefer then feel free to PM (although doing it openly will help others that want to travel the same journey).

...makes completly sense to me in context with achieving a maximum of system indepandance.
One thing that was missing from my previous reply is indeed that ALB42 and me mostly work on getting the other Pascal units working for our platforms. In that regards some OS specific functionality isn't as interesting as it otherwise might be.

For example for Lazarus (visual building applications) there were several approaches and ALB42 ended up with what we currently have available. It is a constant process of development and progress (and sometimes sat-backs).

I tried Delay but tht's not found by the compiler...
Ah yes, sorry.

I should have mentioned that some of our API function names (whether it Amiga, AROS or MorphOS) collide with Pascal functions that are available (all or not available in a particular unit).

Also to stay consistent with the naming we had to change some of the names for our native API calls. A list of changes can be found here.

There you can see that the function that you are looking for is now named DosDelay()  ;)

Perhaps also an idea to mention is that c makes extensive use of include files (.h files) while it is normal for Pascal to have a unit that contain both the header (in the interface section) as well as the actual implementation (in the implementation section).

In case you are truly lost with Pascal then you can always attempt to get yourself a bit more familiar with things using the official Free Pascal documentation.

Of course, in case you get stuck then feel free to ask (although nobody is able to teach you the Pascal language as only you yourself is able to do so). If you are reasonably seasoned with c programming then (i guess) the most difficult part  would be to get yourself familiar with the standard Pascal libraries and getting to know where exactly everything is tucked away  :)


Hi Fastbit66,

Thank you very much for reporting back on your issues. Dumb is that i forgot to suggest compiling in ram disk as that rules out at least HD related issues (memory issue will appear more often there though  ;)).

With regards to your question about reaction. I don't think our (current) headers have everything in place to program for/with reaction. In basics it is just calls to intuition, but most OS4 specifics are not in place (ALB42 would know for sure).

In theory you could just follow examples such as mentioned here, and i also noticed a video here (haven't looked at it myself yet).

The only difference with regards to the c examples should be the explicit use of library interfaces. So everywhere where you read things like...
Code: [Select]
.. you omit the library interface so that you just call Wait, GetAttr, and SetAPen.

At least, that is my understanding atm.

Please keep in mind that reaction is very OS4 oriented and as such has not got any priority for us. All the (other) basic libraries are in place though such as dos, graphics, intuition etc but, i do not know for sure if all OS4 additions are in place.

My main focus so far was on getting Classic, AROS and MorphOS headers on par with eachother. afaik ALB42 added some additional extensions that are (yes or no) platform specific.

That is also the part were we could use some help  :P

If you feel/experience something is missing for your needs then please do tell.

Please also see this page for what headers are  available.

Also please note that although we try to do everything in our power to add to our existing library that we are limited time wise and hardware wise.

In case you are able to help us create missing or add to existing headers then we would consider that very helpful and would allow for others to make use of your work as well. Reporting back on missing features will also aid us.

When reporting issues, also keep in mind that we are bound to existing (and available) SDK's.

PS: i forgot to mention, one other field that is platform specific is the use of hooks. We can get into details about those when you are running into that.

i am not very proficient with linker or compiler related issues.

However, we can try some simple deduction (in case you are sure it is not hardware related issues).

Make the simplest of program and see if that (always) works for you:
Code: (pascal) [Select]
program test;

  WriteLn('Hello world');

Then try add up the ante:
Code: (pascal) [Select]
program test;


  WriteLn('Hello world');

Then the next unit:
Code: (pascal) [Select]
program test;
  SysUtils, Exec;

  WriteLn('Hello world');

etc. etc. until you can reproduce your problem again. All the units are listed in the uses clause of the winpubscreen example: SysUtils, Exec, AGraphics, Intuition and Utility;

Something that is definitely different in the winpubscreen example is the use of the forward declaration of routine handle_window_events.

You can try to remove that line and place that function above the main routine.

Please feel free to ask in case you did not understand something and/or have additional questions.

edit PS:
I just realize, perhaps the tag ending is a problem.

In the call to OpenWindowTags, where you can see the TAG_END, add another TAG_END (or a zero, which is factually a TAG_END). Perhaps they always need to be even (pairs) on OS4.

Would be cool if i can help.
Would be as evenly cool if you could and would.

You're running on the bare metal so you have one big advantage over us there :)

Every 'issue' that you run into and are able to report about would be helpful.

In case you have your mind set on actually developing something using Free Pascal then please feel free to ask in case you have questions.

It helps (but not required) if you know a little c (Pascal is just a bit more distinguished in it's communication in comparison to c, where the latter sometimes leaves you in the dark about what is exactly happening while the first requires you to be more explicit in many cases).

It is possible to convert every sdk example (usually c) into Pascal code, and such example should work just the same.

Hey !!! Thanx a lot for that hint.
You're welcome  :)

I commented the two lines out compiled AND WORKS !!! YEAHHHH
Which was the intention. Congratulations on having fixed your first bug with Pascal  8)

Muitest, smallThreadTest and the winpubscreen still bring up the grim reaper when trying to run.
Having looked at the sources, i would be very interested to know why winpubscreen fails as i can't seem to find any obvious errors. Perhaps i'm overlooking something.

The threadtest could be problematic for OS4 (although in theory should work, but there are some hoops) and also muitest might expose some undesired behavior on OS4.

Hopefully the MUI examples that ALB42 posted a link to, do a better job for your case. Please feel free to let us know.

Just in case you feel even more adventurous and in case you would add the following line...
Code: [Select]
WriteLn('We are now at line', {$I %LINE%});
... on every line between begin end blocks (just before every statement), then running the program from a shell will display this output to you and let you see what lines are executed successfully (including the line number).

That way you are able to see what function work and which do not (as you will see the last writeln that executed successfully). That way you would be able to pinpoint where exactly things go wrong in the source-code.

Sharing those results would help us tremendously.

As a matter of fact, i still use this method myself in case things go seriously wrong. The only difference would be that i am a bit more proficient with it so that i do not need a writeln for every line, but use it to globally pinpoint a troublesome subroutine and then examine that subroutine into detail manually.

No need to do such a thing if you are not familiar or not feel confident enough, just a hint in case you'd like to experiment  ;)

Ok thank you for letting me know. nothing serious then. Just moving forwards. Just for completeness: OS4 target with current stable release 3.0.2 (also) suffers from this (fixed in trunk) ?

Code: (asm) [Select]
PPC disassembly:
 6fb00f08: 4182001c   beq-              0x6FB00F24
 6fb00f0c: 4182001c   beq-              0x6FB00F28
*6fb00f10: 7c695b67   .word             0x7C695B67
 6fb00f14: 7c69e11c   .word             0x7C69E11C
 6fb00f18: 7c6903a6   mtctr             r3
Well, ^^ that ^^ can't be good .. two branches no catch in case they fail .... something must have gone wrong there i guess.

Since the new linker works for you, i won't worry too much about it.

To ALB42 i would like to ask: optimizations at play ? (or at least a known problem ?)

Pages: [1] 2 3 ... 14