8 ms·

The Starfox PCB has a bunch of traces going off the board, I'm guessing that's for a program & test harness used during manufacturing? I've never seen that done

The Starfox PCB has a bunch of traces going off the board, I'm guessing that's for a program & test harness used during manufacturing? I've never seen that done before. Was that a common practice back in the day? Nowadays we would put pads on the board and use a bed of nails to do that.

bluedino 3y ago
A Starfox cartridge was used to make a homebrew devkit for SNES Doom The development was challenging for a few reasons, notably there were no development systems for the SuperFX chip at the time. I wrote a complete set of tools - assembler, linker and debugger - before I could even start on the game itself. The development hardware was a hacked-up Star Fox cartridge (because it included the SuperFX chip) and a modified pair of game controllers that were plugged into both SNES ports and connected to the Amiga's parllel port. A serial protocol was used to communicate between the two for downloading code, setting breakpoints, inspecting memory, etc https://fabiensanglard.net/gebbdoom/ https://fabiensanglard.net/gebbdoom/
- rightbyte 3y ago
  It is really asstonishing how dev hostile those game consoles were. Like, "we know how to do it but invent it yourself". Nintendo could have released sane sdk:s and not make every dev studio figure out what works. Like, maybe share a toy version of the source of Super Mario and Zelda or whatever to show how an engine is made. The games would surely have been prettier as a result.
  - tadfisher 3y ago
    They did have SDKs (well, an assembler and linker) as well as devkits and extensive documentation. The problem was you had to enter an extensive agreement and pay a hefty amount for the privilege of using them. It made sense in that era, as you had to have the cash on hand to order a minimum of 10,000 cartridges (also manufactured by Nintendo) anyway.
  - bluedino 3y ago
    Nintendo was dev hostile as well. In Argonaut's case, Starfox 2 was canceled (but still completed) because they didn't want SNES 3D games competing with the soon-to-be-released N64 And then they shot down Argonauts 3D platformer demo, saying they would make their own, causing them to create Croc instead. In a way it made sense because you didn't want to end up with Sega where they kept trying to extend the old platforms. But they weren't looking to create a new in-between or add-on system like the Sega CD or 32X
    - wk_end 3y ago
      TBF you can’t exactly begrudge Nintendo for wanting to end up with SM64 instead of Croc.
      - philistine 3y ago
        That version of history is in contention. The devs of Croc are adamant they basically invented 3D platformers and Nintendo stole their ideas, but the timelines with the first builds of Super Mario 64 rule in favour of Nintendo.
    - MBCook 3y ago
      Oh I didn’t realize they made Croc. That was a good game.
  - arantius 3y ago
    > It is really asstonishing how dev hostile those game consoles were... What's actually astonishing is the range of things that seem strange at first, but are actually very clear and logical, IF you also understand the historical context. The path that led reasonable people to make these decisions. Here, see the comments elsewhere about how licensing worked for physical cartridges (they were expensive -- open source cartridge games doesn't make much sense). Plus a dash of copy protection and especially, read into the video game crash of the 80s. This was part of the plan to avoid shovelware (which arguably made Nintendo the success it was). > The games would surely have been prettier as a result. What are you basing this on? 80s and 90s era console hardware was quite restricted, and the software we got did I think all that the hardware could do.
Karliss 3y ago
You can sometimes see a similar approach in somewhat recent (~last 10 years) microcontroller devboards. Many of Nucleo devboards for STM32 microcontrollers, and some Cypress PSoC devboards (CY8CKIT) consist of two halves. One containing the main MCU (the one devboard demonstrates), and other half containing programmer/debugger. Idea is that you can use it as is out of the box for running basic example programs, or you can break it in half thus obtaining a cheap programmer + devboard which has a slightly more convenient format for embedding in product prototype. Similar thing but reversed roles with ChipWhisperer-lite (platform for experimenting with side channel power analysis and glitching attacks). There you have the main board which connects to PC and performs the IO for attack and example target (victim) board. But all of that is for R&D purpose only, not for use in manufacturing of final products. I looked up the images for Starfox PCB it looks weird. Can't imagine it ever being practical in production just for programming. Did they just shipped devboards to customers? In the images I saw the area near PCB edge where traces stop looked very smooth and somewhat recessed compared to broken tabs that were connecting PCB to bigger panel. As if that area was cut by router instead of being broken off. Maybe they just kept the production PCB design (almost) identical to devboards, to save the work designing two different PCBs and reduce the chance of any issues caused by differences between devboards and production PCBs.

bluedino 3y ago

A Starfox cartridge was used to make a homebrew devkit for SNES Doom The development was challenging for a few reasons, notably there were no development systems for the SuperFX chip at the time. I wrote a complete set of tools - assembler, linker and debugger - before I could even start on the game itself. The development hardware was a hacked-up Star Fox cartridge (because it included the SuperFX chip) and a modified pair of game controllers that were plugged into both SNES ports and connected to the Amiga's parllel port. A serial protocol was used to communicate between the two for downloading code, setting breakpoints, inspecting memory, etc https://fabiensanglard.net/gebbdoom/ https://fabiensanglard.net/gebbdoom/

rightbyte 3y ago
It is really asstonishing how dev hostile those game consoles were. Like, "we know how to do it but invent it yourself". Nintendo could have released sane sdk:s and not make every dev studio figure out what works. Like, maybe share a toy version of the source of Super Mario and Zelda or whatever to show how an engine is made. The games would surely have been prettier as a result.
- tadfisher 3y ago
  They did have SDKs (well, an assembler and linker) as well as devkits and extensive documentation. The problem was you had to enter an extensive agreement and pay a hefty amount for the privilege of using them. It made sense in that era, as you had to have the cash on hand to order a minimum of 10,000 cartridges (also manufactured by Nintendo) anyway.
- bluedino 3y ago
  Nintendo was dev hostile as well. In Argonaut's case, Starfox 2 was canceled (but still completed) because they didn't want SNES 3D games competing with the soon-to-be-released N64 And then they shot down Argonauts 3D platformer demo, saying they would make their own, causing them to create Croc instead. In a way it made sense because you didn't want to end up with Sega where they kept trying to extend the old platforms. But they weren't looking to create a new in-between or add-on system like the Sega CD or 32X
  - wk_end 3y ago
    TBF you can’t exactly begrudge Nintendo for wanting to end up with SM64 instead of Croc.
    - philistine 3y ago
      That version of history is in contention. The devs of Croc are adamant they basically invented 3D platformers and Nintendo stole their ideas, but the timelines with the first builds of Super Mario 64 rule in favour of Nintendo.
  - MBCook 3y ago
    Oh I didn’t realize they made Croc. That was a good game.
- arantius 3y ago
  > It is really asstonishing how dev hostile those game consoles were... What's actually astonishing is the range of things that seem strange at first, but are actually very clear and logical, IF you also understand the historical context. The path that led reasonable people to make these decisions. Here, see the comments elsewhere about how licensing worked for physical cartridges (they were expensive -- open source cartridge games doesn't make much sense). Plus a dash of copy protection and especially, read into the video game crash of the 80s. This was part of the plan to avoid shovelware (which arguably made Nintendo the success it was). > The games would surely have been prettier as a result. What are you basing this on? 80s and 90s era console hardware was quite restricted, and the software we got did I think all that the hardware could do.

Karliss 3y ago

You can sometimes see a similar approach in somewhat recent (~last 10 years) microcontroller devboards. Many of Nucleo devboards for STM32 microcontrollers, and some Cypress PSoC devboards (CY8CKIT) consist of two halves. One containing the main MCU (the one devboard demonstrates), and other half containing programmer/debugger. Idea is that you can use it as is out of the box for running basic example programs, or you can break it in half thus obtaining a cheap programmer + devboard which has a slightly more convenient format for embedding in product prototype. Similar thing but reversed roles with ChipWhisperer-lite (platform for experimenting with side channel power analysis and glitching attacks). There you have the main board which connects to PC and performs the IO for attack and example target (victim) board. But all of that is for R&D purpose only, not for use in manufacturing of final products. I looked up the images for Starfox PCB it looks weird. Can't imagine it ever being practical in production just for programming. Did they just shipped devboards to customers? In the images I saw the area near PCB edge where traces stop looked very smooth and somewhat recessed compared to broken tabs that were connecting PCB to bigger panel. As if that area was cut by router instead of being broken off. Maybe they just kept the production PCB design (almost) identical to devboards, to save the work designing two different PCBs and reduce the chance of any issues caused by differences between devboards and production PCBs.