Draft: Blocks wordset

[jkotlinski]

No description provided.

[ekipan]

if it stays an odd number, say 5, then any block editor that does shadow blocks will still be able to use all 5 buffers while you browse +2 and -2

[ekipan]

whoops nvm I should have read more, I see you're doing #11 mod please ignore.

[jkotlinski]

It is really nice that you take a look at things. It is maybe getting closer to first release. Test and documentation are still missing.

[jkotlinski]

Also to be done: update EVALUATE, \ and REFILL to support blocks.

Edit: Done

[jkotlinski]

Probably need to support:

• disk change
• release/delete blocks

[ekipan]

I've avoided the problem by only using ( in my blocks. FWIW my vote is 40 to (1) make editors simpler to implement and because (2) horizontal scrolling is kinda gross UX. It's definitely unorthodox though. Perhaps a poll is in order?

[jkotlinski]

I don't think a poll is needed, just need to work out the pros and cons. I agree 40-width makes a lot of sense for the reasons you mention.

The strongest argument for 64 is that long strings can be useful, for example, it allows defining a S" string that is 40 characters long or more. I am not sure if there is a clean way to do the same with 40-width.

[jkotlinski]

Actually: I realize now, long lines is not a problem for blocks. When LOADing a block, S" will parse until the next ", even if it is on another line.

It is a problem if the code is later copied from block to file, but then it can be resolved by joining the string lines to a single long line.

I think altogether, that makes a strong case for 40-width.

[ekipan]

Unlike files, block LOAD is specified to use the entire block source as the input buffer, so words like s" and ( should be able to span across lines portably if I understand correctly (if I don't understand correctly please let me know).

Another strong argument for 64 is to make it more likely to be able to directly reuse any Forth source already in 16x64 screens out there that have \ comments. I'm personally ambivalent to that though.

[jkotlinski]

For the most part, I don't think porting from 16x64 to 25x40+24 would be a big problem. At least not compared to all the other problems when porting code from a Forth to another.

[ekipan]

You can compact the string code a bunch more, if you care:

: holds ( c*n n -- ) 0 do hold loop ;
: _0_t_s ( t s -- 0d ) decimal 
0 #s bl hold 2drop 
0 #s bl '0' bl 3 holds ;

( ... )
<# _0_t_s 'b' '-' 'a' 3 holds #>
<# $d hold _0_t_s 'u' '2' 2 holds #>
<# _0_t_s 'u' '1' bl '5' 4 holds #>

Though I think 'u' '2' 2 holds costs one more byte of code over '2' hold 'u' hold. If you think holds is too clever for its own good you can always just continue holding without it.

[jkotlinski]

@ekipan thanks for the tip. however. i will leave that code unoptimized until later. in case my solution turns out to be wrong.

[jkotlinski]

Another difficult decision: Allocate blocks once upfront, or just-in-time?

I am toying with the idea to allowing addressing blocks 1-199, but that block sectors are only allocated on first write.

The good thing about this is that it allows sparse sequences, i.e. using blocks 1, 10 and 100 will only allocate 3kb worth of disk sectors. This might make things more manageable, for example one set of words can be on blocks 10-13, another on 20-25, et.c., with some unallocated blocks inbetween.

The drawback is of course the risk of sudden and unexpected "disk full" errors. Also, adjacent blocks would no longer be guaranteed to be physically close to each other on disk (leading to longer seek times).

What do you think?

[jkotlinski]

Another idea that kind of dodges all problems, but adds complexity and other problems in return:

\ maps the given 1541 drive for BLOCK usage.
\ the drive is expected to hold a disk that is either
\ empty, or has previously been used for blocks.
\ watch out: block disks are not DOS compatible!
\ valid block id's are 1-170.
: BLOCKS ( device# -- ) ... ;

I guess the problem with this approach is especially for new users, who might need to go through hassle of creating empty .d64 image, mounting to drive 8/9, and learning BLOCKS command, before even entering the editor. Also, it is just a hassle that it is not at all DOS compatible.

[Whammo]

It's interesting that a 4 block file has 1016 max data bytes in it. That could be a screen full, and a filename for the next screen. This is also how screen memory is arranged. 1000 bytes of screen memory then 16 unused bytes.

[jkotlinski]

The 40x25=1000 bytes most importantly leaves space for eight sprite data pointers.

[Whammo]

Yeah, the sprite pointers start at 2040.
2024-2039 are unused.

[Whammo]

This might be fun:
https://www.pagetable.com/?p=568
A 256 Byte Autostart Fast Loader for the Commodore 64
Could be extrapolated to a fast sector loader.

[Whammo]

Applications that require large amounts of data to be processed are best stored in relative disk files. These will use the least amount of time and provide the best flexibility for the programmer.
C64 Programmer's Reference Guide.