iss wrote: ↑Sat May 19, 2018 1:21 pm
Hello, overCLK! Great utility.
Well, thanks. Glad that you like it.
iss wrote: ↑Sat May 19, 2018 1:21 pm
I've tested the github version with your last fix and there is no error message.
But when extracting the PATCH.001 file the result is 268 bytes which contain data only for the 1-st part (chunk) of 3 total.PATCH.001.png
Here is the info which describes what PATCH.001 is and how to create it. The info is extracted from "SEDORIC 3.0 à NU".
patch-001.pdf
To create file is used:
COPYM"P?"TO"PATCH.001" which merges the 3 parts. Unfortunately, I don't know more about Sedoric internals. Maybe
@Symoon can help more (or anyone else)?
My knowledge of French is even worse than my knowledge of Sedoric. But anyway:
I guess you would expect to have extracted a PATCH.001 with size 5 bytes. There are (were) two reasons why the extracted file is bigger:
- When a file has load/execution address or defined flags, the utility preserves this information in a 12byte header. The utility is also (hopefully) able to strip this header when the file is added to a DSK if it exists, and should take such metadata from this header.
- There was a bug, and the utility did not take into account the size of the file to export it, exporting instead whole 256 byte sectors, so the minimal file size would be 256 bytes.
This explains your 256 + 12 = 268 byte file.
I've corrected the bug and with the new version you would export a file of 5 + 12 = 17 bytes
The version in github master should also already support "remembering" the last used directory. I'm not attaching it here to avoid wasting more host space.
If you still want to export a 5 byte file, you can try setting to zero the load and exec address and unticking all the set flags of the PATCH.001 in the utility. Extracting it afterwards, you will have a file of 5 bytes, since the utility is able to decide whether it needs to export the header to preserve the metadata or not. In this way you would trick the program by making it think that no metadata is present and so no header is really needed.
When I designed it I thought it was a good idea. Maybe it is not after all.
iss wrote: ↑Sat May 19, 2018 1:21 pm
About the disk sizes, IMO standard sizes can be: 16/17/18 sectors on 40,41,42, 80,81,82 tracks. But maybe is would be better tracks to be free selectable.
I would like to have a set of standard formats to quickly set it from a menu, but I will keep the possibility to choose any combination of sides/tracks/sectors as it is now. So, what "named" formats could we offer? :
3" single/double side
3.5" single/double side
and what are the parameter for each of them?
iss wrote: ↑Sat May 19, 2018 1:21 pm
I saw already your answer about resize-able main window and understand your point, but I really think it will be better to have at least vertical resize (just my 2cents)
.
Well, if you all think it's a good idea... I will add it to the TODO list in my head.