newTIboyRob

Chrome has been blocking things such as.d64's for me as well. I tried Microsoft Edge and thus far haven't encountered any DL issues.

@351cougar yes, I am aware, thank you. The members here and the forum itself are both excellent.

Well, it's been about 7 weeks since I last posted, but I just wanted to say this thread had a happy ending. Today I was able to first take off the silver Start key, get the flashlight in there, notice the brown piece inside, see the large spring was still in tact, see there was a small empty hole at the center base of the brown piece, insert the new thinner/smaller spring in there, see that the bottom of the white piece has an empty circle which will allow the thinner spring to come up and through that, and then finally gently press the white piece with the posts all the way down back in. It didn't take right away, but with another firm press, it did take, and the white piece was nice and springy. I put the silver piece for the Start key back, and bam... right back in business. Though this might be something many of you are laughing at, for me, to just bite the bullet and be a little brave and get in there, see what I needed to do and then actually do that correctly and get it to work ... all highly gratifying. I tested it out with a game of Pitfall which requires the Start key to use. It is naturally quite firm and needs a good heavier feel pressing, as it will need quite a bit of presses to "catch up" with the other more loose springs on the keyboard, but, at least she works. I just wanted to share the nice story and positive results with my fellow Atarians

@OLD CS1... I am getting closer and closer I think to getting this thing to work, but I still have a few things to fix, because I saw I unfortunately created another splat file. I was hoping not to abandon this project (as I/we all decided it was best to do with the Data Manager program on my other thread) since from your help and Casey's help it seems I am very close. The current status is that the main dot matrix listing I posted works great and my handwritten amend1 showing how I routed your drive directory file list segment, despite your last post, worked PERFECTLY too (thank you!). However, when I added 4 new lines which involve the ,S,R and ,S,W, those, in conjunction with the main program itself, caused the new splat file. So I would have to post those 4 lines and we would have to get those correct and working in conjunction with the entire program, which means reviewing it as a whole to make sure there are no other conflicts within the entire program. The whole splat file thing just makes me, well, nervous. I would only want to finish the program off if you- (addressing you here because you are the one who has been mostly with me on this thing), but I will say it to everyone here on the thread, so, if you all will try to help fix the error/s and take this home. I will, this one last time, put my card back in the PC and just delete that one splat file, but never again will I do this. It's just too scary. So what I am saying is that I don't want to try saving another sequential file again until we are 100% sure the final program will not cause any more splat files. If I posted the 4 lines, would you (all) work with me to finish it off and ensure it is working perfectly before I would try to save a data file again? If no one wants to examine this with me, I will abandon it, because I just don't want to risk any more playing attempts on my own with saving a data file since each imperfect attempt will likely cause a splat file. I was personally willing to try more experimenting to get it on my own, but factoring in the splat thing, at this point, I actually just need it to be correct, tested, and ready to go before I would again run the program. This is the likely the last VIC-20 program modification for the SD2IEC I will ever try myself or even ask about at all.

@carlsson .. good points as usual. After consideration, I think the reward doesn't seem worth the risk, as even though it wouldn't be a lot of work to change connections and drive numbers, there's still a slight possibility that something still could just go awry, short circuit with the SD2IEC or the like, not to mention that even if I can get it saving to the 1541, who's to say that the disk image/program will even behave with that; it's not guaranteed. If someone had prior cleaned this program up and adapted it for SD2IEC use, then tested it and then archived it, there was the answer. But perhaps that was a lot to ask. Under the circumstances here though and based on the fact that it had just been archived before it was adapted for and fully tested in the SD2IEC configuration, there is just too much to do here and I think it's time to throw in the towel with this one. Of course if anyone reading does get the program to work, save, load and run with the SD2IEC, please let us know! You tried, I tried, we tried. Thanks for giving it a go!

@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

