Unable to load shell on real hardware

[famiclone6502]

I have an NES with a Famicom EXP port mod, plus a Famicom keyboard and flash carts.

Using the Everdrive N8 Pro I am able to type just fine, but when I try to load (l sh), it gives one of these various behaviors:

1. It just goes to the next line as if nothing happened.
2. It starts to read and locks up (I left it for a long while just to be sure).
3. I receive an I/O error.

I am unable to load the disk at all using the PowerPak, it locks up on the load screen.

I don't have a real floppy drive or RAM cart setup to test with, unfortunately.

(Very cool project, thanks for sharing!)

[decrazyo]

I can think of 2 issues that might be causing this.

1. I think the Everdrive N8 Pro uses a custom BIOS by default and the disk driver uses the BIOS (possibly in unintended ways) in a few places.
2. The disk driver may have a few unresolved race conditions or something. that code is kind of a mess.

You could try making your Everdrive use a "legally obtained" copy of the FDS BIOS, if you haven't already, by putting it in "EDN8/disksys.rom".

[famiclone6502]

That's a great suggestion. I didn't think about it not being the original BIOS with the jingle on boot-up. Unfortunately, I haven't been able to get any disksys.rom to work in the EDN8 directory. It still uses the built-in blue screen version, no matter which one I've tried. I even truncated the first 16 bytes just to be sure there wasn't a header, as the release notes said it required not being there. I am on the latest firmware, confirmed in the menus. I'll ask around if anyone has gotten this to work correctly, see what they use.

If you did get the original BIOS to work, let me know what the checksums are for the file so I can be sure that I'm using the correctly prepared version.

Thanks!

[decrazyo]

I've got the older Everdrive N8 (non-pro) which doesn't seem to support changing the disk system BIOS so I haven't been able to test that out myself.

[kazueda]

Hello from Japan.
I am trying to use your LUnix shell. I encountered the I/O error with the message of "[0001] unhandled: I/O error." My circumstance is Sharp Twin Famicom, Disk System RAM Adaptor, and FDS Emulator. When you need some alpha testers, please notice me. I will help you.

Here is a movie of booting LUnix.
https://twitter.com/kazueda/status/1758679666431541625

I also own a China clone Everdrive N8 which can load fds files. After receiving "l sh" command, my system freezes for a long time.

[decrazyo]

This is hard to debug/develop with the equipment I have so forgive me for just putting my thoughts/ideas out here.
I've dug into my driver code and there are only 2 things that should result in an I/O Error.

1. A block ID was read that didn't match an expected block ID. (likely)
2. The driver failed to verify the checksum at the end of a block. (unlikely)

Here's what I think is happening.
On my emulator of choice (Mesen) the disk drive immediately returns to the beginning of the disk when it's requested to. But on real hardware, and possibly drive emulation like Everdrives and the FDSKey, it likely take some time to return to the beginning of the disk.
If the driver doesn't properly account for the time that it takes to return to the start of the disk (and it probably doesn't) then it will eventually end up reading some random part of the disk while thinking it's at the beginning. That would probably cause an I/O Error but might also cause random crashes depending on what data happens to be read.

I'll review my code and see if I can identify the problem.

[kazueda]

Thank you for you reply. My FDS Emulator and Chinese clone Everdrive N8 show a file selecting menu. These interfaces may cause the missing of the 1st block of the lng-fds files.

[famiclone6502]

I should also mention that it detects my NTSC NES as a 50hz PAL unit on startup. Let me know if you want me to open a separate issue for this, but I thought it might cause timing issues with reading a disk.

[kazueda]

To famiclone6502-san. You mentioned that you used your Everdrive N8 Pro for booting the lunix.fds. Is it possible to set your Everdrive N8 Pro autoboot mode and boot your NES with Everdrive N8 Pro?

[famiclone6502]

To famiclone6502-san. You mentioned that you used your Everdrive N8 Pro for booting the lunix.fds. Is it possible to set your Everdrive N8 Pro autoboot mode and boot your NES with Everdrive N8 Pro?

Yes, I've been using auto-boot. Sometimes the behavior differed when using auto-boot, sometimes it didn't, but it would do one of those three issues originally described. They both say 50hz PAL.

[decrazyo]

@famiclone6502 The 50hz PAL issue is probably unrelated to the shell loading issue. The disk driver treats all systems identically, regardless of how it was identified. Feel free to open another issue for that.

[kazueda]

Thank you for your reply.
My progress.
I obtained FDSkey. This gadget checks the file size of lunix.fds. So I expanded the size of file to 65516 bytes. This modified file was loaded and showed "." prompt.
After typeing "l sh," I saw the error message of "[0001] unhandled: I/O error." on TV.
At the same time the display on my FDSkey showed an error message of "Wrong block CRC."
Disk reading was terminated at header part.
Any advice?

[decrazyo]

The "Wrong block CRC" message from the FDSkey definitely suggests that the driver is failing to verify the checksum.
I spent some time trying to find/fix the problem in the driver but I haven't had much luck.
I probably won't be able to fix this without better hardware to develop/test with.

[TakuikaNinja]

I'm getting a hang after running the command in Mesen2. You really ought to test it on this emulator with the recommended developer settings.

[kazueda]

@decrazyo Thank you for telling your progress to us. Accoridng to my FDSkey responce, reading data stopped at the end of header region. I imagine that FDS file can not inform the begining of the disk to the CRC checking IC. I think we need to add the information of an end of disk or of a begining of the disk to the FDS file. I will try to add GAPS between "FDS" and "*NINTENDO-HVC*" later.

Reference

1. Gaps
   Physically on the disc, there are "gaps" of 0 recorded between blocks and before the start of the disc. Length of the gaps are as follows:
   Before the start of the disc : At least 26150 bits, 28300 typical.
   https://www.nesdev.org/wiki/FDS_disk_format

2. Disk format in Japanese
   http://cmpslv2.starfree.jp/Famic/Famdis.htm

[kazueda]

@TakuikaNinja Could you tell us your Mesen2 setting. If possible, please show us Mesen2's debugger message.

[TakuikaNinja]

@decrazyo Thank you for telling your progress to us. Accoridng to my FDSkey responce, reading data stopped at the end of header region. I imagine that FDS file can not inform the begining of the disk to the CRC checking IC. I think we need to add the information of an end of disk or of a begining of the disk to the FDS file. I will try to add GAPS between "FDS" and "NINTENDO-HVC" later.

Reference

1. Gaps
   Physically on the disc, there are "gaps" of 0 recorded between blocks and before the start of the disc. Length of the gaps are as follows:
   Before the start of the disc : At least 26150 bits, 28300 typical.
   https://www.nesdev.org/wiki/FDS_disk_format

2. Disk format in Japanese
   http://cmpslv2.starfree.jp/Famic/Famdis.htm

The .fds format does not include gaps or CRC data. I think it may be something else about the disk file layout which is incorrect.

[TakuikaNinja]

@TakuikaNinja Could you tell us your Mesen2 setting. If possible, please show us Mesen2's debugger message.

(I use a HIDPI monitor, which makes my screenshots really large. sorry.)
The upper half of the setting menu here should all be enabled for debugging/development purposes. The lower half is just for relatively inconsequential stuff like PPU reset behaviour & $2004 readability.