SAM File Headers (HDR, HDL)

Play it once, SAM. For old times' sake.
Post Reply
User avatar
flatduckrecords
Manic Miner
Posts: 759
Joined: Thu May 07, 2020 11:47 am
Location: Oban, Scotland
Contact:

SAM File Headers (HDR, HDL)

Post by flatduckrecords »

According to the SAM Technical Manual the file header buffers store the length of a BASIC program as a three-byte value. (That is, the file headers used by the ROM, I know the DOS does its own thing). But when I inspect it, the values don’t seem to be in a little-endian byte order (the middle byte seems to be the LSB for example).

How do I calculate the length?

User avatar
Stefan
Manic Miner
Posts: 764
Joined: Mon Nov 13, 2017 9:51 pm
Location: Belgium
Contact:

Re: SAM File Headers (HDR, HDL)

Post by Stefan »

As you, I would expect them to be little endian, but of the special sort that live on Endor.

This is from memory, check if it works out:
- lowest byte normal
- high byte - must remove top 2 bits (ie combined with low byte can address at most 16383 bytes)
- pages byte (how many 16K are involved)
User avatar
flatduckrecords
Manic Miner
Posts: 759
Joined: Thu May 07, 2020 11:47 am
Location: Oban, Scotland
Contact:

Re: SAM File Headers (HDR, HDL)

Post by flatduckrecords »

Thanks @Stefan,

Yes, looks like byte-16 must represent the pages (it's only ever been 0 in all my tests), leaving 17 and 18 as the word (with the top two bits lopped of) that describes the program's length. (Likewise for the other lengths that include variables etc).

It tallies up with what the system variables (PROG, NVARS, etc) say as well:



headexam.mgt

I'm trying to understand why I can't LOAD over the network. SAM seems to read the filetype and name correctly, but then just hangs like it's waiting for data. Hopefully peeking into the HDL buffer (now that I've made some sense of it, thank you!) will reveal what's going wrong…
Post Reply