Jump to content

Photo

TIImageTool 1.5

TIImageTool

32 replies to this topic

#1 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,196 posts
  • Location:Germany

Posted Thu Aug 1, 2013 4:48 PM

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 by mizapf, Thu Aug 1, 2013 5:13 PM.


#2 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,751 posts
  • Location:Denmark

Posted Thu Aug 1, 2013 10:27 PM

Cool :thumbsup:

#3 ti99iuc ONLINE  

ti99iuc

    Stargunner

  • 1,099 posts
  • Location:Italy

Posted Fri Aug 2, 2013 8:58 AM

good job ! :D

#4 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,527 posts
  • Location:Eagan, MN, USA

Posted Fri Aug 2, 2013 10:34 AM

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.

#5 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • 1,055 posts

Posted Fri Aug 2, 2013 5:34 PM

...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 :).

#6 slinkeey OFFLINE  

slinkeey

    Moonsweeper

  • 475 posts
  • Not a Gamer
  • Location:Racine, WI

Posted Tue Jan 13, 2015 10:29 PM

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 by slinkeey, Tue Jan 13, 2015 10:44 PM.


#7 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,053 posts
  • Location:Silver Run, Maryland

Posted Wed Jan 14, 2015 7:54 AM

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



#8 slinkeey OFFLINE  

slinkeey

    Moonsweeper

  • 475 posts
  • Not a Gamer
  • Location:Racine, WI

Posted Wed Jan 14, 2015 8:43 AM

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.



#9 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,196 posts
  • Location:Germany

Posted Wed Jan 14, 2015 9:26 AM

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.



#10 slinkeey OFFLINE  

slinkeey

    Moonsweeper

  • 475 posts
  • Not a Gamer
  • Location:Racine, WI

Posted Wed Jan 14, 2015 9:46 AM

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



#11 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,196 posts
  • Location:Germany

Posted Wed Jan 14, 2015 12:21 PM

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.



#12 ralphb OFFLINE  

ralphb

    Moonsweeper

  • 358 posts
  • Location:Germany

Posted Thu Jan 15, 2015 3:21 PM

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.



#13 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,053 posts
  • Location:Silver Run, Maryland

Posted Thu Jan 15, 2015 3:52 PM

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

 

...lee



#14 ralphb OFFLINE  

ralphb

    Moonsweeper

  • 358 posts
  • Location:Germany

Posted Fri Jan 16, 2015 10:16 AM

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.



#15 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,053 posts
  • Location:Silver Run, Maryland

Posted Fri Jan 16, 2015 10:46 AM

 

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



#16 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,196 posts
  • Location:Germany

Posted Fri Jan 16, 2015 1:13 PM

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.



#17 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,484 posts

Posted Fri Jan 16, 2015 1:57 PM

 

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.



#18 ralphb OFFLINE  

ralphb

    Moonsweeper

  • 358 posts
  • Location:Germany

Posted Fri Jan 16, 2015 2:51 PM

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.



#19 ralphb OFFLINE  

ralphb

    Moonsweeper

  • 358 posts
  • Location:Germany

Posted Fri Jan 16, 2015 2:56 PM

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.



#20 ralphb OFFLINE  

ralphb

    Moonsweeper

  • 358 posts
  • Location:Germany

Posted Fri Jan 16, 2015 3:01 PM

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.



#21 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,484 posts

Posted Fri Jan 16, 2015 3:46 PM

 

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 :)



#22 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,196 posts
  • Location:Germany

Posted Fri Jan 16, 2015 6:01 PM

 

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...-disk-from-java



#23 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,510 posts
  • Location:BUR

Posted Sun Jan 18, 2015 2:10 AM

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! :)

#24 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,484 posts

Posted Sun Jan 18, 2015 3:30 AM

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":

 

Attached File  allocation.JPG   47.2KB   1 downloads



#25 ralphb OFFLINE  

ralphb

    Moonsweeper

  • 358 posts
  • Location:Germany

Posted Sun Jan 18, 2015 4:50 AM

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.







Also tagged with one or more of these keywords: TIImageTool

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users