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 ... 13
Free Pascal / Re: hvl2wav c2pas translation failure
« on: February 16, 2017, 01:49:43 AM »
of thanks for that tip with sarLongInt, yes it seems it does the same... I did not know that.
I didn't either.... it just seemed odd to me that FPC would not have an implementation for doing an arithmetic shift (and it actually officially didn't until recently  :o).

Learning something new every day  :)

*"Magic Elixier of mighty bug finding" wears off*

I had a couple of minutes to spare for a quick test that shows what that magix elixer of yours brought sofar:
Code: [Select]
"a moon light.ori.wav" and "a moon light.ori.wav" have 0 different bytes ( 100.0000% similarity )
"a moon light.ori.wav" and "a moon light.pas.wav" have 37074380 different bytes ( 1.9812% similarity )
"a moon light.ori.wav" and "a moon light.pas.fix.d3.wav" have 34541768 different bytes ( 8.6770% similarity )
"a moon light.ori.wav" and "a moon light.pas.fix.fxparam.wav" have 13649319 different bytes ( 63.9133% similarity )
"a moon light.ori.wav" and "a moon light.pas.fix.random.wav" have 2360052 different bytes ( 93.7604% similarity )

That's an improvement of about 92 percent against my initial results and much better then the earlier reported 75 percent similarity  ;D

Hmz... that makes me wonder what my contribution was to that code i've committed   ???

I know, what the problem is: it is some rounding error in the basic waveforms which is rather strange in the C program, I really did get not why it happens and what is wrong there.
I did a small readup on that and some SO answers seem to indicate that indeed there are 'better' conversion techniques, depending on the compiler (static casts etc).

But I can tell you how to find it.
Hmz that is very interesting.

I also recognized the pattern when looking at the diff files and therefor was initially suspecting GenWhiteNoise() routine to be the cause for that as that seemed the most likely candidate to me. I wasted quite some cycles on that   :'(

I could have sworn that i've tested the waveforms with running a checksum over the generated waveforms and compare c against Pascal results. I either remember this wrongly or i made a boo boo in the checksum calculation :-S

At least I can not hear a difference when playing the wav. For me this would be ok to keep it like that.
You are quite right about that.

This is just one of those things that keeps buggin' me until the ends of time, and i won't rest until i've turned every stone in order to be able to pinpoint the whats, wheres and/or whys ... i consider it a narcissistic character flaw  :D (*)

Very important lesson learned/reminded though: always ever doubt your own work as for certain you will keep making mistakes with these kind of conversion. A second set of eyes is a god-bless for such cases.

Thank for that mate !

(*) changing float64 type inside chelpers unit from double to extended seems to have done the trick.
Code: [Select]
"a moon light.ori.wav" and "a moon light.pas.fix.extended.wav" have 0 different bytes ( 100.0000% similarity )
Weird, as i figured float64 to comply to FPC's type double ? did i go wrong there ?

Free Pascal / Re: hvl2wav c2pas translation failure
« on: February 13, 2017, 06:46:58 PM »
First one is easy:
Oops  :-[

Yes, thank you for spotting this as well as for your explanation.

It's one for the hall of shame as i am familiar with how this c construct works. I seem to have missed this when i re-cleaned the sources with those from my local working dir (not branch).

fwiw: there is another one exactly like that at line 1516

The second was VERY hard, took me 2 hour to figure out whats wrong there ;-)

Hmz, i wonder if all that casting was a premonition :-)

