3 ms·

> They were really frustrated with the code footprint limitations of the DS. As in the memory or the final binary size? I would have thought memory management

> They were really frustrated with the code footprint limitations of the DS. As in the memory or the final binary size? I would have thought memory management was the tricky part -- even with the mandatory 8 MB expansion in the GBA slot -- but I suppose they would have been under even more pressure to fit it onto the smallest cart possible, with the cost of the expansion pack added for every unit

tpmx 4y ago
Now you're making me uncertain. I was pretty certain it was the code/binary footprint. I remember suggesting they look into using any MMU for doing code overlaying/swapping [and the DS doesn't appear to have one...]. The Opera code was very memory efficient after having gone through so many memory usage optimizations triggered by lots of mobile platform ports. It was a really long time ago, sorry :)
- strangecasts 4y ago
  No worries! It does sound likely, it was definitely from a time where people had to do everything they could to fit games onto the cartridges! The Wikipedia page [1] claims* they had an MMU on the expansion cart - so they could have taken your advice :) * I couldn't find a source, and AFAICT the DeSmuME emulator [2] seems to treat it like a big chunk of linear memory? [1] https://en.wikipedia.org/wiki/Nintendo_DS_Browser#Memory_Expansion_Pak https://en.wikipedia.org/wiki/Nintendo_DS_Browser#Memory_Exp... [2] https://github.com/TASEmulators/desmume/blob/master/desmume/src/addons/slot2_expMemory.cpp https://github.com/TASEmulators/desmume/blob/master/desmume/... E: I forgot about the mobile Opera ports, that also tracks - I'd love to read about the engineering that went into them!
  - tpmx 4y ago
    > E: I forgot about the mobile Opera ports, that also tracks - I'd love to read about the engineering that went into them! Can't really meaningfully expand on that, most of that happened before I joined in 2004, but I can tell you that the fact that Opera was extremely memory efficient made Opera Mini (250M monthly uniques, 150k web page transcodes/s) economically possible starting 2005. We needed to keep the browser/window state around for each user until they clicked the next link. If we threw it out, any javascript state would be lost.
    - strangecasts 4y ago
      That's fair - those are very impressive numbers! Reading about Mini doing layout specifically for devices with <128px wide displays, I wonder how well today's responsive design frameworks would deal with that...
      - orangewindies 4y ago
        Mini did some tricks so the "display" was much wider than the device display but text columns were wrapped at device display width. So you you could zoom out and see the whole page but the text was readable when you zoomed in.
- gsnedders 4y ago
  As a former colleague who does remember (hi!), it is indeed the case that they had an MMU doing code swapping, along with extra RAM on the cartridge.
  - tpmx 4y ago
    Hi! Do you remember what the limit was that prompted this costly measure? Addressable code space from the CPU? How could there be a limit in the megabytes, not gigabytes? I don't get it.
    - gsnedders 4y ago
      Executable code space from the CPU was the limitation; I forget if this was lower-level software or hardware.

tpmx 4y ago

Now you're making me uncertain. I was pretty certain it was the code/binary footprint. I remember suggesting they look into using any MMU for doing code overlaying/swapping [and the DS doesn't appear to have one...]. The Opera code was very memory efficient after having gone through so many memory usage optimizations triggered by lots of mobile platform ports. It was a really long time ago, sorry :)

strangecasts 4y ago
No worries! It does sound likely, it was definitely from a time where people had to do everything they could to fit games onto the cartridges! The Wikipedia page [1] claims* they had an MMU on the expansion cart - so they could have taken your advice :) * I couldn't find a source, and AFAICT the DeSmuME emulator [2] seems to treat it like a big chunk of linear memory? [1] https://en.wikipedia.org/wiki/Nintendo_DS_Browser#Memory_Expansion_Pak https://en.wikipedia.org/wiki/Nintendo_DS_Browser#Memory_Exp... [2] https://github.com/TASEmulators/desmume/blob/master/desmume/src/addons/slot2_expMemory.cpp https://github.com/TASEmulators/desmume/blob/master/desmume/... E: I forgot about the mobile Opera ports, that also tracks - I'd love to read about the engineering that went into them!
- tpmx 4y ago
  > E: I forgot about the mobile Opera ports, that also tracks - I'd love to read about the engineering that went into them! Can't really meaningfully expand on that, most of that happened before I joined in 2004, but I can tell you that the fact that Opera was extremely memory efficient made Opera Mini (250M monthly uniques, 150k web page transcodes/s) economically possible starting 2005. We needed to keep the browser/window state around for each user until they clicked the next link. If we threw it out, any javascript state would be lost.
  - strangecasts 4y ago
    That's fair - those are very impressive numbers! Reading about Mini doing layout specifically for devices with <128px wide displays, I wonder how well today's responsive design frameworks would deal with that...
    - orangewindies 4y ago
      Mini did some tricks so the "display" was much wider than the device display but text columns were wrapped at device display width. So you you could zoom out and see the whole page but the text was readable when you zoomed in.
gsnedders 4y ago
As a former colleague who does remember (hi!), it is indeed the case that they had an MMU doing code swapping, along with extra RAM on the cartridge.
- tpmx 4y ago
  Hi! Do you remember what the limit was that prompted this costly measure? Addressable code space from the CPU? How could there be a limit in the megabytes, not gigabytes? I don't get it.
  - gsnedders 4y ago
    Executable code space from the CPU was the limitation; I forget if this was lower-level software or hardware.