Draft: Blocks wordset

[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.