[Coco] format memory (was) Gotek floppy emulator

[Gene Heskett]

On Tuesday 16 February 2016 07:25:15 Gene Heskett wrote:

Another update way below.

> On Monday 15 February 2016 20:29:02 Bill Pierce via Coco wrote:
> >  Gene, on both my emulator and real Coco, smap shows 11k free. As I
> > said, I can format from the cmd line, but not from within something
> > else like the boot script from the ditro disks.
> >
> > One thing I've noticed is that 3.3.0 does not like older drivers. It
> > fares better with drivers built from the same build. Are all your
> > drivers in the 3.3.0 boot current? Or did you use some of your older
> > custom drivers? I even formatted my 4 gig partions on my Glenside
> > IDE with with my current boot.
>
> I did go down & play. I also have 11k free but its fragmented.
>
> Format needs $2b70 worth of memory for its data, or 11,120 bytes.
> With the dw cable unplugged, I was able to format a 180k disk, once.
>
> But then an old problem surfaced. This hd boot never lets go of the
> startup file, rendering it read-only to anything else, which means I
> cannot edit to kill some other things I do in it, the startup file 
> that could gain me some memory.  That seems to have been the scene
> since about 3.2.4 or so.  I can copy it,to a renamed file, edit it and
> save it by a different name, and once I have done that I jumped thru a
> couple hoops and managed to delete the original, but last night I
> saved it with a longer name from an older session of minted, twice,
> without finding the filename I had saved it as, so apparently my copy
> of minted can't save a renamed file.
>
> I have to plead that I've forgotten the save syntax of what I call vim
> on my system which is the tsedit with the patch that called it vi, but
> somewhere in the nitros9 history, vi became a device descriptor
> without consulting anyone who was using it as an editor, the best
> editor we ever had as it can handle a file 56k long!
>
> But no consideration to that, so someone destroyed the only editor we
> had that can handle a big file. I tested minted, and it out of memory
> at about 10k for max file size. Dynastar is unlimited, but a PITA to
> use as it only handles 8 or 10k at a time, so I had to use ded to
> rename it vim, no problem there as the original 6 byte space was still
> there. dEd was also used to rename the directory entry to vim.  And I
> had been runing it that way for quite a few years.
>
> So neither vim, nor minted, can now save an edited startup file.  Any
> other file BUT startup, no problem.
>
> The "file exists" is minteds output as it does a error exit. So
> obviously there is something in the startup file than needs an
> ampersand as its end of line. Easy to say, impossible to do when you
> cannot even edit the file.
>
> The mb.floppy script tried to run, but errored out on the standard.bl
> (this is in the 3.3.0 subdir so it would have been all 3.3.0 stuff but
> with my HD descriptors, had it worked. But the standard.bl managed to
> gain 3 dots in front of the .../MODULES/SCF/w4.dw descripter, so it
> bailed out, leaving TemBoot. minted was able to fix that, but then the
> format crash was back no matter how many times I reset it, and I was
> so frustrated I hit the switch and went to bed.
>
> I need to drill another hole in the floor so I can bring the dw cable
> back up and use dw, which that boot has in it. I had to use that hole
> it was in, to get a cat5 to the milling machine in the garage. And
> with my back, thats not an easy job. A spade bit gets this shag rug
> wrapped around it, so the bit, if it can be pulled from the hole as
> the shag melts and sticks to the bit and the floor locking the bit
> into the partial hole, which has to be cleaned up quite a few times to
> finish the hole.  The holes is about 4" deep as it hits a floor joist.
> And I keep forgetting to bring in a contractors razer blade knife so I
> can remove a strip of that 40 yo rug just to get a clear spot to start
> a new, 3rd hole in the floor but straight down but 2 or 3" from the
> wall so I miss the joist.  For me and my crushed disks back, thats
> back breaking work these days.
>
> Sorry if I sound frustrated, but when every tool we have is being
> frustrated by such errors, its catching.  And until I can get that
> hole drilled, I've no way to get any better tools to the machine.
>
> But I'll see if I can get it done in the next few days.
>
> > Bill Pierce
> > "Charlie stole the handle, and the train it won't stop going, no way
> > to slow down!" - Ian Anderson - Jethro Tull
> >
> >
> >
> > My Music from the Tandy/Radio Shack Color Computer 2 & 3
> > https://sites.google.com/site/dabarnstudio/
> > Co-Contributor, Co-Editor for CocoPedia
> > http://www.cocopedia.com/wiki/index.php/Main_Page
> > Global Moderator for TRS-80/Tandy Color Computer Forums
> > http://www.tandycoco.com/forum/
> >
> > E-Mail: ooogalapasooo at aol.com
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Gene Heskett <gheskett at wdtv.com>
> > To: coco <coco at maltedmedia.com>
> > Sent: Mon, Feb 15, 2016 6:51 pm
> > Subject: Re: [Coco] format memory (was) Gotek floppy emulator
> >
> >  I cannot format a disk from a fresh reboot. I may hear the drive
> > step 2 to 4 times, but then it stops and I see flickering dashes in
> > the video, as its crashed.  And it quite often takes several taps on
> > the reset button if very quick cadence before it will again do a
> > cold boot.  Wash, rinse and repeat.  And my normal boot has at least
> > 11k of ram free, but for some reason, is not contiguous, but in 2
> > pieces. The gap I believe is the space between the end of the
> > bootfile in memory, and the beginning of the 8k block with shell &
> > some other utils to mostly fill an 8k block. The biggest piece has
> > more than enough room for the 6144 byte track buffer.I am half
> > tempted to go see if I can make format use only the bigger piece of
> > memory as  my vfy can easily modify that in the executables header. 
> > If I have any good luck, I'll report back.Cheers, Gene Heskett--

Good luck dept:

I can format one 35 track single sided floppy, most of the time, running 
format from the command line.

So, based on the subprocess theory using additional ram, I commented the 
format related stuff out of a mb.floppy command.

So I format a floppy, reboot, run mb.floppy, which then does the device 
name acquisition, and runs os9gen on it after creating bttemp for the 
track 34 write. I have looked at the floppy with dEd /d@, and the whole 
of track 34 contains the $e5 the format command left, the FAT bits are 
clear, but os9gen refuses to write track 34, claiming it already has 
data there. I have run the loop 5 times now, without os9gen actually 
writing a track 34.

I haven't done a cmp between the os9gen on the HD, vs the one in the 
3.3.0/6309l2 image currently being used as the src code.

Now, an even easier way to test this might be to incorporate a 
cx /x1/cmds at the top of the mb script, and a corresponding cx /dd/cmds 
at the bottom.  That way it would use the os9gen from the 3.3.0/6309l2 
image.dsk for the scripts execution time.

That build is dated April 6, 2015, so the question then is: do I need to 
run another git pull and refresh the build?

So that is the next thing I'll try once I've cleaned all the card edge 
connectors.

Not immediately however, as today is my lady's 76th & I need to pay some 
attention to her, and a tool I thought was not going to arrive until 
Saturday, was in the mailbox last night when I arrived back from Home 
Depot, so I can resume production of the trim bits for the blanket 
chests I am making, one for each of my surviving boys. ATM, both of 
those take precedence over coco stuff.

Thanks for reading this far.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>