For the second, no, it's not. I just checked (with Axe 0.4.0). You have to do

Value→{Pointer}
Fill(Pointer,X-1)

I think it's because Fill( takes the pointer of the data, but Value→{Pointer} leaves the data value itself. In otherwords, you're Fill(ing the data at pointer Value.

Oh, so the one line would work if Value was a GetCalc( statement?

I dunno if those are there to establish a foundation for the automated linking or what...

Perhaps it involves bit manipulation?

So, quick tutorial on Port. (And the link port in general)
As you know, the link port has two lines on which to send data, the tip and the ring. Each can be in one of two states, high or low.
When you write a set bit, it pulls that line low, while writing a reset bit allow it to go high.
Bit 0 is the tip and bit 1 is the ring.
Like Quigibo said, you write 0 to let both go high, 1 to pull the tip low and let the ring go high, 2 to let the tip go high and pull the ring low, and 3 to pull both low.
Reading, however, is somewhat different. Instead of a set bit indicating that it is low, a set bit indicates that the line is high. A reset bit indicates that the line is low.
This means that when you read 0, both are low; 1, the tip is high and the ring is low; 2, the ring is high and the tip is low; 3, both are high.
With respect to two connected calcs, a line is read as low if either calc is pulling it low. The line will only be read as high if both calcs are letting it go high.
Hope this helps!

This is no data transfer routine if i remember correctly, this is direct access to the hardware, so you have to write your own data sending routines if you want to send actual numbers.  Here is my understanding of the command:

The IO cable has 3 wires, called the tip, ring, and ground.  Ground is not used for transfering data, so we will only concern ourselves with the tip and the ring.  The ring and the tip can either be in two 'states' or voltages, high and low.  The calculator can either "pull" a ring/tip low, or let it go high.  What this means is that if it is "pulled" low, the calculator forces the tip/ring to go into a low voltage.  Even if the other calculator is letting the voltage go high, the tip/ring will still be at low.  Thats where the term "pulling low" comes from, because the calculator "pulls" and forces the voltage.  When the calculator "lets the voltage go high" it does not force it, but only lets it go.  If both calculators let go, the voltage goes high.  If either one (or both) of the calculators is pulling low, the line will be read as low.

To SET the cable, use the #->Port command.
0 lets both lines go high
1 pulls the tip low
2 pulls the ring low
3 pulls both lines low

To READ the port, use the Port->Var command.
0 means both lines are low
1 means tip is high
2 means ring is high
3 means both lines are high

Yeah reading and writing is confuzzling, but thats the way it works unfortunately.  Note that i haven't actually used the link port at all so all of this is conceptual if any of this is incorrect please let me know!

Let me explain the new masked sprite routine because its really cool.  The first layer is the sprite and the second layer is the mask.  The way it works is that anything drawn on the first layer is going to be black or gray and any bit that is neither in the sprite layer nor the mask layer becomes transparent.  So the codes are 11 for black, 10 for gray, 01 for white, and 00 for transparent.  Think of it like a controlled Pt-Off() that also draws gray since you can control which pixels to see through when drawing.  The routine is slower than the normal sprite drawing but much faster than trying to draw to both layers individually.  Also, due to the choice of color codes, you can use this for monochrome masking as well with the first layer being the sprite you want to draw and the second layer is black in the areas you want to draw over.  However keep in mind that the routine still draws to both buffers so make sure you aren't storing anything there first.  Here is an example

Layer1:
    ████████
  ██        ██
██            ██
██    ████    ██
██    ████    ██
██            ██
  ██        ██
    ████████

Layer2:
    ████████
  ████████████
████████████████
██████    ██████
██████    ██████
████████████████
  ████████████
    ████████

Result:
░░░░████████░░░░
░░██        ██░░
██            ██
██    ████    ██
██    ████    ██
██            ██
░░██        ██░░
░░░░████████░░░░

The crosshatched color means those pixels don't change when drawing the sprite (transparent).

Also, please let me know if you are still getting errors that you were getting before.  I tried to fix as much as I could but since I still can't figure out the problem, that means I'm just guessing so I need your help to see if anything actually got fixed.

Let me explain the new masked sprite routine because its really cool.  The first layer is the sprite and the second layer is the mask.  The way it works is that anything drawn on the first layer is going to be black or gray and any bit that is neither in the sprite layer nor the mask layer becomes transparent.  So the codes are 11 for black, 10 for gray, 01 for white, and 00 for transparent.  Think of it like a controlled Pt-Off() that also draws gray since you can control which pixels to see through when drawing.  The routine is slower than the normal sprite drawing but much faster than trying to draw to both layers individually.  Also, due to the choice of color codes, you can use this for monochrome masking as well with the first layer being the sprite you want to draw and the second layer is black in the areas you want to draw over.  However keep in mind that the routine still draws to both buffers so make sure you aren't storing anything there first.  Here is an example

Layer1:
    ████████
  ██        ██
██            ██
██    ████    ██
██    ████    ██
██            ██
  ██        ██
    ████████

Layer2:
    ████████
  ████████████
████████████████
██████    ██████
██████    ██████
████████████████
  ████████████
    ████████

Result:
░░░░████████░░░░
░░██        ██░░
██            ██
██    ████    ██
██    ████    ██
██            ██
░░██        ██░░
░░░░████████░░░░

The crosshatched color means those pixels don't change when drawing the sprite (transparent).

Also, please let me know if you are still getting errors that you were getting before.  I tried to fix as much as I could but since I still can't figure out the problem, that means I'm just guessing so I need your help to see if anything actually got fixed.

Wow nice, that will come handy for sure for grayscale games. Nice update. I will try to test app compiling when the app exist at one point, although I cannot promise yet.

Also although I am late on this, the previous update was pretty great too. I also noticed my ball game dropped by a few bytes from 0.3.3 to 0.4.0

The routine only renders the sprites, you still need to call DispGraph^r to display them, so it still needs to be in 6mHz. (I'm pretty sure.)
At least for displaying greyscale. Rendering the sprites should work at either speed, cause I think it's just a modified version of the original sprite routine.