Gathering DS flashcard knowledge - DIY "opencard" idea

lifehackerhansol

i write working(?) code
Member
Joined
Oct 2, 2021
Messages
468
Trophies
0
XP
1,424
Country
Canada
Does this mean that a flashcards kernel (kernel, not firmware) is in essence a ".nds" program like any other, that is specialized in starting / transferring other ROMs from the flashcards (SD or other) memory to the DS memory?
All flashcarts boot a certain file off the SD card. Almost always, it's just a homebrew `.nds` file, which may or may not be encrypted (original R4, or any timebombed carts out there). The exception to this `.nds` file is the M3 line of carts, which uses a different type of header for whatever reason.
e.g. could nds-hb-menu be seen as a "kernel" and could a flashcard simply transfer nds-hb-menu to the DS's memory as a "kernel"?

I got a bit confused on this topic because all flashcards basically have some cluttered mess of .dat files or __rpg folders that represent the "kernel".
Yes, nds-hb-menu can be a "kernel". The word itself doesn't mean much. There's going to be a specific file on the SD card (with some random extension like .dat or whatever), but that file is normally just an NDS file. It may be encrypted in some form (original R4 or timebombed cart).

That said, the real meaning of a "kernel" is that it is able to utilize the cartridge hardware to, you guessed it, load ROMs off the SD card. Some carts have special hardware, and the kernel patches the game in memory to make use of this and enable compatibility of running it off an SD card as opposed to a traditional flash chip.

But generally speaking, anything can be made a kernel if you can build any homebrew NDS file, DLDI patch it, and rename it to the file name that the cartridge expects. That way, instead of having to update the cartridge every single time, you can just update this .nds file and get easier compatibility updates.
Why are no flashcards doing it this way (e.g. using .dat files or having a cluttered combination of many files represent the kernel). Is this only for obfuscation or is there some major step in kernel to DS communication that I haven't picked up on yet?
All flashcarts do it this way, with minor obfuscations that are mostly defeated. The "dat" file you speak of is just a homebrew NDS file. You can see my personal project where I aim to replace the kernel with a standardized loader here: https://github.com/lifehackerhansol/flashcard-bootstrap. You'll probably find "devnotes.txt" useful. I've found that several just needed memory address adjustments but are otherwise standard stuff.

Of course, there are some carts that are different, for example the M3 line of carts have a totally different structure in their boot file and I have to end up manually patching some things so it loads my NDS file.
I have been browsing through DLDI repositories now.

I understand the principle of DLDI - it acts as a uniform bridge between binary and memory, allowing device manufacturers to implement a device specific codeset while homebrew developers can use a unified interface without having to worry about the hardware.

I do however have a hard time understanding how that code in the DLDI template file achieves said communication with the memory (most likely SD Card) hardware. I assume this also passes throught the FPGA but how?
You can see https://github.com/DS-Homebrew/DLDI. (well nowadays instead of being DS-Homebrew it's my personal playground lol).

In most cases, actual SD card read/write is generally handled in the flashcart internally (via the FPGA or whatever the case). Each flashcart exposes a few set of CARD_COMMANDs (defined in card.h as REG_CARD_COMMAND). We then utilize these commands in the DLDI to send cartridge commands to the flashcart. Think of REG_CARD_COMMAND as an API of sorts, and all flashcarts do it a bit differently. Then, whatever controller in the flashcart hardware reads these commands, and then transfers data via REG_CARD_DATA_RD register.

In most cases I've seen, for example reading from the SD, the cartridge would send a command to the SD card containing the address of the SD card it wishes to read. We then wait for the cartridge to ACK this, and then we send a command that starts the raw read, and we get data via REG_CARD_DATA_RD. Then we loop it for as many sectors as necessary. Some add a checksum to the data, which is slightly overkill but I digress.

That being said, I purely work on the DLDI side of things, and I don't really know what goes on internally. So I can't give a straight answer on that side of things.
 

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
All flashcarts boot a certain file off the SD card. Almost always, it's just a homebrew `.nds` file, which may or may not be encrypted (original R4, or any timebombed carts out there). The exception to this `.nds` file is the M3 line of carts, which uses a different type of header for whatever reason.

Yes, nds-hb-menu can be a "kernel". The word itself doesn't mean much. There's going to be a specific file on the SD card (with some random extension like .dat or whatever), but that file is normally just an NDS file. It may be encrypted in some form (original R4 or timebombed cart).

