Jump to content

thorfdbg

Members
  • Content Count

    965
  • Joined

  • Last visited

Community Reputation

398 Excellent

1 Follower

About thorfdbg

  • Rank
    Dragonstomper

Recent Profile Visitors

10,620 profile views
  1. This POKEY bug reminds me of a similar if not identical bug in the VIA 6522 shift register which can also miss a clock. It is the bug which caused CBM using a bit-banging interface for the floppy, and which is responsible for the terribly slow floppy transfer rate of those machines. The problem was fixed in the CIA chips (revised and enhanced VIA), but CBM in their infinite wisdom decided to keep the bitbanging interface for compatibilty reasons. I wonder whether Atari just copied the POKEY design from VIA, does anyone know?
  2. Look, I consider it rather telling that Atari itself never produced a device that used their own interface. When they provided new hardware, they rather used the joystick ports - consider the kludgy XEP-80. The whole thing solved a problem nobody had back then. It became somewhat relevant later with third-party additions, but at that time, Atari had given up the platform already. To boot from an external parallel device, a considerably simpler construction would have been possible - just a small SOI patch-up or an improved bootstrap would have done.
  3. Would a Dos 2 compatible Dos with a command line interface, designed for the 1050 work? IOWs, everything a RAM-based DOS could achieve can be done. Frankly, if I want a hard disk....well, there are certainly other systems that take more profit from it. The Atari 8 bit is just a nice legacy game machine.
  4. I would not call it "bad". Just "under-documented" and "over-engineered" and "bulky". It partially could replace SIO functions, also CIO functions, it also had a relocatable loader, and a HATABS extension. Yet, for most users at its time, it was left unused, and just took away precious ROM space.
  5. The corresponding DOS does, or whatever was booted through the PBI functions - or the DOS in general. I found this quite annoying back then that you always needed to boot the Dos from the floppy, and that it took RAM away from the user. Thus, from the 64K of RAM the system had, only half of it was left for the user. A harddisk wasn't an option for most users back then - instead, Atari should have integrated a suitable DOS into the extended ROM. That would have been much more beneficial to most users than the PBI - for which no equipment existed while Atari was selling the XL line.
  6. Oh well, maybe we have very different ideas what kind of a system this should be. Any kind of hard disk handler will take even more of my precious RAM. If I would want a faster or more powerful machine - I have a PC, thank you.
  7. By whom? Frankly, the number of PBI devices is rather low... the whole thing is grossly underdocumented, so I don't dare to look into this dark area of the Os.
  8. All existing already .. see above. Os++ has a faster FP ROM, a DOS and a DUP, all in the regular 16K ROM.
  9. Exists already, look into Os++ that comes with Atari++. It includes a Dos which takes only page 7 + disk buffers. The latter can be relolcated behind the Basic ROM or the Os if you need even lower footprint.
  10. Almost. As you say, the I/O chip region is not part of the ROM, but in this specific region of the ROM, the self-test is mapped. Thus, you need to do the following: 1) Write the contents from $c000 to $cfff linearly to a file 2) Turn on the self-test by clearing bit 7 of PIA Port B $d301 3) Append the contents from $5000 to $57fff linearly to the file 4) Turn off the selftest by setting bit 7 of PIA Port B $d301 5) Append the contents from $D800 to $ffff to the same file. This gives a ROM-image that can be directly burned to an EPROM.
  11. No, a GOTO doesn't break anything, but you can start a new FOR-NEXT loop with T as counter. The only issue is that an entry remains on the run-time stack of Atari Basic that, if you repeat doing this, continously eats up memory. However, the next RETURN the code runs into removes any stray FOR/NEXT entries from the run-time stack. The recommended way is to first do a POP, then a GOTO. The POP removes the entry, the GOTO leaves the loop. An alternative approach that also works has been proposed by the OP.
  12. There is a checksum code, indeed, just a pretty well hidden one. I forgot unfortunately the details. If I recall, it was part of the VBI which checked for a flag, upon which it decoded a function which performed the checksum.
  13. Not Basic, but here is a C source which does that: checksum.c
×
×
  • Create New...