+Vorticon Posted January 20, 2015 Share Posted January 20, 2015 I'm not sure your code is working. This looks more right to me: PDT EQU >1800 . . . MOV R4,R0 AI R0,PDT BLWP @VSBR SOCB @BITPOS(R5),R1 BLWP @VSBW * Write the modified byte back to the PDT You did not set up R1 for VSBR. Where will the VDP read value go? You cannot use a label for AI as far as I remember. In the SOCB line, R1 will contain the address of the byte read, not the actual value. Which part of my code seems wrong to you? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 20, 2015 Share Posted January 20, 2015 (edited) You did not set up R1 for VSBR. Where will the VDP read value go? You cannot use a label for AI as far as I remember. In the SOCB line, R1 will contain the address of the byte read, not the actual value. Which part of my code seems wrong to you? Actually, that is incorrect. the single-byte read and write operate on the high byte of R1. It is the multi-byte read/write that need an address. Also, the PDT must reside at >0000 or >2000 in VRAM, not >1800. >1800 is the character name table. Your code will work with the following modifications: PDT EQU >2000 * Must be >0000 or >2000 . . . MOV R4,R0 * VRAM address of PDT AI R0,PDT * pattern byte to R0 BLWP @VSBR * High byte of R1 now has the needed PDT byte SOCB @BITPOS(R5),R1 * OR the appropriate pattern with the PDT byte BLWP @VSBW * Write the modified byte back to the PDT Note also the change in the PDT-labeled and MOV instruction lines. [EDIT: Basically, it is Rasmus’ code with the EQU change.] ...lee Edited January 21, 2015 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 20, 2015 Share Posted January 20, 2015 (edited) ... You cannot use a label for AI as far as I remember. ... A label can be used as an immediate value (one that appears in assembled code immediately after an immediate instruction) because its value cannot be changed from its assembled value. What you cannot use is indirection such as @BITPOS. ...lee Edited January 20, 2015 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 20, 2015 Share Posted January 20, 2015 Ah! Thanks for the clarifications. I was doing all this from memory on the fly and it's been a while since I programmed in assembly. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 21, 2015 Share Posted January 21, 2015 MOV @PDT(R4),R0 Lee, that won't work. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 21, 2015 Share Posted January 21, 2015 MOV @PDT(R4),R0 Lee, that won't work. Oops! Yeah, your code is it. Only change is PDT EQU >2000. ...lee Quote Link to comment Share on other sites More sharing options...
apersson850 Posted January 24, 2015 Share Posted January 24, 2015 (edited) LOGO had plot functions, using the turtle (turtlegraphics). But since it was simulating bit-map mode within the standard mode, it "ran out of ink" when there weren't any characters left to define patterns in. Normally, UCSD Pascal didn't allow for the bit map mode to be used, but it was possible to tweak the operating system to make that possible. My own line drawing algorithm wasn't as efficient as Bresenham's algorithm though. A day when I have nothing else to do, I'll fire up the TI and see how much of a performance improvement changing the algorithm would do. Edited January 24, 2015 by apersson850 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 24, 2015 Share Posted January 24, 2015 I tried playing with the LOGO draw functions, but they are pretty slow unfortunately. Fun though Quote Link to comment Share on other sites More sharing options...
bfollett Posted February 22, 2015 Author Share Posted February 22, 2015 (edited) Everyone did such a great job getting the TI to run the Mad magazine demo using various TI programming languages. I thought I'd post a challenge for another Atari demo conversion. This one actually took about 3 hours to run with Atari Basic and produced an on screen hat. The Atari's hires mode(Graphics 8+16) is 320 pixels so some variables might need a little tweaking to keep the results under 256 pixels for the TI. 140 GRAPHICS 8+16:SETCOLOR 2,0,0150 XP=144:XR=4.71238905:XF=XR/XP160 FOR ZI=-64 TO 64170 ZT=ZI*2.25:ZS=ZT*ZT180 XL=INT(SQR(20736-ZS)+0.5)190 FOR XI=0-XL TO XL200 XT=SQR(XI*XI+ZS)*XF210 YY=(SIN(XT)+SIN(XT*3)*0.4)*56220 X1=XI+ZI+160:Y1=90-YY+ZI230 TRAP 250:COLOR 1:PLOT X1,Y1240 COLOR 0:PLOT X1,Y1+1:DRAWTO X1,191250 NEXT XI:NEXT ZI260 GOTO 260 More info here: http://j-b.livejournal.com/419883.html Bob Edited February 22, 2015 by bfollett 2 Quote Link to comment Share on other sites More sharing options...
Stuart Posted February 22, 2015 Share Posted February 22, 2015 (edited) Everyone did such a great job getting the TI to run the Mad magazine demo using various TI programming languages. I thought I'd post a challenge for another Atari demo conversion. This one actually took about 3 hours to run with Atari Basic and produced an on screen hat. The Atari's hires mode(Graphics 8+16) is 320 pixels so some variables might need a little tweaking to keep the results under 256 pixels for the TI. 3 hours! Was it actually plugged in? I actually used this 'graph' as a benchmark for various configurations of TMS99xx processors running a port of the Powertran Cortex BASIC. Quickest was 1 minute 17 seconds. [OK, OK, I suspect yours is a little more detailed. And it's not symmetrical so you have to calculate both the left and right sides. ] Details at [http://www.avjd51.dsl.pipex.com/tms99110_breadboard/tms99110_breadboard.htm] and scroll right to the bottom of the page. A copy of the program for the BBC Micro here: [http://41j.com/blog/wp-content/uploads/2012/03/beebug_3dobj.jpg]. Slightly different parameters for the graph again. Edited February 22, 2015 by Stuart Quote Link to comment Share on other sites More sharing options...
bfollett Posted February 22, 2015 Author Share Posted February 22, 2015 3 hours! Was it actually plugged in? Atari definitely doesn't have the fastest math routines and that's unfortunately mainly what the program does. There were fast math chips available. While researching those I came across this page: http://www.atarimagazines.com/v1n4/fastchip.html It has a couple of short Basic benchmark routines so I typed the second one into Classic 99 and the TI faired pretty well, somewhere around 17 seconds which beat quite a few of the other computers listed. Also probably due to its 16 bit processor it had the most accurate value for the variable S. Take a look Bob Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted February 22, 2015 Share Posted February 22, 2015 Everyone did such a great job getting the TI to run the Mad magazine demo using various TI programming languages. I thought I'd post a challenge for another Atari demo conversion. This one actually took about 3 hours to run with Atari Basic and produced an on screen hat. The Atari's hires mode(Graphics 8+16) is 320 pixels so some variables might need a little tweaking to keep the results under 256 pixels for the TI. [sNIP]More info here: http://j-b.livejournal.com/419883.html Bob A guy sitting around me saw that, and after I explain it was generated by an Atari computer he says, "Wow, those old computers can do that?" He meant it. He just gets the stink eye from me. Maybe I will culture him later by pulling up some old-school demos on YouTube. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 22, 2015 Share Posted February 22, 2015 OK, here's a version for ABASIC on the Geneve: Time is 58 min. As you see I used a scaling of 150% on the width (line 220). 140 CALL SCREEN(2) :: CALL GRAPHICS(3,3) 150 XP=144 :: XR=4.71238905 :: XF=XR/XP 160 FOR ZI=-64 TO 64 170 ZT=ZI*2.25 :: ZS=ZT*ZT 180 XL=INT(SQR(20736-ZS)+0.5) 190 FOR XI=0-XL TO XL 200 XT=SQR(XI*XI+ZS)*XF 210 YY=(SIN(XT)+SIN(XT*3)*0.4)*56 220 X1=XI*1.5+ZI+256 :: Y1=90-YY+ZI 230 CALL DCOLOR(16,1) :: CALL POINT(1,Y1,X1) 240 CALL DCOLOR(2,1) :: CALL POINT(1,Y1+1,X1) :: CALL DRAWTO(1,211,X1) 250 NEXT XI :: NEXT ZI 260 GOTO 260 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 22, 2015 Share Posted February 22, 2015 (edited) As for the BASIC Fastchip benchmark, here are the results for the Geneve (ABASIC): Time = 7.34 (taken by hand, maybe 7.1 in reality) S = 503.5438022 X = 1.23 (running on MESS, but the times should be pretty much the same on the real iron) Edited February 22, 2015 by mizapf Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 23, 2015 Share Posted February 23, 2015 (edited) I ported to TI BASIC, as with the MAD one. I was able to find a couple of tiny optimizations in my plot function (and the line draw, but this code doesn't use that). The reason for the drawing was mysterious to me at first, but I finally worked it out. Originally I was going to just go for the wireframe approach, but I finally figured out that the line draw provides a crude hidden-surface removal and gives the nice 3D effect: 230 TRAP 250:COLOR 1:PLOT X1,Y1 <--- plots the pixel in white 240 COLOR 0:PLOT X1,Y1+1:DRAWTO X1,191 <--- erases from one below the pixel to the bottom of screen for hidden surface removal That forced me to write an 'unplot' function, and I cheat a bit and let it early out when it finds characters it doesn't own, since I can't fill the screen top to bottom! The code is running and is going to take a long time I added clock support so I could get a final value out of it. I'm running at 50% scale but I don't think it will be able to draw it all even with that... still, we'll let it run. 9 DIM COLS(255) 10 DIM CC$(126),HPAT$(3),UPAT$(3) 11 FOR A=0 TO 126 12 CC$(A)="0000000000000000" 13 NEXT A 15 OLDMR=-1 17 OLDDR=-1 19 OLDCH=33 20 CURCHAR=33 25 STARTCHAR=33 30 HEX$="0123456789ABCDEF" 32 HPAT$(0)="89ABCDEF89ABCDEF" 34 HPAT$(1)="45674567CDEFCDEF" 36 HPAT$(2)="23236767ABABEFEF" 38 HPAT$(3)="1133557799BBDDFF" 50 GOTO 5000 99 REM PLOT A DOT AT DOTCOL,DOTROW (0-BASED) 100 MR=INT(DOTROW/8)+1 130 MC=INT(DOTCOL/8)+1 135 IF (MR=OLDMR)*(MC=OLDMC)THEN 150 140 CALL GCHAR(MR,MC,CH) 145 OLDMR=MR 146 OLDMC=MC 150 IF CH>=STARTCHAR THEN 160 152 IF CURCHAR>159 THEN 310 155 CH=CURCHAR 156 CALL HCHAR(MR,MC,CH) 157 CURCHAR=CURCHAR+1 160 AROF=CH-STARTCHAR 170 TC$=CC$(AROF) 180 XC=DOTCOL-(MC-1)*8 190 P=(DOTROW-(MR-1)**2+1 210 IF XC<4 THEN 220 212 P=P+1 214 XC=XC-4 220 X$=SEG$(TC$,P,1) 260 TT$=SEG$(HPAT$(XC),POS(HEX$,X$,1),1) 265 IF TT$=X$ THEN 300 270 TC$=SEG$(TC$,1,P-1)&TT$&SEG$(TC$,P+1,16-P) 280 IF CH=OLDCH THEN 290 285 CALL CHAR(OLDCH,CC$(OLDCH-STARTCHAR)) 287 OLDCH=CH 290 CC$(AROF)=TC$ 300 RETURN 305 REM OUT OF INK! 310 CALL SCREEN(7) 320 RETURN 399 REM UNPLOT AT DOTCOL,DOTROW 4998 REM MAIN CODE START - INIT THE DISPLAY 5000 FOR A=1 TO 16 5010 CALL COLOR(A,16,2) 5020 NEXT A 5022 FOR A=0 TO 255 5024 COLS(A)=193 5026 NEXT A 5030 CALL CLEAR 5040 CALL SCREEN(16) 5050 INPUT "SCALE? (0.5 RECOMMENDED):":SCALE 5053 PRINT "STEP? (";INT((1/SCALE)*10)/10;"RECOMMENDED):"; 5055 INPUT ST 5060 CALL CLEAR 5070 OPEN #1:"CLOCK" 5075 INPUT #1:A$,B$,SS$ 5089 REM DRAW A HAT! 5090 XP=144 5091 XR=4.71238905 5092 XF=XR/XP 5100 FOR ZI=64 TO -64 STEP -ST 5110 ZT=ZI*2.25 5111 ZS=ZT*ZT 5120 XL=INT(SQR(20736-ZS)+0.5) 5130 FOR XI=0-XL TO XL STEP ST 5140 XT=SQR(XI*XI+ZS)*XF 5150 YY=(SIN(XT)+SIN(XT*3)*0.4)*56 5160 DOTCOL=INT((XI+ZI)*SCALE+128+.5) 5161 IF (DOTCOL>255)+(DOTCOL<0)THEN 5190 5163 DOTROW=INT((96-YY+ZI)*SCALE+.5) 5164 IF (DOTROW>191)+(DOTROW<0)THEN 5190 5165 IF COLS(DOTCOL)<=DOTROW THEN 5190 5169 COLS(DOTCOL)=DOTROW 5170 GOSUB 100 5190 NEXT XI 5192 NEXT ZI 5199 REM FINISHED - SIT FOREVER 5200 INPUT #1:A$,B$,SE$ 5201 CALL SCREEN(2) 5205 CALL CHAR(OLDCH,CC$(OLDCH-STARTCHAR)) 5210 CALL KEY(0,K,S) 5220 IF S=0 THEN 5210 5230 PRINT SS$,SE$ 5240 END EDIT: 3.5 hrs in, and I found a few optimizations. Changed the source above, it should now be nearly twice as fast (due to not overdrawing the previous pixel, which the trig and the scaling was causing to happen often). If you want to actually run it, run that. Screenshot below shows the original app at near 4hrs, the same code running in overdrive for about 3.5, and the new version running for about 30 minutes so far (in Overdrive). Edit2: After just about 12 hours I'm calling it quits. I had three versions running - the original code in TI BASIC, the same code under CPU Overdrive, and a heavily optimized version under CPU overdrive. (I've updated the source above again for the last few tweaks). None of the projects finished, although the original version under overdrive had run out of characters, so I wasn't going to see much more anyway. I printed out the status and timestamps and did some really rough calculations about how long they would take. The first version under TI BASIC ran for 11h28m, and finished roughly 25% of the spiral. Based on that, an estimated total time of 45h52m to complete. The same code under CPU Overdrive ran for 10h43m, and finished roughly 90%. The estimated total time would have been 11h54m, and that gives me a ratio to compare the optimized version. The optimized version ran under CPU Overdrive for 5h58m and finished roughly 56%. That gives an estimated total time of 10h39m, and a real-world non-overdrive estimated time of 41h00m, which is a nice round number but longer than I'm willing to let it go. Edit3: I also tried RXB, just for kicks. I extended the code to use the cursor and edge character, since RXB allows that too. I had some trouble with the overnight run, but I was able to extract some basic data. I believe that it was running notably quicker, and could have completed the task in 25h43m (non-overdrive, which was the main problem ). That's almost twice as fast as the TI BASIC estimate (41h). Edit4: Last Edit, I promise. I couldn't resist the urge to make it accessible. So, having roughly got the full time, this version cheats by letting you set the step on the loops. I did a 50% scale at step 4 (in about 37 minutes), and a 10% scale at step 10 (in about 3 minutes). the step makes it sometimes miss pixels on the erase phase, but it got enough that you can see the shape The 50% version still ran out of characters at about the same place. (Both times are in overdrive). it's probably worth noting that MESS full speed is faster than Classic99's overdrive. I didn't try there but it may be more tolerable. Edit5: Ran one last time in MESS. MESS managed an average of 4.6x unthrottled (with frameskip 10, versus C99's overdrive being roughly 3.8x). I ran at a scale of 0.3 and a step of 4, and it drew the entire hat. I didn't time it this time. Edit6: Senior Falcon had some brilliant simple optimizations that completely eliminate overdraw. With that (updated above), under Classic99, the entire graph is rendered at 0.4 scale in only 12 minutes and 37 seconds (System Maximum). Tickled by that! Edited February 26, 2015 by Tursi 2 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted February 23, 2015 Share Posted February 23, 2015 Could we possibly get a re-post on the program please? Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted February 23, 2015 Share Posted February 23, 2015 Could we possibly get a re-post on the program please? You getting a bad value as you have it running in TI Extended Basic. The line above FOR A=1 to 16 sets the Character Set value. Sadly sets 15/16 are NOT available in TI Extended Basic. (See page 10 of the original TIXB manual) -- those will give a bad value as that is sprite space now. If you want to run this program without errors you should try plain TI BASIC. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted February 23, 2015 Share Posted February 23, 2015 You getting a bad value as you have it running in TI Extended Basic. The line above FOR A=1 to 16 sets the Character Set value. Sadly sets 15/16 are NOT available in TI Extended Basic. (See page 10 of the original TIXB manual) -- those will give a bad value as that is sprite space now. If you want to run this program without errors you should try plain TI BASIC. RXB has character sets 15/16 and you can run TI Basic programs from RXB and they work fine. I suggest you run them from RXB if you can in Classic99 or MESS or Win994A or get one of the CARTS. Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted February 23, 2015 Share Posted February 23, 2015 (edited) RXB has character sets 15/16 and you can run TI Basic programs from RXB and they work fine. I suggest you run them from RXB if you can in Classic99 or MESS or Win994A or get one of the CARTS. Good idea, I should try that later, normally I use Classic99 or V9t9, all tho I need to update my RXB on my PC, its still RXB 1001 from around '95 or so very old version, also have dig out my eprom eraser and update the cart version soon to your latest RXB. Edited February 23, 2015 by Gary from OPA Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 23, 2015 Share Posted February 23, 2015 Yep, TI BASIC only. (Or RXB, but that didn't exist when I first wrote the plot function many years ago. If I'm going to be silly, I go ALL silly. ) Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 23, 2015 Share Posted February 23, 2015 (edited) I updated my TI BASIC version above.. there were some pretty good optimizations I could make (besides outright cheating like changing the number of pixels calculated), and the new version is roughly twice as fast. The biggest change is that due to the scaling (and occasionally just the nature of plotting curves), the same pixel would be drawn twice in a row. Because drawing a pixel in my code is very slow, and then it has to erase all the pixels beneath it, this could take numerous seconds. I added a quick check and if the pixel calculated is the same as the last one, we skip the draw/erase steps. The snapshot I put in the post up there shows the story, I expect that version to overtake the previous one started hours ago. Eventually I'll get some times to post there too Edit: Aborted the runs and estimated the times back in the original post. Edited February 23, 2015 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted February 23, 2015 Share Posted February 23, 2015 You getting a bad value as you have it running in TI Extended Basic. The line above FOR A=1 to 16 sets the Character Set value. Sadly sets 15/16 are NOT available in TI Extended Basic. (See page 10 of the original TIXB manual) -- those will give a bad value as that is sprite space now. If you want to run this program without errors you should try plain TI BASIC. It must have been late, because I actually KNOW THAT! Not only that, but the single statements per line is a dead giveaway. Anyway... I ran it on my TI this morning... tick...... tock..... tick...... RESET! So I then ran it under Classic99 at system maximum, better... but still.... Quote Link to comment Share on other sites More sharing options...
bfollett Posted February 23, 2015 Author Share Posted February 23, 2015 (edited) Wow, all this is all making the Atari's stock Basic 3 hour run seem almost fast, and there are faster Basics available plus basic compilers. Still it would be nice to see a final output from TI Basic regardless of the runtime. Thank goodness for warp speed in the emulators. Bob Edited February 23, 2015 by bfollett Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 23, 2015 Share Posted February 23, 2015 And ... it shows how fast the Geneve actually is in comparison to other platforms - a pity that there are so few ABASIC applications. Hmmm ... are there any? This was actually my first ABASIC program. Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 24, 2015 Share Posted February 24, 2015 Yeah, TI BASIC is the wrong application for this. But it's not actually comparing apples to apples, either. ABASIC and the Atari BASIC both have their graphics primitives written in assembly language, and both have a dot-addressable mode to plot to. My program is calculating the graphics in BASIC via string manipulation and redefining characters. But I did it because it's one of those things that a younger me would have called impossible, and I like showing myself up. (That said, TI BASIC /is/ really slow and doesn't even compete.) I'm not letting it run to completion either way, though, you'll have to settle for the 80% pic I posted already. (It's too distracting, I keep checking in on it.) Who's going to dive in with some other versions to show what the TI can really do? 1 Quote Link to comment Share on other sites More sharing options...
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.