deater / dos33fsprogs Goto Github PK

I tried to use prodos to SAVE a BAS file onto a ProDOS disk, but it didn't work.

One part of the problem is that BAS files need an annotation/subtype of 0x0801, but prodos only respects -a for files of type BIN. However, even when I added a new condition at around line 464, in prodos_add_file(), the contents of the BASIC file installed appeared to be a jumble of garbage when I attempted to load it in an emulator. Wasn't clued into how things work enough to pursue it any further.

Hi,

it looks like mkdos33fs does not generate valid "boot" disks.

Let me explain better what I mean.

I wanted to test an AppleSoft BASIC program of which I had the listing, so the plan was to generate a disk image with the tokenized BAS version of it and run it under an emulator, linapple was my choice (http://linapple.sourceforge.net/).

So this is what I first tried:

./mkdos33fs ao2.dsk
./tokenize_asoft < PROGRAM.bas > PROGRAM
./dos33 ao2.dsk SAVE A PROGRAM

but it looks like mkdos33fs does not generate a full functioning disk image, and linapple bails out with a weird prompt, which i don't know what it is (maybe this is a linapple issue?):

On the other hand, reusing tests/empty.dsk worked just fine:

cp tests/empty.dsk ao2.dsk
./tokenize_asoft < PROGRAM.bas > PROGRAM
./dos33 ao2.dsk DELETE HELLO
./dos33 ao2.dsk SAVE A PROGRAM

BTW thanks a lot for dos33fsprogs, I first managed to create a working image with CiderPress (http://sourceforge.net/projects/ciderpress/) under Windows but a linux-only workflow works a lot better for me, CiderPress has some command line tools which work under linux but they are incomplete at best.

Regards,
Antonio

Hello! Your tools are very cool! And you are inspiring me to do some hacking from Linux as well. (I don't have PulseAudio/ALSA input issues, so I wonder if it is a driver issue you're experiencing?)

Anyway, a few thoughts came to mind:

1. I noticed in your TODO list you mention "Convert to assembly language?" Have you checked out Beagle Compiler? [ftp://ftp.apple.asimov.net:21/pub/apple_II/images/programming/basic/beagle/Beagle Compiler v3.2.dsk] Beagle's Applesoft compiler does a great job at speeding up programs, and even has a faster hires line routine. Would be worth a shot since your output is Applesoft.

2. Since you're using DOS 3.3 disks, why not use a souped-up DOS flavor for speedy loading, such as DiversiDOS? Because KSP is so cool, but waiting for a hires screen to load is trying on my patience. If the disk were formatted with DiversiDOS, the load would be about a second.

3. Declare all Applesoft variables in the very first line of code. I've heard that this speeds up program execution.

system.dsk is recognized, but not e.g. SYSTEM.DSK. Similarly for .2MG. Perhaps you could use strncasecmp instead of strncmp to examine the filename extensions?

The problem is that BSD/traditional Unixes (including Darwin/Mac OS, which impacts me), use a getopt() that, by default, demands that all the options be specified before any non-option arguments.

So, while e.g. dos33 -h gives:
Usage: dos33 [-h] [-y] [-x] disk_image COMMAND [options]
the reality is that, on my Mac, all of the options to COMMAND must be placed before the disk_image argument in order to be recognized by getopt().

That is, I may not portably type:
dos33 -y MY-DISK.DSK BSAVE -a 0x6000 MYBIN
but instead:
dos33 -y -a 0x6000 MY-DISK.DSK BSAVE MYBIN

Suggested solutions:

1. you could run getopt() once for 'hyx', and then run it again after moving the argv pointer past the disk_image and COMMAND arguments, so that getopt() "sees" the following options as coming first.
2. probably easier - I believe most modern BSDish systems can be more relaxed about where options are placed on the command line, either with an appropriate macro #defined, or by calling a differently-named getopt() routine?

any information?

file:
asoft_compact

Example:

$ dos33 ROMX-BASIC.DSK BSAVE -a 8000 basic-loader.bin BLOADER; echo $?
Error!  basic-loader.bin not found!
0

Expected result: final line should read 1.

Motivation: it is often convenient to use dos33 within a Makefile, and it may be desired to remove a disk-in-progress in the event that some operation goes wrong, so that future make invocations don't assume that a disk image's existence means it was successfully completed. But this is only possible if dos33 correctly indicates its success or failure to the parent process (shell).

What a great project! Thank you for creating and sharing it.

Can you please include a LICENSE in the repository such as the GNU GPLv3? This way it allows others to truly study and learn from your amazing work.

Last time I was using this program, perhaps half a year ago, my script to build a disk was working just fine; I recently tried to do that build again and it failed with a complaint about the diskette image having no free space when I tried to write a file. After a bit of debugging, the issue seems to be the dos33 DELETE command: if I simply overwrite an existing file rather than deleting it and writing a new one, things continue to work.

I've reproduced this problem on x86_64 running Debian 9 and Debian 11.

The problem is easily reproduced using an image from this repo. Download EMPTY-DOS33-48K-V254.dsk image and simply run dos33 $img DELETE HELLO followed by dos33 $img CATALOG and you'll see that the image has been corrupted. Here's the output of CATALOG of the above image from before and after the DELETE:

-rw-r----- 1 cjs cjs 143360 Aug 13 19:42 z.dsk

DISK VOLUME 254

 A 002 HELLO

-rw-r----- 1 cjs cjs 143360 Aug 13 19:42 z.dsk

DISK VOLUME 0

 T 000 ^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À^À

I've started looking back through the commits and testing them to see where this broke. It's still broken in commits from a month or more ago.

When using the Virtual II emulator version 11.1 as an Apple IIe, running on a Macintosh running OS X Mojave, if you boot from ootw.dsk and either start with CHECKPOINT 1 or watch all of the INTRO MOVIE till the end, the following text is shown...

Pressing Return simply shows the previous animation screen again for a few seconds...

And then you get the PRESS RETURN TO CONTINUE screen again. It's an endless loop. Swapping out the ootw.dsk for ootw_side2.dsk does nothing. I tried it from the Total Replay 5.0b2 and it gives the same thing.