sjt

Do not under estimate Gazoo

It's certainly possible to have shorted ram chips. most often they are just "stuck" However when in circuit the excessive current draw should give them away easily, they will cook. I've found that it's not hard to slip when placing chips over others, bridging pins. That's why you must exercise extreme caution when using this method. Check it carefully before turning on the power. Out of the circuit, you should be able to detect a shorted condition. Simply take a known good chip and make a resistance chart. Any abnormality from the known good chip would indicate an issue. However, there may be variances between chip manuf. If your sure you put a chip over another and the pins were not bridging,and it blew a regulator, it stands to reason that you must have low resistance to gnd on pins (pretty much a dead short) . As you know those chips have 3 supplies. If you socketed a board and placed 1 chip at a time in, unless the chip has a dead short, it should not take out a regulator. If it does you should have been able to read that on your meter Another thing you can do is run the board using a bench supply and current limit the +5,-5,+12 supplies.

Yes, senior falcon your right. The max of an individual data line is limited to 155 but 2 data lines can be added together to achieve larger data strings. The program I wrote takes this in account now, if the 2 strings generated can fit in the boundary of one data line they are combined. Otherwise the data is split into 2 data lines. Simply read as A$,B$ C$=A$&B$ Call say(,C$) I learned this the hard way, if the data line exceeds that limit it trashes the merge file Steve

Thanks for everyone's help. I decided the easiest way to do this was take the hex data, put it in merge format to be placed at the end of A XB program I wrote. It recodes it and writes out a new merge file using tokens. (Sounds more complicated than it is) I take the raw hex data in lines of text- Byte format, ex. Byte >FF,>FE,>00 etc change the line begining for each to example -9000 DATA FF,FE,00 etc 9010 etc etc Simple search and replace. I then save that in merge format. (using classic99) That file gets merged with the XB program I wrote and outputs a new merge file with the data now in a couple of complete strings and a small header to speak the data, and display it. As it stands I have it limited to 240 bytes, in a max of 120 byte chunks. Just made it easier to break up phrases. While I'm playing with it. Eventually it could write out 252bytes of data + string header to conserve space, and read instructions etc The attached file shows the result. This will only work reliably on an actual TI computer with speech of course. On win994a it will try to work but will have trouble most often and not be able to speak it twice I removed the tokenized header that is created by my conversion pgm and added a few lines to allow it to be spoken using both methods. Sounds pretty much the same. SHALLWEPLAY.zip

To test the ram, use a known good chip ,bend the pins in and place over the ram in question. Look at the screen of the computer under test. If the display changes, replace that chip. If it still doesn't look right continue testing. This is not 100% effective, but will answer the question more often than not. Steve

Here is a disk to help get anyone started using a supercart. I have added patched loaders for disks 1-5. This was written long ago. I think the author may no longer be with us. (Robert Jones) If anyone out there has the source, it could be changed to page results. For now you are limited to one screen. The utility on this disk will read any programs on a disk, those that can be loaded into the supercart can be selected from a menu. You select what you want to load and press a single key...and it's done supercart1.zip

That speech is a fairly close representation of the speech at the end of the arcade game. Glad you like it. BTW I read the developers had trouble creating speech for the game, and chose to use the garbled speech to match the speech balloons in the game. Also the character is designed the way it looks because it was suppose to shoot using it's nose. PM me if I can help

I use one I built to load older 8k cart software and newly developed 8k software that loads from that >6000 space on the actual hardware. With a menu driven loader I can change the software in the cartridge in seconds on the TI, versus writing a new eprom. I have built multibank supercarts (hard switched) in the past, but with multicart menu software you can take the developed 8k program and add it to others and create a multicart. You can use one of Ksarul's boards, or if you want a challenge make a multicart eprom cart out of a duplicate game cartridge for fun Steve

A friend suggested a program called MAGICFM with a serial cable form PC to TI to transfer programs

The disk image will run under win994a , with speech. (You must turn on the speech under prefs) Maybe someone else can jump in on the best method to get it onto your 994a. I transfer the file by network to another computer with a 3 1/2 drive and use a program called TI-99pc to create a floppy for my TI system. If you only have the 5 1/4 drive, not sure what the best method would be. Hopefully someone will step forward to help you.

As a test I added _bert speech to the exit as found in the game. I'm a bit rusty on Xb programming, what can be used to compile a XB program? RBERT2.zip

