Storing binary data in screens.

[JimBoyd]

IamRob wrote:

Also, if Control Characters are getting automatically converted to an Ascii displayable character, that takes away from the ability to use pointers and Control Characters in screen blocks.

I don't see the purpose of new Forths making Control Characters into printable ascii characters. Does that mean there will need to be different word definitions for different devices?

For example, displaying text to a display screen will display the Control Characters as an ascii character, but printing the text to a printer will print the Control Character as is.

To clarify, Fleet Forth's TYPE does NOT convert control characters, QTYPE does. This is so I can LIST a screen without the listing doing things like changing the text color or clearing the screen because a BLOCK of binary data was listed by mistake, or was indexed.
My metacompiler actually uses a certain range of blocks for virtual memory while building a new Forth kernel.
Fleet Forth's blocks can hold any type of data, not just screens of source code.

[BruceRMcF]

Note that you don't have to give up the convenience of 1KB Blocks to have bigger screens ... you can define a "QuadScreen" as four Blocks on a divisible by four block number boundary and just build a QSCREEN editor wordset to work with four blocks and a display unit. 64x64 is plenty of room to write liberally commented sets of word definitions.

[JimBoyd]

BruceRMcF wrote:

Note that you don't have to give up the convenience of 1KB Blocks to have bigger screens ... you can define a "QuadScreen" as four Blocks on a divisible by four block number boundary and just build a QSCREEN editor wordset to work with four blocks and a display unit. 64x64 is plenty of room to write liberally commented sets of word definitions.

I've mentioned something like this here and here.