Activity for ToolShed
-
tim lindner committed [5aad4c] on Code
Added pointer to new site in readme.
-
Home
-
olegyk modified a comment on ticket #49
After installing the latest * snapshot toolshed-snapshot20230914-win32.zip * from https://toolshed.sourceforge.net/snapshots/ it's all working now both in Windows CMD >decb dsave -e -t OKBASIC.DSK, OKBASIC decb copy "OKBASIC.DSK,TIMER.BAS" "OKBASIC/TIMER.BAS" -t and in MSYS / MingW $ decb dsave OKBASIC.DSK, OKBASIC -e -t decb copy "OKBASIC.DSK,TIMER.BAS" "OKBASIC/TIMER.BAS" -t Both due to the double quotes (") properly generated. So I am all set.
-
I can confirm that on Windows, dsave generates copy parameters with single quotes ('): decb copy 'OKBASIC.DSK,TIMER.BAS' './TIMER.BAS' and when executing such command line using CMD, it causes the error 215: decb copy 'OKBASIC.DSK,TIMER.BAS' './TIMER.BAS' copy: error 215 But the same issue occurs when running the same binaries from MSYS/MinGW: $ decb dsave -e OKBASIC.DSK, OKBASIC decb copy 'OKBASIC.DSK,TIMER.BAS' 'OKBASIC/TIMER.BAS' copy: error 215 The binaries of the ToolShed are build on Windows...
-
After installing the latest * snapshot toolshed-snapshot20230914-win32.zip * from https://toolshed.sourceforge.net/snapshots/ it's all working now both in Windows CMD >decb dsave -e -t OKBASIC.DSK, OKBASIC decb copy "OKBASIC.DSK,TIMER.BAS" "OKBASIC/TIMER.BAS" -t and in MSYS / MingW $ decb dsave OKBASIC.DSK, OKBASIC -e -t decb copy "OKBASIC.DSK,TIMER.BAS" "OKBASIC/TIMER.BAS" -t Both due to the double quotes (") properly generated.
-
I can confirm that on Windows, dsave generates copy parameters with single quotes ('): decb copy 'OKBASIC.DSK,TIMER.BAS' './TIMER.BAS' and when executing such command line using CMD, it causes the error 215: decb copy 'OKBASIC.DSK,TIMER.BAS' './TIMER.BAS' copy: error 215 But the same issue occurs when running the same binaries from MSYS/MinGW: $ decb dsave -e OKBASIC.DSK, OKBASIC decb copy 'OKBASIC.DSK,TIMER.BAS' 'OKBASIC/TIMER.BAS' copy: error 215 The binaries of the ToolShed are build on Windows...
-
I can confirm that on Windows, dsave generates copy parameters with single quotes ('): decb copy 'OKBASIC.DSK,TIMER.BAS' './TIMER.BAS' and when executing such command line using CMD, it causes the error 215: decb copy 'OKBASIC.DSK,TIMER.BAS' './TIMER.BAS' copy: error 215 But the same issue occurs when running the same binaries from MSYS/MinGW: $ decb dsave -e OKBASIC.DSK, OKBASIC decb copy 'OKBASIC.DSK,TIMER.BAS' 'OKBASIC/TIMER.BAS' copy: error 215 The binaries of the ToolShed are build on Windows...
-
Paul Fiscarelli posted a comment on ticket #53
Both of these issues appear to be resolved - I've been testing for the last week and have yet to reproduce the issues.
-
OK. This new issue is now fixed.
-
Handle decb copy better under disk full conditions.
-
I've been testing the latest push and the issue where granules were being appended to the disk image appears to be fixed. However, there is a new issue when attempting to write a file to a disk image with free granules, but there are not enough free granules to write the file. The following error is thrown in this scenario: copy: error -1 Error: -1 - unknown error Also, a new disk directory entry is created for the file on the disk image, but it appears no further data is attempted to be written...
-
I just commed a change to fix this: Add DECB executive option to set the granule count. Change libdecb allocation algorithm to mimic what the ROM does. Remove use of HDBDOS offset as a flag. Document colon and plus operator when used in a decb path. Docuemnt new granule count option.
-
Revamp DECB FAT handling.
-
Tormod Volden posted a comment on ticket #53
hg log -v -p -r 754:c257cd7fb0fb https://sourceforge.net/p/toolshed/code/ci/a777c76f483348c20a0c95dc9a6c6e4720352f1a/ https://sourceforge.net/p/toolshed/code/ci/c257cd7fb0fb2006650bbc936f1a4e3f484c5a2b/
-
How do I find that commit?
-
For why the hdbdos_offset is checked, please see commit 754:c257cd7fb0fb (and commit 753:a777c76f4833).
-
For why the hdbdos_offset is checked, please see commit 754:c257cd7fb0fb .
-
find_free_granule() in libdecbwrite.c is broken. Working on a patch now, I'm not sure why it needs to test against path->hdbdos_offset. That seems like an error.
-
When attempting to recreate this issue on a Linux box, I noticed I accidentally made a mistake in the included 'readme.txt' file, for steps to recreate the issue. Incorrect command: decb copy -2 -b -4 %binary_path% %disk_path%,%filename%.BIN Correct command: decb copy -2 -b -r %binary_path% %disk_path%,%filename%.BIN While testing under Linux, the same issue is present. Here is the updated 'readme.txt' file with the corrected syntax.
-
When attempting to recreate this issue on a Linux box, I noticed I accidentally made a mistake in the included 'readme.txt' file, for steps to recreate the issue. Incorrect command: decb copy -2 -b -4 %binary_path% %disk_path%,%filename%.BIN Correct command: decb copy -2 -b -r %binary_path% %disk_path%,%filename%.BIN While testing under Linux, the same issue is present. Here is the updated 'readme.txt' file with the corrected syntax.
-
decb copy, appending granules to disk images
-
Please file a new "Bugs" ticket, and provide complete steps to reproduce, including disk image formatting/init and exact file sizes (or sample images and files).
-
I'm experiencing issues when using decb to write files to 35-track disk images, where decb will attempt to fit the file at the end of the disk image. If there aren't enough free granules/sectors at the end of the disk to fit the file, instead of decb looking for other free granules on the disk, it will append granules to the disk image. When exhibiting this behavior, it will also truncate the file to the nearest granule size - that is, if a file requires more than one full granule but less than two...
-
Anonymous posted a comment on ticket #49
Here you, apologies for the long output! **** login shell, os9 dsave Working.dsk, moon/Working -l -e os9 copy 'Working.dsk,DIGDUG.BAS' 'moon/Working/DIGDUG.BAS' -l -b=32768 copy: error 215 on file ''Working.dsk,DIGDUG.BAS'' to ''moon/Working/DIGDUG.BAS' ': badly formed pathname os9 copy 'Working.dsk,CAR.BAS' 'moon/Working/CAR.BAS' -l -b=32768 copy: error 215 on file ''Working.dsk,CAR.BAS'' to ''moon/Working/CAR.BAS'': bad ly formed pathname os9 copy 'Working.dsk,VELMA.BAS' 'moon/Working/VELMA.BAS'...
-
Thanks, I'd like to see on Cygwin, using snapshot builds, both with login shell and non-login shell: os9 dsave Working.dsk, moon/Working -l -e decb dsave Working.dsk, moon/Working -l -e
-
Anonymous posted a comment on ticket #49
Yeah, I'd be happy to send you more info. Could you be more specific on exactly which commands and which environments you want to see command line output for?
-
Please disregard what I said about decb dsaveversus os9 dsave improvements. decb dsave actually just calls into the os9 dsave code, so the results should be the same. Which they also were for your 2.2 trials. I don't understand why there is a difference between the two on cygwin, when using the snapshot builds. I don't know the reasoning behind mintty only exporting SHELL from login shells, but it is likely why we see a difference in dsave. With mintty -it will be a login shell so SHELL is exported...
-
Please disregard what I said about decb dsaveversus os9 dsave improvements. decb dsave actually just calls into the os9 dsave code, so the results should be the same. Which they also were for your 2.2 trials. I don't understand why you see a difference between the two on cygwin, when using the snapshot builds. I don't know the reasoning behind mintty only exporting SHELL from login shells, but it is likely why we see a difference in dsave. With mintty -it will be a login shell so SHELL is exported...
-
Anonymous posted a comment on ticket #49
Results of commands run in different cygwin cmd prompts: env | grep SHELL: login shell, dsave not working: SHELL=/bin/bash non-login shell, dsave working: (no output) set | grep SHELL: both SHELL and SHELLOPTS are set identically in both login & non-login shells: SHELL=/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor Dunno why env and set are giving different results. Does this explain the behavior to you?
-
BTW, man bash | less +/^INVOCATION explains what the login shell means for bash.
-
Yes, "login shell" means the first shell you get when you log in. In this shell, files like /etc/profile and .bash_profile will be sourced at the start. Other shells are created when running shell scripts (a non-interactive shell), or when opening terminal windows in a GUI login (interactive shell). Then typically only /etc/bashrc and .bashrc are read. Other shells than bash might have slightly different rules. If you run set in your two cases, you'll probably see a difference. In particular, please...
-
Anonymous posted a comment on ticket #49
Aha. Now... On both vanilla DOS and cygwin, the DECB dsave command works great! On vanilla DOS, the os9 dsave works great. Oddly, on cygwin, the os9 dsave continues to give the same error 215 / badly formed pathname error. I investigated further, since I don't know much about cygwin. My start-menu icon for cygwin runs C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - If I manually run that command line to generate my cygwin prompt, os9 dsave continues to fail. If I manually run that command line...
-
Anonymous posted a comment on ticket #49
Unfortunately, same problem. (This is all with the latest released 2.2 build, btw.) On vanilla DOS: D:\coco\disks>os9 dsave Working.dsk, moon\Working -l -e os9 copy 'Working.dsk,DIGDUG.BAS' 'moon\Working/DIGDUG.BAS' -l -b=32768 copy: error 215 on file ''Working.dsk,DIGDUG.BAS'': badly formed pathname (output continues with error for each file in .dsk) Manually pasting a generated os9 copy command also fails: D:\coco\disks>os9 copy 'Working.dsk,DIGDUG.BAS' 'moon\Working/DIGDUG.BAS' -l -b=32768 copy:...
-
Please test using the latest snapshot at https://toolshed.sourceforge.net/snapshots/ A lot of the dsave rework came after 2.2.
-
+1 for double-quotes on vanilla DOS. os9 dsave has received more attention than decb dsave over the last years, and a "recent" (3 years old in source repo but unreleased) change is that os9 dsave chooses double-quotes for non-POSIX shells. It still uses single-quotes on POSIX shells, IIRC to allow e.g. dollars in path names, that otherwise would be wrongly substituted by the shell. By the way, the -e option is difficult to get correct in all situations, since it spawns a command interpreter using...
-
Anonymous posted a comment on ticket #49
Hoping you'll take another look at this. I'm not the original opener of the ticket, but the quotes issue has been a problem for me on Windows 10 as well, and I found this ticket. Running on vanilla DOS and CygWin both yield: D:\coco\disks>decb dsave -e Working.dsk, moon\Working decb copy 'Working.dsk,DIGDUG.BAS' 'moon\Working/DIGDUG.BAS' copy: error 215 dsave: error 215 encountered during dsave (to even get this far on CygWin, I do need to replace \ with /; I also tried on PowerShell, but the comma...
-
Anonymous posted a comment on discussion Open Discussion
Thank you very much. I didn't read that anywhere (wouldn't surprise me if i missed it), so I'm wondering if others might be wondering the same thing. Again, thanks.
-
librbftest division by zero on macOS (clang)
-
A classic "use after free", fixed in commit 5589e087.
-
Tormod Volden committed [5589e0] on Code
librbf: Fix use after free in _os9_freefile
-
BTW, I uploaded a new Windows snapshot at https://toolshed.sourceforge.net/snapshots/
-
librbftest division by zero on macOS (clang)
-
HDBDOS not building correctly with LWASM 4.20 and 4.21
-
HDBDOS not building correctly with LWASM 4.20 and 4.21
-
I have commit this in https://sourceforge.net/p/toolshed/code/ci/12c61f472a1b813ab54a094ce46483cb85cf044e/
-
Note this bug is tracked in https://sourceforge.net/p/toolshed/bugs/51/
-
os9 copy issues with EOL translation
-
I have committed a simple fix for this. As posted in the discussion the issue can be reproduced and the fix verified with this: printf "1234\r\n7890\r\n3456\r\n" > /tmp/test.crnl os9 format /tmp/os9disk.img os9 copy -b11 -l /tmp/test.crnl /tmp/os9disk.img,test os9 copy /tmp/os9disk.img,test /tmp/test.back sed -n l /tmp/test.back A remaining corner case issue can be reproduced by changing -b11 to -b5 above. I have added a proper unit test for this - a lot more work than above command lines :) - that...
-
librbftest division by zero on macOS (clang)
-
Tormod Volden committed [00ac12] on Code
ar2: Fix incomplete prototypes
-
Tormod Volden committed [0fc550] on Code
mamou: Fix incomplete prototypes
-
Tormod Volden committed [403d1e] on Code
dis68: Fix incomplete prototypes
-
Tormod Volden committed [8d8956] on Code
os9dsave/cocodsave/os9dir/libdecbsrec: Fix unused variables breaking build
-
Tormod Volden committed [9c8663] on Code
libdecb: Print warning if unusual postamble
-
Tormod Volden committed [65bb86] on Code
unittest: Add test of EOL conversions in libtoolshed
-
Tormod Volden committed [4981ac] on Code
libtoolshed: Do not modify source buffer in Native2Coco/Coco2Native
-
Tormod Volden committed [ca55e1] on Code
libtoolshed: Improve corner-case EOL detection for os9 copy -l
-
Tormod Volden committed [12c61f] on Code
hdbdos: Avoid using RMB for addresses outside the code
-
Anonymous posted a comment on discussion Open Discussion
I created a test file that had CR,LF split at the 32KB boundary, and used the default 32KB buffer size, and the lines after that point became double-spaced with the v2.2 program, confirming your analysis of the program. I'm not currently set up to patch the ToolShed source code and run make, so for now will just specify a buffer size larger than the largest text file I expect to ever process with "os9 copy". Thanks for your prompt help!!
-
Anonymous posted a comment on discussion Open Discussion
I made some minor changes to the file, and the problem went away. Unfortunately I didn't save a copy that had the problem. But the issue did seem to start around the 64KB mark, so your suspicion as to the cause is probably correct. What is the largest buffer size that may be specified for "os9 copy"? My source code files have lots of comments in them, because internal documentation can't be misplaced like external documentation, so that makes them bigger than many other people's files. Dave W
-
I don't there is any practical limit for the buffer size to worry about, the code deals with as an integer, so if you are running this on a 32-bit computer a 2 GB size could work. It will allocate at least one buffer of that size though, so enough RAM must be available for the process. -b2111000K seems to work fine here :)
-
I don't there is any practical limit for the buffer size to worry about, the code deals with as an integer, so if you are running this on a 32-bit computer a 2 GB size could work. It will allocate at least one buffer of that size though, so enough RAM must be available for the process.
-
os9 copy issues with EOL translation
-
Steps to reproduce and verify: printf "1234\r\n7890\r\n3456\r\n" > /tmp/test.crnl os9 format /tmp/os9disk.img os9 copy -b11 -l /tmp/test.crnl /tmp/os9disk.img,test os9 copy /tmp/os9disk.img,test /tmp/test.back sed -n l /tmp/test.back
-
Steps to reproduce and verify: printf "1234\r\n7890\r\n3456\r\n" > /tmp/test.crnl os9 format /tmp/os9disk.img os9 copy -b11 -l /tmp/test.crnl /tmp/os9disk.img,test os9 copy /tmp/os9disk.img,test /tmp/test.back sed -n l /tmp/test
-
You can test this patch. I will also make new snapshot builds for Windows once I have committed this.
-
It is also interesting to note that NativeToCoco() uses DetermineEOLType() to "sniff" the encoding of the file, while CoCoToNative() selects the target file encoding based on the platform it is compiled for. This is not mentioned in the ToolShed documentation.
-
Maybe you can confirm that the issue disappears (or you get other results) if you specify a buffer size with the -b option different than the default 32768 bytes. I guess this bug hasn't popped up much because people rarely deal with files larger than 32K on their NitrOS-9 systems.
-
After a quick look at the code I can imagine this happens because the file is processed in buffer-size chunks, and each chunk is checked with DetermineEOLType(). If the file is split so that one chunk ends with CR and the next starts with LF, the latter chunk will be detected as a EOL_UNIX type and simple LF->CR conversion will be done on it. Maybe the simplest fix would be for DetermineEOLType() to go through the whole chunk in search for CR,LF and not just be happy with the first LF it finds. Obviously...
-
Can you share the file? Or a part of it which reproduces the bug?
-
Anonymous posted a comment on discussion Open Discussion
Today I noticed that one of my text files has the last 229 lines double-spaced when using "os9 copy" to copy a Windows text file to an OS-9 disk image. Those lines have CR,LF converted to CR,CR instead of only CR. I have never noticed this happening before, and can't see what might have triggered it. The Windows file has 2480 lines and 72089 bytes in it, but only the last 229 lines are affected. The command line doing the copy: os9 copy -l -r KRNBOOT\dskboot.asm NOS9DEV.DSK,KRNBOOT/dskboot.asm I...
-
David Ladd posted a comment on ticket #50
Thank you for looking into it. I found the issue and I figured I better report it. I use Linux Subsystem for Windows(Debian) and also MINGW(for building MAME) and also Raspberry Pi's for testing and building projects. I know someone wanted the current build of the HDBDOS WAV files related to DriveWire and the Deluxe RS232-Pak and Modem Pak. Which is how I found out it wasn't building.
-
This patch to hdbdos.asm makes it build with latest LWASM (identical binaries as with 4.19). I will commit these changes, unless there are other suggestions. The old code was neater in that it showed clearly the length of each variable. But I guess with raw output, there is no way to do something à la RMB.
-
After fine-reading the LWASM documentation the new LWASM behavior seems to do what it should. RMB - "Reserve a number of bytes in the output." ORG - "When using the raw target format, ORG is used only to determine the addresses of symbols." So any RMB reservations will be added to the raw output binary at the point they appear in the code, regardless of the address they have been assigned through ORG.
-
Thanks for the notice. It seems to be a regression in LWASM: LWASM 4.20 has the same issue. LWASM 4.19 works fine. The hdbdos.asm code ends with fill $39,MAGICDG+$2000-* where MAGICDG is the address of the start (the "DK" magic). The "fill" seems broken.
-
It is caused by this commit: http://www.lwtools.ca/hg/index.cgi/rev/a812bb4d3a51 The bad hdbdos binaries are 19 bytes too long, and the code reserves 19 bytes through rmb directives but for RAM locations outside the code segment... Hmm, hdbdos should maybe not use rmb here since nothing needs to be "reserved". I remember having troubles in another project also due to this commit.
-
It is caused by this commit: http://www.lwtools.ca/hg/index.cgi/rev/a812bb4d3a51 The bad hdbdos binaries are 19 bytes too long, and the code reserves 19 bytes through rmb directives... I remember having troubles in another project also due to this commit.
-
HDBDOS not building correctly with LWASM 4.20 and 4.21
-
It is caused by this commit: http://www.lwtools.ca/hg/index.cgi/rev/a812bb4d3a51 I remember having troubles in another project also due to this commit.
-
Thanks for the notice. It seems to be a regression in LWASM: LWASM 4.20 has the same issue. LWASM 4.19 works fine. The hdbdos.asm code ends with fill $39,MAGICDG+$2000-* where MAGICDG is the address of the start (the "DK" magic). The "fill" seems broken.
-
Additional information: LWASM v4.21 OS: Raspberry Pi OS ARM64 OS: Debian 11 AMD64 OS: Ubuntu 18.04LTS AMD64 OS: Windows 11 AMD64 MINGW64 These are all the OS's I have currently tested under.
-
HDBDOS not building correctly
-
Yes, append a colon and the number of the drive. For example: decb dir cocomax.img,:2 or decb dir disk.img,SUBDIR:2
-
[Reposted from anonymous thread hi-jack] Is there any way possible for the PC - windows to read the directories in the .dsk, image above drive 0? There are 255 virtual disks, but I can only read the directory of disk 0.
-
Thanks! I downloaded the image and concatenated the three disk in to one "HDB-DOS" image called cocomax.img When I run the old toolshed 2.2 decb: $ decb free cocomax.img,:2 Free granules: 193 (444672 bytes) And with the current repo decb: decb free cocomax.img,:2 Free granules: 5 (11520 bytes) (It took me some time to realize how important that comma is...) So that seems to work well for "dcb free" at at least. Of course, this also works for a single disk image if treated as a "HDB-DOS" image: decb...
-
Mathieu BOUCHARD posted a comment on ticket #39
Sorry, I haven't used decb nor drivewire nor the CoCo since Sep 2018. But the Cocomax2 disk image has been all along in https://colorcomputerarchive.com/repo/Disks/Applications/Coco%20Max%20II%20%28Colorware%29.zip , and I just ran «od -Ax -tx1 "Coco Max II (Original).dsk"» and at position $13300 (FAT8 table) it shows FF padding.
-
I think __CYGWIN__ is also defined on 32-bit Cygwin, so that one is enough.
-
Isn't __CYGWIN__ also defined on 32-bit Cygwin?
-
Oh this post was stuck in the moderation queue. These issues are also discussed in https://sourceforge.net/p/toolshed/discussion/22367
-
Anonymous posted a comment on discussion Open Discussion
Hi all, I've tried this under both cygwin and under Ubuntu 20.04 running on wsl, and then with native Ubuntu 22.04. These problems only seem to manifest compiling unger cygwin. So I checked out the current code with : hg clone http://hg.code.sf.net/p/toolshed/code toolshed-code Then changed to the toolshed-code directory and did : make -C build/unix 2>&1 | tee mk.out To capture the output of the make. The make fails with warnings in several places. I also tried with CC=gcc, but that did not make...
-
os9gen throws _os9_seek(): SET_SEEK warning
-
Fixed in mercurial commit 770:cb49b722e1de
-
I added (unsigned char) to everywhere where it was needed. Let me know if it builds on Cygwin now.
-
Tormod Volden committed [397ad2] on Code
Use unsigned char with isdigit/toupper/etc
-
I fixed up the Cygwin detection in makewav.c - it should be __CYGWIN__ and not __CYGWIN32__ - so the digittoint() issue should be gone. I am not able to reproduce the other warnings on MinGW (gcc 12) even if I add -Wchar-subscripts to CFLAGS. Allen, can you please attach your diff with the (unsigned char) casts?
-
Tormod Volden committed [b0897c] on Code
makewav: Correct Cygwin build detection
-
Dsave makdir instead of mkdir and destination separator issues
-
Yes, I think makdir is the classic OS/9 name. This is not unix! :) I think the quotes are added just in case there are spaces or dollar signs in the file paths. And they would work if you use any kind of command shell other than the "DOS" cmd.exe., like a Bash shell or something from MinGW/MSYS or Cygwin. BTW I would anyway recommend using e.g . Bash shell (included in e.g. Git for Windows) if you do command line work on Windows. We could make dsave more sophisticated and only add quotes if it seems...
-
Anonymous posted a comment on ticket #49
Ok, after looking a bit around the code the use of makdir seems ok, and for some reason the paths are also correct now, but the copy command looks like this: os9 copy 'os9.dsk,EP90/NCPS/ftab270g.nc' 'd:/temp/EP90/NCPS/ftab270g.nc' which throws on Windows 10 an error: copy: error 215 on file ''os9.dsk,EP90/NCPS/ftab270g.nc'': badly formed pathname For testing, if I use: os9 copy os9.dsk,EP90/NCPS/ftab270g.nc d:/temp/EP90/NCPS/ftab270g.nc without quotes, the command executes okay, without errors.
-
Alin Marcu created ticket #49
Dsave makdir instead of mkdir and destination separator issues
