Jump to content

HiassofT

Members
  • Content Count

    1,155
  • Joined

  • Last visited

  • Days Won

    1

HiassofT last won the day on November 10 2011

HiassofT had the most liked content!

Community Reputation

621 Excellent

About HiassofT

  • Rank
    Stargunner

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Salzburg, Austria

Recent Profile Visitors

21,083 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Another thing to keep in mind is that several SIO emulators, SIO2xx and PBI hard drive devices don't actually blank the (ATR) image space on a format command. Personally I consider such behavior a bug (as it's differing from what standard floppy drives on the Atari do) but if you have one of these devices you might need to enable "empty sector writes" in case you're not 100% sure the image space was really blank. so long, Hias
  8. No. As the Indus needs quite a bit of code uploaded to the drive to get synchromesh working I never added it. Squeezing in support for the protocol might be possible but there's not enough memory left to add the drive code and Indus detection / drive upload code. There's a patched indus drive ROM which adds support for happy ultra speed, it's best to use just that, it should work with the highspeed code out of the box. so long, Hias
  9. Well, there are both variants - some protocols (eg XF551) transmit the command in standard speed, some others (eg Happy / Speedy) in highspeed. As the command frame contains a checksum, which will very likely be not matching if the device is receiving at the wrong speed it's not too bad (yeah, there are some pitfalls still). Yes and no. Some protocols (eg 1050 Turbo) are really simple to implement, the driver just hooks into the OS IRQ handler and changes speed to high when the command frame is sent. Happy eg is quite simple, too, as everything is sent in high speed. But that doesn't work easily with the OS SIO code, a highspeed driver has to implement the whole SIO protocol. If you want to use the fastest possible rate it gets very tricky. Using IRQs no longer works as they take too long. Even with polling code it's nasty as the OS VBI can mess up timing. With a standard graphics 0 screen there's not too many CPU cycles left. It's possible to do but it took me a while until I got that working. If you are interested check out the README.txt and the source code of my highspeed SIO patch, most of the important stuff should be in there https://www.horus.com/~hias/atari/#hipatch so long, Hias
  10. Hard to say, I'd guess that should work fine, too. SIO devices will then need to pull down harder though. If you clip off the caps there's in general no need though for any additional pull-up. That may help a bit in some extreme cases, usually you should be fine with just the caps removed. so long, Hias
  11. The Speedy has ROM checksums, but it's easy to correct them. I wrote a tool to do that a couple years ago, it's in the Mega Speedy software ZIP https://www.horus.com/~hias/megaspeedy/software/megaspeedy-software-V1.10-20170923.zip in src/romcsum (both C source code and a Win32 exe) - it works with 8k, 16k and 32k (latter Mega Speedy) plain ROM dumps (without any COM/EXE headers). If started with one argument it wil verify the checksum of the ROM, if started with two arguments it will save a ROM with correct checksum to the second file - eg "romcsum patched.rom fixedcsum.rom" so long, Hias
  12. Check for intermittent contacts, bad solder joints or broken traces - especially at the large, heavy components like the huge caps. A magnifying glass and wiggling the components may help identifying such issues. I had a quite similar issue with one of my 1050ies here last year, and the culprit was a broken trace to one of the large caps just before the solder pad. Suspecting bad solder joints I had already resoldered the caps before, but it didn't help. And even with a magnifying glass and wiggling it was almost impossible to see that the cap had no contact - multimeter verified that though. That board almost drove me nuts, but finally I succeeded and the 1050 was alive again. so long, Hias
  13. This is about to be expected. The cassette routines in the Atari OS only allow a bit of variation in speed. Back in the old days there a couple of "Turbo Tape" systems existed (most of them requiring modification of the cassette recorder) but these are not implemented/emulated in AtariSIO. so long, Hias
  14. I never signed up to Facebook, Instagram, Twitter, Whatsapp or what all these nonsense-overload sites are called - forums and email are doing the job real fine and I still have time to meet friends in real life without a smartphone beeping every 5 seconds with a new cat pic from one of theit news feeds. If I want to look at a cat I just bend over and pet our own one 🙂 so long, Hias
  15. I'd also recommend reading through the Serial Input/Output Interface User's manual, it contains lots of interesting info and details eg http://ftp.pigwa.net/stuff/collections/nir_dary_cds/Tech%20Info/SIOSPECS.PDF so long, Hias
×
×
  • Create New...