The VGA routines in the OS are windowed. Even though you're not using the windowing, it takes extra time to do the processing on a character by character basis. None of the other text routines (except tv_wtext which this is based on) do windowing. That's why you didn't run into this before.
Mike, everything is working great.· I'm getting the time and the RFID door method works perfectly.· Thanks a million - now I'll play around with it and maybe add some new commends to the menu.
What would be the chances of you creating a resolution of perhaps
320 x something.· The present font is a little hard to scan from a distance, and in the shop I mat be 36 inches from the screen if I'm watching the mill.
Sid,
There's already a low resolution VGA text routine that gives a 32 x 15 display. It shouldn't be hard to change the TV display routines to use the low res VGA driver. It's actually part of my plan to develop a common set of display routines that are mostly compatible. The biggest problem now is cursors and color. The hires VGA driver has a nice cursor capability that the TV and lowres VGA driver don't have. Also, the color capabilities are just incompatible among the drivers. I'll add it to my list of projects.
Mike
Mike: I assumed you knew, otherwise I would have mentioned something sooner - you have to send magic codes back to the keyboard to get the lights to come on. Otherwise the lights are completely independent of the buttons (for instance, hitting CAPS LOCK has nothing to do, from the keyboard's point of view, with the CAPS LOCK light coming on; you have to tell the keyboard to turn it on). A pain, but look on the bright side - you could also make the lights flash quickly in sequence like marquee lights.
I don't remember the exact protocol anymore but if I run back across it or get some code working I'll give it to you. Right now though the lights on the keyboard thing doesn't bother me too much - I'm mostly interested in getting my Propeller talking to my hard drive and my 68000, and it will be easier for me not to get sidetracked if I worry about small things later.
I'm almost to the point where I can start wiring in the IDE hard drive for my suitcase computer. I'd like to make it so that you can use the hard drive to "emulate" an EEPROM for the purposes of storing files on, so that it could work with your copy and load commands. Any suggestions?
Dennis,
I took a quick look at the assembly driver for the keyboard and it seemed to be sending the magic codes to the keyboard, but I didn't look to see why and when it did so.
The copy and load commands use name lookup routines in OS_fileSystem.spin and I/O routines in OS_loader.spin. The I/O routines take a 23 bit address and read/write/boot from that starting address given a byte count. Look at the comments at the beginning of OS_loaderInit. The name lookup routines take a 12 byte blank filled name and either look it up returning the address of the 32K page where it's located or look up an unused 32K page. There are other routines to rename a 32K page or mark it as deleted.
To "emulate" an EEPROM, you will need an assembly routine in a cog to do the actual I/O that works like the existing OS_loaderInit I2C routines and has a little extra code to start up a new SPIN interpreter. Chip posted this a while back. The I/O driver needs to be self contained because you may have to overwrite all available RAM when you boot a new SPIN program. You'll need to modify the existing OS_fileSystem routines to call the hard drive cog for addresses over 23 bits. The routines in OS_fileSystem that keep track of which EEPROMs are present would show that the additional space is always present. You'll get a space of 8MB on your hard drive with 256 "files" available, plenty for this kind of use.
Oh nice. I like your design, Mike. One of the features I wanted to put in my Propeller computer is the ability for it to completely (but temporarily!) replace the monitor program on the Propeller with different code, for instance to load a game that takes up the whole Propeller. I could reserve a separate 8MB partition on the hard drive for this, and then my Unix file system and my Propeller file system could coexist on the same disk. Then I could just tell the Propeller to load program #N and it could go to its partition and load it. I could keep games and demos for the Propeller stored on my hard drive, and these programs wouldn't necessarily have to know they weren't running on a demo board.
After the loader cog finishes, I suppose the program that is loaded on it could just shut itself down to free up that cog?
At first, I thought I'd have to leave the loader cog running because I'd need a "kill" button to restore the original program from EEPROM, but then I realized that's exactly what the reset button does! I could just modify the startup code so that if the Propeller gets reset, it checks to see if there is a program running and merely suspended on the 68K side of my board, and if it does it could resume the suspended program instead of rebooting the 68K. This would also be handy for development because if my Propeller program crashes, I can just reset the chip and the rebooting Propeller could send a message to my OS on the 68K to let it know a hardware glitch had occurred and it could then redraw the desktop or restart any disk I/O it was trying to do.
Mike, I just had a cool idea for a useful utility for your OS.
Why not write a tool that can work with the Propeller's RXD and TXD pins used for PC programming to load EEPROMs with binary files from the PC?
It would act as an useful EEPROM programmer that could be used to write EEPROM's larger then 32k, which is where the Propeller Tool drops off at.
Just an idea though, I know it's much harder to do then say.
Also I think different EEPROMs use different ways of accessing different areas of the memory. 64k paging, etc. This would have to be coded into the utility as well.
(hmmm).... That makes me wonder.
Well it's just an idea. ^^
--Andrew Arsenault
Dennis,
1) In the OS, the loader is part of the I2C I/O cog, but it is written so it can be run separately. In that case, it can be called from SPIN. The SPIN start routine can start the loader in its own cog, replacing the SPIN interpreter. When the loader is finished, it will then restart SPIN in the same cog to interpret the loaded program.
2) If you add some extra EEPROM, you can store some restart information in it. The 68K could serve that function as well with the Propeller sending a command to the 68K requesting the saved information which could be backed up on the disk. You'd only need a few bytes to keep enough status information to resume where you'd left off on the Propeller.
Andrew,
The problem with using the Propeller's RXD and TXD pins is that the DTR pin comes with it and will restart the Propeller. I'm trying to debug a routine to load directly from another set of pins from the Propeller Tool to the extra EEPROM via a USB2SER or Prop Plug.
The routines in the OS already know about EEPROMs of different sizes.
Andrew,
The problem with using the Propeller's RXD and TXD pins is that the DTR pin comes with it and will restart the Propeller. I'm trying to debug a routine to load directly from another set of pins from the Propeller Tool to the extra EEPROM via a USB2SER or Prop Plug.
The routines in the OS already know about EEPROMs of different sizes.
Looks like you've already thought about this then. ^^
Keep up the great work. Your OS is starting to become a staple in this scene with many people taking interest in it everyday.
Mike, now that I have been using the OS VGA sytem for a few days, I would like to convert my mill program, which is presently using vga.text, to the OS system.· Here is how I propose to go about it.· Please tell me if I have something wrong.
I would delete everything in the present OS VGA after this little routine:
·if not key.present ··· text.str(string("--> keyboard not present, can't continue")) ··· long[noparse][[/noparse]ldr#initMarker] := 0 ··· abort false · start
Then I would append my entire mill program.· I would not need to copy any objects since the only two objects the mill program uses are keyboard and vga.text.· I would have to delete the startup commands for the keyboard and the vga since they are contained in the OS system.· I would have to copy over the necessary VARS and CONS that the mill program uses.
Sid,
That makes sense to me. I assume you'd name your main routine "start" so the OS initialization routine will call it when it's done.
Yes, you don't need the simulation object. I just put it in to provide a virtual Stamp and RFID for testing purposes for your other program. You won't need the "OS_fileSystem" object or the "OS_editWindow" object either since you'll be deleting the OS command interpreter and these are not used elsewhere.
I am in the process of simplifying this kind of thing by putting the initialization routine in its own object so you just have to call it as the first thing in your program and your program is the "main program". I'm also setting things up so the TV display driver and lores VGA driver are interchangable. They'll be two versions of "OS_dspText.spin" and "OS_dspTextInit.spin" and you'll just pick the one you want (and copy the files to your own program directory). When I can make the hires VGA driver and the other two more compatible, there'll be 3 versions of interchangable drivers to choose from.
Mike
Post Edited (Mike Green) : 9/21/2006 10:39:50 PM GMT
Mike, small problem.· I have thse two methods in my mill program:
PRI changeXpos(delta) · xpos += delta · WriteLong (@xpos,xpos)
PRI changeYpos(delta) · ypos += delta · WriteLong(@ypos,ypos)
When I tried to compile the OS version, I got an error - "Expected instruction or variable" and it highlighted "WriteLong".· Can you help?· Can't delete - this is a very important method that continually updates my X and Y position.
Mike, I have attached my mill program Pulsout__AA_AutopickVGA archive.· The two methods are at Lines 428 and 432, and are called at Lines 229, 231, 233 and 235.· The program uses the object vga_text, which in turn uses the object vga.
Sid,
1) You attached what seems to be the original milling program so I can't tell if something happened in editing it for the OS. I need the one that gets the error.
2) You've got a huge drilling table, at least 1600 longs (6.4K) not to mention a large program. I'm concerned that you're tight on memory. That wouldn't explain the error, but it may be a problem as you get further along. You can cut this table in half just by using words instead of longs. You can also pack the two items into one word as I show below. I also note that you have two longs per entry, but increment the pointer only once. You get away with this since you probably don't have any distances in the table that are exactly the same number as the command letters (next time through the loop, you interpret the distance as a command letter).
3) I can't see why you get the error. It doesn't make sense unless there is some punctuation error that's in the version you got the error in. I need to be able to reproduce the error here.
CON
#0, DirLeft, DirRight, DirIn, DirOut, DirQuit, DirPause, DirDrill
' lots of stuff
coord := word[noparse][[/noparse]board][noparse][[/noparse]pntr++]
dir := coord >> 13
coord &= $1FFF
if dir == DirLeft
' existing stuff
elseif dir == DirRight
elseif dir == DirIn
elseif dir == DirOut
elseif dir == DirQuit
elseif dir == DirPause
elseif dir == DirDrill
DAT
travl word DirLeft << 13 + 2075
word DirIn << 13 + 1300
word DirRight << 13 + 0
word DirOut << 13 + 0
word DirIn << 13 + 525
' and so on
Mike, thanks for the suggestion - I'll have to study that a bit.· Right now there are 2475 longs free - the DAT lists are no problem.· I have a special folder where I store DAT files I am not using, and I could easily copy the existing DAT files to that folder, keeping only the one that I want to run.
I give up on my current attempt to OS my mill program.· The program compiles and loads just fine, but there is no display.· If I temporarily delete the appended program, the the display shows:
Running Mill OS· 9/22/06
If I go back to the program-appended version I get no display.· I am attaching the current version of Mill OS - maybe you can spot something.· I hope.
I'll see if I can incorporate your suggestions as soon as the current problem gets solved.
You've probably run out of space. The OS uses some of that free space for the VGA display buffer and font tables (probably about 2400 longs). The OS_loader object has its own I2C routines. I'll change your WriteByte routine to use the OS_loader version so you don't need the i2cObject object and change the DAT information to use words instead of longs. That should free up quite a bit of memory.
Here's the modified version. I can't test it, but it does compile fine. I made the changes I suggested to the tables and the part of the automill that gets the directive and coordinate. I also changed ReadByte and WriteByte to use the routines in OS_loader. It's clearly a lot smaller now.
Had a couple of minor problems.· The first time I ran it, I went to Autorun - F - and the display was messed up.· It kept going back to the top of the display and overwriting what was there.· So......I took a good look at the Autorun routines, then I deleted all the screen color changes that were a holdover frim vga.text - OS was interpreting these as something else.· Once I got all those cleared up, the program ran perfectly.
Now then, this generates a secondary problem.· When I start the DAT list for a new board, I enter the coordinate I go to, and the direction X or Y.· Like this:
1000· X
800· Y
0· X
0· Y
I then copy and paste this data into an Excel templete which yields the following:
This is now in a format my Stamp can work with.· I copy the Excel data into the DATA section of a special Stamp program which converts the Excel data to this:
If I can't modify my Stamp program, then I guess I will have to manually edit each line of the LONG DAT list.· Believe me, I don't look forward to that!
Sid,
It should be trivial to modify your Stamp program. It's a simple substitution. Instead of "L", use DirLeft<<13. Instead of "I", use DirIn<<13. Instead of "R", use DirRight<<13. Instead of "O", use DirOut<<13. Use + instead of the comma and WORD instead of LONG and there you have it. If you have problems, post the Stamp program and I'll have a look at it.
Unfortunately, I have nearly zero experience with Excel Macros. It should be straightforward for Excel to do the work for you and produce a text file that you can cut and paste into your Propeller program. Maybe someone else here can help you with that.
Mike
Mike, I finally got my Stamp program to output data in yoiur new DAT format.· You can't just substitute dirLeft<<13 for "L" - the Stamp won't accept that.· What I did was this:
IF dir = "I" THEN
DEBUG· "WORD··· ",· "DirIn<<13 +", " ",SDEC f, cr
ENDIF
IF dir = "R" THEN
DEBUG· "WORD··· ",· "DirRight<<13 +", " ",SDEC f, cr
ENDIF
and so on for "L", "O", "D", "P" and "Q".
Wrote a little test program that went left,in,right,out,pause, drill and quit.· Went through my little procedure and pasted the results into the program as trav8.· Modified my Autorun program to call trav8, and the screen went through all the moves perfectly, so I guess it is OK.· Won't be really confident until I can write a little program to etch a real board, but for right now it looks like we're home free.· What a tremendous amount of data the HiRes screen displays!!
Didn't try out loading to EEPROM and seeing if the program would remember where it was when I shut down.· Doesn't really matter because I can't get that feature to work on the Demo board anyway, which is what I using on the mill.· If I have to sut down in the middle of something, I just jot down the X and Y posits, then restore them when I boot up and go thru the Reset method.
by eliminating the extra 'quote comma quote' bits.
Do check the initial menu display to see if xpos and ypos are saved correctly. It should work on the Demo Board with the routines in OS_loader. You can take out the calls to ReadLong as follows: (they're not needed since the Propeller reads the values from EEPROM when the program is loaded into RAM)
Mike, I disabled the two ReadLong statements, loaded·the program into EEPROM instead of RAM.· Executed a couple of manual moves and the screen said X = 100··· Y = 100.
Turn the Prop off, then back on.· Both X and Y read 0 so the program is not saving the last posits.
Comments
Sid
The VGA routines in the OS are windowed. Even though you're not using the windowing, it takes extra time to do the processing on a character by character basis. None of the other text routines (except tv_wtext which this is based on) do windowing. That's why you didn't run into this before.
Mike
What would be the chances of you creating a resolution of perhaps
320 x something.· The present font is a little hard to scan from a distance, and in the shop I mat be 36 inches from the screen if I'm watching the mill.
Your modules got mailed today.
Sid
There's already a low resolution VGA text routine that gives a 32 x 15 display. It shouldn't be hard to change the TV display routines to use the low res VGA driver. It's actually part of my plan to develop a common set of display routines that are mostly compatible. The biggest problem now is cursors and color. The hires VGA driver has a nice cursor capability that the TV and lowres VGA driver don't have. Also, the color capabilities are just incompatible among the drivers. I'll add it to my list of projects.
Mike
I've been watching your progress waiting for a text version. Thank you, good work!
-Parsko
I don't remember the exact protocol anymore but if I run back across it or get some code working I'll give it to you. Right now though the lights on the keyboard thing doesn't bother me too much - I'm mostly interested in getting my Propeller talking to my hard drive and my 68000, and it will be easier for me not to get sidetracked if I worry about small things later.
I'm almost to the point where I can start wiring in the IDE hard drive for my suitcase computer. I'd like to make it so that you can use the hard drive to "emulate" an EEPROM for the purposes of storing files on, so that it could work with your copy and load commands. Any suggestions?
I took a quick look at the assembly driver for the keyboard and it seemed to be sending the magic codes to the keyboard, but I didn't look to see why and when it did so.
The copy and load commands use name lookup routines in OS_fileSystem.spin and I/O routines in OS_loader.spin. The I/O routines take a 23 bit address and read/write/boot from that starting address given a byte count. Look at the comments at the beginning of OS_loaderInit. The name lookup routines take a 12 byte blank filled name and either look it up returning the address of the 32K page where it's located or look up an unused 32K page. There are other routines to rename a 32K page or mark it as deleted.
To "emulate" an EEPROM, you will need an assembly routine in a cog to do the actual I/O that works like the existing OS_loaderInit I2C routines and has a little extra code to start up a new SPIN interpreter. Chip posted this a while back. The I/O driver needs to be self contained because you may have to overwrite all available RAM when you boot a new SPIN program. You'll need to modify the existing OS_fileSystem routines to call the hard drive cog for addresses over 23 bits. The routines in OS_fileSystem that keep track of which EEPROMs are present would show that the additional space is always present. You'll get a space of 8MB on your hard drive with 256 "files" available, plenty for this kind of use.
After the loader cog finishes, I suppose the program that is loaded on it could just shut itself down to free up that cog?
At first, I thought I'd have to leave the loader cog running because I'd need a "kill" button to restore the original program from EEPROM, but then I realized that's exactly what the reset button does! I could just modify the startup code so that if the Propeller gets reset, it checks to see if there is a program running and merely suspended on the 68K side of my board, and if it does it could resume the suspended program instead of rebooting the 68K. This would also be handy for development because if my Propeller program crashes, I can just reset the chip and the rebooting Propeller could send a message to my OS on the 68K to let it know a hardware glitch had occurred and it could then redraw the desktop or restart any disk I/O it was trying to do.
Why not write a tool that can work with the Propeller's RXD and TXD pins used for PC programming to load EEPROMs with binary files from the PC?
It would act as an useful EEPROM programmer that could be used to write EEPROM's larger then 32k, which is where the Propeller Tool drops off at.
Just an idea though, I know it's much harder to do then say.
Also I think different EEPROMs use different ways of accessing different areas of the memory. 64k paging, etc. This would have to be coded into the utility as well.
(hmmm).... That makes me wonder.
Well it's just an idea. ^^
--Andrew Arsenault
1) In the OS, the loader is part of the I2C I/O cog, but it is written so it can be run separately. In that case, it can be called from SPIN. The SPIN start routine can start the loader in its own cog, replacing the SPIN interpreter. When the loader is finished, it will then restart SPIN in the same cog to interpret the loaded program.
2) If you add some extra EEPROM, you can store some restart information in it. The 68K could serve that function as well with the Propeller sending a command to the 68K requesting the saved information which could be backed up on the disk. You'd only need a few bytes to keep enough status information to resume where you'd left off on the Propeller.
Andrew,
The problem with using the Propeller's RXD and TXD pins is that the DTR pin comes with it and will restart the Propeller. I'm trying to debug a routine to load directly from another set of pins from the Propeller Tool to the extra EEPROM via a USB2SER or Prop Plug.
The routines in the OS already know about EEPROMs of different sizes.
Looks like you've already thought about this then. ^^
Keep up the great work. Your OS is starting to become a staple in this scene with many people taking interest in it everyday.
I would delete everything in the present OS VGA after this little routine:
·if not key.present
··· text.str(string("--> keyboard not present, can't continue"))
··· long[noparse][[/noparse]ldr#initMarker] := 0
··· abort false
· start
Then I would append my entire mill program.· I would not need to copy any objects since the only two objects the mill program uses are keyboard and vga.text.· I would have to delete the startup commands for the keyboard and the vga since they are contained in the OS system.· I would have to copy over the necessary VARS and CONS that the mill program uses.
Have I overlooked anything?
Sid
Sid
That makes sense to me. I assume you'd name your main routine "start" so the OS initialization routine will call it when it's done.
Yes, you don't need the simulation object. I just put it in to provide a virtual Stamp and RFID for testing purposes for your other program. You won't need the "OS_fileSystem" object or the "OS_editWindow" object either since you'll be deleting the OS command interpreter and these are not used elsewhere.
I am in the process of simplifying this kind of thing by putting the initialization routine in its own object so you just have to call it as the first thing in your program and your program is the "main program". I'm also setting things up so the TV display driver and lores VGA driver are interchangable. They'll be two versions of "OS_dspText.spin" and "OS_dspTextInit.spin" and you'll just pick the one you want (and copy the files to your own program directory). When I can make the hires VGA driver and the other two more compatible, there'll be 3 versions of interchangable drivers to choose from.
Mike
Post Edited (Mike Green) : 9/21/2006 10:39:50 PM GMT
PRI changeXpos(delta)
· xpos += delta
· WriteLong (@xpos,xpos)
PRI changeYpos(delta)
· ypos += delta
· WriteLong(@ypos,ypos)
When I tried to compile the OS version, I got an error - "Expected instruction or variable" and it highlighted "WriteLong".· Can you help?· Can't delete - this is a very important method that continually updates my X and Y position.
Sid
I need more information. That message usually shows up when a name is not defined. What's it supposed to do?
Mike
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Sid
between writelong and its opening parenthesis
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Now I have a new problem.·
The program compiles and loads OK, but I get no display on the monitor.· Let me work on tht for a little bit before I ask for help.· Don't go away.
Sid
1) You attached what seems to be the original milling program so I can't tell if something happened in editing it for the OS. I need the one that gets the error.
2) You've got a huge drilling table, at least 1600 longs (6.4K) not to mention a large program. I'm concerned that you're tight on memory. That wouldn't explain the error, but it may be a problem as you get further along. You can cut this table in half just by using words instead of longs. You can also pack the two items into one word as I show below. I also note that you have two longs per entry, but increment the pointer only once. You get away with this since you probably don't have any distances in the table that are exactly the same number as the command letters (next time through the loop, you interpret the distance as a command letter).
3) I can't see why you get the error. It doesn't make sense unless there is some punctuation error that's in the version you got the error in. I need to be able to reproduce the error here.
CON #0, DirLeft, DirRight, DirIn, DirOut, DirQuit, DirPause, DirDrill ' lots of stuff coord := word[noparse][[/noparse]board][noparse][[/noparse]pntr++] dir := coord >> 13 coord &= $1FFF if dir == DirLeft ' existing stuff elseif dir == DirRight elseif dir == DirIn elseif dir == DirOut elseif dir == DirQuit elseif dir == DirPause elseif dir == DirDrill DAT travl word DirLeft << 13 + 2075 word DirIn << 13 + 1300 word DirRight << 13 + 0 word DirOut << 13 + 0 word DirIn << 13 + 525 ' and so onI give up on my current attempt to OS my mill program.· The program compiles and loads just fine, but there is no display.· If I temporarily delete the appended program, the the display shows:
Running Mill OS· 9/22/06
If I go back to the program-appended version I get no display.· I am attaching the current version of Mill OS - maybe you can spot something.· I hope.
I'll see if I can incorporate your suggestions as soon as the current problem gets solved.
Sid
Had a couple of minor problems.· The first time I ran it, I went to Autorun - F - and the display was messed up.· It kept going back to the top of the display and overwriting what was there.· So......I took a good look at the Autorun routines, then I deleted all the screen color changes that were a holdover frim vga.text - OS was interpreting these as something else.· Once I got all those cleared up, the program ran perfectly.
Now then, this generates a secondary problem.· When I start the DAT list for a new board, I enter the coordinate I go to, and the direction X or Y.· Like this:
1000· X
800· Y
0· X
0· Y
I then copy and paste this data into an Excel templete which yields the following:
This is now in a format my Stamp can work with.· I copy the Excel data into the DATA section of a special Stamp program which converts the Excel data to this:
LONG··· "L",1000
LONG··· "I",800
LONG··· "R",0
LONG··· "O",0
This is the procedure I have been using.· I'm going to see if I can modify my Stamp program so it will generate an output like:
······· WORD··· DirLeft<<13 +·1000
······· WORD··· DirIn<<13 +·800·······
······· WORD··· DirRight<<13 + 0
······· WORD··· DirOut<<13 + 0
If I can't modify my Stamp program, then I guess I will have to manually edit each line of the LONG DAT list.· Believe me, I don't look forward to that!
Anyway, thank you very much.
Sid
It should be trivial to modify your Stamp program. It's a simple substitution. Instead of "L", use DirLeft<<13. Instead of "I", use DirIn<<13. Instead of "R", use DirRight<<13. Instead of "O", use DirOut<<13. Use + instead of the comma and WORD instead of LONG and there you have it. If you have problems, post the Stamp program and I'll have a look at it.
Unfortunately, I have nearly zero experience with Excel Macros. It should be straightforward for Excel to do the work for you and produce a text file that you can cut and paste into your Propeller program. Maybe someone else here can help you with that.
Mike
IF dir = "I" THEN
DEBUG· "WORD··· ",· "DirIn<<13 +", " ",SDEC f, cr
ENDIF
IF dir = "R" THEN
DEBUG· "WORD··· ",· "DirRight<<13 +", " ",SDEC f, cr
ENDIF
and so on for "L", "O", "D", "P" and "Q".
Wrote a little test program that went left,in,right,out,pause, drill and quit.· Went through my little procedure and pasted the results into the program as trav8.· Modified my Autorun program to call trav8, and the screen went through all the moves perfectly, so I guess it is OK.· Won't be really confident until I can write a little program to etch a real board, but for right now it looks like we're home free.· What a tremendous amount of data the HiRes screen displays!!
Didn't try out loading to EEPROM and seeing if the program would remember where it was when I shut down.· Doesn't really matter because I can't get that feature to work on the Demo board anyway, which is what I using on the mill.· If I have to sut down in the middle of something, I just jot down the X and Y posits, then restore them when I boot up and go thru the Reset method.
Life is good!
Sid
by eliminating the extra 'quote comma quote' bits.
Do check the initial menu display to see if xpos and ypos are saved correctly. It should work on the Demo Board with the routines in OS_loader. You can take out the calls to ReadLong as follows: (they're not needed since the Propeller reads the values from EEPROM when the program is loaded into RAM)
PRI showMenu text.out(0) ' ReadLong(@xpos) text.str(string("Xpos = ")) ' , 12,6, text.dec(~~xpos) ' ReadLong(@ypos) text.str(string(" Ypos = ")) text.dec(~~ypos) text.out(13)Turn the Prop off, then back on.· Both X and Y read 0 so the program is not saving the last posits.
Sid
Sid