Using EPCQ256 in x1 mode with remote update - Stratix IV E

[Altera_Forum]

I'm using the EPCQ256 config device for my Stratix IV E design. We were using the EPCS128, but it's not large enough. 

I have the SOIC16 device wired up in x1 mode.  I'm able to use the Quartus programmer (along with a jic file) to write my image to the factory location (page 0). Power-cycling my board results in the FPGA configuring as expected - so the basic wiring/connections must be correct. I'm using Quartus 12.0.1.  The altasmi_parallel module, which I use in my application to read/write the PROM, has an option to select which PROM-type is out there. If I set this to an EPCS128 (a previous revision of my board used the EPCS128), I am able to read and write the EPCQ256 PROM just fine (using half of the device). I can also read the ID and status and receive valid values (0x19 for the ID). However, if I set the altasmi_parallel module to use an EPCQ256, I am unable to get anything other than 0xFF when reading the ID, status, or data. Using SignalTap I'm able to observe the busy signal get asserted for a short time, then go away and then the 'read-valid' output from the altasmi module is asserted along with the 0xFF data; so, the altasmi block is responding with that data, it's not just sitting on the outputs of the module.  Is anyone else successfully using the EPCQ256 in x1 mode along with the appropriate altasmi module for remote updating?  I am confident my application logic interfacing with the altasmi module is mainly correct because the exact same logic is used to interact (successfully) with the altasmi module when it is an EPCS128 version.

[Altera_Forum]

Quick update: I moved to Quartus 12.1 and regenerated the altasmi_parallel module (EPCQ256) and synthesized. The resulting sof file gave me access to the EPCQ256 PROM to read and write data and ID and status. One odd thing is that the device ID is returned as 0x10 rather than the expected 0x19.  

 If I use the EPCS128-version of altasmi_parallel the ID can be read back as 0x19, as expected. I have an open SR with Altera about this and they recognized similar results - reading the EPCQ256's ID with an EPCS128 version of altasmi returned 0x19, using the 'proper' altasmi module returned 0x10. They are looking into this internally, too.