Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1,928 Excellent

1 Follower

About senior_falcon

  • Rank
  • Birthday 10/14/1951

Profile Information

  • Gender
  • Location
    Lansing, NY, USA

Recent Profile Visitors

10,331 profile views
  1. Yes, this is a worthwhile modification. Plans are available for piggybacking 2 memory chips and a couple more chips on the console chips, plus some wires to connect various pins. As I remember, assembly programs took about 60% of the time to run - i.e. a program that took 100 seconds on the 8 bit bus took about 60 seconds on the 16 bit bus. I don't remember any significant speedup when running an XB program - a program that took 60 seconds to run would take about 59 seconds in XB. You can "try before you buy" by using Win994a which has the option of putting the expansion memory on the 8 bit or 16 bit bus.
  2. You probably won't see much difference with this. It looks like you are plotting single pixels. The calculations for the pixels are in XB and there would be no speed gain there. And the bottleneck with PIXEL is the CALL LINK which is way slower than a couple of VSBW operations. I have hopes that it will be possible to use your own CALL LINKs with compiled code and that would be a big help for a program like this.
  3. Should work fine. The only thing that could cause problems is if you use direct PEEKs or POKEs. Because the memory locations of the code are different the addresses would be wrong. Once this is done I will give your program a try.
  4. I am excited by some performance improvements I've been making to The Missing Link. I've taken out some VSBW and VSBR routines and replaced them with faster routines. The short video below shows the original TML on the left and the improved version on the right. Both are running the start of the TMLDEMO program. Although I start the left program first, the right hand one quickly overtakes it. I think you'll agree that this is a nice performance improvement.
  5. Nope. I suppose it could be done (not by me), but then your program size would necessarily have to be smaller. There's the trade-off. More features vs less program space.
  6. Back to making good progress on XB 2.8 G.E.M. Thanks to Sometimes99 I was able to expand the fonts to a total of 60. You can see that I chose complete fonts - i.e. both upper and lower case characters except for fonts 33 and 34. It was tough having to eliminate 87 percent of those fonts, but more than 60 seems obsessive compulsive. The Missing Link has been expanded to include Missing Link extras (plus a few more subroutines) which are now available at any time without having to load them into high memory and embed them with your program. It took a while to create the tools needed to test and debug this change. This seems to work perfectly. Now to go back to the start menu and make some revisions to my code. Then to add XB256, T40XB. I want to have XB 2.8 + XXB as an entry in the menu instead of doing it with CALL XXB. After that I hope to be able to add the assembly language loader for CALL LOAD to replace the slow GPL one that is normally with XB.
  7. Sounds like you have it figured out.
  8. 9985_Instruction_Cycle_Times.pdf Pity the 9985 came to a bad end. This would have offered a noticeable speed improvement over the 9900. I will leave it to the gurus to determine exactly how much faster it would have been.
  9. My comments were about the VDP ram and how it is used. What happens if you only have 2K memory remaining in the VDP? the answer is simple - your approach won't work because you need a 4K buffer to load your file. If you use Internal Fixed 128 format this problem goes away. It's just a suggestion. It's up to you whether you want to spend the time to modify this so it works in every case.
  10. "I have fixed BLOAD and BSAVE in the next version of RXB they both do not use >1020 they instead work like variables and allot a location not used, also the new versions are not 8K but 4K so less VDP space used and can load 4K into anywhere in 32K thus even use the highest line numbers of a program replacing them with another page with same line numbers but different lines in them. Example would be: 32000 ! this is a data statement for lower in program 32010 DATA AB94202C6393614C 32020 DATA 345BDF94572EA753 At different page would have totally different lines, but also reside at same location with same line numbers. Of course you have to pad the program so that the end result of these line numbers are on a 4K boundry of memory, but you have unlimited XB program sizes. If you do this in SAMS it is instantaneous switching of pages. This makes SYSTEX seem pretty archaic in comparison let alone by speed. This new versions will allow Assembly to be loaded in upper 24K area not being used by XB programs. Can you think of any other ways to use this?" It sounds like you are reserving a 4K block of VDP ram to save/load the code. If you do this while running a large XB program that uses a lot of strings, you may not have the 4K of space required. You might think about saving in something like IV128 IF128 instead, as that could be set up to use the disk buffers or another safe location that would have no impact on the XB program.
  11. According to the white papers, Plan B was to use the TMS9980 if the 9985 did not work out. According to some information found on the web: "The TMS9980 is fully object-code compatible with the TMS 9900 microprocessors, albeit it's approximately 33% slower than the TMS9900 at the same frequency. The slower execution speed of the TMS9980 is exclusively due to its more narrow, 8-bit external data bus." This performance is about the same as the more expensive 9900 running on the 8 bit bus. Anyone know why the decision to use the 9900 instead of the 9980 was made?
  12. For this test I used BSAVE to save XB256 as XB256BS. Then, to be sure we are comparing equivalent programs, I wrote a 2 line XB loader: 1 CALL BLOAD("DSK7.XB256BS") 2 CALL PEEK(-4,X):: CALL LOAD(10574,144+X):: CALL LINK("XB256A") For comparison, the XB256 SYSTEX like loader is: 1 !XB256 "Isabella" H. Wilhelm 2019 2 CALL INIT :: CALL LOAD(8192,255,152):: CALL LINK("X"):: CALL PEEK(-4,X):: CALL LOAD(10574,144+X):: CALL LINK("XB256A") It looks like BLOAD is a bit faster, which makes sense. SYSTEX loads an XB program to VDP ram, then transfers it to CPU high memory, then transfers that to CPU low memory. BLOAD cuts out the middle man. It loads 8K to high memory, then transfers that directly to low memory. In fairness, this is not SYSTEX. It is my own loader called KWIKLOAD, but I believe that the two are essentially identical. Both are useful tools. The files in KWIKLOAD are a bit smaller. Here XB256 is 7.12K long while XB256BS is 8.12K long. That's because KWIKLOAD uses CALL INIT to load some of the code. Also, it doesn't save junk bytes. If there is 1K of assembly routines, then it will only save those 1000 bytes. I believe SYSTEX works the same way. If you have an XB program that requires some A/L support routines, KWIKLOAD/SYSTEX would be a good choice because it can all be put into one file. And of course, they can be used with any version of XB. On the other hand, BLOAD is a bit more universal. You can imagine an XB program with a lot of assembly support routines. Unlike SYSTEX, BLOAD can change to different assembly routines on the fly with no disruption to the running XB program. (edit - May not work because it overwrites VDP ram starting at >1020) The 8K segment of code can be an assembly program that has nothing to do with XB. BLOAD seems to be ideally suited for use with the AMS system. I have attached a zipped folder with KWIKLOAD and KLOADNEW. These are almost identical. The difference is that KWIKLOAD leaves the XB program intact when it runs. KLOADNEW will transfer the code to low memory, then erase the XB loader program. To embed low memory assembly routines in an XB loader: 1 - Load the assembly routines to low memory with CALL LOAD(...) 2 - CALL LOAD("DSK1.KWIKLOAD.OBJ") or CALL LOAD("DSK1.KLOADNEW.OBJ") 3 - CALL LINK("X") Now the assembly routines are embedded in an XB loader. You can either save this or add lines of XB code to it. KWIKLOAD.zip
  13. Does anyone know anything about the specs for the 9985? I see it would have been clocked at 5MHz or maybe bumped down to 4MHz. Clearly a faster clock would have helped. Did the instructions take the same number of clock cycles as the 9900 or did they require fewer clock cycles like the 9995?
  14. Pronouns can be tricky devils. Just to be clear, here my use of "this" means if the utilities NUMASG, STRREF, etc. can be made to interface with a compiled program. That way in the compiled program the assembly subroutines would be used exactly the same as they would be used in XB. So CALL LINK("CIRCLE", 100,100,50) would work the same when compiled as it does when running TML. The more I ponder this the more hopeful I become.
  15. Just curious to know what part of the statement you disagree with.
  • Create New...