Open aperezbios opened 1 year ago
@PetteriAimonen any thoughts on what might be going on here?
Closed duplicate issue #43, however that issue does contain one more log using a different boot dongle for the system.
INFO: namco 2x6 boots from a security dongle and then accesses IDE for game data. As such, different security dongles (games) may behave differently.
Setup info: Namco 256 with 246+ Jumper set.
Here's a Debug log with the motherboard in 256 mode. The non-debug log is much shorter, but with debug enabled, it seems to also have an issue with IDE_CMD_NOP eventually; I could speculate it is a different manifestation of the same issue.
[10ms] Platform: ZuluIDE RP2040 [10ms] FW Version: 2023.07.26-dev Jul 26 2023 17:08:40 [11ms] DIP switch settings: cablesel 1, drive_id 0 debug log 1 [11ms] Flash chip size: 2048 kB [12ms] Flash unique ID: 0x2C0F73E3085062E6 [13ms] DBG Loading FPGA bitstream [102ms] FPGA initialization succeeded [109ms] SD card detected, FAT32 volume size: 29542 MB [110ms] SD MID: 0x27, OID: 0x50 0x48 [110ms] SD Name: SD32G [110ms] SD Date: 4/2021 [111ms] SD Serial: 0x000001A4 [115ms] Could not determine image type by filename, defaulting to: CD-ROM [116ms] Loading image te51-dvd0.iso [554ms] DBG Image file te51-dvd0.iso is contiguous, sectors 10897236 to 19119955 [570ms] Device 0 configuration: [571ms] -- Max PIO mode: 3 (phy max 3) [571ms] -- Max UDMA mode: 0 (phy max 0) [572ms] -- Max blocksize: 4096 (phy max 4096) [574ms] DBG -- Operating as primary drive, secondary drive not detected [575ms] Initialization complete! [577ms] DBG IDE_EVENT_HWRST [1080ms] DBG -- Operating as primary drive, secondary drive not detected [1578ms] DBG -- IDE regs: STATUS:0x00 CMD:0xFF DEV:0x00 DEVCTRL:0xFF ERROR:0x01 FEATURE:0xAA LBAL:0x01 LBAM:0x14 LBAH:0xEB [2000ms] FPGA license request code: 0xE6 0x62 0x50 0x08 0xE3 0x73 0x0F 0x2C 0xFF 0xFF 0xEF 0xFF 0xEE 0x39 0xDF 0x89 0xA3 [2001ms] FPGA license accepted with status 0x80 [17384ms] DBG -- Operating as primary drive, secondary drive not detected [18198ms] DBG IDE Command for DEV1: 0x00 IDE_CMD_NOP (device 0x10, dev_ctrl 0x02, feature 0x00, sector_count 0x34, lba 0xEB 0x14 0x12) [18200ms] DBG -- Ignoring command for device not present [18883ms] DBG -- IDE regs: STATUS:0x80 CMD:0x00 DEV:0x10 DEVCTRL:0x02 ERROR:0x01 FEATURE:0x00 LBAL:0x12 LBAM:0x14 LBAH:0xEB [33898ms] Detected IDE STATUS register stuck at busy state 0x80 for 16 seconds, resetting to zero [34899ms] DBG -- IDE regs: STATUS:0x00 CMD:0x00 DEV:0x10 DEVCTRL:0x02 ERROR:0x01 FEATURE:0x00 LBAL:0x12 LBAM:0x14 LBAH:0xEB
I think IDE_CMD_NOP may actually be the culprit - I don't think there is a proper handler for it.
I wonder if the host is actually issuing NOP command or if it is somehow mistransferred, but in any case there is some weird remaining busy state after it. I couldn't find an utility to send raw ATA commands on Linux, but it appears to be possible via HDIO_DRIVE_CMD ioctl.
@PetteriAimonen I think we're going to have to implement support for IDE_CMD_NOP, as I've run in to several instances where it's being issued.
Hmm, turns out the IDE_CMD_NOP is expected to always fail, which is what the default handler does anyway. The actual bug has to be something else..
Hmm, turns out the IDE_CMD_NOP is expected to always fail, which is what the default handler does anyway. The actual bug has to be something else..
Thanks for the reply and work.
These ISOs are from DVDs if that wasn't mentioned. I noticed this issue:
https://github.com/rabbitholecomputing/ZuluIDE-firmware/issues/7
Let me know if you think that's relevant, or if there are any other things I can try with the debug dip set.
@Alex-Kw DVD ISOs probably still have issues, but the difference would matter only when it gets to actually reading the disc.
You could try the latest build from https://github.com/rabbitholecomputing/ZuluIDE-firmware/releases/tag/latest and post the debug log from it. It has some small changes to how unexpected situations are handled.
@PetteriAimonen Thank you, I've updated the firmware and here's the first result with just the debug DIP switch set. I wonder if it's looking for a second drive and no primary? I believe the CD/DVD Drive I pulled was on cable select, so if it helps, I can obtain logs with the ZuluIDE device configured the other ways (Cable Select or PRI/SEC).
[10ms] Platform: ZuluIDE RP2040 [10ms] FW Version: 2023.08.23-dev Aug 24 2023 04:40:07 [11ms] DIP switch settings: cablesel 0, drive_id 0 debug log 1 [11ms] Flash chip size: 2048 kB [12ms] Flash unique ID: 0x2C0F73E3085062E6 [13ms] DBG Loading FPGA bitstream [102ms] FPGA initialization succeeded [109ms] SD card detected, FAT32 volume size: 29542 MB [110ms] SD MID: 0x27, OID: 0x50 0x48 [110ms] SD Name: SD32G [110ms] SD Date: 4/2021 [111ms] SD Serial: 0x000001A4 [116ms] Could not determine image type by filename, defaulting to: CD-ROM [117ms] Loading image te51-dvd0.iso [558ms] DBG Image file te51-dvd0.iso is contiguous, sectors 10897236 to 19119955 [580ms] Device 0 configuration: [580ms] -- Max PIO mode: 3 (phy max 3) [581ms] -- Max UDMA mode: 0 (phy max 0) [581ms] -- Max blocksize: 4096 (phy max 4096) [584ms] DBG -- Operating as primary drive, secondary drive not detected [585ms] Initialization complete! [587ms] DBG IDE_EVENT_HWRST [1092ms] DBG -- Operating as primary drive, secondary drive not detected [1589ms] DBG -- IDE regs: STATUS:0x00 CMD:0xFF DEV:0x00 DEVCTRL:0xFF ERROR:0x01 FEATURE:0xAA LBAL:0x01 LBAM:0x14 LBAH:0xEB [2000ms] FPGA license request code: 0xE6 0x62 0x50 0x08 0xE3 0x73 0x0F 0x2C 0xFF 0xFD 0xEF 0xFF 0xEE 0x39 0xDF 0x89 0xA3 [2001ms] FPGA license accepted with status 0x80 [17410ms] DBG -- Operating as primary drive, secondary drive not detected [18223ms] DBG IDE Command for DEV1: 0x00 IDE_CMD_NOP (device 0x10, dev_ctrl 0x02, feature 0x00, sector_count 0x34, lba 0xEB 0x14 0x12) [18224ms] DBG -- Command was for a device that is not present - reporting failure [18908ms] DBG -- IDE regs: STATUS:0x41 CMD:0x00 DEV:0x10 DEVCTRL:0x02 ERROR:0x04 FEATURE:0x00 LBAL:0x12 LBAM:0x14 LBAH:0xEB
@PetteriAimonen any thoughts on what might be going on here?
I think something has to be going significantly wrong with the register writes, resulting in garbage values.
Possibly some kind of timing issue, but that's very hard to debug without having a logic analyzer trace.
@PetteriAimonen I have a Saleae Logic 8 here. If that would be sufficient, let me know what signals to monitor and I could probably give it a try.
@Alex-Kw It's certainly worth a try.
Here are the most useful 8 signals to probe:
Trigger on falling edge of DIOW. Ideally samplerate would be at least 10 MHz, and capture for at least 3 seconds.
I've marked the location of pins on the bottom side of ZuluIDE PCB in the image below, but you can probe wherever it is easiest - either on the ZuluIDE connector, or on another connector on a 3-connector IDE cable.
OK, Here it is. This is a full capture from trigger until the system locks up / stops trying to access. You should be able to use Saleae Logic 2 software for free to open the capture (presuming you don't have it already).
I truly hope it helps. I fashioned a quick cable to connect my Saleae Logic 8 to a 3 connector IDE cable (great idea, thank you), so if further testing is required with this pinout I am good to go. TE5-DVD0.sal.zip
@Alex-Kw excellent, thank you for this trace. I hope it sheds some light on WTF is going on :)
@Alex-Kw Thanks, I'll try to dig into older versions of the ATAPI specification to see if they clarify anything. Do you happen to know whether the Namco hardware is usually picky about which CD drives it supports, or does it generally work with any drive? If you have a compatible drive available, doing the same logic analyzer capture with it would provide useful information.
Here are some initial notes, I'm not yet sure how each of them will affect things:
Host has both read and write signals in active state for 1 second after boot. This is not a valid state, so ZuluIDE could ignore it. Currently it will be interpreted as either read or write randomly, based on which signal activates first. Results in garbage data written to IDE registers, but I think it will not matter as it is replaced later.
The host uses old-school way of directly connecting the IDE bus to system (ISA?) bus. There is a lot of other traffic on the bus. ZuluIDE should be ignoring this, but testing on that has been a bit sparse because the systems I currently have use a separate IDE controller chip.
The write sequence looks like this:
For some reason there are two pulses on DIOW instead of one. The first one possibly violates ATA specification Address valid to DIOW
minimum time. I think the double write may be related to behavior of IOCS16 signal, which ATA devices use to indicate to host that destination register has 16 bits. It should work on ZuluIDE but again I don't have a system that requires it.
First command occurs at 18 seconds after boot. Register transfer sequence decoded:
Then after 1 µs pause
And after that it appears to decide there is no drive to talk to.
After the first COMMAND write ZuluIDE will be in BUSY state. My interpretation of the ATAPI6 specification is that the result of further writes is indeterminate at this point. But the host is clearly expecting some immediate effect on the STATUS register.
Thanks for the immediate thoughts @PetteriAimonen, I'll be happy to repeat the test with a working optical drive.
Regarding how picky the system is, for the most part, most drives work. There are a couple of games, namely Tekken 4 and Bloody Roar 3, that are themselves known to be very picky with ATAPI command set and thus drive selection. I am purposely avoiding them for now, Tekken 5 (in use here) is usually quite agreeable drive-wise. I'll upload the other trace ASAP.
@PetteriAimonen Here is the same capture setup / same boot dongle, with an optical drive instead of the ZuluIDE+disc image. Hopefully it provides some insight, I let it run until it was loading game data for ~20-30 seconds.
Thanks.
Weirdnesses 1-3 appear exactly the same, so I think they are working ok with ZuluIDE also.
There is a clear difference in the command sequence. Instead of only reading STATUS once, the host dutifully polls for 100 ms until the device is ready:
WR SECTOR_COUNT xxx1xxx0 RD SECTOR_COUNT WR LBA_LOW xxx1xxx0 RD LBA_LOW WR DEVCTRL? WR FEATURE xxx0xxx0 WR DEVICE xxx0xxx0 WR CMD xxx0xxx0 WR CMD xxx0xxx0 RD STATUS xxx0xxx0 RD STATUS xxx0xxx0 RD STATUS xxx0xxx0 .. polls for 100 ms RD STATUS xxx1xxx1 WR DEVICE xxx1xxx0
This is how it should work, so it seems the first STATUS reply by ZuluIDE has something that the host doesn't like.
It's difficult to capture the entire status register contents with a 8-channel analyzer, but I'll try to reproduce the sequence here in FPGA simulator and compare the value against specifications.
@Alex-Kw I have a test build here. It tries to speed up the response to STATUS read by a bit, and sets bit 4 so that I can see in trace when the response is ready.
New trace and new debug log from this build would be useful.
https://github.com/rabbitholecomputing/ZuluIDE-firmware/actions/runs/6034876110
@PetteriAimonen Sure, here you are. Thanks for your help so far.
Edit; this might be 1st boot where the firmware updated. If this isn't what you expect in the trace I'll rerun it.
The upgrade looks ok, trace of D4 changed as expected. Based on trace, the timing meets ATA standards with plenty of time to spare, but for some reason the host still does not appear to like the STATUS response. But the host seems to violate timing in a few places, so it might expect tighter than standard behavior from the drive.
I will attempt some further timing improvements in the FPGA code, but that will have to wait until next week.
In the meanwhile if you are eager to test, traces of both ZuluIDE and the physical CD-ROM drive with D7 / pin 3 probed instead of D4 could confirm that the status BSY state is actually as I expect. If the logic analyzer is capable of higher samplerate, that would be useful also.
Sounds good. I can attempt to marginally increase the sample rate; I believe I'm at 20MHz and may be able to get 25MHz. I'll try. Moving the pin over from D4 to D7 shouldn't be an issue either.
Thanks, that seems to confirm that it is a response time issue. Based on the trace:
In the newest trace it appears to get just a tiny bit further with ZuluIDE before failing, so it's probably close to the edge now.
Any update on this? The natives are getting restless and some are considering upwards of $300 on a working IDE ODE for the Namco 245/256
@Alex-Kw Unfortunately no.. it proved a quite complex issue and I haven't been able to work on it.
@Alex-Kw Unfortunately no.. it proved a quite complex issue and I haven't been able to work on it.
That is unfortunate... anything that can be done to help? Yet again people are seeking a working IDE ODE for the Namco 246 / 256 and are pointing to a $335 product with hope; https://www.arcade-projects.com/threads/ide-simulator-using-it-in-a-namco-246-256.28716/#post-412677
@Alex-Kw can you please try this again with https://github.com/rabbitholecomputing/ZuluIDE-firmware/releases/tag/v2024.05.14 and report back with a debug log file on it? Please try with debug mode both enabled and disabled
@Alex-Kw can you please try this again with https://github.com/rabbitholecomputing/ZuluIDE-firmware/releases/tag/v2024.05.14 and report back with a debug log file on it? Please try with debug mode both enabled and disabled
I should be able to try this again soon, my Namco hardware and IDE accessories were mistakenly taken with a cabinet purchase but are set to be returned to me soon. I'll report back as soon as I'm able to revisit this and retry! Thank you :)
Are there any updates on this?
Reported by @Alex-Kw , an early adopter/beta tester: