You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if HelloAmi's icon.library "loadwb" did enable the extra menus loadwb -debug does.
This would allow entry to the rom debugger, which is useful to enable amigaXfer.
I would actually like to recommend writing that to a floppy (instead of official workbench) on amigaXfer's documentation, and this is the only blocker to this.
Could you be so kind to test the attached version (search for "-debug" in the included source to find the minor changes): icon-library_amigaXfer.zip
I did only a quick test with the test scripts (seems to work), but I will be mostly offline during the Easter holidays...
Did some research and found the problem: The original LoadWB uses MKBADDR((LONG)FindResident("workbench.task") + sizeof(struct Resident) + ((argc == 2) && (strcmp(argv[1], "-debug") == 0) ? 8 : 0) as segment list for CreateProc (because it assumes that the default and debug segments directly follow the resident module header. But the "workbench.task"of V1.2 and V1.3 are longword-aligned (strictly speaking this is a bug, because the segments are not BPTR-aligned) and only works due to luck (op-code overlapping): (00000000, 7001 (moveq #1,D0), 60__ (bra.b ...) ends up as ____0000, 00007001 (ori.b #1,D0), 60__ (bra.b ...)). This alignment issue has been fixed in V2.0 and newer ROMs.
Libs/icon.library LoadWB will be fixed in the next BootWB1x release (tests pending) and will always start the Workbench with the debug flag. However, wouldn't it be easier to develop a boot sector with an Intuition button/requester to directly call exec.library/Debug - or do you really need a running Workbench for the initial transfer?
However, wouldn't it be easier to develop a boot sector with an Intuition button/requester to directly call exec.library/Debug
I already have bootblocks in amigaXfer that call Debug (always and optionally).
The issue is about file transfers. That is, for the situation where somebody doesn't have a legal copy of workbench or an otherwise bootable disk image, I can point people to your project's disk image, or even bundle it in my releases.
Then, once they've booted, they can e.g. download and run things from Aminet, directly. (It'd help there if the initial CLI was kept open, fwiw)
My alternative to get to the same place would be to somehow recover control after dos.library has initialized, and I might eventually do that (I have some ideas on how to do it). But a debug-enabled BootWB gets me there today :-)
I guess you know that V1.x Workbench "Debug" menus have no text - therefore you might have to advise your users to click in the space directly to the right of "Special" menu :)
And I noticed that using the Workbench without a mouse/joystick is even more tricky with the Initial CLI still open :)
During the tests I had some ideas for a better experience (e.g. hotkeys to open a new CLI and/or re-open the Workbench), but this needs more research and a lot of testing.
Activity
nicodex commentedon Apr 1, 2021
I will have a look at it.
nicodex commentedon Apr 1, 2021
Could you be so kind to test the attached version (search for "-debug" in the included source to find the minor changes):
icon-library_amigaXfer.zip
I did only a quick test with the test scripts (seems to work), but I will be mostly offline during the Easter holidays...
rvalles commentedon Apr 2, 2021
Thanks for the fast response.
I gave it a quick test on my A500. Wrote latest release HelloAmi.adf to a floppy then replaced icon.library with the attachment.
It works (shows debug menu) with kickstart 40 and 37.
It does not work (no debug menu) with kickstart 34.
nicodex commentedon Apr 14, 2021
Did some research and found the problem: The original LoadWB uses
MKBADDR((LONG)FindResident("workbench.task") + sizeof(struct Resident) + ((argc == 2) && (strcmp(argv[1], "-debug") == 0) ? 8 : 0)as segment list for CreateProc (because it assumes that the default and debug segments directly follow the resident module header. But the "workbench.task"of V1.2 and V1.3 are longword-aligned (strictly speaking this is a bug, because the segments are not BPTR-aligned) and only works due to luck (op-code overlapping): (00000000, 7001 (moveq #1,D0), 60__ (bra.b ...)ends up as____0000, 00007001 (ori.b #1,D0), 60__ (bra.b ...)). This alignment issue has been fixed in V2.0 and newer ROMs.Libs/icon.library LoadWBwill be fixed in the next BootWB1x release (tests pending) and will always start the Workbench with the debug flag. However, wouldn't it be easier to develop a boot sector with an Intuition button/requester to directly call exec.library/Debug - or do you really need a running Workbench for the initial transfer?rvalles commentedon Apr 14, 2021
Nice research you did there. Thank you.
I already have bootblocks in amigaXfer that call Debug (always and optionally).
The issue is about file transfers. That is, for the situation where somebody doesn't have a legal copy of workbench or an otherwise bootable disk image, I can point people to your project's disk image, or even bundle it in my releases.
Then, once they've booted, they can e.g. download and run things from Aminet, directly. (It'd help there if the initial CLI was kept open, fwiw)
My alternative to get to the same place would be to somehow recover control after dos.library has initialized, and I might eventually do that (I have some ideas on how to do it). But a debug-enabled BootWB gets me there today :-)
nicodex commentedon Apr 15, 2021
BootWB1x v35.4 has been released.
I guess you know that V1.x Workbench "Debug" menus have no text - therefore you might have to advise your users to click in the space directly to the right of "Special" menu :)
And I noticed that using the Workbench without a mouse/joystick is even more tricky with the Initial CLI still open :)
During the tests I had some ideas for a better experience (e.g. hotkeys to open a new CLI and/or re-open the Workbench), but this needs more research and a lot of testing.