| T O P I C R E V I E W |
| pderocco |
Posted - 03/05/2012 : 22:38:54
1) When you open a file, and you choose the Read Mode, Even Byte gives you the odd bytes, and Odd Byte gives you the even bytes. The other choices work correctly.
2) Worse, if you select any Read Mode other than Normal, you get a half or a quarter of the data that you should. For instance, if you're burning an 8K EPROM like a 2764, and you select Even Byte, you only get a 4K buffer containing the even bytes out of the first 8K of the file. This makes no sense. It should give you the even bytes out of the first 16K of the file, for a total of 8K, since that's how big the EPROM is.
3) It took me a while to figure out that if I want to extract the second 8K from a file, I need to specify a file offset of -2000, rather than 2000. This makes no sense. Since files can't contain negative addresses, this number must always be zero or negative. The file offset should be subtracted from the file addresses rather than added to it, so that the user always specifies a zero or positive offset.
4) After burning about eight EPROMs. I'm already tired of changing the Fill Mode from Normal to Fill 'FF'. Please make this sticky, at least within a session.
|
| 3 L A T E S T R E P L I E S (Newest First) |
| pderocco |
Posted - 03/08/2012 : 12:20:18
quote:
Originally posted by ZLM
Thank you for your feedback. I think there are no many users use those features. This is why the bug not been reported.
So does that mean that these bugs are likely to be fixed in the near future? Is the software still being supported, or is it only the devices.txt file that gets updated?
quote:
For your question 4, the file fill mode "Normal" is same as "FF". So you do not have to select the "FF" every time.
I don't believe that's true for hex files. If there are gaps in the data, it appears that the old buffer contents are retained from the previous hex file that was loaded.
|
| ZLM |
Posted - 03/06/2012 : 18:15:40
Thank you for your feedback. I think there are no many users using those features. This is why the bug not been reported.
For your question 4, the file fill mode "Normal" is same as "FF". So you do not have to select the "FF" every time.
Others we need to confirm them. |
| pderocco |
Posted - 03/05/2012 : 23:00:52
Re the above:
1) is only a problem when you're reading a hex file, not when you're reading a binary file. (At least it's true for Intel hex.)
3) This works (backwards, in my view) on hex files, but doesn't work at all on binary files. If I have a 16K file, and I want to burn the second half into an 8K EPROM, I ought to be able to specify an offset of 2000, but I concede that the way the program works now, I should specify -2000. But when I do that, I get an empty buffer. If I specify -100, I get the data shifted down in the buffer by 256 bytes, but it doesn't read further into the binary file, it just fills the top 256 bytes in the buffer with FF.
The only way I can use this software reliably is to break my data into individual binary files matching the size of the EPROM, and not specify any options. I can't believe bugs like this could be in version 6 of any software. Does anyone actually use this stuff? This is like version 0.9 beta crap.
|
|
|
