Jump to content

HiassofT

Members
  • Content Count

    1,164
  • Joined

  • Last visited

  • Days Won

    1

HiassofT last won the day on November 10 2011

HiassofT had the most liked content!

Community Reputation

630 Excellent

About HiassofT

  • Rank
    Stargunner

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Salzburg, Austria

Recent Profile Visitors

21,138 profile views
  1. Ah, I had a vague impression there was more to it than just that one thread but both my memory and my search-foo failed me - thanks for refreshing my memory! so long, Hias
  2. Just installed wine on my laptop and noticed com1-com4 are symlinked to /dev/ttyS0-3 by default. so ~/.wine/dosdevices/com5 (or some other number that's not already used) may be a better choice. Not sure why RespeQt won't work (can't test here ATM) so long, Hias
  3. OK, your groups are right and I was wrong - missed the wine part (sorry). Haven't used wine with serial ports in ages but I think this might do the trick: ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1 That should make the port available as COM1: in windows applications. so long, Hias
  4. Yes, it's /dev/ttyUSB0 and, also yes, most likely it's a permission thing (probably your user is not in the right groups). please run this and post the output ls -l /dev/ttyUSB0 groups so long, Hias
  5. Tricky 🙂 Synchronous mode rang a bell, candle had a look at it some time ago - see this thread The major problem though isn't async vs sync mode but coping with the CPU, ANTIC cycle stealing and OS NMI limitations so it'll work reliable in normal use case scenarios. POKEY really is a bitch (no FIFO, requiring manual acknowledgement of received bytes via IRQEN etc) and I'm not sure it's possible to get faster transfers working with full error checking (overrun, timeout, framing errors) than I implemented in my highspeed SIO code. With ANTIC DMA and NMI turned off and framing/overrun error checking removed faster speeds should be possible, but that's a bit of a niche use case. I still haven't found time to look into that (TBH it wasn't too high priority to me either), so if someone wants to have a go at that I'd be interested to read/hear about that! so long, Hias
  6. Looks like printers/atari1029.cpp is simply missing an #include <assert.h> at the beginning. BTW: tags between r4 and r5.2 are missing in the repo. @atarixle with tags present you could do a git bisect (see "git help bisect"), eg "git bisect start r5.2 r5.1", then compile and enter "git bisect good" or "git bisect bad", depending on the test results. Instead of the r5.x tags you could also use commit hashes, but we'd need to know which hash was r5.1 so long, Hias
  7. Yes, that could work. Easiest way would be to sample the clock line as there should be a square wave. Sampling the data line is a lot trickier as you only know that there should be 5 bytes in the command frame but can't make too many assumptions about the actual data. Modems back in the 1980ies/90ies used a similar approach to determine the baud rate, parity etc in command mode, but as all commands had to start with "AT" it was a lot easier to implement as they knew what the bit pattern should look like. If the UART baud rate selection is fine grained enough to use an eg ~125500 rate for divisor 0 then that's in general good enough to provide reliable operation (both in RX/TX direction and both on PAL/NTSC computers). SIO2PC implementations have been using that successfully for quite a while. If you have the possibility to stretch the start bit when transmitting to the Atari it's even better. so long, Hias
  8. For SIO devices it's best to target PAL rates, as NTSC rates are higher and that doesn't play nice with late POKEY sampling. In theory you'd have max +/-5% tolerance for serial communication (that's +/-50% bit time at the tenth bit, the stop bit), rule of thumb is to target +/-3% so you have a bit of margin for slow edges and clock skew and jitter (yeah, the latter was a problem with two of the lotharek SIO2PC USB interfaces, 125000bit/sec was unreliable due to large clock jitter the dual SIO2PC/1050-2-PC ones were fine). Compensating for only 3 of the clock cycles, targeting PAL, left enough headroom for NTSC as well as receiving from POKEY. Another approach would be to stretch the start bit by about 7 Atari cycles when transmitting and use the exact PAL or NTSC rate (or something between) - then there's enough margin so the rate isn't too critical. so long, Hias
  9. At the lower divisors (at least 0-2, better 0-3 or 0-4) you have to set the baudrate a bit lower to compensate for late pokey sampling (details are in README of my highspeed SIO patch). Targeting a byte time of 3 Atari cycles more than what the formula gives works fine. See eg my AtariSIO implementation: https://github.com/HiassofT/AtariSIO/blob/master/tools/UserspaceSIOWrapper.cpp#L1148-L1168 so long, Hias
  10. Yes, using a USB-serial adapter with a standard DB9 connector should work fine. In general I recommend getting a USB-serial adapter with the FTDI FT232 chip - these are well supported and usually have all the necessary control lines connected on the DB9 RS232 port. Some time ago I tested with an (IIRC Digitus branded) adapter and my homebrew serial SIO2PC cable connected to a RPi and it worked just fine. so long, Hias
  11. A quick grep through the Altirra source code turned up that SIO2SD uses device id $72 as well. These additional device IDs are mainly used for device configuration (eg selecting drive mapping, navigating through the directory tree on the SD card, setting highspeed baudrate etc) and using a fixed device ID for that (compared to adding commands to eg the $3x disk drives) makes a lot of sense: this device ID will always be present on the SIO bus if a SIO2SD, SDrive, ... is connected (even if no actual drives are currently enabled) and there's no chance the additional commands added to eg $3x disk drives could interfere with existing software trying to check for or use some proprietary (Happy, Speedy, ...) command and/or highspeed SIO protocol (XF551 and Happy Warp are inidicated by bits 7 and 5 set in the command). So the command space of disk drives is already quite cluttered and it's not easy to find an empty spot there. I'm pretty sure several other device IDs will be used by existing hardware (or PBI devices or SIO emulators). For example I use $61 ("a") in AtariSIO for the remote control interface - it can be disabled though if it causes problems. Ah and PCLink uses $6F. IIRC IDEPlus and SIDE U1MB BIOS use $20, $Bx and $A0. @flashjazzcat should know more about that. Not sure if some devices use the other lower number IDs ($00-$2F) plus you can also look into using some of the higher ones ($80-$9F, $C0-$FF). so long, Hias
  12. Those XF551 checks (with DSTATS=0) usually ignore the SIO error status, it's a simple "fire and forget" command to work around the XF551 firmware quirks. So don't worry too much about that. Just checked my MyPicoDos code and in getdens.src I set DBYTLO/HI and DSTATS to 0, start the SIO call and then wait 20 frames (time enough for 512 bytes at 19k2) for the the sector data to be transmitted before proceeding. I think it should be perfectly fine to implement some simple strict checking, eg check if DBYT matches the sector/status/percom length and if DSTATS is set right ($80 or $00 doesn't make much sense for "read" as does $40 or $80 for "write" commands) and if the parameters are odd return eg a $90 error. I'd say it's also probably not worth spending too much time and thoughts about the actual error code numbers. most of the code out there doesn't use the error status for much more than at maximum some error text printout on the screen. so long, Hias
  13. Well, with DSTATS=0 you should simply ignore what's in DBYT (and DBUF) as there's no data to transmit 🙂 Not 100% sure what'll happen with DSTAT set to $40 or $80 and DBYT set to 0 - could well be that SIO expects a checksum for the zero-bytes block or goes completely crazy so long, Hias
  14. That's not correct. For (serial) SIO communication DBYT determines the number of bytes to receive. After that SIO will receive the checksum byte and compare it to the calculated checksum. So if you set DBYTLO/HI too short you'll mostly get a checksum error (chances are 255:1) or if you set it too long you'll get a timeout. The important thing is that SIO will never trample on memory beyond what you set in DBYT, if some PBI devices don't check DBYT and return an error if it doesn't match the phyiscal sector size their firmware is broken and needs fixing (it's a really simple check that doesn't cost much). BTW: it's also perfectly vaild to issue a read sector command with DSTAT set to 0 (meaning an immediate SIO command), then SIO won't need a buffer at all. You can use that eg to read sector 4 to work around the XF551 density detection problems and then just wait a bit - this way you won't run into a checksum error (if you set DBYT to 128 and XF551 sends 256 bytes), and then have to wait a bit to recover or run into the SIO timeout (if you set DBYT to 256 but XF551 sends 128 bytes). so long, Hias
  15. I think RespeQt and other current SIO2PC software versions should be fine. But I'm not 100% sure, it's been too long since I looked into it. Pretty sure original SIO2PC versions for DOS had issues and ISTR I also noticed that issue with some (early?) SDrive or SIO2SD version. so long, Hias
×
×
  • Create New...