Bitmap mode.

[+Vorticon]

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?

[+Lee Stewart]

 

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

[+Lee Stewart]

... 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

[+Vorticon]

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.

[Asmusr]

MOV @PDT(R4),R0

Lee, that won't work.

[+Lee Stewart]

MOV @PDT(R4),R0

Lee, that won't work.

Oops! Yeah, your code is it. Only change is PDT EQU >2000.

 

...lee

[apersson850]

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

[+Vorticon]

I tried playing with the LOGO draw functions, but they are pretty slow unfortunately. Fun though

[bfollett]

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,0
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+ZI+160:Y1=90-YY+ZI
230 TRAP 250:COLOR 1:PLOT X1,Y1
240 COLOR 0:PLOT X1,Y1+1:DRAWTO X1,191
250 NEXT XI:NEXT ZI
260 GOTO 260

More info here: http://j-b.livejournal.com/419883.html

Bob

Edited February 22, 2015 by bfollett

[Stuart]

 

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

[bfollett]

 

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

[+OLD CS1]

 

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.

[+mizapf]

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

[+mizapf]

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

[Tursi]

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

[Omega-TI]

Could we possibly get a re-post on the program please?

[Gary from OPA]

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.

[RXB]

 

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.

[Gary from OPA]

 

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

[Tursi]

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. )

[Tursi]

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

[Omega-TI]

 

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....

[bfollett]

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

[+mizapf]

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.

[Tursi]

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?