mizapf

You cannot execute jar files directly; they must be passed to the Java runtime. Hence the invocation of java. The UnsupportedClassVersionException means your Java runtime is outdated. Could you add the output of "java -version"? I'd expect this is some Java runtime earlier than 1.5, maybe 1.4 or earlier. As I need some classes from Java 5 (JVM 1.5), you'll have to upgrade this Java runtime, or you cannot run TIImageTool on that machine. I usually try to add error messages to the program which are self-explanatory to some degree, but this happens before my code is loaded.

ehm ...yes, octet-stream, sure. Many of these web server issues (concerning the download of files like disk images etc.) can be cleared up with a little server config work ... glad that it helped.

Well, because to err is human and to write crappy code is a particular form of that. We do have some bugs and bad designs in the TI ROMs, like the DSRLNK that is already in the console but always returns to the GPL interpreter, or the bug in the TI disk controller that produces unexpected bytes in the preamble, or the cassette routine that just happens to work correctly but actually has a big flaw in it.

So you don't use the file name stored inside the TIFILES file? (If there is one) I'd expect relying on the name in the host file system can cause trouble with the missing case sensitivity in Windows systems (while the TI file system is case-sensitive).

In the console you must provide the jar file as an argument to java. java -jar /Users/Patti.../tiimagetool.jar

Hmmm ... if you had DIS/FIX 80 files, TIImageTool would be able to output source files that can be re-assembled. For memory dumps (program format) this is not available, unfortunately.

I have not heard of problems with particular applications in MESS. Please allow me to point out that I included a disassembler in TIImageTool that can disassemble memory dumps (PRG), tagged object code (D/F80), and GPL. Maybe it can help you even better than DISkASSEMBLER.

You can export a single file with right mouse click on the file (show the context menu), then select "Save as TIFILES". You can export a complete disk with the Export function in the "File" menu. Select a target directory, then save. You get another dialog window that asks how the file names shall be created. Finally, you get a message window "Export completed successfully". I once suggested to use the extension ".tfi" for TIFILES format (as a general indication regardless of the tool or emulator), but there are also other extensions (like xmo, because Xmodem tools were the first to create such files) or none. BTW, the 1.5.0 you get from the "Get info" most likely shows the required Java version, not the release number of TIImageTool. The Export function works recursively, just in case you have subdirectories on the image.

This is an indication that an exception occured. Could you please run TIImageTool from a shell / command line and report what is printed there?

The diagnostic program cannot run with Editor/Assembler because of AORG >7120 at the beginning of the file. Unless, of course, you somehow installed RAM at that location. I'd expect that loading seems to work, but the console will lock up on start or do other weird things. The REF/DEF table will be updated, but points into the void. If you remove that line or do a AORG >A000 there is some hope that you can assemble it for E/A as usual, and it may run. Take care of the memory test routine; it must not overwrite the test program.

Hi Robert, what I know about the standard TI 32K is that the even bytes appear as 0xFF while the odd bytes are 0x00. That is, after power-up, memory words show up as FF00 FF00 FF00 etc. This is also emulated in MESS when you turn off the 32K console mod and instead plug in the 32kmem as a peripheral card. There was one case where this behavior made a big difference: The TurboPasc99 compiler and runtime refused to run when memory is initialized as 0000. And I remember that it was the time when I upgraded my console when I gave up on TurboPasc. What 32K mem are you using in real life?

Also here: Chances are better when you give me information how it failed (error message, for example).

It is START, but you should be more specific about "not get it working". BTW, tigameshelf delivers this file wrongly by text/html MIME type, not application/octet-string as would be appropriate. This can be defined in the webserver's conf file. I wondered why I get the file as a dump in my browser.

