[Coco] format memory (was) Gotek floppy emulator

[Tormod Volden]

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?

> 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.

>
> 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 ...

>
> 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.

Regards,
Tormod