Bootstrapping an Amiga without a bootable floppy • Hacker News Board

Re: Bootstrapping an Amiga without a bootable floppy

#21

Post by the_only_law » Tue, May 04, 2021, 1:07 PM UTC

rasz wrote: post #20

Apparently IBM XT also had a way of being bootstrapped with no drives attached https://hackaday.com/2011/10/03/resurrecting-an-xt/ ;———————————————————————— ; LOAD A BLOCK OF TEST CODE THROUGH THE KEYBOARD PORT : ; FOR MANUFACTURING TEST. : ; THIS ROUTINE WILL LOAD A TEST (MAX LENGTH=FAFFH) THROUGH : ; THE KEYBOARD PORT. CODE WILL BE LOADED AT LOCATION : ; 0000:0500. AFTER LOADING, CONTROL WILL BE TRANSFERRED : ; TO…

Interesting. I had a 5155 (XT luggable) with drives but no disks. I debated writing a machine code bootstrapping program (POKE’d in through the ROM basic) to boot over the serial port.

I sold it before I got the chance. It’s a neat machine, but not my particular niche in the retro realm.

Re: Bootstrapping an Amiga without a bootable floppy

#22

Post by rvalles » Tue, May 04, 2021, 5:34 PM UTC

rasz wrote: post #20

Apparently IBM XT also had a way of being bootstrapped with no drives attached https://hackaday.com/2011/10/03/resurrecting-an-xt/ ;———————————————————————— ; LOAD A BLOCK OF TEST CODE THROUGH THE KEYBOARD PORT : ; FOR MANUFACTURING TEST. : ; THIS ROUTINE WILL LOAD A TEST (MAX LENGTH=FAFFH) THROUGH : ; THE KEYBOARD PORT. CODE WILL BE LOADED AT LOCATION : ; 0000:0500. AFTER LOADING, CONTROL WILL BE TRANSFERRED : ; TO…

I had never heard about this one. Neat.

re: Amiga, it is sad that, with 256KB of ROM, they couldn't fit a key combination to call exec's Debug() in the strap module.

I understand that, somehow, nobody thought about it.

Re: Bootstrapping an Amiga without a bootable floppy

#23

Post by rvalles » Tue, May 04, 2021, 5:35 PM UTC

rasz wrote: post #19

starik36 wrote: post #16

Another cool thing happening in the Amiga world is PiStorm - a Raspberry Pi based replacement for the CPU. And the resulting speed up in performance and RAM. https://www.youtube.com/watch?v=-CwVofNogDI

if speed is what you want why not just run winuae and emulate at >1000x the speed of 68000? Even pi4 runs winuae at >400mips. You know whats funny? Workbench still stutters while filling drawers one icon at a time.

While fast, PiStorm is still similar to a 030, and not anywhere near fast enough for 060 demoscene.

Workbench is what it is.

Re: Bootstrapping an Amiga without a bootable floppy

#24

Post by rvalles » Tue, May 04, 2021, 5:44 PM UTC

LIV2 wrote: post #7

rvalles wrote: post #2

Author here. I am amazed it made frontpage. openbsd's httpd seems to be handling the load well. I will read your comments if any :)

Great work! I had thought about trying this myself but gave up after realising I'd not have access to Trackdisk.device from Romwack - Didn't know about Coolcapture/Warmcapture. I guess I need to read up some more!

Did re-read your comment, and thought I'd point you to some code so you can quickly see how it works.

Regarding trackdisk.device, you might want to take a look at:

https://github.com/rvalles/pyamigadebug/blob/master/ExecLibr...

And the function calling mechanism for RomWack backend:

https://github.com/rvalles/pyamigadebug/blob/master/RomWack....

Ultimately, TrackdiskDevice ends up being a thin wrapper around ExecLibrary:

https://github.com/rvalles/pyamigadebug/blob/master/Trackdis...

For performance purposes, the Floppy tool does instead use this small server written in asm:

https://github.com/rvalles/pyamigadebug/blob/master/asm/flop...

And the python boilerplate client to talk with it:

https://github.com/rvalles/pyamigadebug/blob/master/FloppyXf...

For the BERR case, without the initial reboot, Amiga will just crash again when calls are made from the exception handler. Recovering control after a reboot is a nice and clean way to get the Amiga into a known state. It is definitely also doable without rebooting, but somewhat more involved.

Else, when entering the debugger via e.g. the extra debug menu present in workbench when loaded via "loadwb -debug", the context RomWack works with is a user context, so I just take over the user task. As long as I don't corrupt the stack (or anything else), I can even return cleanly.