hhos

I'm not advocating this mod so much as evaluating it. I just analyzed what it is doing, realized how easy it would be to include fully populated Scratch Pad, and wrote up something on it. It is here essentially because I think this is a simple, cheap and effective way to speed the TI99 up. I figure, for that very reason, quite a few people have used it, and don't realize with a little bit of time, solder and wire, they could add just a little bit of out of the way memory. This mod also leaves a number of unused resources which could be useful for further expansion, some of which could start to resemble aspects of your system. There's not enough to put together a paging system for the RAM blocks, but it would be a cheap start. Right now, my focus is on designing a system that only uses technology that was available in the early 80s. No FGPAs or CPLDs. PALs are out simply because even if I can find them, the expense would be too great. GALs, PALCEs, PEELs, and similar chips programmed with only the capabilities of a PAL chip are OK. And, of course, I will use SRAMs that weren't available in the 80s, also because of availability and expense. As the system matures I'll allow more modern technologies into the design. The first goal though, is to make it as fast as I can with 74XXX technology chips. This one also adds 64K, no wait states, to the console. It just uses only 32K of it. It is a minimal expansion to give a developer an idea of how his software would play on an early 80s machine, and then on an 80s machine with zero wait states. At least that is how I look at it. I'm assuming that since you can switch RAM into the memory I/O space, that you use the CRU to switch the 8K blocks in and out? Where did you map that into the CRU space? I might put that into my next mod. How many wait states do you have when accessing that external RAM expansion? Only on VDP access? How many wait states does it insert? I believe GROM is even slower than VDP, possibly because it is on the 8 bit side of the MUX? What about GROM access? And the other memory mapped devices? Sound chip? Speech Synthesizer? Anything else? I'm still looking at ideas for my own TI99 mod design, but this one still looks like a good basis to start with on the first one. Yours sounds like it will be more similar to my #3 or #4. Does your modified system use only legacy 74XXX chips? PALs or GALs? Something more sophisticated? HH

I modified a couple of the pictures from the Ballmann-Clulow project to show the jumpers and soldering points. There are two pictures in the attached file. You only follow ONE of them. They both have the same result. It's just a question of whether you want to cut a trace, or pull/cut one pin on each of the two 6810s. Pulling/cutting the pin looks easier but, sometimes it's a little tricky pulling the pin. You might break off the pin from the chip, or pull the trace up off the board. Cutting the pin is easier. Just be careful, in either case, when you solder your wire into the hole underneath the bent up pin. Cutting the trace is the easier way to go, especially if you feel you lack soldering skills. There is just one more point to solder to, and about 5 times the length of wire for the jumper, but each solder point is unobstructed, and there is virtually no chance of accidentally pulling a trace away from the board. HH CG_32K_console_1K.Scratch.tar.gz

BEWARE: I have not tested this but, it is so simple and I can see no reason for it not to work. If you have already installed this 32K console SRAM mod, then it won't take much more work to fully populate the RAM space at >8000 to >83FF. That would give you 1024 bytes instead of just 256. It seems to me that disconnecting the CS* from the 6810s and moving that signal over to pin 4 of U504 C2 (first remove the +5VDC from it) should be all that is necessary. I see two possibilities for doing this. I think this might be the easier of the two but, you may find other possibilities that I didn't consider. The signal could be removed from the 6810s by cutting the trace coming from pin 8 of U507. Run a jumper from pin 8 of U507 to pin 4 of U504 C2. Do not forget to remove the 5VDC from pin 4 prior to connecting this jumper, though. Cutting this trace at this point cuts off the connection to U606, pin 12. In all likelihood, you would want to reestablish the connection from U507, pin 8 to pin 12 of U606. This would be required, if you have the defeat switch installed, so the Scratch Pad memory would still be fast memory when the switch is in bypass mode. The 2nd solution I came up with was to pull or cut the CS* pin on BOTH 6810s. Then run a jumper from the hole that is left under pin 11 to U504 C2-4 (again, remove the 5VDC from it first). This doesn't break the connection to pin 12, U606, so nothing more should have to be done. Alternatively, you could remove both 6810s from the board since they will not be used anymore. I intend to leave them in, possibly to be used as a small buffer for another idea with which I have been toying. I made up schematics for what I call the Clulow-Guion 32K upgrade, and I am attaching them to this post. They are intended as an addendum to "Hardware Manual for the Texas Instruments 99/4A Home Computer" by Michael L. Bunyard. The largest difference between the CG32K and the BC32K is the CG32K can be switched back and forth between 0 wait states and the normal 4 wait states using a toggle switch. I don't think you can hot swap it, though I can't offer first hand test results. Even though I am going to use this as a basis for the 1st stage of my own design, I do not intend to use a toggle switch to bypass the zero wait state in mine, so chances are that I never will test a hot swap of this particular mod. I want to be able to hot swap mine via software, and perhaps a mechanical push button. Instructions for the three current Ballmann-based mods are found here: http://www.mainbyte.com/ti99/16bit32k/32kconsole.html Please let me know if you think I'm in error with the schematics or the modification I've suggested. If you try it and it works, please let me know. If it doesn't work... well, that's your fault for trusting me. Clulow-Guion_32K.upgrade.tar.gz

