4 ms·

This really needs a ranking for upstream support. I mean, just a basic keyword check yields 2, 4, 5, 6, and 8 have a Mali GPU so hopeless unless you want to run

This really needs a ranking for upstream support. I mean, just a basic keyword check yields 2, 4, 5, 6, and 8 have a Mali GPU so hopeless unless you want to run a supercomputer with the equivalent functionality of a time-sharing terminal system destined for the landfill in a near future. It would be soo important to have a way to enable people to learn stuff like low-level graphics programming on real hardware designs. One of the big failures of the GPL, we have all the software on top of the stack but little on the bottom.

derefr 9y ago
> learn ... low-level graphics programming on real hardware designs Why not program an NES game? You can develop against any number of cycle-accurate emulators, and then test your completed program on any random $10 "Famiclone" device that has an SD card slot. (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.) Alternatively, for around $30, you can get an original Nintendo DS + an R4i flash-cart, which is a pretty extensive and interesting graphics platform to target: it has tile-mode graphics, bitmap-mode graphics, sprites with hardware scaling/rotation/shearing, and a fixed-function 3D pipeline with UV mapping and lighting, all able to be active as different hardware-composited layers of the framebuffer—but all still directly addressed using pokes to MMIO registers, rather than there being any hardware abstraction layer. Pretty great for learning graphics, honestly.
- khedoros1 9y ago
  > (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.) A number of other gaming systems used similar mapping systems. And it's not so far conceptually from EMS on real-mode x86.
  - derefr 9y ago
    NES Mappers aren't quite the same thing as regular memory bank-switching, or even the same as MMU programmability. They were a whole lot weirder. Mappers, in the context of NES programming, are regions of on-cart ROM or WRAM that were wired up through various custom ASICs (the eponymous "mapper" chips) to do things like, for example, have contiguous looping reads to the same 64-byte address sequence (so, one 8x8 tile's worth of nametable data) produce as output a sequence of animated frames, by having the ASIC switch which physical page is backing that region of the address space once per VBLANK, entirely transparently to the CPU and asynchronously to running code (i.e. not driven by a maskable interrupt.) In other words, each cartridge essentially cobbled together its own MMU by throwing together random chips which could respond in completely arbitrary ways to specific masked read-lines from the address bus; and many of these chips did very domain-specific things to very small regions of memory, rather than being general-purpose (there have been more than 100 different mapper chips put into NES cartridges, some used by only one released game.) As far as I know, no other system has ever done anything quite so weird as that at a hardware level.
    - jacquesm 9y ago
      It definitely upped the gamesmanship required for cloners of cartridges, and it made the system somewhat future proof.
    - khedoros1 9y ago
      One 8x8 tile takes 16 bytes of nametable data, not 64. There are a couple hundred mappers and variants, but the 4 most common ones (thinking of cnrom, unrom, mmc1, mmc3) cover 90-something percent of all cartridges out there, and don't have the address increment that you're describing. Most of them just cover bank switching, or (like MMC3) add some IRQ stuff under certain conditions. There are cartridges with extra copy protection, extra audio channels, etc. As you said, the ASICs do basically arbitrary things, but it's not like you have to learn one of the really esoteric mappers. The most common mapper behaviors are comparable to bank-switching on other systems. I'd say that the SNES gives NES a run for its money, in terms of weirdness. The ASICs in many of the cartridges there included whole processor cores.
      - 9y ago
- AnIdiotOnTheNet 9y ago
  Because the PPU and other such sprite-based hardware bares no resemblance to a modern graphical pipeline? It'd be more educational to just provide a framebuffer connected to a displayport controller and teach people software rendering.
Const-me 9y ago
> have a Mali GPU so hopeless At least for our use cases, a Mali GPU works OK. It drives 2 external displays with GLES 3.1 on Linux, one of the displays has 4K resolution.

derefr 9y ago

> learn ... low-level graphics programming on real hardware designs Why not program an NES game? You can develop against any number of cycle-accurate emulators, and then test your completed program on any random $10 "Famiclone" device that has an SD card slot. (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.) Alternatively, for around $30, you can get an original Nintendo DS + an R4i flash-cart, which is a pretty extensive and interesting graphics platform to target: it has tile-mode graphics, bitmap-mode graphics, sprites with hardware scaling/rotation/shearing, and a fixed-function 3D pipeline with UV mapping and lighting, all able to be active as different hardware-composited layers of the framebuffer—but all still directly addressed using pokes to MMIO registers, rather than there being any hardware abstraction layer. Pretty great for learning graphics, honestly.

khedoros1 9y ago
> (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.) A number of other gaming systems used similar mapping systems. And it's not so far conceptually from EMS on real-mode x86.
- derefr 9y ago
  NES Mappers aren't quite the same thing as regular memory bank-switching, or even the same as MMU programmability. They were a whole lot weirder. Mappers, in the context of NES programming, are regions of on-cart ROM or WRAM that were wired up through various custom ASICs (the eponymous "mapper" chips) to do things like, for example, have contiguous looping reads to the same 64-byte address sequence (so, one 8x8 tile's worth of nametable data) produce as output a sequence of animated frames, by having the ASIC switch which physical page is backing that region of the address space once per VBLANK, entirely transparently to the CPU and asynchronously to running code (i.e. not driven by a maskable interrupt.) In other words, each cartridge essentially cobbled together its own MMU by throwing together random chips which could respond in completely arbitrary ways to specific masked read-lines from the address bus; and many of these chips did very domain-specific things to very small regions of memory, rather than being general-purpose (there have been more than 100 different mapper chips put into NES cartridges, some used by only one released game.) As far as I know, no other system has ever done anything quite so weird as that at a hardware level.
  - jacquesm 9y ago
    It definitely upped the gamesmanship required for cloners of cartridges, and it made the system somewhat future proof.
  - khedoros1 9y ago
    One 8x8 tile takes 16 bytes of nametable data, not 64. There are a couple hundred mappers and variants, but the 4 most common ones (thinking of cnrom, unrom, mmc1, mmc3) cover 90-something percent of all cartridges out there, and don't have the address increment that you're describing. Most of them just cover bank switching, or (like MMC3) add some IRQ stuff under certain conditions. There are cartridges with extra copy protection, extra audio channels, etc. As you said, the ASICs do basically arbitrary things, but it's not like you have to learn one of the really esoteric mappers. The most common mapper behaviors are comparable to bank-switching on other systems. I'd say that the SNES gives NES a run for its money, in terms of weirdness. The ASICs in many of the cartridges there included whole processor cores.
    - 9y ago
AnIdiotOnTheNet 9y ago
Because the PPU and other such sprite-based hardware bares no resemblance to a modern graphical pipeline? It'd be more educational to just provide a framebuffer connected to a displayport controller and teach people software rendering.

Const-me 9y ago

> have a Mali GPU so hopeless At least for our use cases, a Mali GPU works OK. It drives 2 external displays with GLES 3.1 on Linux, one of the displays has 4K resolution.