We have quite a bit planned for Rom Raider and I wanted to organize everything. Other devs, please edit this post to add anything you have planned. Expect these changes in version 0.6.0 beta and beyond, hopefully within a month or two. We're now tracking all tasks in Trac (http://trac2.assembla.com/romraider/report/2), and the "Tasks" link to the left has been updated to reflect.

Version 0.6.0GUI overhaul- Move toolbars from table window to main window- Improved keyboard shortcuts-- +/- work more intuitively-- Tab to switch from table list to table window-- Ctrl-a to select all-- Shift-insert to paste- Different table views on tabs (table, line/bar graph, 3d, show changes, etc)- Value selections persist between table view types- Scrolling for large tables- Greatly improved load speed and memory usage- More intuitive "Save" system-- Keyboard shortcuts conform to Windows standards-- Warning when overwriting file-- Possible option to append timestamp to filename and retain old file- Warn on close and revert changes- Make selected rom more obvious when multiple files are open

The guy(s) developing the software being mentioned on that site are incredibly talented. While the only downloadable software I could find is FreeSSM, they seem to have developed a tool for locating and annotating all the tables in a ROM. I left a comment asking where this tool can be downloaded as I think it would greatly help us with regards to creating new defs.

The guy(s) developing the software being mentioned on that site are incredibly talented. While the only downloadable software I could find is FreeSSM, they seem to have developed a tool for locating and annotating all the tables in a ROM. I left a comment asking where this tool can be downloaded as I think it would greatly help us with regards to creating new defs.

I think you have to wait a little time for it, till the link is posted (like me too).One of the guys is part of this this forum, too. Maybe he give some infos or leave a commend

There aren´t many people working sucessfully on the Diesel, but there you can read about amaising sucesses

I don't think this is of any value to us. EcuFlash only rewrites the changed blocks of the flash area when comparing it to the local copy of the ROM, so this value never changes. At least not for me, it returns 0xFFFF. As they state, it appears to be updated by the bootloader and EcuFlash is not that.

It was more personal interest. I didn't realise that there was a reflash counter in the ROM.

dschultz wrote:

EcuFlash only rewrites the changed blocks of the flash area when comparing it to the local copy of the ROM, so this value never changes. At least not for me, it returns 0xFFFF. As they state, it appears to be updated by the bootloader and EcuFlash is not that.

I haven't really read much about how our ECUs are flashed, but doesn't EcuFlash use the bootloader to execute its own code in RAM for reflashing? In that case, does the bootloader protect that specific area of the ROM and then increment the counter after the reflash operation finishes? I don't want to take the thread off-topic, so if you have more info for me and don't mind PMing me, that'd probably be better.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum