Jump to content
IGNORED

SIO2PC with FTDI Friend from Adafruit


fadix

Recommended Posts

I am interested in making my own SIO2PC. I came across the FTDI Friend from Adafruit for $14.75.

 

Would that board work? I see the signal logic level is 3.3V by default, but I think the Atari SIO port is 5V.

 

If the logic levels are okay, then I should just be able to use jumper wire to connect the headers directly to pins on the SIO port, right?

Link to comment
Share on other sites

 

So it will only work with the SIO port if I change the setting to 5V. Something like this cable, though, would work without any modification of settings.

 

Thank you.

 

Well, it says this for the product you linked to above: "The version we have is the 3.3V. The data signals are at 3V and the power line provides 5V. We suggest this for any product that needs FTDI cables. Because the cable is 5V compliant, you can use it with 3v or 5v logic just fine - no level shifting required!."

 

This is an actual FTDI cable, but FTDI also has 5v version of it, we should ask why? if this one can be used in both 3.3 and 5v applications.why do they have a 5v version. I personally would take "compliant" claims with a grain of salt (just ask Candle about 5v "tolerant" devices :) ). If you decide to go with this cable I would suggest verifying the 5v operation with the vendor before you commit to it.

 

Better yet why not select something like this? You could use CTS handshaking line for SIO2PC and the DTR for 10502PC functionality and it is a 5v device.

Edited by atari8warez
  • Like 2
Link to comment
Share on other sites

Better yet why not select something like this? You could use CTS handshaking line for SIO2PC and the DTR for 10502PC functionality and it is a 5v device.

 

I went with what you linked. I tried to just get the SIO2PC functionality working. I am using AspeQt on Linux and when I try to load an .atr image, I just get a noise from the Atari and it takes a little longer to display the Memo Pad than usual. I initially tried CTS, but then I tried DTR. Both get the same response. I am using an Atari 400 and have tried multiple .atr images. I don't have any experience with Atari disk drives, so maybe I am missing something obvious. I am putting the .atr in D1 and using the correct /dev/tty device.

Link to comment
Share on other sites

 

I went with what you linked. I tried to just get the SIO2PC functionality working. I am using AspeQt on Linux and when I try to load an .atr image, I just get a noise from the Atari and it takes a little longer to display the Memo Pad than usual. I initially tried CTS, but then I tried DTR. Both get the same response. I am using an Atari 400 and have tried multiple .atr images. I don't have any experience with Atari disk drives, so maybe I am missing something obvious. I am putting the .atr in D1 and using the correct /dev/tty device.

 

Nope the DTR won't work, it is an output signal from the PC (DTR will be needed if you use ProSystem software to access an Atari drive), what you need here is a handshake line that is an input to the PC. AspeQt uses either DSR/CTS or RI for receiving Atari's SIO7 (Command) line signal. Your FTDI device exposes the CTS handshake line, so you need to go to the Tools/Options menu in AspeQt and change the handshake line to CTS, it normally defaults to DSR.

Edited by atari8warez
Link to comment
Share on other sites

 

Nope the DTR won't work, it is an output signal from the PC (DTR will be needed if you use ProSystem software to access an Atari drive), what you need here is a handshake line that is an input to the PC. AspeQt uses either DSR/CTS or RI for receiving Atari's SIO7 (Command) line signal. Your FTDI device exposes the CTS handshake line, so you need to go to the Tools/Options menu in AspeQt and change the handshake line to CTS, it normally defaults to DSR.

 

I did change it to CTS in the Tools/Options menu and got the result I described. If I put an .atr file as disk 1 will it load by itself, or do I need a separate DOS image?

Link to comment
Share on other sites

If you mount a bootable ATR image on drive slot 1, yes your Atari should boot from that drive so long as you don't also have a physical Atari drive connected in the SIO chain with drive ID D1: (if you have a physical and virtual drives with the same ID on the SIO chain they will both try to respond to SIO commands). If you have a physical drive in your SIO chain you must make sure that no disk image is mounted on the corresponding AspeQt drive slot.

 

Are you seeing any activity in the log window of AspeQt (the area under the drive slots where you see AspeQt messages). Can you post a screenshot of the log so I can see what's happening. Which SIO speed(s) are you using in AspeQt?

 

Also you may want to try this ATR, it is a DOS 2.5 boot disk:

 

DOS 2.5.atr

Edited by atari8warez
Link to comment
Share on other sites

If you mount a bootable ATR image on drive slot 1, yes your Atari should boot from that drive so long as you don't also have a physical Atari drive connected in the SIO chain with drive ID D1: (if you have a physical and virtual drives with the same ID on the SIO chain they will both try to respond to SIO commands). If you have a physical drive in your SIO chain you must make sure that no disk image is mounted on the corresponding AspeQt drive slot.

 

Are you seeing any activity in the log window of AspeQt (the area under the drive slots where you see AspeQt messages). Can you post a screenshot of the log so I can see what's happening. Which SIO speed(s) are you using in AspeQt?

 

Also you may want to try this ATR, it is a DOS 2.5 boot disk:

 

attachicon.gifDOS 2.5.atr

 

I get the following message in the log window using your DOS 2.5.atr and 19200 (1x) SIO speed.

 

 

Serial port speed set to 19200.

Emulation started through standard serial port backend on '/dev/ttyUSB0' with CTS handshaking.

[Disk 1] Mounted 'DOS 2.5.atr' as 'SD Diskette (90k)'.

I am still just getting memo pad with your atr.

Edit: Interestingly I just started playing Donkey Kong and the red and green LEDs on the FTDI basic are flashing rapidly. They have been doing so for the duration that the Donkey Kong cartridge is in the Atari.

Edited by fadix
Link to comment
Share on other sites

 

I get the following message in the log window using your DOS 2.5.atr and 19200 (1x) SIO speed.

 

 

Serial port speed set to 19200.

Emulation started through standard serial port backend on '/dev/ttyUSB0' with CTS handshaking.

[Disk 1] Mounted 'DOS 2.5.atr' as 'SD Diskette (90k)'.

I am still just getting memo pad with your atr.

 

 

I get the following message in the log window using your DOS 2.5.atr and 19200 (1x) SIO speed.

 

 

Serial port speed set to 19200.

Emulation started through standard serial port backend on '/dev/ttyUSB0' with CTS handshaking.

[Disk 1] Mounted 'DOS 2.5.atr' as 'SD Diskette (90k)'.

I am still just getting memo pad with your atr.

 

Looks like AspeQt is not receiving anything from the COM port. Did you double check your SIO cable and make sure correct wires are connected to the FTDI board? Do not count on the colors of the wires to determine which wire is which, use your multimeter and the below schematic to make sure right wires are connected. The schematic shows the view of the SIO port looking from behind the computer.

 

post-15627-0-85932400-1390692286_thumb.gif

 

SIO3 --> TXD

SIO5 --> RXD

SIO7 --> CTS

SIO4/6 -->GND

 

Also did you or can you test the COM port created by the FTDI breakout board using a terminal program to make sure that the COM port is working. You can do loopback tests by shorting TXD and RXD for data, or DSR and DTR for handshaking lines.

Edited by atari8warez
Link to comment
Share on other sites

 

 

Looks like AspeQt is not receiving anything from the COM port. Did you double check your SIO cable and make sure correct wires are connected to the FTDI board? Do not count on the colors of the wires to determine which wire is which, use your multimeter and the below schematic to make sure right wires are connected.

 

attachicon.gifsio.gif

 

SIO3 --> TXD

SIO5 --> RXD

SIO7 --> CTS

SIO4/6 -->GND

 

Also did you or can you test the COM port created by the FTDI breakout board using a terminal program to make sure that the COM port is working

 

I have the wires hooked up as you specify. Can you elaborate on how I would check that the COM port is working. /dev/ttyUSB0 is the only device that appears/disappears as I connect/disconnect the FTDI board.

 

Also you missed my edit to the last post, but when I played Donkey Kong, the red and green LEDs started flashing rapidly on the FTDI board. They are doing it for the duration that I have the donkey kong cartridge in.

