Jump to content

thorfdbg

Members
  • Content Count

    849
  • Joined

  • Last visited

Community Reputation

333 Excellent

About thorfdbg

  • Rank
    Dragonstomper

Recent Profile Visitors

10,143 profile views
  1. Just forget the internal memory test. First, the test on the first K is all fake, i.e. it always shows green and does not perform an actual test. Then, the test for the region that is covered by the self-test overlay ($5800 to $5c00) is also all fake and does not test anything, just lights the square green. Then, the test is not quite a test. It writes a byte, and immediately read it back. However, a typical failure pattern for dynamic RAM is that bits are flipped randomly after a while, i.e a better test would be to write all bytes, then wait a while, then read them back. Last, the test tests the RAM byte-wise, but the RAM is organized bit-wise, i.e. each bit is in a separate chip, not each K block. Thus, it would be much more helpful to have eight blocks, each representing one bit, and belonging to each of the chips. Long story short: Just forget the outcome of this test - it's worthless.
  2. Too late. Remember, a program may want to load into the $a000 area, thus at the time you run through warmstart, the conflict already happened.
  3. On the XL operating system and Os++, this is normal if you run through a reset. The state of the basic switch is stored in address $3f8. The byte at this address shall be non-zero to enforce that the Basic ROM stays disabled after going through the reset vector. On a second matter, it is in general not sufficient to switch basic off just before the binary starts. You need to turn it off before the binary loads. That is, you need to prepend a small code to the actual that is run through the init-vector of the dos loader, which turns basic off both through PIA Port B, through the BasicDisabled flag at $3f8, then adjusts memtop, then re-opens the editor, then continues loading. This is because a binary may well use addresses above $a000 to load to, and this would fail if Basic would be still on during loading.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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".
  10. 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.
  11. AUDxC =E is not any different from $A, so yes. However, if you use other distortions, e.g. $C, you can hear frequency 0.
  12. 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.
  13. 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:
  14. 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.
  15. 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.
×
×
  • Create New...