Just to explicitly answer your questions ...
1- what is the easiest way to measure space still available within each segment, and % already used by my program and data?
As carlsson said, right now, the easiest way is to check out the "CFG" file generated by the assembler (the other half of the "BIN+CFG" package). Alternatively, you can account it by hand by reading the assembler generated listing file (if you enabled that in the command line).
2- should I generally aim to occupy 100% of one segment before starting to use the next? Or would leaving some buffer space available be advisable for whatever reason?
Generally, you should aim to fully fill a segment before moving to the next, but it is up to you. As intvnut suggested, leaving large gaps in multiple segments may cause you trouble down the line, as your program grows and needs additional space. Backfilling large data tables across splintered segments can be a big headache.
Technically, it does not matter. To the Intellivision, it is just a single memory space, and it will access it in the same way, at the same speed, wherever it is.
The only requirement is that contiguous data tables and subroutine procedures must exist wholly within a single segment. That is, a procedure or a large data array cannot straddle multiple segments.
3- between using one larger segment, or 2+ smaller ones, is it all the same? Any benefits to opting to use more, smaller segments?
Technically, it is all the same. The only benefit of using multiple smaller segments is to avoid the headache of having to allocate your program across them when one fills; provided you already know that your needs will be met by the target segments.
For example, in my program, I knew I had a lot of graphics and music data, so I designated the largest segment (ROMEG #2: $C040 - $FFFF = 16K) as a "data segment," and the default 8K segment at $5000 (ROMSEG #0) as the "code segment."
Thus, all code modules would be included in segment #0 and all data tables in segment #2. Then, for most of my development, I didn't have to worry about my program overrunning its ROM space.
All that said, keep in mind that this may get you up to speed quickly, but it doesn't absolve you from tweaking the allocation further, especially if your program grows larger than those two segments. In my case, I eventually ran out of data space in ROMSEG #2 and had to put the overflow in additional segments, eventually using them all.
4- does the choice of segment have any impact on performance, compatibility or ability to run the code on real hardware? I noticed the "avoid" notes on the table above, but don't quite get the practical meaning, or what needs to be done differently on IntyBASIC for instance.
There is no impact at all on performance, but compatibility and ability to run the code on real hardware is limited by the choice of cartridge PCB you choose to use. The segments described in the 42K.bas example program are the most commonly used by home-brewers because they are the parts of the memory map accessible to the CPU which were largely reserved for future expansion but left otherwise unused. (The Intellivision's memory map is truly a mess!)
Those segments are currently supported by the CC3, the Intellicart, the JLP cartridge family from LTO productions, and the LTO Flash!. Beyond those very well known ones, you'll have to discuss the supported ROM memory map and features of the individual platform you choose, with its manufacturer.
The warning about the "EXEC's ECS ROM probe" is related to the way the Intellivision Master Component looks for and detects the ECS. During the bootstrapping routine, the EXEC probes the $7000 memory block to see if there is something there. Typically, this block is undefined in the Master Component, but peripherals like the ECS occupy it. If the EXEC notices that there is something there, it will jump and execute it, essentially transferring control to the peripheral device.
We don't really want to obstruct that mechanism so what we do in home-brewed programs is to skip the very first block in that memory range ($7000 - $70FF) in our memory allocations, effectively starting the segment at $7100. That's it.
Therefore, when the Master Component probes that address, it will find nothing and continue as normal; or if the ECS is present, it will boot it as normal.
The second comment regarding the "game's ECS ROM mapping out code" is the other part of that ECS equation. So now that you skipped the EXEC peripheral probe memory block, if the user plugs in an ECS cartridge, it will boot up normally, and its own version of the EXEC will take a chunk of ROM designated specifically for itself.
However, as a home-brewer, you do not intend to use the ECS EXEC at all, and so you would prefer to make that memory space available to your program. There's a specific trick we do for this which involves hooking into the device probe address at $7000 and inserting a small bootstrap code that essentially bank-switches the ECS ROM to another bank, sending it out into the weeds, and freeing the memory range $4800 - $4FFF for your program.
Thus, that segment will only be available if your program performs that bootstrapping trick, which means that your target platform must support bank-switching. That's what the warning means: ROMSEG #5 is only available provided you account for your program mapping out the ECS ROM. That's it.
Edited by DZ-Jay, Fri Jan 11, 2019 6:18 AM.