![]() |
not sure what it is bug/feature/me - Printable Version +- Forum (https://www.boriel.com/forum) +-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12) +--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11) +---- Forum: Help & Support (https://www.boriel.com/forum/forumdisplay.php?fid=16) +---- Thread: not sure what it is bug/feature/me (/showthread.php?tid=473) |
not sure what it is bug/feature/me - frisian - 06-29-2012 First something easy I spotted in DRAW.ASM, there are two EQU's that point to the same address Code: LOCAL __PIXEL_ADDR one of those two can be removed. The program I work on I typed in long ago (needless to say it contains typo's in the data) you can find a copy in WOS it's called PIANOLA. http://www.worldofspectrum.org/infoseekid.cgi?id=0008549 In trying to speed up this program i ran into some problems. The program plays music by machine code, the information is transferred by means of reading data into a string. Compiling the hole program is not my intention, but some drawing and printing to the screen can surly be sped up by compiling that part. There is a difference in ZX Basic and the Compiler in handling float's in the PLOT and DRAW statements. It draws 2 figure's with the help of following code Code: 2030 FOR i=8 TO 215 STEP 207 1. first add .5 (round off the number) 2. INT must work like in ZX Basic (3.9 gives 3, -3.9 must give -4) Code: dim p,q,c,s as float This code will give the same figure as ZX Basic. I think a closer look into how ZX Basic works using float's in PLOT and DRAW and how the are converted to integers is needed Now my code compiled without error and it's output looked like the normal basic version. The final piece of code. Code: dim p,q,c,s as float The compiled piece of code worked but it corrupted something so the running of the normal basic part was not what it should be. First I load the program, RUN, the program loads the two piece of machine code and runs normal until it returns from the first time it used the compiled code, it then needs to print the title of the music piece on the screen, but here go things wrong, instead it prints what looks likes a piece of listing from the basic program, it seems that some where something is corrupted. But now comes the weird part, if I BREAK the program and let it RUN without loading the two pieces of machine code, it works as it should with out a problem. :?: I have tried out something, and found at last the line that causes the problem. If I REM this line out PRINT OVER 1; BRIGHT 1; INK p1; PAPER 4;AT i,1+(i=5);h$;AT i,27+(i=5);f$ there is no problem, or replacing f$ and h$ with " " will also work. The problem seems to be with f$ and h$ or I am doing something wrong. (I rewrite the code, now I know what will work) Sorry for the somewhat long posting. Regards Frisian. Re: not sure what it is bug/feature/me - boriel - 06-29-2012 Your code runs OK in my emulator. I don't see any corruption. If you are adding extra machine code during runtime (por POKES or UDG), you might be corrupting the heap (used mainly for string -alphanumeric- variables). To use UDG use --spectrum, or better ask here the other (best) way to do it. If you need to load machine code at any location, there are other methods, like using a malloc for reserving such space, or using asm directives with DEFB. Can you upload a screenshot of the corruption? Re: not sure what it is bug/feature/me - boriel - 06-29-2012 frisian Wrote:Both give a different figure. It took me some days before I figured out that the calculations in the compiled version where correct, converting the float into a integer screwed things up.This bug is marked for correction. INT will behave as Sinclair BASIC, since CAST(Integer, <float value>) will also perform the truncation. So we'll have both choices. Better comment this issue in the bug thread (your first post). |