Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

328 Excellent

About thorfdbg

  • Rank

Recent Profile Visitors

10,099 profile views
  1. Yes, though it is possible to write another Os handler to manage such large screens. In fact, I should have such a thing somewhere and need to dig it out. It is a wide-display mode graphics 8 variant that is as tall as I could possibly make it. It does support PLOT and DRAWTO, though I need to check whether I still have the disk somewhere.
  2. There is also Basic++, which is also significantly faster than Atari Basic. There is Basic XL and Basic XE, both from Oss and thus essentially the same development team than Atari Basic. But no - none of these options fit your above check list. Atari Basic, TurboBasic and Basic++ do not have string arrays. Microsoft Basic does. None of them are compiled, though TurboBasic has a compiler, and there are multiple compilers available for Atari Basic and its variants (e.g. the ABC compiler). Recursive calling: Well, GOSUB is recursive, but none of the variants has argument parsing and local variables. Better graphics support you find in TurboBasic, sprite support you find in Basic XE and Basic XL.
  3. If you want to replace the Os floating point functions, then you need a little bit more than a fast binary multiplication and division. You would need two floating point registers (6 bytes) and a floating point result register. Of course, the OsRom FP representation is not very appropriate... *In principle*, you could connect a Motorola 68882 with suitable glue logic - you can run Motorola FPU as memory-mapped I/O chip. Actually, there have been math extension boards for the Amiga that worked like this, i.e. the CPU "manually" programmed the co-processor interface of the FPU, and collected results from there. It is not "quite as elegant" as an FPU connected to the dedicated coprocessor interface of the 68020 and 68030, but it should be faster than the mathpack, and certainly a lot more precise. The 68882 uses however the (much saner) binary IEEE floating point format, not the decimal mathpack format. It is not a suitable plug-in for the mathpack.
  4. While I do not know the cc65 calling conventions for functions, one thing is for sure: you are *at least* missing an RTS at the end of your assembler function.
  5. Actually, the Atari Os does not. If there is no dedicated handler for BRK, the code just runs into an RTI, and the RTI returns (of course) to the address of the BRK instruction + 2. No surprises at all. The only reason why it is usually understood to be a 1-byte instruction is because the official 6502 docs document it as a 1-byte instruction, and assemblers just copied this convention. What a BRK handler does about it is of course completely of its own. It could use the byte, adjust the return address or do anything else it considers fit.
  6. 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".
  7. 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.
  8. AUDxC =E is not any different from $A, so yes. However, if you use other distortions, e.g. $C, you can hear frequency 0.
  9. 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.
  10. 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:
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...