Not functioning for me

[snhirsch]

Hi, After several years away from my SuperPET, I finally diagnosed and repaired my PetSD and tried to get it working with the latest code on master. Not cooperating at all, but I'm unsure why. Here's the log file:

fsser.log

What exactly is it complaining about? I have used this exact format for specifying disk image providers with prior versions of the code.

[fachat]

I think we have changed the format of the assign, resp. made it more intelligent finding file types and disk images. So IIRC the "di" provider is gone, you just specify a disk image on the file system. Can you try "-A0:=os9.d64 -A1:=Waterloo2-Language-1.d64"? "A0:=..." is the short form for "A0:fs=...", but the filesystem provider now detects disk images and uses them.

Also, I am not sure in what state the master currently is. It should be fine, but if you run into problems, can you try out the "direntry" branch? You need to flash a new firmware though, as the wireformat communication protocol has changed (don't forget to re-flash when you go back to the master)

[snhirsch]

Thanks for fast response! That form does not work, but 'An:fs=..' does. I tried mounting one of the SuperPET Waterloo tools disks on 0 and the OS9 boot image on 1. Unfortunately the OS9 boot fails. It's supposed to run OS9.PRG, when invoked as 'disk/1.os9', but it cannot find the file.

fsser.log

I'll try the direntry branch next. I have tried going back to the last known working version from Aug 2013, but it will not build on current systems.

[snhirsch]

After wasting hours trying to understand why 'direntry' branch failed so miserably I discovered that the pcserver binary had been renamed and I was still trying to run fsser from the master branch :-(. Having now run the correct application I'm pleased to say things are working better. However, I/O is glacially slow - probably due to the intense amount of logging. Can you give me some advice on how to turn this off?

UPDATE: I forced off the terminal log messages, but throughput is still 10-20x slower than usual. On the PetSD the green LED is on almost solid, but the yellow LED (data transfer from PC) flickers only once every 2-3 seconds. It's wasting an enormous amount of time doing .... something, but I'm not sure what.

[fachat]

If, in firmware/bus.c you change the

#define DEBUG_BUS

to

#undef DEBUG_BUS

it should be much faster. Edit: don't forget to build & flash the firmware after that.

[snhirsch]

Thanks! I'll try that. I'm seeing problems when writing to disk under OS9. There's a seemingly endless stream of console messages about "WRITE(eof)..." and copies of even small files don't seem to complete. What settings should I use to get a better trace of this?

[fachat]

Does the PetSD use 75160/75160 IEEE drivers? What I noticed on the xs1541, if I use too long cables, I actually have to add another drive to the IEEE bus and switch it on to make transfer reliable - even if I don't use the drive (e.g. an SFD1001 switched to unit 9).

[snhirsch]

Yes, those are the bus transceivers used in PetSD as well. I have it on the end of a 6-ft. IEEE cable. I'll try daisy-chaining another drive and see if that helps.

[snhirsch]

Introducing another drive didn't help. I'm seeing an error on the xdserver log when I attempt a write operation from OS9. The target volume is also corrupted afterwards. What level of debug should I enable on both firmware and xdserver to best help diagnose this? Can I use the PetSD to sniff IEEE interaction between the PET and 4040 disk drive? If so, I can capture a successful write operation. Would really like to get XD2031 working completely for OS9.

[fachat]

Can you try branch https://github.com/fachat/XD2031/tree/172-os9 and also run the test program "dumprom3" (it's a tokenized BASIC, you can see it with petcat) on the standard PET BASIC and send me the resulting file?

[snhirsch]

Hi. That branch code doesn't work any better than the 'direntry' branch. I can boot OS-9, but any attempt at writing to the OS-9 volumes (REL files) fails and corrupts the volume. Attached is the ROM image, which does not look right to me. rom.zip

[fachat]

The ROM image produced by the file is not a direct image, but to help me understand issues with repeated LISTEN/SECLISTEN/.../UNLISTEN code (as a PRINT# from BASIC creates). At least the your output confirms that you don't have the same problem that I have with my hardware it seems.

REL files are a whole different matter. I will have to check how to best capture the REL file disk commands that are issued. Does VICE emulate the 6809 good enough for OS-9? Looks like it does http://mikenaberezny.com/hardware/superpet/super-os9-mmu/ So I'll see if I can fix my (ancient) VICE patch to capture IEEE488 traces to the current version of VICE and see what happens.

Can you tell me more what to do exactly (like each action or command you enter) and how I would identify the problem then afterwards?

[snhirsch]

I sent you files and information privately a few weeks back. Just curious if you've had a chance to bring up OS-9 on VICE?

[fachat]

I've adapted my patch to collect IEEE488 dumps to vice 3.4 and was indeed able to take a trace from a working VICE running OS-9. The next step will be to trim it down and make a real test case for XD2031 to how/where it breaks

[snhirsch]

Excellent! Let me know if there's anything I can do to help?

On Wed, Jul 1, 2020 at 5:03 PM A. Fachat notifications@github.com wrote:

I've adapted my patch to collect IEEE488 dumps to vice 3.4 and was indeed able to take a trace from a working VICE running OS-9. The next step will be to trim it down and make a real test case for XD2031 to how/where it breaks

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fachat/XD2031/issues/172#issuecomment-652645602, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY5SUMWRY4PDA346VOSTD3RZOQD3ANCNFSM4MXKVWMQ .

[fachat]

@snhirsch can you try the current HEAD on branch 172-os9?

[snhirsch]

I'm going to cautiously say you nailed it, but need to do a lot more testing. I am now able to copy files between disks and directories without error and the target files appear to operate correctly. What was the magic ingredient that made it start cooperating?

I'll pound on it as much as possible and let you know how it goes. Thanks for the great work!

[fachat]

There were two problems: 1st the OS-9 re-opens files (with the same secondary address), esp. REL files, without closing the associated files (secondary address) in the drive. That wasn't implemented yet. 2nd there was an optimization in the firmware that did not set the buffer read/write pointer correctly. Those two cases are represented in the "os9tests" suite of test cases now.

[snhirsch]

Will this be merged to master in the near future? Also, any chance of driving these fixes back into PetSD? I know that's not your project, but perhaps if you could isolate the diffs and forward them to whoever took over from Nils?

[fachat]

closed in current development stream, that will be merged into master at some point in time