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

#426
Yes, standard install using the FIR linked in the first post to enable bootflag on cam.

I cannot quantify the risk of bricking.  To my knowledge ML has never bricked any users cams (only some devs, when doing work to understand the cams).  This release for 200D has a small number of features and has been tested by about 2 and a half people.  I tried to code it in a cautious way to minimise risk, but it can never be risk free.
#427
Reserving.
#428
Don't get too excited - very few features work.  But, it's ML, and it's on 200D.

Edit 2022-10-31: bugfix ROM dump function in Debug menu, offsets needed updating.  Build zip link updated.

Build: https://github.com/reticulatedpines/magiclantern_simplified/releases/download/release_200D_2022-10-31/magiclantern-Nightly.2022Oct31.200D101.zip
Firmware version: 1.0.1
Bootflag enabler: https://a1ex.magiclantern.fm/bleeding-edge/200D/BOOT200D.FIR
Repo: https://github.com/reticulatedpines/magiclantern_simplified

What works:
- ML menus
- 30 min LV timer disable; AKA webcam mode (NOT normal video recording, a 30 min limit remains here)
- Shutter count
- Screenshots
- ML overlays in LV
- various debugging features (crash logs, task mon, etc)

What doesn't work:
- everything else

To exit sub-menus, use Av, not Q.

I would describe current status as a framework for porting ML to new cams.  A lot of the work has been on internals to support the differences between old and new generations, as well as changes to the repo and build system to make it easier to use on more modern systems.  It's much easier now for new devs to join in and work on things without too much pain.

ML boot process, inputs and GUI work on a wider range of cams in test, including: 750D, 850D, M50, RP, R.  These are either not stable enough yet, too early to release a build for, or nobody with time and access to the cam is available to support it.

It is possible to use ML APIs to patch arbitrary RAM and ROM locations on Digic 7 and up.  This means all features that classic ML supports can be ported - if the hardware supports it.  This still leaves many unknowns, but does mean if you want to do dev work, you have a lot of power to investigate capabilities.

For cool features, the main thing we need are devs with time and ability to reverse engineer camera and OS internals, especially the DMA controller.  This is how raw video works, instructing the DMA controller to map devices together in a way Canon GUI doesn't expose.  New cams do this differently than old cams and so far this area isn't well understood.

Newer cams are very powerful, they just need work to free that power!

Large pieces that were required to get to this point:
- boot code for each new digic generation (A1ex, me)
- handling the new display / GPU (A1ex, kitor, me)
- fixing lens info for overlays (kitor)
- fixing task handling (turtius, me)
- MMU patching (srsa, me)
- module support (me)

Special thanks to Kitor for code reviews, design discussions and git help!

Special thanks to coon42 for PCB design for UART connector:
https://github.com/coon42/magic-lantern-dev-kit/tree/master/cable/gerber

Special thanks to Walter for many boring 200D tests on physical cam,
and answering thousands of ML questions in Discord.

https://i.imgur.com/yvZX1V1.mp4
#429
Per cam profiles could be nice.  Assumes there is some unique cam ID you can get, I guess likely.  Not sure what people would use them for since it depends on what other features you implement :)
#430
Quem is typo of qemu.

The IO trace log reddeercity is talking about is not a normal log, and can give you lots more info than you normally see, and can help.  Fundamentally, he's saying that since you don't understand why it works, you can't know if it works safely.  Which is a reasonable argument.

I do wonder if this is really related to dropping the speed for reads, it seems weird that would help (possible!  But strange - the card is rated to do higher speed reads than writes).  Here's a few tests you could run:
- do a 240 write, then change clock to 240 before doing a read: perhaps it's not 160 that fixes the read, but doing a mode change.
- do a 240 write, then change clock to 160 (or whatever is supposed to be good), but don't do any reads, then change to 240, then do the read.  Perhaps 160 is relevant, but not required to be the final selected mode.
- do a 240 write, don't change clock for the read but do trigger a small pause.  Perhaps the change to 160 helps simply because it takes some time, and this lets some other part of the system become happy.

These kinds of tests could be combined with IO trace to help us work out what the critical factor is.
#431
General Help Q&A / Re: Which camera do I get?
August 28, 2022, 05:54:31 PM
Yes, the AF is weak on these cams in video mode.  If you're streaming a talking head you probably don't care; put it in one-shot, tap half-shutter to AF once, then never change it.
#432
General Help Q&A / Re: Five questions
August 24, 2022, 07:18:47 AM
5K is not upscaled 1080.  See this long thread: https://www.magiclantern.fm/forum/index.php?topic=25781.2925
#433
Quote from: tdnelson2
I started a repo to develop a 010 Editor Template for parsing MLV files.

