[Coco] format memory (was) Gotek floppy emulator

[Gene Heskett]

On Thursday 18 February 2016 03:30:23 Tormod Volden wrote:

> On Thu, Feb 18, 2016 at 9:04 AM, Gene Heskett wrote:
> > 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
>
> Do you need the reboot in between?

Yes, something is leaking memory and in two or 3 other operations, smap 
reports I am down to 10k of sysram left so I have to reboot to get that 
last 1k back again.
>
> > 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.
>
> I think this is the root of your problem: It seems like you are not
> using a consistent 3.3.0 setup, but an amalgam of your own modules and
> commands, possibly very old and incompatible.

Likely, my cmds directory has several hundred older commands in it that 
are not in the release .dsk's cmds tree. But the core commands are the 
latest AFAIK.  And that is what counts when running an mb of any flavor.

> > 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.
>
> Can't you just invoke it with the full path? /x1/cmds/os9gen ...

6 of one, half a dozen of the other. By doing the cx, I automatically 
should get anything else, like merge, from the new image too.

> > That build is dated April 6, 2015, so the question then is: do I
> > need to run another git pull and refresh the build?
>
> Probably not needed. The problem can be that you are not always using
> the 3.3.0 binaries, but mixing in much older stuff.
>
> If you now have DriveWire working again, I would recommend doing a
> clean boot from DriveWire using DWDOS. This would eliminate issues
> with your own modules interferring.

That also brings up the need for me to run a script on that image, which 
updates the rbf file descriptors so I don't lose the contents of a pair 
of 1Gb seagate hawk scsi drives. It also does the current floppy 
descriptors for the same reason. That would not be required if we had a 
script that queries LSN0 on the selected drive, and writes a new 
descriptor based on what it can learn from the drive.  But we don't have 
one of those critters that I'm aware of, so my script simply saves the 
descriptor in memory when its run, to a new file in the modules/rbf 
subtree of the most recently built and dw mounted .dsk image.  And its 
that portion of the dw mounted .dsk that gets dsaved to the HD, where I 
run the mb's from, and that has been done.  The bootlist/file used is 
edited to use my descriptors.  Part of my SOP when I do a new git pull 
and build.

> Regards,
> Tormod


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>