Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - turtius

#1
Since momentum has picked up for the for DIGIC 7 & 8, figured its the best time to port DOOM onto the 200D.

Here is the demo showing the DOOM port in action by @kitor who helped with rendering of this port.

Some notes on the port itself :

  • save currently does not work
  • no sound 
  • not all buttons are mapped   
  • WIFI updater is included by @coon
  • gui is glitchy
The fork can be found here: https://github.com/turtiustrek/magiclantern_doom


Compiling

git clone https://github.com/turtiustrek/magiclantern_doom
cd platform/200D.101
make clean && make -j32

Note: this only supports the firmware version 1.0.1
This should produce the autoexec.bin file at the platform/200d.101 directory which can loaded on a boot-flag enabled SD-card.
compiled binary can be found on github: https://github.com/turtiustrek/magiclantern_doom/releases
Executing
Create a directory on the root of the SD-card called 'DOOM' (it has to be in caps) and place the WAD file inside it while making sure its all in caps.
it should look like this: /DOOM/DOOM.WAD
and finally start shooting those demons
#2
The chdk links are dead.
#3
Camera-specific Development / Re: Canon EOS R5 / R6
September 03, 2020, 03:16:40 PM
Quote from: coon on September 02, 2020, 12:48:38 AM
I am going to try out the Jtagulator: http://www.grandideastudio.com/jtagulator/

This device can scan up to 24 pins simultaneously and figures out the pinout of UART or JTAG. You can also set the voltage via software at which the device scans the pins (pretty handy for 1.8V pins).
It is a bit expensive but it is also open source so I will solder it by myself within the next few days.

I will let you let you know once I've tried that out but first the PCB and the parts needs to arrive...
What about the connectors and the FPC cable itself? any ideas?
#4
Well perhaps try loading the ROM dumps into ghidra or ida and compare them with a port which has a port running. Currently i attempted to compare the 50D with 200D (as instructed by @names_are_hard) and found that the dumps are very similar.
#5
QuoteSo far, this is the second camera with "verbose" messages from the MPU, besides EOS R, but I don't remember anyone probing for UART pins on other DIGIC 6/7/8 models, at the time of writing.
Side tangent: I have probed the 200D and got no 'verbose' messages.
Here is a crash from running @names_are_hard repo:

MON>>>
E1OFF

MON>>>[MAIN]:<ERR>( 83)



#6
Reverse Engineering / Re: JTAG on DIGIC chips
February 13, 2020, 08:44:58 PM
i know i shouldn't be bumping old threads but any ideas where to begin for DIGIC7 chips?
#7
Reverse Engineering / Re: Battery grip pins / UART
January 31, 2020, 07:02:06 AM
Okay so i took apart the 200D and the connector was visible. Using a arduino due and a needle i was able to get some logs from the UART.
(115200,8N1)
#8
its about time...
dm me on discord..
https://discord.gg/yBurP7a (discord server invite link.)
The server is pretty much built up and awaiting for users. Hopefully it shouldn't be that difficult
#9
Minor thing about the ROM's and the layout of the canon's firmware and such.. planned stuff and more..
Quoteif you can convince people to use it
Ill just say use the web version... simple as pie
In-fact when the chat 'session' gets old one can just search the whole conversation without the need to ask again here....
#10
IRC is a hassle. Can the smaller discussion be on discord or some sort?
#11
Impressive! Keep it up! I do not have  knowledge on disassembly and reverse engineering and i wish i could help.
Don't stop keep on going(you know i might own a 200D).
#12
QuoteYes, but currently the only notes on the Wi-Fi interface are these (for the old 6D). One could certainly attempt to find the stubs and try that proof of concept code.
My new task.

QuoteI've also found real-time logging via UART problematic while troubleshooting bricked cameras - it's just too slow to print all Canon's messages in real-time. No wonder they are printing only a tiny subset, and even that happens in a background task.
Bummer! Well that saved saved me from evaporating.  :D

QuoteVery interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?
I think that could be a newer revision.
maybe to keep us out?
#13
@kitor How did you measure the pitch of the FPC connector with that small size?

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.
#14
Reverse Engineering / Re: Battery grip pins / UART
June 22, 2019, 06:49:43 PM
This UART connector is also available on the 200D(@kitor suggested)under the 'thumb resting rubber' which is very similar to the EOS R.


#15
QuoteBy looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.
It's exactly the same but the pins could be different.Now its time to dissect a old video player and hopefully find the right FPC cable

#16
I have been looking through several ram dumps of 200D and i was wondering where is the output of the raw DryOS debug messages and for that i need the following question to be answered.(I'd really appreciate it) 

Where is the debug port for the 200D?
can the WIFI or NFC interface be used to send logs to the host (or any suitable interface for logs) ?


I have not been actively working on magic lantern either as i do not know what i am looking at.i just end up brut-forcing stuff which i know is not going to get me anywhere 
Thank you,
#17
QuoteI have a 200D and am slowing porting magiclantern
How far did you get? I mean i am goofing around with my 200D too with the RAM dumps etc .If there was a list or some updates i'd follow it.

Also, any decoded buttons 'codes' are found yet?
#18
QuoteNotice Canon's data structure is a bit larger than the 3 fields I've declared;
Yes i found my self nitpicking each log and found the same result against the ram dump.

QuoteThat means, it doesn't point to the currently displayed buffer, but to the "back" one, for some reason. This code pattern was present on all DIGIC 6/7/8 models I've checked.
Ah! So now i see, when i was changing that region it affected a 'part' of the display which was probably the live view from the camera.

#19
Great News! Future seems bright for these camera's!

Also, (if you dont mind) can you briefly explain the process which took place too find this address when the memory region is  not 'cache-able'?
Thanks,
#21
So I got bored (again).To counteract that I decided to compile the latest branch and run it on actual EOS200D(it works).
The logs that the program created got me to tinker some memory location on the camera.
The first address I tinkered was the supposed 'gain control' which was noted as DispDCtrl:e055f277:42:03: GAIN R:0x0eb G:0x0ec B:0x100
[0] 1.435252
in the log. I went ahead and set the contents of the area to '0x00'(random int) and surprisingly,the camera booted and the display was working perfectly(unexpected). Right after switching the camera to record, there were two separate 'boxes' created which had the live view shifted few places to one another and settled as soon as the camera was still.
I mean this was not useful too anyone but I was inspired. So yeah.
#22
Awesome analysis and work through. I will try to find some stuff with my novice skills. Though you can always PM me to test some code  for the 200D.

Cheers!
#23
QuoteIf lucky, all you need to print Hello World is to modify the contents of that bitmap buffer (which will have to be identified from a RAM dump, starting from the argument of DISP_SetUpdateOSDVram).
...
How would i get a RAM dump? if i cant invoke many location's then  how would i go about getting a RAM dump then?
#24
I recompiled the digic6 branch and dumped the autoexec.bin on my 200D.
What exactly is the OSD Vram? (On Screen Display?)


These two instructions are being executed together at every 'update'.
002FD1BA>    CtrlSrv:e04a0783:04:03: DISP_SetUpdateOSDVram(0x4169ea00)(0)
002FD2E2>    CtrlSrv:e04afd6f:04:03: refresh x=728 y=442 w=84 h=60


How can i poke this function? i mean what would be minimalist code required to poke a function
#25
Quotefiguring out how to print things on the screen (i.e. a software-only task)
How were able to achieve that with the ROM dumpers?


Quote- 200D: proof of concept code available;
Is it from the digic6-dumper branch? The same one which you gave me few months back?