dos33fsprogs/chiptune_player/README.chiptune
2018-02-22 12:19:04 -05:00

96 lines
2.3 KiB
Plaintext

The Challenges of an Apple II chiptune player.
The goal is to design a chiptune player that can play large
(150k+ uncompressed) chiptune files on an Apple II with 48k of RAM
and a Mockingboard sound card.
An interrupt routine wakes at 50Hz to write the registers and a few other
houskeeping things.
Not enough RAM to hold full raw ym5 sound data (one byte for each of 14
registers, every 50Hz). This compresses amazingly. Using LZ4 by at
least a factor of 10. But it won't fit all in RAM so we have to load
the full file from disk (no way to do disk I/O, disk I/O disables interrupts)
then decompress in chunks. So we need room for both the compressed file
plus uncompressed data.
The problem is decompression also takes a while, longer than the 50Hz.
So if we just decompress the next chunk when needed the sound will noticibly
pause for a fraction of a second.
One solution to that is to have two decompress areas and flip between them,
decompressing in the background to one while the other is playing. The problem
is splitting the decompressed data into smaller chunks like this is that
it doesn't compress as well so it takes up more disk/memory space
for the raw file.
Memory Map
(not to scale)
------- $ffff
| ROM/IO|
------- $c000
|DOS3.3 |
-------| $9600
| |
| |
| FREE |
| |
| |
|------- $0c00
|GR pg 1|
|------- $0800
|GR pg 0|
------- $0400
| |
------- $0200
|stack |
------- $0100
|zero pg|
------- $0000
Sizes
time ym5 KRW(3) KRW(2)
~~~~ ~~~ ~~~~~~ ~~~~~~
KORO.KRW 0:54 ? 2740
FIGHTING.KRW 1:40 ? 3086
CAMOUFLAGE.KRW 1:32 1162 4054
DEMO4.KRW 2:05 1393 4061
SDEMO.KRW 2:12 1635 5266
CHRISTMAS.KRW 1:32 1751 4975
SPUTNIK.KRW 2:05 2164 8422
DEATH2.KRW 2:27 2560 8064
CRMOROS.KRW 1:29 2566 8045
TECHNO.KRW 2:23 2630 8934
WAVE.KRW 2:52 2655 8368
LYRA2.KRW 3:04 2870 9826
INTRO2.KRW 2:59 3217 9214
ROBOT.KRW 1:26 3448 7724
UNIVERSE.KRW 1:49 4320 9990
NEURO.KRW 3:47 8681 22376
AXELF.KRW 10:55 9692 47989
Interesting bugs that were hard to debug:
+ Bug in qkumba's LZ4 decoder, only happened when a copy-block size was
exactly a multiple of 256, in which case it would copy
an extra time.
+ Bug where the box-drawing was starting at 0 rather than at Y.
Turns out I was padding the filename buffer with A0 but going
one too far and it was writing A0 to the first byte of the
hlin routine, and A0 is a LDY # instruction.