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
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.
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
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.
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.