I finally got around to looking at this project, which I am calling the Clulow-Guion_32K upgrade, located http://www.mainbyte.com/ti99/16bit32k/32kconsole.html Actually not that hard to figure out once you get the pin #'s on those piggy-backs straight. I initially had almost half of them bass ackward . Figuring out where the 2-input AND on U613, pin 13 for the wait state bypass defeat switch was a bit confusing, but I think I got it now. Your mod has 64K RAM and only 32K is used? Did they put some of the extra memory into that space, or do you still only have 256 bytes in the >8000 to >83FF address area? It only has 256 bytes. There may be enough unused logic gates in there now to implement a 1024 byte scratch pad, though. There's certainly enough memory. There is no attempt to accelerate Video, Cart, or GROM access. That, in part I think, would explain the lack of acceleration when running console BASIC, or XB. When I'm certain of the placement of that AND gate I'll post a revised schematic. And, if I can figure it out quickly, maybe a way to mod this mod for the 1024 byte Scratch PAD (not a high priority for me at the moment since the 32K expansion would be just as quick w/ this mod). HH

Thanks, Ksarul. Thanks, Fabrice. I'll be wary. Were any of the errors in the last six pages? Those schematics of the TI99/4QI are the only part of this manual that I am using. Can you direct me to a list of the errors that you have found? HH

I found this: http://www.mainbyte.com/ti99/man/ti99_tech.pdf It appears to be what I was looking for. It has what appears to be a board layout for a 99/4, then schematics for a 99/4A, and then schematics for the 99/4QI. Thanks, HH

"It" would be the Bunyard book I take it? That is the one that I have been using. Thanks, HH

"My detailed study of them will show me that they were not reliable: Several errors slipped inside. The first step was a precise study of the logic of the microcomputer in order to detect all the errors. It was a very interesting step." Fabrice Montupet made this statement in his TI(ny)-99/4A thread in June '17. So far I have not found any errors in the schematic that I have. I can imagine he has had many requests for details on his findings. I do not wish to waste his time if he has already provided this information somewhere. I did search for a while, and I found schematics for what I presumed was the PAL version of TI99/4A, because it had a TMS9928A. But then I saw that it still had a 10.7 MHz crystal, so it couldn't be PAL. A little research revealed that the TMS9929A is the PAL version of the 9928A. Since Fabrice lives in France I further presume the PAL version would be the one he uses (I think I recall him saying somewhere that the 9929A was his favorite VDP ), and this schematic would be the one that has the errors? Or perhaps he is referring to differences between the NTSC schematic and the PAL version? I really just want to know if I need to be wary of errors in the NTSC schematic for now. However, in my search for schematics, I have not come across any for the beige version of the TI99/4A. I understand there were some significant changes made in how things are decoded in these units. Is this info out there? If so, where is it? Thanks, HH

