AndyDragon
Contributor
I have a shiny new VT 4.0 and have been loving it...imagine my (non) surprise when Oceanlog failed to download properly once the profile memory passed the 512Kb mark in the computer's memory. The profile is there, but Oceanlog fails to download properly. And I know why.
When the downloader in Oceanlog reads the internal log book entry for the profile data, it's not using the proper byte masks for the addresses.
Here's the list of profile addresses (and the original bytes) for my profiles. I use 2 sec profiling, so likely I'm the first one to hit this (or to notice it):
Dive 1: 0x00a50 ('A5 60' @ memory location 0x0424) to 0x03550 ('55 23' @ memory location 0x0426)
Dive 2: 0x03560 ('56 63' @ memory location 0x042C) to 0x05A20 ('A2 25' @ memory location 0x042E)
Dive 3: 0x05A30 ('A3 65' @ memory location 0x0434) to 0x089F0 ('9F 28' @ memory location 0x0436)
Dive 4: 0x08A00 ('A0 68' @ memory location 0x043C) to 0x0A330 ('33 2A' @ memory location 0x043E)
Dive 5: 0x0A340 ('34 6A' @ memory location 0x0444) to 0x0D710 ('71 2D' @ memory location 0x0446)
Dive 6: 0x0D720 ('72 6D' @ memory location 0x044C) to 0x10E90 ('E9 30' @ memory location 0x044E)
Dive 7: 0x10EA0 ('EA 70' @ memory location 0x0454) to 0x148A0 ('8A 34' @ memory location 0x0456)
Dive 8: 0x14830 ('83 74' @ memory location 0x045C) to 0x16E90 ('E9 36' @ memory location 0x045E)
The downloader worked for the first 6 dives, but after that, the profiles (and exit time and a few other things) at completely wrong. It seems that instead of using 1F as a mask for the second byte of the address values, the developer is using 0F. This means the address is being truncated to 512Kb when the downloader reads memory instead of 1024Kb. This leads to corruptions in the downloaded data.
Please correct this, I didn't pay for a $1000 computer which cannot be downloaded properly...
When the downloader in Oceanlog reads the internal log book entry for the profile data, it's not using the proper byte masks for the addresses.
Here's the list of profile addresses (and the original bytes) for my profiles. I use 2 sec profiling, so likely I'm the first one to hit this (or to notice it):
Dive 1: 0x00a50 ('A5 60' @ memory location 0x0424) to 0x03550 ('55 23' @ memory location 0x0426)
Dive 2: 0x03560 ('56 63' @ memory location 0x042C) to 0x05A20 ('A2 25' @ memory location 0x042E)
Dive 3: 0x05A30 ('A3 65' @ memory location 0x0434) to 0x089F0 ('9F 28' @ memory location 0x0436)
Dive 4: 0x08A00 ('A0 68' @ memory location 0x043C) to 0x0A330 ('33 2A' @ memory location 0x043E)
Dive 5: 0x0A340 ('34 6A' @ memory location 0x0444) to 0x0D710 ('71 2D' @ memory location 0x0446)
Dive 6: 0x0D720 ('72 6D' @ memory location 0x044C) to 0x10E90 ('E9 30' @ memory location 0x044E)
Dive 7: 0x10EA0 ('EA 70' @ memory location 0x0454) to 0x148A0 ('8A 34' @ memory location 0x0456)
Dive 8: 0x14830 ('83 74' @ memory location 0x045C) to 0x16E90 ('E9 36' @ memory location 0x045E)
The downloader worked for the first 6 dives, but after that, the profiles (and exit time and a few other things) at completely wrong. It seems that instead of using 1F as a mask for the second byte of the address values, the developer is using 0F. This means the address is being truncated to 512Kb when the downloader reads memory instead of 1024Kb. This leads to corruptions in the downloaded data.
Please correct this, I didn't pay for a $1000 computer which cannot be downloaded properly...