TIImageTool 1.5

[+mizapf]

The time is now ... finally. This was my most delayed release ever. Originally planned for February, TIImageTool v1.5 is now ready for release.

 

You can get an overview of all functions at http://www.mizapf.de...iimagetool.html

 

Download the latest version from http://www.mizapf.de...tiimagetool.zip

 

New in this release:

• Picture viewer: TIImageTool can display TI ARTIST, MyArt, and YAPP pictures
  
• GPL Disassembler: As it says, allows for disassembling GPL binary code.
  
• Tagged Object Code disassembler: You can disassemble DIS/FIX 80 files.
  

The DIS/FIX 80 disassembler took quite some time, but I think it was worth the effort. Given a D/F80 file, it tries really hard to get a syntactically correct source code from it. In most cases you should be able to assemble the resulting source code again.

 

Although it most likely does not appear anywhere, it can cope with different memory scopes (program/common/data-relocatable).

 

Note that TIImageTool is not only useful for MESS users. It can be used for disk image management (file operations), can work with Archiver files, and contains full XModem support.

 

TIImageTool requires a Java Runtime version 1.5 or newer. A current Java 6 or 7 is fine. If you want to use serial connections you need the RXTX library.

Edited August 1, 2013 by mizapf

[sometimes99er]

Cool

[ti99iuc]

good job !

[+Vorticon]

Very nice! I have traditionally used Fred Kaal's TiDir for image handling, and it has a lot of the same basic functionality as TIImageTool, but the latter seems to have a lot more great options. I particularly like the archiver support and the serial file transfer support. I will definitely give it a try tonight.

[RobertLM78]

...I particularly like the archiver support and the serial file transfer support. I will definitely give it a try tonight.

The archiver support is superb! I have only played around with serial connections, but the fact that I can quickly make an archive of a bunch of files to send to the TI via MFM and Moserial has helped save me a lot of time - infinitely better than transferring one file at time .

[slinkeey]

I figured I would give this tool a whirl to look at a CF card from my NanoPEB.

 

These are the step I take:

-Start up TIImageTool 1.55

-Select [File] > [Open Device]

-Enter [/dev/sdb] as the device (That is what my CF card shows up as when plugged in.)

 

I get the following error:

-Defect or missing file system: Sector 196347 beyond image size.

 

Any suggestions?

 

Nevermind... I am using the wrong tool.. Woops..My Mistake.. It's not for CF cards.. Just CF7 images.... Sorry

Edited January 14, 2015 by slinkeey

[+Lee Stewart]

I figured I would give this tool a whirl to look at a CF card from my NanoPEB.

 

These are the step I take:

-Start up TIImageTool 1.55

-Select [File] > [Open Device]

-Enter [/dev/sdb] as the device (That is what my CF card shows up as when plugged in.)

 

I get the following error:

-Defect or missing file system: Sector 196347 beyond image size.

 

Any suggestions?

 

Nevermind... I am using the wrong tool.. Woops..My Mistake.. It's not for CF cards.. Just CF7 images.... Sorry

 

The CF cards for the nanoPEB and CF7+ have the same format. I am not aware that TIImageTool can handle the CF7+/nanoPEB format. You can use Fred Kaal's TIDir to work with those images on a PC.

 

...lee

[slinkeey]

Guess I need to get a Windows box, or try it in Wine, or try diosbox for the dos commands that come with the nanopeb.

[+mizapf]

TIImageTool can handle images on drives that are similar to normal disk images, which means that it expects a volume information block at sector 0. I did not yet include support for CF7+. The error message about the sector beyond the image size means that TIImageTool tried to interpret some contents of the CF card as a file descriptor which are actually something different.

[slinkeey]

Sorry about this... It is my fault for using the wrong tool for the job.. Nothing wrong with TIImageTool.

[+mizapf]

On my list, will be added later. The main issue with that format is that - if I remember correctly - it contains multiple volumes, each of which has its own file system. This differs significantly from the other images that can be handled in TIImageTool, so it is more than just adding an adapter.

[ralphb]

My apologies to mizapf for butting in here and hijacking his thread, but I would like to point out to slinkeey that I've just added CF7A support to the xdt99 tools mentioned in another thread here. It's an additional tool called xvm99, which can read and write disk images to and from CF cards, but also supports all the xdm99 commands for manipulating files within the volumes. Make sure to download xvm99.py in addition to the main release.

 

Are there any CF7A/nanoPEB experts here? The disk images that my CF7A+ uses look somewhat strange to me ... They have 1600 sectors (which doesn't match their geometry, but that's OK), and entering any other sector count into the disk image will make TI Disk Manager (the real, physical one) miscalculate both free and used sectors in the catalog. Never mind the used count, but how could the sum of used and free possibly differ from the total count stored in disk sector 0?

 

