Re: Pointer at the start of a BASIC line: what good is it?

On Nov 1, 2021, at 11:02 AM, Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net> wrote:
> * On Sat, Oct 30, 2021 at 06:37:04PM -0700 gsteemso wrote:
>> I believe the distinction is something like, if you do a {LOAD
>> "file",unit} the above behaviours apply; if, on the other hand, you do
>> a {LOAD "file",unit,1} then newer-model BASICs will blindly honour the
>> load address stored in the file (extremely useful for machine-language
>> code).
> 
> While the ",unit,1" honors the load address, the relocaiton code is
> called in all cases on the VIC 20 and C64. That is, if you load
> something into BASIC RAM, it will be relocated.

Eh? I could have sworn...

> Of course, if you have a ML program that start at $C000 (on a C64), the
> relocation code will not find anything useful at $0801 other than  what
> was there before, and it will behave "as if" it was a no-op. However,
> the code runs.

That makes sense!

>> Analyzing the exact behaviour of a bare LOAD command, vs. one which
>> explicitly states the normally-implied secondary address of zero, vs.
>> one with a secondary address of one, is greatly complicated by the
>> distinction between how a specific version of BASIC interprets it and
>> how any specific IEEE-488 or Commodore Serial Bus device will
>> interpret it.
> 
> What does the IEEE-488 and Commodore Serial Bus have to do with it? At
> least on BASIC 2 and later, it was a clear distinction between BASIC
> load and KERNAL load. This was not true on BASIC 1, so there, you might
> have a point.

Ah, _that's_ what was tripping me up! Yes, it does indeed differ substantially between the BASIC level and the kernal level.

> Actually, the ",unit,1" will not even be propagated to the floppy; it is
> a computer-only distinction!

At the BASIC level, certainly! *grin* In fact, according to Hydrophilic's unparallelledly awesome BASIC Encyclopedia, the interpreter behaves as if any _even_ secondary address given to it was a zero and any _odd_ secondary address was a 1.

To be obsessively completist, at the kernal level... well, technically, the kernal has both high- and low-level routines for accessing numbered devices. The ones we're interested in here are (mostly) the high-level ones, which BASIC uses. Once an access is confirmed to refer to an actual (IEEE-488 or Commodore Serial) bus device, as opposed to cassettes/RS232/keyboard/screen, the secondary address is treated as a semi-opaque value -- only meaningful to the device in question.

For example, I know that various printers use them in a range of incompatible ways to expedite setting certain printing options for each job; and that Commodore's disk drives often used them as "channel numbers", which the drives' DOS used in pretty much the same way that the kernal used logical file numbers. (I will admit that, as haphazard and unsystematic as the whole mess was overall, Commodore did keep pretty solidly to a convention that channel 15 was for commands / responses.)

Basic only exposes the kernal-level controls for such things via the OPEN command, which is pretty much a bookkeeping operation with no direct effects... unless you use the OPEN "[filename]" form, which immediately sends a Commodore-specific bus command to the targeted device directing it to _also_ open [filename]. Ah, Commodore; always keeping things simple.

(*snerk* ...Nope, turns out I still can't say that with a straight face, even with a quarter-century of practice.)

G.

PS: An odd side detail of the aforementioned DLOAD and BLOAD: they were defined such that they can only address drives 0 or 1 on devices #8-11! If your data is on a unit outside that range, or on any but two of the partitions of a large CMD-type hard drive within that range, you have to use the cumbersome BASIC 2 syntax _anyway_.