FUZIX zx+3-boot-0.3 image does not boot on the real thing

[pawosm-arm]

I've tried to boot zx+3-boot-0.3.dsk on the real ZX Spectrum +3e (Garry Lancaster's ROM v1.43) with ZXMMC interface and 4GB MMC storage installed. Unfortunately, after a while of reading from floppy it stops with usual "Insert tape and press PLAY" message. I have no problem with booting ZX CP/M 2.2, CP/M Plus or my own forever-work-in-progress OS from the same floppy drive. Strangely, I can boot the same image on Fuse emulator with the same +3e (v1.43) ROM installed, yet it ends at "no card found" messages with "bootdev:" prompt (note that emulation of ZXMMC, although it can be enabled in Fuse, it never worked for me). I wonder, do I need to install some files on the MMC card before I boot 0.3 disk image? Currently I have Workbench +3e installed and as I found it cool (especially with its use of Kempston mouse), I want to still have it there in workable state.

[pawosm-arm]

My suspicion was correct, and indeed, the need for having filesystem installed first is written on fuzix.org page, which for some reason I didn't see before as somehow I managed to get direct download link without even visiting this page. Closing this one then, as it is not an error.

I still have no idea how to place this filesystem image on ZXMMC storage along with Workbench +3e partitions.

[EtchedPixels]

Fuzix expects a standard PC compatible partitioning scheme. I am not sure what +3e uses as I keep the original ROMs on my systems. Given Fuzix is still fairly experimental on a +3 I wouldn't try mixing it with something you care a lot about in case it eats the contents of the card. It's not done that to me for a long time but nevertheless ...

[pawosm-arm]

Hi! Thanks for your reply. I do have the contents I care a lot about on this MMC card, yet I'd make backup copy before editing it on my Linux PC anyway. The biggest issue with pulling the card out (for making changes on PC) is that ZXMMC device is installed inside of +3 (a pass-through unit installed into CPU socket), doing so requires opening the machine, putting delicate keyboard connecting straps at risk of breaking. To avoid doing it, I'm using Gotek device to copy files between PC and +3 whenever possible.

In theory, it is possible to have PC partitions along with +3e on MMC card as described here: http://www.worldofspectrum.org/zxplus3e/sharingdisks.html yet I never saw it working, so it may take me some time to make attempt. Can you point me to the correct rootfs image I could install on it?

Also, I'd like to ask you how to configure Fuse emulator (running +3e machine emulation) for FUZIX. I never managed to configure Fuse with mass storage (could only make it work with 40 and 80 tracks floppy images), I guess I'm missing something crucial here.

[pawosm-arm]

Following instructions on http://www.worldofspectrum.org/zxplus3e/sharingdisks.html page I've managed to prepare MMC card which has both PC partition table (as requested by Fuzix) and special partition (type 05, extended DOS) which can be utilized by +3e firmware. I've created 32MB partition of type 7E and 4MB partition of type 7F. I've downloaded and installed 32MB rootfs image on 7E partition. It still does not boot.

Seems like original problem (with boot inability) persists. To boot the .dsk image on the real Spectrum, I'm using Gotek interface connected to the external floppy connector and remapped as A: (in hardware) by the only proper hardware A/B switch as described here: https://zxnet.co.uk/spectrum/floppy_drive_swap

What I'm observing is that Gotek has severe problem with reading zx+3-boot-0.3.dsk image. Even cat "a:" is problematic: on Fuse it shows "No files", on the real thing it says it can't read sector 0.

