why isn't VIC Mail program working with SD2IEC after a few program changes?

[carlsson]

You should CD into the name of the D64 image. You should not have to worry about the name of the unsuccessful files. If the validate command actually works - which seems not clear at the point we're at right now- it will remove all splat files regardless of name or file type.

[newTIboyRob]

Ok, so from that above, as relates to your original of:

 

OPEN1,8,15,"CD:folder-with-images"

PRINT#1,"CD:filename.D64"

PRINT#1,"V0"

(wait a little)

CLOSE 1

 

...I just skipped over that line 2, as I had just done and was still the in OPEN 1,8,15:"CD:VIC20-𝜋.D64" (which when you go into that folder has the VIC MAIL PRG and the 3 splat files)

so I just tried PRINT#1."V0"  ... and got the red flashing light. Now where are we?

[carlsson]

Ok, I dug out my VIC-20 with uIEC/SD to verify. It is correct that the firmware does not support the validate command inside D64 images. It does support S for scratch files though, but it doesn't help that much since you are not supposed to scratch splat files. Very strange, but that tells Rob he doesn't have to bother with this particular operation as it won't work.

 

I also noticed that D64 Editor on the PC doesn't have a function to validate a D64 image. It can scratch files, edit BAM etc though. That probably leaves the only option to mount the D64 from a SD card into the VICE emulator and validate files that way, if even that is possible - perhaps with true drive emulation turned on.

[newTIboyRob]

Since I only use the actual VIC-20, what do you think about just putting my SD card back in my PC, deleting the old VIC20-𝜋.D64  since the only thing on there is the VIC MAIL and 3 splat files, with the thought that the 3 splat files would be removed as well, and then just downloading a fresh copy VIC20-𝜋.D64 to replace that old affected one?

 

Is that dangerous or do you think that may be safe for me?

Edited March 14 by newTIboyRob

[Casey]

Why not just load VIC Mail into the VIC-20, format the volume on the SD2IEC, and then save VIC Mail back to the image?

[carlsson]

At this point, I'm not sure if SD2IEC supports formatting a mounted D64. I just put my VIC back in its drawer so I can't say for sure, but if you remove the D64 from the card on the PC and put a fresh D64 back, your splat files obviously will be gone. While you're at it, you can rename the D64 to a shorter name (8 characters + 3 for extension) so you don't have to fiddle with the Pi character when accessing it manually on the VIC-20.

[newTIboyRob]

I think I'll just do that then and take the risk. This thing is causing me/us too much fuss... even if it is a gamble and you're not "supposed" to delete splat files outright. Then I can finally try out Casey's program changes!

Edited March 14 by newTIboyRob

[+OLD CS1]

34 minutes ago, carlsson said:

I also noticed that D64 Editor on the PC doesn't have a function to validate a D64 image. It can scratch files, edit BAM etc though.

DirMaster does.

18 minutes ago, carlsson said:

At this point, I'm not sure if SD2IEC supports formatting a mounted D64.

I will give it a try when I get back home.  Not being able to validate a disk image makes sense, since this kind of work really does seem to exceed the intention of the device, in the first place.

18 minutes ago, carlsson said:

While you're at it, you can rename the D64 to a shorter name (8 characters + 3 for extension) so you don't have to fiddle with the Pi character when accessing it manually on the VIC-20.

Tru.  Plus, working with files on the original disk image is not a good idea if you do not have backups.  The old adage comes into play: never dev in prod.

[+OLD CS1]

1 hour ago, OLD CS1 said:

1 hour ago, carlsson said:

At this point, I'm not sure if SD2IEC supports formatting a mounted D64.

I will give it a try when I get back home.  Not being able to validate a disk image makes sense, since this kind of work really does seem to exceed the intention of the device, in the first place.

Format (N0:) works.  I created a blank D64 with DirMaster, then formatted it in the SD2IEC.

[newTIboyRob]

@Casey ... hello. So now that I put a fresh copy of the Vic Mail program we've been talking about on my SD card (sayonara, splat files!), I loaded up the program and first made some "safe" changes to some of the earlier program lines. I then proceeded down the program, modifying some of the words in some of the lines, e.g. changing "PROV and PC" to "STATE and ZIP". I've again attached the PDF of the complete original program, but for your convenience, I've retyped the main bunch of lines which come into play with your changes, and then typed my changes in bold type. I just have the changes saved at this point, but haven't tried running the program, not only for fear of future splat files, but I'm also hoping you could take one final look at the modified program and see if you come across what you think will be any more problem areas in the program's saving or displaying process. Perhaps you might have some other suggestions or enhancements that you think would be handy or need modifying before the final save and run too?  I'm hoping you can first answer 3 questions, (the first 2 are just simple yes/no verifying):

 

SNIP ITS FROM ORIGINAL PROGRAM:

 

69 PRINT "SQQQQQQQQQQQQQQQQR WRITE RECORD  (Y/N)_              ";GOTO71

70 PRINTLEFT$(U$,7) ;:GOTO 69

71 GETW$;IFW$<>"Y"THEN71

72 OPEN1,1,1

73 FORA=1 TO8

74 IFN>0THEN80

75 PRINT#1,X$(A)

76 IFN>0THEN80

77 POKE37148,252:T=TI

78 IF (TI-T)<20THEN78

79 POKE37148,254

80 NEXT

81 CLOSE 1

82 IF N>0THEN83

83 GOTO86

84 N=N+1

85 RETURN

86 PRINT "SQQQQQQQQQQQQQQQQENTERED.  ANOTHER NAME (Y/N)           ";

(see lines 87-98 in the PDF if needed)

 

 

MY CHANGES:

 

0 OPEN 15,8,15

 

----------

Question 1:  If you refer back to your post on your program changes, for my following changes, due to lack of room, I had to combine and cram your things into one line, both for line 72 and 73. Can you just verify that everything is still ok entered like this: 

 

72 INPUT "FILE TO SAVE";Q$:OPEN 1,8,2,Q$+",S,W":GOSUB 1000

73 IF EN THEN PRINT EN,EN$,ET,ES:STOP:FORA=1TO8

1000 INPUT#15,EN,ER$,ET,ES:RETURN

 

-----------

Question 2:  The RETURN in line 1000 is just for the GOSUB 1000 at the end of line 72, and that RETURN for that subroutine should not affect any other subroutines throughout the program, correct?

-----------

 

If you'll check the full PDF, you'll see I deleted lines 77-79 and 99-100 since they all referred to tape, and then did:  

103 OPEN 1,8,2,Q$+",S,R"

 

------------

Question 3:  It seems now to be in pretty good shape, but can you do me a favor and take one final review of the full PDF and tell me if you see any other upcoming conflicts/issues with these changes, e.g. the printing sequence at the end of the program, or if we're actually ready for take off here?

 

Thanks, I really appreciate this!   

VICMAILPROG.pdf

Edited March 15 by newTIboyRob

[newTIboyRob]

@Casey You haven't yet replied, so in the interim, I continued to think of some more program enhancements. I went through it all again and found 3 more things:

 

1) Wouldn't a nice addition to the beginning of line 103 be:

103 INPUT "FILE TO LOAD";Q$:OPEN 1,8,2,Q$+",S,R":GOSUB 1000

just in case I come to the menu fresh one day when I hadn't already been working on something, but just wanted to load in and print a file's last recorded record?

 

2) In line 111, must we use the GET#1 or can INPUT#1 be used?

 

3) Was also considering what you said about how I want to handle the files from this program. The way the program is currently set up, if the same file name was entered in line 72, wouldn't the computer just overwrite the previous file with the current one being saved, as you say, it would just use 1 file and replace it each time?  Thus if you wanted to save the file under a new name you could still do that, e.g. Take2 and yet you would still have take 1 and the new take 2 would be a second separate file anyway?  I see what you mean about that the program could get even fancier with loading the directory, but I couldn't figure that out with the $, and I also got confused and couldn't figure out the way in the beginning of line 73 to tell the user a certain file name already exists and to name the new file something else. Those would be nice final things. 

 

Still hoping you'll reply to this and last post  

Edited March 18 by newTIboyRob

[newTIboyRob]

I've kept playing with the file concept in the program, but ran into a snag that perhaps someone can answer. It occurred to me that if in the program, the directory can just display, then there would be no need for the "FILE ALREADY EXISTS, TRY AGAIN" concept at all, as naturally you would just see the list of file names, save the current file as a new and different name, and that would do it. I experimented with what I've learned thus far, to see if the commands would work not only in direct mode but also in program mode... and I thought it was a promising and good guess, well... almost.  But hopefully there is a fix. In a sample program, I tried:

 

5 PRINT CHR$(147)

10 OPEN 1,8,15,"CD:VIC20MISCBUS":CLOSE 1

20 OPEN 1,8,15,"CD:VICMAIL":CLOSE 1

