Discussion Big News on NUON Controller Development

[sixersfan105]

Yep, rotary controllers have been done in the past (a very small run) using the "Yak Twister" boards made by Lee Olivares (he who must not be named) - he's the guy who has been hoarding the polyface chips and refuses to play nice with anyone. Here's a video by Nick P. (a good guy) who has made a few NUON rotary controllers from those boards:

and then here is another he made:

 

[Stephen]

Lee Olivares (he who must not be named) - he's the guy who has been hoarding the polyface chips and refuses to play nice with anyone.

We call those people "cunts". This is acceptable here because most of the VMLabs folks are British, and they use that word the way Americans use "the" (according to my wife who has learned to accept it)

 

[midnight8]

glad to hear progress is being made. Lot of units out there with no controllers

 

[Wire]

Yea found the forum posts on the rotary controller looks like when you restrap the polyface chip it will take rotary inputs.

Key info from eltoozero on atariage:

Nuon Game System Talk & Discussion

atariage.com

The key is putting controller in "CONFIG UPPER4" mode by setting MODE_A to 8.25k and MODE_B to 1.82k, then setting the "UPPER4" bits 5,6,7,8 to low, high, low, high, which produces a properties value of "1000" in hex as seen by the controller dump program.

Some other interesting info in the next post of the thread. Anyone out there have the polyface chip manual he references?
The emulator chip I have been working on I am to the point where I can get the software to detect it and pop in the initial analog values and status but then it stops updating until the unit is rebooted. Also if I have the emulator chip attached when it boots I get no video out of the player...
Guessing I am missing some packets / handshakes still. Going to fire the snoop code back up and see if I can find what I missed.

More digging:

YakYak • View topic - The Yak Twister

that thread by the same person has lots of technical details on the conversion.

Is this obscure enough for you?

Is this obscure enough for you?

geekhack.org

has a close up of the rework

 

[The Helper]

Sticking this thread. I am really confident we are going to get a controller solution but I can tell you right now it will not happen until next year. Unless you hear about a break through it is the hard way and it will definitely not be until next year as the controllers or adaptor will still have to be made. 2023!

 

[mgarcia]

Some other interesting info in the next post of the thread. Anyone out there have the polyface chip manual he references?

I think it's the 'NUON port data' folder from: https://www.thehelper.net/threads/y...chematics-manuals-and-more.24167/#post-200260
The images attached are the contents of that folder.
Also the Serial Adapter Schematics folder contains polyface 1 info, attached.

I'm guessing you have a controller right? and sniffing out the communication is sent and received?
Going by your image, it doesn't looks like you are tho, because you wired up wires straight to the controller port to the breadboard.... that's impressive!

Any chance of an update, with info on how to replicate? would love to have something close to a controller



Here's the relevant parts in that long post.

By reviewing the spec document we were able to suss out the pinout and luckily we had access to a controller "dump" program which displays the properties of connected controllers.

The Polyface is an interesting chip, it handshakes with the Nuon console and exposes various "features" on the controller to the console, managed by drivers in the Nuon system BIOS.

The "features" on the particular controller type are determined by a pair of "mode resistors", there are main modes and config modes; the config modes tell the chip to read a bitmask from 8 digital input pins.

There are pins to connect the rotary per the spec document, but we determined there was a hidden ground plane under the chip grounding the quad input pins, meaning we needed to lift pins...

 

[Wire]

Thanks for the link will try and dig though it this week. I "think" I am getting good traces now. Going to try and collect a few sets of traces of the real remote and try and see what I can pick out on the init strings. Have the button packet figured out but running into issues that lock up the player on init.

 

[Wire]