That said, the real meaning of a "kernel" is that it is able to utilize the cartridge hardware to, you guessed it, load ROMs off the SD card. Some carts have special hardware, and the kernel patches the game in memory to make use of this and enable compatibility of running it off an SD card as opposed to a traditional flash chip.

But generally speaking, anything can be made a kernel if you can build any homebrew NDS file, DLDI patch it, and rename it to the file name that the cartridge expects. That way, instead of having to update the cartridge every single time, you can just update this .nds file and get easier compatibility updates.

All flashcarts do it this way, with minor obfuscations that are mostly defeated. The "dat" file you speak of is just a homebrew NDS file. You can see my personal project where I aim to replace the kernel with a standardized loader here: https://github.com/lifehackerhansol/flashcard-bootstrap. You'll probably find "devnotes.txt" useful. I've found that several just needed memory address adjustments but are otherwise standard stuff.

Of course, there are some carts that are different, for example the M3 line of carts have a totally different structure in their boot file and I have to end up manually patching some things so it loads my NDS file.

You can see https://github.com/DS-Homebrew/DLDI. (well nowadays instead of being DS-Homebrew it's my personal playground lol).

In most cases, actual SD card read/write is generally handled in the flashcart internally (via the FPGA or whatever the case). Each flashcart exposes a few set of CARD_COMMANDs (defined in card.h as REG_CARD_COMMAND). We then utilize these commands in the DLDI to send cartridge commands to the flashcart. Think of REG_CARD_COMMAND as an API of sorts, and all flashcarts do it a bit differently. Then, whatever controller in the flashcart hardware reads these commands, and then transfers data via REG_CARD_DATA_RD register.

In most cases I've seen, for example reading from the SD, the cartridge would send a command to the SD card containing the address of the SD card it wishes to read. We then wait for the cartridge to ACK this, and then we send a command that starts the raw read, and we get data via REG_CARD_DATA_RD. Then we loop it for as many sectors as necessary. Some add a checksum to the data, which is slightly overkill but I digress.

That being said, I purely work on the DLDI side of things, and I don't really know what goes on internally. So I can't give a straight answer on that side of things.
Thanks! That does clear up my mental image. As a matter of fact, it seems I was already browsing that same repository you mentioned :P.

I'm starting to see how data is being pulled from the SD card. I just still have somewhat of a hard time imagining the complete picture. How does the kernel that gets eventually loaded into the DS's memory "pipe" data through the flashcard? Because, as far as I understand it, the access to the SD card can't just be mapped 1:1 to running code on the DS. I can't even really formulate my question on this topic properly so there's still some key pieces I'm missing. ** Edit **: I was either blind or just confused, re-reading your message clears up quite a bit of the SD card stuff. I mainly still struggle with the "DS To Flashcart To SD" part. Is this a good representation of the flow or am I missing key parts (high-level of course)?

flow-flashcard.png



Since I'm typing my reply anyways I'm going to add another question :). Do you happen to know how the "bootloader" setup would be implemented on flashcards? I mean step 3 of this process:
How it usually works:

1. The DS firmware initializes the ROM and encrypted communication. The flashcard pretends to be a game and delivers legit looking data.
2. The firmware reads headers, executables and overlays. The flashcard will at some point deliver modified data/code in form of executables or overlays instead of the game data it pretends to be. Sometimes vulnerabilities are used in the overlay handling of the firmware.
3. The firmware executes the loaded executables and this is where the loader for the "kernel" kicks in. It initializes the microSD card and loads + deobfuscates whatever .dat file the kernel uses from the root of the microSD filesystem.
4. The "kernel" takes over and you will see the menu to select games.
5. If you select a game the "kernel" loads and deobfuscates the ROM loader, passes it some config options and executes it.
6. The ROM loader loads the games executables, overlays and then applies patches so it can read from the microSD via a cluster lookup table. The same is done for savegame read/write. This cluster lookup table is sometimes implemented on the FPGA so the ROM loader just needs to fill it.
7. The game runs.

It really is just a big chain of stages of executables. Often just .nds files with or without obfuscation.
That is a key part of the flow it seems and before @ghjfdtg mentioned it I didn't even know it was a thing so any information I can get about the subject is welcome!
 
Last edited by xbmbmx,

metroid maniac

