Homebrew I'm planning to make a programming language for a DSi

  • Thread starter Thread starter BenHasADSi
  • Start date Start date
  • Views Views 3,066
  • Replies Replies 27
  • Likes Likes 4

BenHasADSi

Member
Newcomer
Joined
Dec 8, 2024
Messages
9
Reaction score
5
Trophies
0
Age
24
XP
32
Country
Canada
Hey everyone,

I’m Ben, a passionate developer and fan of the homebrew community. I’ve always admired the creativity and ingenuity of this community, and I’m excited to share an idea I’ve been working on: Bread, a programming language specifically designed for the Nintendo DSi!

The goal of Bread is to provide an accessible yet powerful tool for creating homebrew applications, games, and experiments directly for the DSi. I want to make it easier for developers (new and experienced) to tap into the unique capabilities of the console.

Why Bread?

Simple Syntax: Bread will be designed with ease of use in mind, making it approachable for beginners.

DSi-Centric Features: It will include libraries and commands tailored to the DSi’s hardware, such as the touchscreen, microphone, and cameras.

Community-Oriented: Bread is meant to be open and collaborative. I’d love feedback, ideas, and even contributors to help shape the language.


Current Status

Right now, I’m in the planning stages, designing the syntax and figuring out how best to interface with the DSi’s hardware. I’ll be documenting the process as I go and sharing updates with the community.

How You Can Help

Feedback: What features would you like to see in a DSi programming language?

Suggestions: Are there existing tools or frameworks that could inspire Bread?

Collaboration: If you’re interested in helping build or test Bread, let’s connect!


I believe the DSi still has so much untapped potential, and I hope Bread can help unlock more of it. Feel free to share your thoughts—I’d love to hear from you!

Thanks for reading, and I look forward to building something great together!

Cheers,
Ben

Feel free to also join my Discord server to chat 24/7 about some ideas for our upcoming programming language, Bread!
https://discord.gg/6Nn5YcQP
 
Last edited by BenHasADSi,
If you don't mind sharing: what does the Bread syntax currently look like in your planning?

As for ideas: this may not be what you're going for, but being able to use a visual programming language on the DS itself would be cool, accompanied by sprite and music creation tools.
 
If you don't mind sharing: what does the Bread syntax currently look like in your planning?

As for ideas: this may not be what you're going for, but being able to use a visual programming language on the DS itself would be cool, accompanied by sprite and music creation tools.
Hey, thanks so much for your interest and feedback!

I’m still in the early stages of planning the Bread syntax, but here’s the general idea I have so far:

Bread is designed to be simple and DSi-centric. Here’s an example of what a basic program might look like:

// Display "Hello, DSi!" on the top screen
screen.top.display("Hello, DSi!");

// Detect a tap on the touchscreen
touch.onTap((x, y) => {
screen.bottom.draw.circle(x, y, 10, "blue");
});

// Play a sound when a button is pressed
button.A.onPress(() => {
sound.play("beep");
});

But I am still on the works.
The goal is to make it feel intuitive, with commands that directly interact with the DSi’s hardware features like the touchscreen, buttons, and cameras.

On the other hand,
I absolutely love this idea! A visual programming interface on the DSi itself could make homebrew development accessible to even more people. Pairing that with sprite and music creation tools is brilliant—it would turn the DSi into a full-fledged development station.

It’s a bit ambitious, but definitely something I’d like to explore in the future. Maybe we could start with a Bread IDE for the DSi that supports basic code writing and debugging, and then evolve it into a visual system.

If you’re interested in helping shape Bread or have more ideas, let me know I’d love to collaborate or hear more about what you'd like to see!

Thanks again for the encouragement and great suggestion!
 
I had an idea very similar to this but for the 3ds. Hope you succeed!

I might think about trying to port bread to the 3ds with support for 3ds features if bread turns out good enough.
 
I had an idea very similar to this but for the 3ds. Hope you succeed!

I might think about trying to port bread to the 3ds with support for 3ds features if bread turns out good enough.
Perhaps we can make the programming language both DSi and 3DS? Come on abroad with me to create the Bread programming language!
 
