XB VDP PROGRAM VS RAM INT/VAR 254 TEST

[RXB]

To prove my point about VDP is slower then RAM I just designed another demo on normal XB to show the difference.

VDP PROGRAM vs RAM INT/VAR 254 so you see VDP program mode is much slower then RAM INT/VAR 254 in program modes.

 

[+InsaneMultitasker]

To prove my point about VDP is slower then RAM I just designed another demo on normal XB to show the difference.

VDP PROGRAM vs RAM INT/VAR 254 so you see VDP program mode is much slower then RAM INT/VAR 254 in program modes.

 

Hi Rich, can you explain what you mean by VDP program mode? Whenever I load a program in XB, as long as I have the 32K expansion turned on, the program loads and runs from the top 24K or CPU RAM. I can verify this by doing a SIZE. The usage of 32K is the same whether I load a PROGRAM and Internal/Variable 254.

The speed difference is interesting, it just doesn't seem to mesh with what I see on the real hardware. So it is certainly curious.

[senior_falcon]

Hi Rich:

 

There are a couple of problems with your speed demo. First of all, you say that IV254 runs in RAM while program format runs in VDP RAM. Not so. If the 32K expansion memory is there then the program will be loaded to RAM regardless of whether it is in IV254 or Program format. I don't see an option in Classic 99 to turn off the expansion memory, so unless you found a way to do that then both examples were loaded into RAM.

 

Second, to run the program XB has to load it, then do the prescan, and then it can run it. You are making some assumptions here that may not be correct. You say that disk access is not the reason for the slower performance, but there is really no way to know that. I'm pretty sure that duplicating the disk performance was not high on Mike's list of priorities. So it is likely that his disk routines don't run at the same speed as they would on the real TI-99. As I remember, loading an IV254 program is somewhat slower on the TI than loading the same program in program format, but it may be that IV254 loads faster with Classic 99.

 

It would be an interesting experiment to run the same program on two TIs, one without memory expansion and running out of VDP RAM and the other with 32K and running out of RAM to see how the performance differs. I would bet a shiny new quarter that the difference would be no more than 1 or 2 percent. I have no way to test this here because my console has the RAM built in and all my other consoles are dead.

[Tursi]

Classic99 doesn't emulate the TI disk system, so there's no timing to reproduce there. The differences in his experiment are interesting.

 

When loading a PROGRAM type file, the entire thing is loaded to VRAM first. In the case of having 32k, it's then relocated into the 32k memory expansion.

 

With IV/254 format records, it's loaded one record at a time into VRAM, and then each record is copied into CPU memory.

 

On the surface it would appear that IV/254 format files would be doing more work, but what we could be seeing is a more efficient load process. (For example, no need to relocate the program since it never could run from VDP).

 

Actual disk access time on Classic99 is practically 0 for all intents and purposes. The DSR hands off to native code, so the finding of the file, and the loading of the data into VDP memory is all handled outside of the 9900's space by native C code. This means that the timing difference comes entirely from what happens /around/ the disk access.

 

Of course, on a true floppy disk, the time spend locating individual records might outpace the time needed to load a PROGRAM block. But Rich's test is easy enough to reproduce on hardware.

Edited May 6, 2013 by Tursi

[senior_falcon]

I did some testing on the real TI to determine relative speeds loading PROGRAM format files vx. INT254 files. I started with:

NEW

CALL INIT

CALL LOAD(-31952,211)

CALL LOAD(-31950,211)

CALL LOAD(-31866,211)

This moves the pointers to the start of the program so they are at >D3E7 instead of >FFE7. Now if you write a program and save it there are an extra 11264 bytes that XB thinks are part of the program, but which actually do nothing except go along for the ride. The disk saves these as if they are part of the program

Now enter this program:

10 CALL GCHAR(1,1,G)::G=G+1::CALL HCHAR(1,1,G)::DISPLAY AT(10,1):G

20 RUN "DSK1.SPDTST1"

Save this as DSK1.SPDTST1 This will save the program in PROGRAM format.

Then CALL FILES(9)

Change line 20 to RUN "DSK1.SPDTST2" and save the program as DSK1.SPDTST2. The CALL FILES(9) causes the program to be save in IV254 format.

Now:

NEW

CALL FILES(3)

CALL HCHAR(1,1,0,768)

OLD DSK1.SPDTST1

Type RUN and when the second hand comes around to 12 and press enter.

I waited until 8 was printed (the programs were slightly different) which took 121 seconds.

Did the same but with SPDTST2 (the IV254 file) and it took 118 seconds. So there may be a tiny speed advantage to IV254, but there is one thing to consider. I had wanted to make two fresh disks with only one file on each to avoid the possibility of fragmented files, but my horizon ramdisk decided to misbehave so I just put them on the same disk. So it may be the speed difference is due to fragmented files. Still, I was surprised to see the IV254 load as fast as it did. They always seemed sluggish to me, but of course that was probably because they were large files!

 

I did a little further testing using Win994a which has the option of using or not using the 32K expansion. Cory was very careful in making the speed as accurate as possible, so this is probably a fair test. Here is the program:

20 I=I+1::J=I*I*I::K=I/3.14::PRINT I;::GOTO 20

With no 32K expansion (i.e. running in VDP) it got to 849 in one minute. With the 32K it got to 852.

Breaking the line up into single statement lines and running in TI BASIC it got to 427 in one minute. (Running this program in XB got to 837, so there wasn't that much of a slowdown from splitting up the line)

[senior_falcon]

Now that we've seen just how slow TI BASIC is, try modifying the above program to remove the PRINT:

20 I=I+1

30 J=I*I*I

40 K=I/3.14

60 GOTO 20

Run for one minute in XB and in TI BASIC. The results after one minute: In XB I=2129. In TI BASIC I=2514. So there ARE times when BASIC is faster!

[Opry99er]

Ha! Good stuff there...

 

Benchmarking is a time-tested way to have a little bit of fun and (from time to time) prove a point. =) I love watching Willsy's benchmarking of TF vs. XB. He starts the XB program, takes his sweet ass time getting the TF emulation going, then WRITES the WORD in TF, (making a mistake and re-writing it in the process) casually executes the TEST, and TF just blows by XB like it's standing still... Hilarious.

 

[RXB]

Thanks for the input. I stand corrected on the running from RAM or VDP, it obviously runs from RAM all the time.

 

But I was 100 percent correct that INT/VAR 254 is faster every single time then the TI BASIC way of loading programs.

 

I have run tests and not one single time did Program mode beat INT/VAR 254 as all my XB programs have been converted to INT/VAR 254

 

An added advantage is I can always tell a XB program from any other type as they are ALWAYS INT/VAR 254

[+InsaneMultitasker]

But I was 100 percent correct that INT/VAR 254 is faster every single time then the TI BASIC way of loading programs.

 

I have run tests and not one single time did Program mode beat INT/VAR 254 as all my XB programs have been converted to INT/VAR 254

Is there a way to force a save to IV254 using standard XBASIC? This discussion has me curious about some of my BBS program load times. Thanks

[RXB]

I have a video on this posted:

http://www.youtube.com/watch?v=UHQcOho0KEA

 

I put out a post on TRANSFORM that does this on hard drive but can not find the post?

Here is the XB program that goes with the video:

 

100 ! TURN OFF GRAM PROTECT	 FOR >8000 (GRAM4)
110 ! SAVE AS I/V 254 ONLY	 INSTEAD OF PROGRAM IMAGE
120 CALL CLEAR :: PRINT "TRUN OFF GRAM PROTECT >8000":"< PRESS ANY KEY >" :: CALL KEY("",0,K,S)
130 CALL POKEG(-29098,5,142)! CHANGE GRAM BYTES
140 PRINT "SAVED ONLY IN I/V 254 IN XB"
150 ! TRANSFORM XB program	 image format into XB	 Internal Varible 254	 format for catalogs.
160 CALL VERSION(V) :: IF V<2001 THEN PRINT "VERSION TO OLD TO CONTINUE!" :: END
170 DISPLAY AT(1,12)ERASE ALL:"TRANSFORM": :" PROGRAM IMAGE TO I/V 254"
180 CALL HPUT(6,3,"EXAMPLE:",8,3,"PATHNAME:DSK1.",10,3,"PATHNAME:DSK.DISKNAME.",12,3,"PATHNAME:WDS1.DIR.",14,3,"PATHNAME:WDS.DIR.SUB-DIR.")
190 CALL HPUT(17,3,"(Where to save results.)",23,3,"PATHNAME:")
200 ACCEPT AT(23,10)BEEP:M$ :: IF M$="" THEN RUN
210 CALL CLEAR :: PRINT "Creating USER file DV80TEMP"
220 OPEN #1:M$&"DV80TEMP",OUTPUT
230 PRINT #1:"NEW"&CHR$(13)
240 DISPLAY AT(1,2)ERASE ALL:"* DIRECTORY TO TRASFORM *"
250 CALL HPUT(5,3,"EXAMPLE:",7,3,"PATHNAME:DSK1.",9,3,"PATHNAME:DSK.DISKNAME.",11,3,"PATHNAME:WDS1.DIR.")
260 CALL HPUT(13,3,"PATHNAME:WDS1.DIR.SUB-DIR.",15,3,"PATHNAME:WDS.VOL.DIR.")
270 CALL HPUT(17,3,"PATHNAME:WDS.VOL.DIR.SUB-DIR.",23,3,"PATHNAME:")
280 ACCEPT AT(23,10)BEEP:_$
290 @,X=0 :: IF LEN(_$)=0 THEN RUN
300 DIM TYPE$(6),F$(128)
310 TYPE$(1)="DIS/FIX"
320 TYPE$(2)="DIS/VAR"
330 TYPE$(3)="INT/FIX"
340 TYPE$(4)="INT/VAR"
350 TYPE$(5)="PROGRAM"
360 TYPE$(6)="DIRECTORY"
370 OPEN #2:_$,INPUT,INTERNAL,FIXED 38
380 INPUT #2:A$,J,J,K
390 CALL CLEAR :: DISPLAY _$;" - DISKNAME= ";A$:"AVAILABLE= ";K;" USED= ";J-K
400 DISPLAY:"FILENAME SIZE TYPE P":"---------- ---- ---------- -";
410 INPUT #2:A$,I,J,K
420 T=ABS(I) :: IF LEN(A$)=0 THEN GOTO 550
430 DISPLAY: :A$;TAB(12);J;TAB(17);TYPE$(ABS(I));
440 IF J<4 THEN DISPLAY "FILE TO SMALL TO CONVERT!" :: GOTO 410
450 IF ABS(I)=5 THEN 490
460 IF ABS(I)=6 THEN 510
470 B$=" "&STR$(K)
480 DISPLAY SEG$(B$,LEN(B$)-2,3);
490 IF I>0 THEN 510
500 DISPLAY TAB(28);"Y";
510 IF T=4 AND K=254 THEN 540
520 IF T<>5 THEN 410 ELSE IF @<>0 THEN 540
530 PRINT "(A for all)" :: DISPLAY AT(24,1)BEEP:"(X for XB) ?" :: CALL KEY("",3,W,S) :: IF W=65 THEN @=W ELSE IF W=88 THEN 540 ELSE 410
540 X=X+1 :: F$(X)=A$ :: GOTO 410
550 PRINT: :"! Creating program list.": :"PLEASE WAIT..."
560 IF X=0 THEN 620
570 FOR Y=1 TO X
580 PRINT #1:"OLD "&_$&F$(Y)&CHR$(13)
590 PRINT #1:"SAVE "&M$&F$(Y)&CHR$(13)
600 PRINT #1:"NEW"&CHR$(13)
610 NEXT Y
620 CALL CLEAR :: PRINT "PLEASE WAIT..."
630 PRINT #1:"! TRASFORM is finished."&CHR$(13)
640 PRINT #1:"! PLEASE DELETE FILE:"&CHR$(13)
650 PRINT #1:"! "&M$&"DV80TEMP"&CHR$(13)
660 CALL CLSALL
670 CALL USER(M$&"DV80TEMP")

 

