TIImageTool on Github

[+mizapf]

This is not a major new release; I just installed a repository for TIImageTool on Github:

 

https://github.com/mizapf/tiimagetool.git

 

For building you just clone this repository, get a recent JDK, ant, and a copy of RXTXcomm.jar. Build file is included.

[Omega-TI]

I've never tried TIImageTool. Is it something like TI99Dir?

[+mizapf]

It's free, so why not try and see? (oops, it rhymes)

 

This is essentially a Java-based disk image management tool. The emphasis is on disk images, TIFILES files must be imported into an image to work with them. Originally written by me to have a more functional replacement of imgtool (the tool that accompanies MAME), it may be useful for anyone working with disk images, also for other emulations.

 

You can find a link in my signature to get a recent precompiled version.

[+Schmitzi]

ah, precompiled works for me now thx

[Omega-TI]

Ahh, other emulations... got it. Okay, since I pretty much only deal with Classic99 and real iron and mostly in V9T9 format, I guess I'll stick with what I'm using.

 

Thanks for coming back with an answer. Sometimes I find it easier to simply ask a question of the knowledgeable people here, than to potentially waste a lot of valuable time jumping through hoops to install something, only to find out it does not suit my individual needs or purposes.

[+mizapf]

Yes, you will get the best usage experience with TIImageTool when you use it for its intended purpose.

[+Lee Stewart]

I've never tried TIImageTool. Is it something like TI99Dir?

 

One thing that TIImageTool can do that TI99Dir cannot (or will not) is construct a fragmented file when there is not enough room on the diskette for an unfragmented file. You probably don't care about this feature, but it was very important for me to be able to get all of the fbForth 2.0 support files on a 90KiB diskette image for distribution. This is actually proper behavior that real iron DMs have no problem indulging, when necessary. I don't think I ever complained to Fred about it because I had such an easy fix with Michael's TIImageTool.

 

...lee

[ralphb]

[...] TI99Dir cannot (or will not) is construct a fragmented file when there is not enough room on the diskette for an unfragmented file. You probably don't care about this feature [...]

 

Don't care? That means if I delete just one file on a disk, I wouldn't be able to use all the free sectors on that disk, no?

 

But maybe he just does it differently. xdm99, for example, just completely defragments the disk whenever it writes to it, so all files are always unfragmented, but you still can use the full capacity.

[+Schmitzi]

...so maybe we could need a "Defrag-Tool", one pure on the TI-side, and more on the DSK-side of the TIImageTool/TI99DIR-side ?

[ralphb]

...so maybe we could need a "Defrag-Tool", one pure on the TI-side, and more on the DSK-side of the TIImageTool/TI99DIR-side ?

 

No, all disk controllers (and TIIT) handle fragmentation just fine and can use the entire disk. And floppy disk fragmentation isn't as performance-degrading as it was for hard disks with FAT, either.

 

It's just an observation for TIDir (which I don't use myself, because Windows).

[+mizapf]

I found a new nickname for TIImageTool that does not somewhat sound weird: TIMT (see new package name de.mizapf.timt). Hmm. Speaking that word in mind, it reminds me of "Zimt", the German word for cinnamon.

 

...

 

Indeed, TIImageTool is best when used for managing image files, in particular copying/moving files from one to another, creating new images, sending/receiving by Xmodem from/to an image, and so on. For that reason it should be most useful for MAME/MESS users. For people who do not use disk image files, there are some few things that could be interesting:

• Direct file view (plain dump)
• TMS9900 and GPL disassembler
• Image viewer (TI Artist, MyArt, YAPP, Fractals)
• Using Xmodem to transfer files between the PC and a TI or Geneve
• File export from / import into a disk image

However, all is based on disk images. If you want a GPL disassembly, you have to import the file on a disk image first (which is not that difficult, actually, as there is drag-and-drop).

[+Lee Stewart]

Don't care? That means if I delete just one file on a disk, I wouldn't be able to use all the free sectors on that disk, no?

 

But maybe he just does it differently. xdm99, for example, just completely defragments the disk whenever it writes to it, so all files are always unfragmented, but you still can use the full capacity.

 