WOW! That was quite a project. That's going to take some time to figure out. I too am planning on piggy-backing onto those ROM chips, but I'm putting RAM chips to replace the ROMs. The RAM will act as ROM chips until I'm ready to change something. There will be battery backup with appropriate steering diodes to keep them from blanking out at power off. The ROMs will stay so I can go running home if I get into trouble, but I will have 64K of pseudo ROM to work with. I think I am still planning on replacing the console RAMs with my two 32K RAMs. That way they are set, with a couple more address lines, to fully populate the 1K console RAM space. Then I will add the necessary decoding for the rest of the RAM. That reminds me. I still haven't checked the pin alignments for the 6810 chips! Yikes! Bad idea, bad idea! I guess those are from an era before they started to standardize the SRAM/EPROM pinouts. Your mod has 64K RAM and only 32K is used? Did they put some of the extra memory into that space, or do you still only have 256 bytes in the >8000 to >83FF address area? I don't say that emulators are useless for benchmarking, by any means. I just don't think they are accurate enough to make a less than 5% call. 1% is well outside their limits of accurate measurement. HH

I can believe there is a LOT of processing going on to process any BASIC language. I can further believe there is even more processing going on in interpreting BASIC and XB on the TI99, because it is an interpreter interpreting an interpreter that uses mostly VRAM. What I can't accept is that a test performed on any TI99 simulation would be valid test of the real thing's actual performance. For the most part I have found that the real computer is slower than the emulation. Emulators are always full of shortcuts around hardware that the author doesn't understand, or finds too difficult to simulate. The DSR in the TI99 disk drive comes to mind. Besides, I don't run Windows on my main machine. I run Linux. I am considering a couple of schemes for eliminating wait states on one of my TI99s. The two front runners are Thierry Nouspikel's and an alternative scheme of my own. I intend to do both of them, but I'd like to look at what others have done. And so I would like to learn more about the method used in your computer. I'd appreciate it if you could answer a few questions about it. 1) What problems, if any, do you have with any of the hardware when you have it in the no wait state mode? 2) What is the wait switch attached to? 3) Do you have some instructions that you followed to install it that you could send to me? And maybe a picture of the finished project? Regards, HH

I think a couple of TI99s I have had something similar to this on them. If memory serves, they are pretty docile until I hit a key. Then they go wacko, or maybe it waits until I select BASIC? Then it goes bonkers? HH

Sinistar Laser Blaster HH

I'm new to TI99, but I've already had the experience of losing my source code on a floppy due to corrupted software from a 30+ year old disk. Backup? Oh, yeah. Huh??!! Now I remember. Back in the day, when I got my first computer, a Model 1 TRS-80 I had no trouble with saving BASIC programs, or at least none that I remember. When I got into assembly, though... it was the norm to lose my source on the tape. It was strange that once I got it assembled, the binary would save and reload without a flaw. Weird. As a consequence of that, I got used to doing a lot of manual assembly. I think I can still disassemble about 75% of a Z80/8080/8085 hexadecimal print out because of it. I would show the boy a simple example of the difference in speed between BASIC, PASCAL, GPL, FORTH, C, AL and whatever else you can come up with. This benchmark testing thread comes immediately to mind. http://atariage.com/forums/topic/248187-benchmarking-languages/?do=findComment&comment=3421682 , but there are probably better examples somewhere. I showed my nephew 6809 AL on my CoCo, then his parents bought him an Apple IIe+, and I showed him 6502 AL on that, learning it along with him myself. It was fun. He now works for IBM, developing VM compiler/interpreter software. I have some mixed feelings about that. I don't think he ever got into programming in AL, though. I just think it opened up other possibilities for him. HH

I am thinking that there would be a much larger difference between XB with no 32K and XB with either of the 32K RAM models, than there would be between the 8 bit 32K and the 16 bit 32K. In fact, without disabling some of the wait states I would expect to find no difference between the 8 bit and 16 bit benchmarks. I believe this is because the 32K is located in the >2000 - >3FFF and >A000 - >FFFF memory space. These addresses are always wait stated unless there is a hardware override. From what I've read so far it would seem to be inadvisable to try to override the wait states when running the TI RAM in the PEB, or the daisy chain memory from TI. Both are totally dependent on the extra time provided by the wait state generator for reading. Writing to them is not so problematic, if I remember correctly. I'm surprised the performance penalty for using VDP memory for XB doesn't make more of a difference. I guess that just means the performance penalty for using the slow RAM is quite substantial as well. Do you know how many, and which of the wait states were disabled during these tests? HH