@carlsson... so I had a go at this program. Saying it's odd and has so so many potholes to fill is an understatement. I got varying results, which I will type out just so we can see its wacky unreliability. But I am starting now to think that this program requires major surgery, and maybe I- and since I am dragging you along in tow, I'll say we- want to jump ship right at this point. Take a read: Before even entering anything, the program with CR still believes both that the disk contains data and that record #1 already exists. Maybe yes to the first (I selected n), but no way on the second, as I had yet to make a record. Then I tried to add a record #2. You definitely made a huge improvement here, as at least data entry was accepted, so I typed: FIRST: ANDERS (in your honor) LAST: CARLSSON PHONE: 1234567890 EMAIL: JUMPSHIP@BLAH.COM then I pressed 0 for save, and I saw a solid green light but also a solid red light at the same time appear on the SD2IEC. I [RESET] I tried AD for a record #3, with reversing the above data, thus: CARLSSON ANDERS 0987654321 SHIPJUM@BLAH.COM. Tried saving it, flashing red light. [RESET] I tried BRowse. No matter what record # you enter, it defaults to displaying the last set of info you had just entered along with the flashing red light. If you enter, eg. rec #3, it will just return to the main menu[RESET]. That stinks if you actually do want to browse different records. This was interesting though: after I entered EX for exit, it briefly displayed "Writing Key File" and then jumped to Basic Ready at the basic screen... so it definitely saved something. However, in the basic directory, there was no new file shown. (Though not showing in basic, I'm wondering if any data files would show on the FB-20 disk image?? I didn't check.) I tried SEarch... No matter the record, it will only find the field for the first 3 letters per line entered: It will find "ANDERS" if you type in "AND" in the first name line, but will not find SON in the last name field, but will find CAR. I tried CHange... Record #1's data comes up, but there is no ability whatsoever to move within fields to change data. What kind of "change" is that??? I tried other things, like adding new records, but if you BRowse it will replace the old record with the last current data entry and only display that. One thing that was consistent is that, despite the red with green lights on the SDIEC, it was saving records, as the next time I came around, it recognized there was a saved record#2. There were times though, e.g. when I tried adding a record #3, when I saw no green light, just the flashing red. So the upshot here is you really don't ever know if it actually saved everything. Likely not, if there was no green light activity. It tried to read records, but it just scanned through them briefly and did nothing. Big whoop! [I avoided DElete and PR, and EX does sorta write the file to the SD2IEC... I presume.] On and on... you get the idea. What good is it if you can't see the data files saved, can't make any changes and can't really tell what it will retain? Unreliable with a capital U. As I say, it would require quite a bit of cleaning up, in my opinion, and I saw it's a long ass program ending at line #10009. In short, it needs the Hoover Deluxe, not just the Hoover. Then it may be able to be saved. It is one of those nagging things that you want to be right, but isn't, and to get it right requires quite a bit. Abandon ship or are you feeling further adventurous with it, since you were able to make some waves?

@carlsson ... thanks for delving into this thing. Yes, I had the same experience, at first it wasn't taking any form of input; it was like dead in the water. So from what you last mentioned, maybe this program will only have limited use, but at least you got it working on your end. That right there is just really cool. Thanks for your take 3 version, I will give that a go tonight after the bad weather here clears, see what occurs and report back. Just so I know what you mean, can you redefine what you mean by fields and registers? I think of field as the area of the line where the input data goes, and are we saying by register, like a record or the entirety of what makes up a whole file?

Has anyone got this disk image program running on an actual VIC-20? I still can't get the program to run smoothly.

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

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!

@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.

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?

@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

@carlsson Boy, I did not have any luck whatsoever with your D64 unfortunately. For the time being, I copied that image loose (folderless) on my SD card. The D64 image looked fine on the PC, appearing just as you posted it, vic-data-manager2. Once I got into that folder in regular basic on the VIC itself, (its directory name simply being "DATA"), the file that appeared was a supersized X followed by a bent looking stick icon. I figured out that since I couldn't type to load that, I just cleaned up the bottom of the screen, then scrolled back up to that file line, added the ,8 and it did load and run the familiar looking program. However, same old story thereafter, with added bizarreness: As previously mentioned, it still reported that the Disk Contains Data Erase [y/n], so I selected n. When I tried CR from the menu, this time it did let me create a random record # 51, but when I tried to type anything, or use the AD option, it showed a lime green cursor in the left column next to the #1 field and none of the keys worked except return. Thus it would only move the lime green cursor down the column next to the other sequential numbers. Naturally I stopped here. Now what to do?