An idiot with an opinion
Member
Joined
May 16, 2009
Messages
2,068
Trophies
2
XP
2,575
Country
I'm starting to see how data is being pulled from the SD card. I just still have somewhat of a hard time imagining the complete picture. How does the kernel that gets eventually loaded into the DS's memory "pipe" data through the flashcard? Because, as far as I understand it, the access to the SD card can't just be mapped 1:1 to running code on the DS. I can't even really formulate my question on this topic properly so there's still some key pieces I'm missing.
Since I'm typing my reply anyways I'm going to add another question :). Do you happen to know how the "bootloader" setup would be implemented on flashcards? I mean step 3 of this process:
Like lifehackerhansol said, the flashcard FPGA provides a set of extra commands which allow access to the SD card. These provide high level sector access to the SD card. Just send data, the sector address, a command byte and it will read or write the SD card there. The FPGA takes care of the serial communication with the SD card.

At boot, the flashcart functions like an official cart, except the ROM contained is the bootloader instead of a game. The DS firmware runs it the same way it loads a game. The bootloader can use the previously mentioned SD commands to load and run the kernel from the SD card. The kernel can also use those commands for general file IO or to load homebrews that don't use retail read/write commands for ROM/save. As mentioned before this only works on DS or DS Lite, DSi & later perform authenticity checks on the binaries and more. For those platforms the "bootloader" needs to be authentic game code and execution is captured some time later.

For piracy-capable flashcards, the FPGA also defines additional commands which allow you to program it with read/write mappings for the ROM and save files on the SD card. Once the mappings are set up, later official read/write commands will use data from those files rather from the bootloader. Essentially the flashcard is now emulating a retail card at the protocol level, so the FPGA has some understanding of FAT too. Some DS flashcards didn't support this like the Games n Music so they can't run retail ROMs without lots of binary patches like nds-bootstrap.

Disclaimer: This is knowledge gleamed from looking at stuff like DLDI drivers and woodrpg source, not experiential.
 
  • Like
Reactions: Ryccardo and xbmbmx

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
Like lifehackerhansol said, the flashcard FPGA provides a set of extra commands which allow access to the SD card. These provide high level sector access to the SD card. Just send data, the sector address, a command byte and it will read or write the SD card there. The FPGA takes care of the serial communication with the SD card.

At boot, the flashcart functions like an official cart, except the ROM contained is the bootloader instead of a game. The DS firmware runs it the same way it loads a game. The bootloader can use the previously mentioned SD commands to load and run the kernel from the SD card. The kernel can also use those commands for general file IO or to load homebrews that don't use retail read/write commands for ROM/save. As mentioned before this only works on DS or DS Lite, DSi & later perform authenticity checks on the binaries and more. For those platforms the "bootloader" needs to be authentic game code and execution is captured some time later.

For piracy-capable flashcards, the FPGA also defines additional commands which allow you to program it with read/write mappings for the ROM and save files on the SD card. Once the mappings are set up, later official read/write commands will use data from those files rather from the bootloader. Essentially the flashcard is now emulating a retail card at the protocol level, so the FPGA has some understanding of FAT too. Some DS flashcards didn't support this like the Games n Music so they can't run retail ROMs without lots of binary patches like nds-bootstrap.

Disclaimer: This is knowledge gleamed from looking at stuff like DLDI drivers and woodrpg source, not experiential.
I see, thank you! It seems I was editing my previous reply while you were typing this ^_^.

I'm starting to see the full picture now. My next attempt will most likely be raspberry pi pico or some other devboard and my old DS lite.

I'll research the DSi requirements later -- I'd like the flaschard to work on a DSi (not DSi mode, but work on a DSi). But that's if I ever get it to work on the DS lite in the first place.



Thanks again everyone that has replied here so far. It really boosts the research and I'm sure that I wouldn't have found half of the information shared here if I were to do it completely on my own.
 

lifehackerhansol

i write working(?) code
Member
Joined
Oct 2, 2021
Messages
468
Trophies
0
XP
1,424
Country
Canada
Thanks! That does clear up my mental image. As a matter of fact, it seems I was already browsing that same repository you mentioned :P.