1. the C program is not 64 bit safe :-(, so if you compile 64 bit the pseudorandom go havoc
That would propbably have been encountered and/or addressed with the (recent) jessie 64 bit conversion as well (i just noticed that it was worked upon).

2. the behavior for Pascals "shr" and Cs ">>" is different for negative numbers
(pascal shifts as it would be unsigned value, C fills the leading places with "1", so the number stay negative)
I am somewhat familiar with the differences between c and Pascal with regards to shifting. I just not had any clue that the implementation in the replayer was depending on this behaviour.

TBH i probably would not have been able to find that myself, so thank you very much for having spotted that.

Am i correct when stating that using the (new) SarLongInt intrinsic would have similar results as your manual solution ? , e.g.:

Code: [Select]
    if ( voice^.vc_Waveform = (4-1) ) then
      // AddRandomMoving
      AudioSource := AudioSource + ( voice^.vc_WNRandom and (2*$280-1) ) and (not 1);  // FPC note: check not(1)
      // GoOnRandom
      voice^.vc_WNRandom := int32( int64(voice^.vc_WNRandom) + int64(2239384) ) ;    // FPC: overflow
//      voice^.vc_WNRandom := ((((voice^.vc_WNRandom sar 8) or (voice^.vc_WNRandom shl 24)) + 782323) xor 75) - 6735;
      voice^.vc_WNRandom := ((( sarLongInt(voice^.vc_WNRandom, 8) or (voice^.vc_WNRandom shl 24)) + 782323) xor 75) - 6735;

I have not seen the results with this change with my own two eyes (i had to rely on reports from 3th party) but that seems to have been a major improvement over pre-existing wav output.

If i have to trust the reports then this would make about 75 percent of the outputted wav similar to the wav as outputted by the original hvl2wav utility and those values that are different are close to its original counterpart. There are no complete diff blocks anymore, only several values (which seems another indication something is still wrong with one of the applied effects).

I'll apply the fixes to my tree as soon as i'm able to. Please feel free to a pull request if wanted. (fwiw: i'll credit you for the fixes anyway)

Thank you very much for your input, analysis and solutions. At the least you gave me a very good motivation to try my other changes again in order to try locate where else i did go wrong. Feel free to further aid me in this though  :D


Free Pascal / Re: hvl2wav c2pas translation failure
« on: February 12, 2017, 05:26:55 PM »
First of all,thank you very much for your time on this ALB42. It is really appreciated.

I'm sure you will hate that error ;)
Yups  :)

maybe better would be:
Code: [Select]
    d3 := d3 and (not $80);
    d4 := d4 and (not $80);
Oh dear... that is a very nasty typo which i have overlooked dozens of time by now. Thank you for your fresh pair of eyes and make me see that.

(at least for me it works this way)
awesome work btw. I like it.
Unfortunately, for the test-song i used, it made not a single bit of difference  :o That made some progress, but it seems that was not all what is wrong with my code (stupid me initially corrected the wrong source)  :-[

I've uploaded my test song (a moon light) to your ftp server. Its in pub/hvl, and the zip contains the original .hvl file and both the Pascal produced wav as well as the wav produced by the original hvl2wav program on windows.

Please don't be intimidated by the diff file :-)

Unless you are familiar with the tune(s) you probably won't spot too much difference. There are two hvl tunes with some effects that even sounds strange for the untrained ears (the names eludes me atm, i'll look them up when i get back).

There unfortunately is more then meets the eye. The asm code (relying on processor specifcs) was converted into c (relying on c compiler behavior) which i then converted into Pascal (which has it's own peculiarities).

I'm pretty sure my error lies in either a wrong interpretation of what the c compiler produces or unfamiliar/overlooked behavior from the Pascal compiler. In my experience replayers are a bit nasty to port (good).

PS: feel fee to give away the link to the archive in case it is requested, since it's your bandwidth i'm wasting.

Free Pascal / hvl2wav c2pas translation failure
« on: February 11, 2017, 06:07:49 PM »
Since another thread already discussed the basics of C, and some 'hidden' specifics that the language confronts you with i got into a bit of a problem with regards to translating hively player to Pascal.

I've looked at my 'port' a numerous amount of times now and, i simply fail to see where i go wrong. Most probably i have interpreted that the c-code does something but in fact does something different then i was expecting. As can be read from that earlier mentioned thread, that is something i am still struggling with (even after all these years).

The wonderful results can be found here.

I would be obliged if someone with more c knowledge (and preferably a bit of Pascal as well) would be able to point me a bit into the right direction. One word of warning though as the code is a bit tedious and long winded. I've looked at the code for so long that i can't even distinguish spaces from numbers anymore  ;D

In case wondering, i used the hvl2wav sources. That way i could use the original c produced executable to generate a wav file and see what the Pascal translated code produced, compare the wav files to see if both codes produced the same -> my code goes a bit off at some of the effects (i was even unable to determine which effect(s)).

In the end i would like to add the ahi/wav back-end to be used in a player or all platforms (even though the c code can be used to do the same).


Free Pascal / Re: Welcome to FreePascal on Amiga Systems
« on: February 11, 2017, 05:51:25 PM »
FreePascal for Amiga got it's own Subforum, so Welcome.
Macaroni and cheese, now with a cherry on top  ;D

I hope to establish this as a central discussion point for all FreePascal@Amiga users.
And Amiga stands here for Amiga OS3, Amiga OS4, AROS and MorphOS.
Yes, that would be nice.

One Request please let the war between the Platforms out.
Kum ba yah  :)

Currently there are not much differences between the 4 Platforms, and I'm working on it to make it even smaller.
And in case you do spot differences then please don't hesitate to notify so things can be addressed. Trinity forever !  (or actually die as soon as possible)  ;)

Thank you to the powers that be for this opportunity.

AmigaOS 3.x Dev / Re: 24Bit Image on AGA/ECS
« on: February 11, 2017, 12:15:39 AM »
About Datatypes I also thought, but I don't have a file ;) only a memory area with RGB Values.
hmz, i was going to suggest using datatypes as well.

render.library seems to offer something like that.
I got myself a 5 minute break, and what am i doing... telling that FPC also offer something similar  :P

(Please check good for typo's/obvious errors as i only had remote compilation available, in theory below code should work)

Code: [Select]
program test;


  Classes, FPImage, FPDitherer, FPReadBMP, FPWriteBMP;

  WBPalette : TFPPalette;
  // Default 4 'color' workbench (colors are a bit off, sue me :-p ).
  WBColors  : Array[0..3] of TFPColor =
    ( red: $9595; Green: $9595; Blue: $9595; Alpha: $FFFF ),
    ( red: $0000; Green: $0000; Blue: $0000; Alpha: $FFFF ),
    ( red: $FFFF; Green: $FFFF; Blue: $FFFF; Alpha: $FFFF ),
    ( red: $3B3B; Green: $6767; Blue: $A2A2; Alpha: $FFFF )

  i,x,y     : integer;
  SrcBitmap : TFPMemoryImage;
  DstBitmap : TFPMemoryImage;
  FS_Dither : TFPFloydSteinbergDitherer;
  Writer    : TFPWriterBMP;
  // Create palette based on WB colors;
  WBPalette := TFPPalette.Create(0);

  for i := Low(WBColors) to High(WBColors)
    do WBPalette.Add(WBColors[i]);

  WriteLn('After adding colours the palette contains ', WBPalette.Count, ' colors');
  for i := 0 to Pred(WBPalette.Count) do
    WriteLn('color[',i,'] = ', HexStr(WBPalette[i].Red,4), ' ', HexStr(WBPalette[i].Green,4), ' ', HexStr(WBPalette[i].blue,4), ' ', HexStr(WBPalette[i].alpha,4));

  // init
  SrcBitmap := TFPMemoryImage.Create(0,0);
  DstBitmap := TFPMemoryImage.Create(0,0);
  Writer    := TFPWriterBMP.Create;

  // 'simulate' raw data

  // create and apply dithering
  FS_Dither := TFPFloydSteinbergDitherer.Create(WBPalette);
  FS_Dither.Dither(SrcBitmap, DstBitmap);
  // 'simulate' display (replace with drawing into window)
  Writer.BitsPerPixel := 4;
  DstBitmap.SaveToFile('Test.Out.bmp', Writer);

  // example:
  for y := 0 to Pred(DstBitmap.Height) do
    for x := 0 to Pred(DstBitmap.Width) do
      // print pallette index numbers, otherwise for rgb values use colors proprty.
      // WriteLn('Pixel(x,y) = ', DstBitmap.Pixels[x,y]);
      Write(' ', DstBitmap.Pixels[x,y]);

  // Done

Dunno how practical fpimage would be on classic though, as it is a bit memory hungry. In theory it works good.

Would probably also work nicer if you could use LCL :)

Free Pascal 68k / Re: Description of Free Pascal
« on: January 17, 2017, 03:41:31 AM »
Thank you.

Interesting related project: Trinity
Trinity reached its goal. Function names and parameters have been made consistent for supported platforms (please go bug us if not the case). A new release of Free Pascal (e.g. 3.x or 4.x, whatever comes first) should incorporate those changes.

If you wish to have the fruit of that labour right now, then use Free Pascal from trunk. The only place where Trinity is still valid is when using Free Pascal 3.0 and/or 3.0.x, but i haven't updated Trinity for while now in order to reflect other changes (so Trinity is way behind Free Pascal trunk now).

Aros Vision / Re: Comparation of AROS API and 3.5 API
« on: January 17, 2017, 03:34:57 AM »
Library   AmigaOS 3.5   AROS
AmigaGuide   Yes   Yes, the library exist. But not one function is actually implemented. The practical answer is therefor no.

Proof can be read inside this directory. Just click the individual functions and read the implementation:
aros_print_not_implemented ("amigaguide/Name_of_Function");

Programming Tutorials / Re: C Chapter 3: Pointer variables
« on: May 28, 2016, 05:21:25 PM »
Thank you for the additional information itix.

Indeed the latter example using the double brackets is something i wondered about as well. It's obvious once you know it... as logic implies :-)

At least the behaviour of the comparison of the loop as showed, was certainly an eye opener for me and helped explain a few situations that i've been looking at in a strange way before.

It seems i still miss some fundamental understanding of how pointers work under certain circumstances and most of that flawed understanding seems to stem from default compiler/construct behaviour that is unknown to/for me (or have hard time finding/understanding documentation). And as murphy dictates, the moment you're starting to think that it would perhaps be ok to say "hey, i think i'm starting to grasp this stuff" .... something comes along that blows all your understanding/logic down the youtube channel :-)

Programming Tutorials / Re: C Chapter 3: Pointer variables
« on: April 29, 2016, 06:41:05 PM »
ah, ok (epiphany moment). The words "Also, the value assigned in an assignment statement is returned to the previous operation as a value of the same type." makes the behaviour plausible (for me at least).

Plausible, but i was not aware of that. Most of the code i port(ed) does not seem to rely on this behaviour so much (or more probably, overlooked by me :-) )

