Jump to content

thorfdbg

Members
  • Content Count

    865
  • Joined

  • Last visited

Community Reputation

339 Excellent

About thorfdbg

  • Rank
    Dragonstomper

Recent Profile Visitors

10,183 profile views
  1. Concerning "short integers": TurboBasic provides %0 to %3 as tokens, but one has to actively use them. I afraid they never became very popular because you have to remember to put them in. To reduce the size of the program, it was already custom in Atari Basic to replace constants by variables, to be initialized at program start. I believe there was also an automated solution for that which put in variables C0=0,C1=1,C2=2... at the end of the program. Concerning line number searching, Basic++ optimizes it in so far as it scans from the current line if it is a forward branch. TurboBasic keeps a 256 byte lookup table, indexed by the high-byte of the line number. However, Turbo also uses this type of line number search for FOR/NEXT loops, and for RETURN. Basic++ keeps here the address of the target line which is certainly faster. The ABC compiler creates a line number table as suggested, and uses a bisection to find a target line. The comment about FOR I do not understand. What is the other "FOR"?
  2. This is essentially a 16+24 bit big shift register. The carry that is rotated out of VAL,VAL+1 is rotated back into RES,RES+1,RES+2. After 16 rotations, the number in VAL,VAL+1 moved out of the lower part and is now completely in the upper bits. As rotation is identical to doubling, the algorithm works, except that doubling is here done in decimal instead of binary.
  3. Actually, this is version 1.08, but this should not make much of a difference.
  4. With the mathpack patch, it is down to 2726 jiffies.
  5. Basic++, with Os++ gives me 3874 jiffies, 1028 primes. You are likely using the original Os, with the original (slow) mathpack.
  6. Result for the ABC compiled code: 1899 primes in 2009 jiffies.
  7. You better use it with Os++ because the Os++ math pack is also considerably faster. As far as a compiler is concerned - well, any Atari Basic compiler would do. I would suggest to try it with the ABC compiler, which should create a suitable fast binary.
  8. With "cheating", i.e. math pack patch as in "host does the computation", down to 5291 jiffies. Of course, that is then not a fair benchmark, but it given an impression of where the overhead of the basic interpreter is.
  9. Basic++: 1899 prime in 7849 jiffies. This is faster than I thought. It is not ideal in Turbobasic since this still does a line search, although abbreviated, for each for-loop. Basic++ pushes the address to the stack.
  10. Frankly, there are other people that are better sources for learning. Of course POKEY is pretty limited, as said, it is an effects generator for video games and not a programmable synthesizer as SID is. Look for example (or "hear for example") at the sound demos of the POP-Demo by Kemal Ezcan, or the music intro of Nadral. I also consider some of the themes from Paradise Programming good quality, e.g. "The Tail of Beta Lyrae", "Mr. Robot". Or, to name another example, the minimal type of music Lucasfilms could play by only two channels in "The Eidolon". "M.U.L.E." has also a very recognizable tune, or "Ballblazer" (another Lucasfilms example). All these are good examples of what one can do. Certainly not high quality by today's standards, or to the trained musical ear, but yet, admirable and not quite so terribly out of tune as some of the examples found here.
  11. And that is exactly wrong. SID *does not* use a frequency divider. It is a phase accumulator. That is, at each clock cycle, a value f is added to an accumulation register a, and the upper bits of a are input to the waveform creation. This way, the output frequency is proportional to f, the frequency control register. This is quite different for POKEY, where the output frequency is proportional to 1/r, where r is the register value. This is exactly what creates the problem on the pokey side: Miserable frequency resolution for high-pitch notes.
  12. Unfortunately, you do not have much of a choice on an Atari 8-bit computer, really. As stated, one can certainly improve the situation a little bit.
  13. Well, unfortunately, it does. emkay's music *is* out of tune pretty much all of the time... However, concerning techniques: It is not strictly necessary to use 16 bit counters and hence waste one channel. The resolution is sort-of OK for the lower tunes, but it becomes a problem for higher-pitched notes. What one can do instead is to use a base-frequency of 1.79Mhz for the higher notes, and get away with an 8-bit counter, thus switch AUDCTRL dynamically. Unfortunately, this only allows to extend the resolution of two channels, not all four of them. For lower frequences, AUDC=Cx works - sort of. POKEY is more a sound effect generator than a music synthesizer, though.
  14. Actually, the formula computes the output frequency given the value of the pokey timer values. It is *2 since the output is inverted every time the timer underflows, and it is +7 (or +14 = 7*2) because this is the number of cycles Pokey needs to reload its internal counters from the timer values.
  15. It is as stable as the oscillator in the system. Pokey creates sounds by dividing the clock frequency, and the division is always the same. What may not be the same is the base frequency of the oscillator. It is a crystal oscillator which are *usually* quite stable, but the machine is old, and so may be the crystal.
×
×
  • Create New...