I'm starting to see how data is being pulled from the SD card. I just still have somewhat of a hard time imagining the complete picture. How does the kernel that gets eventually loaded into the DS's memory "pipe" data through the flashcard? Because, as far as I understand it, the access to the SD card can't just be mapped 1:1 to running code on the DS. I can't even really formulate my question on this topic properly so there's still some key pieces I'm missing. ** Edit **: I was either blind or just confused, re-reading your message clears up quite a bit of the SD card stuff. I mainly still struggle with the "DS To Flashcart To SD" part. Is this a good representation of the flow or am I missing key parts (high-level of course)?

View attachment 349651


Since I'm typing my reply anyways I'm going to add another question :). Do you happen to know how the "bootloader" setup would be implemented on flashcards? I mean step 3 of this process:

That is a key part of the flow it seems and before @ghjfdtg mentioned it I didn't even know it was a thing so any information I can get about the subject is welcome!
This image looks fairly accurate to me.

As for the bootloader... it depends on each cart. But in most cases, the DS loads the ROM in the flashcart like any other. The ROM stored on the flashcart will be what I call "bootloader".

Depending on the bootloader, it may have a few setup steps. The DSTT (and by definition all timebombed carts) checks the SD card for whether it is SD or SDHC, and writes to 0x023FFC24. The DLDI then reads the value and correctly determines the correct commands to send depending on SD/SDHC. There are some other carts that do maybe other things, but I haven't looked that far yet.
- This has been a pain point for homebrew apps, as this bool can be overwritten pretty much any day. I had to add a ridiculous hack (i.e. not clearing BSS upon hotpatching DLDI) just to make sure the bool stays.

Or, the bootloader doesn't need to set up the hardware. It's possible to program it as such that upon power up the FPGA automatically initializes (I think that's how retail cartridges work? I don't really know, I reverse engineer other's homebrew lol) In this situation, it just launches whichever file on the SD card it boots from. It's very similar to how flashcard-bootstrap works (I sent you my project in an earlier post), it will basically load the NDS file's ARM9 and ARM7 into its respective addresses, decrypt where necessary, and have the CPUs BX to it. The difference to my project is that most flashcarts don't DLDI patch the boot file, it expects the boot file to already be DLDI patched or have the SD commands statically linked.

After that, whatever homebrew you renamed to the boot file will just do its own thing.
 
  • Like
Reactions: xbmbmx

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
This might be interesting to look at: https://github.com/shinyquagsire23/gwcard
I didn't come across that repository yet, interesting indeed!

Goes right into the obsidian vault ;).
Post automatically merged:

Okay, so...

I (think I) have a 3D printed case that will work well enough to hold the breakout board into a DS. I haven't tested yet because well... I cannot test it really - how would I? I am thinking about ripping a SLOT-1 slot (lol) out of a broken DS and frankensteining the pins of that slot to my breakout board. In theory if I pass all pins of a retail card to the same pins of my breakout board and it doesn't lose contact, the DS should read the retail card through my breakout board... I'm quite confident though that at the current state it will lose contact (breakout board in the 3D printed cartridge wiggles quite a bit).

Also, now that I'm getting somewhat close to being able to test with hardware, I'm looking for some resources on the hardware communication.

Currently I've accumulated this over various sources (including GBATEK and HardwareBook, and some random forum posts here and on other sites):

Physical PIN layout:

1: GND
2: CLK (4MB/s)
3: ???
4: Chipselect ROM
5: Reset
6: Chipselect EEPROM (sav)
7: Interrupt Request (Unsure what this means)
8: 3.3v IN (note to not use rp pico 3.3 OUT - Will damage DS I assume)
9-16: D0-7
17: GND (loops to 1)

I have three questions:

1) What does interrupt request mean, and what functionality does it provide?

2) I'm kind of lost on the whole communication flow to be honest right now. GBATEK does a good job of explaining the byte sized commands but... Where are they sent? What pin(s)? I missed / forgot where that is explained more in depth but I can't piece together how or where those commands are passed.

Anyone who can elaborate a bit on this, please do. It's quite vital I understand this to really be able to do anything so feel free to explain it to me like I'm 5.

The hardware side of this project will be the toughest, I don't have any formal education in electronics or ICs (yet) and my hobby tinkering never went further than some barebones arduino / rpi powered RC car.

3) What does pin 3 do? Some forum posts seem to say the receiving part of the DS card slot doesn't even connect to the pin. Is this correct (quick flashlight inspection does seem to show a pin inside my DS for pin 3 - unsure though quite hard to see), or is the connection not soldered onto the DS main board? Or is this false and does this pin serve a function?
 