Perhaps we can make the programming language both DSi and 3DS? Come on abroad! Do you have any experiences to C++ or DS game maker?
I barely understand basic C++ but I have programmed several thing for the 3ds with libctru.

I think it'd be best to program the bread interpreter in a way that wouldn't be ds dependent, and to have that instead call some platform specific library for graphics and input. (Hope that made sense)
 
I barely understand basic C++ but I have programmed several thing for the 3ds with libctru.

I think it'd be best to program the bread interpreter in a way that wouldn't be ds dependent, and to have that instead call some platform specific library for graphics and input. (Hope that made sense)
Ok then, feel free to message me if you have ideas for my programming language!
 
So I saw Ciro ask about syntax, but the response didn't describe much to me. Would bread be dynamically typed or static typed? Would it use {} for scope declaration or use tabs.

Also in your example, you used
Code:
screen.top.display("Hello, DSi!");
The following approaches might be more clean:

Code:
var target top_screen = target.create(screen.top)

print(top_screen, "Hello Breadbox")
OR

Code:
var target top_screen = target.create(screen.top)

target.set_target(top_screen)

print("Hello Breadbox")
 
So I saw Ciro ask about syntax, but the response didn't describe much to me. Would bread be dynamically typed or static typed? Would it use {} for scope declaration or use tabs.

Also in your example, you used
Code:
screen.top.display("Hello, DSi!");
The following approaches might be more clean:

Code:
var target top_screen = target.create(screen.top)

print(top_screen, "Hello Breadbox")
OR

Code:
var target top_screen = target.create(screen.top)

target.set_target(top_screen)

print("Hello Breadbox")
Well, that's what I'm thinking because I do know that it might be hard to type in all of the code by taping on the bottom screen. So I guess we keep it unknown but like I said, I'm still in development. It’s also an example so I don't know if it will look the same thing like this. It’s kind of like Python
Post automatically merged:

And the reason why I posted about my idea is because I can't so it myself. A programming language requires a lot of things, and I can't believe by myself to do all of this. And that's where you come! We can all make a programming language that is simple to make games on a DSi!
 
Last edited by BenHasADSi,
Well, that's what I'm thinking because I do know that it might be hard to type in all of the code by taping on the bottom screen. So I guess we keep it unknown but like I said, I'm still in development. It’s also an example so I don't know if it will look the same thing like this. It’s kind of like Python
Post automatically merged:

And the reason why I posted about my idea is because I can't so it myself. A programming language requires a lot of things, and I can't believe by myself to do all of this. And that's where you come! We can all make a programming language that is simple to make games on a DSi!
I'm not very good at writing programming languages, but I can help where I can. I'll think about syntax and other things related to the language itself.

As for typing on the ds: I think breadbox is enough even without being able to type on the ds itself. It'd make development of small games ten times easier. You could also later make a visual scripting language which breadbox compiles into bread.
 
I'm not very good at writing programming languages, but I can help where I can. I'll think about syntax and other things related to the language itself.

As for typing on the ds: I think breadbox is enough even without being able to type on the ds itself. It'd make development of small games ten times easier. You could also later make a visual scripting language which breadbox compiles into bread.
Ok! So breadbox is not a programming language or is it? Is it like the HShop kind of thing? Because you said later I can make a visual scripting language, right?
 
Some terminology I have in my head

Breadbox = The software that runs it
Bread = The language
Ok, so Breadbox is an emulator for the language Bread! If you want, we can talk about this more in my Discord server so we don't loose touch https://discord.gg/6Nn5YcQP
Post automatically merged:

By the way! This is the first screenshot of Bread! I copied the input examples from Devkitpro and used a little help from ChatGPT. The converting came out successfully, but the problem is that the keyboard (or the input) is corrupted! But at least I know what's working and what's not. Stay tuned for more tests and screenshots!
 

Attachments

  • download.png
    download.png
    60.5 KB · Views: 42
Last edited by BenHasADSi,
  • Like
Reactions: NotImpLife
Can't wait to see how the Bread programming language project turns out. In the meantime I'm doing parallel attempts to unify GBA, DS and possibly 3DS development into a single scripting language, so I know how sophisticated the entire process is.
 
