Open up an issue on GitHub and we can help you better. The usual reason for problems like this is the layout of the image is incorrect on GoTek, and/or the GoTek is set to the wrong CHS (cylinders/head/sector) for the image being used.
We dropped all support for 286 or 386+ protected mode/paging etc, as well as produce only 8088/8086 instructions so it'll run on any x86 (including the PCjr with its peculiarities, remember that?) running in real mode only without MMU. Of course, that means any program can write anywhere, so more care is taken towards program correctness, which is kind of fun.
Yes it runs on that Amstrad. A funny story about the Amstrad, at one point we added divide-by-zero trap handler in the kernel for user space apps. When the Amstrad reboots via our 'shutdown', its gets a div zero exception in its own BIOS (which at the time prohibited the reboot, lol).
We don't support a compressed kernel anymore but have a way to compress user executables which saves about 30%. Sadly, even with straightforward decompression, that process on ancient 8088's sometimes takes longer than reading an uncompressed executable. But we're finally at the point of having "too much stuff" to fit on a floppy. And of course everyone wants games. (Don't ask about Doom: yes we have it, no it doesn't fit on a floppy :)
Yes, one can actually boot and run a minimal system on 360k floppy, but if you want networking you need 720k. The native compiler might fit on 1440k but needs a lot more for any development if the C library header files etc are wanted.
There's a couple of ROM versions, one which runs with a ROM filesystem and boots a shell over serial and another which uses BIOS INT 13h calls for an external MINIX or FAT filesystem. Both are run using an emulator which allows selection of ROM address, RAM size, etc. It'd be too hard to develop reliably without emulators for any of our images.
And yes the native compilers are running way faster under emulation than the originals on real hardware! Funnily enough, we're finding the slowest portion of the native toolchain is the assembler, due to lots of symbols and slow hashing.
Thanks for the comments! ELKS will run on an 8088, but also runs on any x86 PC using the legacy "real mode" which runs in 16-bit segmented architecture without an MMU or any hardware protection. It can be fun to boot a PC and see a close resemblance to Linux, but run the way things used to be, using only 16-bits.
It'll also run in ROM, e.g. using a 8018x CPU w/onboard PIT and PIC.
The point of ELKS today is about "small is beautiful" and seeing what can be done when limited to 64k code and 64k data, and 640k RAM. It's based on a very old fork of Linux and many of the internal structures are similar to what was found in Linux 2.0, without the changes for SMP support.
We just recently got a native C compiler/assembler/linker toolchain up and running. I must say making that happen provided some vivid comparisons of what programmers had to go through in decades past in both slower speeds and small executable file sizes, versus what we all have and expect today at our fingertips.
Yes, they're available on the archived Dr Dobbs Journal DVD V6 (https://archive.org/details/DDJDVD6), starting in the May 1991 section, or thereabouts.
Funnily enough, I just happened to have ported D-Flat to macOS and Linux in the last couple of weeks. Check it out (w/screenshots): https://github.com/ghaerr/dflat. It uses a small TUI library that maps multi-byte ANSI/xterm arrow key and mouse wheel inputs into unicode private-use codes for internal processing by D-Flat. It also remaps all of the IBM PC code page 437 characters for unicode output, and converts the entire "PC-compatible" screen image including attributes into ANSI terminal output, thanks to some nice code from the Cosmopolitan Project.