Link to comment
Share on other sites

 

I have the wires hooked up as you specify. Can you elaborate on how I would check that the COM port is working. /dev/ttyUSB0 is the only device that appears/disappears as I connect/disconnect the FTDI board.

 

Also you missed my edit to the last post, but when I played Donkey Kong, the red and green LEDs started flashing rapidly on the FTDI board. They are doing it for the duration that I have the donkey kong cartridge in.

 

So you loaded Donkey Kong from the cartridge, does that game use disk drives? the leds on the FTDI breakout board should only be flashing when a game/software accesses the disk drive(s).

 

To do a loopback test you'll need a terminal emulator program like picocom.

Cross the RDX and TXD pins of the FTDI breakout board with a piece of wire, run the terminal emulator, open the COM port on /dev/ttyUSB0, type a few letters in the terminal emulator screen and you should see those letters echoed back to you. (make sure the term emulator itself does not echo characters back, there is usually an option when you open the COM port called half-duplex, don't use that)

 

To do a loopback test on the handshake pins, cross the CTS to DTR, in the terminal emulator find the option to "assert" the DTR line, when you do that you should see CTS asserted as well. if that happens your handshake lines are working too.

 

Here's a link where they discuss such a test

 

Sorry I am not a linux person and I am not familiar with that particular terminal emulator program, so my knowledge on these is limited.

Edited by atari8warez
Link to comment
Share on other sites

 

So you loaded Donkey Kong from the cartridge, does that game use disk drives? the leds on the FTDI breakout board should only be flashing when a game/software accesses the disk drive(s).

 

To do a loopback test you'll need a terminal emulator program like picocom.

Cross the RDX and TXD pins of the FTDI breakout board with a piece of wire, run the terminal emulator, open the COM port on /dev/ttyUSB0, type a few letters in the terminal emulator screen and you should see those letters echoed back to you. (make sure the term emulator itself does not echo characters back, there is usually an option when you open the COM port called half-duplex, don't use that)

 

To do a loopback test on the handshake pins, cross the CTS to DTR, in the terminal emulator find the option to "assert" the DTR line, when you do that you should see CTS asserted as well. if that happens your handshake lines are working too.

 

Here's a link where they discuss such a test

 

Sorry I am not a linux person and I am not familiar with that particular terminal emulator program, so my knowledge on these is limited.

 

I did the tests and the boards seems to be working.

 

Donkey Kong is a cartridge and as far as I know it doesn't load anything from disk, so I don't know why it was flashing the LEDs.

Link to comment
Share on other sites

 

I did the tests and the boards seems to be working.

 

Donkey Kong is a cartridge and as far as I know it doesn't load anything from disk, so I don't know why it was flashing the LEDs.

 

Do you have a multimeter (preferably a digital one)?, if you do, please do this test for me. When your 400 is ON, take a voltage measurement from your SIO port pins 4 and 7, the ground (black wired) probe of your multimeter touches the #4 pin while the positive (red wired) probe touches the pin #7. Make sure nothing else is connected to the SIO port including the FTDI breakout board. If you're getting a voltage reading under 3v then in all likelihood your PIA chip is defective, you should normally get 4.95 - 4.99v from a healthy SIO7 pin. Do the same test with SIO5 pin, you should get a voltage close to 5v on that pin too. If SIO5 is below 3v, then in all likelihood your POKEY chip is defective.

 

I have a 600XL that exhibited above anomalies and swapping the chips fixed the problems.

Edited by atari8warez
Link to comment
Share on other sites

 

Do you have a multimeter (preferably a digital one)?, if you do, please do this test for me. When your 400 is ON, take a voltage measurement from your SIO port pins 4 and 7, the ground (black wired) probe of your multimeter touches the #4 pin while the positive (red wired) probe touches the pin #7. Make sure nothing else is connected to the SIO port including the FTDI breakout board. If you're getting a voltage reading under 3v then in all likelihood your PIA chip is defective, you should normally get 4.95 - 4.99v from a healthy SIO7 pin. Do the same test with SIO5 pin, you should get a voltage close to 5v on that pin too. If SIO5 is below 3v, then in all likelihood your POKEY chip is defective.

 

I have a 600XL that exhibited above anomalies and swapping the chips fixed the problems.

 

I measured 5v with the multimeter on both pins. So I tried again to hook up the board and it seems to be partially working. I think it was just my wiring. Now I am able to boot certain disks, but others only partially load. The disk you attached is one that partially loads. The output I get when loading it is below. It seems to jump from 91 to the 300s. I am able to boot the cx85 master disk successfully, but not the secondary disk for the cx85.

 

 

[Disk 1] Get status.

[Disk 1] Read sector 1 (128 bytes).

[Disk 1] Read sector 2 (128 bytes).

[Disk 1] Read sector 3 (128 bytes).

[Disk 1] Read sector 4 (128 bytes).

[Disk 1] Read sector 5 (128 bytes).

[Disk 1] Read sector 6 (128 bytes).

[Disk 1] Read sector 7 (128 bytes).

[Disk 1] Read sector 8 (128 bytes).

[Disk 1] Read sector 9 (128 bytes).

[Disk 1] Read sector 10 (128 bytes).

[Disk 1] Read sector 11 (128 bytes).

[Disk 1] Read sector 12 (128 bytes).

[Disk 1] Read sector 13 (128 bytes).

[Disk 1] Read sector 14 (128 bytes).

[Disk 1] Read sector 15 (128 bytes).

[Disk 1] Read sector 16 (128 bytes).

[Disk 1] Read sector 17 (128 bytes).

[Disk 1] Read sector 18 (128 bytes).

[Disk 1] Read sector 19 (128 bytes).

[Disk 1] Read sector 20 (128 bytes).

[Disk 1] Read sector 21 (128 bytes).

[Disk 1] Read sector 22 (128 bytes).

[Disk 1] Read sector 23 (128 bytes).

[Disk 1] Read sector 24 (128 bytes).

[Disk 1] Read sector 25 (128 bytes).

[Disk 1] Read sector 26 (128 bytes).

[Disk 1] Read sector 27 (128 bytes).

[Disk 1] Read sector 28 (128 bytes).

[Disk 1] Read sector 29 (128 bytes).

[Disk 1] Read sector 30 (128 bytes).

[Disk 1] Read sector 31 (128 bytes).

[Disk 1] Read sector 32 (128 bytes).

[Disk 1] Read sector 33 (128 bytes).

[Disk 1] Read sector 34 (128 bytes).

[Disk 1] Read sector 35 (128 bytes).

[Disk 1] Read sector 36 (128 bytes).

[Disk 1] Read sector 37 (128 bytes).

[Disk 1] Read sector 38 (128 bytes).

[Disk 1] Read sector 39 (128 bytes).

[Disk 1] Read sector 40 (128 bytes).

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 83 (128 bytes).

[Disk 1] Read sector 84 (128 bytes).

[Disk 1] Read sector 85 (128 bytes).

[Disk 1] Read sector 86 (128 bytes).

[Disk 1] Read sector 87 (128 bytes).

[Disk 1] Read sector 88 (128 bytes).

[Disk 1] Read sector 89 (128 bytes).

[Disk 1] Read sector 90 (128 bytes).

[Disk 1] Read sector 91 (128 bytes).

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 41 (128 bytes).

[Disk 1] Read sector 42 (128 bytes).

[Disk 1] Read sector 43 (128 bytes).

[Disk 1] Read sector 44 (128 bytes).

[Disk 1] Read sector 45 (128 bytes).

[Disk 1] Read sector 46 (128 bytes).

[Disk 1] Read sector 47 (128 bytes).

[Disk 1] Read sector 48 (128 bytes).

[Disk 1] Read sector 49 (128 bytes).

[Disk 1] Read sector 50 (128 bytes).

[Disk 1] Read sector 51 (128 bytes).

[Disk 1] Read sector 52 (128 bytes).

[Disk 1] Read sector 53 (128 bytes).

[Disk 1] Read sector 54 (128 bytes).

[Disk 1] Read sector 55 (128 bytes).

[Disk 1] Read sector 56 (128 bytes).

[Disk 1] Read sector 57 (128 bytes).

[Disk 1] Read sector 58 (128 bytes).

[Disk 1] Read sector 59 (128 bytes).

[Disk 1] Read sector 60 (128 bytes).

[Disk 1] Read sector 61 (128 bytes).

[Disk 1] Read sector 62 (128 bytes).

[Disk 1] Read sector 63 (128 bytes).

[Disk 1] Read sector 64 (128 bytes).

[Disk 1] Read sector 65 (128 bytes).

[Disk 1] Read sector 66 (128 bytes).

[Disk 1] Read sector 67 (128 bytes).

[Disk 1] Read sector 68 (128 bytes).

[Disk 1] Read sector 69 (128 bytes).

[Disk 1] Read sector 70 (128 bytes).

[Disk 1] Read sector 71 (128 bytes).

[Disk 1] Read sector 72 (128 bytes).

[Disk 1] Read sector 73 (128 bytes).

[Disk 1] Read sector 74 (128 bytes).

[Disk 1] Read sector 75 (128 bytes).

[Disk 1] Read sector 76 (128 bytes).

[Disk 1] Read sector 77 (128 bytes).

[Disk 1] Read sector 78 (128 bytes).

[Disk 1] Read sector 79 (128 bytes).

[Disk 1] Read sector 80 (128 bytes).

[Disk 1] Read sector 81 (128 bytes).

[Disk 1] Read sector 82 (128 bytes).

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 362 (128 bytes).

Link to comment
Share on other sites

This is what I get when I turn my 65XE ON and boot with the same DOS 2.5 disk

 

Emulation stopped.

Serial port speed set to 19200.

Emulation started through standard serial port backend on 'COM4' with DSR handshaking

[Disk 1] Get status.

[Disk 1] Read sector 1 (128 bytes).

[Disk 1] Read sector 2 (128 bytes).

[Disk 1] Read sector 3 (128 bytes).

[Disk 1] Read sector 393 (128 bytes).

[Disk 1] Read sector 394 (128 bytes).

[Disk 1] Read sector 395 (128 bytes).

[Disk 1] Read sector 396 (128 bytes).

[Disk 1] Read sector 397 (128 bytes).

[Disk 1] Read sector 398 (128 bytes).

[Disk 1] Read sector 399 (128 bytes).

[Disk 1] Read sector 400 (128 bytes).

[Disk 1] Read sector 401 (128 bytes).

[Disk 1] Read sector 402 (128 bytes).

[Disk 1] Read sector 403 (128 bytes).

[Disk 1] Read sector 404 (128 bytes).

[Disk 1] Read sector 405 (128 bytes).

[Disk 1] Read sector 406 (128 bytes).

[Disk 1] Read sector 407 (128 bytes).

[Disk 1] Read sector 408 (128 bytes).

[Disk 1] Read sector 409 (128 bytes).

[Disk 1] Read sector 410 (128 bytes).

[Disk 1] Read sector 411 (128 bytes).

[Disk 1] Read sector 412 (128 bytes).

[Disk 1] Read sector 413 (128 bytes).

[Disk 1] Read sector 414 (128 bytes).

[Disk 1] Read sector 415 (128 bytes).

[Disk 1] Read sector 416 (128 bytes).

[Disk 1] Read sector 417 (128 bytes).

[Disk 1] Read sector 418 (128 bytes).

[Disk 1] Read sector 419 (128 bytes).

[Disk 1] Read sector 420 (128 bytes).

[Disk 1] Read sector 421 (128 bytes).

[Disk 1] Read sector 422 (128 bytes).

[Disk 1] Read sector 423 (128 bytes).

[Disk 1] Read sector 424 (128 bytes).

[Disk 1] Read sector 425 (128 bytes).

[Disk 1] Read sector 426 (128 bytes).

[Disk 1] Read sector 427 (128 bytes).

[Disk 1] Read sector 428 (128 bytes).

[Disk 1] Read sector 429 (128 bytes).

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 362 (128 bytes).

[Disk 1] Read sector 363 (128 bytes).

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 472 (128 bytes).

[Disk 1] Read sector 473 (128 bytes).

[Disk 1] Read sector 474 (128 bytes).

[Disk 1] Read sector 475 (128 bytes).

[Disk 1] Read sector 476 (128 bytes).

[Disk 1] Read sector 477 (128 bytes).

[Disk 1] Read sector 478 (128 bytes).

[Disk 1] Read sector 479 (128 bytes).

[Disk 1] Read sector 480 (128 bytes).

[Disk 1] Read sector 481 (128 bytes).

[Disk 1] Read sector 482 (128 bytes).

[Disk 1] Read sector 483 (128 bytes).

[Disk 1] Read sector 484 (128 bytes).

[Disk 1] Read sector 485 (128 bytes).

[Disk 1] Read sector 486 (128 bytes).

[Disk 1] Read sector 487 (128 bytes).

[Disk 1] Read sector 488 (128 bytes).

[Disk 1] Read sector 489 (128 bytes).

[Device $00] command: $00, aux: $0000 ignored.

[Device $4f] command: $40, aux: $4f4f ignored. [x28]

[Device $4f] command: $40, aux: $0000 ignored. [x28]

Here I am at the BASIC READY prompt and I type DOS to load the DOS menu

[Disk 1] Speed poll.

Serial port speed set to 57600.

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 362 (128 bytes).

[Disk 1] Read sector 363 (128 bytes).

[Disk 1] Read sector 361 (128 bytes).

[Disk 1] Read sector 430 (128 bytes).

[Disk 1] Read sector 431 (128 bytes).

[Disk 1] Read sector 432 (128 bytes).

[Disk 1] Read sector 433 (128 bytes).

[Disk 1] Read sector 434 (128 bytes).

[Disk 1] Read sector 435 (128 bytes).

[Disk 1] Read sector 436 (128 bytes).

[Disk 1] Read sector 437 (128 bytes).

[Disk 1] Read sector 438 (128 bytes).

[Disk 1] Read sector 439 (128 bytes).

[Disk 1] Read sector 440 (128 bytes).

[Disk 1] Read sector 441 (128 bytes).

[Disk 1] Read sector 442 (128 bytes).

[Disk 1] Read sector 443 (128 bytes).

[Disk 1] Read sector 444 (128 bytes).

[Disk 1] Read sector 445 (128 bytes).

[Disk 1] Read sector 446 (128 bytes).

[Disk 1] Read sector 447 (128 bytes).

[Disk 1] Read sector 448 (128 bytes).

[Disk 1] Read sector 449 (128 bytes).

[Disk 1] Read sector 450 (128 bytes).

[Disk 1] Read sector 451 (128 bytes).

[Disk 1] Read sector 452 (128 bytes).

[Disk 1] Read sector 453 (128 bytes).

[Disk 1] Read sector 454 (128 bytes).

[Disk 1] Read sector 455 (128 bytes).

[Disk 1] Read sector 456 (128 bytes).

[Disk 1] Read sector 457 (128 bytes).

[Disk 1] Read sector 458 (128 bytes).

[Disk 1] Read sector 459 (128 bytes).

[Disk 1] Read sector 460 (128 bytes).

[Disk 1] Read sector 461 (128 bytes).

[Disk 1] Read sector 462 (128 bytes).

[Disk 1] Read sector 463 (128 bytes).

[Disk 1] Read sector 464 (128 bytes).

[Disk 1] Read sector 465 (128 bytes).

[Disk 1] Read sector 466 (128 bytes).

[Disk 1] Read sector 467 (128 bytes).

[Disk 1] Read sector 468 (128 bytes).

[Disk 1] Read sector 469 (128 bytes).

[Disk 1] Read sector 470 (128 bytes).

[Disk 1] Read sector 471 (128 bytes).

So the disk is fine and works here, all I could say at this point double and triple check your cable connections.

I am sometimes surprised when people say ready made SIO2PC's are too expensive, but lot of work goes into one that is made professionally and properly enclosed and they work right out of the box :)

Edited by atari8warez
Link to comment
Share on other sites

Sorry to get to this so late...

 

I found a small bug in the Linux version that causes it to be very unreliable to the point of not really working.. It's a one line fix... I'll boot up my Linux system in a bit and find it..

 

Can you compile your own if I send the change, or would you like the binary?

Link to comment
Share on other sites

Sorry to get to this so late...

 

I found a small bug in the Linux version that causes it to be very unreliable to the point of not really working.. It's a one line fix... I'll boot up my Linux system in a bit and find it..

 

Can you compile your own if I send the change, or would you like the binary?

 

I can compile my own. That would be great if you can send me it.

Link to comment
Share on other sites

Crappy.. I don't have the original file so I can't show a diff.. Here's the code I have now:

 

in serialport-unix.cpp, starting at line 258

do {
        data.clear();
        /* First, wait until command line goes off */
        do {
            if (ioctl(mHandle, TIOCMGET, &status) < 0) {
                qCritical() << "!e" << tr("Cannot retrieve serial port status: %1").arg(lastErrorMessage());
                return data;
            }
            if (status & mask) {
                QThread::yieldCurrentThread();
            }
        } while ((status & mask) && !mCanceled);
        /* Now wait for it to go on again */
        if (tcflush(mHandle, TCIFLUSH) != 0) {
            qCritical() << "!e" << tr("Cannot clear serial port read buffer: %1")
                           .arg(lastErrorMessage());
            return data;
        }

        do {
            if (ioctl(mHandle, TIOCMGET, &status) < 0) {
                qCritical() << "!e" << tr("Cannot retrieve serial port status: %1").arg(lastErrorMessage());
                return data;
            }
            if (!(status & mask)) {
                QThread::yieldCurrentThread();
            }
        } while (!(status & mask) && !mCanceled);

        if (mCanceled) {
            return data;
        }

Basically, the part that flushes the receive buffer used to be at the end of this block and I moved it to the middle..

 

Clearing the buffer after the COMMAND line has asserted usually causes it to lose a byte or two, so I clear it before...

Edited by MrMartian
Link to comment
Share on other sites

Crappy.. I don't have the original file so I can't show a diff.. Here's the code I have now:

 

in serialport-unix.cpp, starting at line 258

do {
        data.clear();
        /* First, wait until command line goes off */
        do {
            if (ioctl(mHandle, TIOCMGET, &status) < 0) {
                qCritical() << "!e" << tr("Cannot retrieve serial port status: %1").arg(lastErrorMessage());
                return data;
            }
            if (status & mask) {
                QThread::yieldCurrentThread();
            }
        } while ((status & mask) && !mCanceled);
        /* Now wait for it to go on again */
        if (tcflush(mHandle, TCIFLUSH) != 0) {
            qCritical() << "!e" << tr("Cannot clear serial port read buffer: %1")
                           .arg(lastErrorMessage());
            return data;
        }

        do {
            if (ioctl(mHandle, TIOCMGET, &status) < 0) {
                qCritical() << "!e" << tr("Cannot retrieve serial port status: %1").arg(lastErrorMessage());
                return data;
            }
            if (!(status & mask)) {
                QThread::yieldCurrentThread();
            }
        } while (!(status & mask) && !mCanceled);

        if (mCanceled) {
            return data;
        }

Basically, the part that flushes the receive buffer used to be at the end of this block and I moved it to the middle..

 

Clearing the buffer after the COMMAND line has asserted usually causes it to lose a byte or two, so I clear it before...

 

That seems to have helped. Now all the DOS .atr files I try to load work, but not most other files. I tend to get the attached screen.

m0BUCi0.jpg

Link to comment
Share on other sites

 

Am I able to attach the file directly via the forum, or do I have to link to it? I can't figure out how to do the former.

 

If, when you reply to a post, you hit the "More reply options" button at the bottom right, then you should get the full post editor with the ability to attach a file.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...