anacierdem / ed64 Goto Github PK

I don't know if it is register compatible.

e.g use;

ed64://usb both to read and write to the serial stream.

Then it will be possible to do fprintf without hooking to stdio.
Then other libs (e.g gdbstub64) can write to a file instead of using everdrive calls.

Also see #24

Also see #34 if that's also involved. Probably using a dfffierent set of libdary functions causing things to change places. Then we are probably overwriting currently running code. Let's try to find some form of a layered loading solution if that's the case.

Only the real usb logs should go to the stdout

Not an issue :) but more a question.

I came across your repo for ED64 Tools and when I saw "Implement direct SD card access via libdragon filesystem API." I got super excited. As I have been for a long time wanting to do a raspberry pi mod to my flash cart so I can sync game saves and modify gameshark cheats over wifi.

I'm curious how this feature is coming along or how you are thinking to implement it. I tried to browse the Libdragon API to find what it possible with the file system. Is this what you're planning to use? (https://libdragon.dev/ref/group__system.html)

Users should not neet to assign all their functions for reboot to work.

See;
https://www.microchip.com/forums/m703281.aspx

We should use the active libdragon version instead when building dependencies.

Sorry in advance if I don't have the most reproducible use case in the world, but hopefully I can provide both the issue and a solution...

I was repeatedly getting the error RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: "length" is outside of buffer bounds at the end of my writes; the last print I would get was "Writing at 7Mb/7.02978515625Mb"

After looking at sendData I suspected using STATUS_UPDATE_AT as the third parameter in Buffer.from looked fishy, since we should have the exact required size available.

I locally modified Buffer.from to take size-offset, and provided that to the writeNext at the end of sendData as well.

Might be an issue specific to the version of node I'm using, or could be the exact sizes I'm using. I'm not a node expert, so just in case it's helpful I'm on 10.16.0.

This is something that I will probably implement on the docker project first. Then it can be used here as well.

So that the gdbstub lib can write to file stream (#7) while ed64 is initialized with everdrive_init(false). Maybe we can remove hooking alltogether...

It should have node & git to make development easier with vscode remote.

Remove duplicate function.
Remove unnecessary async modifiers & unnecessary asyncs in Promises.
Do readability improvements.

It will be better to release the loader as loader64 such that npx can find it even if it is not locally installed.

Implement a web based rom loader. There is no serial port support on deno yet, but it is possible to have a common implementation once it has landed in the future.