Interestingly, this could be circumvented - the boot rom does the logo scroll using data from cart, THEN, in a separate loop checks it vs local copy. If you can make the cart read different data at each stage, you are golden!
IIRC Argonaut/Jez San had a POC of this using a very simple hardware bodge, intended as a potential way of publishing Eclipse (What became X) without a Nintendo licence.
Fortunately - Nintendo were interested in the 3D rendering, and that started the SuperFX/Starfox/ARC journey.
First would type out a few lines of code incredibly fast with lots of mistakes (and not bothering to backspace over wrongness) - then go back and clear up damage using notepad level editing.
Second would stare fixedly at screen for several seconds, whilst remaining still as a statue, then carefully emit the minimum string of editing commands to achieve the change.
Their actual rate of progress was pretty much identical.
> Second would stare fixedly at screen for several seconds, whilst remaining still as a statue
That eliminates many of the benefits. Was your coworker relatively new to Vim? Or maybe pondering what change to make, not how to actually make it? This is what I've seen from a coworker who was learning Vim and forcing themselves to learn the "proper" way to do things. I don't consider that to be a bad thing, provided that you balance it with actually getting work done.
I always do whatever allows me to edit the line without or with relatively short pause. That might be efficient vim commands, or it might be sloppy if the line isn't formatted in such a way that it fits my muscle memory. If I'm dissatisfied with the edit and think there might be a better way, I research it after the fact so I can later practice and know for next time.
This comes with experience; I've been using Vim for over a decade. Any pause in my editing is because I'm actually figuring out what change to make, not how to make that change.
They were reasonably experienced, but had an appetite for optimization beyond what most people would consider reasonable. In defense however, the task at hand was creating graphics microcode, so that mindset did pay off.
As you rightly point out - there is a reasonable middle ground.
> The second one was investing to become faster in the future.
There's definitely an upper limit to human text manipulation speed, and I would be downright shocked if the difference between "fastest vi user" was even a single order of magnitude better than "experienced mouse user."
I was disappointed when I tried to use svd2rust for the atmel-provided svd's. They unfortunately do not provide reset values for some registers, which causes svd2rust to panic.
I was able to make a hacky fix for that. If you get the `svd2rust` source code and modify `generate.rs` on line 756 you can get it to generate a library file and not panic.
There are still a ton of warnings that pop up, and I haven't yet tested it on an MCU but in theory it should work.
I did exactly the same thing, but I'm not totally happy with it. Good for fooling around with, but not convinced I'd want to push something using it into production without a bit of further investigation.
I think the standard approach for crates to work around problems like this is to patch the vendor's XML. Terrible that it's necessary, but workable. The "STM32F103xx.patch" in japaric's stm32f103 support crate [1] seems a decent example of the sort of hacks that are standard.
[1] https://github.com/japaric/stm32f103xx/blob/master/STM32F103...
