Closed chitselb closed 6 years ago
solution: When scr
becomes -1, add #vmbuf to it, wrapping around to the last screen. Since screen 0 can always be located by STOP-HOME
this should improve navigation speed in the editor.
fixed scr
Thinking further, source can be loaded from screens, and screens can be loaded from any filesystem (including tape!). Since the reference machine is PET s/n 700251 with tape, that means disk block i/o support can wait for the C=64 port
apparently
scr
should not be a negative value.0 max
might helpThe real fix for this is to allow block/scr/prev to be 16-bit unsigned for most purposes, pluggable VM for disk and SD-card etc.. support, and capping virtual-memory-on-cassette-tape(tm) at packet 255. Could maybe add a system user variable, VMOCT . VMOCT is the maximum # of packets available to
vmbuf
. When 0, VMOCT disables altogether that whole tape thing , which is what most C=64 users will want. Otherwise , and going up from packet 0 wraps around in a ring-buffer style to packet # VMOCT. This could also be used to implement 'shadow screens'