OK, there is one issue in the code: The reported CRU address is wrong. The bit it actually wants to complain about is 1304, not 1302, but as we see in the CRUERR block, it takes the R12 address, strips off the first 3 hex digits, moves the remainder to the high byte but divides by two: (0x1304 & 0x000f) << 7 This makes sense when you want to say: "Bit x", but they add the string "130" before (BASE). So if the address is actually 1304, we can see in the CRU map that this is the HANDSHAKEIN pin when reading, and doing a SBZ/SBO means to set the HANDSHAKEOUT (see Thierry's CRU map). I'd say this is not guaranteed to be equal. So maybe this is a false alarm. *** CRU BASE ROUTINE *** CRU INCT R12 SBO 0 TB 0 JNE CRUERR SBZ 0 TB 0 JEQ CRUERR CI R12,>130E JEQ PIO JMP CRU CRUERR LI R0,>169 LI R1,CRERR LI R2,11 BLWP @VMBW ANDI R12,>F SLA R12,7 LI R0,>1A9 LI R1,BASE LI R2,3 BLWP @VMBW MOVB R12,R1 AI R1,>3000 LI R0,>1AC BLWP @VSBW CRWAIT JMP CRWAIT

As far as I could figure out from the schematics of the 99/8, and in particular from the OSO chip, the chip is mainly a bus adapter that cannot do much more than converting 8-bit bus words in the console to 4-bit words on the Hexbus and back, and also processing control lines (like "bus available") or raising interrupts. IIRC at the other end of the bus there is a complete controller system together with another 9900 or 9995 that gets the words from the bus and executes some DSR. In MESS I implemented a simple version of the OSO mainly to avoid a lockup. Also, let's see what the schematics reveal. If there is a processor, it will also have some ROM, and this can be difficult to dump; probably only by taking out the ROM and reading it in a special device.

Judging from the diagnostic tool and from the schematics, the CRU Bit error message may indeed indicate a defect 74LS259 latch or other issues on the signal path. The error message is printed on the screen when the bit value read via CRU differs from the bit value previously written on the same address. Concerning CRU operations, it is not guaranteed that you can read the bits that you previously wrote with SBZ/SBO/LDCR. The circuitry must allow for reading bits via CRU and giving them meaningful values. In this case, we can actually read the latches values.

We already have the Hexbus ROM, but I still need to "guess" a suitable hardware for it; this is the main problem. Apart from the fact that there is still a lot of other things to do before. To do it properly, we need the schematics of a Hexbus floppy. Unlike our 4A peripheral devices, the Hexbus devices are more autonomous; they have an own CPU with a device operating system. On the other hand, as we only have high-level commands on the Hexbus, we can do something like an "abstract floppy drive", that is, when we have a command like "read a sector", we'll deliver the sector contents from the disk image, and not involve a complete disk controller emulation.

You can see Exbasic II in action in the TI-99/8 emulation in MESS. However, at this time you cannot use floppy support because we still need a Hexbus floppy emulation. The DSRs on the existing controller cards do not work with Exbasic II. Briefly, Exbasic II sets up the PAB in CPU RAM instead of VDP RAM, and finally locks up; you can start it when you don't plug in any controller for now. On the Geneve we have ABASIC.

But these are already two features: separate windows and DnD. :-) I have them on my list; for that reason I'm counting with 1.5x instead of going to 1.6 because this is my plan for the next release.

Yes. The RS232 card uses bit 7 to control the LED. Unlike other cards, it does not light up when the DSR is active. Bit 7 at base 1300 is 130E. This also explains why nothing can be seen on the LED when setting 1300. I don't know what exactly is tested with the diagnostics. Maybe you should have a look at http://nouspikel.group.shef.ac.uk/ti99/rs232c.htm#CRU%20map which lists all bits with their meanings. Bit 1302 is used for PIO, not RS232. (Why is the forum software always messing up weblinks??)

Well then, if you have Java anyway, why don't you try TIImageTool? This is one of the use cases I wrote it for. You can "export" the disk image to your host file system and get a collection of TIFILES files. I guess this is what you want ot achieve. Works with sector dump images (v9t9) and track dump images (pc99).

I never had any contact to Spectrum users, most had a C64, I had some contacts with fellow TIers, but I was always wondering how the Spectrum compared to the TI. Now with MESS, I finally had a chance to get a glimpse, but the first impression was quite, well, modest. In fact, now I know that our TI has a fairly pretty presentation with its master title screen, module selection, and the Basic. Although, as we know, the stock console has its disappointments, without any doubts. So if you had a Spectrum, how did it "feel" like? (Apart from the rubber keyboard.)

Why "dir"? - Quite simple: "ls -al" are two words, and they appear as two separate arguments. Also, I used "type" and not "cat" for a text file output. I don't want to imply that you get something like a shell with all of its functions. You may have noticed that "lsf" is an analogy to "ls -F". And actually, $ alias dir alias dir='ls -l'

Nice ... may I put that image in our ninerpedia? Do you have a bigger version?

I remember I had the ones with black button and an orange line around it, and I think the Texas Instruments name was white (but my memory can fool me). Today, I still have my Competition Pro, and when I recently opened it I noticed that there are no signs of aging, despite the groaning noise it makes when I play Munch Man or TI Invaders on MESS. But this seems to be merely caused by the rubber around the lever.