Minor doc updates.

This commit is contained in:
Chris Hodges 2023-07-25 18:37:59 +02:00
parent 0496cf73bd
commit d62eacf5f8

View File

@ -54,7 +54,7 @@ during the vertical blank.
Please use the documented sizes for the `MySong` and `MyPlayer` data
structures, which are the symbols `sv_SIZEOF` and `pv_SIZEOF`
respectively (about 2K and 12K with volume table).
respectively (about 2KB and 12KB with volume table).
The source needs two common include files to compile (`custom.i` and
`dmabits.i`). You should leave assembler optimizations enabled.
@ -69,6 +69,7 @@ The source needs two common include files to compile (`custom.i` and
- a pointer to chip memory sample buffer in `a1`
- the pointer to `MySong` in `a2`
- a pointer to a longword for progress information or null in `a3`
This will create the samples, too.
4. After that, regularly call `pre_PlayerTick` with `MyPlayer` in `a0`
and optionally the copperlist in a1 if you're using that mode).
@ -87,9 +88,13 @@ Raspberry Casket, depending on the features compiled in, is about
So this means that the optimization is not just "on the outside".
About 2.4 KB of the code (and data) are spent for the sample generation,
the remaining code for playback.
### Timing
Sample generation is a bit faster (I guess around 10-15%), but most of the time is spent on muls operations, so this is the limiting factor.
Sample generation is a bit faster (I guess around 10-15%),
but most of the time is spent on `muls` operations, so this is the limiting factor.
Raspberry Casket is about twice as fast as the old replayer for playback.
Unfortunately, the replayer is still pretty slow and has high
@ -117,6 +122,11 @@ solve this problem.
## Changelog
### V1.x (unreleased)
- Fixed a bug regarding the copper output mode with looping waves having a loop-offset.
- Fixed wrong register use on triggering waves regarding the loop offset.
- Minor code size optimizations.
### V1.1 (28-Dec-22)
- Optimized base displacement by reordering variables.
- Further optimized ADSR code.