fujinet-firmware
fujinet-firmware copied to clipboard
FujiNetWIFI
ProDOS cannot be booted from Disk II
When trying to boot ProDOS from Disk II it will click, display the splash/copyright, and then get stuck in a loop trying to move off track 1 but never quite make it.
This disk image will consistently fail when booted via FujiNet Disk II, but will work fine when written to a real 5.25" floppy: CHRIS-PRODOS-A.dsk.zip
09:56:52.022 > trk pos 01.0/Q004 on d1
09:56:52.060 > trk pos 01.2/Q006 on d1
09:56:52.072 > trk pos 01.1/Q005 on d1
09:56:52.072 > trk pos 01.0/Q004 on d1
09:56:52.111 > trk pos 01.2/Q006 on d1
09:56:52.122 > trk pos 01.0/Q004 on d1
09:56:52.161 > trk pos 01.2/Q006 on d1
09:56:52.173 > trk pos 01.1/Q005 on d1
09:56:52.173 > trk pos 01.0/Q004 on d1
09:56:52.212 > trk pos 01.2/Q006 on d1
09:56:52.224 > trk pos 01.0/Q004 on d1
09:56:52.262 > trk pos 01.2/Q006 on d1
09:56:52.274 > trk pos 01.1/Q005 on d1
09:56:52.274 > trk pos 01.0/Q004 on d1
09:56:52.313 > trk pos 01.2/Q006 on d1
09:56:52.324 > trk pos 01.0/Q004 on d1
09:56:52.363 > trk pos 01.2/Q006 on d1
09:56:52.375 > trk pos 01.1/Q005 on d1
09:56:52.375 > trk pos 01.0/Q004 on d1
09:56:52.414 > trk pos 01.2/Q006 on d1
09:56:52.426 > trk pos 01.1/Q005 on d1
09:56:52.426 > trk pos 01.0/Q004 on d1
09:56:52.464 > trk pos 01.2/Q006 on d1
09:56:52.476 > trk pos 01.1/Q005 on d1
09:56:52.476 > trk pos 01.0/Q004 on d1
09:56:52.515 > trk pos 01.2/Q006 on d1
09:56:52.526 > trk pos 01.0/Q004 on d1
09:56:52.565 > trk pos 01.2/Q006 on d1
09:56:52.577 > trk pos 01.1/Q005 on d1
09:56:52.577 > trk pos 01.0/Q004 on d1
09:56:52.616 > trk pos 01.2/Q006 on d1
09:56:52.628 > trk pos 01.0/Q004 on d1
09:56:52.666 > trk pos 01.2/Q006 on d1
09:56:52.678 > trk pos 01.1/Q005 on d1
09:56:52.678 > trk pos 01.0/Q004 on d1
09:56:52.717 > trk pos 01.2/Q006 on d1
09:56:52.728 > trk pos 01.0/Q004 on d1
09:56:52.767 > trk pos 01.2/Q006 on d1
09:56:52.779 > trk pos 01.0/Q004 on d1
09:56:52.818 > trk pos 01.2/Q006 on d1
09:56:52.830 > trk pos 01.0/Q004 on d1
09:56:52.869 > trk pos 01.2/Q006 on d1
Yup, I can reproduce this:
- Apple II+
- SoftSP v6 DIY in Grappler+
- ProDOS 2.4.3 in Disk ][ drive 1.
Exactly the same output as above.
And if I let it sit on the //c long enough, I get a relocation error, with the following backtrace:
09:53:18.700 > trk pos 006 on d1Guru Meditation Error: Core 1 panic'ed (Cache disabled but cached memory region accessed).
09:53:18.701 >
09:53:18.701 > Core 1 register dump:
09:53:18.703 > PC : 0x4008f892 PS : 0x00060035 A0 : 0x80082598 A1 : 0x3ffc2e20
09:53:18.704 > A2 : 0x3ffc2e3c A3 : 0x3f400928 A4 : 0x00000020 A5 : 0x3ffc2e3c
09:53:18.706 > A6 : 0xbad00bad A7 : 0xbad00bad A8 : 0x00000000 A9 : 0x3ffbaa14
09:53:18.708 > A10 : 0x3ffc9dc0 A11 : 0x00060023 A12 : 0x00000001 A13 : 0x003fffff
09:53:18.710 > A14 : 0x00000003 A15 : 0x00060623 SAR : 0x00000003 EXCCAUSE: 0x00000007
09:53:18.712 > EXCVADDR: 0x00000000 LBEG : 0x4008f88c LEND : 0x4008f8a8 LCOUNT : 0x00000001
09:53:18.714 >
09:53:18.714 >
09:53:18.714 > Backtrace: 0x4008f88f:0x3ffc2e20 0x40082595:0x3ffc2e30 0x4008268f:0x3ffc2e80 0x4008303e:0x3ffc2eb0 0x4008628d:0x3ffc2ef0 0x40087426:0x3ffafd50 0x40084b33:0x3ffafd70 0x400985c1:0x3ffafd90
09:53:18.883 >
09:53:18.883 > #0 0x4008f88f:0x3ffc2e20 in memcpy at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/memcpy.S:176
09:53:18.883 > #1 0x40082595:0x3ffc2e30 in iwm_diskii_ll::fakebit() at lib/bus/iwm/iwm_ll.cpp:1127
09:53:18.883 > #2 0x4008268f:0x3ffc2e80 in encode_rmt_bitstream(void const*, rmt_item32_t*, unsigned int, unsigned int, unsigned int*, unsigned int*, int) at lib/bus/iwm/iwm_ll.cpp:1050 (discriminator 2)
09:53:18.883 > #3 0x4008303e:0x3ffc2eb0 in fn_rmt_driver_isr_default(void*) at lib/hardware/fnRMTstream.cpp:735
09:53:18.883 > #4 0x4008628d:0x3ffc2ef0 in _xt_lowint1 at /home/thomc/.platformio/packages/[email protected]/components/freertos/FreeRTOS-Kernel/portable/xtensa/xtensa_vectors.S:1118
09:53:18.883 > #5 0x40087426:0x3ffafd50 in spi_flash_op_block_func at /home/thomc/.platformio/packages/[email protected]/components/spi_flash/cache_utils.c:133
09:53:18.883 > #6 0x40084b33:0x3ffafd70 in ipc_task at /home/thomc/.platformio/packages/[email protected]/components/esp_system/esp_ipc.c:87
09:53:18.883 > #7 0x400985c1:0x3ffafd90 in vPortTaskWrapper at /home/thomc/.platformio/packages/[email protected]/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:154
09:53:18.883 > #0 0x4008f88f:0x3ffc2e20 in memcpy at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/memcpy.S:176 09:53:18.883 > #1 0x40082595:0x3ffc2e30 in iwm_diskii_ll::fakebit() at lib/bus/iwm/iwm_ll.cpp:1127
There is no memcpy() call in fakebit() so that seems a bit odd.
What seems to be happening is that the FujiNet is missing steps. ProDOS steps the head down just fine by rolling the stepper waveform, with around 4 milliseconds per step. Suddenly the FujiNet has a delay of 40 milliseconds every 4th step and so it thinks the stepper is going the other way and does D=2.
11:44:22.195 > trk pos 03.0/Q012=Q003 idx=7 D=-1 P=0001/1 on d1
11:44:22.199 > trk pos 02.3/Q011=Q003 idx=7 D=-1 P=1001/9 on d1
11:44:22.202 > trk pos 02.2/Q010=Q255 idx=7 D=-1 P=1000/8 on d1
11:44:22.204 > trk pos 02.1/Q009=Q002 idx=7 D=-1 P=1100/12 on d1
11:44:22.204 > Copy track: 00.2/Q009
11:44:22.210 > trk pos 02.0/Q008=Q002 idx=7 D=-1 P=0100/4 on d1
11:44:22.214 > trk pos 01.3/Q007=Q002 idx=7 D=-1 P=0110/6 on d1
11:44:22.218 > trk pos 01.2/Q006=Q255 idx=7 D=-1 P=0010/2 on d1
11:44:22.222 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1
11:44:22.222 > Copy track: 00.1/Q005
11:44:22.225 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1
11:44:22.261 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1
11:44:22.271 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1
11:44:22.271 > Copy track: 00.1/Q005
11:44:22.274 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1
11:44:22.311 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1
11:44:22.321 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1
11:44:22.321 > Copy track: 00.1/Q005
11:44:22.324 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1
11:44:22.362 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1
11:44:22.372 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1
11:44:22.372 > Copy track: 00.1/Q005
11:44:22.375 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1
11:44:22.412 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1
wow.
On Fri, Mar 28, 2025 at 1:55 PM FozzTexx @.***> wrote:
What seems to be happening is that the FujiNet is missing steps. ProDOS steps the head down just fine by rolling the stepper waveform, with around 4 milliseconds per step. Suddenly the FujiNet has a delay of 40 milliseconds every 4th step and so it thinks the stepper is going the other way and does D=2.
11:44:22.195 > trk pos 03.0/Q012=Q003 idx=7 D=-1 P=0001/1 on d1 11:44:22.199 > trk pos 02.3/Q011=Q003 idx=7 D=-1 P=1001/9 on d1 11:44:22.202 > trk pos 02.2/Q010=Q255 idx=7 D=-1 P=1000/8 on d1 11:44:22.204 > trk pos 02.1/Q009=Q002 idx=7 D=-1 P=1100/12 on d1 11:44:22.204 > Copy track: 00.2/Q009 11:44:22.210 > trk pos 02.0/Q008=Q002 idx=7 D=-1 P=0100/4 on d1 11:44:22.214 > trk pos 01.3/Q007=Q002 idx=7 D=-1 P=0110/6 on d1 11:44:22.218 > trk pos 01.2/Q006=Q255 idx=7 D=-1 P=0010/2 on d1 11:44:22.222 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.222 > Copy track: 00.1/Q005 11:44:22.225 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.261 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1 11:44:22.271 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.271 > Copy track: 00.1/Q005 11:44:22.274 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.311 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1 11:44:22.321 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.321 > Copy track: 00.1/Q005 11:44:22.324 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.362 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1 11:44:22.372 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.372 > Copy track: 00.1/Q005 11:44:22.375 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.412 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1
— Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-firmware/issues/892#issuecomment-2762183491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZSDA2AN2IUQFXWKNCD2WWLINAVCNFSM6AAAAABZ5RHUCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRSGE4DGNBZGE . You are receiving this because you commented.Message ID: @.***> [image: FozzTexx]FozzTexx left a comment (FujiNetWIFI/fujinet-firmware#892) https://github.com/FujiNetWIFI/fujinet-firmware/issues/892#issuecomment-2762183491
What seems to be happening is that the FujiNet is missing steps. ProDOS steps the head down just fine by rolling the stepper waveform, with around 4 milliseconds per step. Suddenly the FujiNet has a delay of 40 milliseconds every 4th step and so it thinks the stepper is going the other way and does D=2.
11:44:22.195 > trk pos 03.0/Q012=Q003 idx=7 D=-1 P=0001/1 on d1 11:44:22.199 > trk pos 02.3/Q011=Q003 idx=7 D=-1 P=1001/9 on d1 11:44:22.202 > trk pos 02.2/Q010=Q255 idx=7 D=-1 P=1000/8 on d1 11:44:22.204 > trk pos 02.1/Q009=Q002 idx=7 D=-1 P=1100/12 on d1 11:44:22.204 > Copy track: 00.2/Q009 11:44:22.210 > trk pos 02.0/Q008=Q002 idx=7 D=-1 P=0100/4 on d1 11:44:22.214 > trk pos 01.3/Q007=Q002 idx=7 D=-1 P=0110/6 on d1 11:44:22.218 > trk pos 01.2/Q006=Q255 idx=7 D=-1 P=0010/2 on d1 11:44:22.222 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.222 > Copy track: 00.1/Q005 11:44:22.225 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.261 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1 11:44:22.271 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.271 > Copy track: 00.1/Q005 11:44:22.274 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.311 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1 11:44:22.321 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.321 > Copy track: 00.1/Q005 11:44:22.324 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.362 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1 11:44:22.372 > trk pos 01.1/Q005=Q001 idx=7 D=-1 P=0011/3 on d1 11:44:22.372 > Copy track: 00.1/Q005 11:44:22.375 > trk pos 01.0/Q004=Q001 idx=7 D=-1 P=0001/1 on d1 11:44:22.412 > trk pos 01.2/Q006=Q255 idx=2 D=2 P=0010/2 on d1
— Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-firmware/issues/892#issuecomment-2762183491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZSDA2AN2IUQFXWKNCD2WWLINAVCNFSM6AAAAABZ5RHUCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRSGE4DGNBZGE . You are receiving this because you commented.Message ID: @.***>
Hooked up logic analyzer to see what ProDOS is actually sending when it goes into the loop. It really does have a 40ms delay and has stopped stepping.
Just to confirm logic analyzer is hooked up correctly, here's a capture during the initial boot just before the splash screen.
I had a try with this disk image. the first time it booted up ok. Then I did a few more and its gives me inconsistent behavior. works sometimes, and other times gives the looping symptoms. On a IIe enhanced with a db19 controller and the latest rc1.5 build
