Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

121 Excellent

About GoodByteXL

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location
    XL heaven
  • Interests
    A8 archiving

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. off topic This is something I tried to confirm for all the decades since the 80's. And the result to me: it is nonsense to blame the capacitors, as long as they are fine. I never (!!!) had and have the need to extract the SIO caps in more than 40 machines over the decades to get reliable SIO highspeed. And I had a lot of discussions about it over the decades. To my experience a clean SIO signal has absolutely no problem to function as Atari produced it. To proof this I repaired an old 800 XL mainboard, Rev C, last winter and tested it. NO issues! Next I extracted ALL CAPS C71 to C78. No difference. A friend of mine checked that using a logic analyzer and told me that there is a very small cleanup effect by doing this, but nothing spectacular. This is why PD 0 is no issue on the side of the Atari machine itself. The signal might get disturbed by other devices and then deteriorates - in this case it might help. The only instance I know is concerning the XE machines. The original Atari schematics for the 130 XE floating around do show an important error. C71-78 are doubled in those drawings: 1 set guided directly to the POKEY, another set close to the SIO port. I saw XE mainboards carrying both cap sets. These machines might have problems to get higher speeds than PD 4. The caps close to the SIO port are superfluous, if the ones around POKEY are on the board. Of course there are so many other issues having an effect on the SIO lines, that every user might get a different experience and coincidentally does something that heals the problem. Then with the next re-arrangement of the setting the game might start over again.
  2. Good catch. Indeed do not use those trailing path delimiters in my batches. Will for the time being put a note in the manual with the PCL driver.
  3. No - there is simply no need for it as SDX uses unlike Atari type DOS relative file access. Jumping to any sector anywhere on the drive is blazing fast compared to Atari type DOS. And, if you expanded a directory by copying too many files to it, approx. more than 200, it will never decrease. Empty it and delete it. To cleanup there is a tool for it on the tool kit.
  4. Given you are using real hardware, there are a few things to keep in mind ... If there is a hardware cache inside your machine, it might not work with the PCL driver. Disable it (like I recommended that in the manual for the FIFO). SIO high speed might be too high (here I cannot use the PCL driver at higher settings than PD 4 with PCL). Starting with PD 3 and lower creates that experience you described then. Of course this is related to my hardware. It might be different over there. If possible, please use the latest version of SDX -> 4.49g and the corresponding tool kit. Used RespeQt 5.3 (test-wise, standard version is 4.0 here) under Linux to recursively do copies to and from a PCL drive; works fine here. I do my backups also that way. To speed the process up a little bit you could use COPY /RS switching off ANTIC.
  5. Took some time to find it, but here is the oldest hint to this problem I know of: ANALOG issue 45, page 23, Using BASIC XL's Hidden Memory by Robert Opitz
  6. Yes, all ABBUC e. V. content from 1985 - 2015 is covered on this DVD:
  7. Besides using it under Linux - Are there any printers working at all? Tried it lately and it is a mess. The only readable output is on 1020 as long as it does not comprise more than 1 page. Every next page gets printed on the first sheet. Redirection to a PDF under Linux works fine, but again, everything on 1 page.
  8. Dug it up, finally. This is what Simius proposed and I followed it:
  9. Yes and no - the problem arose back then when trying to engage bank $D5 for other uses, e. g. internal real time clocks. So it has not necessarily to be a 'stacked cart' but something using that bank. When resigning the those carts this fix should always be taken into account.
  10. I came across the same experience you described years ago. I wanted to use CF and SD cards with Rev C as I did before with the MSC IDE Controller. Simius told me that there is a kind of incompatibility of Rev C with 'some' CF adapters for IDE. As a fix he sent me some guidelines how to modify the Rev C - and it works fine since then with adapters and still with hard drives. My standard setup uses a 4 GiB CF card using a large FAT partition as an read-only archive. The CF card is frequently mirrored to an image to be used with Altirra running the same setup in hardware. As for another run it it still save to use IDE 2.5 as there are more than sufficient options to use adapters for it. Even if IDE to M-SATA seems to be a crazy idea, such an adapter plus a small SSD is relatively cheap compared to an an CF adapter and brand CF card.
  11. It is like written earlier ... Or in other words, the OSS supercart does not allow the usage of bank $D5xx as it kills what is there unless corrected.
  12. Yep, took it from the corresponding article I wrote for ABBUC magazine #105. It reads like this:
  13. When modifying the original OSS pcb it needs an additional 74LS32 if you plan to use the rest of the bank $D5 together with one of the OSS languages in M091 cart format. I am not familiar with the boards from PCBway. BITD I managed to modify one of my OSS carts to a 4-in-1 type hosting ACTION!, BASIC XL, BASIC XE, and MAC/65. More than a decade ago I learned with the help of Hias that those carts lack proper decoding and modified my OSS-4-in-1 again.
  14. Please keep in mind that the original cart design M091 does lack a proper address decoding. While banking the whole bank $D5 is addressed, what causes other hardware or software using other parts of that bank (than the few addresses really needed by these OSS carts) to crash. For correct schematics please contact tfhh in this forum. It needs one more chip - LS 32 - to solve this. Or a proper programmed GAL, etc.
  • Create New...