Yeah, it is a copy routine, more specifically the function strdup from gnu.

Speaking of precedence, i see both of you using a small change in order of events, but (and yes i could probably check that myself) is that actually true ? or is that why the statement is (or must be) enclosed in (double) brackets to make it work the way it does ?

e.g. The ++ operators are located at the right (so they come after the assignment), ergo the 'data' is copied first. Assuming the source pointer returned a #0 character then (without extra enclosed brackets) the while condition would become zero (= false) and exits the loop before even getting to the part of incrementing the pointers ? Or is the statement between the (first) while brackets always completely evaluated first (before determining what the while condition would become) ?

Truly sorry about the sidetrack, but very much appreciated for answering.

Programming Tutorials / Re: C Chapter 3: Pointer variables
« on: April 29, 2016, 12:14:07 PM »
Thank you SamuraiCrow.

Pointers, being a relatively easy type in concept, can cause many hazards (at least i find myself more cursing at them then they do good for me) :-)

Although the following question is perhaps more related to operators (and their precedence), i found myself rather puzzled at the following snippet:

Code: [Select]
while ((*ptr ++ = *orig ++));
Where orig is a * char (ergo null terminated) passed to a function and ptr holding a copy of that passed * char (memory was allocated for that using strlen + 1).

Seeing that, i am able to analyze (in pascal-ish form):
- ptr^ := orig^;  // copy single character from orig to ptr
- inc(ptr); // next ptr position in memory
- inc(orig);  // next orig position in memory

