|Re: [hatari-devel] Bug report: AHCC not working anymore with GEMDOS emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On lauantai 18 helmikuu 2012, Eero Tamminen wrote:
> On sunnuntai 12 helmikuu 2012, Matthias Arndt wrote:
> > I tried this and attached the trace output. I assume as soon as the VDI
> > calls start coming up again, the crash is already over.
> > Trace output is attached.
> I've found a program (ICDraw, shareware i.e. freely distributable)
> using "?" wildcard which doesn't work with GEMDOS emu, but works with
> HD image.
> Your trace didn't show "?" usage, but maybe I'll find something
> that may fix your case too.
This was a red herring.
This particular program says that it doesn't find the file if file is write
protected. It doesn't even try to open it (with which Hatari would give
a warning), if the attributes in DTA set by Fsfirst()/Fsnext() don't match
what it's asking for...
First it searches for files with 0x20 (file to be written and closed)
attribute and then for files with 0x0 (normal read/write file) attribute.
But my read-only files returned attribute 0x01.
PS. By having e.g. C: on ACSI image and D: GEMDOS HD emulation:
atari-hd-image 8 8mb-disk.img TEST icondraw/
cd test.hd; ln -s ../icondraw D; cd ..
hatari --trace gemdos --machine falcon --tos etos512k.img -d icondraw/
I can have gemdos tracing both for HD image and for HD GEMDOS emulation.
In case of HD GEMDOS emulation the trace output has one extra Fsnext()
call because Hatari's Fsfirst() internally calls Fsnext(). That got
me a confused at first...