Good luck

Rich

 

P.S. any program image less then 5 sectors may present problems so add enough to make them 5 sectors or more in size.

Edited May 7, 2013 by RXB

[senior_falcon]

Is there a way to force a save to IV254 using standard XBASIC? This discussion has me curious about some of my BBS program load times. Thanks

Download "The Missing Link" from TI-99/4a development resources pinned to the top of this site. Missing Link has a utility that converts program files to IV254 files. It is documented on pages 19-20 of the manual.

[RXB]

Download "The Missing Link" from TI-99/4a development resources pinned to the top of this site. Missing Link has a utility that converts program files to IV254 files. It is documented on pages 19-20 of the manual.

 

With RXB I posted a way to do a entire list or hard drive of them in one fell swoop unlike the Missing Link.

 

I also have never seen The Mission Link manual? The only copy I have was mailed to me by the Author I think or someone wanting me to do a review.

 

P.S. Ok I downloaded the manual and found that last statement to be correct. TML will not do more then one program at a time into INT/VAR 254

 

RXB Transform program will do entire hard drive if the DV80 File that is created for USER is not larger then storage Device Size allowed.

 

It would not be hard to change the program to use CS1 instead of Disk or Hard Drive.

Edited May 7, 2013 by RXB

[senior_falcon]

Automatic is good! The manual describes using TML's CONVERT subroutine in the immediate mode. For what it's worth, a clever programmer could convert your TRANSFORM program to use the CONVERT subroutine instead of RXB. Two advantages are that it can convert files as short as 3 sectors long and it would be compatible with a standard TI. I do like the idea of having all XB programs in a easily identifiable format like IV254.

[+InsaneMultitasker]

One last thought and why this is such a curiosity to me: In my experience, IV254 has never loaded more quickly than a program image, especially where a floppy disk is involved. I always loathed hitting the IV254 limit for this very reason.

 

From a DSR perspective, loading a program image should always be faster than a record-based-IO load due to the latter having more overhead. That doesn't mean IV254 can never be faster. Factors such as interlace may come into play.

 

I do like Rich's idea of being able to distinguish XB programs from EA and other images. I'll have to test drive a few programs later this month.

[RXB]

Thanks.

Since the first time I go my TI I hated that Program Image was XB, BASIC, EA5 and even TI Artist pics and others.

 

It drove me crazy when attempting to organize a large library. Very badly thought out for future TI99/4A libraries.

[Willsy]

Thanks.

Since the first time I go my TI I hated that Program Image was XB, BASIC, EA5 and even TI Artist pics and others.

 

It drove me crazy when attempting to organize a large library. Very badly thought out for future TI99/4A libraries.

 

Good point. It would be better if instead of calling then "Program Images" they called them Memory Dumps or something; because that's what they really are. At least then, if they were called DUMPS or something similar, you know all bets are off in terms of what *may* be in the file.