English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 14 September 2013, 19:18   #21
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Age: 28
Posts: 1,255
Send a message via MSN to 8bitbubsy
Quote:
Originally Posted by Photon View Post
Here's the code from 1Klång which calculates it realtime to save 10 bytes (i.e. no table at all). D1 contains note 0-11 << 16 + octave 0-n on entry. I might use this in P61_Init actually to save some horrible includes and compile options

Code:
_baseC    =54229
_baseA    =64489
_octBase=_baseC

    move.w #_octBase,d0
    swap d1
    bra.s .jmpin
.octl2:
    mulu #61858,d0            ;exponential: 1/(2^(1/12))*65536
    swap d0
.jmpin:    DBF d1,.octl2
    swap d1                ;!hi word NOT clear. d1=octave

    addq.w #4,d1            ;shift 4 more (prec)
    lsr.w d1,d0            ;shift down by #octaves.
    move.w d0,_prds(a2)        ;prd
Hmm could you convert this to C for me? These "swap" instructions confuses me a bit, like how would I do this in C...
8bitbubsy is offline  
AdSense AdSense  
Old 14 September 2013, 23:59   #22
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
Oh. Well, you just multiply 54229 by 61858 / 65536 n times and halve the result o times, where n is the note 0-11 (0 is C, 1 is C#, etc) and o is the octave 0-5.


Code:
uint get1Note(n,o) {
	uint x=54229;
	for (int i=0;i<(n-1);i++) {
		x=(x*61858) >> 16
	}
	x=x >> (o+4); //shift to a range of usable octaves
	return x;
}

uint D1=get1Note(2,1);	//D-note in 2nd octave
"uint" is supposed to mean unsigned 32-bit integer to your compiler.

Last edited by Photon; 15 September 2013 at 12:10.
Photon is offline  
Old 15 September 2013, 00:17   #23
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Age: 28
Posts: 1,255
Send a message via MSN to 8bitbubsy
I made a little snippet out of your example:
Code:
#include <stdio.h>
#include <stdlib.h>

/* note = 0..35 (C-0 .. B-2) */
unsigned short noteToPeriod(char note)
{
    char i;
    char octave;
    unsigned int x;

    octave = note / 12;
    note %= 12;

    x = 54299;
    for (i = 0; i < note; ++i)
        x = (x * 61858) >> 16;

    x = (x + 4) >> octave;

    return x;
}

int main(int argc, char* argv[])
{
    char i;
    for (i = 0; i < 35; ++i)
        printf("%d\n", noteToPeriod(i));

    system("pause");

    return 0;
}
It outputs this:
54303
51255
48378
45663
43100
40681
38398
36243
34209
32289
30477
28766
27151
25627
24189
22831
21550
20340
19199
18121
17104
16144
15238
14383
13575
12813
12094
11415
10775
10170
9599
9060
8552
8072
7619

It should output something spanning from 856 to 113....
8bitbubsy is offline  
Old 15 September 2013, 01:28   #24
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
Yes, add 4 to oct (shift value) not to x

This still puts you 2 octs below the octave you need. 848 is correct, 856 is incorrect

Just put 856<<6 as start x for PT table
/ Sleepy Photon using mobile g'night

Last edited by Photon; 15 September 2013 at 01:34.
Photon is offline  
Old 15 September 2013, 02:29   #25
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Age: 28
Posts: 1,255
Send a message via MSN to 8bitbubsy
Quote:
Originally Posted by Photon View Post
Yes, add 4 to oct (shift value) not to x

This still puts you 2 octs below the octave you need. 848 is correct, 856 is incorrect

Just put 856<<6 as start x for PT table
/ Sleepy Photon using mobile g'night
848 is not right, 856 is.
8bitbubsy is offline  
Old 15 September 2013, 12:54   #26
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
Not if the # DMA cycles is 3546895 and the standard A is 440 Hz.

You can calculate it on your calculator: (the "8" is the number of samples in your waveform.)

notestep = 2^(1/12)=1.0594630943592952645618252949463

prdA = 3546895/440/8

prdA# = prdA/notestep

prdB = prdA#/notestep

prdC = prdB/notestep = 847.32138942651245571147266932506

baseC = prdC*64 = 54228.568923296797165534250836804 ~= 54229.

(Sorry for saying 848 is correct, I had gone to bed so I just halved one of the integers from your ouput there a couple of times I think. )

Last edited by Photon; 15 September 2013 at 13:04.
Photon is offline  
Old 15 September 2013, 19:14   #27
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Age: 28
Posts: 1,255
Send a message via MSN to 8bitbubsy
That's not what I mean. This is not the same values as in the PT period table. I want an accurate PT table output. :P
8bitbubsy is offline  
Old 15 September 2013, 20:31   #28
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
But the values were written by hand, not generated.

You've already spotted the manual errors they made (as, I think, has many a coder who wondered why the base note differed from the one in HRM, not that HRM is perfect either).

Unless the errors are consistent between octaves (higher octave values are all half of the lower), it'll be hard to "save some table words".

If you want compatibility, keep the original table with the errors (I did that in P6108). If you want to be correct, you have my generator (from 1Klång).

The "corrected wrong-base table" seems terrible to me, unless you can point out which of the values in the whole table is the correct one. You picked 856 and corrected the others, but this is arbitrary. What is to say 856 wasn't wrong and C# or A is the correct period to modify the others from?

So anyway, good luck and if I sound like I "come on strong" it's because I do care about some pet subjects on Amiga, music is one of them
Photon is offline  
Old 15 September 2013, 21:43   #29
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Age: 28
Posts: 1,255
Send a message via MSN to 8bitbubsy
Again, I strive for Amiga output accuracy, not note frequency accuracy. By errors, I mean values that mismatched those of the original bad PT table used in the original replayers.
I just wanted the smallest possible way to generate this bad table, that's it. I'm not saying that its values are correct, they are definitely wrong at some points.
8bitbubsy is offline  
Old 16 September 2013, 10:56   #30
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,495
Well, as I said, check if all matches in the higher octaves match if you shift down (halve) the lower ones.

Else you're out of luck.

You could do the above and perhaps it matches 95% of the values, and you could fix up the ones that don't match exactly by storing the "diff". I don't see how the diffs could be stored in less space, though.
Photon is offline  
Old 29 September 2017, 12:16   #31
Lisiak4
Registered User

 
Join Date: Sep 2017
Location: Czech Republic
Posts: 17
Quote:
Originally Posted by 8bitbubsy View Post

It's supposed to be like this:
Code:
    856,808,762,720,678,640,604,570,538,508,480,453,
    428,404,381,360,339,320,302,285,269,254,240,226,
    214,202,190,180,170,160,151,143,135,127,120,113,0,
Thanks, that's what I was looking for. So far I have values from 127 to 508. I already know how the values continue to reduce the frequency (period 508 and above)

With permission, this extended table will be written on the Czech forum too
Lisiak4 is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for the most accurate Paula audio emulation craig64 support.Other 12 03 November 2013 02:02
What is the most accurate speed test for WinUAE? Steve support.OtherUAE 5 04 December 2012 18:04
Calculating percentages in assembly aka bpm and period h0ffman Coders. Asm / Hardware 8 16 September 2012 18:49
Software for generating screenshots and videos Edi (FZ2D) Retrogaming General Discussion 5 08 April 2010 23:34
How accurate is the emulation? manicx support.WinUAE 26 07 July 2003 08:35

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 21:34.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Page generated in 0.18110 seconds with 14 queries