Last edited by xbmbmx,

metroid maniac

An idiot with an opinion
Member
Joined
May 16, 2009
Messages
2,068
Trophies
2
XP
2,575
Country
I have three questions:

1) What does interrupt request mean, and what functionality does it provide?
If the cartridge sets this pin, the DS CPUs will receive an interrupt. Looks like it's represented by bit 20 in these registers. I don't know if it was in widespread use - GBA carts also had an interrupt request pin and it was rarely used.
2) I'm kind of lost on the whole communication flow to be honest right now. GBATEK does a good job of explaining the byte sized commands but... Where are they sent? What pin(s)? I missed / forgot where that is explained more in depth but I can't piece together how or where those commands are passed.
These IO ports are used.
 

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
If the cartridge sets this pin, the DS CPUs will receive an interrupt. Looks like it's represented by bit 20 in these registers. I don't know if it was in widespread use - GBA carts also had an interrupt request pin and it was rarely used.

These IO ports are used.
I see. Well, I'm having real difficulty understanding the IO section... I'm unsure if there's any way to learn how to comprehend this chapter?

Screenshot_20230129-151553-023.png


Currently this is just :wacko: to me, and that's a problem...
 

metroid maniac

An idiot with an opinion
Member
Joined
May 16, 2009
Messages
2,068
Trophies
2
XP
2,575
Country
I see. Well, I'm having real difficulty understanding the IO section... I'm unsure if there's any way to learn how to comprehend this chapter?

Currently this is just :wacko: to me, and that's a problem...
If you have specific questions, I can do my best to answer each...
 

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
If you have specific questions, I can do my best to answer each...
Currently I don't really have much questions yet as I don't really understand it enough to have questions :/

There are a few I struggle with already:

400011A0h, 400011A2h, 400011A4h: are these byte commands (I assume the H notation is Hex, or is that a wrong assumption)? How are they interpreted and by who? (DS -> card) or (card -> DS)?

What are the numbers representing (e.g. 31) in the 40001A4h section? I assumed pin numbers but that's clearly not the case as there aren't 31 pins present. Leading me to believe the other section numbers also don't represent pin numbers?

Generally: how must I imagine these commands to be passed? I'll try to think of a concrete scenario today and maybe someone can explain a brief step-by-step of what communication for that scenario would look like. I understand this (or these) question(s) are quite broad and probably hard to answer concisely, I'm really learning from 0 on the hardware protocol and trying to wrap my head around it.

Any input on these questions (or general input related to the hardware protocol) would really help me forward.
Post automatically merged:

Do they represent bits in the response on the command? I am confused haha, hopefully someone can shed some light on this topic because it'll be a real struggle to figure out by myself I imagine.
 

metroid maniac

An idiot with an opinion
Member
Joined
May 16, 2009
Messages
2,068
Trophies
2
XP
2,575
Country
400011A0h, 400011A2h, 400011A4h: are these byte commands (I assume the H notation is Hex, or is that a wrong assumption)? How are they interpreted and by who? (DS -> card) or (card -> DS)?
Those are memory mapped IO registers. Reading or writing to those addresses from either the ARM9 or ARM7 CPU (the documentation tells you which) will do something to IO. Memory mapped IO is a widely used way for CPUs to talk to peripherals, if you haven't encountered it before.
The full memory map for NDS is here.
What are the numbers representing (e.g. 31) in the 40001A4h section? I assumed pin numbers but that's clearly not the case as there aren't 31 pins present. Leading me to believe the other section numbers also don't represent pin numbers?
Those are bit indices. For the 31st bit of the word at 40001A4h, writing a 1 starts a block transfer, reading a 1 indicates a block transfer is ongoing, and reading a 0 indicates it is idle.



If you don't have any background in this sort of thing, why not begin by looking at something simpler like the Game Boy or Game Boy Advance? There's barely any cartridge protocol to speak of there.
 
  • Like
Reactions: xbmbmx

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
Those are memory mapped IO registers. Reading or writing to those addresses from either the ARM9 or ARM7 CPU (the documentation tells you which) will do something to IO. Memory mapped IO is a widely used way for CPUs to talk to peripherals, if you haven't encountered it before.
The full memory map for NDS is here.