No. It just appears that TI99Dir, for some reason, refuses to allocate any file sectors inside the initially reserved FDR section in sectors 3 – 33. TIMT (I like it @mizapf!) has no problem doing that as, I presume, is the case with your xdm99.

 

...lee

[Tursi]

ralphb, on 15 Jul 2016 - 01:47 AM, said:

 

And floppy disk fragmentation isn't as performance-degrading as it was for hard disks with FAT, either.

 

On a real floppy drive, it's pretty painful. Every fragment means a seek back to the allocation sector, re-read, find the next block, and seek back to there. Especially if a file's near the other end of the disk, you're talking full seconds.

 

You likely wouldn't even notice a single fragment in a hard disk file, the data's cached and the seek time is measured in milliseconds.

[atrax27407]

There already is a defrag tool for the TI.

[+mizapf]

On a real floppy drive, it's pretty painful.

 

Oh yes, and since we implemented the full head seek and sector lookup timing in MESS, we sucessfully emulated the pain as well. With the sound output of the emulated drive you get at least an idea why it takes so long for loading...

[ralphb]

On a real floppy drive, it's pretty painful. Every fragment means a seek back to the allocation sector, re-read, find the next block, and seek back to there. Especially if a file's near the other end of the disk, you're talking full seconds.

 

Well, I totally agree. My statement doesn't really make sense, but I guess I mentally imagined a TI that loads a program once and runs that for hours, versus a PC with a hard disk running lots of different programs.

[RXB]

Hmmm written in Java right?

 

http://mashable.com/2016/01/29/java-plug-in-death/#hwnpZNrxi8q0

[+mizapf]

Yes, and it is a pretty good idea.

 

Rich, I explained on http://www.ninerpedia.org/index.php?title=TIImageTool (bottom of page) why there is absolutely no reason to be concerned about Java. Java is still a brilliant programming language (in my view) and much safer than C or C++.

 

The reports about security issues all relate to the Java Plug-in. This is the part of the browser that allows the browser to run Java Applets. TIImageTool is not based on Applets. It is a plain simple application that runs with the same level of security than any other application that you install on your computer. Thus, I recommend to check whether the browser has an active Java Plug-in and to deactivate it.

 

The fuss about Java security is justified to some extent, but in my view there is some ongoing FUD campaign (maybe from the usual suspects) against Java. The good thing about that is that we'll see the perishing of C# and .NET earlier, I am pretty sure. (Did I mention this is my personal opinion? )

[sometimes99er]

July Headline: Assembly Language enters the Top 10 again

 

 

http://www.tiobe.com/tiobe_index

[sometimes99er]

So I got version 2.21 off your signature.

I make a new floppy. File, New, Floppy image, Ok, name the image file zombi, Save.

I import ZOMBtiV033.txt by Sinphaltimus. Edit, Import files, Files of Type: All files, ZOMBtiV033.txt, Ok.

Also new to this release, TIImageTool will try to find out whether the imported file is a BASIC program. For this purpose it looks at the first ten lines (or less) and tries to parse them for TI BASIC and then for Extended Basic. When successful, it offers you a modified import dialog.

Well, I don't get a modified import dialog ?

[+mizapf]

"Modified import dialog" means it offers an option for TI BASIC and Extended Basic (beside the simple text option). If you refer to the new features (comment lines without line number), this is not yet committed.

 

Greater things are coming along... just give me one or two days.

[sometimes99er]

"Modified import dialog" means it offers an option for TI BASIC and Extended Basic (beside the simple text option). If you refer to the new features (comment lines without line number), this is not yet committed.

 

Greater things are coming along... just give me one or two days.

 

Ok. Created a very simple TI Basic program, and now the options shows up. Does not with ZOMBtiV033.txt - and I did remove the first blank line. I'll wait around then.

[+mizapf]

Dear friends, I'm proud to announce another release of TIImageTool, release 2.3 of September 2016. I believe it offers some pretty interesting features for you.

