Sid,
You have been using WriteLong to save the values to xpos and ypos. WriteLong calls WriteWord which calls WriteByte to do the actual work.
changexpos and changeypos call WriteLong. These are called by the Autorun routines. I don't know if they're called when you manually enter a new position.
Another thing you could try is to substitute $7FE8 for @xpos and $7FEC for @ypos in the calls to WriteLong and do
xpos := ReadLong($7FE8)
ypos := ReadLong($7FEC)
in your start routine. These locations are not used in the EEPROM, but they are cleared to zero when the Propeller Tool downloads the program to the EEPROM.
Sid,
Make sure you're compiling with the right version. Copy the OS files fresh from the latest version, particularly the display driver. I can see how easy it is to get the versions out of sync. I'll have to start putting version numbers in the comments of each file.
Mike
Mike, I've been working with Mill OS - the version that toggles OK.· I changed a couple of the DAT lists from LONG to WORD, made the necessary corrections in my program and they run perfect.· It's a slow, tedious process to change every LONG to WORD - I may go back and recompile the lengthy ones - I've already modified by Stamp program to output WORD instead of LONG.
If I load the program into EEPROM instead of RAM, the program saves the last posits, both in manual and Autorun, so that is just great.· I tried it several times, and each time I reboot, the screen displays the last posits.· I guess the program is about as perfect as I would want.· It appears to do everything I ask flawlessly.· I would say this has been quite an effort -· maybe not for you but certainly for me.· I can never thank you enough.
If you would like to see a copy of Mill OS, let me know and I will post it.· I had to make a lot of cosmetic changes, and I had to go through the entire program and change all instances of kb.XXX to key.XXX.· With just the two changes I have made converting the DAT lists, I have increased free memory from 2898 to 2969 longs.
The Propeller Tool has a search and replace menu item including a replace all item. You can change all instances of kb. to key. with a couple of mouse clicks. I did the same thing to change LONG to WORD, changed I", to DirIn<<13+ the same way. Saves a lot of typing. Look in the Propeller Manual on pages 49-51.
Thanks for the tip, Mike.· Now THAT is a big time-saver.
I'm about ready to load Mill OS into the Demo board that runs SuperMill.· On the board that I am using in here, SCL has a pullup to Prop Vdd, which the Demo board does not have.
At the beginning of my program I start the I2CObject with:
i2cObject.Init(i2cSDA, i2cSCL, true)·
Do I change this to false before I load the Demo board?
PUB Start : okay · ' start the object · if i2cStarted == false ··· i2cStarted := true
This tells me that if I start the object as TRUE it will stay TRUE.· It also tells me that if I start the object as FALSE it will get changed to TRUE.· So why the TRUE/FALSE option - why not just set it to TRUE and be done with it.
I changed the object start from TRUE to FALSE and back to TRUE again - it made no difference.· The program saved the last posits in all instances.
You'll have to ask James why he decided to do it this way. I assume that he wanted i2cStarted to indicate whether the I/O pins had been initialized. If you're using James' routines, then you need his .init call and the 3rd parameter should be false if you have pullups on both lines. If you're using my I2C routines (in OS_loader), you don't need any of James'. They do the same sort of things. My routines check automatically for the pin 28/29 I2C bus and don't care whether you have pull ups there or not. In fact, James' routines should work fine if you have pullups, but set the 3rd parameter to true.
You are confusing me a bit in that the routines I modified for you had all references to James' I2C routines removed since OS_loader provides its own EEPROM read/write routines and you didn't need duplicate functionality.
OK, but, if you go through some of the other modified versions I sent you recently, you'll see a different WriteByte that calls ldr.writeEEPROM(ldr#i2cBootSCL<<18+location,@contents,1) or something similar. Since you're happy with what you've got and it works, don't mess with it.
Yes, that is in some of the versions I have.· Have been trying to clean up my confusing files.· I moved all the quasi-duplicate files to a folder named "Old Programs" where I can call them if I ever need them.· Right now my working folders have only one top file, which makes life a bit easier.
New project - I want to write a Prop program to extract a user-defined root from any number.· Here is what I want to do:
Enter number a
a = 1000
Enter root to extract b
b = 3
c = log a
d = c/b
e = antilog d
print e
I read the Appendix in the Propeller manual but all the examples are in assembly, which is Greek to me.· I don't know how to call the log or antilog of a given number.
Unless you want to learn how to use the built-in log/antilog tables, just download the floating point routines from the Propeller Object Exchange.
If you really want to use the tables, they're just words at fixed addresses. You can access the log tables at word[noparse][[/noparse]$C000] and the antilog tables at word[noparse][[/noparse]$D000] where i is an index from 0 to 2047. You can do all the manipulation in SPIN if you want. It's just moving bits around. The text in the appendix describes what to do.
Mike, I just loaded Mill OS into my Demo board for the mill.· Everything works OK except it does not save the last posits.· This is the same version that works perfectly on my Prop board with the SCL pullup.
Sid,
Which I2C routines are you using? If it's the i2cObject, you'll have to contact James about that. His routines are supposed to work without the pullup. I have tested my OS_loader routines on the Demo Board and they seem to work fine with the boot EEPROM.
Mike
Mike, I'm using the I2CObject.· I'll live with it for awhile - I need to make some TV Module boards.· When I get caught up I'll send you my Mill OS program and ask to to modify it so I don't need the I2CObject.
Mike, I just finished the two TV Module boards using the new HiRes program and it ran flawlessly.· The display on my 15" LCD monitor was even better than I had hoped for.· Onky one thing - the shop is a very brightly lit room, of course, and it would help if the medium blue background were a bit darker so that the letters would stand out a bit more.· Is there any way I can darken it a little?
I hold down my PCB workpiece with double-sided golf grip tape, and I have started routing the outside dimensions of the board with an .040 router.· Does an outstanding job - no more trimming down with my little table saw.
I cut the table speed in half when I'm doing that since I didn't want to take a chance on breaking the router.
Sid,
There's a control byte used with the dsp.out4 command called Color which is followed by a row number, a foreground color, and a background color. The comments around line 85 of OS_vgaHiresText describe how the values are made up. Essentially they are %RRGGBB00 where R is red, G is green, and B is blue with values from 0-3. You'd call dsp.out4(dsp#Color,row,%RRGGBB00,%RRGGBB00) where row is the row to change and the other two values are the foreground and background color codes. I think the default set is %11110000 and %00001000. Play around.
Mike
Sorry, Mike, but I guess I'm not smart enough to follow what you were trying to tell me.· I searched all the files in the folder and I couldn't find the two default control bytes you mentioned.· I thought if I could find those I could play around with changing the vales.· I did find a command to change color - $13 - but that was as far as I got.· No matter, I'll just leave things like they are.· I have a worklamp shining on the mill table so maybe I can do away with the overhead lights.· We'll give that a try.
Look in OS_vgaHiresText.spin around line 85. You'll see some comments describing "colorPtr" which contains the address of the color table, one word for each line on the screen (up to 64 lines depending on resolution). These words have two bytes, one containing an 8 bit code for the foreground color and one containing the background color. The comment describes how the bytes are constructed. The command to change color ($13) does just that. It takes a row # followed by a foreground color byte and a background color byte and changes the color table entry for that row.
You can also play around with the color, contrast, and brightness settings on your VGA monitor. Sometimes that will help.
Mike
and I was able to determine the address of the colorptr to be 32724.· That was as far as I could get.· If you have your heart set on me learning now to change the colors, then you are going to have to tell me what to write and where to write it.· Do I have to change all the rows individually or can they all be changed at once?
It's a good thing everyone else on this forum is more knowledgeable than I.
Mike, I went through the previous files you have posted and tried to modify my mill program to save posits without the I2CObject.· I could not get it to work - I must be skipping a step somewhere.· I have attached the current version of my Mill OS V1.10 which runs perfectly except that it does not save the posits when I reboot.· When you have time, could you try to modify it to do away with the I2CObject and use the ldr.EEPROM, then·send it back to me as V1.20.· No hurry.· Thanks a lot.
Comments
Sid
You have been using WriteLong to save the values to xpos and ypos. WriteLong calls WriteWord which calls WriteByte to do the actual work.
changexpos and changeypos call WriteLong. These are called by the Autorun routines. I don't know if they're called when you manually enter a new position.
Another thing you could try is to substitute $7FE8 for @xpos and $7FEC for @ypos in the calls to WriteLong and do
in your start routine. These locations are not used in the EEPROM, but they are cleared to zero when the Propeller Tool downloads the program to the EEPROM.
PRI changeXpos(delta)
· xpos += delta
· WriteLong ($7FE8,xpos)
PRI changeYpos(delta)
· ypos += delta
· WriteLong($7FEC,ypos)
and then I wrote:
PRI showMenu
· text.out(0)
· 'ReadLong(@xpos)
· xpos := ReadLong($7FE8)
· text.str(string("Xpos = "))
· text.dec(xpos)·
· 'ReadLong(@ypos)
· ypos := ReadLong($7FEC)
· text.str(string("········ Ypos = "))
· text.dec(ypos)
I ran my litle test program in Autorun and it said:
X = 0···· Y=800
Press any key to return to start
When I pressed a key to return to start the screen said:
X=0····· Y=0
Now it isn't even keeping the current posits.
Sid
Don't knock yourself out over this - it would really be nice to have it working, but I can live without it.
Sid
Sid
Make sure you're compiling with the right version. Copy the OS files fresh from the latest version, particularly the display driver. I can see how easy it is to get the versions out of sync. I'll have to start putting version numbers in the comments of each file.
Mike
Sid
Sid
Sid
Sid
If I load the program into EEPROM instead of RAM, the program saves the last posits, both in manual and Autorun, so that is just great.· I tried it several times, and each time I reboot, the screen displays the last posits.· I guess the program is about as perfect as I would want.· It appears to do everything I ask flawlessly.· I would say this has been quite an effort -· maybe not for you but certainly for me.· I can never thank you enough.
If you would like to see a copy of Mill OS, let me know and I will post it.· I had to make a lot of cosmetic changes, and I had to go through the entire program and change all instances of kb.XXX to key.XXX.· With just the two changes I have made converting the DAT lists, I have increased free memory from 2898 to 2969 longs.
Now to play with it for awhile.
Sid
The Propeller Tool has a search and replace menu item including a replace all item. You can change all instances of kb. to key. with a couple of mouse clicks. I did the same thing to change LONG to WORD, changed I", to DirIn<<13+ the same way. Saves a lot of typing. Look in the Propeller Manual on pages 49-51.
I'm about ready to load Mill OS into the Demo board that runs SuperMill.· On the board that I am using in here, SCL has a pullup to Prop Vdd, which the Demo board does not have.
At the beginning of my program I start the I2CObject with:
i2cObject.Init(i2cSDA, i2cSCL, true)·
Do I change this to false before I load the Demo board?
Sid
PUB Start : okay
· ' start the object
· if i2cStarted == false
··· i2cStarted := true
This tells me that if I start the object as TRUE it will stay TRUE.· It also tells me that if I start the object as FALSE it will get changed to TRUE.· So why the TRUE/FALSE option - why not just set it to TRUE and be done with it.
I changed the object start from TRUE to FALSE and back to TRUE again - it made no difference.· The program saved the last posits in all instances.
Sid
You are confusing me a bit in that the routines I modified for you had all references to James' I2C routines removed since OS_loader provides its own EEPROM read/write routines and you didn't need duplicate functionality.
PRI WriteByte(location,contents)
· i2cObject.writeLocation(EEPROM_ADDR, location, contents, 16, 8)
· waitcnt(clkfreq / 50 + cnt)
It may be redunant or there may be a workaround but the program is working beautifully, so I am happy.
Sid······
New project - I want to write a Prop program to extract a user-defined root from any number.· Here is what I want to do:
Enter number a
a = 1000
Enter root to extract b
b = 3
c = log a
d = c/b
e = antilog d
print e
I read the Appendix in the Propeller manual but all the examples are in assembly, which is Greek to me.· I don't know how to call the log or antilog of a given number.
If you have time and if you are in the mood.
Sid
If you really want to use the tables, they're just words at fixed addresses. You can access the log tables at word[noparse][[/noparse]$C000] and the antilog tables at word[noparse][[/noparse]$D000] where i is an index from 0 to 2047. You can do all the manipulation in SPIN if you want. It's just moving bits around. The text in the appendix describes what to do.
Sid
Which I2C routines are you using? If it's the i2cObject, you'll have to contact James about that. His routines are supposed to work without the pullup. I have tested my OS_loader routines on the Demo Board and they seem to work fine with the boot EEPROM.
Mike
Sid
I hold down my PCB workpiece with double-sided golf grip tape, and I have started routing the outside dimensions of the board with an .040 router.· Does an outstanding job - no more trimming down with my little table saw.
I cut the table speed in half when I'm doing that since I didn't want to take a chance on breaking the router.
Sid
There's a control byte used with the dsp.out4 command called Color which is followed by a row number, a foreground color, and a background color. The comments around line 85 of OS_vgaHiresText describe how the values are made up. Essentially they are %RRGGBB00 where R is red, G is green, and B is blue with values from 0-3. You'd call dsp.out4(dsp#Color,row,%RRGGBB00,%RRGGBB00) where row is the row to change and the other two values are the foreground and background color codes. I think the default set is %11110000 and %00001000. Play around.
Mike
Sid
You can also play around with the color, contrast, and brightness settings on your VGA monitor. Sometimes that will help.
Mike
·text.dec(ldr#colorptr)
·waitcnt(clkfreq*10 + cnt)
and I was able to determine the address of the colorptr to be 32724.· That was as far as I could get.· If you have your heart set on me learning now to change the colors, then you are going to have to tell me what to write and where to write it.· Do I have to change all the rows individually or can they all be changed at once?
It's a good thing everyone else on this forum is more knowledgeable than I.
Sid
Sid