Those are bit indices. For the 31st bit of the word at 40001A4h, writing a 1 starts a block transfer, reading a 1 indicates a block transfer is ongoing, and reading a 0 indicates it is idle.



If you don't have any background in this sort of thing, why not begin by looking at something simpler like the Game Boy or Game Boy Advance? There's barely any cartridge protocol to speak of there.
No reason to not look into GB or GBC :P, I just kind of dove head first into this, and as the NDS(i) is my "target" I just got going on that part of documentation/research.

The memory map does make more sense to me now, but indeed 0 experience and still rough to interpret what's actually going on, hard to get a grasp on how the cartridge recieves those actions (ultimately in a far future I would make a card that can respond to those actions appropriately)

I'm slowly chewing through learncpp at the moment and I imagine that the chapters on bit manipulation and such will also give me a better picture.

I'll pause the cartridge protocol research for now untill I get through learncpp, then I imagine making some homebrew using the card.h file will also help a lot. Trying to make my own version of something like a ROM dumper will most likely be a good test to see if I understand it enough.

Thank you for the clarification!
 

metroid maniac

An idiot with an opinion
Member
Joined
May 16, 2009
Messages
2,068
Trophies
2
XP
2,575
Country
I'll pause the cartridge protocol research for now untill I get through learncpp, then I imagine making some homebrew using the card.h file will also help a lot. Trying to make my own version of something like a ROM dumper will most likely be a good test to see if I understand it enough.
Reading how libnds talks to the card in card.c can also give you a picture of how correctly structured communication with the card looks like for NDS software.
 
  • Love
Reactions: xbmbmx

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
Okay, so the general concept of talking to the card through the DS is now somewhat clear to me thanks to @metroid maniac : the I/O maps map the DS's memory to physical interaction with the card, and again map the cards physical reaction to memory, which you can then read and if needed manipulate.

The next step now is: What about the hardware (and cartridge)?

If I want to end up making a cartridge prototype I need to know how the communication happens on the hardware level (what do the eight D pins do, how to interpret signals over these pins and how to reply to them).

Is there any documentation on this part of the communication protocol? (The actual signals sent, the protocol used to interpret them, and the replies send by cards)

In private chat I discussed this with @Sono . He mentioned this is Octo-SPI with a proprietary protocol, his NTRboot project was built with logic analysing and trial-and-error.

A possible plan of attack here is to use a logic analyser and start from scratch, matching the GBATEK handshake part of the communication with the signals being sent into the breakout board - maybe piggybacking on communication of a retail card to see the communication.

However, if there is already information on this out there, that would be easier, and most likely more reliable than me just going ham with an analyser (close-to-0 electrical knowledge, very little IC knowledge).

I do intend to document any findings in my vault and somewhere in the future also release it as a document that doesn't contain copyrighted material (as I stated previously I cannot simply share my vault as I also track digital copies of books I bought and such in there for annotations - I can add you to the git repository on request).

So, any insight on the SPI communication, how to interpret said communition on cartridge (!) side and so on is very welcome!
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,284
Country
United Kingdom
I don't know that I would go logic analyser as much as one of those nice modern oscilloscopes that captures data. Logic analysers have their place but if you are jumping right into encrypted communications and such then I have concerns, and that is before data rates (the SPI baud rate mentioned there could well be what you have to try to handle and 4Mhz signals can start to get into annoying analogue electronics territory (or if you prefer there is a reason the cartridge slot is a big metal shield and pins so very close to the CPU*

It is however clear even without you saying that you probably want to get some more grounding in electronics and low level operations, possibly also some low level programming -- asking what interrupt request is as opposed to specifics of the interrupt in question being that. While a more than suitable answer was given I want to go. I am sure you could give a nice textbook answer on what is a loop and tell me all about IF ELSE, WHILE and FOR EACH or whatever they are in your chosen language of the day, however when it comes down to electronics and CPUs screaming along blindly following instructions it gets really annoying to have to check if something has happened every few cycles, never mind 50 of them because this is a complicated computing system we are imagining in this (music, graphics, controls, memory, network, cartridge... all having a good case for multiple instances), when instead real work™ can be getting done.

