RE: [colorforth] modern block style / response

[Fréderic DUBOIS <frederic.dubois@xxxxxxxxxxxxx>]

...

> > When editing as an example, one is changing things in ram 
> > often using block.
> > When finished changing things, one issues a save command to 
> > write all (nc)
> > number of tracks back out to the floppy. Block can address of 
> > course much
> > more than the maximum capacity of the floppy. The nc variable 
> > for Chuck's CF
> > is initialized to 9 tracks. to use more adjust the nc 
> > variable and do a
> > save or edit the color.asm file.
> 
> 9* 10 sectors per track= 45KB ?!

It is 18 sectors per track -> 81KB

> Let's say... I reserve the 32 upper KB for this while the 
> lower ram is for
> workspace. To map another group of 32 blocks I would have to 
> have a special
> word, say SECTION. Of course we should do SAVE before. It 
> seems to me that
> SECTION is a kind of (old) BLOCK on a larger scale. Maybe 
> there's something
> better to do?
>  

I've missed a point which is that when doing 0 BLOCK 1 BLOCK the data is
still there for both address.
Thinking twice, maybe there's no point in trying to copy CF's block into my
environment - some will say, there's also no point in using an 8086 and
that's what I sometimes think in flashes of lucidity - but that's just a
hobby after all( my forth system, not flashes of lucidity).
To follow the idea of RAM blocks I think that my situation is closer to RAM
banks.
In my implementation when issuing a BLOCK command no address is returned;
instead the block is loaded always in a same area pointed to by BUFFER. In a
system with RAM banks or equivalent ( like EMS memory) the principle would
still work, and that's nearly what my disk-cache does.

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com