Jump to content

HiassofT

Members
  • Content Count

    1,145
  • Joined

  • Last visited

  • Days Won

    1

HiassofT last won the day on November 10 2011

HiassofT had the most liked content!

Community Reputation

596 Excellent

About HiassofT

  • Rank
    Stargunner

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Salzburg, Austria

Recent Profile Visitors

20,726 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. That's to shorten the signal rise time. Together with the 3k3 pull-up resistor in the Atari total resistance is down to about 2k, and that's often enough to get reliable transmission at divisor 0, even with the 1nF caps in place. It can also help with a lot of SIO devices hooked up to the bus as that will also increase total bus capacitance. so long, Hias
  14. As ijor already mentioned latency is the big issue, and we'll have latency in the (USB/serial) driver code, the USB controller/protocol and the USB-serial adapter. A couple of months ago I did some measurements with FTDI chips on Linux, with the serial driver configured to low-latency mode (to avoid delays when sending data, plus IIRC that also configures the FTDI chip to use the lowest latency timer setting of 1ms). On a USB3 (XHCI) controller or on a USB2 (EHCI) controller with an USB2-hub inbetween (so the EHCI controller doesn't route the USB traffic to one of the UHCI or OHCI companion controllers) the minimum roundtrip latency was near the 125us microframe interval. On an UHCI controller it was near the standard 1ms frame interval, on an OHCI controller it was twice that - not sure if that is an issue with the OHCI controller or the Linux driver. In addition to that the FTDI chip won't send data packets faster than 1ms (the minimum latency timer setting). So, for example, when you receive a command frame ACK plus COMPLETE byte from a peripheral these two bytes (which are specced to have a gap of at least 250us between them) will be received as a single packet with 2 bytes by the PC. While that's no big deal for sector reads (which often take a long time) other commands like "get status" will have about that minimum gap. That alone is a nasty thing, as when talking to a XF551 you should switch from 19200 bit/sec to 38400 bit/sec immerdiately after the ACK, before the COMPLETE When acting as a SIO device you have all the time you want before switching speed and sending the complete on Read commands, but on write commands the Atari will start sending data (at high speed) about 1ms after it received the command frame ACK. You can imagine that you won't have much chance on a full speed USB connection with 1ms frame interval (you also need to repeatedly query the USB adapter if it has finished transmitting the byte), and even with a 125us interval it's rather hard to get the timing right - other devices on the USB bus may be blocking it (so you're at 250-500us round trip time) and/or latencies in the OS/driver will ruin the timing. With "real" serial ports things already look a lot better. There you don't have the latencies from the USB bus and if talking to the chip directly (bypassing the stanard drivers from the OS, like what I do with the atarisio kernel driver for 16550/16C950 UARTs) latencies can be reduced a lot and the XF551 protocol is no problem. OTOH with other USB-serial adapters like the prolific 2303 things are even worse, they (or at least the linux drivers) don't seem to support querying the transmitter empty status - so one has to "guess" if transmission is actually finished and wait blindly for a rather long time until it's safe to switch serial speed. so long, Hias
  15. Thanks for checking! Seems I missed your last post mentioning init_uart_clock. This'll result in a lower baud base (1.2MHz instead of 3) and also in higher jitter from the fractional divider. That's probably the reason for the changes in range. so long, Hias
×
×
  • Create New...