Enhanced Pico-Dos

[bxdanny]

They say you should always test a program again after making even the slightest change. In this case, I thought I remembered doing exactly that. But I guess I remembered wrong.

The tape-generating part of Program 4 was broken in both the 1.37 and 1.38 versions posted here. When I added the counter showing the memory locations being processed, I forgot that I was PRINTing with SAVE on, and that those numbers were thus getting onto the tape, which therefore would not work. I needed to add the lines

85 POKE 517,0

and

95 SAVE

to turn SAVE mode off and back on at the appropriate points in time. So I'm attaching a version that does that. Because I want the final version here to WORK, dammit!

One more line (307) is also added to Program 1, the Disassembler, so that the ESC key can be detected in the case of running with Control-C disabled on a system with CEGMON.

No changes to other programs, or to the system code on tracks 0 and 1. (But see Edit #2 in the preceding message if you were one of the first four to download ep38.zip.) No changes to the included text file either.

[bxdanny]

Well, as at least 12 people here are already aware, I continued tinkering with this, and uploaded a version 1.39 in another thread. So I guess I might as well post it here too.

As I stated there, the biggest difference from the last (1.38a) version is the addition of the OSI disk-to-disk copier on track 39, runnable with the XQ command. But there are other small differences, which I will list here:

-Checking for Control-S (to pause output) now occurs after a character is output, as it should, rather than before, as it did bef, er, previously.
-If the Extended Monitor has been loaded, this checking will occur regardless of the contents of $0212 (530).
-The changes to normally unused drivers that were the only actual difference in the system code between 1.37 and 1.38 are changed just a bit again, to eliminate a couple of unnecessary JMP instructions. This has no effect at all on any functionality.

Also, in Program 6, the Editor loader, a now-pointless feature (making the system reread the video screen parameters from ROM on warmstart, to update some internal values) has been removed, or rather REMmed out (see lines 55 and 60). For that reason only, the program's version number in line 10 was also changed.

The accompanying text file was also edited just a bit, in addition to having information about the Copier added.

[bxdanny]

Well, user davisgw reports that the copier I added does not, in fact, work on his system, even though copying under full OS-65D does. I sent him (or rather posted in that other thread) a modified version for him to test, but until I hear back, it may be better to stick with 1.38(a).

I'd welcome feedback from anyone else with a dual drive system who can test ep39.img, and specifically the copier on track 39. Does it work, or give consistent errors? It works fine in the emulator. For that matter, does access to the B drive actually work at all on real hardware? For reading and for writing? I can't imagine why it wouldn't, but I realize I don't actually know for sure.

[davisgw]

bxdanny,
It will be a few days before I can test the copy function in 1.39a. I've discovered that my drivers for the floppy lines are not robust enough to work well with the Gotek and a floppy attached because the pullup resistors cannot be removed on the Gotek without modification, which I don't want to do. This is the reason my Motor On output to the floppy is so flaky and read/write operations sometimes fail. Also, I'm reluctant to wire this line always active which will leave the floppy drive always running. So I'm wiring up the changes and waiting for more robust driver chips to arrive.

[bxdanny]

davisgw,

OK, I'll wait. I'm sure you'll let me know when you are ready.

-Danny

[davisgw]

Danny,
I tried ep39a again and there seems to be a problem with initialization of the drive hardware. On both my 600D and my S100 system when I typed "load 0" or "XQ 39" sometimes it would activate the B drive and fail because the ep39b was in the A drive. This happened particularly if it failed writing the B drive, and when I booted again and tried a second time it would fail the "Load 0". But if I booted OS65D, then booted ep39a everything worked fine.
On the plus side the floppy I wrote on the 600D from the Gotek booted and executed fine on the dual floppy S100 system. So it seems that the last state of the drive hardware does not get initialized by ep39a.

[bxdanny]

davisgw,\

Had you used the "BA" command to reboot shortly before this happened? I noticed that, if I issued a BA command while at a B* prompt, it (any ep version) would reboot from the B drive and think it was the A drive, until an explicit SElect command was given, at which point it would sort things out right. I don't know how that's possible, but that's what it does on the emulator, and maybe on the real hardware too. You could try doing that (BA at B*), maybe with different versions (like 1.38 and 1.39) in the two drives so you can be sure from the sign-on message which is which, and see what happens.

[davisgw]

Danny,
I tried ep1.39 and all it would do when I did an "XQ 39" is to produce error #5. So I ran ep1.39a several times and it works well, but one time when the copy completed it ended with drive B being active and it would not run again without doing a BA command. So the more I think about it after reading your list of enhancements and how you produced them, the user needs to be sure of the active drive before the "XQ 39" command because something in memory causes the code to "remember" the last active drive even after a cold boot (I think).
I had previously no knowledge of the "BA" command so that is not the cause of what I observed. Just add a comment in your documentation to check the active drive status before running the copier, and I think ep1.39a is good to go!

[bxdanny]

Thanks to davisgw for testing the ep39 revision. I'm not sure I fully understand what he said was happening, but I am updating the version here to the 1.39a version i had posted for him. It may or may not generally make a difference, but I don't think it can hurt. I'm not sure why I have been omitting the "1." part from the file names, but I'll stick with the convention I've been using.

While it definitely is not what makes any difference, the five-page sector (constituting the Copier) on track 39 of the "a" revision can be distinguished from that on the previous one by its first four bytes being set to $00.

The only difference between ep39 and ep39a is in that Copier sector, and the only difference in the accompanying text file is the line in the "a" version stating it is for revision a. [Edit 1/31/24: A note about the updating of the Copier has been added to the included text file. There were no downloads of the version without that note.] But yes, make sure you are loading from the correct drive. And it may be helpful, when copying over a diskette that was already formatted for OSI, to reformat ("initialize") it first with the IN command, which will format all tracks 1 to 39 (unless a single track is specified).

[nama]

I've tried the latest release on my C1 using my FlashFloppy gotek. One thing I notice is that when I initially launch Enhanced Pico-Dos, and I type 'load xxxx', I always get an Err #6.
however, If I then jump to another disk image/OS such as OS65D and launch that, then go back and launch Enhanced Pico-Dos, typing 'load xxxx' now works and loads the file. Could be a quirk of my system. Wondering if anyone else has noticed similar behaviour.

Also, creating a new disk and copying PicoDos from the Enhanced Pico-Dos menu creates a disk with the original PicoDos, and not Enhanced Pico-Dos.
Unfortunately on my C1, the original PicDos seems to load but my keyboard is unresponsive. I have experienced this problem both with the Enhanced Pico-Dos generated disk, and original PicoDOS that I've downloaded from the net...not sure what that's all about!