Okay so instead of passing stuff like classpath and otherwise, I am going to have a configuration ROM where all the settings and initial stuff set by the VM are stored. This will allow it to grow in size and support other options in the future so that SummerCoat/RatufaCoat do not need to be completely changed to support new configuration items. But this will definitely help and make it nice and cool to work with. It will also probably be easier to generate as well.


Okay so now I have this much better looking config ROM, so this will be nice! The good thing in this case is I will be able to write to a rather expanding format of things, without needing to hardcode various parameters in the method call. This very much future proofs the VM and such.


So the next thing to figure out is, what causes the arguments to mess up and such.


So I might have an idea, maybe it is related to the volatiles? It did work before the return values were fixed by using temporary volatiles. So not too sure then.


It might be code being called in the boot strap, but I am pretty sure I want to be sure it is not code being done in the actual note code itself. I mean calling other methods are fine.


Okay so, in note 8 and 9 are being used correctly when being passed to the note method. Additionally 8 is being used as the object to do length on.


Unless the RAM links are like too short at the start? I should check that out.


Okay the RAM links are fine. So it seems like it has trouble getting the vtable of what was pushed in. But the big thing is that they end up being the same exact arguments.


So I think note is fine?


Okay so this is the call to the notes. The registers 14 and 15 seem to be fine so these are okay. However they are the same value.

***** @4f1155e4 INVOKE             /INVOKESTAT | L51  /J23  reljme/jvm/
A:[        23,         14,         15] | V:[+1326452060,   +1067384,
>>>> 4f100d5c >>>>>>>>>>>>>>>>>>>>>>
> ARG [1067384, 1067384]
> WAS cc/squirreljme/jvm/Bootstrap.__start:(IIIIII)V @4F1155E4h (:51


Okay so, 14 is the result of jvmLoadString() and 15 is the result of jvmNewArray. Maybe with all of the return changes I made, I accidently saved or trashed the value of the return with what was previously in it. So no idea.


So I should look in jvmNewArray just to see.


Okay, so removing the code test debug makes things work. Like the act of calling Assembly.objectToPointer("Hello?") messes up. Storing the string and never using it again, messes up? Okay so, if a string is referred to but is never used to where it would become GC electable, it just fails to work properly?


More issues with jvmLoadString(). So will need to solve that actually.