I am able to boot other systems and commercial games using Gotek device. E.g. CP/M Plus .dsk image obtained from Locoscript Software (https://locoscript-software.square.site/product/zx-spectrum-3-cp-m-plus-mallard-basic-dsk-image-/11) is properly bootable using Gotek on the real Spectrum (the image contains proper boot sector, it's not just a disk image containing DISK file with BASIC loader in it as in ZX CP/M 2.2, which also boots fine).

CP/M .dsk file starts like that:

00000000  4d 56 20 2d 20 43 50 43  20 66 6f 72 6d 61 74 20  |MV - CPC format |
00000010  44 69 73 6b 20 49 6d 61  67 65 20 28 44 55 35 34  |Disk Image (DU54|
00000020  29 0d 0a 44 69 73 6b 2d  49 6e 66 6f 0d 0a 00 00  |)..Disk-Info....|
00000030  28 01 00 13 00 00 00 00  00 00 00 00 00 00 00 00  |(...............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  54 72 61 63 6b 2d 49 6e  66 6f 0d 0a 00 00 00 00  |Track-Info......|
00000110  00 00 00 00 02 09 52 e5  00 00 01 02 00 00 00 00  |......R.........|
00000120  00 00 02 02 00 00 00 00  00 00 03 02 00 00 00 00  |................|
00000130  00 00 04 02 00 00 00 00  00 00 05 02 00 00 00 00  |................|
00000140  00 00 06 02 00 00 00 00  00 00 07 02 00 00 00 00  |................|
00000150  00 00 08 02 00 00 00 00  00 00 09 02 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 00 28 09 02 01 03 02  2a 52 00 00 00 00 00 06  |..(.....*R......|
00000210  f3 01 fd 1f 3e 1f ed 79  31 00 fe 21 00 00 e5 11  |....>..y1..!....|
00000220  00 d0 06 04 cd 8c fe cd  59 fe d1 20 25 d5 06 10  |........Y.. %...|
00000230  af be 28 1b e5 6e 67 29  c5 01 08 02 cd 8c fe c1  |..(..ng)........|
00000240  e1 23 10 ec 21 b4 fe 34  d5 cd 59 fe d1 28 df e1  |.#..!..4..Y..(..|
00000250  7e af c2 ef fe e5 c3 36  ff 21 00 d0 01 ff 40 7e  |~......6.!....@~|
00000260  e6 f0 20 1f c5 e5 11 0c  00 19 43 11 b4 fe 1a fe  |.. .......C.....|
00000270  3f 20 03 7e a1 12 ae a1  20 07 1b 2b 0e 7f 10 ee  |? .~.... ..+....|
00000280  af e1 c1 11 10 00 19 c8  19 10 d4 c9 c5 e5 01 f7  |................|
00000290  ff af 3c 09 38 fc 87 47  7d c6 0a 4f eb cd b5 fe  |..<.8..G}..O....|
000002a0  eb e1 c1 14 14 23 10 e4  c9 3f 3f 3f 3f 3f 3f 3f  |.....#...???????|
000002b0  3f 45 4d 53 00 1e 0a c5  e5 cb 38 0e 07 cd 89 ff  |?EMS......8.....|
000002c0  38 19 e1 c1 cd 42 ff c4  42 ff c8 c5 e5 cb 38 3e  |8....B..B.....8>|
000002d0  27 b8 20 01 0f 47 0e 02  cd 89 ff cd bd ff 02 07  |'. ..G..........|
000002e0  00 16 27 cd a2 ff af 32  a1 ff e1 c1 1d 20 c8 cd  |..'....2..... ..|
000002f0  36 ff 16 04 21 0a ff cd  1a ff cd 1a ff 15 20 f4  |6...!......... .|
00000300  01 fd 80 ed a3 06 20 ed  a3 c7 04 00 7f 01 00 08  |...... .........|
00000310  0f 07 7e 32 01 07 7f 75  03 10 7e 23 01 fd 00 ed  |..~2...u..~#....|
00000320  a3 06 c0 ed a3 3d 20 f4  46 23 3e 76 e3 e3 e3 e3  |.....= .F#>v....|
00000330  3d 20 f9 10 f5 c9 01 fd  1f 3e 17 ed 79 3e 07 d3  |= .......>..y>..|
00000340  fe c9 c5 e5 e5 21 62 ff  af cb 38 17 71 2b 2b 71  |.....!b...8.q++q|
00000350  2b 77 2b 70 87 87 2b 77  cd bd ff 09 66 00 00 00  |+w+p..+w....f...|
00000360  00 02 00 2a ff e1 01 fd  2f ed 78 f2 69 ff e6 20  |...*..../.x.i.. |
00000370  28 06 06 3f ed a2 18 ee  cd e7 ff e1 c1 e6 db c8  |(..?............|
00000380  fe 40 c0 3a 01 fc ee 80  c9 21 a1 ff 7e 90 c8 70  |.@.:.....!..~..p|
00000390  30 02 2f 3c 57 79 d3 fe  cd bd ff 06 03 af 03 0f  |0./<Wy..........|
000003a0  00 00 06 04 cd 2a ff 15  20 f8 06 05 cd 2a ff cd  |.....*.. ....*..|
000003b0  e2 ff e6 fb fe 20 c8 e6  03 20 f4 37 c9 cd e2 ff  |..... ... .7....|
000003c0  e6 c0 fe 80 20 f7 e3 46  23 e3 e3 c5 01 fd 2f ed  |.... ..F#...../.|
000003d0  78 87 30 fb fa dc ff 06  3f 7e ed 79 23 c1 e3 10  |x.0.....?~.y#...|
000003e0  e9 c9 cd c6 ff 01 08 21  00 fc 01 fd 2f ed 78 87  |.......!..../.x.|
000003f0  30 fb 3a 00 fc f0 06 3f  ed a2 e3 e3 e3 e3 18 ea  |0.:....?........|
00000400  e5 e5 e5 e5 e5 e5 e5 e5  e5 e5 e5 e5 e5 e5 e5 e5  |................|
*

...while zx+3-boot-0.3.dsk begins like that:

00000000  4d 56 20 2d 20 43 50 43  45 4d 55 20 44 69 73 6b  |MV - CPCEMU Disk|
00000010  2d 46 69 6c 65 0d 0a 44  69 73 6b 2d 49 6e 66 6f  |-File..Disk-Info|
00000020  0d 0a 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  28 01 00 0d 00 00 00 00  00 00 00 00 00 00 00 00  |(...............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  54 72 61 63 6b 2d 49 6e  66 6f 0d 0a 00 00 00 00  |Track-Info......|
00000110  00 00 00 00 02 09 4e e5  00 00 01 02 00 00 00 00  |......N.........|
00000120  00 00 02 02 00 00 00 00  00 00 03 02 00 00 00 00  |................|
00000130  00 00 04 02 00 00 00 00  00 00 05 02 00 00 00 00  |................|
00000140  00 00 06 02 00 00 00 00  00 00 07 02 00 00 00 00  |................|
00000150  00 00 08 02 00 00 00 00  00 00 09 02 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 00 28 09 02 01 03 02  2a 52 00 00 00 00 00 c8  |..(.....*R......|
00000210  f3 01 fd 7f 3e 08 ed 79  01 fd 7f 3e 08 ed 79 21  |....>..y...>..y!|
00000220  00 40 11 01 40 01 11 69  af 77 ed b0 01 fd 1f 3e  |.@..@..i.w.....>|
00000230  0d ed 79 11 02 00 21 00  01 18 0f 14 1e 01 7a e6  |..y...!.......z.|
00000240  03 c6 04 d3 fe d5 cd 5d  fe d1 d5 cd 81 fe d1 3e  |.......].......>|
00000250  fd bc ca 00 01 1c 3e 0a  bb 20 ef 18 de 3e 0f cd  |......>.. ...>..|
00000260  e5 fe af cd e5 fe 7a cd  e5 fe 3e 08 cd e5 fe cd  |......z...>.....|
00000270  be fe cb 6f 28 f4 3e 1e  06 dc 05 20 fd 3d 20 f8  |...o(.>.... .= .|
00000280  c9 3e 46 cd e5 fe af cd  e5 fe 7a cd e5 fe af cd  |.>F.......z.....|
00000290  e5 fe 7b cd e5 fe 3e 02  cd e5 fe 7b cd e5 fe 3e  |..{...>....{...>|
000002a0  1b cd e5 fe af cd e5 fe  0e fd 16 20 c3 b3 fe 06  |........... ....|
000002b0  3f ed a2 06 2f ed 78 f2  b5 fe a2 c2 af fe 0e fd  |?.../.x.........|
000002c0  e5 21 dd fe 06 2f ed 78  17 30 f9 17 30 0a 06 3f  |.!.../.x.0..0..?|
000002d0  ed a2 e3 e3 e3 e3 18 ec  3a dd fe e1 c9 ff ff ff  |........:.......|
000002e0  ff ff ff ff ff 08 01 fd  2f ed 78 87 30 fb 87 d8  |......../.x.0...|
000002f0  08 06 3f ed 79 dd e3 dd  e3 c9 ff ff ff ff ff ff  |..?.y...........|
00000300  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000400  f3 31 00 f2 31 00 f2 21  35 a4 11 00 f0 01 3f 0c  |.1..1..!5.....?.|

I may suspect there's some flaw in .dsk preparation process. I wonder if this ticket should be reopened...

[EtchedPixels]

Different .dsk formats.

It's possible there is a bug but the ones I generate seem to be working with the stuff I have used

http://www.cpcwiki.eu/index.php/Format:DSK_disk_image_file_format

is the disk format. Shouldn't be hard to change the tools to also generate the DU54 format and that would probably be quite a useful addition for writing them on a +3 or an Amstrad PCW8256 or similar. using DU54.COM.

Kernel/tools/raw2dsk is fairly simple

[pawosm-arm]

Some progress! Making copy of your boot disk on the Fuse emulator under CP/M Plus with du54.com utility indeed gave me a copy of the startup image bootable (in Gotek device) on the real machine!

One thing I've noticed, you wrote raw2dsk routine yourself. For my forever-work-in-progess Speccy3OS I'm re-using one of the tools (dsktrans) shipped along with John Elliott's libdsk library (dsktrans -itype rcpmfs -otype dsk $TMPDIR out.dsk), yet I'm not creating a boot sector, rather my system is booted the same way as ZX CP/M 2.2, the disk image contains BASIC loader in the DISK file:

10 CLEAR VAL "24575"
20 LOAD "speccy3.bin" CODE
30 GOTO USR VAL "24576"

Whole boot procedure, micro-kernel, font, initial ramdisk and some startup processes are in the single binary file of 40960 bytes size. The files (DISK and speccy3.bin) on the startup disk are clearly visible and accessible to the user. Some trickery was necessary to make those files usable and loadable for PLUS3DOS.

Coming back to Fuzix. I managed to boot it on the real thing, yet it failed right after starting init and adding some buffers (see attached screenshot of mplayer started as such: mplayer tv:// -tv device=/dev/video4:input=1 to get the live image from USB frame grabber to which Speccy's SCART output is connected). The machine froze at that moment and reset button had to be pressed. A hda2 partition was selected at bootdev: prompt. A scary moment right after reset: CAT TAB could not find any +3e partitions anymore! Fortunately, they came back after power cycle.

Partitions were created as such:

Device     Boot  Start    End Sectors   Size Id Type
/dev/sdb1          128 420095  419968 205.1M  5 Extended
/dev/sdb2       420096 485631   65536    32M 7e unknown
/dev/sdb3       485632 493823    8192     4M 7f unknown

4MB /dev/sdb3 (swap) was filled with zeros with the dd command, 32MB /dev/sdb2 has content of rootfs-z80-32.img installed with the dd command. The /dev/sdb1 partition contains all of the +3e partitions.

Any ideas what could cause the crash?

[EtchedPixels]

Looks like it blew up on the first write to the SD card. That would also explain why your cat tab happened - the +3E firmware isn't smart enough to get out of a card stuck in the middle of a write transaction. I need to take a look at the code and the ZXMMC see if I can see what is different between it and the emulation/other systems.

[EtchedPixels]

On the loader btw I don't think it would be hard to load the kernel image via a helper app from BASIC providing you can find somewhere to put everything whilst loading it before kicking the BASIC and disk out. The zxdiv port does that via esxdos.

[pawosm-arm]

Hi again, I looked at those hexdumps of the .dsk image headers, and I've found that the only relevant difference is in line starting at offset 00000030: the 28 01 00 0d should be 28 01 00 13, a single byte which should be changed from 0x0d to 0x13 to make original Fuzix images bootable in Gotek drive. This requires following change in raw2dsk.c code:

--- raw2dsk.c.old   2019-11-03 15:04:16.697260353 +0000
+++ raw2dsk.c   2019-11-03 15:04:20.897242120 +0000
@@ -23,7 +23,7 @@
     buf[0x30] = 40;
     buf[0x31] = 1;
     buf[0x32] = 0;
-    buf[0x33] = 13;
+    buf[0x33] = 0x13;

     if (argc != 3) {
         fprintf(stderr, "%s: source dest.\n", argv[0]);

Seems like it's something that Fuse does not care about, while Gotek can't read disk image without this thing being set properly.

[pawosm-arm]

I also finally managed to boot it in Fuse. Turned out, Fuzix bootloader can't find emulated storage devices other than DivIDE (I tried ZXMMC and Simple 8-bit IDE emulations, both unsuccessfully).

I've dumped to a file the entire content of the MMC card (as described couple of posts ago) with partition table, +3e partitions, 32MB rootfs-z80-32.img 7E rootfs partition and the 7F swap partition, then used raw2hdf (comes with fuse-utils) to get .hdf image which Fuse understands. Both +3 and +3e emulations managed to boot Fuzix and complete the init sequence, which I couldn't see completed on the real thing.

[EtchedPixels]

Yes I bet that confused it - it's the size of a track, and should indeed be 0x1300 bytes

I can duplicate the zxmmc not being seen under emulation here, which is interesting and I will take a look at that.

[EtchedPixels]

Ok so that's a fuse bug I think - it responds to CMD0 with an immediate 0x01, which isn't actually valid, there will always be a padding byte as it may be tristated for that byte. If I hack around that it works properly on the emulation.

It won't see the simple 8bit IDE. Not hard to add support for it though.

[pawosm-arm]

Just to confirm the above. I've managed to make ZXMMC emulation work AT ALL (so the partitions started to be operable from +3 BASIC), by using ROMs downloaded form this page: http://www.worldofspectrum.org/zxplus3e/p3eroms.html.

I tried to use image that worked with DivIDE emulation:

fuse -m plus3e --zxmmc --zxmmc-file 500MB.hdf --rom-plus3e-0 $HOME/fuse/roms/mmcen3e0.rom --rom-plus3e-1 $HOME/fuse/roms/mmcen3e1.rom --rom-plus3e-2 $HOME/fuse/roms/mmcen3e2.rom --rom-plus3e-3 $HOME/fuse/roms/mmcen3e3.rom zx+3-boot-0.3.dsk

Unfortunately, Fuzix bootloader could not find any usable partition (or rather, it could not find MMC card at all), possibly due to mentioned bug in fuse (I tried fuse built from soureforge git repo and one from Gentoo Linux distribution package with the same outcome).

[pawosm-arm]

Some progress again. I managed to boot Fuzix in Fuse in +3e with ZXMMC emulation. I was pointed by Sergio Baldoví at following commit in Fuzix: 08a8d4a62165da1feca8529df033ca42978b54c8 According to Sergio:

Fuzix is discarding the response of CMD0 - GO_IDLE command. Previously this line was only active on CMD12 (STOP_TRANSMISSION) command, but was enabled by (this) refactoring So it seems a bug in Fuzix. Although current code might work with real cards, IMO it is not safe to discard the first response.

I've introduced following change in my local Fuzix clone:

diff --git a/Kernel/dev/devsd.c b/Kernel/dev/devsd.c
index 4581295b..fe8b16fb 100644
--- a/Kernel/dev/devsd.c
+++ b/Kernel/dev/devsd.c
@@ -138,8 +138,7 @@ int sd_send_command(uint_fast8_t cmd, uint32_t arg)
     sd_spi_transmit_byte(n);

     /* Receive command response */
-/*    if (cmd == CMD12)  - ignore first reply byte anyway because it may
-      be floating bus */
+    if (cmd == CMD12)
         sd_spi_receive_byte();     /* Skip a stuff byte when stop reading */
     n = 20;                             /* Wait for a valid response */
     do {

...and I've rebuilt the whole thing (with TARGET=zx+3). It took half a day to build this thing (aaargh!), but for a first time, Fuse managed to find Fuzix partitions on emulated SD (ZXMMC) card.

Unfortunately, Fuzix still crashes when using MMC card on the real +3e machine with ZXMMC interface fitted into it and it still needs power off after that.

A side note, I've noticed that I need to power off completely also after playing 2019's game Dirty Dozer (there's no .dsk image of it, so to run it on the real +3e, I've made .z80 snapshot of it within Fuse). Somehow it also makes +3e partitions disappear after reset.

[EtchedPixels]

No its a bug in the emulator. The first byte is floating bus so has to ignored with most hardware adpaters. There's a reason it always works with real cards.

[sbaldovi]

No its a bug in the emulator. The first byte is floating bus so has to ignored with most hardware adpaters. There's a reason it always works with real cards.

Thank you for raising this up. Fuse emulator is far than perfect. We will consider emulating NCR timings. Linux kernel indeed ignores the first byte ([1]).

I'm not expert and interpreted that first byte could by valid, as ChaN ([2]) states:

The response is sent back within command response time (NCR), 0 to 8 bytes for SDC, 1 to 8 bytes for MMC.

Likely also true by his form of reading the response:

Because the data transfer is driven by serial clock generated by host controller, the host controller must continue to read data, send a 0xFF and get received byte, until a valid response is detected.

[1] https://github.com/torvalds/linux/blob/04cbfba6208592999d7bfe6609ec01dc3fde73f5/drivers/mmc/host/mmc_spi.c#L269 [2] http://elm-chan.org/docs/mmc/mmc_e.html

[pawosm-arm]

There's one more difference between Fuse and the real ZXMMC device fitted in the real +3e machine I did notice during my last Sunday's experiments. I wrote simple routine to read a single sector of data from MMC card. After reading the data (with two inirs) it reads two following bytes from the SPI port. In Fuse, these bytes are always zeros, on the real thing these bytes form upper and lower halfs of a CRC16 value (as I verified by simple piece of code). I assume that most of the software seeing zeros here skips CRC16 comparison and continues carelessly (or just ignores these two bytes, as Fuzix does). However I wonder how it works the other way round: Fuzix sends two bytes of fake CRC after writing a sector of data. Luckily or not, Fuse accepts these happily, but what about the real ZXMMC device in the real +3e machine? Could it be the reason why the device got stuck during Fuzix 'init'?

[EtchedPixels]

The SD card shouldn't check them as we turned CRC checking off during card init. I guess the way to find out is to see what the actual Spectrum firmware does and try some experiments on the actual card.

[pawosm-arm]

Should this one be closed (as the booting the real thing from a floppy image is now sorted) and the new opened for write failures with the real ZXMMC device?

[EtchedPixels]

Probably.

[pawosm-arm]

zx+3-boot-0.3 image now boots from floppy after fixing the 'size of track' value.