RXB Posted July 12, 2014 Share Posted July 12, 2014 My suspicion is that the difference is related to XB moving the program and line table around from VDP to ERAM during the load. The comments infer the program image must be manipulated whereas the IV254 is directly copied into ERAM. I think the following comments support this theory: So I think the loading speed changes because it is quicker without the extra manipulation. But I don't think the program is executing from VDP if 32K is available, the comments seem to support this. You could validate speed by timing program execution; however, if you time execution AND loading, that muddies the waters for the very reasons above. (Also if I understand correctly, the IV254 program load operation requires 32K. So by saving programs smaller than 13K in this format, someone with XB and no 32K will be unable to load the program from standard XB. This is the only compatibility danger I see in saving all XB programs to IV254) Running tests now with Classic99. BASIC TEST 100 REM BASIC VERSION 410 OPEN #1:"CLOCK" 420 INPUT #1:A$,B$,C$ 430 PRINT A$:B$:C$ 440 A=A+1 450 GOTO 440 Normal XB Program Image test and a normal XB IV 254 test: 100 ! This is a test program 110 ! that tests the idea of 120 ! XB programs image runs 130 ! from VDP and IV 254 140 ! runs from RAM so in 150 ! order to test them 160 ! the same program must 170 ! be saved and run in 180 ! both formats thus a 190 ! comparison can be done 200 ! to test this process. 210 ! First step is to both 220 ! tests use variables as 230 ! both use the same area 240 ! of memory for strings 250 ! and variables storage. 260 ! Second step is to run 270 ! both tests for an 280 ! extended period of 290 ! period of time. 300 ! Third step is compare 310 ! the varible size as 320 ! if Program Image does 330 ! only run from VDP then 340 ! of course it will be 350 ! slower as a result 360 ! becuase RAM is faster 370 ! then VDP. 380 ! Forth step is to 390 ! present the results 400 ! and see the responses. 410 OPEN #1:"CLOCK" 420 INPUT #1:A$,B$,C$ 430 PRINT A$:B$:C$ 440 A=A+1 450 GOTO 440 Will run them for extended period of time and see results. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 12, 2014 Share Posted July 12, 2014 I was editing some code in Myarc's advanced basic (geneve) and it saved my BBS in PROGRAM image format. This caught me by surprise when I went back to XB to test things on the TI! As you can guess, the TI and XB could not load the program! It took me a little bit to realize why. The Geneve can save/load to/from CPU RAM directly and does not have the memory restriction. On the TI I wonder if your RXB save/load routines could be modified with a third option to use the newer cards (Myarc, SCSI, IDE) ability to save and load directly from CPU RAM. I'm guessing the code would not be easy and maybe impossible if the ROM is involved. I just thought you might find it interesting because the load time is nearly instantaneous in both cases on the Geneve thanks to the direct CPU transfers. Here's a screenshot of the file saved in both XB format (IV254) and ABASIC (program): Quote Link to comment Share on other sites More sharing options...
RXB Posted July 13, 2014 Share Posted July 13, 2014 I was editing some code in Myarc's advanced basic (geneve) and it saved my BBS in PROGRAM image format. This caught me by surprise when I went back to XB to test things on the TI! As you can guess, the TI and XB could not load the program! It took me a little bit to realize why. The Geneve can save/load to/from CPU RAM directly and does not have the memory restriction. On the TI I wonder if your RXB save/load routines could be modified with a third option to use the newer cards (Myarc, SCSI, IDE) ability to save and load directly from CPU RAM. I'm guessing the code would not be easy and maybe impossible if the ROM is involved. I just thought you might find it interesting because the load time is nearly instantaneous in both cases on the Geneve thanks to the direct CPU transfers. Here's a screenshot of the file saved in both XB format (IV254) and ABASIC (program): gene0006.png Matter of fact yes that is what I had been working on for RXB 2001 but got so much flack as people thought it was favoritism for SCSI over others. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 13, 2014 Share Posted July 13, 2014 WOW this is perplexing! After 1 hour results are: BASIC Program Image = 673543 XB Program Image = 532370 XB Internal Variable 254 = 523577 Totally unexpected results for BASIC!!! But it did confirm that IV 254 is faster then Program Image in normal XB. BASIC did not have all the REM statements so wonder if that had any effects. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted July 13, 2014 Share Posted July 13, 2014 Thanks, I sort of like it too. Does PC99 support multiple cartridges loaded at once? I used a trick here to suppress Review Module Library by putting the same Groms on the first two pages and the different Groms on the third page. A real cartridge won't need to do that since the first two pages can be mapped to the same memory area, thereby saving 40k of Grom space. I think all you have to do to make it PC99 format is split up the Grom files into separate Groms and name them properly, easily done with a Hex editor. Do you know the format of the PC99 module files? I haven't used PC99 for about 20 years, so I don't remember offhand. Gazoo PC99 does support multiple cartridges. I'll look into doing your idea. As for the header. I have that information somewhere, just got to find it. Quote Link to comment Share on other sites More sharing options...
Gazoo Posted July 13, 2014 Share Posted July 13, 2014 PC99 does support multiple cartridges. I'll look into doing your idea. As for the header. I have that information somewhere, just got to find it. Ok, Let me know. I'll be happy to create the necessary files for you. Meanwhile, I was able to create a real TI cartridge with the 'no menu/menu' version I created, and it worked flawlessly, pretty cool. Gazoo Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 13, 2014 Share Posted July 13, 2014 WOW this is perplexing! After 1 hour results are: BASIC Program Image = 673543 XB Program Image = 532370 XB Internal Variable 254 = 523577 Totally unexpected results for BASIC!!! But it did confirm that IV 254 is faster then Program Image in normal XB. BASIC did not have all the REM statements so wonder if that had any effects. So BASIC had a higher number, which means it was the fastest as it did the most iterations? That is not what I would have expected! Quote Link to comment Share on other sites More sharing options...
+hloberg Posted July 13, 2014 Share Posted July 13, 2014 (edited) Ok, Let me know. I'll be happy to create the necessary files for you. Meanwhile, I was able to create a real TI cartridge with the 'no menu/menu' version I created, and it worked flawlessly, pretty cool. Gazoo How. I want to learn how to create real cartridges and gonna sell any? And, if you would, go ahead and create the necessary files and I'll see if I can find that header info for PC99. Edited July 13, 2014 by hloberg Quote Link to comment Share on other sites More sharing options...
Gazoo Posted July 13, 2014 Share Posted July 13, 2014 How. I want to learn how to create real cartridges and gonna sell any? The board works as it is now. But the designers want to refine it a little, so we'll have to wait just a little while longer. I'm lucky to be one of the testers, as I can create images for it. Creating a real cartridge is REALLY complicated, and I've only just today learned how to program the Grom chip. I know it's hard to wait for this, but be patient, it'll be worth it. Gazoo Quote Link to comment Share on other sites More sharing options...
RXB Posted July 13, 2014 Share Posted July 13, 2014 So BASIC had a higher number, which means it was the fastest as it did the most iterations? That is not what I would have expected! Yea this is really backwards. By everything we know BASIC should be the slowest. It may well be that as it is only running from VDP that Scratch Pad is making the difference here. As when it sees a variable it puts it into FAC and does calculations then puts it back into VDP. XB uses a set of XML Assembly routines and clearly they are inefficient in comparison. Quote Link to comment Share on other sites More sharing options...
Gazoo Posted July 13, 2014 Share Posted July 13, 2014 (edited) Sure what project do you need to do? Hack the TI Multiplan cart so that the disk files load from Rom so no disk is needed. I'm not talented enough to do that, but you are. I know how the Rom bankng works and can help with that. And make two versions, 40 columns and 80 columns. Perhaps a menu choice when Multiplan loads? And it's not to benefit you or me, It's for those that actually might use Multiplan. Whattayathink? Gazoo Edited July 13, 2014 by Gazoo Quote Link to comment Share on other sites More sharing options...
+hloberg Posted July 13, 2014 Share Posted July 13, 2014 The board works as it is now. But the designers want to refine it a little, so we'll have to wait just a little while longer. I'm lucky to be one of the testers, as I can create images for it. Creating a real cartridge is REALLY complicated, and I've only just today learned how to program the Grom chip. I know it's hard to wait for this, but be patient, it'll be worth it. Gazoo Well, making my own carts is a long term goal, very long. I'll eventually get there after I learn a bunch other things TI99 such as gpl etc... Quote Link to comment Share on other sites More sharing options...
RXB Posted July 13, 2014 Share Posted July 13, 2014 (edited) Hack the TI Multiplan cart so that the disk files load from Rom so no disk is needed. I'm not talented enough to do that, but you are. I know how the Rom bankng works and can help with that. And make two versions, 40 columns and 80 columns. Perhaps a menu choice when Multiplan loads? Whattayathink? Gazoo Sure, I do not have a copy of Mulitplan anywhere as I have never used it except on a PC, never on a TI. Do you have the GROMS and DISKs for Classic99? Just need to take a look at how and where I can put it. If they take up to much space then we will have to use SWGROM routine I have played around with. RO EQU >8320 KEYVAL EQU >8375 GROM >6000 * CART GROM AORG >0000 DATA >AA01 * VALID GROM / VERSION DATA >0000 * (FUTURE EXPANSION) LOL TI DEAD SO I HAVE PLANS DATA >0000 * POWERUP DATA PROG * PROGRAMS DATA >0000 * DSR DATA >0000 * CALLS DATA >0000 * INTERUPTS DATA >0000 * BASIC LIBRARY B >0000 * 10 POWER AUTO START BRANCH B >0000 * 13 MENU AUTO START BRANCH PROG DATA >0000 * 16 MENU HEADERS FOR USER DATA SWRUN STRI 'SWAP GROM EXAMPLE' SWRUN HOME * THE FIRST (SWAP) PART FMT COL 0 ROW 2 HTEX 'SWAP GROM & RETURN GROM EXAMPLE!' COL 0 HCHAR 32,45 COL 0 ROW +2 HTEX 'WE ARE IN THE FIRST GROM BANK' COL 0 ROW +2 HTEX 'PRESS ANY KEY TO SWITCH BANKS' FEND SWRUN1 SCAN BR SWRUN1 DST >9804,@RO * THE SWAP GROM OP-CODE DSWGR RTRUN,@RO FMT * THE LAST (EXIT) PART COL 0 ROW 8 HTEX 'WE ARE BACK IN FIRST BANK' COL 0 ROW +2 HTEX 'PRESS ANY KEY TO END EXAMPLE!' FEND SWRUN2 SCAN * KEYSCAN BR SWRUN2 EXIT * END PROGRAM BACK TO TI TITLE SCREEN ***************************************************************** * THIS PART ONLY IS IN THE SECOND BANK AT >9804 GROM >6000 * ***************************************************************** RTRUN FMT * THE SECOND (RETURN) PART COL 0 ROW 12 HTEX 'WE ARE NOW IN THE SECOND BANK' COL 0 ROW +2 HTEX 'PRESS ANY KEY TO SWITCH BACK!' FEND RTRUN1 SCAN * KEY SCAN BR RTRUN1 RTGR * THE RETURN GROM OP-CODE ************************************************************** END Put the disks in the second bank of GROM, I played around with a routine that would search for them in all 16 banks till it found them. Or we could put the DISKs in the TI Basic area as you can not use both TI Basic and Multiplan at same time. Edited July 13, 2014 by RXB Quote Link to comment Share on other sites More sharing options...
jacquesg Posted July 13, 2014 Share Posted July 13, 2014 I have the Art Green version of Multiplan installed on my HSGPL card in bank 4 (>9810) where it overwrites TI Basic. The Multiplan files MPHLP and OVERLAY reside on DSK9 of one of my HRD. I usually use DSK1 as a work disk which IIRC must be named TEMP. Every slot(8 GROM plus 4 ROM) of the HSGPL card are utilized. There is a small bug which can arise when you first set up a spreadsheet but it can easily be avoided. Jacques Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 13, 2014 Share Posted July 13, 2014 WOW this is perplexing! After 1 hour results are: BASIC Program Image = 673543 XB Program Image = 532370 XB Internal Variable 254 = 523577 Totally unexpected results for BASIC!!! But it did confirm that IV 254 is faster then Program Image in normal XB. Rich, if a higher number means it is faster then what you have posted shows the program image loading faster than IV254. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 13, 2014 Share Posted July 13, 2014 Rich, if a higher number means it is faster then what you have posted shows the program image loading faster than IV254. Well actually IV254 does have to be moved up to the upper 24K RAM unlike VDP that just stays where it is. But both run from RAM after testing I was mistaken. The main advantage of IV254 is figuring out if it is a BASIC or XB file or EA file. All of my files for XB on my drives are IV254 for XB programs. The real bonus for speed would be to move the Strings and Variables into RAM as that would speed up XB by a huge factor. But like I said before the only place to move them would be using the SAMS card using the 32K I left untouched. (Imagine 32K RAM for strings and numbers/arrays) 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 13, 2014 Share Posted July 13, 2014 You might want to run the same tests using Winfried Winkler's XB3 too--I seem to remember that he modified it to look for 32K first, and that if it was present, pushed the program straight there in the fashion of an IV254 file, even if it was in PROGRAM format. That was primarily to avoid the problems loading larger TI BASIC programs into memory with a disk system attached, but it may have had other effects too. This is a very interesting discussion on the inner workings if XB though--thanks! Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 13, 2014 Share Posted July 13, 2014 WOW this is perplexing! After 1 hour results are: BASIC Program Image = 673543 XB Program Image = 532370 XB Internal Variable 254 = 523577 Totally unexpected results for BASIC!!! But it did confirm that IV 254 is faster then Program Image in normal XB. BASIC did not have all the REM statements so wonder if that had any effects. I tried the same test using the Geneve's Advanced BASIC for one hour. I thought it would be 3x to 4x faster but it was only 2x. ABasic 4.05 == 1,242,313 I also tried the test on the Geneve using the standard XB cartridge. A bit faster than the TI but nothing earth-shattering. Again,I would have expected more. Geneve w/XB Cart: 818,820 Is TI BASIC using different floating point routines? Is there extra housekeeping in XB slows things down, like interrupt processing? 1 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted July 13, 2014 Share Posted July 13, 2014 Sure, I do not have a copy of Mulitplan anywhere as I have never used it except on a PC, never on a TI. Do you have the GROMS and DISKs for Classic99? Just need to take a look at how and where I can put it. If they take up to much space then we will have to use SWGROM routine I have played around with. <snip> Put the disks in the second bank of GROM, I played around with a routine that would search for them in all 16 banks till it found them. Or we could put the DISKs in the TI Basic area as you can not use both TI Basic and Multiplan at same time. Here's the Groms file. MultiplanG.bin Still looking for the disk. I was thinking more along the lines of putting the disk files in Rom, not Grom. The idea is to put this in one of the ubergrom carts along with an Extended Basic and maybe something else. Grom space is at a premium in the cart, but there's plenty of Rom space to easily fit the files. Extended Basic(s) need the first 2 banks of Rom, selected by writing to c>6000 and c>6002, so the file data could be stored in any of the Roms starting at c>6004 (3rd bank) and above. Does anybody have the original Multiplan disk? Gazoo Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted July 13, 2014 Share Posted July 13, 2014 ....Does anybody have the original Multiplan disk?... Here ya go - this was one of the first archives I sent to my PC from the TI . TIMP.zip Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted July 14, 2014 Share Posted July 14, 2014 I tried the same test using the Geneve's Advanced BASIC for one hour. I thought it would be 3x to 4x faster but it was only 2x. ABasic 4.05 == 1,242,313 I also tried the test on the Geneve using the standard XB cartridge. A bit faster than the TI but nothing earth-shattering. Again,I would have expected more. Geneve w/XB Cart: 818,820 Is TI BASIC using different floating point routines? Is there extra housekeeping in XB slows things down, like interrupt processing? The 2x faster is probably about right though. I was reading an ad for the Geneve in the MicroPendium earlier today (12/86) that claimed only 2-3 times faster. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 14, 2014 Share Posted July 14, 2014 I tried the same test using the Geneve's Advanced BASIC for one hour. I thought it would be 3x to 4x faster but it was only 2x. ABasic 4.05 == 1,242,313 I also tried the test on the Geneve using the standard XB cartridge. A bit faster than the TI but nothing earth-shattering. Again,I would have expected more. Geneve w/XB Cart: 818,820 Is TI BASIC using different floating point routines? Is there extra housekeeping in XB slows things down, like interrupt processing? XB uses Floating point way to much and when you look at what I posted of the XB source code of Floating Point you can see they made it way to complicated compared to BASIC. Also it does like 5 times more unneeded crap to be more accurate at 10 Decimal Places but it does this ALL THE TIME, a huge waste of time 99% of all program times. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 14, 2014 Share Posted July 14, 2014 Here ya go - this was one of the first archives I sent to my PC from the TI . Thanks! Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted July 14, 2014 Share Posted July 14, 2014 Thanks! You're welcome bud Quote Link to comment Share on other sites More sharing options...
RXB Posted July 17, 2014 Share Posted July 17, 2014 Came up with a IV254 concept that works great and is easy to use too!!!! Everything works normally in RXB 2014 same as normal XB like this: SAVE "DSK1.PROGRAM' or SAVE DSK1.PROGRAM or SAVE "DSK1.PROGRAM',MERGE or SAVE DSK1.PROGRAM,MERGE But now I have added this option: SAVE "DSK1.PROGRAM',IV254 or SAVE DSK1.PROGRAM,IV254 The new option in RXB will save programs in IV254 format when you specify this option with the IV254 word after a comma just like MERGE does. Or without using this option it all works exactly the same as normal XB!!!!! 7 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.