XFER unable to send SSD images - fixed

[Kazzie]

I appear to have a similar problem that has plagued a number of individuals in the past:

• Hw to get ROM files to floppy?
• XFER problems when sending .SSD
• Xfer question

The common problem is that when attempting to write a SSD file to a floppy disk, the operation fails. Having started transfer, there is a short wait (for transmission of the data), then the floppy drive spins up for half a second, and shortly afterward XFER reports (on the PC):

Written 1 tracks of 80
Problem retrieving CRC for disk 1 track 0 from BBC

What I've tried so far:
Using a Thinkpad X61s's serial port (known good), under Windows XP and Slackware 14.2, I've built and re-built serial cables according to the two pinouts given in XFER 5.3a's sercable.txt (for DSR/DTS and RTS/CTS handsaking). I've tried two known good floppy drives, one 40T SSDD and one 40/80T DSDD. I've tried telling XFER to run at only 1200 baud instead of 9600, too.

I am able to transfer the BASIC file to the BBC with no problem. I can get a SSD image from a floppy disk, and can also read individual files from a floppy, or write them back to another floppy. But sending an SSD fails (whether the destination disk is formatted or not).

Using an old version of XFER 4 I found online, I was able to receive files, send files, but getting a disk image failed. XFER 4 didn't support writing disk images to the BBC, so I couldn't test that.