The program Willy suggested would work to create the data. (I've used it with slight modification) But it is a slow process, and then reading it into strings to use the data will be very slow. I think the faster way to handle the data is to use tokens and create a dv163 merge file. The data would be in the form of a single string Read as text. DATA " (ascii representing hex values) " A string converted and written in dv163 format would look something like this: disregard the\ lines \0001\93c8\string length?\hex for data in string format"chr$(2)etc &chr$(255)" line# data Writing 255 stored as FF not stored as 32 35 35 Is it possible to do this inside the xb environment Does this make sense? Steve

In this case I was looking to incorporate raw speech data in XB . Which can be substantial in size.. Though there may be a limitation of the max data that can be sent to the synthesizer at one time using XB , maybe 256 bytes? Steve

Sometimes99er, That's pretty much exactly what I need to do, however the hex data will be created outside of magellan. Though it would require a lot of typing, can hex data be entered by hand and then used to create a merge xb file? The data would not be graphics. I've seen some older programs where data lines were in XB programs in this format. I assumed there was some utility out there? I think sometimes there were separate data files that accompanied the main program and this method was employed to put the data inside the xb program so they data would not be separated from the program as it was shared with others Does this make sense?

XB programmers Is there an easy way to convert data that is in hex format to DATA statements in XBASIC. Is there a program that can convert hex data to tokenized data statements? If I have a block of data that is in hex format but want to have it read by xbasic, Not as a separate file, but part of the extended basic program. it can be in data statements, correct? It will not make much sense looking at it since some codes will not be valid text characters but xbasic can read the data in that format. EX. BYTE >FF,12,01,FE,02 ETC ETC TO...... DATA "........" One more thing is there an easy way to delete blocks of XB lines from a program

I never tested this on Mess. It will run under Win99 and loaded into a cartridge and run on real hardware. (supercart or eprom in a cartridge, should work in a multicart, though it will take up a bunch of screen positions)

Most likely it's a bad video ram chip. Get a known "good" chip , bend the pins slightly in and place it over the top of each ram. (all pins must make contact) Note: there could be more than one bad. When you hit the bad one the screen will improve. Steve

Thanks Mark, and thanks again for your help.

I was having some fun playing with speech on the TI and threw together a speech demo cartridge of some LPC data I was working on. This could be added to a multicart, run as a 8k eprom cartridge , put in a supercart or run under win99 (file included) as a cartridge. It should run with just the console, speech synthesizer and programmed cartridge (eprom/multicart/supercart) Steve SPEECHDEMO1.ZIP

If anyone out there has a supercart, or wants to build one, this is a great utility. i uploaded a altered loader disk here that has additional patched files that will allow the SUPERCART loader to be moved to DSK2. Once on DSK2 , all files will be scanned there, cataloged and made available to load into a SUPERCART. The original program was written by Robert Jones. (Anyone have contact info?) I think the loader may be Barry Boone's? At this moment I don't know how many files can be cataloged by the program. This could also be moved to other drives as well with file program edits. The loadable cartridge program files are (33sectors) in size, they are raw 8K rom cartridge bin files. They can be any program that has been written to run from that cartridge block of memory at >6000 I added a RUN Program selection to a horizons ramdisk menu to load it with one keystroke. SUPERCART1.ZIP

Done!!! Thank You... You were 100% correct. It was at the program start. I can now alter it to run from where I want it to. Including off of a ramdisk. I just finished a supercart to play with. Steve

I'm trying to re- direct disk access from DSK1 on an assembled EA5 program. The program catalogs (DSK1) [uTIL1] and then passes a file selection to a loader [load1] that loads the >6000 space (supercart ram) I have been able to redirect the loader to load from DSK2 for example. And I have redirected the selection on the cataloging program to select the loader on DSK2. That was done using a Hex editor and simply changing the obvious calls to DSk1. But the cataloging program which is named util1 which was meant to be called from the editor assembler. By selecting option 5 and enter it launches the (UTIL1) program, In turn it catalogs dsk1, offering menu selections designated with letters abc...etc Making a selection from the disk catalog causes the Load program to load that file into the >6000 space. I can not figure out how to place all the files on say DSK2 have it it work correctly. Somehow the UTIL catalog program reads DSk1 , though there are now NO obvious calls to DSK1 after it has been edited. I couldn't find a disassembler, to try and shed some light on how this is done. Anyone out there addressed something like this before? Does the floppy controller dsr default to DSk1 access? unless directed otherwise? Of course , if someone out there has the source for these programs it would make this much easier.

Does anyone have contact info for Robert Jones?

I've already said yes to this one.

Looking for 3rd party TI 99/4a hardware. Working or Not. Horizons, Triple tech,MBP, Morning Star etc. PM me if you have something. Steve