Jump to content

HiassofT

Members
  • Content Count

    1,148
  • Joined

  • Last visited

  • Days Won

    1

HiassofT last won the day on November 10 2011

HiassofT had the most liked content!

Community Reputation

602 Excellent

About HiassofT

  • Rank
    Stargunner

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Salzburg, Austria

Recent Profile Visitors

20,863 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. Good to hear this is working now! My OS SIO patch only accelerates D1:-D8:, so PCLINK will run at standard speed - so the result is to be expected. If you have a U1MB you could try using it's PBI SIO driver, IIRC this will accelerate PCLINK as well. I had a look at the SIO connection part of the 1050 schematics: The caps C56,C57,C58 (which are recommended to be clipped off) create a path from SIO data in to ground (C61 which is also recommeded to be removed is behind the CA3086's transistors so won't affect the SIO bus directly). With a 4k7 resistor in series and a total capacitance of about 19pF that won't be a huge load - though it'll still affect the SIO bus even if the drive is powered off. I also measured the parasitic capacitance of a SIO cable (between SIO data in/out lines and GND lines) and got about 110pF. So the worst "offender" seems to be the 1nF caps in the Atari, followed by SIO cable, then parasitic capacitance in the SIO device (like the caps in the 1050), each about one order of magnitude apart. The additional pull-up may help a bit in extreme cases (caps in the Atari plus a few SIO devices connected), but I'd guess a similar pull-up would be needed on SIO data out as well. so long, Hias
  10. In these tests I used my self-built serial SIO2PC interface where I added a 0.1" header so I can easily access the SIO signals. When I tested with the RPi and level shifter some time ago I used the SIO part of the PCB of a dead 1020 which I sawed off. Also with some headers added so I can easily grab signals. A picture of that is here: http://www.abbuc.de/community/forum/viewtopic.php?f=3&t=9715#p80170(the second SIO connector from that PCB now lives in my eclaire daugherboard, if it would still be there that PCB could serve as an easy method to get signals from a SIO chain). On other occasions I grabbed signals directly from the SIO port inside the Atari, one time I soldered headers into the holes of the (removed) SIO caps on the in/out/cmd lines - then I could attach dupont wires and have the keyboard of my 800XL in place. so long, Hias
  11. Some more traces of SIO data in (command ACK byte) with the pull-up removed no caps: caps: and here a zoom-in on the first bit of the ACK plus in comparison zoomed in traces with the pull-up in place. no pull up, no caps: pull up, no caps: no pull up, caps: pull up, caps: so long, Hias
  12. Did you have the diode in place in this test? The traces look a lot like it's missing - you have a steep rising edge from the push/pull outputs on the RPi up to 3V3 and then a slow rising edge from the pull-up resistor on the levelshifter up to 5V. so long, Hias
  13. I did some tests with my serial SIO2PC interface (MAX232, diode plus 4k7 pull-up on SIO data in). Only the SIO2PC and an 800XL were on the SIO chain and the cable was rather short (~15cm) and I tested at pokey divisor 0 (~125kbps). First on an 800XL with the caps in place: SIO data out, first byte of command frame: SIO data in, command frame ACK Then on an 800XL with the caps removed: SIO data out, first byte of command frame: SIO data in, command frame ACK So, with the caps in place the additional 4k7 pull-up on data-in indeed improves signal rise time (whether that's actually needed is another thing). Compared to SIO data out even single 1-bits make it near 5V whereas on SIO data out the edges are less steep and the signal only goes to about 4V. Compared to the measurements with the caps removed (with about perfect signal quality) one can see though that the signal high time (at the typical threshold of about 1.5V) is significantly shorter (especially on SIO data out). This means the headroom for variations in baud rates is smaller, too, which can be a problem in some cases (PAL and NTSC rates are a tad different, UARTs usually can't be configured to exact Atari baudrates or may have jittery clocks - like I saw on the Lotharek SIO2PC USB interface). So, instead of trying to doctor around symptoms with schmitt triggers (whcih can't compensate for the shorter signal high time) it's better to just remove the caps if you want good signal quality and reliable highspeed transmission. If you add more devices to the SIO chain with additional caps in place (like a bunch of 1050ies) things will get a lot worse. so long, Hias
  14. Thanks for refreshing my memory! Just checked the 800XL schematics, pull-ups on the SIO data lines are 4k7, not 3k3 as I posted before. So it'd probably be worth re-checking if the additional pull-up is actually needed. ISTR transmission was more reliable with it when I tested back then (with SIO2SD, SDrive and SIO2PC), but that was before I had a scope so I didn't check the actual traces. so long, Hias
  15. This is mainly true for TTL chips where the output stage is basically an open collector transistor coupled with a pull-up resistor. Current sinking capability of those devices (through the transistor to ground, on low level output) is usually about 5-10 times higher than current source capability (through the pull-up, on high level output). CMOS devices with totem-pole / push-pull output stages have (almost) symmetrical current source/sink values. See eg. the RPi GPIO specifications here https://www.raspberrypi.org/documentation/hardware/raspberrypi/gpio/README.md SIO data in (peripheral data output, Atari computer input) is typically open-collector output as well - eg the diode in SIO2SD converts the push-pull output of the Atmel to an open-collector equivalent, and only the pull-up resistor in the Atari (plus the optional one on the SIO2xx side) make the signal actually go high. The Pokey data sheet doesn't seem to contain output current specs (I_OH, I_OL) so checking the waveform on SIO data out would be interesting - I'm sure I did this at some point but can't find any traces stored on my PC, so not sure if the rising edges are steeper than the ones on SIO data in with the pull-up or not. Anyways, rising edges both on SIO data in and out will be flatter than falling edges, the critical point to look for though is around 1.2-1.5V, which is the typical lo/hi switching point both for inputs to the pokey and the RPi (and also most other TTL compatible inputs). Anything that happens above 2-2.5V is (in general) unimportant. so long, Hias
×
×
  • Create New...