Read though the documentation and some of it seems to line up with the traces I have taken (Found the command that transmits the ID then nothing once initialized). But other parts do not. (Documentation says ID 0xFF should be system commands but I don't see any 0xFF anywhere in the transmission. This may be due to some sort of bit scrambling still digging on that one) Got 5 clean traces of boot no controller, boot with controller, and boot then hotplug controller. Starting to dig though those traces and seeing if I can sort out what is going on.

 

[mgarcia]

I'm starting to think, the controller doc (images above) isn't as useful as I thought... it doesn't mention "polyface", instead 'interface controller'...
And the "MMP-L3A" is from the Nuon prototypes, so I guess that controller info is so old, it's probably useless :/

Aries 1 (MMP-L3B) is the first production NUON device. It is the successor to the pre-
production prototype known as Oz (MMP-L3A).


Which could explain the separation of data lines (DO and DI) in that doc, where as the retail DVD controller ports only have a single data line, maybe that's the main function of the polyface, a serial to parallel chip for devices and parallel to serial into Nuon's bus.

I'm just guessing, I'm a hobbyist EE

 

[Wire]

Could be still poking here. Been a bit busy lately but trying to put a few hours in a week on this. I think I have enough to try and emulate the controller detection. Going to try and code that up on the second pico and see if I can get a trace while it is running.

 

[cubanismo]

I did a deep-dive on the available controller documentation I could find. Below are my conclusions and ideas for further research.

The above "Polyface manual" images appear to be excerpts from an old version of the Nuon Architecture document. They line up almost exactly with the Aries 3 Nuon architecture OEM document shared various other places, which appears to be the latest version available. The only changes are:

• The Aries 3 version notes the transfer rate is programmable, to match the rate supported by the connected device. The old version just says it is up to 1Mbit/s. I'm not sure this actually indicates any difference in capabilities. Both amount to the bust being of variable data rate, but perhaps there's an underlying change in how speed is negotiated somewhere. There's no description of such a mechanism in either document.
• The Aries 3 version lists the DO and DI lines as one combined data line. This makes sense. They probably combined these lines at some point as the protocol only allowed transmission in one direction at a time in both the old and new versions, so no need to waste a pin on separate lines.
• The Aries 3 version does not explicitly define the 8-bit device ID field in command packets. The earlier version also notes this is an entirely SW/user construct and not baked into the hardware (Note in both versions this document is documenting the host side, I.e., the Nuon chip, not the device side I.e. Polyface chip. Who knows whether this field is baked into the protocol handled by the Polyface chip, which could be a subset of that the Nuon is capable of).
• The Aries 3 version excludes the description of the initialization sequence. This is a bummer. I don't know if this implies it has changed, or if VM Labs just felt (presumably) DVD Manufacturer-style OEMs didn't need this information. Doesn't really make sense though, because it seems as relevant as any other information here from a host device manufacturer POV.
• The Aries 3 version excludes the description of the splitter device. Similar to the init sequence omission, not clear why. For whatever reason, details of this level of the protocol seem to have been scrubbed from these later document versions.

I have no proof, but my gut tells me the earlier docs should still accurately describe at least the mid-level details of the protocol. The structure is pretty simple, and I'm not clear why they'd change it. Some details that are covered in both documents (E.g., the device reset sequence described in the definition of ctrlStat1/ctrlStat2) are the same, and sort of imply parity on the omitted parts to some degree (E.g., the reset bitstream wouldn't have $FF in the high bits if $FF wasn't still a broadcast device ID is my guess). Hence, I'm a little worried that if you're not seeing the $FF Device ID packets being transmitted by the Nuon at init time @Wire, the traces may be missing something. I'm curious what your current understanding of the init sequence packets is based on traces. Could you share your current notes?

It may be interesting to approach this from the software side as well, to validate or supplement the hardware sniffing work. We have dumps of the N501 BIOS ROM, which should contain the routines to detect, init, and poll data from the controllers per the BIOS documentation in the official SDK file "doc/Misc/bios.pdf". Since we know the registers used to do this and what they do, we should be able to search that code for the relevant register reads/writes and suss out the packet format of the relevant commands from that. No rewiring or hardware required. Does someone have a disassembler for MMP code? I believe Nuance has one built in, but I'd have to go dig it out and see if it can be made to work stand-alone, if Nuance includes real BIOS code or just minimal reimplementations of the user-facing BIOS "syscalls," or whether I can coerce Nuance to load the BIOS dump code and view it from within Nuance.

 

[cubanismo]

I put some work into this today and last night, but no real findings yet, just updates on methodology and tools.

• There's a disassembler in the VMlabs SDK: vmdisasm. It's a little light on documentation, in that it has none I could find, and the usage information it prints when you run it without parameters is so opaque I had to open the disassembler itself up in an x86 disassembler to figure out the syntax for the "range" parameter. If you're wondering, it expects something of the form "<start address>:<size>", where "<start address>" can be a number in hex, decimal, or octal format (0x prefix for hex, 0 prefix for octal. It uses the standard strtoul function with "0" for the base parameter if you're familiar with the C standard library), or a symbol from the binary. It only works on cof programs and object files as far as I can tell, not raw binary files, but there's a workaround for that. The version in the official SDK also crashes a lot if you give it invalid or slightly valid input, and it just up and stops disassembling if it encounters an invalid instruction, meaning you often can't just throw it a blob of code+data and have it disassemble the whole thing in one go. You have to disassemble until you hit an invalid instruction (Generally this is because you're trying to disassemble data), then sort of rummage around in a hex editor until you think you're looking at code again, then restart disassembly at that point. It also only accepts addresses in the Nuon address space, I.e. the loaded address, rather than allowing you to specify simple offsets within a file. Major pain.
• Nuance has two real BIOSes in it as raw .bin files (One called "vmlabs_bios.bin", one from the N501), and someone's clearly already been disassembling them and added a lot of helpful annotations to the disassembled code. They're partial disassemblies, so I had to disassemble more sections as I tried to walk through callchains, but it saves a lot of time. I've been working the vmlabs BIOS so far, as it has more pre-existing disassembly and annotation. Most importantly, this saved me trying to track down another BIOS dump or rip the flash chip out of its socket in my N501 to make my own dump. It also had examples of the mildly clever trick needed to disassemble .bin files with vmdisasm: Build them into a coff executable by including them in an assembly source file via .incbin and compiling that with llama, the SDK assembler, using the -fcoff output format.
• The application-facing controller routines are already disassembled and lightly annotated. _ControllerInitialize() is the one where I started tracing down, as it makes it clear the System Timer 0 interrupt is used to handle sampling controller data. It also initializes the _Controller data structure the other routines read cached data out of. Knowing the address of that struct, I was able to grep through the other disassembly for it looking for something that writes to it. In the vmlabs BIOS, the controller data structure lives at 0x807b8490.
• The main body of the system timer 0 interrupt handler routine that updates the controller data structures appears to live at 0x80791548 in the vmlabs BIOS. However, I haven't been able to fully trace through it yet. It calls a bunch of subroutines that call other subroutines, and I haven't been able to track down where in the callchain it reads or writes comm bus data, either directly or through another queue of data from another interrupt handler.

So still more work to do, but at least things are making sense and I haven't hit any dead ends yet.

 

[Wire]

Attaching 6 files. One is a boot trace with no controller attached. The second is the boot with controller. The third set is hot plugging in a controller post boot. I also have the same file annotated with my best guesses. Was hoping to get more done this weekend but home repairs sucked it all up.

 

[cubanismo]

Awesome, I'll do my best to double check everything and line it up with the BIOS-side code. I had a free hour and made it a few more levels down the call stack last night, but my time is similarly limited and I'm still getting familiar with the NUON instruction set. No breakthroughs yet.

 

[midnight8]

BAM!

OK so I saw that someone leaked out the information on this on Facebook already (Carl) so I guess I can talk about it now. I sent my NUON controllers, one Stealth and one Logitech (for the analog) so that Carl from Songbird could clone them. Based on what I have heard we have success. Looks like a mid year release but do not quote me on it just wait for Carl to make the official announcement. And we did not even need the Yak Twister guy either he just slowed us down just saying. Way to go Carl getting that going on glad I could help!

nice

 

[The Helper]

nice

Yeah that is old though and it is not done. Carl and Wire are working on it still.

 

[The Helper]

Some controller info here https://www.thehelper.net/threads/nuon-has-been-added-to-mame.176004/

another related thread: https://www.thehelper.net/threads/the-nuon-controller-people.175956/

 

[The Helper]

This is a double post but here are the NUON controller schematics in the right thread

 

[Wire]

Major progress:

https://twitter.com/i/web/status/1599239440555069440

TLDL
We have a stock (knockoff) N64 controller talking to the Nuon. Note this is only tested on the N501 so far with the controller utility, Free Fall (how do you play that game) and Iron Soldier.
Working on getting more games / system to test against. everything maps over 1 to 1 other than the Nuon button which is currently mapped to the Z button. (Would being able to swap the mapping of the Z with some other button be useful for some games?)

Starting work on the final card design but also need to find a source for Nuon connectors / cables. mini Firewire does work but Carl is looking into if we can get something closer to the original made.

 

[sixersfan105]

Oh snap, NUON USB controller adapter preorder! https://controlleradapter.com/products/nuon-usb