[Coco] format problems

[L. Curtis Boyle]

I think it could be patched for no-halt as well… would have to figure out an 8K block that is “safe” to swap out while it’s formatting.
L. Curtis Boyle
curtisboyle at sasktel.net



> On Jan 19, 2019, at 8:44 PM, Gene Heskett <gheskett at shentel.net> wrote:
> 
> On Saturday 19 January 2019 17:21:26 L. Curtis Boyle wrote:
> 
>> Format takes enough system RAM to build an entire track image at once
>> (so it can build the interleaves), and not just the data portion, but
>> the header, footer, sync, CRC, etc. The system call for write track
>> should be changed to allocate a temporary 8k block from outside the
>> system map, since it has to kill IRQ’s during the write track anyways
>> (for the standard floppy controller; no halt controllers and/or hard
>> drive controllers will do things a little differently).
> 
> So that might not/won't fix it for my no-halt disto controller. Whats it 
> take for the no-halt? Humm, I thought that was disabled during 
> formatting? The fact that its coming into rb1773 at write track, or read 
> track, either one should bypass the sector buffer if rb1773 is written 
> correctly.  Have we found a bug in rb1773?  Sure nuff smells like it, 
> Curtis. Maybe I should try it with another, halting controller? That 
> would be a revolting development to quote Jackie.
> 
>> As for SHELL, 
>> it should be kept at <$1E00 bytes simply so that it doesn’t take more
>> thank one 8K block in it’s process space. Since processes always have
>> the program mapped at the end of the 64k process space, and the last
>> $200 (512) bytes is always vector page RAM and I/O, if you push it
>> past that it has to allocate 16k in your process space so that it
>> won’t try to overwrite the vector page & I/O, and still leave you up
>> to 56k data area for the shell to use, if needed.
>> 
>> Sent from my iPhone
>>