I use Linux almost exclusively. I consider it far superior to Microsoft's Windows. When I've gotten a few hardware issues solved I was thinking I would have to have something like Linux to manage it. I am still planning on that, and I was going to model it after the NitrOS9 operating system designed for the 6x09 microprocessor. It has some pitfalls that I hope to avoid such as their commitment to 256 byte sectors, which makes hard drive access a small problem. Here is a technical spec that describes how they do their drivers, file systems, etc http://www.nitros9.org/NitrOS-9_Technical_Reference.pdf. The RBF manager is the part that addresses the disk drive issues. There might be a few good ideas in there for you. I know I always liked it. I know almost nothing about the way Unix/Linux file systems work. When I ask myself how they work the answer is usually, "They work good." They all seem to use inodes, though. Aren't inodes an integral part of how Unix/Linux implement hard links? Having two directory entries that point to the same inode, and thus the same file? Do you have a guide to how you're allocating the metadata? I've been popping into this thread to check for an update for several weeks now. I hope you aren't going to give up on this. I've got it set up to notify me via email now. I hope to see something more soon. HH

I'm not certain it will work. My understanding though, is that the CRUCLK synchronizes the CRU signals when writing to the CRU. Reading from it is governed by another combination of signals, which I unfortunately can not remember, and I don't know where I read about it. Neither is dependent on the CLK input, though. I could very well be wrong. My memory ain't what it used to be, and maybe it never was. I can't remember. None of the chips I ordered have that "-40" suffix, but I'll have to try it anyway. I'm looking at the possibility of making that CLK variable by dividing down from a 6 Mhz clock. That will give me a granularity of 10.6667 uS if the 9901 will take the full 6 MHz. Dividing by 12 will give me the low end for the CLK (2000 nS, 500kHz), according to the data sheet. Thanks for looking out for me, HH

I ordered 5 TMS9901's at about 2:30 this morning. Don't worry, I don't think I'm going to use them all in just one machine. I might put two of them in this one, though, for a total of three. Piggy-backing is a good idea. I'll check any pins I use for connections to Vcc, Vss, or anything else. Thanks for the tips. I plan to cut/pull at least one trace/pin for my chip select signal on the 9901 anyway... I'm going to map them in at >40 - >7E, and >80 - >BE. I'll use a 74LS138 or 74LS139 (1/2) to further decode the addresses. I'm thinking of connecting a higher frequency to the clock input of the second 9901. Anyone know what the upper frequency limit is on the 9901? I gave the datasheet electrical specifications a quick look. There were no MHz units to any of the specs, but the nominal clock cycle time is 333 nS(3 MHz), and minimum is 300 nS(3.3333 MHz). I know the TI99 has been over-clocked at 3.579545 MHz and 4 MHz. I think that would have changed the clock to the 9901 as well. Any of you over-clockers ever check to see if there is any trouble with the 9901 TIMER while running above 3.3333 MHz? HH

This is my console CRU map (attached). I created this to help me keep all this straight. I hope it helps at least one other person. Here is where you can download a datasheet for the TMS 9901: http://pdf1.alldatasheet.com/datasheet-pdf/view/29080/TI/TMS9901.html This manual is helpful with a number of 99er questions: https://archive.org/details/tibook_hardware-manual-for-the-texas-instruments-994a HH TI99.console.CRU.map.html.tar.gz

