CSDb - Latest Forum posts

CSDb Entries: Release id #102361 : arise #$10 /Kisiel

Kisiel — Wed, 08 Feb 2012 23:45:27 +0100

anyone who is not rabbit friends use google translate:
"Nie życzę sobie żeby to siedziało na torrentach. I chuj."
as said wackee.
So the concept of this release is to give the stuff only for "right one" members of the CSDB community.

I think this release breaks CSDB rules, EoD is for slum dogs, arise product is for the chosen ones.
For me is new history of releases on CSDB.

C64 Coding: Kick Assembler Thread 2 /McKrackeN

McKrackeN — Wed, 08 Feb 2012 23:43:03 +0100

Yes!! That's it!! Thanks for your help and for this amazing compiler!!

C64 Coding: Kick Assembler Thread 2 /Slammer

Slammer — Wed, 08 Feb 2012 23:35:15 +0100

I Just tried it and it works fine here. My guess is that you define the macro+constant inside one scope and execute your macro outside the scope. Eg. if you start you system.asm file with a .filenamespace directive.

C64 Coding: Fractional Scaling - Math problem /JackAsser

JackAsser — Wed, 08 Feb 2012 22:13:41 +0100

Well. I said you should use 16-bit 8.8 fix point tables! Hence:

round(65535/14) = 4681

4681 * 7 = 32767 in 8.8 fix point (0x7fff) or with decimal point: 7f.ff
As you see, to properly round this value to eight bits you simply add 0.5 (0x80) => 7fff + 0x80 = 0x807f and truncate the top 8-bits (0x80).

Volia?

C64 Coding: Fractional Scaling - Math problem /WVL

WVL — Wed, 08 Feb 2012 21:57:35 +0100

hehe, accuracy bites you in the ass :)

Have you thought about using logarithms or exponentials for your calculation? Normally these kill your resolution, but sometimes they help out wonderfully because with them you can have a changing accuracy, depending on the values you're working on..

let's say your denominator is very big (100-128 or something), then your calculation is a*128/demon. -> 128/denom is very close to 1, so a good resolution for big denominators, even with just 8 bit numbers.

Now, if your demoninator is very small, you're in trouble.

Anyway, think about doing the calc with exp or log, and see how that changes things :)

C64 Coding: Fractional Scaling - Math problem /TWW

TWW — Wed, 08 Feb 2012 21:50:21 +0100

Alright, thanx, I see that we are more or less on about the same thing :-)

However I have an issue with accuracy which I want to flag:

Let's say you have the fraction 7/14 which you want to scale to x/255.

Calculating it directly it gives us x = 128 (rounded).

If we use a lookup table with 2 decimals we will get:

255/14 = 18,21

If we then multiply this with 7 we get the new numerator = 127,47 which unfortunately rounds to 127.

If we increase the amounts of decimals in our lookup table (8 bits is getting awfully small right about now) to 3 bits we get:

255/14 = 18,214

multiply with the numerator: 18,214 * 7 = 127,498 still not good enough.

So let's go crazy and do 4 decimals:

255/14 = 18,2143 (Rounded)
which gives: 18,2143 * 7 = 127,5001 and we finally got it right, right?

let's increase the accuract to 7 decimals and we get: 18,2142857 x 7 = 127,4999999. Down on our asses again.

This inflicts other fractions as well but here where 4 decimals makes it right, on other fractions this makes it wrong. The rounding makes it fokked.

So if I want it accurate, I think the way to go is via multiply table and do a 16by8-bit division which retains the accuracy better...

Or maybee I should just go take a caiphirinha and chill 8-D

C64 Composing: How to make crazy-comet slides in Goattracker /Magnar

Magnar — Wed, 08 Feb 2012 20:36:28 +0100

Hi all,
Anyone know of a easy way to make a effect of the popular Rob Hubbard "crazy comet" sliding sfx in a instrument or with pattern commands?

I'm also wondering if there is anyone that have a nice Goattracker way of making the modular effects used in Jeroen Tel's Cybernoid 2 title song?

Maybe there exists some GT sng file convertions of these two songs?

/Magnar

C64 Coding: Fractional Scaling - Math problem /JackAsser

JackAsser — Wed, 08 Feb 2012 19:42:11 +0100

You said:

Quote:

Say you got the fraction 44/93.

Then you want to scale it to a predetermined denominator of 128 which would give: 61/128 (rounded).

61 is found by calculating 44*128/93.

Hence 61 is found by calculating numerator*128/denominator

Basically you multiply by 1/x (in your case 128/x because you need that scale) which is same as dividing by x in the first place.

Regarding 16-bit multiplications using square sum tables, no problems, check out the wiki article.

/Andreas

C64 Coding: IDE64 old versions and stack /cadaver

cadaver — Wed, 08 Feb 2012 18:42:59 +0100

Thanks for info!
Ah, actually I was wrong, it was not overwriting/restoring stack, but the $02a7-$0314 area where I also had variables used by IRQs. In this case I could swap them with some noncritical variables used only by the main program.

CSDb Discussions: Problem transferring discs to d64/PC /Groepaz

Groepaz — Wed, 08 Feb 2012 18:18:01 +0100

Quote:

OpenCBM? Ah yes, back to a PC with board with a parallel port that works those stoneage cables..

you can use opencbm also with "zoomfloppy", which connects to an usb port.
Quote:

