Jump to content

thorfdbg

Members
  • Content Count

    841
  • Joined

  • Last visited

Community Reputation

327 Excellent

About thorfdbg

  • Rank
    Dragonstomper

Recent Profile Visitors

10,029 profile views
  1. Not quite sure on which level you want to understand this. On a pure basic level, it is just a matter of opening "D:*.*" with AUX1=6 and read lines until an EOF. But this is probably not what you need. If you need to decode the raw (binary) version of a directory, then an entry consists of one byte of flags, two bytes of the size in sectors, two bytes of the start sector, 8 bytes for the file name, and 3 bytes for the extender. This makes 16 bytes per entry. For the precise layout, I need to check, but the MSB of the flags identify whether an entry in the directory is deleted or not (and if deleted, it is not shown and the entry can be recycled). If the flags is 0, then this ends the directory. Bit 5 is (if I recall correctly) the "I am write protected" flag, and bit 2 is always set to identify that the file is in Dos 2 layout (as compared to Dos 1 which has a different sector link). Then, some "invalid" combinations have been allocated by Dos 2.5 to indicate "I am outside of the 720 VTOC", and by Dos 2.++/Dos 2.XL to indicate "I am a headline".
  2. Well, frankly, the 68K is considerably more orthogonal than the 6502. There are only two types of registers, and every instruction works on every register. The 6502 is not quite so symmetric. X and Y have different roles and work differently, many instructions only operate on A, and not on Y and X. In the end, it is pretty much an apples to oranges comparison. The 6502 was considerably earlier on the market, it was not designed as part of a processor family as the 68K was. As far as the number of operations per cycle, the 68060 is certainly better than the 6502 - but then again, a completely different beast. The 68K was microprogrammed, the 6502 was hardwired. It's clear that the 6502 performs more operations per cycle. Though can do more things as well, llike multiply or divide.
  3. AUDxC =E is not any different from $A, so yes. However, if you use other distortions, e.g. $C, you can hear frequency 0.
  4. Freq. 0 is as such valid, though the frequency is too high to be audible. However, there is a DC bias in Pokey if it generates sound, and the bias is relative to the volume. So the knocking sound is the variable DC bias due to the amplitude modulation. The sound itself is not audible.
  5. Problem is that this already mixes E: and S: functionality. For example, scrolling. If you copy to S:, and have a graphics screen open, then S: forwards the scrolling to E:, and instead of scrolling the entire screen (e.g. 192 lines), it only scrolls the first 24 lines. S: should rather be a "frame buffer", i.e. you copy in it, but it should not scroll. Scrolling and interpretation of control characters is up to E:
  6. One of the problems is that in the original Atari Os implementation, S: and E: are not very well isolated. Essentially, if you open S: in graphics mode 0, you get almost an E: output, except that (as you observed) the cursor handling is broken. This is not a problem of your program, it is a defect in the S: implementation, and the partial sharing of the S: source with that of E: In Os++, this should work correctly.
  7. Whether Microsoft Basic would be better or worse would be another discussion - not related to the apparent slowness of Atari Basic and its sub-optimal math performance. I strongly believe that Atari Basic was a good choice as it provided elementary graphics and sound support that allowed users to use the powers of the machine without much complexity. Compare this with the C64: Creating sound or graphics was a nightmare of peek/poke. Even if math performance might have been better, the overall package the user got in the C64 world was worse. The C64 port was a "quick and dirty" port of MS basic, without taking any of the strengths of the machine into account.
  8. Not only that. Most importantly, available slots for player DMA. 8 players would have required 3 additional DMA slots from Antic, and thus would have required to reduce the size of the playfield. Later on, in the Amiga, Jay did exactly that: Made the start of the playfield DMA configurable such that you could compromize between the number of sprites and the width of the playfield.
  9. I doubt that. Atari Basic was what SMI could deliver in time. It is not the result of some kind of engineering master plan to keep Basic slow, just what was possible in time and the capabilities of the team back then. Atari needed a Basic, they needed it quickly, and it should be sufficient to demonstrate the powers of the machine. Consider it would have been Microsoft basic: No "graphics" command, no "sound" command, only peek and poke. Probably a bit faster, but certainly not better.
  10. You are right, though this is just (another) defect of Atari Basic where a check for the dimensionality of the original array is missing on its use. Similarly, one can also access 1-dimensional arrays with two indices giventhat the second index is zero.
  11. I wonder which type of answer you expect. The only way how to get a definite answer is to ask the authors, and other than that, speculations and arguments have been provided in the thread. As stated, I assume that the reason is that SMI wanted to support interactive programming, allowing CONT after editing the program. The interpreter size is not an argument (experimentially falsified).
  12. Hardly. Basic++ fits into 8K and does exactly that. I believe I said this already.
  13. Not really. Did that for Basic++. The line number search requires an additional JSR, the address does not, and the same function is used for NEXT and RETURN, so it does not make much of a difference. The tricky part is that the address is not necessarily valid.
  14. There is no way to timeout INPUT. What you can do is to query KeyCodeShadow, and if this is 255, continue operation of the program. If it is set, get the next keypress through GET. You would then need to implement some elementary editing functions (such as backspace) yourself. For the serial port, you can find out how much data has been buffered up and can be retrieved. For that, issue a status, and then read the number of buffered bytes from $2eb and $2ec. If this is zero, there is nothing to read from R: Otherwise, you can retrieve the bytes without blocking. This should give you about an idea how to run the input loop.
  15. Ehem. The way how Basic++ handles this does allow you to stop the program, edit it, and continue its execution, so there is no user observable drawback. The only drawback is that the stack entry is larger. A common application of this technique are "self-modifying" programs. You printed the new program contents on the screen, including a "CONT" at the screen bottom, then poked the screen editor into auto-linefeed mode and stopped the program. That even works in FOR/NEXT loops or subroutines. Including in Basic++ of course.
×
×
  • Create New...