flashjazzcat Posted March 12, 2015 Share Posted March 12, 2015 (edited) Just a heads-up and no disrespect to CA65, but MADS also supports relocatable object file linking. Edited March 12, 2015 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 12, 2015 Share Posted March 12, 2015 (edited) Hi! Just a heads-up and no disrespect to CA65, but MADS also supports relocatable object file linking. Sorry, I did not know that Does it also support multiple sections? Edited March 12, 2015 by dmsc Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 12, 2015 Share Posted March 12, 2015 Sorry, I did not know that Does it also support multiple sections? I have only used relocatable MADS binaries with a custom-written loader on the Atari. I've never used the linker; I just know it exists. Check out the "Relocatable Code" section here. The section at the end deals with linking. The download package also provides examples ("Libraries"). Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 12, 2015 Share Posted March 12, 2015 (edited) The Apple II version runs in about 32 minutes once compiled with Einstein. That's really no improvement and I think I used the right options for the best speed. Clearly, most of the time is spent in the floating point library but this should have eliminated the constant parsing that goes on at runtime. I'll double check the compiler options and try again if I messed up. I may try The Beagle Compiler to see if it's any better. I recompiled and retested. It completed the image in a little over 22 minutes. So almost 1/3 of the time spent drawing from BASIC is spent on interpreter activities like parsing, searching for lines, converting strings to numbers, etc... *edit* No code changes were required. Edited March 12, 2015 by JamesD 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 13, 2015 Share Posted March 13, 2015 (edited) I recompiled and retested. It completed the image in a little over 22 minutes. So almost 1/3 of the time spent drawing from BASIC is spent on interpreter activities like parsing, searching for lines, converting strings to numbers, etc... *edit* No code changes were required. I tried the Beagle Compiler V1.0 and it seems to be taking the same amount of time. The newer version supports a couple high speed math cards which would speed things up quite a bit but there is no emulation of those cards. *edit* It ended up taking a minute longer than Einstein The two math cards Beagle Compiler supports are: Innovative Systems' Floating Point Engine Applied Engineering's Fast Math Card The notes included with the compiler show some sample times for a hi-res plot and 2000 runs of the Savage Benchmark. The AE care shows execution times half of those without the card for the hi-res plot and the FPE card is about 8 times as fast as the standard compiled version. The Savage Benchmarks demonstrate an even greater difference over the standard compiled version. In theory, with the FPE card an Apple could complete this in under 3 minutes if that ratio held. Edited March 13, 2015 by JamesD Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 13, 2015 Share Posted March 13, 2015 Hi! It is the assembler from the CC65 suite, http://cc65.github.io/cc65/ IMHO the best assembler for the 6502 :) Seriously, the thing that makes ca65 stand apart from the rest is it support for object files and linking, that makes possible to structure big programs with multiple independent files. I've heard of MADS and ATASM too. How do those stack up? Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 13, 2015 Share Posted March 13, 2015 AtAsm is probably the most alike to Mac-65 but isn't well supported and earlier versions have some bugs making it IMO unusable. MADS is probably the most feature-rich cross assembler for 6502 and widely used. Source from AtAsm and Mac-65 can be ported over with fairly minimal effort. I don't think the English documentation for Mads is so great through. Might have changed since I last looked. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 13, 2015 Share Posted March 13, 2015 Avery's translated docs are perfectly usable, IMO. 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 13, 2015 Share Posted March 13, 2015 Which one gets hooked into Eclipse? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 13, 2015 Share Posted March 13, 2015 Which one gets hooked into Eclipse? Any of these: Quote Link to comment Share on other sites More sharing options...
+MrFish Posted March 13, 2015 Share Posted March 13, 2015 I don't think the English documentation for Mads is so great through. Might have changed since I last looked. Take a look for yourself: MAD-ASSEMBLER 1.9.5 - English Documentation 1 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 14, 2015 Share Posted March 14, 2015 Any of these: assemblers.PNG Quite a few... just not ca65 I see. Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 14, 2015 Share Posted March 14, 2015 Quite a few... just not ca65 I see. Just not the one I switched to. Argh Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 14, 2015 Share Posted March 14, 2015 Just not the one I switched to. Argh You could switch again... it might not be that much trouble if the capabilities and syntax are similar enough (if not identical). Then again, if you're happy where yer at that's fine too. I did some reading on the cc65 site and it seems like a nice suite of programs. Quote Link to comment Share on other sites More sharing options...
devwebcl Posted March 14, 2015 Share Posted March 14, 2015 By the way, in the Atari you can turn the screen DMA off and turn it on only at the end, reducing the overhead, then the runtime would be only 16 seconds. The screen is black, so I assume you are using this optimization already. Do you have a version, where we can watch the image being rendered ? Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2015 Share Posted March 15, 2015 Hi! The screen is black, so I assume you are using this optimization already. Do you have a version, where we can watch the image being rendered ? You are right, I attached the wrong XEX (but the zip contained the correct source). This is the last, complete, version. It is 765 bytes. fedora.xex fedora-asm.zip 3 1 Quote Link to comment Share on other sites More sharing options...
devwebcl Posted March 15, 2015 Share Posted March 15, 2015 Hi! You are right, I attached the wrong XEX (but the zip contained the correct source). This is the last, complete, version. It is 765 bytes. Cool, that's a nice demo. by the way, I can see the final image is slightly different to the original image at the boundaries (on the top of the hat). this happens to the apple2 and other versions as well (I did a Java version and also is different), I haven't checked the code for the difference, but I can assume is related to SQR or SIN functions. Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 15, 2015 Share Posted March 15, 2015 Hi!, Cool, that's a nice demo. by the way, I can see the final image is slightly different to the original image at the boundaries (on the top of the hat). this happens to the apple2 and other versions as well (I did a Java version and also is different), I haven't checked the code for the difference, but I can assume is related to SQR or SIN functions. Yes, I noticed it too, but it only appears in the Atari version, I think it is a problem with the way BASIC rounds the floating point values to draw the pixels. There are one difference in the algorithm: - In the original the loop ends at a precomputed coordinate, with the variable XL=INT(SQR(SX*SX-ZS)+0.5). - In this version, I rearranged this as: SX*SX = XL*XL + ZS, so the condition is "X*X + ZS >= SX*SX". This causes a difference in the "ring" at the border of the figure. 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 15, 2015 Share Posted March 15, 2015 (edited) I tried the Beagle Compiler V1.0 and it seems to be taking the same amount of time. The newer version supports a couple high speed math cards which would speed things up quite a bit but there is no emulation of those cards. *edit* It ended up taking a minute longer than Einstein The two math cards Beagle Compiler supports are: Innovative Systems' Floating Point Engine Applied Engineering's Fast Math Card The notes included with the compiler show some sample times for a hi-res plot and 2000 runs of the Savage Benchmark. The AE care shows execution times half of those without the card for the hi-res plot and the FPE card is about 8 times as fast as the standard compiled version. The Savage Benchmarks demonstrate an even greater difference over the standard compiled version. In theory, with the FPE card an Apple could complete this in under 3 minutes if that ratio held. I looked up the FPE card and it has a 68881 or 68882 Math Coprocessor on it. Single precision IEEE floats are one less byte in length that Applesoft and double precision are twice as long so there would be some overhead in converting. But it shows the potential for such an upgrade. Edited March 15, 2015 by JamesD Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 15, 2015 Share Posted March 15, 2015 You could switch again... it might not be that much trouble if the capabilities and syntax are similar enough (if not identical). Then again, if you're happy where yer at that's fine too. I did some reading on the cc65 site and it seems like a nice suite of programs. I really wanted the ability to make libraries of code and use a linker to join everything. That's how I do things for work and to me it doesn't make any sense to do it any other way. Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 15, 2015 Share Posted March 15, 2015 I really wanted the ability to make libraries of code and use a linker to join everything. That's how I do things for work and to me it doesn't make any sense to do it any other way. That's a good point too. It all depends on what features are the most valued by each person. Quote Link to comment Share on other sites More sharing options...
devwebcl Posted March 17, 2015 Share Posted March 17, 2015 Hi!, Yes, I noticed it too, but it only appears in the Atari version, I think it is a problem with the way BASIC rounds the floating point values to draw the pixels. There are one difference in the algorithm: - In the original the loop ends at a precomputed coordinate, with the variable XL=INT(SQR(SX*SX-ZS)+0.5). - In this version, I rearranged this as: SX*SX = XL*XL + ZS, so the condition is "X*X + ZS >= SX*SX". This causes a difference in the "ring" at the border of the figure. actually they are quite different: http://manillismo.blogspot.com/2015/03/fedora-hat-diferencias.html Quote Link to comment Share on other sites More sharing options...
JamesD Posted December 16, 2015 Share Posted December 16, 2015 (edited) Laser 500 code. Notice I put the graphics mode and color setting before the loop. This change will make pretty much every version I posted run faster. 100 DIM RR(320) 110 GR 4 : COLOR 3,0,0 120 FOR I=0 TO 320:RR(I)=193:NEXT I 130 XP=144:XR=4.71238905:XF=XR/XP 140 FOR ZI=64 TO -64 STEP -1 150 ZT=ZI*2.25:ZS=ZT*ZT 160 XL=INT(SQR(20736-ZS)+0.5) 170 ZX=ZI+160:ZY=90+ZI 180 FOR XI=0 TO XL 190 XT=SQR(XI*XI+ZS)*XF 200 YY=(SIN(XT)+SIN(XT*3)*0.4)*56 210 X1=int(XI+ZX):Y1=int(ZY-YY) 220 IF RR(X1)>Y1 THEN RR(X1)=Y1:SET(X1,Y1) 230 X1=ZX-XI 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:SET(X1,Y1) 250 NEXT XI:NEXT ZI 260 GOTO 260 Edited December 16, 2015 by JamesD 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted December 16, 2015 Share Posted December 16, 2015 Laser 500 code. Notice I put the graphics mode and color setting before the loop. This change will make pretty much every version I posted run faster. ... Except it's not actually inside the loop so it doesn't matter. <groan> Quote Link to comment Share on other sites More sharing options...
JamesD Posted September 13, 2017 Share Posted September 13, 2017 (edited) MC-10 using standard MICROCOLOR BASIC. This is a text screen really and 64x32..A video of it drawing. The left side is regular Microcolor BASIC and the right side is my enhanced version. 100 SX=26:SY=8:SZ=10:CX=64:CY=32 110 DIM RR(CX) 120 FOR I=0 TO CX:RR(I)=CY:NEXT I 130 CLS 0 140 CX=CX*0.5:CY=CY*0.46875:FX=SX/64:FZ=SZ/64 150 XF=4.71238905/SX 160 FOR ZI=64 TO -64 STEP -4 170 ZT=ZI*FX:ZS=ZT*ZT 180 XL=INT(SQR(SX*SX-ZS)+0.5) 190 ZX=ZI*FZ+CX:ZY=CY+ZI*FZ 200 FOR XI=0 TO XL 210 XT=SQR(XI*XI+ZS)*XF 220 YY=(SIN(XT)+SIN(XT*3)*0.4)*SY 230 X1=XI+ZX:Y1=ZY-YY 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:SET(X1,Y1,1) 250 X1=ZX-XI 260 IF RR(X1)>Y1 THEN RR(X1)=Y1:SET(X1,Y1,1) 270 NEXT XI:NEXT ZI 280 IF INKEY$="" THEN 280 And Jim Gerrie altered it to use 64x48 graphics. 0 DIMLU(1,2):GOSUB9000:GOTO100 3 CLS0:POKE49151,28:RETURN 4 POKE49151,0:CLS:RETURN 5 XX=INT(X1/2):YY=INT(Y1/3):BY=MC+XX+YY*32:VL=LU(INT(X1-XX*2),INT(Y1-YY*3)):POKEBY,VLORPEEK(BY):RETURN 6 XX=INT(X1/2):YY=INT(Y1/3):BY=MC+XX+YY*32:VL=LU(INT(X1-XX*2),INT(Y1-YY*3)):POKEBY,(NOT(NOT(VLORPEEK(BY))ORVL)):RETURN 100 SX=28:SY=10:SZ=14:CX=64:CY=48 110 DIM RR(CX) 120 FOR I=0 TO CX:RR(I)=CY:NEXT I 130 CLS0:POKE49151,68 140 CX=CX*0.5:CY=CY*0.46875:FX=SX/64:FZ=SZ/64 150 XF=4.71238905/SX 160 FOR ZI=64 TO -64 STEP -4 170 ZT=ZI*FX:ZS=ZT*ZT 180 XL=INT(SQR(SX*SX-ZS)+0.5) 190 ZX=ZI*FZ+CX:ZY=CY+ZI*FZ 200 FOR XI=0 TO XL 210 XT=SQR(XI*XI+ZS)*XF 220 YY=(SIN(XT)+SIN(XT*3)*0.4)*SY 230 X1=XI+ZX:Y1=ZY-YY 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:GOSUB5 250 X1=ZX-XI 260 IF RR(X1)>Y1 THEN RR(X1)=Y1:GOSUB5 270 NEXT XI:NEXT ZI 280 IF INKEY$="" THEN 280 290 SOUND1,1:END 9000 LU(0,0)=32:LU(0,1)=8:LU(0,2)=2:LU(1,0)=16:LU(1,1)=4:LU(1,2)=1:MC=16384:RETURN Edited September 13, 2017 by JamesD 4 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.