• HFE (Lotharek) image handling
• Search for files and content
• Enhanced BASIC program parsing
• Detect and fix CRC errors in track dump files
• Live console output window

 

1. HFE support (see attached screenshot). You can now open HFE images for your Lotharek floppy emulator with TIImageTool; no need to convert. As all image formats (sector dump, track dump, HFE, CHD) are treated in the same way, all operations are available, like copy/pasting between images, renaming, deleting, archiving etc. You can also create new images im HFE format.

 

2. Search for files and content (see attached screenshot): a feature that I was dreaming of for years. It does not need too many words for explanation; the screenshot shows basically everything that is available. Thanks to the Java library (java.util.regex), regular expressions may be used. Moreover, you can even search in file contents. The results are shown in a separate window, and when you click on one of them, the containing image is immediately opened and displayed.

 

3. Enhanced pasting for BASIC listings. Since MAME/MESS does not support pasting into the emulation (and probably never will), TIImageTool comes in handy and allows you to simply paste the BASIC listing into a file on the image. With the recent enhancements, you can paste lowercase BASIC programs and those that have interleaved non-line comments.

 

4. Detect CRC errors. Well, this is a remedy for the mess that TIImageTool caused when it was young. The Track Dump Format images (aka pc99) have CRC fields that are fixed to F7F7. TIImageTool and MESS allowed for using proper CRCs here, and messed them up with a bad CRC calculation. Since opening those files led to a pile of warning messages, I felt like cleaning up that issue.

 

5. Live console output window. The console output is useful when some obscure error occurs. Up to now, the window only showed the current log file, but did not update its contents. This is now enabled.

 

As always, it's free, you can get it on Github, on WHTech (pc utilities) or via Ninerpedia. Have fun, and take my apologies in advance for any issues that may appear with every new release of software. If you spot issues, please report them to me so that I can fix them soon.

 

[sometimes99er]

Example in post #20 paste fine in Classic99, and still does not import in new TIImageTool.

File ZOMBtiV033.txt cannot be imported

I then deleted the first blank line.

Error in line 800, column 10; use another BASIC version or save as text.

I then trimmed all trailing spaces.

File ZOMBtiV033.txt cannot be imported

I then removed all blank lines.

Error in line 0, column 0; use another BASIC version or save as text.

I then gave up.

 

Entering blank lines or trailing spaces with program lines is accepted, enters without error and run fine, in Extended Basic with both Classic99 and MAME/MESS.

 

Edited September 4, 2016 by sometimes99er

[+mizapf]

OK, I think I could successfully fix that. Please pull a new copy or download from WHTech or via Ninerpedia.

 

Concerning the trailing spaces, the BASIC parser was somewhat surprised that the number parser stopped before it reached the line end, so this was a glitch in my parser.

 

If you try to import the ZOMBti you will see that it works much better, but still fails. This is not my parser's fault, the problem is in the program text:

 

6830 CALL COLOR(#DET2,7):: ZHELTH=ZHELTH-2 :: IF ZHELTH>=1 THEN 7110
:: Score=Score+10::CALL DELSPRITE(#26):: CALL DELSPRITE(#det2)::  GOSUB 5230

I don't believe that this can be pasted into an emulator with the intended result. After "7110" there is a newline (Enter key) which terminates line 6830. Thus the next line is definitely not a valid BASIC line; it will be executed immediately and not be put into the BASIC program.

 

All this pretty BASIC authoring creates, in my view, malformed BASIC code. It looks nice, but it is not a syntactically correct TI/Extended Basic program which requires program lines to begin with a line number and which uses uppercase commands. For that reason, I had to apply some fixes because I assumed wellformed code as it would be output by LIST. This worked perfectly until you guys became creative.

 

But as I said, this double-colon at the line start may prove to be a vicious error, because when you paste that into an emulator you won't notice that these lines are not read into the program memory. I doubt that it makes sense to assume that a double-colon means to merge the text lines, when the Extended Basic parser won't react the same way.

 

[Edit: The error message now tells the text line where parsing failed.]

Edited September 4, 2016 by mizapf