You have defined things as uint in the template when they are uint8_t in the struct def from the header.  Uint is probably size 4.  uint8_t is size 1.
#434
Feature Requests / Re: Parametric ISO
August 16, 2022, 03:01:22 AM
Are you saying you want different portions of the same exposure to be captured at different ISO?  If so, this is not possible - the sensor accumulates light / charge with nothing like ISO being involved.  Only when the sensor is read out are amps used to select ISO - and at that point all the light for the exposure has already been collected.
#435
Dual ISO now works on 200D.  So that's nice.  Process is similar to other cams, but the data format for ADTG / CMOS registers appears different, here are some examples:


0b400000 // ISO 100
0b444440 // 1600
0b440400 // Dual ISO, 100/1600
0b455550 // 3200
0b466660 // 6400
0b466660 // 12800, so presumably this is boosted further elsewhere and is non-native ISO


I'm currently assuming this means the data is now 16 bit, and b4 is the register index.  The lower and upper 4 bits are used by some commands.
#436
It would contain image data and would be displayed.  But I'm happy if you don't want to do this.  Just buy some cloud storage, really.  It'll be $10 a month or less and won't be randomly removed in the future like this Photos offer, and you can simply upload MLV without any of this fuss.
#437
It's exactly what your current plan is: store the content of a filetype that's not covered, by splitting the data into multiple files that are covered.  You're only "storing images".  Both are equally against the spirit.
#438
You've misunderstood; you don't need to know anything about the internals of MLV for this approach.  Just slice it up so each piece is small enough to fit in the image data of a DNG (or any raw format Photos supports).
#439
Quote
Any tips on how I can get started on implementing this? This type of software development is pretty far out of my wheel house

Any file can be considered a long list of numbers.  The image data in a raw file is also a long list of numbers (the pixel data).  Chop up the file you care about into the correct sized pieces, and copy the numbers into the raw (in the correct place for it to be the "image data").  Repeat until you run out of source file.  Name each generated raw file sequentially or whatever.

Somebody always does something like this when there's an "unlimited" storage deal going, and the deal always gets shut down in a year or two (especially when somebody starts using it for storage of unsavory content).  Amazon Photos may last longer since it's not free.

EDIT: in case it's not clear - I am recommending you don't do this.  Just buy some cloud storage, it'll be much less hassle and won't get shut down in the future randomly.
#440
Since your game plan is to abuse Amazon Photos to store video, and you already expect to do work after downloading the "photos" to reconstruct the videos *and* since Amazon Photos allows storing raw images with no alterations:

Chunk the video up into pieces and store each piece as b&w data in a series of raw images.  Perfect reproduction of any file.  Easy to automate.
#441
crop_rec_4k_mlv_snd is very close to lua_fix, lua_fix was merged into it "only" 2 years ago:
https://foss.heptapod.net/magic-lantern/magic-lantern/-/network/branch%2Fcrop_rec_4k_mlv_snd
https://foss.heptapod.net/magic-lantern/magic-lantern/-/compare/branch%2Fcrop_rec_4k_mlv_snd...branch%2Flua_fix?from_project_id=321

Merging these would be easy, so merging to mine shouldn't be too hard; I've already done the hard lua_fix + unified merge.

But that's enough cluttering up this SD card thread!  Let me know if you get the merge working, and I'll let you know if I do :)
#442
Quote
Sure, I can do tests later, but I am not very interested in unified branch which is the main one you are using in magiclantern_simplified.

Nope - unified is too old.  Mine is unified + lua_fix + qemu + some other ones (I forget...  there are so many open branches on official, I wanted to get away from that).  I want one long-lived branch only (and stable / release branches, no work happens there).  Other branches are for feature work only, before merging into dev (the main branch).  I nuked a lot of history because it was too confusing to understand, hundreds of branches.  I made that magiclantern_hg_02 repo to keep all history from all branches preserved in case it was needed.

Quote
I think lua_fix is similar to unified.
I don't really know, because I don't know of any documentation for what the different branches are for (other than commit messages), but in practice, lua_fix was the dev branch for several years.  It has many changes that are unrelated to lua.  I think the intention was to merge to unified, but this never happened.

Quote
I think we need to import crop_rec_4k_mlv_snd in magiclantern_simplified repo, then we need to find a way to merge dev branch and crop_rec_4k_mlv_snd correctly, but I think these two branches have a lot of differences, things might break, if that works I have no problem to work in your main branch.
I can look at this and see how different they are.

Quote
For now I think the best way is to stay in my fork of magiclantern_hg_02, and port the new D45 crop mode stuff in one place, and probably merging other branches if it make sense, then importing the updated crop_rec_4k_mlv_snd to magiclantern_simplified then dealing with merging it to e.g. dev branch (unless if you have other plans).
That would also work for me.  I warn you that the different official branches are painful to merge.  I had to inspect several 40k line diffs.  Fun.  Make sure you have some free time :D
#443
Quote
Anyway, I said before I would rewrite my 650D/700D/100D code in a clean way and make the repo has native git support (no needs for hg / mercurial), and actually re-writing in progress and it might take some time:

https://github.com/bilalfakhouri/magiclantern_hg_02/commits/crop_rec_4k_mlv_snd

