|
|
Post by gsteemso on Jun 1, 2015 2:04:42 GMT
*cough* Uh, yeah. That’s what happens when I only read the post I’m replying to instead of going back over the whole thread. Obviously, that was gibberish. My apologies. Basically, what I should have written was something like this:
So, Hydrophilic, you agree that when starting a new program, which I must point out is the normal use of (D)LOAD from direct mode, erasing the variables from the last one is the correct action. Program chaining as you describe it works fine when you LOAD one program from within another, in program mode. Where then is the problem you have with it? It sounds like you’re expecting BASIC 7 to magically read your mind and determine that “this DLOAD is different, please pretend we’re in program mode so I can chain these programs by hand instead of doing what I usually want this command to do.”
In other words, you have not so much found a bug as found a feature you wish Commodore had added—an extra parameter to the DLOAD command to tell it you don’t want a clean slate. I have to say, that is an amazingly specialized requirement. How does everyone else feel, have any of you ever encountered a situation where that functionality would be useful? I tend not to spend as much time programming as I would like, so have no relevant experiences to draw on in evaluating the proposed feature.
|
|
|
|
Post by C128Man on Jun 2, 2015 14:15:55 GMT
In other words, you have not so much found a bug as found a feature you wish Commodore had added—an extra parameter to the DLOAD command to tell it you don’t want a clean slate. I have to say, that is an amazingly specialized requirement. How does everyone else feel, have any of you ever encountered a situation where that functionality would be useful? I tend not to spend as much time programming as I would like, so have no relevant experiences to draw on in evaluating the proposed feature. I'm agree with you. It isn't really a bug. If is it necessary to have a clean situation after the dload, we could use "CLR" to clear all variable in memory. |
|
|
|
Post by hydrophilic on Jun 3, 2015 10:43:16 GMT
All I can say (if you examine the ROM), is there are many differences between 'program (D)Load', and normal/manual (D)Load...
Well my MAIN point was that (D)Load will *not* erase variables in program mode (good... if you don't want them, use CLR).
But when used in direct mode (no program running), DLOAD will *always* destroy (CLR) all variables!
This is A MAJOR PAIN IN THE ASS FOR DEBUGGING!!!!!!!!!!!! Did I emphasize that enough?
Sure, on limited systems (like C64) it is expected (almost required) to erase previous variables... but when you have a system like C128 (or CBM-II) where variables are clearly separate from programs, it is counter productive ("pain in the ass") to have all variables erased when not needed... if for some reason I *want* them erased, I can type "CLR"... simple!
But when the OS automatically erases variables (in direct [non-program] mode), there is no "simple" command to restore them (sure, you can do it with obscure PEEKs and POKEs)
In other words, destruction of variables was virtually required with old systems (like C64) but with bigger systems (C128/CBM-II) it is not needed... and because there is no "REMEMBER" command, this seems like a bug / fail to me...
Just my opinion... God knows CBM never consulted me before releasing C128 (or any!) version of BASIC...
|
|
|
|
Post by C128Man on Jun 24, 2015 18:25:00 GMT
One more thing about DLOAD. It's also possible to load a program from disk with RUN "pgmname". It seems to load a program with RUN, erase all variables.
Example, same as above, except line 60
The main program:
5 if peek(dec("1300"))=1 then goto 70
10 scnclr
20 print "main program"
30 print "------------"
40 a=2
50 print "value a=";a
60 run "souspgm"
70 print "return main program!!"
80 print "value a=";a
85 print "value b=";b
90 end
The sub program:
20 print "sub program"
30 print "-----------"
40 b=45
50 print "value a=";a
55 print "value b=";b
60 print "end sub program"
70 poke dec("1300"),1
80 dload "mainpgm"
85 print "value b=";b
90 end
The result is:
main program
------------
value a= 2
sub program
-----------
value a= 0
value b= 45
end sub program
return main program!!
value a= 0
value b= 45
The variable A isn't pass to sub program, but the B returns to main program
|
|
|
|
Post by hydrophilic on Jun 25, 2015 7:27:46 GMT
Yes, RUN gives you the power of DLOAD + CLR. Great command for launching a brand-new program (never use it for program chaining!) I feel/empathize with Gsteemso's comments... but my point was that I wish/think/promote that DLOAD should operate the same in direct mode as in program mode. Sadly DLOAD will CLR all variables in direct mode... this was a virtual requirement with older systems (like C64), but is unnecessary (and a true burden) with more advanced systems (like C128/CBM-II). Anyway, thanks for your demo code, bendevil! [EDIT]I found a hack to get around the direct-mode version of DLOAD... use BLOAD... This will load the BASIC program without destroying variables... but it is dangerous/risky/advanced! So if no VIC-II bitmap has been allocated, an the PRG was saved with no allocated bitmap (on C128) then you can simply do: BLOAD"filename"But if the program was from VIC-20 or C64 (or C128 with different GRAPHIC mode), then you MUST add parameter "P" with the correct load address... Basically (no pun) there are only 2 options with standard C128 setup... BLOAD"filename",P7169 :REM no VIC bitmap has been allocatedor BLOAD"filename",P16385 :REM a VIC bitmap has been allocatedPlease remember this hack is only for DIRECT mode... you could use it in a program IF you also include a GOTO (first program line). Well the program mode is totally off-topic, but here is a simple demonstration disk: Test.d64 (170.75 KB) So you see, this is truly a hack, and another reason why the official DLOAD is buggy. [Edit 2]Almost forgot! If you try this Direct-Mode hack, do NOT attempt to edit or save the newly-loaded program. This is because BLOAD does not update the "end-of-basic" pointer... No problem in a program, but in Direct-Mode, attempting to save the program will silently fail (unless magically the b-loaded program was the same size as the first), and worse, attempting to edit the program can cause the entire system to crash (memory wrap)! So you see (again) this is truly a hack... yet another reason why DLOAD is buggy. |
|
