Shop OBEX P1 Docs P2 Docs Learn Events
upload code from eeprom — Parallax Forums

upload code from eeprom

Is it possible to recover code back to the prop ide from the propeller chip eeprom?

Comments

  • JonnyMacJonnyMac Posts: 9,159
    edited 2020-08-07 01:16
    You can read the binary image (compiled code), but you cannot restore the source from that.

    Edit: As Dave points out... not easily.
  • With a lot of work you can create a Spin/PASM source from a binary. A few years ago I wrote a disassembler for SPASM (Spin Assembly). It would decode the method tables, and identify the starting locations of methods and objects. It also generates SPASM mnemonics. The SPASM mnemonics could be analyzed by hand to generate Spin statements. Like I said, it would take a lot of work to generate source, but it's possible.
  • You could always put the eeprom in a programer and save it, copy it, and view it.
  • Cluso99Cluso99 Posts: 18,069
    Is the binary code in the eeprom any use or were you after the source?

    If it's the former then there have been routines to save the eeprom to a file. Before we go chasing will this do the job?
  • Thank you for all the information. I was hoping to get back the spin code from the eeprom. I lost all of my spin programs and wanted to pick up where I left off on a particular project without having to start over. Sounds like it might be best to start again.
  • Cluso99Cluso99 Posts: 18,069
    mikea wrote: »
    Thank you for all the information. I was hoping to get back the spin code from the eeprom. I lost all of my spin programs and wanted to pick up where I left off on a particular project without having to start over. Sounds like it might be best to start again.
    Unfortunately yes. You didn’t by chance post any code to the forum? Always a good backup!
  • mikea wrote: »
    Thank you for all the information. I was hoping to get back the spin code from the eeprom. I lost all of my spin programs and wanted to pick up where I left off on a particular project without having to start over. Sounds like it might be best to start again.

    When I have had to "start-over" on projects, I've found that the next generation was much better than the first. YMMV, it all depends on how long ago it was when you last worked on the project...
  • Cluso99Cluso99 Posts: 18,069
    FWIW I cannot stress how important a good backup regime is.
    I save and backup my code regularly. This means that when I'm working on my code I save often, particularly when I get a part working. I use filenames with -nnn where nnn is an incrementing number. Sometimes I even add and alpha to that if the changes are more incremental. This then needs to be archived off onto another medium (ie external HDD) regularly too as you never know when that corruption event (can also be a virus) may happen, and you can guarantee it will be at the most in-opportune time. This is something I've done since the early 70's so it is habit. If I introduce a bug I can go back and compare various versions to see where the change was done - Notepad++ is a great comparison tool and while I haven't used it, I believe Visual Studio Code also has a comparison tool too. I use VSC to edit my prop (P1 & P2) code nowadays.
  • kwinnkwinn Posts: 8,697
    +1 I back up weekly to a 1TB HDD with a USB interface where I keep the 3 most recent backups of my Home directory. Learned my lesson the hard way a long time ago.
  • ElectrodudeElectrodude Posts: 1,660
    edited 2020-08-08 21:09
    Distributed version control systems such as Git (don't bother with Github unless you actually need it) are also great for versioning local files. Unlike older VCSes such as SVN and CVS, Git (and others, e.g. Mercurial) doesn't need a server (despite what Github wants you to think), which makes it perfect for all kinds of projects that people don't usually think of when they think of Github: quick-and-dirty toy projects, private projects you don't want hosted by a third party, things you will publish but aren't ready to yet, etc.

    I've found git to be much more convenient and hassle-free than constantly having to remember to save-as with a new name and then having the clutter of many visible versioned files. On top of that, Git makes it easy to compare versions against each other and has semi-automated (or fully automated, if you write a helper script) tools for finding where a bug was introduced. I couldn't imagine going back to manual versioning. I really recommend everyone to try Git or Mercurial or something similar - they make life so much easier.
  • Cluso99Cluso99 Posts: 18,069
    Doing the saving yourself has no software implications. My saved files from the 70’s and 80’s etc only needed to be moved to current media. Will git and mercurial software still be available and able to read your files and change history in 40-50 years? I very much doubt it!
  • Cluso99 wrote: »
    Doing the saving yourself has no software implications. My saved files from the 70’s and 80’s etc only needed to be moved to current media. Will git and mercurial software still be available and able to read your files and change history in 40-50 years? I very much doubt it!

    Of course it will be. It's open source and widely used.
  • ElectrodudeElectrodude Posts: 1,660
    edited 2020-08-08 23:47
    Wuerfel_21 wrote: »
    Cluso99 wrote: »
    Doing the saving yourself has no software implications. My saved files from the 70’s and 80’s etc only needed to be moved to current media. Will git and mercurial software still be available and able to read your files and change history in 40-50 years? I very much doubt it!

    Of course it will be. It's open source and widely used.

    And, besides, because of how simple Git is by design, it will be possible for someone thousands of years from now without a working copy of Git to extract files from it with nothing more than a zlib decoder (which uses the same compression algorithm that zip files use) and a couple lines of shell script that I wrote once and have probably since lost but that should be pretty trivial to reproduce if needed.

    But there's probably not any realistic danger of that becoming necessary, considering that Github has store snapshots of most of the open-source software they host, surely including Git since it's what their company is built upon, in the Github Archive Program's Arctic Vault.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2020-08-09 01:05
    I'm still trying to recover a .sit file I uploaded at 1200 baud to a BBS in 1985 :smile: (They had a whopping 80MB of storage) Lucky I've still got the 400K Mac floppy though :disappointed:

    Just kidding of course although the compressed .sit files I have in a zip backup and I did find a Stuffit decompression tool. The MacDraw I used to draw the pcb and schematics can be read by LibreOffice (mostly).

    Backups are only just backups in case you need them so I use several pocket USB HDDs that rotate being left in the car or some place other than all together. But USB Flash drives are handy too and I have a couple of the small ones on my keyring with backups as well as one with a live Linux boot.

    Back to the EEPROM. If I need to backup a EEPROM I download a Tachyon binary to the RAM and from there I do a Intel hex dump of the EEPROM back to the PC.
  • @Electrodude, agree on git if you don't want to bother with github, but you will still need to create an off system if not site backup of whatever is important to you. Otherwise git will not save you from disk falure or bad enough human fail to accomplish the same result. Github can be just cheap insurance for your project.
  • Dropbox suits me fine and syncs my folders across my PCs. If I need an older copy of the file they are all there from the last few months in the hidden dropbox_cache/old_files folder. I also just copy across the latest dropbox folder to my backups and rename it with the date.
  • @Electrodude, agree on git if you don't want to bother with github, but you will still need to create an off system if not site backup of whatever is important to you. Otherwise git will not save you from disk falure or bad enough human fail to accomplish the same result. Github can be just cheap insurance for your project.

    Yes, of course. I keep remote copies of any git repositories I don't want to put on Github on my VPS. My point is that Git is good both for managing local revisions and for keeping track of archives. Git also has a pack feature that's probably good for offline backups, too.
  • You could always start with a clean EEprom, then write a simple command, save it and see how it looks on the eeprom. Would take a lot of effort.
  • DigitalBob wrote: »
    You could always start with a clean EEprom, then write a simple command, save it and see how it looks on the eeprom. Would take a lot of effort.

    In regards to that avenue just remember that BST generates a proper listing and this can also give you a better idea as to how compiled code can be mapped etc. Here's part of the listing from the old coil demo showing the Spin bytecodes.
    Addr : 008B: Repeat i Step Label0002
    Addr : 008B:       66 02 66  : Variable Operation Local Offset - 1 Assign Repeat-Var loop Address= 0074 -26
    Addr : 008E: Label0004
    102                        repeat dx from 0 to tv_hc - 1
    Addr : 008E:             35  : Constant 1 $00000000
    Addr : 008F:             69  : Variable Operation Local Offset - 2 Write
    Addr : 0090: Label0005
    103                          repeat dy from 0 to tv_vc - 1
    Addr : 0090:             35  : Constant 1 $00000000
    Addr : 0091:             6D  : Variable Operation Local Offset - 3 Write
    Addr : 0092: Label0008
    104                            screen[dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)
    Addr : 0092:       39 50 00  : Constant 2 Bytes - 50 00 - $00005000 20480
    Addr : 0095:          38 06  : Constant 1 Bytes - 06 - $00000006 6
    Addr : 0097:             E2  : Math Op >>
    Addr : 0098:             6C  : Variable Operation Local Offset - 3 Read
    Addr : 0099:             EC  : Math Op +
    Addr : 009A:             68  : Variable Operation Local Offset - 2 Read
    Addr : 009B:             5C  : Variable Operation Global Offset - 7 Read
    Addr : 009C:             F4  : Math Op *
    Addr : 009D:             EC  : Math Op +
    Addr : 009E:             6C  : Variable Operation Local Offset - 3 Read
    Addr : 009F:          37 25  : Constant Mask Y=37 Decrement 0000003F 63
    Addr : 00A1:             E8  : Math Op &
    Addr : 00A2:          38 0A  : Constant 1 Bytes - 0A - $0000000A 10
    Addr : 00A4:             E3  : Math Op <<
    Addr : 00A5:             EC  : Math Op +
    Addr : 00A6:             6C  : Variable Operation Local Offset - 3 Read
    Addr : 00A7:             58  : Variable Operation Global Offset - 6 Read
    Addr : 00A8:             F4  : Math Op *
    Addr : 00A9:             68  : Variable Operation Local Offset - 2 Read
    Addr : 00AA:             EC  : Math Op +
    Addr : 00AB:       B9 81 40  : Memory Op Word VBASE + POP Index WRITE Address = 0140
    Addr : 00AE: Label0009
    
Sign In or Register to comment.