Conversation
|
In my refactor in #110 I removed T from GBA and I moved all the hardware outside the cpu so every UI tools can access it easly |
Yep I saw it! Now we need to decide which one should we merge first :D I'm okay with keeping this in pause and merge yours first and then I rebase. I can use this branch in any case to debug |
| self.registers.to_vec() | ||
| } | ||
|
|
||
| fn get_memory(&self) -> Ref<'_, InternalMemory> { |
There was a problem hiding this comment.
You can return Rc<RefCell<InternalMemory>> instead with self.memory.clone() that returns another usable instance of the Rc. But I don't want to keep it for later, because cpu doesn't need to return the memory, but gba. No problem for now, just a reminder for later.
There was a problem hiding this comment.
Once you merge #111 and I rebase this get_memory fn will probably go away
|
I converted it to draft while we wait for #111 to be merged |
|
Agreed! We will come back to this after other PR's will be merged! |
3 participants
Added a new UiTool to read values from memory.
I don't like very much how it is implemented but it was the only way (or at least the only one I found) to make it work since we have
Gba<T: Cpu>andCputrait didn't have any method to access memory and memory is stored into anRc<RefCell<>>.Please tell me if you think it could be implemented in a better way (maybe without returning
Ref? But I think it's needed sinceInternalMemoryis managed by aRefCell).It's very simple because I want to use it to debug an issue we may have in the instruction implementations. In the future, we could show a matrix with all the values and so on but for now I think this does the job.