Thanks for letting me know. I was trying to find a datasheet for the chip in question. I don't like the rcmx86 sleeping with a pin held high. I was actually messing around with this fix month's ago trying to fix another problem (couldn't get in to uf2 mode). Didn't work. Ended up swapping the pin arrangement.
I forgotten about it to be honest and kiwi reminded me!
--------------------- MERGED ---------------------------
No. The problem was in the original armoured dildo(Arduino) code.
So let's say one decides to use the hekate UF2 from the RCMX86 github. Will the user run into the same issues?
Sorry for so many questions, but I'm still deciding what's the best option with this chip.
No they won't run in to the same issues. Switchboot uf2 is built with 2 components... The bin itself and the payload pusher (ie like tegrarcmsmash or fusee-gelee). The switchboot bin (just like Hekate) was not the source of the problem. The problem was in my implementation of the rcmx86 chip into the "payload pusher" software. But the overall problem is my memory. Back in the day, I was a decent programmer. But just a shell of that person now. At least when it comes to C. Life lesson: don't do drink, drugs or women... It makes you senile.
--------------------- MERGED ---------------------------
The best option is either uf2. I'm not sure how many other people have made uf2 for this chip, but that might be worth a look. I don't think there is much more I can do. We can use the chip to push payloads (which was all it was meant to be) but we also now use it to enter RCM and save fuses... As well as restore licences too!
What I really really really want is an ipatched board. I've noticed a few things on the Jetson (not going into it now... That's a whole different pizza.) And I want to see exactly what is possible.
Drinking and drugs are ok, but no women
Will the firmware images from the creator of the RCMX86 also drain the battery during sleep like your current implementation?
I'm thinking about removing the USB IC, it seems to be useless anyway if I'm not mistaken.
It isn't much use to us or the end user. I think during design, it was meant to fix a different issue (we used to use an umbilical to vcc-in on m92t36) and this caused a couple of problems. The standard usb interface on the samd is fine.Drinking and drugs are ok, but no women
Will the firmware images from the creator of the RCMX86 also drain the battery during sleep like your current implementation?
I'm thinking about removing the USB IC, it seems to be useless anyway if I'm not mistaken.
Did you ever see the RCMX86 without the USB IC ?
I see that the USB pins on the SAMD lead somewhere below the USB IC.
I did a little continuity check right now, but I can't seem to find the pins where they lead to - maybe you know more.
It works perfectly, and as said before, everyone makes mistakes, don't be hard at yourself.
That's why pencils come with a rubber
Illl leave that up to you... Just back up your current uf2...
USB issues seem to be hit or miss. I have no idea why. Possible that the USB logic maybe latches in the "correct" position maybe?
Or you have some power getting to D3 somehow (maybe through a removable SMD resistor). The USB logic is connected by an umbilical to D3. So, another way around the problem, in theory, is supplying D3 with power
Yeah. We had problems accessing UF2 bootloader. You remember? I was playing with D3 thinking that was part of the problem.
So, the easiest and fastest solution was to get away from D0 and D3 and use D1 & D2 as they are completely unused.
No. Because in all my UF2s for the RCMX86, D3 was unused. I enabled the (missing)LED on it for a time but got rid of that.
Since we changed to D1 and D2 (fixing UF2 drive access), D3 should be free. That is naughty of the designers actually. There are enough spare GPIOs to use a dedicated one for the USB logic.
But, at the time, I think the designers thought they were solving issues (and at the time they were), but things have moved on and those "fixes" have become problems in themselves. The USB logic looks like it was added to the design for possibly 2 reasons...
1 - to provide a way of initial flashing of the G18
2 - To "hard shutdown" the USB port as we were getting conflicts etc etc before we grew a brain and learned wehat we were doing... Remember it was early days
And why use D3 and not another pin? Because of the Trinket. They wanted it to be "Trinket" compatible in the Armoured Dildo IDE. Hindsight would be just to get rid of the USB logic...
Last edited by mattytrog,
@mattytrog just for my understanding - let's say I remove this USB IC and hardwire the D- / D+ pads to the SAMD21, what UF2 images could I use?
The reason I ask, is because I don't want the chip to draw any power while in sleep mode, even if it's just a few µA as you said.
But for some reason I can't grasp the concept of these UF2 files for each chip.
All of them say, that they are "clones" of the trinket, but built specifically for the switch to be used as modchips.
So wouldn't that mean we can use ALL the UF2 files available on each chip ?
Example:
Let's say I modifiy the RCMX86 and remove the USB IC - would I still be able to use your UF2 files?
Or can I use the ones from the modchips github here ?: https://github.com/euclala/RCM-X86
My understanding is, that UF2 files are a program combined with the payload of choice.
And the program parts needs to know the pinout configuration of the chip.
So if I remove the USB IC, I shouldn't be able to use any payload from that github above, correct?
The reason I ask, is because I don't want the chip to draw any power while in sleep mode, even if it's just a few µA as you said.
But for some reason I can't grasp the concept of these UF2 files for each chip.
All of them say, that they are "clones" of the trinket, but built specifically for the switch to be used as modchips.
So wouldn't that mean we can use ALL the UF2 files available on each chip ?
Example:
Let's say I modifiy the RCMX86 and remove the USB IC - would I still be able to use your UF2 files?
Or can I use the ones from the modchips github here ?: https://github.com/euclala/RCM-X86
My understanding is, that UF2 files are a program combined with the payload of choice.
And the program parts needs to know the pinout configuration of the chip.
So if I remove the USB IC, I shouldn't be able to use any payload from that github above, correct?
Last edited by FR0ZN,
The difference is between pinouts on the chip.
If all boards used the same pinout and if all didn`t have a crystal oscillator connected, then yes. We could use the same file.
For example...
Trinket vs Feather: Same chip type(MCU) - One is a QFN/QFP 32, the other is a 48... pinouts completely different. Feather has a crystal, Trinket doesn`t.
Another example
Trinket vs RCMX86: Same type again... One is 32pin, one is 48pin. One has an extra IC, the other doesn`t. The wiring needs to be different for the RCMX86 just because of the extra IC.
The only one that is the same is the Rebug and Trinket. Different versions of that exist JUST so the correct chip is reported in straps_info.txt.
I wasn`t going to accomodate any extra boards at all. But Trinkets were scarce and it gives people more options.
If using JUST a 4 wire setup, it doesn`t really matter which file you use... Apart from the external crystal oscillator, there will be no LED indication due to pin 13 on most boards is the LED. But this "Pin 13" is a different physical pin on the chip. And your chip could spontaenously reboot due to capacitive pins set up to accomodate the very old methods of fitting.
Thanks for your reply !
I want to run some tests with this chip and different UF2 / Payloads.
What I want to try first is the following:
1) Remove USB IC and wire the 2 USB pins from the SAMD21 to the D- / D+ pads like you showed here:
2) Flash this hekate 4.6 UF2 as a base: https://github.com/euclala/RCM-X86/tree/master/hekate_ctcaer
3) Use UF2-Splicer.zip (awesome tool btw) - to switch the payloads in the "CURRENT.UF2" on the SAMD21
Do you see any problems there like you mentioned in your quoted post?
Thanks and regards!
Not really problems... Wondering why you need to use different UF2 files. That would make no difference whatsoever.Thanks for your reply !
I want to run some tests with this chip and different UF2 / Payloads.
What I want to try first is the following:
1) Remove USB IC and wire the 2 USB pins from the SAMD21 to the D- / D+ pads like you showed here:
2) Flash this hekate 4.6 UF2 as a base: https://github.com/euclala/RCM-X86/tree/master/hekate_ctcaer
3) Use UF2-Splicer.zip (awesome tool btw) - to switch the payloads in the "CURRENT.UF2" on the SAMD21
Do you see any problems there like you mentioned in your quoted post?
Thanks and regards!
You see the green and yellow lines in the pic? They are USB ready. They can be linked straight to for example a micro-USB connector if you wish.
If you remove the logic chip, you are effectively turning the chip into a mini "trinket" without LED or DotStar. There will be no drain at all from holding the "enable" pin high during sleep.
And because at that point, nothing is connected to D3 taking power, you can leave it high or low. Makes no difference as nothing is taking power from D3 as it is unused.
So, no need to mess around with old software.
And yes. UF2 splicer is good. But I prefer doing things the manual way. I don`t trust anyone else to do it for me. Especially how we chop up and dissect / regenerate the payload on-the-fly via chip firmware
Last edited by mattytrog,
Similar threads
-
-
-
-
@
Psionic Roshambo:
But other than PC and Amiga ports I don't think Time Soldiers had any game system ports after the Master System -
-
-
@
Psionic Roshambo:
Ohhh just noticed that myself I bet it makes the Master System port look amazing by comparison lol
-
-
-
-
-
-
-
-
-
-
-
@
SylverReZ:
If you want a good system to port it to, at least have a good programmer and knowledge.+1 -
-
-
-
@
Psionic Roshambo:
I didn't know they made an MSU cart for the Genesis.... I knew about the SNES one and the library for that is rather large but the Genesis one has very few games+1
-
-
-