Posted By
IstvanV
on 2017-03-28
05:56:58
|  Re: Revival of interesting 'n' funny stuffs
Hi, if I counted right, the IRQ handler routine currently uses 128 cycles in the best case, and it runs at 11084 Hz. The following can increase the CPU usage:
- crossing the page boundary on wavetable lookup (this happens because of how the PWM effect is implemented for the pulse waveform) may cost up to 3 cycles
- handling video interrupts in the IRQ routine costs 6 cycles, although it is simpler and has lower latency than polling $FF09 in the main program
- the border effect costs 4 cycles
- not using undocumented 6502 opcodes adds 4 or 6 cycles depending on how video interrupts are handled
The version on the D64 was compiled with the slower options, except it does use undocumented opcodes.
So, if we assume 131 cycles per sample (worst case for the fast build), then it can run at about 6.4 kHz on the active part of the screen, maybe with a timer interval of 140 (6.33 kHz) for some safety margin.
Removing the table lookup from the D/A would save 4 cycles with undocumented opcodes, 2 otherwise. The ring modulation effect is only used by some of the tracks, deleting it would save 15 cycles, possibly more if it makes other optimizations possible.
Most of the memory from $0C00 to $F77F is in use, but if the size of the input file is known and not too large, then the buffer reserved for it ($8000-$DEFF) can easily be made shorter. Actually, all the sample files on the D64 are smaller than 16K, and only one needs more than 14K ($8000-$B7FF). Thus, the bitmap data could fit into the area $C000-$DFFF after moving some tables to free the last 256 bytes, and $B800-$BFFF may be available for the attributes. Reducing the number of volume levels at which wavetables are generated from 21 to 15 would free additional 4608 bytes.
|
