Spinup - A Mystery Bug? - What's next

So, I was going about trying to get going with my project - and to round it up I'd only have to fix in some input I thought. So I went about and hacked something together that should by all means work. I mean, it's not pretty - but it follows the outspoken idea; To which I however also had a silent rebuttal. I have LazyInput.h as part of SDL Zero, although it doesn't need anything from there. There's a metaphorical "check in" to the System core controller - passing LazyInput to it - but, that's just so we're doing it. So, it's in what would be Lumberjack, the first segment, to be accessed via Meta Jack, initialized in the main init function via a m4meta macro. Or it can be on board of that, it doesn't matter I suppose. So, ignore mouse and gamepad - I was pre-occupied with LazyKeyboard.broken.mysteryBug.cpp - which ... should work. I also enhanced it a little to LazyKeyboard.broken.mysteryBug2.cpp ... but the input doesn't arrive in the Access Unit. I tried to check, so at the end of the update function, to see ... oh, you'll also need inputstates.cpp (crystals.h). And yes, the input is there. Then in the exec_prime I do the same and the input is not there. I tried to circumnavigate the need for register cohesion, teststrings and everything. It's all there - but why no input?

Maybe it works for you. If so, then this is a me thing.
And yea, actually ... there may be another, better way. It is what made me go orgasm a little - but, I'm not so sure whether or not those flights mean much. But when I also get to add multithreading, that'll also be ... ah, yes. IMportant. Sure. I mean - yes. If this is left as it is, we can/would/might/should run into problems with multithreading. So, my bad. I mean - I understood, but still was puzzled and mystified. Like, not that I had to insist, but sure ... to solve it I have to realize the mistake; Else I'd be guessing. And sure, run into a similar issue.


And so, there's the hunch. And sure - if I were to prioritize multithreading, the rest might follow. It is as it is. Yet apart from that do I feel the need to revisit the memory layout a little. I mean - now instead of just stacking things on top, I wonder how to actually use all that reserved space that's there.
And sure - once we get to things that require a lot of buffering ... we're glad we have it, but again ... I suppose I should revisit that - and ... create some cohesive ... thing. Not sure.


So, anyway. The hunch would be - should this not just be a me thing - to route the input via the M-Core. As, oh - yea, that too. There's the thing, as it makes sense: The input, as I understand, is generated via interrupts that simply write into BIOS memory. Maybe modern systems can hook into that interrupt and execute some custom code that will map the input to some customo space, but ... I'm not sure how useful that is. So, maybe not. OK. So, anyhow. The moment we apply a function to take the data that's there and make something of it, we're also reading out to some string buffer. And so we have to wonder: Where do we want that to happen? Because the system core has no dedicated runtime, we have to manage that through M. And that I assume also sets us up for future shenanigans of that sorts. So it is then from here that a Lazy Keyboard on T can be updated - and so, that's the way to go.

Or is it? Well, I'd want it to be a little more dedicated - so, well ... whatever. We shall see ... | Wow, sublime can view images ... . Not sure why tho ... but I suppose it's useful.