vdrive swaps `sd_lba_i[]` array members

[Rhialto]

I was working on integrating the 4040/8250 from https://github.com/eriks5/CBM-II_MiSTer/blob/master/rtl/ieee_drive into my MegaPET core. The drive behaved strangely.

With some analysis, I found out that drive 0 always received the data from track 18, even when it tried to read other tracks. It turned out that drive 1 was set to track 18.

So in my main.vhd file I swap the LBA values for the drives, when I feed them to vdrives_inst. The same for the number of sectors. With that change it works.

   vdrives_inst : entity work.vdrives
      generic map (
         VDNUM                => G_VDNUM,             -- amount of virtual drives
         BLKSZ                => 1                    -- 1 = 256 bytes block size
      )
      port map (
...
         -- MiSTer's "SD block level access" interface, which runs in QNICE's clock domain
         -- using dedicated signal on Mister's side such as "clk_sys"
         -- BUG ??? Swap LBAs of drive 0 and 1
         sd_lba_i         => ( 0 => iec_sd_lba(1), 1 => iec_sd_lba(0) ), -- was iec_sd_lba,
         sd_blk_cnt_i     => ( 0 => iec_sd_blk_cnt(1), 1 => iec_sd_blk_cnt(0) ),-- was iec_sd_blk_cnt, -- number of blocks-1
         sd_rd_i              => iec_sd_rd,
         sd_wr_i              => iec_sd_wr,
         sd_ack_o             => iec_sd_ack,

This swapping I have done here is of course totally un-generic and working for 2 drives only.

I haven't found if the actual bug is in the vhdl for the vdrives or in the QNICE assembly code (at least I assume there is some code involved to copy the disk's data at runtime).

This may explain also why in my earlier attempts to have 2 2031 drives, it didn't work very well.

[Rhialto]

Could it be that the VHDL declaration

signal iec_sd_lba           : vd_vec_array(G_VDNUM - 1 downto 0)(31 downto 0);

and the one from (system) verilog

output      [31:0] sd_lba[NBD],

the endian-ness of [NBD] corresponds to 0 upto G_VDNUM - 1?
In which case the solution might be

signal iec_sd_lba           : vd_vec_array(0 upto G_VDNUM - 1)(31 downto 0);

and similarly for iec_sd_blk_cnt and iec_sd_buf_data_out ?
(so far I did not swap the last one and did not notice if it might need to be swapped).

This would need to be changed both in main.vhd and vdrives.vhd I expect.

[Rhialto]

iec_sd_buf_data_out is the data from the internal track buffer towards the disk image buffer of QNICE.

I was reflecting on the previous comment and thinking: If iec_sd_buf_data_out needs to be swapped too, and I didn't swap it, then the disk images would get corrupted,
But the images don't get corrupted, so this doesn't need to be swapped, which in turn means that the "endianness" theory from the previous comment can't be true.

However, when looked a bit closer at this 4040: I instantiated one of those, and it has 2 "subdrives" as it is called internally. sd_buff_din[0] (internal name) and sd_buff_din[1] always have the same value. The 4040 shares its internal track buffer between the two "subdrives".
So even if the wrong one of those two is used, it doesn't matter.

As a result, the endianness theory can still be correct. It could be tested if you instantiate 2 4040s, or 2 2031s would also work. Maybe I'll do that later, but not now....

[sy2002]

Hey @Rhialto , I just wanted to post a "sign of life" and say THANK YOU that you are using M2M and that you are reporting potential bugs and doing research. This is HIGHLY appreciated. My "real life" currently prevents me from doing any nerdy M2M stuff - but this will change again in future. So please bear with me. And it is cool to see that you have workarounds and that you are not blocked.

I could need some help with the M2M documentation. Since you are starting to work from scratch with M2M, are you interested in supporting? (No timing pressure.)