Closed rpaessle closed 9 months ago
What color does the RGB led on the TN show? Red means the M0S is aware of a problem with the SD card.
Also the nestang uses a rather low clocked 1 bit access method while MISTeryNano uses high clocked 4 bit mode. So this isn't necessarily comparable.
Can you try a different SD card?
The RGB LED is not lit at any time during boot or after the crash. By the way, after crashing, pressing the S2 reset does reinitialize the TN, but the M0s is still frozen with no mouse or keyboard activity. I have previously used Kingston SD cards of 2GB and 8GB capacities without success. The only other one I have at the moment is a Samsung 64GB card, which also did not work with the same symptoms. What brand of SD card do you use?
Pressing the reset button resets only the embedded Atari st.
No led lights up at all? But you can use a USB keyboard to control the OSD? What release are you using?
I am using various SanDisk cards from 4 to 32 GB and a bunch of Chinese no name 16GB. I've never tried a 64gb card but don't expect any issue there. But I doubt that it"s the card itself causing trouble here. I would be surprised if all of yours were incompatible while all of mine are. There's something else going on ...
The RGB LED is never lit, but there is fast flashing at all times on the 2 closest to the USB connector, which I assume is the TOS polling. This is on release 1.2.3 . I also tried the previous release 1.2.2, but I had erratic mouse movements and the same problem with SD. I am using a wireless Logitech mouse and keyboard through a receiver dongle. By the way, I did all firmware uploads using the Gowin tools in Windows 10, so I didn't read the Linux instructions at first. In there, I found the requirement for a file called DISK_A.ST . I had no blank disk images, so I created a blank double-sided 720k image (80 track, 9 sector, double-sided) in Hatari and used that. It made no difference.
The two LEDs flickering is correct. This also happens with the floppy LEDs on a real ST. It's the os checking for disk changes.
So if you can open the OSD and move the mouse then basically all parts work correctly and you have flashed everything as it should.
I am not sure of there's another core making full use of the SD card. In theory you could have a defective card slot with one of the additional data lines being damaged. You wouldn't notice that with any of the other cores as they only use 1 bit. But I don't consider this very likely.
I'd recommend you get a freshly formatted SD card of 8 or 16GB size. Format it with FAT32 and just copy a few files onto it.
The disk_a.st is not a must, anymore. I should update that. Also I should test the exact behaviour when problems with the SD card occur.
The one thing that really irritates me is that you don't get any output on the RGB led. I just tried without anything connected but the M0S and a power supply. No SD card, no HDMI, no USB peripherals. Then after about 3 seconds after power up the RGB led lights up blue indicating that the BL616 and the FPGA can talk to each other. A few seconds later the led turns red indicating a problem with the SD card (as none was inserted at all).
Can you run the RGB led demo from speed for the Tang Nano 20k? Does that work? Maybe some of the Pins are shorted? Please verify that pin 79 works properly. It's the data pin for the RGB led. And then also check pins 80 to 85. These are the SD card connections which are also exposed on the pin headers and might be shorted there.
I have had an unexpected development. The Gowin Programmer(education version) I had been using to write to the TN SRAM from Windows stopped working with the weird error "Any file not found". This happened on the second day for both version 1.98 and 1.99, so I assume some sort of protection is at play. I applied for a license but in the meantime, I went to my Linux machine and loaded the FPGA with openFPGALoader. This apparently loads to flash ROM and not SRAM. Lo and behold, the RGB led turns briefly blue and then green, and the drive A is visible and operational in the ST! I assumed SRAM and flash were operationally equivalent, so this is a bit upsetting. What would account for this difference? Is some SRAM overwritten?
openFPGAloader by default loads into sram. The -f option is required to load into flash.
If you load into sram, then the bl616 will not recognize that the fpga is in its cold boot state and hence, things don't fully work.
Otherwise sram also works fine. I'm usually run from sram during development. I might add a feature that the bl616 detects a newly loaded FPGA so it can re-initialize it properly. The bl616 e.g. needs to tell the FPGA about inserted disk images. It has no clue the FPGA has been re-initialized meantime and thus has forgotten about the disk images.
The GoWin Programmer doesn't reinitialize the flash properly and doesn't cope with the fact that MiSTeryNano makes use of the flash as well. Pressing and holding S2 on the TN20k during power-on will prevent the core from loading. As a consequence MiSTeryNano doesn't use the flash itself and thus even the GoWin Programmer can flash the board. This is all in the docs but I should perhaps make a troubleshooting page.
Understood. I did not fully appreciate what was detailed in MODES.md, specifically regarding the FPGA operational modes. I wonder if some of this information could be added to the INSTALLATION_WINDOWS.md document so that flashing is done correctly. I think I was misled by the image showing "SRAM Program" for atarist.fs and thought the FPGA SRAM had to be used.
I don't use windows.
A PR with easier to follow instructions is greatly appreciated.
I see what your problem was: The last screenshot shows that SRAM is selected which is the wrong selection. Can you perhaps provide an updated/correct screenshot?
Sure, here is the screenshot with the changes.
On Thu, Jan 25, 2024 at 8:08 AM Till Harbaum @.***> wrote:
I see what your problem was: The last screenshot shows that SRAM is selected which is the wrong selection. Can you perhaps provide an updated/correct screenshot?
— Reply to this email directly, view it on GitHub https://github.com/harbaum/MiSTeryNano/issues/20#issuecomment-1910190542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIYUIFKDR57MI3HJPW7KV6TYQJKOHAVCNFSM6AAAAABCHS2N2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJQGE4TANJUGI . You are receiving this because you authored the thread.Message ID: @.***>
Sure, here is the screenshot with the changes.
Uhm ... where's "here"?
Sorry, I guess email attachments don't make it through to here.
That's the screenshot that confused you? I assumed it was the last one which still sais "SRAM". I just "photoshopped" it to also say flash
I just set this up on a v3921 Nano with an external M0s Dock and almost everything works well, except the SD card detection. To test the hardware, I loaded Nestang and was able to see all .nes files on the SD. Using the same card, F12 on MiSTeryNano shows all drives with an X. Hitting enter on any drive causes an immediate crash, requiring a power down reset to correct. As per a previous issue, the file -s /dev/sdb1 produces the following:
/dev/sdb1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 247, hidden sectors 2048, sectors 15644646 (volumes > 32 MB), FAT (32 bit), sectors/FAT 15256, serial number 0x78ed1964, label: "TANG2 "
Any troubleshooting suggestions? I would throw a logic analyzer at this if the pins weren't so darn tiny. Even the SD card pins are embedded under the shell!