30 REM NOW I HAVE NAVIGATED INTO VICMAIL FOLDER AND DISK IMAGE TERRITORY

40 LOAD "$",8 

50 PRINT "WHICH FILE WOULD YOU LIKE";:INPUT F$

 

RUN

<cleared screen>

 

SYNTAX ERROR IN 1

 

I figure that good old VIC was interpreting the shaded title line containing directory name as a line # in the program.

 

Thus, the simple and obvious question: is there a way to nuke that syntax error (not have VIC believe it is a line #) and instead just have the VICMAIL directory list, sans error?

 

 

 

 

Edited March 19 by newTIboyRob

[+OLD CS1]

4 hours ago, newTIboyRob said:

10 OPEN 1,8,15,"CD:VIC20MISCBUS":CLOSE 1

20 OPEN 1,8,15,"CD:VICMAIL":CLOSE 1

This is extra work.  You are not required to close the command channel after each command.  Instead, you can do

10 OPEN 1,8,15,"CD:VIC20MISCBUS"
20 PRINT#1,"CD:VICMAIL":CLOSE 1

Just a program stylistic commentary.

 

4 hours ago, newTIboyRob said:

I figure that good old VIC was interpreting the shaded title line containing directory name as a line # in the program.

What is happening is your line number 40.  You are loading the directory over your program.  This is not the programmatic way to view a directory from within a program.  It has been a long time since I have read a directory from within a program, so I have no help here other than you can likely find such a program on them thar intarwebs.

 

 

[+OLD CS1]

12 minutes ago, OLD CS1 said:

 

10 OPEN 1,8,15,"CD:VIC20MISCBUS"
20 PRINT#1,"CD:VICMAIL":CLOSE 1

Just a program stylistic commentary.

Additionally, it would be worthwhile to add a line (this could be made into subroutines) to check the error channel and not assume the directory change was successful.

[carlsson]

It is not trivial to read (display) the directory from within BASIC. Here is a page that goes through the process step by step:

https://www.defiancestudios.com/2020/12/23/disk-directory-in-basic/

[+OLD CS1]

1 hour ago, carlsson said:

It is not trivial to read (display) the directory from within BASIC. Here is a page that goes through the process step by step:

https://www.defiancestudios.com/2020/12/23/disk-directory-in-basic/

That seemed a lot more convoluted than I remember doing.  I do not recall having to skip the BAM to get to files.  I found this:

 

https://www.lemon64.com/forum/viewtopic.php?t=27891

10 DIM FI$(144):FI=0:Q$=CHR$(34)
20 OPEN 1,8,0,"$"
30 REM SKIP DISK NAME
40 FOR I=1 TO 28:GET#1,A$:NEXT
50 REM READ FILENAMES
60 GET#1,A$:IF A$<>Q$ AND ST=0 THEN 60
70 IF ST THEN CLOSE 1:GOTO 200
80 FI=FI+1
90 GET#1,A$:IF A$<>Q$ THEN FI$(FI)=FI$(FI)+A$:GOTO 90
100 GOTO 60
200 REM PRINT FILES
210 PRINT FI;"FILE(S)":PRINT
220 IF FI THEN FOR I=1 TO FI:PRINT FI$(I):NEXT

 

This one will return with the list of files on the drive in the array FI$() and the number of files in FI.

 

BTW, the DIMensioning the FI$() array to 144 elements could consume a lot of memory.  You may want to trim that down to a more reasonable number.  It is 144 because that is the maximum number of files a 1541 disk may hold.  If you do reduce that, you should probably put a bounds check in the program to make sure you do not over-run the array.

[newTIboyRob]

@OLD CS1... pretty cool program there. But if I was going to introduce that routine in this Vicmail program, even sans the REM statements, I would still need about 6 lines for it, which would mean I would still have to renumber all the line numbers from 103-156 to stick that file lister program in at the load file name spot to first show the directory and then ask which file name to load?   

 

 

My other thought is that I could throw your program in at the very end of the Vicmail program, starting at line #158 by changing line 103 to become 103 GOSUB 158. The problem for me then is I don't know where to stick the RETURN and I will be getting RETURN WITHOUT GOSUB or GOSUB WITHOUT RETURN errors.  I am being extra cautious now, almost paranoid, about the splat files, or else I would be trying this stuff out more often, coming back, trying again, etc.  But I really just want to be done with this program now so it will work nicely, with no splat files occurring, although I am aware that those occur with unCLOSED files.

Edited March 22 by newTIboyRob

[+OLD CS1]

The RETURN goes where the subroutine ends.  Simple as.

 

What is the task of your subroutine?

1. Get a list of files from the disk
2. Present that list to the user
3. Allow the user to select which file to use
4. RETURN

Mind that in this scenario, you need to also offer the ability to start a new file.  Step 3 could be either selecting a number of the file in the list with an option to create a new file, or a free-form entry to type the filename, assuming the file will be created if it does not exist.  Understanding, as well, that the file operation will be different whether you are creating a new file (,w) or reading an existing file (,r).

 

The default operation is read (,r), so if you OPEN a file without an operation, like so

10 open1,8,2,"testfile,s"

The file will be opened for reading.  However, if the file does not exist, this line will produce a drive error (file not found.)  You must open with

10 open1,8,2,"testfile,s,w"

 

BUT!  ,s,w does not have to be in that order.  So, you could, instead, put a ",w" at the end of the variable holding the name of the file if it is a new file.  For instance

REM F$ HOLDS THE NAME OF THE FILE
REM ENTERED BY THE USER
REM ENTER WITH GOSUB 1000

1000 REM DIRECTORY FETCHING AND LISTING LOGIC

1100 INPUT "FILENAME:",F$
1110 PRINT "IS THIS A NEW FILE? (Y)ES"
1120 GET A$:IF A$="" THEN 1120
1130 IF A$="Y" THEN F$=F$+",W"
1140 RETURN

 

You might even instruct the user to put a ",w" at the end of the filename for a new file.  Entirely up to you.  In either case, the open statement for the file would be (using an arbitrary line number)

100 GOSUB 1000
110 OPEN1,8,2,FI$+",S"

 

(Sorry for the switches in programming case.  You get the idea.)

[Casey]

One comment I will add - I don't know anything how the SD2IEC works, but if it emulates a 1541, you'll want to make sure to check that the user actually entered a filename at the prompt (don't assume they did!).

 

On a real 1541 drive (and I just duplicated this on my The VIC20 using accurate disk emulation), suppose a user just hits Return at your INPUT for a filename

 

F$ will equal a null string, so your OPEN statement will work out to OPEN 2,8,2,""+",S,W"

 

The result of this is a SEQ file named "," on the disk.  The 1541 will happily let you create many such files on a disk, all named "," - it will not give you a "FILE EXISTS" error if you do the same thing more than once.  The "fast" disk emulation on The VIC20 doesn't do this, so perhaps the SD2IEC won't either, but if it accurately emulates a 1541, it is something to watch out for.

 

If you end up with multiple comma files, you can only access the first one for reading and you can't rename them.  You can delete them, but they all get deleted at once.

[+OLD CS1]

BTW, to answer your question about using INPUT rather than GET to read a file.  The short is, no.

 

The longer answer is that commas are used as field terminators.  If the line you are reading is

Quote

QUOTH THE RAVEN, NEVERMORE.

Then a simple one variable INPUT statement will read up to the comma.

 

If you want to use INPUT to read a line at-a-time, rather than GET for a character at-a-time, you will prefix each line in the file with a quote.

"QUOTH THE RAVEN, NEVERMORE.

 

This, however, introduces a new problem: now, any quotes contained within the text must be specially handled as a simple INPUT statement would choke on this line with a "?FILE DATA" error.

"QUOTH THE RAVEN, "NEVERMORE!"

 

There are some circumstances in which this paradigm is acceptable.  All of my program configuration files used the prefixed quote on each line followed by data.  However, none of the configuration lines were allowed to contain additional quotes.  For example, a configuration file for my BASIC program linker looks like this

"sysed 1.2-unreg
"sysed head
 1
"high subs/head
 150
"user manip/head
 700
"bbs config/head
 1000
"msg edit/head
 1300
"**
"***

 

This config file is read using INPUT statements, with string or numeric variables as appropriate.

[+OLD CS1]

6 minutes ago, Casey said:

F$ will equal a null string, so your OPEN statement will work out to OPEN 2,8,2,""+",S,W"

 

The result of this is a SEQ file named "," on the disk.

 

Even better, it creates a file with no name!  The directory entry looks like this:

1    ""                 SEQ

 

The up-side, I guess, is it can be accessed with an identical OPEN syntax.  So, yeah, check your user input.

 

Should we get into SHIFT-SPACE, yet?? 🙈

[newTIboyRob]

Oh my, I did not know what I was getting into    I will have to re-read all that great stuff multiple times and try it out downstairs to see it all in action. Thank you guys!

[newTIboyRob]

All right, I resurrected the MPS 803 printer and got it cranking. The result was a light gray, but more than decent PDF print out of the program, certainly visible at 300% magnification. It has the changes that were made days ago, but before the loading directory within the file concept and before any of today's new sub routine mentions, yet including my little personal tweaks like line 39. I figure we can all see it and talk about it this way, and at least the printout gives us an on screen visual instead of having to scroll through the bunch PDF screen shots with wide print I heretofore had to take on the VIC-20. With 407 views, there's gotta be at least 1 person besides me who wanted to see it printed out?  Ah that ancient grinding sound of dot matrix. Gotta love it!

 

Keep in mind that I have only saved and printed this current program, not actually run it, again for fear of splat files. (I'd still rather be 100% sure all is good to go before actually running it, hence my previous request for a review.) Unfortunately though that request has gone unanswered.

 

This printout is a nice starting point though. Besides my personal wording tweaks throughout the program, it shows the current line changes from the original manufactured VICMAIL program, namely lines: 0, 72, 73, deletion of lines 77-79 and 99-100 re:tape, the most recent line 103 change and line 1000.

 

I still need to figure out how to incorporate that directory program @OLD CS1 contributed since those line numbers would conflict, and what he showed 3 posts ago. Perhaps I can try over the weekend and see if I can put it all together, hand-write the changes onto my PDF, repost it, and all of us review and discuss the final version of it to pre splat-check before I dare try running it.  That is... if I can and do come up with something!  

 
 

VMAILMODP1OF2.pdf VMAILMODP2OF2.pdf

Edited March 23 by newTIboyRob

[+OLD CS1]

As I suspect you know, line numbers are arbitrary.  I used 1000-series in my examples, but you can use whatever you want.

[newTIboyRob]

@OLD CS1 ... I started to try to put all the pieces of the puzzle together, trying to utilize the directory files listing, opens, saves and loads. Thus far, I ran into 2 questions, but I think I am on the right track at least. If you follow along with me with my handwritten PDF "amend1", I will explain what I tried, ask the 2 questions and see what you think.  In my further reading of the difference between GOSUB and GOTO, with the former, it wants to go back with the RETURN, whereas with GOTO it doesn't want to return, yes?

 

So I kept the program as was in my last post, up until line 72. I now sent line 72 to lines 1000-1080 (overwriting my prior line 1000) in an attempt to first try to execute your subroutine of reading directory files (your first in your recent mini program posts). Now that the user knows which files are present, assuming he/she will not overwrite an already present file name, lines 1090-1120 then allow the user to enter the new file name (your other mini program, with my consolidation.) My goal is, after that subroutine, to return to unaltered line 73 and then have the program continuing on from there until the load file sequence near line 103, but here are my 2 questions:

 

1) If line 72 is calling on lines 1000-1120, at that line 1120, don't I actually want a GOTO 2000 (not GOSUB there) since the goal is to have it go to 2000 but not return to the 1120ish area, but rather use the return in line 2000 to get back to line 73 to continue program execution?

 

2) If the program can thus continue from 73 until it hits line 103 for the file loading concept, but yet I still want it to first use the file directory part of the subroutine so I called on that (again) with the same concept as earlier:

103 GOSUB 1000... I know that the goal of the subroutine is to have it so you can call on even the same one multiple times without having to rewrite the same lines, which thus would otherwise take up memory and not be as good programming practice.

 

The only thing here I didn't get is... I want the program, at the load file stage, to still call upon the subroutine for the reading directory files in lines 1000-1090, but then change at line 1100 so it now would have to say "FILE TO LOAD", yet still use 1110... but then at 1120, since we are now reading (loading back) the file, now we would need what original line 103 formerly was, with the concept being

1120 INPUT "FILE TO LOAD";F$:OPEN 1,8,2,F$+",S,R":GOTO 2000

 

Thus.. how I can get it to use the first part of the directory of file listing subroutine, yet change line 1100 to FILE TO LOAD and to alter 1120?  Would I need to make another new subroutine to send it somewhere else?  How can I change 1100 and 1120, so that in that part of the sequence, it will change those 2 lines and those 2 lines only at that stage?  Also, from 2000, I would want it to return then not to line 73, but to line 104....   ?

 

 

amend1.pdf

Edited March 24 by newTIboyRob