I do notice that the 'copy' statement is placed inside extra brackets, so that the statement produces a while condition that evaluates to be either true or false.

But, for the life of me, i can't seem to figure out when/why that while loop ends (yes i can run it and see, but am not able to evaluate it theoretically) :-S

Is that related to pointer, operator and/or while loop behaviour, or otherwise compiler/language specific behaviour  ?

How is one able to figure out the answer(s) to the questions that arises from such (relatively small) topics ?

F.i. i've tried to understand operator precedence, but the tables from existing documentation, only seems to contradict itself (imo that is). Mentioning  left-to-right, right-to-left is all nice, but when using larger statements, a simply soul like myself gets lost between choosing left or right :-S.

(if the above is not in sync with your tutor, then please ignore. no need to derail, although i do would like to understand the while loop condition, especially if related to pointer operation).

The following 'de-errored' and 'de-versioned' version of my example seems to compile without issues for me with additional -std=c89, -pedantic and -Wall options given to the gcc compiler, and also seems to compile ok with using -ansi option instead.

Code: (c) [Select]
#include <stdio.h>

int id;

struct id {
    int id;

struct foobar {
    int id;

struct barfoo {
    int id;

typedef struct {
    int id;
} boofar;

typedef struct {
    int id;
} farboo;

int main (void)
  struct id x1, x2;
  struct foobar y1;
  struct barfoo z1,z2;
  boofar myboofar;
  farboo myfarboo;   

  /* Assign a value to variable id (type int) */
  id = 1;

