A bunch of low-level hardware-related questions (and sound synth things)

SDK Get Help
,
1

Hello! I am considering buying the console because it is rather unique and amazing device. Although, as a rookie ARM hardware enthusiast, I have several questions, because I am not interested in making games, so you have all the rights to completely ignore my chatter.

Of course all the questions below belong to C language.

  1. The screen updates

I have read this and it looks like that you already use DMA for updating the screen. But: can you just make single buffer and automatically send the whole frame? Framerate will be capped but it would be easier for CPU (you just update the necessary things (bytes in the buffer) and leave the ones that must not change, and let the DMA do the rest automatically (circular buffer mode), even if half-updated frame is sent, you will understand why it is important for me).

  1. The RAM

You mentioned in the thread linked above that only 320 KiB of SRAM are available, does it mean that other 16 MiB are connected through SPI or some other relatively slow bus? The CPU (STM32F746) has some hardware support for memory, or this memory cannot be accessed by DMA? If these 16 MiB are somehow "external", how fast they are (1-byte reads/writes per second, for example)?

  1. The SDK

Can I completely stop all the FreeRTOS things when my app is running? I know that I would need to manually do the screen and other stuff but I want ALL the performance... I want to start it at my will, though, to e.g. write/read files, but then stop again for performance-critical parts.

  1. The overclock

The datasheet stays that this MCU can run at 216 MHz but your clock speed is lower. I understand it as you wanted to make battery life longer, am I right? Can I somehow crank it up when my app is running and then return back to default values? Which raises the next question...

  1. The low-level control

Can I completely bypass the SDK and make direct hardware register writes, directly program DMA channels and modes, timers, interrupts (with priority levels) etc.?

  1. The audio

I want direct access to audio buffer(s) for doing my own sound synth routines. Changing sample rate to arbitrary values would be nice addition but I am afraid you use some external DACs that would not allow that. I also hope you use some kind of DMA transfers to output the audio. I want to manually start and stop the audio playback at hardware level. Also recording some sounds from microphone would be a nice addition since you can sample on the fly.

  1. The controls

I hope you connected the buttons in such a way that I can use hardware interrupt when they are pressed. This is important because it allows to immediately stop the tight sound synth routine when the button is pressed which is quite convenient.

  1. The app execution

My theory is that the app is loaded into RAM entirely, so the 16 MiB are occupied by code and data. If no, how can I force this to happen?

  1. BUT WHY??

Because I want to write a tracker! The Flipper Zero one was fun but this console has much more RAM so I can play samples in addition to synth sounds, faster CPU means I can have more channels and more advanced synth (like 4-op FM synth yeah), and bigger display means I can organize the display in a more... meaningful way :slight_smile:

I understand that the console is intended for games not for chiptune trackers, but how it can be retro without retro music? :wink: Pulp editor is too limited and is not a tracker which makes me sad. And also... maybe... I will make MOD/XM/IT player! But only if I have the idea about the questions I wrote... So... If you really want to answer to this pile of stupid questions, you sure are welcome!

1 Like
2

It sounds like you just want the standalone STM32F746 without the actual software/other stuff that comes with the PlayDate. That way you'd have access to the 9 points you mentioned above.

You can probably just grab the STM32F746, the screen Panic uses on the PlayDate, 6 buttons, a potentiometer and a speaker and I think you would be good to go.

2 Likes
3

My sense is you're not going to be happy with Playdate. As you note, we have a lot of system there to support game development that's getting in the way of your goals.

Have you thought about building your own hardware? A Teensy 4 has a faster CPU than Playdate and they've got some really nice tools for building soft synths. I think you'll have a lot more fun doing this from scratch!

4

Okay rewriting the loooong response again, the forum was down...

The point is to make the project available for others. If I make a crap design on proto board others would not be able to use it. Google for example hardware chiptune project. On Flipper or there I have a potential audience of several thousand people who are kinda likely to be interested in the project.

