I think IRQs would not be strictly necessary for keyboard input, although you are probably right, some key buffering when the program is busy might be nice.
Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 106 Antworten
letzter Beitrag von daybyter am
gcc-6502 (english thread)
- Claus
- Erledigt
-
Problem: it seems the clock in VICE is stopped at 1:00:00
https://sourceforge.net/p/vice-emu/mailman/message/32213068/
, so I read 3600s here all the time. I tried to set the clock to 0:00:00 to start it, but no
luck so far. So the elapsed time of the program is always 0.
I need a good idea to circumvent this problem...
Edit: I don't have a good idea yet, but at least I managed to start the clock at 0:00:00
Edit2: we need some getchar() Method to wait for a keypress?
Edit3: I've just set the clock to 50 Hz for now. Maybe we should test for pal vs ntsc at startup and store this info somewhere. I think, there are several places, where we need this info?
-
Ok I managed to measure time for the first time. Unfortunately, I cannot display a long directly with sprintf ? %d and %l give a warning, and %ld displays a 'd' instead of the number. So I had to cast the time to int for now.
Due to the missing getchar function, I just added an infinite loop to stop the execution.
But the textmode() function doesn't really work anyway at the moment. It should reset the vic bank to the first bank again and set the screenbuffer to 1024 again etc.
-
Ok I managed to measure time for the first time.
Note that the tod clock may sometimes return incorrect values when reading it out the first time after having started it. To be on the safe side you should read it out twice in a row, discarding the first result.
-
Here is an article on the fast inverse square root on c64. He converts c64 float to ieee, does the magic trick and then converts back to c64 format:
http://www.lemon64.com/forum/v…8c76b776176f95a0d9a0ba497
We could do this in C, too?
-
Did some optimizations on the main program, a better sin method, a vertical line routine (should add a vertical, too), and some other minor stuff.
-
So I wondered about the fastest way to do a cbm float format => ieee 754 conversion.
I think, it could be done with 3 machine instructions?
rol <adr byte 3> ; sign bit goes to carry.
ror <adr byte 4> ; sign bit goes to bit 31 of the float. Lowest exp bit is in carry.
ror <adr byte 3> ; mantissa goes to org position and lowest exp bit is bit 7 now.So the ieee 754 => cbm float would be:
rol <adr byte 3>
rol <adr byte 4>
ror <adr byte 3>We could write those as an inline method, convert the floats where there are fast ieee 754, like the magic number trick for sqrt.
What do you think?
BTW: Claus, do you know, how to get the addies of those bytes? I don't have much about gcc inline assembler yet.
-
Hi daybyter,
here is an article about inline assembly in gcc.
This is also new to me, but you can have a look at my fork on github how I tried it for memset. I had to introduce a new register class for zeropage variables, so you need to sync with my gcc-src and rebuild everything to make this and the following work.
I think you need to do the following:
Alles anzeigenCodeSome explanation:
The __asm__ instruction will simply output text into the assembly file, that is why these strange "\n\t" are needed.
The __volatile__ will prevent the optimizer to remove the code, if it thinks the output is not needed.
The three colons at the end describe in- and output parameters as well as clobbered registers (in this case a zeropage address to output x, the same zeropage address to contain x as input, and the clobbered registers A, X and Y). The registers are only described by register classes, so the compiler can decide itself, which registers to use. We only specify, that they should be zeropage addresses by "Zp".
%0, %1, ... are used to reference registers that have already been specified in the part with the colons. We already said, x is supposed to be in some zeropage location. So if we use %0 in the following, we always refer to this same zeropage location (in both the assembly code and the remaining colon parts).
So far with extended assembly in a nutshell
-
I didn't want to include the conversion code into the sqrt?
Just replace this code:
Alles anzeigenCode- /**
- * Convert a CBM style 32 bit float to ieee format.
- *
- * @param floatAddy The address of the float to convert.
- */
- inline void convertCBM_2_IEEE754( unsigned char *floatAddy) {
- unsigned char new_byte2, new_byte3;
- // Just an ugly hack to get something going.
- // Should be done with a few machine instructions.
- new_byte3 = (floatAddy[2] & (unsigned char)0x7f) | ((floatAddy[3] & 1) << 7);
- new_byte2 = (floatAddy[3] >> 1) | (floatAddy[2] & (unsigned char)0x80);
- floatAddy[2] = new_byte2; // Set the new bytes.
- floatAddy[3] = new_byte3;
- }
-
Well, then it is the same, but using convertCBM_s_IEEE754 as function name
. -
Well, it doesn't seem to work anyway. I wrote me a small test program, and the sqrt results are not even close to the expected result. Have to do further reading, I guess...
-
Do you know, if the output of printf( "%f", <float>) works?
Looking at the results, I'm somewhat confused. sqrt(5) = 2,94...E-14 sqrt(11) = -3.06...E-34
I cannot believe, that the algo with the magic number can be so wrong, since it is so famous?
-
I also made an attempt at float-to-decimal printing code, but that turns out to be really hard (!) and the implementation is even buggier. (Try printf("%f", fpnumber); for a few different numbers.)
Seems there are some bugs
-
Yeah...the ieee conversion fails already...
Just wrote a test program to display the bitpatterns of each number, so I can reproduce this example: -
Ok, just did the conversion step by step and it seems the shift doesn't work?
i = 0011111000100000000000000000000
i >> 1 = 0000111110010000000000000000000?
What really astonishes me: the sqrt( 0.15625) is really almost perfect. But it doesn't work for almost any other number...
BTW: I thought literals are translated now to petscii?
-
BTW: I thought literals are translated now to petscii?
They are, but it seems you do not have the latest version from my fork (or even not the latest from puppeh's?). Did you fetch and pull the changes?
But there is indeed a problem I was not aware of: "%u" is converted to "%U" and then causes an "unknown conversion type character 'U' in format". Hm, it can be circumvented by using "%U" in the source code for now, but I guess the conversion needs to be a bit more intelligent...
EDIT: tiny modifications in sqrttest.c to make it work with the current head of my fork attached. No functional changes though.
-
I used puppeh's version (updated in between), since I thought he had your modifications in his version, too? Will start from scratch now with your sources.
The version with a union is in math,c, too. But so far it made no difference from the result. Just the missing warning. Will fix this, once it works.
-
Ok, still pulling your sources...but...
I got something working! I rewrote the sqrtf test loop about a bazillion times, until I realized, that the printf was the problem!
When wrote printf( "sqrt of %f is: %f", f, sqrtf(f)); the root was negative and all over the place.
When I wrote 2 printf statements to print f and the root, the result was ok.So I just copied the sqrt code from the sqrttest line by line into a function and ran the sincos test from there. And now I want to upload it, before I touch it again in any way! It is crap in many ways. The union is missing, the conversion in slow, ugly and complicated. But the result looks reasonable.
Maybe we should add some math code to git, so we have revision control?
Anyway...I am happy for now...