Which reverts me again to why we're not able to do this via 1541U after all.. *sigh*

i blame the broken ethernet of the 1541u - it never worked stable for me with it either (while it worked perfectly fine with rr+rrnet using the same drive and c64).

C64 Coding: Kick Assembler Thread 2 /McKrackeN

McKrackeN — Wed, 08 Feb 2012 17:29:21 +0100

Thanks for your help!

I think i'm declaring the constant before using the macro but i'm still getting the compiler error.

I have two separate files. One called system.asm and the other test.asm.

// System.asm

.const MyConst = $d012

.macro myMacro(val)
{
        ldy #val
	sty MyConst
}

Then in the test.asm:

// test.asm
.import source "system.asm"

// some code

:myMacro(0)

CSDb Discussions: Problem transferring discs to d64/PC /dano

dano — Wed, 08 Feb 2012 17:15:03 +0100

OpenCBM? Ah yes, back to a PC with board with a parallel port that works those stoneage cables..

Is there fullfeatured useful GUI (allowing masstransfer)?

Which reverts me again to why we're not able to do this via 1541U after all.. *sigh*

C64 Coding: Kick Assembler Thread 2 /Slammer

Slammer — Wed, 08 Feb 2012 16:55:59 +0100

Constants are visible after you have defined them. So the example you give, will work if you declare your const before you use the macro:

:MyMacro($32) 	// This won't work
.const MyConst = $d012
:MyMacro($32) 	// This will work
.macro myMacro(val)
{
    ldy #val
    sty MyConst
}

However, labels can be seen in the whole scope so they can be used before they are declared:

:MyMacro($32) 	// This will work
.label MyLabel = $d012
.macro myMacro(val)
{
    ldy #val
    sty MyLabel
}

C64 Coding: Fractional Scaling - Math problem /TWW

TWW — Wed, 08 Feb 2012 16:47:21 +0100

I'm trying to wrap my head around your post.

If the original denuminator is say 10 then calculating:

table[10] = round((128/10)*256) = 3277

If we then put this into:

numerator' = round(numerator * table[denominator]);0 // 0 decimals

I don't see how this gives the new numinator? I think I must have missunderstood you here.

I did some calculations and found that:

table[x] = round(256/denominator);3 // 3 decimals

then:

numerator' = numerator * table[x]

will give an accurate result. Looks like we're not getting around the 16 bits when doing the FP multiplication though. what will that do to the mult. tables?

CSDb Discussions: Problem transferring discs to d64/PC /Groepaz

Groepaz — Wed, 08 Feb 2012 16:40:30 +0100

Quote:

opencbm does not support mass transfers by default and also not the fastest one.

when using warpmode opencbm should be pretty much exactly as fast as warpcopy (around 30 seconds per disk)

CSDb Discussions: Problem transferring discs to d64/PC /dano

dano — Wed, 08 Feb 2012 15:16:53 +0100

FYI: I didn't that much information from Graham, but his answers read like it might by a bug/problem with WarpCopy not beeing able to properly resync on the disc after one fast-iec read when a disc is not formatted via CBM functions.

Someone might correct me, but i can't tell how to fix this problem as it seems not to be related with a distinct drive(setup).

In the end it means further seeking and waiting for a decent solution that works. What is the problem in the end will be uncovered forever i guess..

C64 Coding: IDE64 old versions and stack /Grue

Grue — Wed, 08 Feb 2012 14:01:34 +0100

I cannot speak for many, but all other finnish ide64 users I know do use already 0.9x series.

C64 Coding: Kick Assembler Thread 2 /McKrackeN

McKrackeN — Wed, 08 Feb 2012 13:56:00 +0100

Hey ppl! I have a newbie question: is there a way to use constants inside a macro?

For instance, I need to be able to do something like this:


.const MyConst = $d012

.macro myMacro(val)
{
        ldy #val
	sty MyConst
}

But I get an error when compiling.

Thanks in advance! :)

C64 Coding: IDE64 old versions and stack /cadaver

cadaver — Wed, 08 Feb 2012 12:29:52 +0100

Hi,
I'm experimenting with IDE64 loading that allows IRQs to run. Actually that's working just as expected, but as my guinea-pig I'm using Metal Warrior 4, and it has very limited RAM left so it uses the stack for the spritemultiplexer IRQ data.

When starting to load a file, old versions (< 0.9) of IDEDOS seem to momentarily overwrite the stack, then restore it. This has the effect of all sprites flashing off for a couple of frames.

On newer IDEDOS this does not happen.

I'd like to know, is there still a large number of < 0.9 firmwares in use, or do people generally update?

C64 Coding: Fractional Scaling - Math problem /JackAsser

JackAsser — Wed, 08 Feb 2012 08:51:15 +0100

numerator´ = numerator * table[denominator]

A 8.8 fixpoint table with 128 entries should be sufficient.

table[x] = round((128/x)*256)

Then use this http://codebase64.org/doku.php?id=base:seriously_fast_multiplic.. to multiply fast.

C64 Coding: Fractional Scaling - Math problem /TWW

TWW — Wed, 08 Feb 2012 01:45:07 +0100

Well to tel lthe truth it's any combination of numbers between 1/1 -> 127/127 which get's scaled into xx/255.

There is no pattern or easy way to predict the next fraction unless I make a seperate routine for all the calculations (which will suck mem).