(I've not been able to send any files that didn't originate from the BBC in the first place, but I suspect that this is because I haven't got a $.XXXX.INF file with the appropriate metadata.)

Does anyone have any suggestions on why writing an SSD should fail, when everything else (on XFER 5.3a) works fine?

[Kazzie]

Some other details I should have included:

I'm using an 8271 and DFS 1.20.

Xfer 5.1 also fails to write an SSD track.

A notable detail is that Xfer doesn't over-write track 0 as it tries (and fails) to write to it. (i.e. If I attempt to write an SSD file to a formatted disk, it still catalogs fine after Xfer fails to write the SSD to it.)

[MartinB]

Does anyone have any suggestions on why writing an SSD should fail.....

Simple. It's because you're not using UPURS.....

[CMcDougall]

^yip, saves 15 mins a 80T DSD

Had no problems at all with this, made up a cable with the info in the .TXT file, used a 5 pin din & a hacksaw, blueTak to make the beeb end plug.

I was using my original beeb with 1770FDC DFS2.26 & a old Toshiba P3 laptop with winXP

All my discs where 80T DSD, never tried a 40T or SSD....

[flaxcottage]

OmniFlop also works. It will write 40T/80T in SSD/DSD flavours, ADFS format as M/L size and also Archimedes format discs. You will need a real floppy driver on the mobo and run XP or before on the PC.

I use it all the time. It is brilliant.

[Kazzie]

Does anyone have any suggestions on why writing an SSD should fail.....

Simple. It's because you're not using UPURS.....

Naturally.

OmniFlop also works. It will write 40T/80T in SSD/DSD flavours, ADFS format as M/L size and also Archimedes format discs. You will need a real floppy driver on the mobo and run XP or before on the PC.

I use it all the time. It is brilliant.

I was also using Omniflop at first, but something on my old Win9x desktop machine's motherboard gave up the ghost, and it's no longer able to boot. So I've not got another proper floppy drive controller available at the moment. So I've gone old-style serial for the time being.

Digging into the Xfer (5.1) code, I see something odd in the assembly subroutine .writeDFStrack (which is called by PROcwriteDFStrack):

Code: Select all

8370\ Receive a DFS track and write to disc
 8380.writeDFStrack%
 8390LDA #10
 8400STA buflen%
 8410JSR rcvtrack%
 8420\ Seek track
 8430LDA #1
 8440STA pblock%+5
 8450LDA #&29
 8460STA pblock%+6
 8470LDX #pblock% MOD 256
 8480LDY #pblock% DIV 256
 8490LDA #&7F
 8500JSR osword%
 8510LDA pblock%+8
 8520BNE write1
 8530LDA #3
 8540STA pblock%+5
 8550LDA #&4B:\ write multiple sectors
 8560STA pblock%+6
 8570LDA #0
 8580STA pblock%+8
 8590LDA #&2A
 8600STA pblock%+9
 8610LDX #pblock% MOD 256
 8620LDY #pblock% DIV 256
 8630LDA #&7F
 8640JSR osword%
 8650LDA pblock%+10
 8660.write1
 8670STA pblock%
 8680RTS

The code seeks to the appropriate track, and then writes the relevant sectors, using OSWORD &7F. But if the seek operation returns a non-zero error at pblock%+8, the write is skipped (@ line 8520).

The 8271 command to be issued is stored in location pblock%+6 before calling OSWORD &7F. The command number used is &29, but I don't see that listed among the OSWORD &7F commands. &69, on the other hand, is listed as "seek".

Is the code issuing a non-existent command, and on seeing an error (&FE) returned, skipping the write operation and throwing errors back in the PC's direction? I'll boot up the Beeb when I get a chance later today and see if changing the command number improves things.

[Kazzie]

That's fixed it.

Changing line 8450 of XFER.BAS to read:

Code: Select all

 8450LDA #&69

instead of LDA #&29 means that my Beeb now writes a full 80 tracks of a SSD to floppy disk.

I've attached a copy of Xfer 5.1a with the correction made. I've also made a pull request for the 5.1 version hosted on github by Robert Hargreaves.

The same error exists in the source code for Xfer 5.3a. I can see it in the /src/ folder, but I can't identify where it lies in crunched version in the /bin/ folders, so no quick fix without recompiling. Am I correct in thinking that Greg Cook (regregex) is the current maintainer of 5.3a?

[Kazzie]

A further detail:

I've found that having the Acornsoft Graphics Extension ROM plugged in stops XFER 5.1 from running correctly. The reason is that with the GXR's resources loaded into RAM, there is not enough available RAM for XFER to run.

The symptoms are that, when running XFER on the BBC (Model B), it will crash out with an error such as No room at line 6630 (with 68B54 and Econet fitted) or No room at line 5290 (with the 68B54 removed). PAGE is reported on my machine as 7680 with the GXR and 68B54 fitted, or 7168 with only the GXR fitted.

Having removed the GXR, XFER runs successfully, with or without the 68B54 present. (PAGE is then 6912 or 6400).

XFER 5.3, with it's smaller, crunched BASIC program, might not be affected, as the smaller BASIC program will leave more RAM available for use by the program. But check XFER 5.3 may still have the bug described above.

[dv8]

I've found that having the Acornsoft Graphics Extension ROM plugged in stops XFER 5.1 from running correctly. The reason is that with the GXR's resources loaded into RAM, there is not enough available RAM for XFER to run.

The GXR can be disabled (and the workspace reclaimed) by issuing the command *NOGXR

It will also default to the disabled state if the ROM is placed in an even numbered slot. It can then be enabled with the command *GXR

[regregex]

The same error exists in the source code for Xfer 5.3a. I can see it in the /src/ folder, but I can't identify where it lies in crunched version in the /bin/ folders, so no quick fix without recompiling. Am I correct in thinking that Greg Cook (regregex) is the current maintainer of 5.3a?

Hi there, just saw your post and will fix and update Xfer shortly.
Greg

[Kazzie]

The same error exists in the source code for Xfer 5.3a. I can see it in the /src/ folder, but I can't identify where it lies in crunched version in the /bin/ folders, so no quick fix without recompiling. Am I correct in thinking that Greg Cook (regregex) is the current maintainer of 5.3a?

Hi there, just saw your post and will fix and update Xfer shortly.
Greg

Excellent, thanks for letting me know.

[jimmy]

I'd like to say thanks to Kazzie for spotting that bug - I never would've found the solution. I can now run "Bad Apple" on real hardware!

The only other thing I had to do was select RTS/CTS mode by default - otherwise I could receive but not respond. I made a serial cable using Sprow's pin-out details.

I see Xfer 5.3b has now been released.