My goal to include the latest achievements for all DIGIC 5 models in a clean way in one branch (includes 100D/650D/700D/5D3/EOS M and probably 6D and 70D). Beside a basic support for DIGIC 4 models.

My main ML repo has git support already.  The commits that do that work are here:
https://github.com/reticulatedpines/magiclantern_simplified/commit/4a29a347f29276d4bec0876412cec4bb12b5a28c
https://github.com/reticulatedpines/magiclantern_simplified/commit/3163d41cee35fb54b4308e1f32318ff87de53645
(I think there might be a third commit near that time, too.  But that should be most of it).

In theory, that repo should work on Digic 4 and 5 cams.  It's been tested, a little...  I'd be interested to learn if your modules work with it - but test in qemu first!  You'll need to copy your module code to my repo and build there, because I made changes to how modules are compiled.  The official repo has a serious bug that can make modules jump to incorrect address when doing calls, triggering bad crashes.

Do you know if crop_rec_4k_mlv_snd is very different from lua_fix?  My repo has lua_fix already (and some other branches, merged together), so you may find it's not that hard to merge your changes into mine directly.  You're welcome to take the hg removal commits whatever you choose.  I think even better would be to recognise if the repo is hg *or* git, and work correctly for both.  It's nice to have the commit tag in the build info screen, which mine currently doesn't do.
#444
General Development / Re: ML code reviews
July 23, 2022, 05:39:41 PM
Ah well, thanks for considering it :)

Reviewing can be quick, but can be slow.  The cache hack change is small and easy, I think an hour or less.  The MMU work is larger and more complicated, several hours minimum, so might take a few days of spare time.

Sounds like I will have to more carefully consider my own code - at least it's good to know.
#445
Cool, nice proof of concept.  SD frequency is a better name.  I like it being part of benchmarking generally, unrelated to sd_uhs module.

We probably want to check if the reg addresses are the same for D678X, if they're not it will get a bit more complicated (either use is_camera(), or a getter function in ML, so different generations can read from different locations?).

I think naming them as the addresses is quite confusing, maybe reg_C0400614 style?  sd_frequency should probably be static, no need to make it global.  I don't see any point in making the reg reads volatile, they're only used once.
#446
Thanks, nice summary.  I agree, nicer to read it back from the cam, to detect what is really being used, not what we think should be in use.

Is this as simple as reading back the ADTG regs, does that give us the correct info?

(I've seen some screenshots now and Mode and Global Draw are already listed, I didn't realise that)
#447
Makes sense to me.  Mode and global draw are easy I think.  OC freq I don't know how to query, I haven't worked on that code at all.  Read back register values I guess?  Or maybe there's a Canon API?  I'd need someone to show me where the OC setting code is.
#448
General Development / ML code reviews
July 21, 2022, 03:42:42 PM
Hello!  It's hard to find people with the ML knowledge to do code reviews, so perhaps devs on here would like to arrange something?  We could swap reviews for changes.

I have two recent changes that I'd really appreciate a review for:
- module changes that make cache hack usage compatible with Digic 678X (and fix a bug in the build system that affects all ML repos): https://github.com/reticulatedpines/magiclantern_simplified/compare/dev...d45_cache_fix
- working but minimal framework for MMU memory patches on Digic 678X cams: https://github.com/reticulatedpines/magiclantern_simplified/compare/dev...mmu_investigation

The MMU commits are kind of ugly and need cleaning up before merging, I'm not asking for a full review there but some validation that the general approach is sound.  Testing on cams isn't required, although the D45 branch should make builds that work on older cams (this has had some testing: thanks Walter!).

I'll review your weird hacks in exchange!
#449
Raw Video / Re: Canon 60D RAW Video
July 07, 2022, 04:20:16 AM
This is lucky imaging, yes?  Raw image quality will be quite a bit higher, but if you have to lower fps to 30 you may get more atmospheric disturbance.  I think you'll have to try it and see.

If you can upgrade to a 650d you should be able to do 640x640 at 50fps.  With lossless compression 800 something, with SD overclocking perhaps as high as 1280x1280 60fps.  I am sure the 650d would be much less than your scope and mount, plus you'd get some back if you sell the 60d.
#450
Cool, probably SSE4.1 then.  I think 64 bit builds should work fine for you so long as they don't include that.  And 32 bit OS *can* use SSE4.1 (and all other SSE), just not your core2duo because it is super old ;)

Quote
Even before no feature used it in win32 version, just the compiler flag was enabled
The compiler will optimise using sse4.1 ops when it feels like it, can happen in any code.

The sophisticated fix would be something like: use CPUID to detect features at runtime, build multiple object files, some with sse4.1, some without, and swap function pointers / load different DLL or .so based on CPUID results.  Probably quite annoying work to do.

CPUs from about 2008 should have SSE4.1 and 4 is a big upgrade from prior versions, I expect you'll see noticeable perf drop with it disabled (have to test to be sure, of course).  How much do you want to support 15 year old hardware?