Jump to content

Ksarul

Members
  • Content Count

    5,545
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Ksarul

  1. That's the same one I have. . .it must have been popular, as the only two PDS implementations I've seen were for Thoroughbred Horses.
  2. The TL331CP (or the approved alternate TL331IP) can still be found (I found one Hong Kong seller claiming to have 2600 of them about five minutes ago on a cursory parts search using the IEEE website). Note that both variants are out of production, unfortunately, so YMMV.
  3. Thanks! New things in XB are interesting too. . .
  4. There were two types of tray for the white label strips. The original ones had you sliding the strip into it (held in place by the edges of the tray frame and sliding out to the right). These consoles also had the Solid State Software labels at the base of the cartridge port slot. Later, TI changed the tray to make it easier to change the strips when using programs that needed them. This type works more like an easel. The machines with this type of tray don't have the Solid State Software badging. One note: the keyboard strips were generally not glued in place, as you had to change them quite often to be able to identify the correct Function and Control key functions used by the program (and their purpose).
  5. When I look for your auctions, it shows no listings at all--but the links you provided do open to the three auctions you identified, so I know they are there. . .I just can't actually see the others. I tried looking from eBay US and eBay Netherlands.
  6. All TI books are worth scanning for the digital collection.
  7. Mine was one of the horse racing programs (there were three, I have to look to see which one mine is again). The name of mine was on the cartridge label, so you may find it if you eject the cartridge to look at it.
  8. Which one of the PDS Sports cartridges is in it? There were several different options, based on what was in their old catalogs. The rest of the machine is a simple rebadge of the regular CC-40, IIRC. And yes, those cases are nice (I have one too). Considering the prices they charged back then for their sports betting systems, the case needed to be that kind of high-quality product.
  9. The current mapper used by the SAMS (74LS612) is already extensible to 16MB. Very little software has even attempted to max out the 1MB space on the current boards. When you put the buffers, the logic to mimic the 32K memory space, the mapper and a pair of memory chips on a board (this is done using through-hole components to keep it a project that can be assembled by an old-school hobbyist), you end up with a board about four inches wide and seven inches long. Horizontally, it will eat a lot of your precious desk space (about as much as the PEB connector). Vertically, it will be somewhat easy to knock loose. Note that you also have to add the necessary power supply connections too. I have considered a sidecar variant, but I really haven't seen a solid reason to go that way yet. A lot of people have the PEB card--yet there is still only a little software that makes use of it (although that has been slowly changing too, so having one is starting to become a good idea).
  10. Reservation and donation complete. I'll be there late Friday (sometime in the evening, most likely), but I will be there, assuming the universe continues to cooperate.
  11. Last two days for hotel reservations at the group rate. . .
  12. The 32K Ram Expansion is the 24K of High Memory and the 8K of Low Memory. All versions of Extended BASIC use the High Memory for their programs when it is available (this means a 32K card is installed), or they use about 13K of the VDP memory as the program space when it isn't present (no 32K card installed).
  13. Powering some displays in the Smithsonian Air and Space museum back in the late nineties. . .
  14. True--I just noted it was less than the 24K available to the XB programmer, not that it was too small to use. I like Cortex BASIC I was really glad to see you do this port too. 14K allows the programmer to make substantial programs, larger than what would be possible in console basic or with the various flavors of Extended BASIC without memory expansion. There are a lot of interesting and useful TI programs that size or smaller.
  15. Oh yes--I really want one of these. I even have a TV around here that accepts a SECAM input.
  16. This was to avoid the programming space reduction evident in the Cortex BASIC port. I use that dialect a lot on my Cortex, but I also have a lot more code space available to me there due to it having a much more flexible memory map.
  17. That was understood, @senior_falcon--my comment was more about maintaining integrity of the 24K of High Memory as space for the BASIC program and not expanding the support routines into that space. Thanks for making sure that knowledge is known to everyone. I have to be more careful not to jump too far from the lines of common knowledge when I write (or at least explain myself better when I do).
  18. The only Hexbus peripheral I don't have in my set. . .
  19. Actually, TI already made a p-Code sidecar. It is really hard to find (I know of only three to four surviving examples, as most of them were sold into the education market and didn't make it into the collector/user community), but it could be cloned if using an apropriate GROM emulation in the box. I'll have to open mine up to get some pictures of the board, as that will be a major determinant on difficulty.
  20. It only has one claim to fame: it is the first modulator that TI was able to get sufficiently hardened to actually pass the FCC certification requirements for a Class B device. As already noted, it is NOT common, unlike the two later variants (your UM1381 being one of those).
  21. You seem laser-focused on speed as the way to improving BASIC. So long as BASIC (any flavor) requires the use of GPL, you will never get an overall gain in execution speed. It is a hardware constraint that you cannot ignore. Rich does all of his programming in GPL, and has kept his focus there for well over 20 years. His work has benefitted the community, and the somewhat recent availability of phsical RXB cartridges has moved interest outside the limited membership of those with access to GRAM devices that emulate the GROMs his code needs to reside in. More people use RXB now--and that is a good thing, but it requires GPL to work, and anything using GPL will not give you the speed increases you are loking for. As to the APESoft routines, they have the same limitations as the Draw and Plot routines, The Missing Link, XB256, or any other language extension. All of them would reside in the 8K of Low Memory--and if you are using one of them, you aren't using any other BASIC support routines, as they would need to occupy the same space. Rich has already identified the scope of the problems here, and why RXB stays away from integration attempts. This is not a simple plug-and-play activity to blend the functions of the language to get the "fast" features you want. It is a complex task. Rich has dedicated much of his adult life towards making RXB as efficient and as useful as possible (and I appreciate that). Harry has taken the BASIC support routines about as far as it is possible to take them in his XB256 program--and integrated them into his Compiler to allow just what you are asking for: FAST program execution at near-Assembler speed. I say near-Assembler speed because code written from the ground up in Assembler will be better optimized and slightly faster, but what the user gets here with his existing software is phenomenal. I am glad that we have his tools to work with--and I'm glad we have Rich's RXB (and Tony Knerr's XB 2.7, which only stopped being developed because of his untimely passing a couple of years ago). Cortex BASIC is also interesting, it just doesn't have a lot of programs written in it--and the code space is a lot smaller due to the memory map of the 99/4A. That shows just how fatal the compatibility issue is: if you can't use the existing Extended BASIC program library with the software you are developing, the only person you will be developing for is yourself. You might want to try and USE the existing products to see what they can give you. Each has advantages, and each has disadvantages too, but all of them meet the first rule of programming: they are useful tools.
  22. I finally had a chance to read through this thread. There are a LOT of TI-specific limitations that the original poster does not seem to grasp. First, you have to deal with the memory map of the 99/4A. Any BASIC other than the console BASIC is dependent upon two to three hardware factors. First, the cartridge port only occupies 8K of the system map. It is possible to add additional 8K bank-switched blocks, but for setting up a ROM-only BASIC, all of your tokens and their trampolines would have to be in that first 8K. The code for your routines could be in other 8K blocks though. This assumes you are using Assembly for everything--and that your Assembly code has been optimized to work in a bank-switched memory space. Note that you also need to deal with the way memory is otherwise allocated in the system. Low memory (mentioned several times in this thread) is an 8K space where existing Extended BASIC extension code resides. High memory is a 24K space where your BASIC code lives. You also have about 12K of space in the video memory space that can be used to hold strings and other variables. These spaces are not generally mutable. Use of a SAMS memory card allows you to bank switch in both the low memory area and the high memory area, but you have to make sure your program keeps track of where everything is in those spaces. TI got around many of these limitations by using GPL and GROM chips to store code and programs. The cartridge port generally supports five GROM chips in a group that each store up to 8K of GPL code. Now combining the five GROMs and the cartridge 8K ROM space allows us to create things like TI Extended BASIC V100 (withdrawn in 1981 due to some significant errors in the math routines), Extended BASIC V110 (Last version from TI--and it still contains a few errors in the trigonometric functions). Note that both of these use a combination of ROM and GROM, Assembly code in the ROM (12K, as it bank-switches half of the space), and GPL in the GROMs. RXB, Triton Super Extended BASIC, Tony Knerr's XB 2.7, and Mechatronic Extended BASIC and Extended BASIC II+ all use the same ROM code TI used, as all of their code changes were in the GPL code contained in the GROMs. Winfried Winkler's Expanded BASIC 3 made changes to both the ROM and the GROM code (and uses four ROM banks instead of two). Some of those changes were to add functions, some were to change memory usage (the cartridge has some limited support for SAMS memory and expects a 32K memory space by default, but will run on a bare console), and some were to correct issues with the trigonometric functions from TI. The Assembly versions of basic (Myarc BASIC 2.12 and Cortex BASIC) don't use GPL. Myarc BASIC runs in a specialized memory space in the 128K/256K/512K card, leaving the normally available 32K memory space open for programs (24K for programs and 8K for Assembly subprogram suport, IIRC). Cortex BASIC runs from cartridge space and part of the 32K space--leaving a much smaller space available for programs. Programs written for either of these will run a LOT faster than programs written for the other TI BASIC/Extended BASIC variants. On pixel graphics, there are several options: Mechatronic Extended BASIC II+ includes the APESoft expanded graphics routines that give access to Bitmap Graphics modes. These routines were also available in Austria/Switzerland/Germany as APESoft Expanded Grafics BASIC and in the US as Amerisoft Expanded Graphics BASIC. The Mechatronic and separate versions were loaded into the 8K low memory space. Cortex BASIC has the necessary routines as well. There are also several external packages that add help here, many of which have already been identified in the thread. Cortex BASIC source code is based on BASIC for the Powertran Cortex, which is a derivative of TI-990 Power BASIC. This would probably be a good starting point if someone really had the time to try and create a full Assembler version of TI BASIC. Don't even think of trying to tie me to that task, as my programming skills are limited to BASIC and a little bit of Pascal. Logo/Logo II are TI cartridges that add another programming language to the TI. Very little was written for this environment, but it is interesting in that there are versions of the cartridge in English, French, German, Dutch, Italian, and Spanish, making it a very suitable language for teaching children to program. The Arcadeshopper store has new-manufactured Cortex BASIC, XB 2.7, Winkler Expanded BASIC 3, Triton Super Expanded BASIC, and RXB 2015 cartridges available. I can also supply any of the above cartridges. The really important thing to understand with any attempt to completely rewrite Extended BASIC is that almost all versions are dependent upon GPL to leave enough memory space open to be able to actually write programs. This means BASIC will be slow, really slow. Cortex BASIC is the only current dialect completely written in Assembler--and it leaves much less open space for programmers to actually write their programs. More importantly, it is not compatible with any of the other BASIC dialects for the TI. It also has very few programs written specifically for it at this point in time. Rewriting ANY of these BASIC dialects is not a project for the casual programmer. It also requires a programmer committed to the project, something the available programmers on this forum have pretty much avoided saying. If YOU want this to come to life, you'll have to dedicate yourself to completing it. Others may help you with specific elements when you get stuck, but that's about all of the help you can hope for. Rich has been asking for help rewriting the XB ROMs for years--and getting nowhere. That is a much smaller undertaking than you are asking for here. . . Auf Deutsch: niemand Hier moechte sowas machen, da der Aufwand ist viel zu Gross und am Ende, kaum Jemand wird es benuetzen. Leider.
  23. Actually, that was all of them they had--if they had more, I would have bought a few hundred more of them. . .
  24. Any updates on this one? It's one of those outstanding TI utilities. . .and highly useful.
  25. I found someone who had a hundred or so NOS can transistors of the right type, so I just had to buy them. . .
×
×
  • Create New...