I am migrating to HAM for my SpaceWar! project and I think it would be very nice for people distributing HAM-empowered software if there was a quick and easy way for other people to load the software we develop. I had expected that I'd be able to prepare all my assets with HAM, and then when it was all working write all the data to eeprom and then read it all back into a single large .eeprom file that I could distribute along with my release, but (and I haven't done much investigation on this yet, so if I am being foolish please feel free to throw furniture) I found that when I uploaded the entire contents of the eeprom and then tried to drag the resulting .eeeprom file back into HAM, HAM complained that the .eeprom file was larger than the available memory.
However we get there, I believe an easy to use end-user HAM-enabled-app installation solution will help get more people on the HAM band wagon. SpaceWar! is going HAM, and I'd like to make it as easy as possible for people to load and play in the future.
The quickest install solution I can imagine is 1) have an end-user run a pre-compiled .eeprom file which is the HAM communications engine 2) run the HAM windows app and click some new "load .eeprom image" button 3) select the release .eeprom image from a file browser 4) the code loads, you click reset, and you're up and running.
By the way, congratulations on a job well done! HAM works very well and is almost exactly what I would have dreamed of doing if someone hadn't done it already. I'm ever so pleased that you did!!!! How about releasing the HAM vb app source so the community can help evolve it?
Epmoyer,
Thanks for the feedback.
There is a slight bug with the adding of assets (in this case, your EEPROM) that are the exact size of memory.
Try this. Try dragging it in just above the memory window. That should cause the app to clamp it to address 0 and it should fit.
I'll try and fix that bug very soon.
I am migrating to HAM for my SpaceWar! project and I think it would be very nice for people distributing HAM-empowered software if there was a quick and easy way for other people to load the software we develop. I had expected that I'd be able to prepare all my assets with HAM, and then when it was all working write all the data to eeprom and then read it all back into a single large .eeprom file that I could distribute along with my release, but (and I haven't done much investigation on this yet, so if I am being foolish please feel free to throw furniture) I found that when I uploaded the entire contents of the eeprom and then tried to drag the resulting .eeeprom file back into HAM, HAM complained that the .eeprom file was larger than the available memory.
However we get there, I believe an easy to use end-user HAM-enabled-app installation solution will help get more people on the HAM band wagon. SpaceWar! is going HAM, and I'd like to make it as easy as possible for people to load and play in the future.
The quickest install solution I can imagine is 1) have an end-user run a pre-compiled .eeprom file which is the HAM communications engine 2) run the HAM windows app and click some new "load .eeprom image" button 3) select the release .eeprom image from a file browser 4) the code loads, you click reset, and you're up and running.
By the way, congratulations on a job well done! HAM works very well and is almost exactly what I would have dreamed of doing if someone hadn't done it already. I'm ever so pleased that you did!!!! How about releasing the HAM vb app source so the community can help evolve it?
Missed your comment on releasing the source. I'm pretty open to it, but I'd like to get it a tad bit farther and cleaned up before I did anything like that. Also, it's not VB, it's C#.
In the meantime, I'll try and fix bugs as I'm made aware of them here or in my inbox (richbenson at gmail dot com)
Yes, Congrats on HAM Keebler, I can't believe you've had no feedback, it's a great App, and now that I know not to use download from eeprom, as it expects 128KB, not the 64KB I have on my protoboard, it's a lot friendlier [noparse]:)[/noparse] and working 100%
so the problems I had with it weren't problems with HAM, just the nut holding the keyboard [noparse]:)[/noparse]
PS, any chance of source release for the PC side? or just a quick eeprom max size mod?
Yeah NP, didn't see that reply, when I started my reply, but got phone call in the middle of typing it [noparse]:)[/noparse]
Any time your ready.
it's really good though so far, I've not had trouble with it, and it's nice being able to slide it up and down etc. or enter the exact addy for it.
like i said, the only things I'd probably add to it, is <128KB for download
and export .spin con file for file starts and lengths.
Baggers said...
Yeah NP, didn't see that reply, when I started my reply, but got phone call in the middle of typing it [noparse]:)[/noparse]
Any time your ready.
it's really good though so far, I've not had trouble with it, and it's nice being able to slide it up and down etc. or enter the exact addy for it.
like i said, the only things I'd probably add to it, is <128KB for download
and export .spin con file for file starts and lengths.
Cheers
Baggers.
Yeah, the export with addresses/offsets was something I had thought of a long time ago, but had forgotten as of late.
Thanks for the reminder!
epmoyer said...
The quickest install solution I can imagine is 1) have an end-user run a pre-compiled .eeprom file which is the HAM communications engine 2) run the HAM windows app and click some new "load .eeprom image" button 3) select the release .eeprom image from a file browser 4) the code loads, you click reset, and you're up and running.
Or one step further. How about this:
Winzip has an install feature. If you have a setup.exe or install.exe file in a zip file, then when you open the zip file, you can click on Install and winzip will extract to a temporary directory and run setup.exe or install.exe.
So how about creating a zip file with 3 files in it.
The Install.exe is a special build of HAM which has minimal interface, and automatically loads benson_ham_driver_1_06.eeprom into Hydra RAM as the spin tool would. It then uses that to upload the file named in install.ini. In this case case, install.ini would contain the name Spacewar.eeprom.
If you have the registered version of Winzip you could go even further and create a self-extracting zip file that will run the install program automatically. So that would be one double click from the desktop to install the 128K EEPROM file on the Hydra. You can't get much easier for the end-user than that.
epmoyer said...
The quickest install solution I can imagine is 1) have an end-user run a pre-compiled .eeprom file which is the HAM communications engine 2) run the HAM windows app and click some new "load .eeprom image" button 3) select the release .eeprom image from a file browser 4) the code loads, you click reset, and you're up and running.
Or one step further. How about this:
Winzip has an install feature. If you have a setup.exe or install.exe file in a zip file, then when you open the zip file, you can click on Install and winzip will extract to a temporary directory and run setup.exe or install.exe.
So how about creating a zip file with 3 files in it.
The Install.exe is a special build of HAM which has minimal interface, and automatically loads benson_ham_driver_1_06.eeprom into Hydra RAM as the spin tool would. It then uses that to upload the file named in install.ini. In this case case, install.ini would contain the name Spacewar.eeprom.
If you have the registered version of Winzip you could go even further and create a self-extracting zip file that will run the install program automatically. So that would be one double click from the desktop to install the 128K EEPROM file on the Hydra. You can't get much easier for the end-user than that.
Well, if nothing else, I do agree that there should be a one button solution in HAM to upload and launch the HAM driver. That wouldn't be too bad.
Ok, I ZIPped it along with a simple Windows Forms test app.
The booter is a single .NET 2.0 class, in a class library. It's REALLY simple:
Booter b = new Booter("COM3");
b.Boot("a.eeprom");
or
Booter b = new Booter("COM3");
b.Reprogram("a.eeprom");
... It also works with .binary files.
The only problem you may face is opening the project, it's made with Visual Studio Express Edition Orcas Beta (...), but since the app itself is a single class, you can just take the source file.
I agree, loading the HAM driver automatically would be a nice addition. A one click install path is probably unnecessary overkill. In general all Hydra users are developers, so they can handle a little mucking about. I just think that if the instructions for installing a HAM-enabled propeller app can be short and sweet then more people will use HAM, which will be better for everyone. My step-by-step HAM instructions for the last HDMF demo release were 7 steps long, which is a tad foreboding.
Again, all this stuff is nit picking and I'm just looking to make a great thing better. Thanks for your work; I'm very glad to have HAM at all!
I agree, loading the HAM driver automatically would be a nice addition. A one click install path is probably unnecessary overkill. In general all Hydra users are developers, so they can handle a little mucking about. I just think that if the instructions for installing a HAM-enabled propeller app can be short and sweet then more people will use HAM, which will be better for everyone. My step-by-step HAM instructions for the last HDMF demo release were 7 steps long, which is a tad foreboding.
Again, all this stuff is nit picking and I'm just looking to make a great thing better. Thanks for your work; I'm very glad to have HAM at all!
Thank you for all the feedback. Now that I know people are actually using it, I'll dust it off, fix some of the bugs and start to clean up the code.
I am a few days away from releasing HDMF, and the HDMF EEPROM Playback demo will require HAM to install. Any chance of getting the .eeprom drag position / available size / 0 clamping fix in real soon so that the HAM installation instructions can be simpler?
Jasper_M said...
Ok, I ZIPped it along with a simple Windows Forms test app.
The booter is a single .NET 2.0 class, in a class library. It's REALLY simple:
Booter b = new Booter("COM3");
b.Boot("a.eeprom");
or
Booter b = new Booter("COM3");
b.Reprogram("a.eeprom");
... It also works with .binary files.
The only problem you may face is opening the project, it's made with Visual Studio Express Edition Orcas Beta (...), but since the app itself is a single class, you can just take the source file.
Cheers for that Jasper, I'm sure It'll come in handy [noparse]:)[/noparse]
Thanks
I am a few days away from releasing HDMF, and the HDMF EEPROM Playback demo will require HAM to install. Any chance of getting the .eeprom drag position / available size / 0 clamping fix in real soon so that the HAM installation instructions can be simpler?
Thanks.
I'll do my best to get it done this weekend.··· Work has been pretty intense and I have a real estate deal going that's taking a lot of time/energy [noparse]:)[/noparse]
Jasper_M said...
Ok, I ZIPped it along with a simple Windows Forms test app.
The booter is a single .NET 2.0 class, in a class library. It's REALLY simple:
Booter b = new Booter("COM3");
b.Boot("a.eeprom");
or
Booter b = new Booter("COM3");
b.Reprogram("a.eeprom");
... It also works with .binary files.
The only problem you may face is opening the project, it's made with Visual Studio Express Edition Orcas Beta (...), but since the app itself is a single class, you can just take the source file.
Wow Jasper, Thanks!
HAM can now launch the HAM driver directly (don't have to use propellor tool) thanks to your Booter class.· (Look for it in HAM 1.07)
At the risk of over designing this, I've given it a lot of thought and what I think would be more useful than exporting spin constants is creating an asset directory within the EEPROM itself. I would create a convention where each asset begins with a 32bit asset tag. People who generate assets would have to generate the tag on their end and place it first in their assets. Then HAM would create a list (either at the start of the 96K region (i.e just above the lower 32K), or at the end working backwards) of assets which basically looks like:
Then an application could just read the directory and find out both that A) The assets its looking for are actually there and Where they are.
It would make moving assets around easier to maintain than a spin copy/paste solution because you wouldn't have to touch your code at all. Once we write a little asset directory reader object everyone can just use that easily to read the directory, so integration with HAM is easy. Maybe HAM or some other utility could be written to allow users to append an asset tag to an existing file if people have legacy assets that they need to add tags to.
Personally I'd also create the convention that asset tags are 4 byte strings and restrict the values to alphanumeric ASCII; that way you can "print out" an asset directory and have somewhat sensical names for your assets like "GFX1" "SND1" "SFX1" "SNG5" "JAZZ" etc.
Hi Rich,
epmoyer's idea is a good one, but... not all users have >64KB ( eg protoboard has only 64KB total, and demoboard only has 32KB )
so it's probably best to have it still export to a spin file, but can be included into a project.
eg.
it exports a file ( named by user ) eg eeprominf.spin
and it's set out like this
CON
Files long 0x41424344 ' first 4 letters of first filename
long 0x45464748 ' second 4 letters of first filename that way if people use 8.3 filename format, it can be the filename, and save us having to make up TAG's
long start_addr1
long end_addr1
long 0x494a4b4c ' first 4 letters of second filename etc...
long 0x4d4e4f50
long start_addr2
long end_addr2
I'm starting work on the adjustable EEPROM size now.
I have it working but i need to do some more testing before uploading 1.07.
This will also include the ability to load the HAM driver from H.A.M. with the propellor tool as well as the fix for adding assets that are as big as the eeprom.
4 bytes is a bit too limiting, 12 is perfect, this way we can use 8.3 filenames at least for the tags, let's do that, and YES always ASCIIZ is the best way to go, ALWAYS make it human readable and editable.
I have it working but i need to do some more testing before uploading 1.07.
This will also include the ability to load the HAM driver from H.A.M. with the propellor tool as well as the fix for adding assets that are as big as the eeprom.
Look for it late tomorrow evening.
Let's make it Friday or Saturday [noparse]:)[/noparse]
If an asset will take up all of EEPROM, it will be automatically placed at address 0, regardless of where you drag to in the memory window.
HexEdit window now displays the starting address of each line instead of the ending address (i.e. first line would show 00000010 instead of 00000000). It's not my hex edit control, but I was able to recompile it with this change.
Improvements:
"Load HAM Driver" will load the driver onto the Hydra automatically.
(Thanks to Jasper for the Booter class)
H.A.M. reboots the Hydra after a successful upload
I set it to correct COMport, set memory size to 64KB then dragged CP_HIADEMO.eeprom into it, then clicked upload to hydra.
Edit: S'ok, sorted that problem now, not only had I forgot to load HAM driver,·I forgot to change it to 5Mhz for my protoboard.
but it sorted that, tv displays correctly, and clock is fine, I can·down load stuff to it, but it doesn't seem to run correctly [noparse]:([/noparse]
I tried some other apps, I tried ManicMiner DodgyKong and two other binaries, but like i said, i just get a black screen. [noparse]:([/noparse]
Also, IIRC those drivers from the book/cd, so·you might have to not release those, as they are part of·Andre's CD.
I set it to correct COMport, set memory size to 64KB then dragged CP_HIADEMO.eeprom into it, then clicked upload to hydra.
Edit: S'ok, sorted that problem now, not only had I forgot to load HAM driver,·I forgot to change it to 5Mhz for my protoboard.
but it sorted that, tv displays correctly, and clock is fine, I can·down load stuff to it, but it doesn't seem to run correctly [noparse]:([/noparse]
I tried some other apps, I tried ManicMiner DodgyKong and two other binaries, but like i said, i just get a black screen. [noparse]:([/noparse]
Also, IIRC those drivers from the book/cd, so·you might have to not release those, as they are part of·Andre's CD.
Hmm..··· The asset is set at address 0, right?
Does it·say·programming·complete?
What happens if you reset it manually, does it still reboot to black?
What EEPROM chip is on the protoboard (specific chip)?
Did the H.A.M. driver show any errors or did seem to go through successfully as well?
Did·you try the "Download From Hydra" feature to see if you could grab the EEPROM contents for investigation?
Another trick you could try is this.·· Rename one of the apps (.eeprom)· you want to upload to benson_ham_driver_1_07.eeprom in the directory where H.A.M. is and use the "Load H.A.M. Driver" option and see if that works.
I might need to get a protoboard to figure this out.·· I don't know what differences there are.· Can·anyone tell me the major differences between the Hydra and the Protoboard?
Yes, Address is set to 0
it does say programming complete.
then goes black
if i reboot, it stays black.
the eeprom has U3 A on top row, then AT512 on the bottom row of text
I'm guessing the differences would be the page size for the eeprom.
I've re-downloaded the bottom half using proptool ( lower 32KB so the program runs ) BUT the graphics are corrupted, it's like the pages are 128 bytes, by the looks of the way the data is layed out, I'm guessing you're using 256byte pages?
if I'm right, this will be the problem. [noparse]:)[/noparse]
Jasper_M said...
Ok, I ZIPped it along with a simple Windows Forms test app.
The booter is a single .NET 2.0 class, in a class library. It's REALLY simple:
Booter b = new Booter("COM3");
b.Boot("a.eeprom");
or
Booter b = new Booter("COM3");
b.Reprogram("a.eeprom");
... It also works with .binary files.
The only problem you may face is opening the project, it's made with Visual Studio Express Edition Orcas Beta (...), but since the app itself is a single class, you can just take the source file.
Jasper, how did you find out the Propellor protocol?
The code is based on (ie. it's a port of) a pascal source file released by Chip. It should be mentioned in the XML comment for the Booter class, along with a forum link.
edit: I·forgot to put the link i the source,·it was only in a·version that I didn't release. This is·the link:·http://forums.parallax.com/showthread.php?p=611536·So the booter class is mostly a port of the serialunit.pas file.
Comments
Please let me know if you run into problems like that. I can't help if I don't know anything is wrong [noparse]:)[/noparse]
I've received virtually no feedback on HAM, so I just assumed noone was using it or it's working perfectly...
Rich
Epmoyer,
Thanks for the feedback.
There is a slight bug with the adding of assets (in this case, your EEPROM) that are the exact size of memory.
Try this. Try dragging it in just above the memory window. That should cause the app to clamp it to address 0 and it should fit.
I'll try and fix that bug very soon.
Rich
Missed your comment on releasing the source. I'm pretty open to it, but I'd like to get it a tad bit farther and cleaned up before I did anything like that. Also, it's not VB, it's C#.
In the meantime, I'll try and fix bugs as I'm made aware of them here or in my inbox (richbenson at gmail dot com)
Rich
so the problems I had with it weren't problems with HAM, just the nut holding the keyboard [noparse]:)[/noparse]
PS, any chance of source release for the PC side? or just a quick eeprom max size mod?
Baggers.
Both of those questions are answered up above [noparse]:)[/noparse]
Rich
Any time your ready.
it's really good though so far, I've not had trouble with it, and it's nice being able to slide it up and down etc. or enter the exact addy for it.
like i said, the only things I'd probably add to it, is <128KB for download
and export .spin con file for file starts and lengths.
Cheers
Baggers.
Yeah, the export with addresses/offsets was something I had thought of a long time ago, but had forgotten as of late.
Thanks for the reminder!
Rich
Or one step further. How about this:
Winzip has an install feature. If you have a setup.exe or install.exe file in a zip file, then when you open the zip file, you can click on Install and winzip will extract to a temporary directory and run setup.exe or install.exe.
So how about creating a zip file with 3 files in it.
1) Install.exe
2) Install.ini
2) benson_ham_driver_1_06.eeprom
3) Spacewar.eeprom
The Install.exe is a special build of HAM which has minimal interface, and automatically loads benson_ham_driver_1_06.eeprom into Hydra RAM as the spin tool would. It then uses that to upload the file named in install.ini. In this case case, install.ini would contain the name Spacewar.eeprom.
If you have the registered version of Winzip you could go even further and create a self-extracting zip file that will run the install program automatically. So that would be one double click from the desktop to install the 128K EEPROM file on the Hydra. You can't get much easier for the end-user than that.
Well, if nothing else, I do agree that there should be a one button solution in HAM to upload and launch the HAM driver. That wouldn't be too bad.
That'd be handy.
The booter is a single .NET 2.0 class, in a class library. It's REALLY simple:
Booter b = new Booter("COM3");
b.Boot("a.eeprom");
or
Booter b = new Booter("COM3");
b.Reprogram("a.eeprom");
... It also works with .binary files.
The only problem you may face is opening the project, it's made with Visual Studio Express Edition Orcas Beta (...), but since the app itself is a single class, you can just take the source file.
I agree, loading the HAM driver automatically would be a nice addition. A one click install path is probably unnecessary overkill. In general all Hydra users are developers, so they can handle a little mucking about. I just think that if the instructions for installing a HAM-enabled propeller app can be short and sweet then more people will use HAM, which will be better for everyone. My step-by-step HAM instructions for the last HDMF demo release were 7 steps long, which is a tad foreboding.
Again, all this stuff is nit picking and I'm just looking to make a great thing better. Thanks for your work; I'm very glad to have HAM at all!
Thank you for all the feedback. Now that I know people are actually using it, I'll dust it off, fix some of the bugs and start to clean up the code.
Keep the feedback/comments/suggestions coming.
Rich
I am a few days away from releasing HDMF, and the HDMF EEPROM Playback demo will require HAM to install. Any chance of getting the .eeprom drag position / available size / 0 clamping fix in real soon so that the HAM installation instructions can be simpler?
Thanks.
Thanks
Baggers.
Rich
No worries at all.
Thanks.
HAM can now launch the HAM driver directly (don't have to use propellor tool) thanks to your Booter class.· (Look for it in HAM 1.07)
Rich
At the risk of over designing this, I've given it a lot of thought and what I think would be more useful than exporting spin constants is creating an asset directory within the EEPROM itself. I would create a convention where each asset begins with a 32bit asset tag. People who generate assets would have to generate the tag on their end and place it first in their assets. Then HAM would create a list (either at the start of the 96K region (i.e just above the lower 32K), or at the end working backwards) of assets which basically looks like:
Then an application could just read the directory and find out both that A) The assets its looking for are actually there and
It would make moving assets around easier to maintain than a spin copy/paste solution because you wouldn't have to touch your code at all. Once we write a little asset directory reader object everyone can just use that easily to read the directory, so integration with HAM is easy. Maybe HAM or some other utility could be written to allow users to append an asset tag to an existing file if people have legacy assets that they need to add tags to.
Personally I'd also create the convention that asset tags are 4 byte strings and restrict the values to alphanumeric ASCII; that way you can "print out" an asset directory and have somewhat sensical names for your assets like "GFX1" "SND1" "SFX1" "SNG5" "JAZZ" etc.
epmoyer's idea is a good one, but... not all users have >64KB ( eg protoboard has only 64KB total, and demoboard only has 32KB )
so it's probably best to have it still export to a spin file, but can be included into a project.
eg.
it exports a file ( named by user ) eg eeprominf.spin
and it's set out like this
CON
Files long 0x41424344 ' first 4 letters of first filename
long 0x45464748 ' second 4 letters of first filename that way if people use 8.3 filename format, it can be the filename, and save us having to make up TAG's
long start_addr1
long end_addr1
long 0x494a4b4c ' first 4 letters of second filename etc...
long 0x4d4e4f50
long start_addr2
long end_addr2
Baggers.
I have it working but i need to do some more testing before uploading 1.07.
This will also include the ability to load the HAM driver from H.A.M. with the propellor tool as well as the fix for adding assets that are as big as the eeprom.
Look for it late tomorrow evening.
Rich
Andre'
Let's make it Friday or Saturday [noparse]:)[/noparse]
Rich
Bug Fixes:
If an asset will take up all of EEPROM, it will be automatically placed at address 0, regardless of where you drag to in the memory window.
HexEdit window now displays the starting address of each line instead of the ending address (i.e. first line would show 00000010 instead of 00000000). It's not my hex edit control, but I was able to recompile it with this change.
Improvements:
"Load HAM Driver" will load the driver onto the Hydra automatically.
(Thanks to Jasper for the Booter class)
H.A.M. reboots the Hydra after a successful upload
Selectable EEPROM size (new combo box at bottom)
Please keep the feedback coming.
Rich
Post Edited (Keebler) : 5/19/2008 11:44:54 PM GMT
SEND: File Header timed out [noparse]:([/noparse]
I set it to correct COMport, set memory size to 64KB then dragged CP_HIADEMO.eeprom into it, then clicked upload to hydra.
Edit: S'ok, sorted that problem now, not only had I forgot to load HAM driver,·I forgot to change it to 5Mhz for my protoboard.
but it sorted that, tv displays correctly, and clock is fine, I can·down load stuff to it, but it doesn't seem to run correctly [noparse]:([/noparse]
I tried some other apps, I tried ManicMiner DodgyKong and two other binaries, but like i said, i just get a black screen. [noparse]:([/noparse]
Also, IIRC those drivers from the book/cd, so·you might have to not release those, as they are part of·Andre's CD.
Post Edited (Baggers) : 6/3/2007 11:19:34 AM GMT
Does it·say·programming·complete?
What happens if you reset it manually, does it still reboot to black?
What EEPROM chip is on the protoboard (specific chip)?
Did the H.A.M. driver show any errors or did seem to go through successfully as well?
Did·you try the "Download From Hydra" feature to see if you could grab the EEPROM contents for investigation?
Another trick you could try is this.·· Rename one of the apps (.eeprom)· you want to upload to benson_ham_driver_1_07.eeprom in the directory where H.A.M. is and use the "Load H.A.M. Driver" option and see if that works.
I might need to get a protoboard to figure this out.·· I don't know what differences there are.· Can·anyone tell me the major differences between the Hydra and the Protoboard?
Rich
Post Edited (Keebler) : 6/4/2007 4:28:04 PM GMT
it does say programming complete.
then goes black
if i reboot, it stays black.
the eeprom has U3 A on top row, then AT512 on the bottom row of text
I'm guessing the differences would be the page size for the eeprom.
I've re-downloaded the bottom half using proptool ( lower 32KB so the program runs ) BUT the graphics are corrupted, it's like the pages are 128 bytes, by the looks of the way the data is layed out, I'm guessing you're using 256byte pages?
if I'm right, this will be the problem. [noparse]:)[/noparse]
Hope this helps,
Cheers,
Baggers.
Edit:
Hi Keebler,
I've fixed the problem, it was to do with the pagesize when writing to eeprom.
I've attached links to the source file and eeprom file, for the now working benson_ham_driver_1_07.
http://www.jimbagley.co.uk/benson_ham_driver_1_07.eeprom
http://www.jimbagley.co.uk/benson_ham_driver_1_07.spin
Post Edited (Baggers) : 6/4/2007 9:45:57 AM GMT
Jasper, how did you find out the Propellor protocol?
edit: I·forgot to put the link i the source,·it was only in a·version that I didn't release. This is·the link:·http://forums.parallax.com/showthread.php?p=611536·So the booter class is mostly a port of the serialunit.pas file.
Post Edited (Jasper_M) : 6/5/2007 10:03:08 AM GMT