Also I am preparing for making full-fledged demos, and that means I believe that limitations like small screen on Flipper or crazy controls and still 1-bit screen on Playdate make it much more interesting (or maybe impressive for the viewer I think, that's not the main goal for me actually). Also just found somebody is already making a tracker, but it still uses internal synth which is boring, unoptimized and generally not fun, at least for me.

And the goal is to show what you can do with clever programming, knowledge and maybe some advice from 8-bit 1 MHz CPUs era :slight_smile:

P.S. Had a lot of fun with Flipper Zero when making a tracker, so if low-level hardware control is there will have fun too, why not?

5

Also I actually have Teensy, although 3.6 not 4. And synth using instruments isn't fun, where are my optimized semi-unrolled loops and crazy barely readable C macros for special things? Not to mention amazing (stolen from Furnace tracker TSU synth core) multimode resonant filter in 3 lines of fixed point calculations code that I used in Flipper tracker... I do love writing such things from scratch, but at the same time I don't want to do this for other things, like file system (yes there are libs but nah it's way more convenient to use parta of SDK as it was with Flipper, you just have basically fread fwrite fopen fclose and you are happily loading/saving modules).

6

And it would not be portable! Where would I jam on it, only at home? Not a musician actually but the Playdate as well as Flipper are nice small portable devices without a bunch of wires and SD card reader or whatever hanging from the side... I am just a uni student so I just don't have time nor money for making something portable.

7

Firstly, your Flipper Zero Tracker is awesome.

There are at least 3 trackers in progress in Playdate but none of them have released so far.

Whilst it would be nice to have full control over Playdate hardware, it is what it is. The challenge is the make the most of the hardware as it stands. I've found it fun and immensely rewarding.

Plus, if you build on the Playdate SDK then developers will be able to use your playback routines in their games? If you build on a different SDK or on bare metal, might it be more difficult to guarantee good playback in a game?

You can code in Lua, C, and perhaps even ASM. I think the door is open for your to make the most of the opportunity.

I'm excited to see your results!

My unofficial answers:

  1. The screen updates

Sprite system already solves this issue.

  1. The RAM

Not sure.

  1. The SDK

I know there has been some reverse engineering of Playdate. Join the Playdate Squad discord.

  1. The overclock

See 3.

Also I believe there are two slightly different MCU used in Playdate over production lifespan.

  1. [The low-level control

See 3.

  1. The audio

Not sure.

  1. The controls

I believe it's a hardware interrupt.

  1. The app execution

Your theory is correct.

8

Oh no worries, you can make it portable, there are circuits that can help you add a lipo battery. You can make it at probably the same price as a PlayDate. As for the case, a cheap generic case(there's a bunch available online) or even use a tin breath mint case. Your imagination is the limit really.

9

While I see no direct answer about direct hardware control, I am still pleased you liked the tracker.

The thing is that in Flipper case I have a decent way of direct hardware control, there is a low-level library and compiler allows direct registers writes.

What about in-game usage? Well, if coded properly, the thing can have sort of API (load song, play song, set volume etc.) and run entirely on timer/DMA interrupts (as was the case with Flipper; Flipper FreeRTOS was happy enough since sound and tracker engines interrupts were of lower priority than OS ones), the question was that Flipper is too slow to update the screen and game logic AND do synth with filters and sample-rate ADSR envelope at the same time, so I didn't bother making it a fully headless thing. Btw Flipper devs announced the fal files which are like dlls but you can load and unload them into RAM from SD card, perhaps something like this would be definitely possible for Playdate, and it would allow game developers to just use my tracker engine through aforementionned pseudo-API, with reasonably optimized modules or in static scenes (the full screen updates at 30 fps and like 14 channels of sound synth with filters would not really like each other...)

10

Okay, only now see the answers. Going to Discord rn

11

I've also sent you a DM.

12

I literally would do a flipper-playdate cross lol, with loooooooong GPIO pins stack going all around the edge... For VGA output, obviously!