Hiya! :) I just got a DS last week, thinking I'd finally start my operating system project. It's good to see a language in the planning stages too. I'm not sure I should give too many ideas though, because language ideas eekee [] [] IF [delete] popularity THEN ;) (That actually came out clearer than I thought it would.) I've been into Forth for a little while, but I'm getting tired of it now. The overly simple parser makes some things more complicated rather than less. The other languages I've been into in the last few years are a "plain English programming" compiler, (it basically compiles a sort of pseudocode,) and APL. I'm not really too keen on C-like syntaxes, but I guess >90% of programmers are.

I think it'd be best to program the bread interpreter in a way that wouldn't be ds dependent, and to have that instead call some platform specific library for graphics and input. (Hope that made sense)
I support this. The various DSs have a lot in common. They do have differences too, but maybe the differences can be handled at a library level, or by providing something like C's #ifdef.

So I saw Ciro ask about syntax, but the response didn't describe much to me. Would bread be dynamically typed or static typed? Would it use {} for scope declaration or use tabs.
I like it when you can rearrange source code to make its function clearer (when that helps), just to make it more readable (long expressions; functions with lots of parameters), and sometimes to fit more on the screen. {} and statements terminated with ; help with those goals. Instead of semicolons, it's just as good if statements end at the end of the line but lines can be joined with : or ; or whatever.

Also, syntactic indentation raises the eternal argument over tabs in which I think all sides are evil and there are no solutions. ;)
EDIT: This wouldn't be an issue if Bread has only a built-in text editor, but you always get people asking to use an external editor instead.


Also in your example, you used
Code:
screen.top.display("Hello, DSi!");
The following approaches might be more clean:

Code:
var target top_screen = target.create(screen.top)

print(top_screen, "Hello Breadbox")
OR

Code:
var target top_screen = target.create(screen.top)

target.set_target(top_screen)

print("Hello Breadbox")
This I don't get, so much. Why are we creating a screen? What does that do that can't reasonably be handled by the run-time? Are there situations where we might want to run without ever initializing one or both of the screens? I guess I could understand it better if it was the microphone, but I'd rather init than create. The compiler could work like Python where initialization can be handled on module import. Settings would have to be changeable after initialization. I like that, it lets me just work with the defaults when I'm new, then start messing around with settings later.

The sort of settings I'm thinking about include assigning the sole 3D engine in the DS to the upper or lower screen. Oh hey, if this is initialized to some default and may be changed later, Bread won't have to have different versions of the screen init functions for different machines.


Well, that's what I'm thinking because I do know that it might be hard to type in all of the code by taping on the bottom screen. So I guess we keep it unknown but like I said, I'm still in development. It’s also an example so I don't know if it will look the same thing like this. It’s kind of like Python
I'm going to use the buttons as a chording keyboard; combinations of buttons make keypresses. My first very rough draft of chording is to have 64 chords from just the 4-way and ABXY buttons without pressing more than 2 at once each side, and another 40 with the less comfortable 4 buttons at once on the ABXY side for a total of 104. L and R can be Shift and Control, though I'm not sure they'd be comfortable to use that way. Maybe some chords could use L and R instead of the respective pad on that side, making 21 additional chords.

One shortfall of a chording keyboard is that auto-repeat can't really work as it's best to wait until button release to recognize chords. A text editor might have to depend on tapping on the touchscreen for moving the cursor, or on search and features like move-paragraph (like Vim), or perhaps L or R could make it repeat the last chord.

Having said all that, back in 2001 before I'd heard of chording keyboards I got pretty quick at tapping away on my Palm Pilot's on-screen keyboard. It's so much better with a stylus than a finger. Not as quick as chording. It might be better than the side-of-thumb buttons on the later Sharp Zaurus models. I never did a direct comparison, but the Z's keyboard hurt my thumbs a bit when I tried to type a story. (The Z is held differently to a DS despite the similar form factor. It's because you have to reach keys in the middle and near the edge.)
 
Last edited by eekee,

Site & Scene News

Popular threads in this forum