Jump to content











Photo
- - - - -

How to read-out FAT12 lookup-table?

grub4dos

  • Please log in to reply
34 replies to this topic

#26 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 February 2022 - 02:51 PM

Yes and no, it is is "implied" in the way these numbers are interpreted, two's complement:

https://en.wikipedia...wo's_complement

 

Try this:

calc 0x7FFFFFFF

echo %@retval%

calc 0x7FFFFFFF+1

echo %@retval%

calc 0x7FFFFFFF+1

calc %@retval%-1

 

calc 0x7FFFFFFF+2

calc %@retval%

 

calc 0xFFFFFFFF

calc %@retval%

 

 

calc 0xFFFFFFFF+1

calc %@retval%

 

 

calc 0xFFFFFFFF+42

calc %@retval%

 

the rightmost 8 characters (4 bytes) in the hex representation remain the same, they are only "interpreted" differently in decimal and of course they "wrap around" at the 32 bit limit, so the &0xFFFFFFFF does the trick.

 

:duff:

Wonko



#27 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 25 February 2022 - 11:49 AM

Thanks for the link and the NICE exercise. You are a great teacher!

However I still do not understand why 'standalone' %@retval% gives the 'two's complement' output above 0x7FFFFFFF. Is there any use for it in grub4dos scripting?

#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 February 2022 - 03:49 PM

I don't know *why*, at least initially also some other commands had 32 bit values only, and if you are limited to 32 bit, it actually makes sense.

 

As said, just like it is in DOS/Windows batch command line, you need to lower the max positive value to allow for negative numbers, otherwise you wouldn't be able to do some operations, let's assume that it is/was for compatibility.

 

Now, that 0x7FFFFFFF i.e. 2,147,483,647 is a too small number for many uses is obvious but if you think about it, it wasn't that bad in the '80's or '90's, I remember buying in 1995 a Compaq desktop that should have had a 300 MB disk but (probably because they had not available that size) arrived with a 500 MB disk (with a 300 MB partition, likely because they imaged the disk in manufacturing), and if I recall correctly first 2.1 GB disks were end 1995 or 1996.

 

JFYI/as a side note, I had to write my own batches to do multiply and divisions on larger numbers in Windows NT batch:

http://reboot.pro/in...?showtopic=2986

 

:duff:

Wonko



#29 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 26 February 2022 - 11:25 PM

Nice, I tested DIVIDER.CMD

 

Wonko's limit of DIVIDER.CMD almost 1 biljard.jpg



#30 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 03 March 2022 - 08:01 AM

About dividing: I found calc can not divide 2GB+ values. I think I reported earlier.

Also using unsigned values does not give meaningfull results.

CALC_cannot_divide_2GB+.png

In the past I wrote my own divider: calc seems to have no problems with multiplication, addition and substraction.

Divider-subroutine.png

But my primary school-approach is not so fast.

Maybe you can 'port' your script to grub4dos? So I can compare speed of calculation..

#31 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 09 March 2022 - 06:19 PM

Currently I am trying to add free clusters to a directory cluster-chain to write Long File Names to an already written Short File Name, if last directory cluster is 'full'.

I first write the Long File Name in free directory entries, then I copy the entry of the corresponding Short File Name to the entry just 'after' the Long File Name and 'delete' the original Short File Name entry by writing E5 to first byte. As such successfull. But Long File Names + Short File Name entry can use a maximum of 21 directory entries. On my 160KB test-floppy image clustersize is one sector, so reaching cluster-borders is rather common. So I have to write to the FAT(s).

My question is if the next cluster in a directory cluster-chain always must have a higher cluster number too?

#32 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 21 April 2022 - 09:34 PM

With a generalized approach I made a simple script to get/ set attributes on FAT12/16/32 file-systems

https://github.com/deomsh/ATTRIB.G4B

BTW I added ATTRIB.ZIP to the Repository (right-click to save files can give bad html, sorry, is my first github-project ever).

Screenshots:

Screenshot_use_ATTRIB.G4B.png Screenshot_II_use_ATTRIB.G4B.jpg

Running ATTRIB.G4B on a grub4dos command-line WITHOUT arguments will show some HELP :ph34r:

#33 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 4 weeks ago

BUG FOUND, please use new release V0.4.1 of ATTRIB.G4B.

 

Also some echos added if PATH or ENTRY is not found.

 

Further changing Archive-attribute on directories now allowed.

 

https://github.com/d...ases/tag/V0.4.1

 

Print-screens to compare MS-DOS' ATTRIB.EXE and ATTRIB.G4B

 

Screenshot attrib MS-DOS.jpg Screenshot ATTRIB.G4B.jpg

 

Although ATTRIB.EXE of course have much more possibilities than ATTRIB.G4B, I do not understand WHY ATTRIB.EXE do not show the Directory attribute.

 

Is there some special (historical) reason?



#34 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted 2 weeks ago

Because I was not fully satisfied with the echo-output of ATTRIB.G4B, I made some changes in the direction of a collumn-style.

 

Further: full DEVICE+PATH is shown, but only if DEVICE was not given on the command-line.

 

Version 0.4.2: https://github.com/d...ases/tag/V0.4.2

 

The new look:

 

ATTRIB.G4B v0.4.2 Changed echo-output if not-on-ROOT or if on-ROOT BEST=III.jpg

 

I found an interesting not-fatal omission in my earlier script: echo -n > (md)%mdbase%+%clussect% && raw dd (......) while %clussect% was not declared (anymore). However grub4dos didn't take notice and happily continued this script-line.

 

In the newer version of the grub4dos debugger can be seen only echo -n is noted as executed, the part: > (md)%mdbase%+%clussect% is not expanded. Can be seen in the print-screen below just below the middle.

 

ATTRIB.G4B v0.4.1 Harmless error with echo -n redirect (md)%mdbase%+%clussect% && raw dd with not existing var %clussect% II.jpg

 

Question: is this normal behavior of the grub4dos debugger, any explanation?



#35 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 136 posts
  •  
    Netherlands

Posted A day ago

Although ATTRIB.G4B contains protection, and will not change the directory-attribute and volume-attribute, I found out that changing attributes (A R S H) on a volume-name is possible by accident in the following case:

 

1) Volume-name (Label) is in high-case written to disk

2) The Volume-name is given is 8+3 File-name format

 

See first print-screen for an example.

 

ATTRIB.G4B v0.4.2 Volume label 8+3  - attributes A R S H can be set IV.jpg

 

So I changed ATTRIB.G4B in version 0.4.3 to prevent this happening. https://github.com/d...ases/tag/V0.4.3

 

However, I added read-out of attributes if the Volume-name is given is 8+3 File-name format, but high-case only

 

See next print-screens for using version 0.4.3 with a Volume-names

 

ATTRIB.G4B v0.4.3 Volume label 8+3  - attributes A R S H cannot be set anymore I.jpg ATTRIB.G4B v0.4.3 Volume label 8+3  - low-case LABELS cannot be found I.jpg

 

BTW be aware Windows Defender does not like this script, on my Windows 10 system copy-operations takes a bit longer. I found out with help of Task Manager. No idea why. :crazy:

See last print-screen.

 

ATTRIB.G4B v0.4.3 Windows Defender is very active during copying I.jpg

 







Also tagged with one or more of these keywords: grub4dos

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users