#1018 SFD1001 directory problem (xpet, IEEE488)

[Andre Fachat]

Hi there,

I am trying to use the SFD1001 emulation with the xpet emulator. However, what I found is that the 1001 true drive emulation seems to broken, and does not load (DIR command) the director of an empty attached d82 image correctly

How to recreate:
1) newly installed vice 3.2, no "~/.vicerc"
2) start xpet, true drive emulation is on, drive type 8 is 1001
3) from the menu, create and attach a new empty d82 disk image
4) type "diR" - once with only the drive initializing, second "diR" with a broken directory

Initializing drive 0 (with an "I0" command) does not help. (see bar.png)

Switching the drive type 8 to 8250 and entering "diR" gives the correct directory (see bar2.png)

Switching the drive type 8 back to 1001 and entering "diR" gives the broken directory again (see bar3.png)

The empty d82 file reads fine with c1541:

c1541 -attach bar.d82 -dir
0 "vice " 01 2c
Empty image
4133 blocks free.

[Andre Fachat]

Comment: compiled with "configure; make; make install". It ended up using xaw UI, but that should - hopefully - not influence the shown problem.

[compyx]

Yup, totally screwed up. Also on Gtk3.

[compyx]

Using the standard PET model, DIR doesn't work, but load"$",8 works.
Does this still bug? After the VIA fixes?

[Andre Fachat]

I don't know what you mean by VIA fixes. It looks it's still on 3.2 here.

Anyway, DIR is a real test of the IEEE488 capabilities. It uses basically a "TALK/SECTALK/IECIN/UNTALK" sequence for IIRC almost every byte, while LOAD does only a single TALK/SECTALK at the start and an UNTALK at the end.

I just did a test again (with 3.2) and neither DIR nor LOAD"$",8 resulted in the expected outcome.

[gpz]

first thing to find out would be: did it ever work? iirc d82 never worked right

[compyx]

With current trunk this also barfs. diR just prints an empty line and READY. Using load"$",8:list results in garbage.
However when I use 8250 as the drive type, stuff works normally.

[Andre Fachat]

@gpz: I would be very surprised if I had left it in such a state before I left... ;-)
Anyway, just tested with vice-2.4 and there it worked.

[gpz]

i am never surprised about finding broken code that never worked in VICE :)

however, it would certainly help a lot if you could find out when exactly it broke then

[gpz]

r29062 broke this... should be fixed in r35440 - please test

[Andre Fachat]

How do I build the trunk? I checked it out, ran "autogen.sh; configure; make" and got a compile error:
Making all in hvsc
../src/arch/sdl/libarch.a(archdep.o): In function archdep_rename': /home/fachat/Documents/8bit/vice-emu-code/vice/src/arch/sdl/archdep_unix.c:684: multiple definition ofarchdep_rename'
../src/arch/shared/libarchdep.a(archdep_rename.o):/home/fachat/Documents/8bit/vice-emu-code/vice/src/arch/shared/archdep_rename.c:44: first defined here
collect2: error: ld returned 1 exit status
Makefile:1929: recipe for target 'vsid' failed

As a side note: wth the removal of kdesvn I am almost lost with plain cmdline svn. How do I checkout a revision? - And are you thinking about moving to git?

[compyx]

That build error is my mistake, I forgot to remove archdep_rename() from sdl/archdep_unix.c Should be fixed in r35442.

Building trunk works you like you did: run autogen.sh once, and then you can just do configure && make. To check out a specific revision use svn up -r <revision>, or add -r <revision> to the svn checkout command when doing the initial checkout.</revision>

[Andre Fachat]

I think it may be fixed, but to be honest, the new UI (SDL?) is clumsy and a long step back from the menu-approach used before (Xaw but I guess in others as well). Where are the drive LEDs and indicators? Can I assume that Gtk3 still has the menus? How do I build it then, my first appraoch failed...

[compyx]

You can build the Gtk3 UI by passing --enable-native-gtk3ui to configure. That one has proper menus and settings are handled via dialogs/"forms". In the SDL UI you can enable a statusbar to show drive "leds".

[gpz]

it should actually be enough to just install the gtk3-dev stuff :)

[Andre Fachat]

Hm, took a bit longer than expected, and was a bit more tedious than expected, but in the end just diligent but routine piece of work... Attached is a patch to r35442 to make each of the drive units capable of being dual drive without interfering with the others.
The only test I did (of course ;-) was doing the screenshots I attached as well.

Even if you don't use it, it may help you find more about some problems. For example I think a lot of attributes should go from drive_t to drive_context_t (I commented them in the patch).

(Note the ROM fix for the 4040 etc ist not yet included)

[Andre Fachat]

P.S.: screenshots done with "./src/xpet -drive8type 8250 -8 test1.d82 -8d1 test2.d82 -drive9type 8250 -9 test3.d82 -9d1 test4.d82 -drive10type 8250 -10 drv0.d82 -10d1 drv1.d82", create/attach form got an additional "drive" selector, but still segfaults unfortunately.

[compyx]

Did you use svn diff or plain diff? I see a lot of /home/fachat stuff in Makefile[.in] which I don't think should be there.

[Andre Fachat]

I did a normal "diff -urb vice+drives vice" command, after having cleaned both dirs using "make distclean". Which I now see does not clean up all the generated files.

Sorry, but after using git for years, I'm not used to svn anymore. I only did a "svn cp vice vice+drives" to create a new source tree locally, where I did my changes.

[gpz]

easier to just do "svn diff" in your modified sourcetree, imho :)

[Andre Fachat]

had to get back into svn.... Anyway, moved the discussion to a proper feature request (with updated patch): https://sourceforge.net/p/vice-emu/feature-requests/314/