I am not sure where to point you for this though. Interrupts are not necessarily something you meet right away, or if you do it is more of an abstract concept that might not even be given a name (inputs in logic gates are kind of interrupts in the real world) or "you don't need to worry about that" part of a shift register setup. If you already know your boolean logic from programming then basic digital electronics should be fairly quick as most of that is usually spent teaching truth tables, you might also gain an appreciation for the why such constructions are used in high level programming as opposed to the because we say so thing that most high level books seem to adopt whenever I go reading.
The trouble comes in that I am not sure what would be best suited here. For general concepts if you meet a void in your knowledge then https://www.allaboutcircuits.com/ usually houses something interesting, https://ocw.mit.edu/courses/6-01sc-...gineering-and-computer-science-i-spring-2011/ is sure to have some good stuff but be a bit of a slot, electronics is popular on video websites and while most will attempt their own intro at some point and have good stuff on specifics but where you find yourself is in a bit of a limbo between beginner and appreciator of esoteric topics. The video set tends to be more repair, extremes and what you encounter when you get there and industry of electronics topics as well (which is wonderful and I can watch it all day long but might not be what you aim for if you want to get there quicker).

*haven't got a nice shot of it removed vs with it so skip to 39 seconds


For low level programming I usually have to get people to start down the path of x86 assembly before moving to in this case an older but not old ARM as x86 is by far the most fleshed out here. https://www.plantation-productions.com/Webster/ and https://stuff.pypt.lt/ggt80x86a/asm1.htm being my usual links.

As far as communications then http://problemkaputt.de/gbatek.htm#dscartridgeprotocol
If you mean anything like if you attach your scope probe to here then you will see this waveform then such things are very rare to find for any console really, beyond interpreting something like the above for yourself (communications are either serial or parallel after all, if you can induce a given command to always be happening then you can capture it, vary it and see where the variation comes on pin level).

Nice intro to grabbing data from the ground up as it were rather than here is magic reader/schematics so run these command prompt commands such things often appear as


Said guy also did a nice video on SPI if we are still considering that in this
 

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
236
Country
Belgium
I don't know that I would go logic analyser as much as one of those nice modern oscilloscopes that captures data. Logic analysers have their place but if you are jumping right into encrypted communications and such then I have concerns, and that is before data rates (the SPI baud rate mentioned there could well be what you have to try to handle and 4Mhz signals can start to get into annoying analogue electronics territory (or if you prefer there is a reason the cartridge slot is a big metal shield and pins so very close to the CPU*

It is however clear even without you saying that you probably want to get some more grounding in electronics and low level operations, possibly also some low level programming -- asking what interrupt request is as opposed to specifics of the interrupt in question being that. While a more than suitable answer was given I want to go. I am sure you could give a nice textbook answer on what is a loop and tell me all about IF ELSE, WHILE and FOR EACH or whatever they are in your chosen language of the day, however when it comes down to electronics and CPUs screaming along blindly following instructions it gets really annoying to have to check if something has happened every few cycles, never mind 50 of them because this is a complicated computing system we are imagining in this (music, graphics, controls, memory, network, cartridge... all having a good case for multiple instances), when instead real work™ can be getting done.

I am not sure where to point you for this though. Interrupts are not necessarily something you meet right away, or if you do it is more of an abstract concept that might not even be given a name (inputs in logic gates are kind of interrupts in the real world) or "you don't need to worry about that" part of a shift register setup. If you already know your boolean logic from programming then basic digital electronics should be fairly quick as most of that is usually spent teaching truth tables, you might also gain an appreciation for the why such constructions are used in high level programming as opposed to the because we say so thing that most high level books seem to adopt whenever I go reading.
The trouble comes in that I am not sure what would be best suited here. For general concepts if you meet a void in your knowledge then https://www.allaboutcircuits.com/ usually houses something interesting, https://ocw.mit.edu/courses/6-01sc-...gineering-and-computer-science-i-spring-2011/ is sure to have some good stuff but be a bit of a slot, electronics is popular on video websites and while most will attempt their own intro at some point and have good stuff on specifics but where you find yourself is in a bit of a limbo between beginner and appreciator of esoteric topics. The video set tends to be more repair, extremes and what you encounter when you get there and industry of electronics topics as well (which is wonderful and I can watch it all day long but might not be what you aim for if you want to get there quicker).

*haven't got a nice shot of it removed vs with it so skip to 39 seconds


For low level programming I usually have to get people to start down the path of x86 assembly before moving to in this case an older but not old ARM as x86 is by far the most fleshed out here. https://www.plantation-productions.com/Webster/ and https://stuff.pypt.lt/ggt80x86a/asm1.htm being my usual links.