BTW, Michael, thanks for the TIIT, it's really a great tool and offers amazing functionality beyond simple disk management! I gladly used it as a reference to generate some unit tests for my cross-assembler and my TIFiles handling routines.

[+Lee Stewart]

See >HERE< and surrounding posts for a discussion of Total-, Free- and Used-sectors reporting by the DSR.

 

...lee

[ralphb]

See >HERE< and surrounding posts for a discussion of Total-, Free- and Used-sectors reporting by the DSR.

 

Thanks for the pointer! That's probably not quite the issue, though -- file sizes are correct, and the disk count is not just off by 1 or 2 (for sectors 0 and 1, respectively).

The behavior I've observed with the CF7A is that changing the number of TOTAL sectors stored in sector 0 at >0A changes the SUM of free and used sectors reported by DM2. This happens despite the allocation map being set to >00 for sectors beyond 360.

 

For example, when I transfer an SSSD image with 39 used sectors (of 360 total) to my CF7A then DM shows 1561 used and 333 free sectors, and both numbers are incorrect. There's also some garbage character before the 333, probably caused by an overflow. When I patch the sector count to 1600, DM correctly reports 39 used sectors.

But I think that your comment about DSRs yields the solution to this puzzle. Based on my observations I assume that the DM module queries the disk drive for the free count instead of calculating the used count itself. The CF7A DSR correctly counts the number of used sectors, falsely assumes 1600 total sectors, reports an overblown free count to the DM, the DM subtracts the overblown free count from the correct total count. This results in an underflow and both free and used count shown are wrong.

 

So in the end the CF7A is to blame.

[+Lee Stewart]

 

Thanks for the pointer! That's probably not quite the issue, though -- file sizes are correct, and the disk count is not just off by 1 or 2 (for sectors 0 and 1, respectively).

The behavior I've observed with the CF7A is that changing the number of TOTAL sectors stored in sector 0 at >0A changes the SUM of free and used sectors reported by DM2. This happens despite the allocation map being set to >00 for sectors beyond 360.

 

For example, when I transfer an SSSD image with 39 used sectors (of 360 total) to my CF7A then DM shows 1561 used and 333 free sectors, and both numbers are incorrect. There's also some garbage character before the 333, probably caused by an overflow. When I patch the sector count to 1600, DM correctly reports 39 used sectors.

But I think that your comment about DSRs yields the solution to this puzzle. Based on my observations I assume that the DM module queries the disk drive for the free count instead of calculating the used count itself. The CF7A DSR correctly counts the number of used sectors, falsely assumes 1600 total sectors, reports an overblown free count to the DM, the DM subtracts the overblown free count from the correct total count. This results in an underflow and both free and used count shown are wrong.

 

So in the end the CF7A is to blame.

 

AFAIK, you cannot change the size of a CF7/nanoPEB disk image! They must be 1600 sectors, which uses all of the allocation bitmap. The way I copy disk images that are other than 1600 sectors to a CF7 CF is to use TIDir to copy files from one image to a newly created CF7 image—then copy the new image to the CF7 card. I believe that TIImageTool can be used to copy the files; but, I am not sure that it can create a 1600-sector image. I know it cannot yet copy the image to the CF card. Someone like Fred Kaal (@F.G. Kaal) or the CF7+/nanoPEB designer/builder, Jaime Malilong, would need to weigh in for more detail and how (if it is possible) one might copy a non-standard, smaller image to a 1600-sector image.

 

...lee

[+mizapf]

The problem with writing to the CF card was that it works under Linux if you have write permission on the device (at least as root), but I was not able to make Windows write to the raw device.

[+InsaneMultitasker]

 

Thanks for the pointer! That's probably not quite the issue, though -- file sizes are correct, and the disk count is not just off by 1 or 2 (for sectors 0 and 1, respectively).

The behavior I've observed with the CF7A is that changing the number of TOTAL sectors stored in sector 0 at >0A changes the SUM of free and used sectors reported by DM2. This happens despite the allocation map being set to >00 for sectors beyond 360.

 

 

This caught my eye. The DSR relies upon the allocation bitmap to compute the free and used sectors. If the problem is with the CF7 DSR, then the author most likely hard-coded the bitmap allocation routine to count all allocation units versus stopping at the total sector count.

 

You could try setting the bitmap to '1' for each allocation unit beyond 360 and set the total AUs to 1600. Your total count would then be inaccurate but your free count would match what is available. This would allow you to use the smaller image, albeit with some extra work.

 

