Protext writes HEX20 everywhere?! (Winape)

[Zuki]

Hi.

I have this super strange problem: In Winape, Protext will write the value #20 everywhere in its working memory, when I load a file (in Protext).

I use the following Winape setup: CPC6128, Protext 2.2 on ROM slot 5, Maxam 1.5 on ROM slot 6 and AMSDOS on ROM slot 7.
No Plus features, Multiface etc.

I boot up Winape with the above configuration. I start Maxam and "E" into edit memory. Everything looks normal. (Work memory is all "0")
I now exit Maxam, and enter Protext.
I write a small test program:

org #2000
ld a,65
call #bb5a
ret

- Just a simple firmware printout of the letter "A"

I don't even need to assemble and run it - I just press "S" for save in Protext, reboot Winape, load my little proggy and alas: The entire working memory (from around #19D to #9A1E) is filled with the value #20

The Protext test program is also where it should be, at around adress #172. But everything else is #20

I certainly don't remember Protext doing this, when I was using my "physical" CPC.

I've tried with different versions of Winape. Different versions of Protext. Disabling Maxam. Using Parados instead of Amsdos. Swapping ROM slots. Using different disk formats in Winape. Using CPC464 or CPC6128

Always the same - I save a Protext assembler file and reload it - and memory is filled with #20 !

I can still assemble and run programs, but why those damn #20 when I load my program? (It is somehow down to Protext, as I have tried to disable everything else)

Any suggestions what is going on? 

[Zuki]

Ah!
It fills the memory with #20 up till HIMEM, so the MEMORY #XXXX command will limit this effect.

Curious however, I don't recall Protext doing this, when I was working on the physical CPC with a ram/rom board. I also fail to see the use of this whole #20-fill thingy. Guess Arnor must have had their reasons 

[GUNHED]

It's common practice for Protext! And I'm very glad it does it actually!

The reason is that files get saved in blocks to disc. So, after the end of the text in RAM further characters will come until the end of the end of the block (or sector buffer - depending on OS or DOS).

Why to add spaces (&20)? Just to fill up the gap between the end of text and beginning of the end-of-block-in-RAM border.
This means that the added space characters eliminate character trash (or even worse control code trash) after the end of the file.
I hope to be understood. 

[Zuki]

Hmm, I guess it sort of makes sense - to wipe the work area of trash data. (But why not just wipe it with zeros instead)?
I'm not sure I fully understand, but at least this way, it is easy to keep track of the work memory 

Anyway, thanks for your answer 

[eto]

(But why not just wipe it with zeros instead)?

#20 is SPACE. If you wipe it anyway, then probably it makes most sense to use a the character code for SPACE.

[GUNHED]

Space is not a control code.