As far as communications then http://problemkaputt.de/gbatek.htm#dscartridgeprotocol
If you mean anything like if you attach your scope probe to here then you will see this waveform then such things are very rare to find for any console really, beyond interpreting something like the above for yourself (communications are either serial or parallel after all, if you can induce a given command to always be happening then you can capture it, vary it and see where the variation comes on pin level).

Nice intro to grabbing data from the ground up as it were rather than here is magic reader/schematics so run these command prompt commands such things often appear as


Said guy also did a nice video on SPI if we are still considering that in this

Thank you. The videos are now on my must-watch (the TV censoring video was already in my "intro to logic analysing" playlist :P).

My lack of electrical knowledge is indeed a real hurdle. I'll just take it a step at a time and ask here for input if I don't understand something.

The logic analyser or oscilloscope choice will depend on 1) availability 2) learning curve 3) cost.

I'm mainly trying to understand how the cartridge receives the communication. I am looking to make some sort of homebrew application that allows me to step through the cartridge handshake process slowly, maybe send some types of commands on a button press and inspect how it is communicated over the pins. Examples like GodMode9i and EEPROM.nds (DevkitPro example source) are a good refernce / starting point.

It's not my intention to start diving into logic on a pure signal level - I'm more so trying to understand what it would take on the cartridge (RP Pico) side to make sense of the signals and answer them.

The SPI video will shed some light I hope, and if not - a deep dive into literature it will be untill I find something that helps me.
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,284
Country
United Kingdom
Logic analysers and scopes are both readily available online. They have basic USB forms that are very limited but can do good things (USB scopes are one thing but the more basic analysers are usually protocol specific -- you might get a USB debugger, a SPI debugger...), to better USB things (bus pirate is an older one but one I really like and picoscope in the expensive automotive tools world for instance) to standalone (but possibly still speak to the PC) things, and some high end oscilloscopes also function as them (as well as being function generators for some purposes too).
The high end USB and standalone do also sometimes have perks -- data storage and high resolution on a standalone scope is a thing the devs have to add, for a PC then you are basically storing text data and is thus basically unlimited and resolution is basically unlimited or at least rather higher.

If you are searching more in the real world or second hand then a scope will be 1000x more readily available as they are used by many people where logic analysers are much more field specific devices. At the same time said online scope might be some old CRT thing without memory (my old CRT thing has a bit of memory, https://gbatemp.net/threads/things-you-recently-bought-or-got.347639/page-531#post-8545735 ) where modern stuff, which does include some nice hackable things from China, has more going on.
If you were slow playing the build up to learning electronics then a 2 channel memory less CRT would be a wonderful learning tool, for this then you are probably going to want to jump into the 4 channel with at least a bit of memory world for this. Looking at the cheap Chinese tat websites a 2 channel bench scope (avoid the handhelds unless you know what its limitations are, for some nice motor debugging where you care more about phase and signal being there then wonderful, hardcode signals analysis is a different debate) with memory and shiny features can be had for around the $200USD mark, 4 channels is a rather more exotic feature these days it seems (don't know why, 5 years ago was far less of one). More general vendors have about the same markup as anything else above that. Oh do be aware that some are software crippled as well (even tools have microtransactions these days).

Step through... this then gets into one of the times underclocking and overclocking truly makes sense for a handheld (or at least one older than the PSP). Signals are fast and fast things take more effort, indeed so much so that even the big boys wanting to analyse say Intel's latest and greatest will uncap it, change the clock and measure an underclocked thing. Though you can go the other way and repeat commands until some input is detected with some homebrew perhaps (be it on screen or via an external trigger -- maybe you send an SPI signal to the save bus similar to the pokewalker, or reinvent dsserial).

Probably should also link

Said channel is one of the bigger electronics channels as well, and has a very nice forum associated with it.
 

ghjfdtg

Well-Known Member
Member
Joined
Jul 13, 2014
Messages
1,350
Trophies
1
XP
3,236
Country
You don't need to understand the signals on analog level. I diasgree getting a scope and it will cost you hundreds compared with adequate logic analyzers you can get for under 100 bucks. Logic analyzers are the right tool for this job. Good luck finding a 16 channel scope. If they exist they cost tens of thousands.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    SylverReZ @ SylverReZ: @salazarcosplay, Morning