Not many, I imagine. But, I don't intend to leave them out just because they don't have the resources that I have. This guy didn't get a lot of help from any of your community way back in 2011: http://atariage.com/forums/topic/190799-ti99-format-disk-program-help/?do=findComment&comment=2414652 Of course, it does look like he didn't give you much time to do so, though. He decided to send his Disk Manager to his friend before the day was over. But a cassette/WAV solution would have gotten him going pretty quickly. From what I've seen, it may even be possible to send the audio over a quiet telephone line. Has anybody ever tried that? A cassette based diagnostic program or a formatter might have helped this guy get an answer in less than the month it took: http://atariage.com/forums/topic/224267-well-i-finally-got-myself-a-peb-but/page-2?do=findComment&comment=2997349 I was in need of a cassette/WAV file based solution for formatting a few disks just a few weeks ago: http://atariage.com/forums/topic/190799-ti99-format-disk-program-help/?do=findComment&comment=4158260 I didn't get a Disk Manager with my PEB. Fortunately, I went looking through all the stuff I had bought years ago for a TI99/4A, and found a FlashROM99. Then it was easy, but if I hadn't found that, who knows how long I would have been working on just getting a floppy formatted? Until I did, I didn't even know if the floppy drive, or the PEB, worked! We are members of a community that could shrink rapidly. The numbers are what drives much of the development that has happened for the TI99, progress that will hopefully continue into the future. Ignoring the plight of any curiosity seeker (me), collector (me again), I-couldn't-afford-one-then-but-I-got-one-now (not me, didn't want one back then), etc. doesn't help increase our numbers. That's your argument, not mine. I can look back, and I remember a co-worker telling me about how slow the TI99 was. I saw one at a party later on. I might have been the only one there that was interested. I had a CoCo1 and a TRS-80 Model 1. The TI99/4A didn't impress me. This thing was running on a clock that was more than 3 times the clock in my CoCo (.895 MHz), and almost 70% faster than that of my Model 1 (1.79 MHz?). And it was crawling!!! I said, "What a piece of s__t!" Yes, I said it out loud. I'm much more diplomatic these days, though. I use emoticons. It doesn't take a crystal ball to see the future when you're looking at that kind of evidence. But now, 36 years later?, party was in '82 maybe '83?, ... I think the TI99/4A has far more potential than has been tapped. After looking it over, I'm wondering if some of the engineers might have thrown a couple of curves around their upper management, making it possible to perhaps double its speed, with a few simple mods. Thierry Nouspikel experimented with several wait state eliminations. http://www.unige.ch/medecine/nouspikel/ti99/wait.htm I'll start with those, but AFAIK he didn't go as far as I am looking to go with it. There's a lot of stuff on his web site that I haven't looked at yet, though. I'm going to modify one, or more, of the units I have (20+ TI99/4A's? and one PEB), just to see what this box could have been if it had been targeted at a different marketplace, or conversely, what it never could have been. Several mods don't even seem to be that difficult, especially since Thierry has done a good deal of heavy lifting for me. HH

I'm planning to do some upgrades to one of my consoles, so I was looking at the CRU for available bits. It looks to me like there are 3 available, but I ran across an upgrade(s) document from Thierry Nouspikel that claims there are only two. The two that he points out are a subset of my conclusion, I am happy to say. But I have a great deal of respect for his opinion, so I'd like to get some of your opinions on mine, some time before I start hacking into this console. To start, I agree that output bits 16 & 17 are available. In addition to those, however, it looks to me like bit 26, which appears on pin 29, is fair game, too. Bit 12 is also connected to pin 29, but that is for input or INT. I would be configuring it for output. According to the datasheet and the schematics for both the /4 and /4A, bit 26 is connected to pin 29, which is pulled HIGH by 5VDC through a 10K resistor. It has no other connections, unless BOTH of the schematics I have are in error. Is this bit available for a project, or is it commonly, or even occasionally, used for something else? Facts or opinions? In the same doc from Thierry, if I remember correctly, he alludes to some unused NOT gates. Does anyone have, or know of, a list of logic gates in the original console, of any type at all, that weren't used? HH

TI99/4A. I was told back in the day that it was slow. At first when I bought one, several years ago, I had to agree. After looking it over some recently, I've decided it's not so bad. I think it was just some unfortunate decisions in TI management that crippled it. It's a weird machine, but in my opinion the console has a great deal of untapped potential, and a good deal of room for improvement. The PEB looks to me like it has even more unused potential than the console, without any upgrades to its hardware. I think it's going to be a lot of fun for me to explore its possibilities. HH

Language First Pass Optimized GCC 15 sec 5 sec Assembly 17 sec 5 sec TurboForth 48 sec 29 sec CAMEL99 DTC 49 sec 27 sec Compiled XB 51 sec 37 sec CAMEL99 ITC 55 sec 29 sec FbForth 70 sec 26 sec GPL 80 sec none yet ABASIC 490 sec none yet XB 2000 sec none yet UCSD Pascal 7300 sec 273 sec What's your point here? GPL is running, at best, 21.25% of the unoptimized assembly language speed. That's kind of like saying that my car can make 45 MPH, so it's ready for the Indy500, isn't it? And that's ignoring the optimized speed difference of both GCC and ASM. Sixteen times the speed of GPL is a pretty good case for disposing of GPL in favor of the much faster ASM, or if you wish, GCC which would be a much larger binary. GPL was only necessary when we only had 256 bytes of directly addressable memory. RAM is much cheaper now. You can buy two 32K SRAM for less than $10. I have at least a dozen that I cannibalized from an older PC. It's time to drop GPL, replace the ROMs that have tied this console to slow GROMs, and GRAMs. Would we have to re-write the ROM ourselves? Yes, let's do that. Then we could cut away grounds and +5V inputs on the interrupt lines and have the 16 levels this CPU was designed for. There would no longer be a need to constantly poll the VDP chip to see when the vertical interrupt has occurred, because we could use the interrupt to almost instantly respond to it. There is also a timer in one of the chips (9901?, I think?) that looks like it could be very useful, if we could use it without the performance penalty imposed by the current, 40 year old, inadequate-off-the-shelf, system. There are a great many reasons why the TI99 lost to the Commodore PET, and the lack of speed was only one of them. This thread's focus is done. I haven't found the answer to EA II's inability to do COPY on my machine, but RAG is doing fine. RXB, if you wish to continue to beat this dead horse, please start a thread of your own. Sincerely, HH

Wow, RXB. That's a lot of code to splash onto the board at once. Tragically, it is mostly wasted on me, though it has given me an idea of how to find, and handle, my problem. I do not know the GPL language at all. I just know that it is slow, like all interpreted languages tend to be. I used to program in DBASE III/dBXL quite often, but when I got what I wanted I put it all through the Quicksilver compiler in order to speed it up. Everybody, PLEASE DO NOT START TALKING ABOUT DBASE LANGUAGES IN HERE NOW! Can you go back and edit that post so that it is a Spoiler Tag? As Tursi did here: http://atariage.com/forums/topic/248187-benchmarking-languages/?do=findComment&comment=3421682 That way anybody who is interested in looking at it may, all others are not inconvenienced by having to scroll down through screens of code. If you decide to post that other Editor Assembler GPL Source Code you might want to make it an attachment. Thanks, HH

I found this excerpt in the documentation that FarmerPotato sent me to: The cartridge also uses the VDP area to store PABs for file access, and to load the file themselves. PAB for Editor, Assembler, edited/printed file, assembly source file, loaded file: >1000-1018 PAB for assembly object file, printer: >1100-1118 PAB for assembly list file: >1200-1218 PAB for file copied during assembly (?): >1300 Assembly source file, edited/printed file: >1080-10CF Assembly code file data, printer data: >1180-11CF Assembly list file data: >1280-12CF Program files (Editor, Assembler, user-defined): >1380-157F It IDs RXB's addresses as PAB locations in VDP, all except the >1400 one. I don't think the E/A II that I'm using will accept the cassette as a source or destination, so I'm calling that one invalid. The rest were just misidentified a buffers. Perhaps the original E/A did accept the cassette, but my one attempt to use my copy of E/A didn't turn out so well, so I won't be trying that again too terribly soon. I'll have to rebuild my disk based E/A disk A from an image file first before I do that. From this it would seem that the >1300 location is the one that isn't working for me when I try to COPY in an external file. There is also this: | | >3580 +-------------------------+ | (free) | >35D2 +-------------------------+ <--- @>8370 | File buffers (4 files) | >37D8 +-------------------------+ <--- @>8370 | File buffers (3 files) | >3FFF +-------------------------+ VR0=0, VR1=E0, VR7=F5 It looks like there is at least the possibility that E/A will only reserve 3 buffers. All of which must be dedicated to a specific purpose, whether I use them or not? Apparently so. So how do I instruct the assembler to reserve 4 buffers? Or, are there different versions of the E/A that only allocate 3 buffers? I am using the E/A II that I downloaded for use with my FlashROM99, so I'm assuming it is a later version, but does it always only provide for 3 buffers? Thanks to all for the help so far, HH

I think your memory map is in error, but I can't seem to locate the document where I read about this. I know that a copy of the File Descriptor Record(FDR) is copied into the VDP memory space. I'm a little bit shaky on what the copy is called, but I'm calling it the FCB here. Doesn't there have to be a 256 byte space in there for the FCB for each open file? It is possible for the buffers to be shared, even if it is a bit messy, but I'm reasonably certain that the TI99 reserves 512 bytes in VDP for each file. Does anyone know where to find an authoritative source of information on this? Thank you, HH