Just released my first ever demoscene demo at Revision 2026 in the Wild-Compo:
A tech demo for Casio fx-9860G graphical calculators!
Sourcecode: https://github.com/Manawyrm/Casiomania
Details: https://kittenlabs.de/casiomania/
https://youtu.be/aLiuF9k3Xt4?t=31
EDIT: 5th place in the Wild compo \o/
@lda No idea what happens without a t6k11 (I mostly only use it for the initial snow and contrast setting).
Give it a shot on a different calculator with SH-4 if you've got one :)
(no promises, though :D)
@manawyrm hm, after removing basically all calls to t6k11-related functions (and with build-fxg3a), it still failed
looks like it's caused by the audio thread using DMA channel 0 (channel 0 and 1 are reserved for gint tasks on the fx-CG50, 0 IIRC is for sending VRAM over and 1 is... something? I honestly forgot why it was used)
I think you'd also need to mess with the C0MID address used as it's hardcoded (I'd say my branch of gint defines fields for that, but the forge it's on is getting hammered by AI scrappers, sorry!)
Still doesn't seem to get past the introduction sequence, so I assume there's something wrong with the DMA code still...
@manawyrm UPDATE: turns out the hang was because I used the wrong DMARS selector (I geninuely forgot each DMARS field held 2 RIDs!)
It now works (mostly) fine on fx-CG50/G90+E (except for audio playback speed, but that could likely be fixed by using a better value for the SCIF's SCBRR/computr it on the fly)
@Ronflaix no timers (those are used for grayscale!) but DMA yes.
Every time the DMA finishes sending bits, it triggers an interrupt which will then generate a new PCM buffer and also convert that into the PWM bitstream.
No mixing at all, just single stream, but you could totally mix if you wanted too.
@Ronflaix ehh, well, there's a lot of interrupts, but generally speaking, it's not too bad. the CPU is suuper fast, you have lots of time to do most things (as long as you don't do soft-float calculations :P).
If you were really strapped for CPU time, I guess the routines could also be optimized a bunch. The audio samples and the big PWM lookup table are all just stored in the code right now, which I'm guessing will load them into the CPU d-cache at every firing of the interrupt.
@Ronflaix
In other words, every few milliseconds your actual main loop will get interrupted, the cache will be overwritten with audio data and then it'll return execution.
That could (and maybe should?) be benchmarked and probably fixed :)
@manawyrm The CPU might be super fast but only its cache and the DSP's memory banks are as fast as that, sadly. (Still haven't opened the repo, sorry) I suppose you're not really using Azure and you're using that free extra cache for shenanigans, aren't you? :D
(I'm using Azure as my own "equivalent" failed to follow up on performance as I was starting to add text for *that* project and I lacked patience, time and tooling to investigate the innards of the CPU.)
@Ronflaix i don't even know what Azure is :D
I'm using a couple of the Y and XRAM regions as well, which are internal to the CPU iirc.
If one were really clever, the DSP RAM could probably be also used for audio usage very well (but I didn't bother).
@manawyrm Azur* is Lephe's "game" framework running on top of gint. I mostly use its rendering and game loop system, replacing my own homebrew ones. I forgot whether it was gint or Azure but one of both used the DSP RAM as partial VRAM to blit to the screen chunk per chunk of scanlines.
If I have some time and motivation, i guess I could check how that'd work on my end. Thanks a bunch for showing me it can be possible.
*EDIT: Azur, not Azure, my bad.
https://git.planet-casio.com/Lephenixnoir/Azur
Jeezy Peeps
Manawyrm | Sarah
Vivi
LDA [doki doki waku waku 
]
Schenkl | 🏳️🌈🦄
James Mitchell
halcy @ 
feuerrot
coldclimate
Joe
dmi 💽 
sb arms & legs
ROllerozxa
yetzt
Stu
48kRAM but with parity
iLow
Ronflaix
Andreas Scholl (Zeronine)
Chip
blinry
지지 ᚠᚱᛖᛃᚨ Daniel 黄法官 CyReVolt