#68041 - olimar - Sun Jan 22, 2006 4:32 am
Last edited by olimar on Wed Aug 20, 2008 10:08 pm; edited 1 time in total
#68053 - FireSlash - Sun Jan 22, 2006 6:16 am
Awesome. I can't wait to see how this evolves :)
_________________
FireSlash.net
#68057 - Normmatt - Sun Jan 22, 2006 6:34 am
Awesome news, i wanna see how this work out, hopefully someone comes along and adds everything everyone wants in a firmware .... i can wish.
#68058 - tepples - Sun Jan 22, 2006 6:43 am
Speaking of wish, I can't see how it would hurt to discuss what features one would one want in a new firmware: - Run GBA ROM in DS mode
- Run GBA ROM in GBA mode
- GBA ROM and SRAM hex viewer
- HTTP bootstrap in DS mode (once sgstair finishes TCP, DHCP, and DNS)
- Run official firmware that you have dumped and repacked
(I'll split it if necessary.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#68074 - caitsith2 - Sun Jan 22, 2006 8:34 am
DS game card music/sfx player. (all official games use the same nintendo sound library.) That would be nice for listening to music without playing the game.
This of course means someone is going to have to completely reverse engineer the nintendo sound library.
Things that should actually sit inside the first 64KBs of the firmware. (shorting SL1 is required to change this area.)
1. Boot DS game card.
2. Boot GBA ROM in DS mode. (flashme equivelent)
3. Boot GBA ROM in GBA mode, on user selected screen.
4. Wireless Multiboot (both signed and homebrew)
5. Change important DS settings.
a. Manual/Automatic mode
b. Language settings. (Don't need to have all 6 language translations of the interface present, just more so that the game that supports multiple languages run correctly.)
c. GBA mode screen
d. Date/Time settings
e. User color/Birthday/Nickname/Message
f. Touch screen calibration
g. Nintendo WFC settings/testing. (if enough room to implement this.)
More or less, all critical functions, so that is some malicious bricker is run on the DS, you can still use the DS without reflashing the firmware using the built in failsafe recovery code.
#68080 - GPFerror - Sun Jan 22, 2006 10:34 am
wireless gdb stub :)
#68081 - HyperHacker - Sun Jan 22, 2006 11:08 am
OK now that's pretty damn cool. Doesn't want to boot my MKDS cart when run over WMB though. (Just the firmware.nds, that is.)
Feature-wise, cool things to include would be:
-Calculator
-CF/SD card file browser, with simple abilities like renaming and deleting
-Notepad (using text files from CF/SD)
-Maybe a JPEG viewer and MP3 player to play files from CF/SD
-Ability to download and run .nds files from any wireless card
-Alarm clock (like the existing one)
-Unlike FlashMe, make it an option whether you want to automatically boot homebrew from the GBA cart or not.
-Transfer GBA/NDS saves to and from PC
-Ability to edit settings and such without having to shut down all the time
-Temperature display
-A few built-in borders to choose from for GBA games (save space by compressing them and just making the middle blank)
-Startup password
-Very first thing shown at bootup should be the name and icon of the currently-inserted NDS game, and the name and Nintendo logo from the GBA game. (This way if your cartridge is dusty, you can tell right away... it's a pain having to keep starting up and going to GBA mode to see if your GBA cart is clean yet.)
-If possible, keep the ARM9 on in GBA mode and/or hook into the ARM7 code, and do various cool things like having the option to toggle the backlight and switch screens during the game, maybe remap buttons, etc.
If there's enough space left (and I doubt there would be <_<):
-Emulators for old consoles (again using CF/SD)
-Simple web browser (maybe text-only)
-Day planner of some sort
Note that the things that require a CF/SD card could be stored on the card itself to save space.
#68084 - chishm - Sun Jan 22, 2006 11:44 am
A lot of these suggestions would be better off done with secondary programs stored on a GBA flash cart (or similar). For instance, emulators, calculators, datebooks, etc can be better done as a homebrew app.
All the firmware really needs is the ability to boot GBA carts, DS cards, and NDS files from the GBA slot; a way to alter the firmware settings; a WMB client and possibly an IP WMB client.
Since this is now out, maybe it could be put in CVS so people can work on different aspects.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#68096 - Ilomoga - Sun Jan 22, 2006 12:34 pm
Wow - great.
I can't boot DS games when starting the "firmware" via Wifime, too, but maybe that's because it's started via Wifime?
All the ideas for software implemented in the firmware are good, but chism is right - they should be loaded from GBA slot. For example that you flash the extended firmware image on a flash cart, the firmware recognizes it when it's inserted and offers more programs.
_________________
The future of gaming is mobile Handheld Gaming.
#68113 - JaJa - Sun Jan 22, 2006 4:48 pm
How about a modular firmware?
All critical functions (GBA loading, DS loading, homebrew loading) in the first 64kb, and an application that write firmware modules into the remaining space.
You could have media modules, web modules, etc.
That way people configure what ever they want.
Then people could write new bits for the firmware with less risk than if they have to write all or expand the firmware.
This also means new modules could be easily added/removed without shorting SL1.
There's no way we can have everything people want in the firmware (everything from GDB stubs to save transfers to emulators).
If it was modular Dev's could have SRAM viewers, GDB stubs, RAM viewers, Register viewers in firmware, whilst others could have web browsers and emulators.
Actually emulators and stuff are a dumb idea. You'd still need something in the GBA slot to store the ROMS's. Hmmm.
But address books and calculators are a good idea.
How about some WinDS features?
Features i'd like to see
- Easily Skinnable Firmware
- PDA style organiser/address book
#68114 - Xgame - Sun Jan 22, 2006 5:04 pm
but need sl1Bridge?
#68117 - CubeGuy - Sun Jan 22, 2006 5:40 pm
I think the most important thing may be the IPWMB. This would allow people who's DS's have been flashed to run homebrew without owning a flash cart or a ralink card.
_________________
It's 'CubeGuy.' One word. No space.
#68118 - MaHe - Sun Jan 22, 2006 6:10 pm
| CubeGuy wrote: |
| I think the most important thing may be the IPWMB. This would allow people who's DS's have been flashed to run homebrew without owning a flash cart or a ralink card. |
I think simply implementing Bafio's WiFi Transfer source code in this firmware should do the trick ... Right?
#68125 - Maverick - Sun Jan 22, 2006 7:18 pm
Id like to see this improved, mainly to include certain things in the protected sector like:
boot ds from ds slot
boot ds from gba slot
boot gba from gba slot
wireless multiboot
settings editor(including boot mode, language, gba screen, date, time, day, color, birthday, nickname, personal message, touchscreen, wfc)
password
FAT file viewer looking through firmware from 64K to end, gba slot, ds slot
and have everything else as files from 64k to end, or on a fat (cf/sd) card in gba or ds slot
_________________
http://downtou.ne1.net/
#68133 - Mr. Picklesworth - Sun Jan 22, 2006 7:39 pm
In order to fit all this, the firmware would need to be a minamalist, perhaps text-based, thing...
That wouldn't hurt, but... yah.
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896
#68139 - sajiimori - Sun Jan 22, 2006 8:02 pm
| Quote: |
| (all official games use the same nintendo sound library.) |
Many, not all. None of the games from my studio use it for music.
#68143 - Lazy1 - Sun Jan 22, 2006 8:36 pm
Feature idea:
A recovery option for bricked gba movie players?
#68183 - chishm - Mon Jan 23, 2006 12:47 am
After thinking about it some more, I figure what we need is a very simple boot menu (like it already is) in the first 64KB. All it needs is a settings editor and WMB client, but keep the text interface.
Then, before it loads the interface, it looks in the other 192KB for another menu. It loads this if it is available, otherwise it falls back on the simplistic menu.
The ARM7 binary could also be kept in the first 64KB, since it is unlikely to change once it is complete. That way, to customise the firmware, all that is needed is to change the ARM9 binary, which is little more than an interface anyway.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#68194 - Mr. Picklesworth - Mon Jan 23, 2006 1:31 am
I second the bricked GBAMP recovery idea. That's something that would only work on the firmware except in very rare circumstances. (Unlike, say, a media viewer).
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896
#68204 - Joat - Mon Jan 23, 2006 2:27 am
Talked about this stuff on IRC already, but a couple of other suggestions / comments (and yah, I'll throw my hat in eventually as well)
Don't worry about the lack of space yet, make your firmware run in the high space for now, and by the time you're running out space, hopefully the wifi lib will be in substantially finished state, so a common arm7 bin can be committed to low firmware. Until then, putting a (frequently) changing arm7 bin in low firmware will require several sl1 flashes as updates are made, which risks the chance of someone bricking their DS each time.
Make sure to respect the required firmware settings spaces (www.bottledlight.com/ds/index.php/Main/Firmware), basically 0x03FA00 and up, and the wifi settings, etc... in low rom (not an issue if you don't mess with the first 64 KB for now).
I also propose a common format for extended settings, so people can try out different firmwares without having to back up / restore the extra data.
Say, an extra 1 or 4 KB of data below 0x03FA00 in a chunked format, something like:
<author-type> <length> <length bytes of data> <crc-16 over rest of data>
That only wastes 4 bytes above and beyond the data contained (assuming length is a byte), and if we somehow magically get more than 255 people writing unique firmware projects, can just reserve 255 as an extended tag, with the real author inside the data payload, etc...
This would let say, a common plugin used in different people's firmwares share the same config data, e.g. an ip address to grab UDP data from.
Just my 2 cents, etc...
Let me know what you think, and since it was my idea, I reserve author-id 42 and 0x42 :)
_________________
Joat
http://www.bottledlight.com
#68213 - HyperHacker - Mon Jan 23, 2006 2:57 am
Is an author byte necessary? (And if it is, 16-bit would pretty much prevent the too-many-developers issue. In that case I call 0x4848. ;))
| chishm wrote: |
A lot of these suggestions would be better off done with secondary programs stored on a GBA flash cart (or similar). For instance, emulators, calculators, datebooks, etc can be better done as a homebrew app.
All the firmware really needs is the ability to boot GBA carts, DS cards, and NDS files from the GBA slot; a way to alter the firmware settings; a WMB client and possibly an IP WMB client. |
Yes, but if you have the free space left over once those are in, why not add things? :p
| Lazy1 wrote: |
Feature idea:
A recovery option for bricked gba movie players? |
Can't you do this via WMB?
#68219 - Lynx - Mon Jan 23, 2006 3:07 am
Wow.. what the hell.. why don't we put WindowCE in the firmware while we are at it? Or, can we put MoonShell in the firmware.. or make is to my DS only plays PicrossDS, and let's put that in the firmware..
or not..
#68226 - Joat - Mon Jan 23, 2006 3:30 am
Yes, the author byte or another type field is very much necessary (if it's not outside of the <length> bytes of data, it has to be inside of it, so that a particular plugin or firmware can find the config setting it's looking for). If you instead put stuff at a known hardcoded location depending on the data (like the color settings are done in the existing firmware), you lose any benefit of having tagged data (it's not tagged).
Re: length field. Was just trying to minimize the perceived impact of wasted space. You've got a lot of options for the fields, such as DWARF-type numbers (7 bits in 1 byte, 15 bits in 2, etc... for arbitrary length), or just burn 2 bytes off the bat for author / length (no need for 3 or 4, the entire firmware is only 4x64 KB)
If we standardize on plugins (probably too early for this, but the main issue with plugins will be a menu-display name, a arm9 load address, and a length), we could just use the entire 192 KB-end settings worth of firmware to store chunks, where one author/type field would indicate a menu plugin, another the settings for that plugin, etc...
Would be good for auto-discovery, the 'firmware-builder' would just pick and choose plugins until they'd used up the free space, and write them to firmware (could even have a CF aware program that lets anyone choose which parts they want in firmware, and loads the plugins from files). No need for a seperate table or anything, scanning 192 KB is nigh-on-instant.
Anyways, going back to that, hmm:
c/d bit, 15 bits of author/type tag, 8 or 16 bits for data sections to denote byte length, 16 bits for code sections to denote word length, then data, then crc of some sort over rest of chunk.
I (weakly) advocate a crc-32 for code, since crc-16 is so weak, but crc-16 doesn't cost any space, while a slow crc32 costs a tiny bit of code, and a fast crc32 costs more than a KB of table, plus code (minor concern compared to what newlib eats, I know, but still).
And if we're doing 15/16 bits of author/type, I call 0xC0DE for the plugin type format.
_________________
Joat
http://www.bottledlight.com
#68275 - tssf - Mon Jan 23, 2006 12:43 pm
I want my firmware to make toast, wash my dishes, and bathe me.
In reality, the only essential features are the ones that Nintendo already includes, plus a few homebrewn-dependant things like maybe Internet, and maybe some form of integration with flashcards and/or compact flash/SD cards.
A feature I'd like to see is a built-in CF reader, so I don't have to worry about _Boot_MP.NDS all the time.
It'd probably make more sense to include most of these suggestions people are making in an application that might work separate, but still with the firmware.
_________________
Mathew Valente [TSSF]
------
Chrono Resurrection Musician
#68280 - Darkflame - Mon Jan 23, 2006 2:03 pm
Indeed.
The ability to boot anything in the easiet possible way is #1
Then maybe the ability for the most flexible wifi system is at #2
The only real app Id like built in would be purhapes a messenger app of some sort. Picochat over wi-fi kinda thing.
#68286 - ethoscapade - Mon Jan 23, 2006 3:16 pm
we don't need any integrated apps or anything. just a more homebrew-conscious boot menu.
(well, i see you've got meteos in your DS, you could play that, or hey! is that nesDS on your supercard? well, why not access that right from the main boot menu too?)
also for chrissakes add a setting for BA/YB switch for GBA games
#68308 - lockwood - Mon Jan 23, 2006 6:31 pm
As we know the firmare has only 256kb size.
So we can make a big firmware when we let it boot from a sd card or somone wants to make an external firmware chip on the passme with a size of 5mb.
just dreams
#68313 - Extreme Coder - Mon Jan 23, 2006 7:40 pm
Now, it would be nice if you could do a flashme sort of thing but for the mk2/3, so that you could copy the menu to its rom on the mk2/3 and boot from it. I guess it isn't THAT hard...
#68320 - olimar - Mon Jan 23, 2006 8:20 pm
Last edited by olimar on Wed Aug 20, 2008 10:08 pm; edited 1 time in total
#68321 - olimar - Mon Jan 23, 2006 8:23 pm
Last edited by olimar on Wed Aug 20, 2008 10:09 pm; edited 1 time in total
#68335 - IxthusTiger - Mon Jan 23, 2006 9:35 pm
| olimar wrote: |
| ethoscapade wrote: | | also for chrissakes add a setting for BA/YB switch for GBA games |
You might as well ask for the firmware to add more buttons too.
Can't be done. It's a hardware issue, not software. |
Oh yeah, that reminds me!
More buttons please. :)
#68341 - olimar - Mon Jan 23, 2006 9:58 pm
Last edited by olimar on Wed Aug 20, 2008 10:10 pm; edited 1 time in total
#68349 - tssf - Mon Jan 23, 2006 10:39 pm
That would be kind of a neat idea, actually. Applying IPS patches to Nintendo DS games before the game started..would make the cheaters much happier.
But what I'd really like to see is a firmware that has a sleek, 3D-based interface.
Imagine a Gamecube-like firmware for the DS? That'd be cool. Maybe integrate Nintendo WFC configuration right into it, as well. Pop in CF/SD drivers, and make them automatically load say, "Firmware-enhanced.nds" or "ds.gba" for other cards, and voila, instant enhanced-extended firmware. Maybe have a boot loader, or a whole suite of tools all in one package..make all the programs rebootable to the firmware (a soft-reset maybe?), etc.
A quick question. What is MK 2/3?
_________________
Mathew Valente [TSSF]
------
Chrono Resurrection Musician
#68351 - olimar - Mon Jan 23, 2006 10:48 pm
Last edited by olimar on Wed Aug 20, 2008 10:09 pm; edited 1 time in total
#68376 - Lynx - Tue Jan 24, 2006 2:53 am
Heck, if you can make it secure and trustable, have it pull the .ips files from a server (or mirror servers) on the internet.
#68888 - Extreme Coder - Fri Jan 27, 2006 7:14 am
| olimar wrote: |
| Extreme Coder wrote: | | Now, it would be nice if you could do a flashme sort of thing but for the mk2/3, so that you could copy the menu to its rom on the mk2/3 and boot from it. I guess it isn't THAT hard... |
Working on that now, as a matter of fact. :) |
OMG, loopy, that rocks!:P Just say the word on any updates:D
#68966 - MaHe - Fri Jan 27, 2006 5:42 pm
Hey, we can't have everything ... We should include only minor but useful stuff in the firmware, not the whole pack of junk, you can use GBA cartridges for that. My favorites:
- WFC settings editor (El Hobito's project looks promising, although it should be stripped to fit in FW)
- Ability to change health-screen text
- IP-WMB (WMB via WiFi, shouldn't be really hard since we've got the source from Bafio - it'd work great by implementing it to work in "harmony" with NiFi WMB)
That's all really great stuff that almost NEED to be implemented :).
Anything else - simply use a flashcart ... :)
#68971 - ghazi - Fri Jan 27, 2006 6:19 pm
This is slightly off topic, but have any of the hardware people found any kind of voltmeter on the DS such that we could tap into to implement a better battery status indicator?
I mean, the one in the firmware looks so good, but then all it does is change at 33% battery? You'd think there'd be a way.
#69001 - HyperHacker - Fri Jan 27, 2006 10:19 pm
I noticed in the GBATek document that VREF used for the touch screen drops from 3.33V to 3.1V as the battery gets weaker, perhaps this could have some measurable effect on input.
Also, while the firmware should be minimal, it could act as a simple shell, listing any .nds (and maybe .mb.gba) files it finds on the CF card (even just in the root or \firmware or some such) in addition to the built-in things. This would give the illusion that these things are built in, and the ability to start them right away without loading another shell first.
Also GBATek states that most newer DSes have 512K. Anyone know a way to see which you have? (It also mentions work on a customized firmware, but it requires a cable to be soldered to your DS and doesn't have WMB. It uses 8 of the buttons for data input, very clever.)
[edit] Forgot to mention 2 features that oughta be in it:
1) Ability to change "no GBA cart inserted" text. Useful for identifying a lost or stolen DS; just put your name in it. (Or if we're not trying to look like Nintendo's firmware, just a user-specified string displayed somewhere.)
2) Simple calculator. It already has a calendar and notepad (write in Pictochat and put to sleep until you get to a PC/pen and paper; the battery lasts for ages in sleep mode), so why not?
Last edited by HyperHacker on Sun Feb 05, 2006 4:31 am; edited 1 time in total
#70104 - tssf - Sat Feb 04, 2006 9:55 am
has any new progress been made on this project? :)
_________________
Mathew Valente [TSSF]
------
Chrono Resurrection Musician
#70270 - HyperHacker - Sun Feb 05, 2006 5:18 am
I'd like to know too. If it's no longer in development I may try making my own, but I'd hate to start working on one only to see someone else make a better one. (Even if mine was better, having two just means more compatibility issues.)
#70273 - olimar - Sun Feb 05, 2006 5:28 am
Last edited by olimar on Wed Aug 20, 2008 10:10 pm; edited 1 time in total
#70742 - Mc Nasty - Wed Feb 08, 2006 2:32 pm
Serious possible (since you don't plan to continue with the project) that taught us where we can change the yokels of the original firmware for "to Personalize" the firmware of our NDS's?
It interests me the topic but you grieve I am filling with knowledge and I still lack a lot that to learn
if they want it I can give them an idea of what I attempt with some images but unfortunately alone that can make
http://i12.photobucket.com/albums/a226/Mc_Nasty/Picto.jpg
But it would serve from idea to see if somebody could make something ace (Only they modified the colors of the structures but although alone aesthetic it changes enough their style)
Escuse my english but Im don't speak
#70859 - Joat - Thu Feb 09, 2006 4:03 am
A quick note for anyone working on a hbfirmware branch. The linkscript fw_arm9.ld needs to be modified:
add
<tab><tab>*(.bss)
just before
<tab><tab>*(COMMON)
in the section
.bss __bss_lma : AT (__bss_lma)
(around line 165)
<tab> == tab character. like makefiles, ld scripts want their tabs.
Loopy is going to change the version on his website presumably, but otherwise, bss doesn't get zeroed properly, and all sorts of bad things may happen (like intermittent lockups on memory allocation).
Fun times trying to figure out what was wrong... Thanks to wintermute for the fix (though we might could blame him for writing the linkscript modified by loopy too :D).
Also, gba borders are neat if pointless :D
_________________
Joat
http://www.bottledlight.com
#70878 - LiraNuna - Thu Feb 09, 2006 6:35 am
I'm planning on a screensaver firmware - sets up a key inturrapt before running a game :)
Only an idea (for now) but i might get on it soon
#70930 - Nushio - Thu Feb 09, 2006 4:21 pm
What I was pondering last night is if simple text could be Replaced.
When the NDS loads, the pesky Health and Safety could be replaced with (Example)
Nushio's DS Instead of the "Health and Safety" banner and instead of the other text, some other message.
I'd also like to change a lot of other stuff, like replacing the Insert GBA Gamepak as was suggested above.
If possible, to change the sound when it loads, and to change the alarm.
I'd like to replace it with some sexy female voice saying "Welcome..." when it loads, and instead of the alarm, same voice saying "Wake up Honey..."
One can dream, I'm sure. I'm pretty sure all of the voices wont fit in the firmware space, but what about the text? :D
#70979 - caitsith2 - Thu Feb 09, 2006 9:14 pm
The text change should be possible. The text is stored in part 5 of the firmware. I still have to work out a compresser for parts 3-5 though. (I have a decompressor for those parts).
#71012 - Nushio - Fri Feb 10, 2006 12:07 am
| caitsith2 wrote: |
| The text change should be possible. The text is stored in part 5 of the firmware. I still have to work out a compresser for parts 3-5 though. (I have a decompressor for those parts). |
Thats nice to hear and know, keep us up to date please, I'm sure everyone will start using customized Firmware after this!
#71047 - HyperHacker - Fri Feb 10, 2006 3:23 am
| LiraNuna wrote: |
I'm planning on a screensaver firmware - sets up a key inturrapt before running a game :)
Only an idea (for now) but i might get on it soon |
The problem with just setting your interrupt handler before running the game is what if the game sets it to something else?
#71096 - josath - Fri Feb 10, 2006 9:39 am
| HyperHacker wrote: |
| LiraNuna wrote: | I'm planning on a screensaver firmware - sets up a key inturrapt before running a game :)
Only an idea (for now) but i might get on it soon |
The problem with just setting your interrupt handler before running the game is what if the game sets it to something else? |
Scan the game binary before jumping to it / starting it, and patch any place that tries to overwrite your interrupt handler?
#71099 - LiraNuna - Fri Feb 10, 2006 10:49 am
Well, i don't know what games might use the keypad interrupt... but it will still work for some...
#71185 - zzo38computer - Fri Feb 10, 2006 9:22 pm
I am going to create a new firmware based on this.
| Code: |
LOAD NITRO FROM CARD
LOAD NITRO FROM GBA
LOAD NITRO FROM HTTP
LOAD GBA
TERMINAL
MEM DUMP
OPTION
POWER OFF
|
Press arrow up/down to move cursor then press SELECT. Press L to swap displays. Press START to auto-detect card and start game. The HTTP and TERMINAL option will not work if I don't have a code used to connect to Internet with.
There may be many different firmware, but the software should always work no matter what firmware is installed. OK?
#71186 - tepples - Fri Feb 10, 2006 9:37 pm
Until sgstair gets TCP working, could we use TFTP instead?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#71188 - zzo38computer - Fri Feb 10, 2006 9:42 pm
Maybe I could use TFTP instead, until TCP works. But probably the first version of this program the LOAD NITRO FROM HTTP and TERMINAL options will not work. Maybe it will be LOAD NITRO FROM TFTP until TCP works. Maybe TERMINAL option will not be in there
#71206 - ghazi - Fri Feb 10, 2006 11:54 pm
I know nobody's thinking about it anymore, and I apologize for going back off-topic again, but this article was absolutely enlightening in a nerdy sort of way.
After reading that, I no longer believe that incredibly accurate battery readings are practical on the DS.
I was thinking a percent-rating would be possible, but it's most likely not. I do think that, if we could tap into some internal voltmeter on the DS (which it certainly has, since the DS knows when the battery is getting low), we could do some data gathering and maybe add a somewhat more accurate block-style rating to the battery indicator (like what you see on most cell phones).
If I get bored later, maybe I'll look into what it'd take to get a very simple program to spit out a voltage reading. I'm an IE, though, so hardware and programming isn't really my cup of tea.
#71698 - Joat - Tue Feb 14, 2006 1:20 am
A couple of things:
- hbfirmware isn't a single project. Loopy released an example of how to make a homebrew firmware, and coders are running with it from there.
- hbfirmware is *not* a hack of the existing firmware, it's a rewrite from the ground up (so asking for changing text, etc... of the original firmware isn't really on topic, see the monster thread on customizing the firmware or somesuch).
- If you do want to add more hacks to the existing firmware, you'll need to cut some features (total pain in the ass, and dramatically reduces the benefits of keeping the old firmware as a basis) or use better compression on parts 3-5 (and hack the loading code), there is almost no free space left in the original firmware.
- For whatever reason (probably because mere voltage level isn't a very good indicator, and possibly because they're crackheads), Nintendo didn't wire up the battery level input on the TSC. Instead, the firmware polls a single high/low level bit in on the PM, which is why there isn't a better level indicator in the stock firmware (there isn't anything better to measure). Could play about with trying to measure the external Vref they used, and callibrating it over a discharge, but again, voltage is not a particularly reliable indicator of remaining charge (and the callibration will change as your battery ages, etc...)
- Also, not really on topic, but the FCC pictures of the DS lite showed a ST 256 KB spi flash, so the DS lite firmware isn't any bigger either (granted, there are zero guarantees that it wouldn't ship with a 512 KB flash, since the pinout and comms protocol are identical). Looks like the battery indicator in the manual is the same as it used to be too, so no new bits in the PM or an alternative method of measuring, meh.
- Haven't messed with it near the boundary, but since the LED light flickers as power rises / drops near the boundary, the PM battery level bit might also toggle on and off, so you could do a sample N times in a period T, so you get 3 levels instead of 2 :D (high/regular/medium, very narrow band of not-quite-low, and low). Really not worth the effort, but I'm throwing it out there.
zz0, what do you mean by TERMINAL?
LiraNuna, the DS itself doesn't have a table of interrupts, just the one irq exception vector per CPU (which the bioses then redirect to the user handler address stored in ITCM or 0x03000000 RAM). The table is an added construct of libnds (or pretty much any other gba/ds library that does more than define registers, though where they store it will be different). So, you will need to patch the startup binaries of a commercial game (which will also involve decompression/recompression for many of them). It's doable, but it is nowhere near as easy as just sticking a bit of code somewhere in fairly unused memory and writing to an interrupt table before branching to the real binaries (also, gimme your gfxer ^_^).
_________________
Joat
http://www.bottledlight.com
#71705 - tepples - Tue Feb 14, 2006 1:43 am
I assume that a TERMINAL might be a telnet or ssh implementation, either in or out.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#71723 - Darkflame - Tue Feb 14, 2006 2:54 am
how about some of the features in this:
http://forum.gbadev.org/viewtopic.php?t=8522&postdays=0&postorder=asc&start=0
?
That is, more options when loading a GBA game.
#71735 - ghazi - Tue Feb 14, 2006 4:24 am
Thanks for clearing that up, Joat.
1, 2 and 3 I pretty much had down, but I didn't realize that the DS was made that way (although the lack of a more accurate readout absolutely makes more sense that way). If it was that simple, they'd have already done it, huh?
In my mind, I had already made the assumption that a voltage could be easily read and was already looking forward to setting up a statistical analysis to find a more accurate measure of charge (taking other factors such as temperature and maybe even age into account).
Adding anything like that directly to the firmware was pretty far outside of what I had planned for the near future, but I thought it might be a neat little homebrew app to have a somewhat more accurate readout.
I guess I'll find something else to go all statistics crazy about (or get back to this simulation project)! =)
Last edited by ghazi on Tue Feb 14, 2006 9:03 am; edited 1 time in total
#71746 - zzo38computer - Tue Feb 14, 2006 6:01 am
Yes, TERMINAL was supposed to be a telnet implementation, but I probably will not add the TERMINAL, I think I changed my mind. Also, will be option menu to change user configuration. I will continue adding more stuff whenever I have more ideas/codes to do it. But before I work on it at all, I need a PassMe2 card (I will get one soon). I was thinking of adding a LOAD GBC option with Goomba emulator built in to firmware if the GBC card could fit into the DS when filed, but now I know that won't work, it is of no use adding the emulator build in to the firmware.
#71812 - zzo38computer - Tue Feb 14, 2006 5:41 pm
I will also change it you press SELECT instead of A and B to select item, START will auto-start instead of memdump, and memdump will be made into a menu option, and there will be a PROGRAMMING MODE to enter commands to change memory and other modes things. Don't use thing in PROGRAMMING MODE that you don't know, it might ruin it
Do you need to add Wifi code to the firmware to make games with WFC work correctly?
#71905 - The 9th Sage - Wed Feb 15, 2006 7:42 am
| zzo38computer wrote: |
Do you need to add Wifi code to the firmware to make games with WFC work correctly? |
That's built into the games on a per game basis...that's why some support it and others don't.
_________________
Now with 20% More Old Man from Zelda 1 than ever before!
#71998 - zzo38computer - Wed Feb 15, 2006 9:58 pm
I think I will call it FWNITRO firmware. There are all the plans so far:
- Based on firmware code in this topic (very good! Now I know how to make firmware on DS!)
- On a menu, move cursor up/down by pressing UP/DOWN arrows, then press SELECT to select it. Press START to exit a menu, or on main menu, pressing START auto-detects a DS game or GBA game and start it automatically.
- Support most important features
- Date/time will be displayed on one display, menu on other display.
- Programming mode, lets you enter simple programs and store them on GBA cartridges.
Menus: (Note: Information in {} is help information, not displayed on menu.)
| Code: |
* MAIN MENU:
LOAD NITRO FROM CARD {load a DS game from the card slot}
LOAD NITRO FROM GBA {Passme}
LOAD NITRO FROM HTTP {type URL, download and run DS game}
LOAD GBA {load GameBoy Advance game from GBA cartridge}
DOWNLOAD {play DS download play}
PROGRAMMING MODE
MEM DUMP
CONFIGURATION {set options}
POWER OFF {power off}
* CONFIGURATION MENU:
(BACK)
WIFI 1 {set Wifi configuration #1}
WIFI 2
WIFI 3
USER PREF 1 {set user preferences}
USER PREF 2 {more user preferences}
* WIFI CONFIGURATION MENU:
(BACK)
AUTO {automatically detect}
SSID
WEP KEY
IP ADDRESS
GATEWAY
DNS1 {primary DNS}
DNS2 {secondary DNS}
SUBNET MASK
* USER PREF 1 MENU:
(BACK)
VERSION {0-255}
FAV COLOR {0-15}
BIRTH MONTH {0-12, zero=none}
BIRTH DAY {0-31, zero=none}
NAME {type in your name}
MESSAGE {type user message}
* USER PREF 2 MENU:
(BACK)
ALARM HOUR {set alarm}
ALARM MIN {set alarm}
ALARM ENABLE {set alarm}
LANGUAGE {0-7}
GBA SCREEN {0-1}
AUTO START {0-1}
CLOCK SET {set date/time}
CALIBRATION {calibrate touch screen}
|
#72023 - Raziel Fireeye - Thu Feb 16, 2006 12:59 am
It will be cool a desktop style where the firmware let you to add direct access icons to homebrew apps in the CF/SD/Flashcarts. The info of each icons will be stored on the flashcart/cf/sd. Is a cool idea for instant access to aps/games/etc...
Something like that ...
[Images not permitted - Click here to view it]
On the top Screen some info about the selected app/game/etc.. and the actions that user can do.
The icons on the touch screen to use stylus to run quickly the aps.
If the user adds so many icons mayby L / R shoulders can be use to scroll desktop to add more icons or show the hiddens icons
(PD: Sorry my english)
#72054 - CubeGuy - Thu Feb 16, 2006 4:32 am
That's exactly what I've been thinking, but too lazy to make a mockup.
_________________
It's 'CubeGuy.' One word. No space.
#72066 - zzo38computer - Thu Feb 16, 2006 5:36 am
Well, there may be many different firmware to choose from, FWNITRO (mine, based on the firmware at the start of this topic, which could be called FW-Minimal) is just one of them. You could choose firmware depending on what you want, for example, a text-only screen with advanced options, a desktop-style screen with icons, or the default Nintendo firmware.
#100745 - Gneisbaard - Wed Aug 30, 2006 7:57 am
the installer seems to include the key table from the bios. Is this legal?
#101854 - pas - Fri Sep 08, 2006 12:55 pm
The best I could think of would be:
The normla Firmware with:
All Flashme can do (boot NDScode from Gbaslot, Failsafefeature...)
A Integratet Webbrowser (like the PSP one) This would be good because it would take nearly no space up in the 4 MB Internall Ram
And a Option to edit the Nintendo Wifi Connections Settings in the DS.
Greets:
Pas
#101855 - dualscreenman - Fri Sep 08, 2006 1:13 pm
We have a space problemw with the firmware. Adding on to the original firmware is hard.
Plus:
-Nobody has even made a standalone browser, try getting one to fit in 256 kb
_________________
| dualscreenman wrote: |
| What about Gaim DS? Gaim pretty much has support for all IM programs. |
| tepples wrote: |
| "Goshdammit, the DS is not a Gaim-boy! It's a third pillar!" |
![[Images not permitted - Click here to view it]](http://img479.imageshack.us/img479/5835/firmwaresample9pl.jpg){kind=link}