The DSR fix would be to use 1600 or the total sectors, whichever is smaller, as a comparison point.

[ralphb]

AFAIK, you cannot change the size of a CF7/nanoPEB disk image! They must be 1600 sectors, which uses all of the allocation bitmap. The way I copy disk images that are other than 1600 sectors to a CF7 CF is to use TIDir to copy files from one image to a newly created CF7 image—then copy the new image to the CF7 card. I believe that TIImageTool can be used to copy the files; but, I am not sure that it can create a 1600-sector image. I know it cannot yet copy the image to the CF card. Someone like Fred Kaal (@F.G. Kaal) or the CF7+/nanoPEB designer/builder, Jaime Malilong, would need to weigh in for more detail and how (if it is possible) one might copy a non-standard, smaller image to a 1600-sector image.

 

Lee, extending the image to 1600 sectors before copying is no problem at all; in fact this is what my tool now does automatically. Works like a charm, and there is no need to copy files individually.

 

I was just confused why both sector counts were off when all the other data looked fine, but your remark about the DSR was the missing piece.

[ralphb]

The problem with writing to the CF card was that it works under Linux if you have write permission on the device (at least as root), but I was not able to make Windows write to the raw device.

 

Michael, not sure about Java, but for Python on Windows (1) the user has to be an Administrator and (2) you need to open the device with "r+b" instead of "wb" for writing, or it won't work. Maybe it's something similarly silly for Java?!

 

In any case you still cannot seek relative to the end, so there is no way to tell the size of the device and how many volumes there are.

[ralphb]

You could try setting the bitmap to '1' for each allocation unit beyond 360 and set the total AUs to 1600. Your total count would then be inaccurate but your free count would match what is available. This would allow you to use the smaller image, albeit with some extra work.

 

That's a clever way of enforcing a smaller image on the CF7A! Sadly it won't work for programs that may decide to "defragment" the floppy when writing to it (not that I know of any such programs ...).

 

In practice, having larger disk images is probably not really a problem unless you want to transfer an image from the CF7A back to a physical disk.

[+InsaneMultitasker]

 

That's a clever way of enforcing a smaller image on the CF7A! Sadly it won't work for programs that may decide to "defragment" the floppy when writing to it (not that I know of any such programs ...).

 

In practice, having larger disk images is probably not really a problem unless you want to transfer an image from the CF7A back to a physical disk.

Defragmentation should not be a problem, as would be based upon each file's FDR (file descriptor record) and the open sectors. Used sectors not allocated in the FDRs would by definition be unmovable.

 

When I get home I'll have to pull up some of my old documentation. I had thought that the bitmap bits beyond the last available sector were supposed to be set to '1' so that the total AUs and total bitmap were consistent. This may be a standard not everyone adhered to, or a standard that was not followed. Pretty much a moot point I suppose

[+mizapf]

 

Michael, not sure about Java, but for Python on Windows (1) the user has to be an Administrator and (2) you need to open the device with "r+b" instead of "wb" for writing, or it won't work. Maybe it's something similarly silly for Java?!

 

In any case you still cannot seek relative to the end, so there is no way to tell the size of the device and how many volumes there are.

 

I'm using a java.io.RandomAccessFile; in Linux it suffices to open /dev/sdX (whichever is the name of the CF card) for reading or writing; the latter requiring to launch TIImageTool as root. For Windows I'm getting a FileNotFoundException when writing.

 

Just had a look ... the problem seems to have hit other people as well. One of the answers seems to be useful ... I should keep a bookmark.

 

http://stackoverflow.com/questions/2108313/how-to-access-specific-raw-data-on-disk-from-java

[Tursi]

When I get home I'll have to pull up some of my old documentation. I had thought that the bitmap bits beyond the last available sector were supposed to be set to '1' so that the total AUs and total bitmap were consistent. This may be a standard not everyone adhered to, or a standard that was not followed. Pretty much a moot point I suppose

They're set to 1 on all the images I ripped from my old system (TI Disk Controller) - not something I had looked at before!

[+InsaneMultitasker]

Below is the section regarding the bitmap and setting the unused allocation units to '1'. This confirms the bitmap should essentially match the total allocation at the time of initialization. From "Software Specification for the TI/994 Disk Peripheral":

 

[ralphb]

Below is the section regarding the bitmap and setting the unused allocation units to '1'.

 

Excellent info, thanks for looking it up! I've adjusted my xdm99 tool accordingly, and now Disk Manager reports the correct number of used and free sectors for small CF7A images as well.