  /* define variables x1 and x2 of type id and assign a value to their id field member */ = 2; = 3; 

  /* define variable y1 of struct foobar and assing a value to the id field member */ = 4;

  /* define variables z1 and z2 of struct barfoo and assign a value to their id field member */ = 5; = 6;

  /* define variable myboofar of type boofar and assign a value to the id field member */ = 7;

  /* define variable mybarfoo of type farboo and assign a value to the id field member */ = 8;

  printf ("The value of          id=%d\n", id);
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;

  return 0;
Does this create a surprising effect on your end as well ?

fwiw: i'm also not interested in shooting holes in your tutor/believes. I just find this a bit peculiar behaviour of the compiler. I'm simply looking at it from my Pascal background: e.g. why offer constructs for defining 'variables' in a new separate namespace to end up treating them as being global.

I'll leave the topic/specifics concerning global struct field members alone, unless someone has/sees reason to pursue. e.g. no need for me to even further derail this thread (sorry about that, i simply wanted to give roMancer a helping hand there).

Please keep on continuing the good work !

What exactly are you confused about roMancer ?

You have defined/declared 5 different structures (2 of them using a direct variable/object(*) type name), as such they are all five treated differently. The fact that all your structures all have a member named id doesn't matter much. e.g. if you want to 'access' the id field you have to explicitly use the variable name to be able to access the actual value of the id field member.

e.g. the statement "That's right, member names are always global in C.", is imho incorrect. But, it might be SamuraiCrow used his words in a context i don't seem to fully grasp.

The one thing i am confused about (but i can imagine the compiler to know which one you meant when wanting to use), is that you have declared both a variable of type integer named id as well as a structural type with the same name. I would have expected the compiler to complain about that.

In case it helps: every time i need to know something about c i so a google search and add the word cplusplus to the search-term. has really nice online reference material and it helped me out a lot. In this particular case concerning structures there is a page here.

t.b.h. i find original gcc man pages a bit of a spartanic read (although in case of confusion i still use it to try make things clear for myself).

(*) oops, i read over those two declarations being typedef'ed. In that context it means that the structures when used can use the shortcut name.

Maybe/hopefully the following example (using your type definitions) make things more clear.
Code: (c) [Select]
#include <stdio.h>

int id;

struct id {
    int id;

struct foobar {
    int id;

struct barfoo {
    int id;

typedef struct {
    int id;
} boofar;

typedef struct {
    int id;
} farboo;

int main (void)
  // Assing a value to variable id (type int)
  id = 1;

  // define variables x1 and x2 of type id and assign a value to their id field member
  struct id x1, x2; = 2; = 3; 

  // define variable y1 of struct foobar and assing a value to the id field member
  struct foobar y1; = 4;

  // define variables z1 and z2 of struct barfoo and assign a value to their id field member
  struct barfoo z1,z2; = 5; = 6;

  // define variable myboofar of type boofar and assign a value to the id field member
  boofar myboofar; = 7;

  // define variable mybarfoo of type farboo and assign a value to the id field member
  farboo myfarboo; = 8;

  printf ("The value of          id=%d\n", id);
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;
  printf ("The value of\n",;

  return 0;

btw: are you using a good editor that has support for syntax highlighting c ? Because that can help tremendously when being new at a particular language. It highlights some of the keywords and other language specifics, and therfor can aid to understand what parts of your code exactly belongs to what.

PS: @admin: any chance of having support for syntax highlighting inside code-tags ? (or did i missed something in that it is already present ?)

edit2: added comments and reorganized a bit to match original definition order

Development Tools / Re: GNU GAS Immediate data misbehaving
« on: January 02, 2016, 06:44:57 PM »
Hi minty,

I'm a bit rusty with regards to asm, but i doubt that what you wrote was ever possible with any assembler.

Do me/yourself a favour and count the number of bytes that you are attempting to store there, and report back that number,

I'm fairly sure that at best, you'll end up in hell  ;)

edit: ah, i noticed too late you already posted the same question on eab (and got answers as well  :) )

Common standards / Re: MUI classes and their serial numbers
« on: December 20, 2015, 06:29:26 PM »

Splendid, as you've been able to answer all that i wanted to know for the time being. This is very much appreciated, so thank you very much for that.

Yes, indeed. i'm currently using the tag-id recognition for debugging purposes, and the other project that's in the process to be published sheds a light on configurations/preferences files (mui prefs files being one of them).

Pages: [1] 2 3 ... 13