You only need to connect the two Vin's. Both QuickStarts have there own regulator and it is not a good idea to connect the outputs of two regulators, also if it normally works (the regulator with the higher voltage will power both boards). So the Vdd's should not be connected.
I would choose 220 Ohm...1kOhm for the resistors between the pins. Too high values limit the max. bandwidth bewtween you can transmit.
Flash chips with Quad-SPI mode have the WE pin normally disabled per default. You need to enable it per bits in the status register. I don't know if this is true for all manufactures/chips but the Windbond W25Q16 I use behaves like that.
So it should be possible to use a Flash chip in an unmodified VGAplus board.
You only need to connect the two Vin's. Both QuickStarts have there own regulator and it is not a good idea to connect the outputs of two regulators, also if it normally works (the regulator with the higher voltage will power both boards). So the Vdd's should not be connected.
I would choose 220 Ohm...1kOhm for the resistors between the pins. Too high values limit the max. bandwidth bewtween you can transmit.
Flash chips with Quad-SPI mode have the WE pin normally disabled per default. You need to enable it per bits in the status register. I don't know if this is true for all manufactures/chips but the Windbond W25Q16 I use behaves like that.
So it should be possible to use a Flash chip in an unmodified VGAplus board.
Andy
Thanks Andy! I thought about just connecting the VIN pins between the two QuickStarts but the VGAplus256 doesn't bring out VIN on its "experimenter connectors" so I tried VDD instead. I'm not powering the second QuickStart so the regulators won't fight will they? Thanks for the suggestion for the resistors. I have 100 ohm and 1K ohm resistors so I guess I'll switch to 1K for the time being. I just used 10K to be a little safer and it seems to work with the speed that OBC is using for communications between the Propellers but it will probably cause trouble at faster speeds.
Also, thanks for the information about the /WE pin on the QuadSPI flash chips. I was planning on using the Winbond W25Q80BV so I'll check to see if it has the appropriate command for enabling writes. It would be great to be able to use an unmodified VGAplus256 board!
Thanks again!
David
Edit: I just switched to 1K resistors and, as you suggested, it works fine. I'm still tying the VDD lines together though since I don't have an easy way to access VIN on the QuickStart that has the VGAplus256 installed on it.
It's a bit ugly to drive the output of an unpowered regulator, but I have made this also a few times, and it seems to work. It may depend on the type of the regulator.
The W25Q80.. is the same as mine just with only 1MB. See section 7.1.7 of the datasheet: [Factory default]: The /WP pin has no control...
This sounds promising but what about what jazzed said about needing a pull-up on /CS (pin 1)? I don't believe that the VGAplus256 board has one.
It would be more safe with a pullup, but the chance that the random noise at the floating pins builds a valid WriteEnable and then a valid write command, before you set the CS pin per software, is not very high.
It would be more safe with a pullup, but the chance that the random noise at the floating pins builds a valid WriteEnable and then a valid write command, before you set the CS pin per software, is not very high.
Andy
I'll try it when I get a chance but I seem to remember having reliabiltiy problems when I hooked up the same Winbond chip to a PropBOE. The problems went away when I added the pull-up that jazzed recommended.
How does your VASP code work? Is it basically just a server for video/audio/keyboard/sd/etc? Could I load another program into the second Propeller and just have it use the same escape sequences to talk to your VASP code? Or is there something that ties it more directly to your Color Basic interpreter?
David,
The VASP code is not tied it any way to the basic code, you can write your own programs on the second propeller or and other micro-controller sending the correct serial commands
David,
The VASP code is not tied it any way to the basic code, you can write your own programs on the second propeller or and other micro-controller sending the correct serial commands
It occurs to me that it might be possible to combine the VASP code with Vince Briel's PockeTerm code to make a VT100 compatible terminal emulator that also supports sound and SD access. This could be a general purpose accessory to any other Propeller or other microcontroller board that normally uses serial I/O. The Propeller Mini Computer hardware would be the perfect hardware platform for this. I guess you'd have to add RS232 level translation to talk over a standard serial connection but that certainly isn't necessary for using it like Jeff is doing with Color Basic.
I guess we'd have to first make sure that Vince's code is open source.
Edit: I just looked at the PockeTerm source code and it doesn't explicitly say what license it uses but it does credit Jeff for the VT100 code so I guess that could be used along with VASP to make a VT100-compatible terminal program.
Yes, it is open source. Sorry, it is suppose to have the open source license on it. I'll have to fix that
Thanks Vince! Nice to see you here! Do you have any new projects underway? I really enjoyed your Replica 1 and MicroKim projects as well as the PockeTerm. Unfortunately, I have the Replica 1 from before you started using the Propeller for the video.
Yeah, I've replicated the OSI Superboard II using a Propeller as the video and direct connect to the 6502 bus as video RAM. I have a link to the discussion here:
Thanks to Jac Goudsmit we put countless hours into getting the video to emulate the OSI and have correct read/write to the Propeller video RAM section. While the video itself wasn't difficult, there were other hurdles with an unusual video memory map that made things difficult. The results are really good right now with a wirewrap prototype. I plan on going to PCB prototype soon! I was fortunate enough to have a real Superboard II to work with and check emulation.
For those who don't know what an OSI Superboard II is, this site gives good info:
Yeah, I've replicated the OSI Superboard II using a Propeller as the video and direct connect to the 6502 bus as video RAM. I have a link to the discussion here:
Thanks to Jac Goudsmit we put countless hours into getting the video to emulate the OSI and have correct read/write to the Propeller video RAM section. While the video itself wasn't difficult, there were other hurdles with an unusual video memory map that made things difficult. The results are really good right now with a wirewrap prototype. I plan on going to PCB prototype soon! I was fortunate enough to have a real Superboard II to work with and check emulation.
For those who don't know what an OSI Superboard II is, this site gives good info:
I'm going to start generating a list, feel free to email me at vbriel@yahoo.com and I'll start an "I want one" list. The aluminum panels run about $2000 for a small order and I need to have enough people interested to do another run. Yeah, sorry Jeff, were off topic.
Hey Jeff, we need to make another trip to NYC again Fun times. I miss NE Ohio, especially when it hits 104 in Southern California. I really miss the Propeller Expo. By the way, reading through this thread there is discussion of SD card with the PockeTerm. Since this is the code we worked on, your version had SD card features built in that could be helpful.
It occurs to me that it might be possible to combine the VASP code with Vince Briel's PockeTerm code to make a VT100 compatible terminal emulator that also supports sound and SD access. This could be a general purpose accessory to any other Propeller or other microcontroller board that normally uses serial I/O. The Propeller Mini Computer hardware would be the perfect hardware platform for this. I guess you'd have to add RS232 level translation to talk over a standard serial connection but that certainly isn't necessary for using it like Jeff is doing with Color Basic.
Edit: I just looked at the PockeTerm source code and it doesn't explicitly say what license it uses but it does credit Jeff for the VT100 code so I guess that could be used along with VASP to make a VT100-compatible terminal program.
Egads.. I hadn't looked at that code for a while! Maybe I should finaly get around to solving the little bug in it that was corrected with this chunk of code.. heh...
col:=col-1
if row == -459
row:=1
if col == -40 ' Patches a bug I havn't found. *yet*
col := 58 ' A Microsoft approach to the problem. :)
if row == -449
row := 2 ' Appears to be an issue with reading
if row == -439 ' single digit rows.
row := 3
if row == -429 ' This patch checks for the bug and replaces
row := 4 ' the faulty calculation.
if row == -419
row := 5 ' Add to list to find the source of bug later.
if row == -409
row := 6
if row == -399
row := 7
if row == -389
row := 8
if row == -379
row := 9
row--
The VASP concept is designed with the idea that it can be swapped out at will and combined with multiple configurations, so there is no reason why not.
As soon as I get a few more of the core commands working, I'll be re-adding a graphic VASP client. I'm also already planning a secondary serial communication connection which will relay serial data TX/RX from the top Propeller back to the client.
I took a couple weeks off to deal with a bunch of storm damage machines in my first job. I'm back in the saddle this week, but I probably won't reveal too many more details till Expo.
I took a couple weeks off to deal with a bunch of storm damage machines in my first job. I'm back in the saddle this week, but I probably won't reveal too many more details till Expo.
Jeff
Sorry to year about your storm damage. I hope it wasn't anything too serious!
Unfortunately, I won't be able to make it to the Expo but I'm looking forward to hearing about any PMC developments you announce there.
I got my two CogSleds and have both my PMC and my extra QuickStart board mounted to one. This makes a much better arrangement than the last time I tried the multi-Propeller version of Color Basic since I no longer have two boards connected only by some resistors and wires! The only problem is that I used all of the mounting hardware for both CogSleds on the one that I'm using for the PMC. How can I get another set of mounting hardware? I asked that on my PayPal order but maybe you didn't see it. Can I order just the mounting hardware for two CogSleds?
Also, I'm still trying to find the best approach for connecting power between the two QuickStart boards. The VGAPlus256 board has two pins labeled "PwE". What are they connected to? I couldn't find them on the schematic. Is one by any chance VIN?
FYI, here is what my two Propeller PMC looks like after mounting it to Jeff's cool CogSled. Much cleaner setup and probably a lot more reliable. Thanks Jeff!
This whole two-Propeller PMC idea is bothering me. What we essentially have is one Propeller being used to implement terminal and the other running the Basic interpreter. It seems like the main reason the second Propeller is needed is to provide 32k of additional hub memory because there isn't enough hub memory on a single-Propeller PMC to allow for a very large Basic program. I'd kind of like to find a way to make better use of the second Propeller. I guess that could be done by providing primitives in Basic that can launch code in other COGs. That way the Basic Propeller could use 7 of the 8 COGs (one is used to run FDS to talk back to the Terminal Propeller) to run Basic code and would have available to it almost all of the pins except the two that are used to talk to the terminal Propeller. I suppose another alternative, if it is too difficult to get Basic running on more than one COG at a time, would be to allow a Basic program to launch another COG running PASM code.
@David, that's an interesting idea. I don't know the VGABASIC details and it's much easier to talk that actually create but......
If it's anything like the other interpreters (SPIN, LMM, PropForth, etc.) if you can isolate a copy of any private HUB memory so it can be duplicated and reserved for a COG, then you could start multiple copies of the interpreter and just point it to a list of tokens to execute. Not as simple as that but it would be cool to have a multi-cog BASIC.
@David, that's an interesting idea. I don't know the VGABASIC details and it's much easier to talk that actually create but......
If it's anything like the other interpreters (SPIN, LMM, PropForth, etc.) if you can isolate a copy of any private HUB memory so it can be duplicated and reserved for a COG, then you could start multiple copies of the interpreter and just point it to a list of tokens to execute. Not as simple as that but it would be cool to have a multi-cog BASIC.
What I've been thinking about doing is putting the editor and compiler on the same Propeller that has the VGA and KB attached (the one with the VGAplus256 board attached). Then, I'd compile the user's program to bytecodes when the "run" command is entered and download the bytecodes to the other Propeller. That Propeller could run the bytecode VM on any of its COGs other than the one used to communicate with the editor/compiler Propeller. This is similar to what Spin does of course. This approach should allow almost all of the 32k of hub memory on the second Propeller to be used for Basic code and data. I'd use the SPI socket on the VGAplus256 board for a SPI flash chip and use PropGCC to build the editor/compiler code using the XMMC memory model that would allow the code to be much larger than the 32k of hub memory. The nice thing about this split between the two Props is that the compiled Basic code will run very fast because it will only be running from hub memory. The compiler and editor can be a little slower because they don't have realtime requirements. I think this can be done without any modifications to the PMC hardware except maybe to add a pull-up resistor to the SPI socket.
What I've been thinking about doing is putting the editor and compiler on the same Propeller that has the VGA and KB attached (the one with the VGAplus256 board attached). ....The nice thing about this split between the two Props is that the compiled Basic code will run very fast because it will only be running from hub memory.
Sounds like a nice split.
Can the running-prop, include a debug link to the editor-prop ?
Enough to allow a single-step, and animate should be low-resource-cost ?
I think the Prop HW would allow a one-line Wait, and if the editor-prop sends impulses shorter than the Bytecode 'next', then it can control the speed of execute. High runs at (almost) full speed, and low paces at the Editor-side rate.
Speed impact is one more line for the wait, and maybe one more line for the Skip-Send test.
Sounds like a nice split.
Can the running-prop, include a debug link to the editor-prop ?
Enough to allow a single-step, and animate should be low-resource-cost ?
I think the Prop HW would allow a one-line Wait, and if the editor-prop sends impulses shorter than the Bytecode 'next', then it can control the speed of execute. High runs at (almost) full speed, and low paces at the Editor-side rate.
Speed impact is one more line for the wait, and maybe one more line for the Skip-Send test.
How many cycles is the ByteCode feeder now ?
The problem is that I've written a whole slew of basic interpreters at this point. Most of them have compilers that run on a PC but the one that is distributed with PropGCC runs directly on the Propeller. Unfortunately, that's not the one that has the PASM bytecode interpreter. I'd have to do some work to merge a number of my basic systems to make one that behaves the way I described in my earlier post. I'll attach the code to the PASM bytecode interpreter to this message so you can see what I have in mind. It does support single stepping.
I'd guess the Editor Prop also has no problems using a spare COG to do some time-of-flight measurements, provided the target device can Set/Clear a pin.
Doing that without adding executed source code lines, might be possible with upper address bits, or similar (but it would still need a Editor Tag system, of course ) ?
I hate to revive a dead thread but this is alls I could find.
I have a propeller gathering on my desk so I want a fun project to do and a quick google returned this thread. I want to turn my propeller into a tiny computer I can pack up with me. I want to make the board myself so I can make it as tiny as possible. I simply need the pins to hook all the accessories to, the SRAM, keyboard and sd card for example.
Comments
You only need to connect the two Vin's. Both QuickStarts have there own regulator and it is not a good idea to connect the outputs of two regulators, also if it normally works (the regulator with the higher voltage will power both boards). So the Vdd's should not be connected.
I would choose 220 Ohm...1kOhm for the resistors between the pins. Too high values limit the max. bandwidth bewtween you can transmit.
Flash chips with Quad-SPI mode have the WE pin normally disabled per default. You need to enable it per bits in the status register. I don't know if this is true for all manufactures/chips but the Windbond W25Q16 I use behaves like that.
So it should be possible to use a Flash chip in an unmodified VGAplus board.
Andy
Also, thanks for the information about the /WE pin on the QuadSPI flash chips. I was planning on using the Winbond W25Q80BV so I'll check to see if it has the appropriate command for enabling writes. It would be great to be able to use an unmodified VGAplus256 board!
Thanks again!
David
Edit: I just switched to 1K resistors and, as you suggested, it works fine. I'm still tying the VDD lines together though since I don't have an easy way to access VIN on the QuickStart that has the VGAplus256 installed on it.
The W25Q80.. is the same as mine just with only 1MB. See section 7.1.7 of the datasheet: [Factory default]: The /WP pin has no control...
Andy
It would be more safe with a pullup, but the chance that the random noise at the floating pins builds a valid WriteEnable and then a valid write command, before you set the CS pin per software, is not very high.
Andy
I'll try it when I get a chance but I seem to remember having reliabiltiy problems when I hooked up the same Winbond chip to a PropBOE. The problems went away when I added the pull-up that jazzed recommended.
Anyway, thanks for all of your help!!
The VASP code is not tied it any way to the basic code, you can write your own programs on the second propeller or and other micro-controller sending the correct serial commands
http://www.brielcomputers.com/wordpress/?cat=25
I guess we'd have to first make sure that Vince's code is open source.
Edit: I just looked at the PockeTerm source code and it doesn't explicitly say what license it uses but it does credit Jeff for the VT100 code so I guess that could be used along with VASP to make a VT100-compatible terminal program.
http://www.brielcomputers.com/phpBB3/viewtopic.php?f=36&t=1515
Thanks to Jac Goudsmit we put countless hours into getting the video to emulate the OSI and have correct read/write to the Propeller video RAM section. While the video itself wasn't difficult, there were other hurdles with an unusual video memory map that made things difficult. The results are really good right now with a wirewrap prototype. I plan on going to PCB prototype soon! I was fortunate enough to have a real Superboard II to work with and check emulation.
For those who don't know what an OSI Superboard II is, this site gives good info:
http://oldcomputers.net/osi-600.html
I've liked this computer since I was a kid reading the computer magazines. I always had a thing for single-board computers
Hi Vince,
Any idea when the Altair will be ready? I built an original in 1975. I ebayed it about 10 years ago for $3,600. I what another!
Sorry to hijack Jeff.
Jeff
Egads.. I hadn't looked at that code for a while! Maybe I should finaly get around to solving the little bug in it that was corrected with this chunk of code.. heh...
col:=col-1 if row == -459 row:=1 if col == -40 ' Patches a bug I havn't found. *yet* col := 58 ' A Microsoft approach to the problem. :) if row == -449 row := 2 ' Appears to be an issue with reading if row == -439 ' single digit rows. row := 3 if row == -429 ' This patch checks for the bug and replaces row := 4 ' the faulty calculation. if row == -419 row := 5 ' Add to list to find the source of bug later. if row == -409 row := 6 if row == -399 row := 7 if row == -389 row := 8 if row == -379 row := 9 row--The VASP concept is designed with the idea that it can be swapped out at will and combined with multiple configurations, so there is no reason why not.
As soon as I get a few more of the core commands working, I'll be re-adding a graphic VASP client. I'm also already planning a secondary serial communication connection which will relay serial data TX/RX from the top Propeller back to the client.
Jeff
Have you made any progress on the two Propeller version of your Propeller Color Basic?
Thanks,
David
Jeff
Unfortunately, I won't be able to make it to the Expo but I'm looking forward to hearing about any PMC developments you announce there.
Also, I'm still trying to find the best approach for connecting power between the two QuickStart boards. The VGAPlus256 board has two pins labeled "PwE". What are they connected to? I couldn't find them on the schematic. Is one by any chance VIN?
Thanks!
-Tor
If it's anything like the other interpreters (SPIN, LMM, PropForth, etc.) if you can isolate a copy of any private HUB memory so it can be duplicated and reserved for a COG, then you could start multiple copies of the interpreter and just point it to a list of tokens to execute. Not as simple as that but it would be cool to have a multi-cog BASIC.
Sounds like a nice split.
Can the running-prop, include a debug link to the editor-prop ?
Enough to allow a single-step, and animate should be low-resource-cost ?
I think the Prop HW would allow a one-line Wait, and if the editor-prop sends impulses shorter than the Bytecode 'next', then it can control the speed of execute. High runs at (almost) full speed, and low paces at the Editor-side rate.
Speed impact is one more line for the wait, and maybe one more line for the Skip-Send test.
How many cycles is the ByteCode feeder now ?
The problem is that I've written a whole slew of basic interpreters at this point. Most of them have compilers that run on a PC but the one that is distributed with PropGCC runs directly on the Propeller. Unfortunately, that's not the one that has the PASM bytecode interpreter. I'd have to do some work to merge a number of my basic systems to make one that behaves the way I described in my earlier post. I'll attach the code to the PASM bytecode interpreter to this message so you can see what I have in mind. It does support single stepping.
xbasic_vm.spin
That's the important detail
I'd guess the Editor Prop also has no problems using a spare COG to do some time-of-flight measurements, provided the target device can Set/Clear a pin.
Doing that without adding executed source code lines, might be possible with upper address bits, or similar (but it would still need a Editor Tag system, of course ) ?
I have a propeller gathering on my desk so I want a fun project to do and a quick google returned this thread. I want to turn my propeller into a tiny computer I can pack up with me. I want to make the board myself so I can make it as tiny as possible. I simply need the pins to hook all the accessories to, the SRAM, keyboard and sd card for example.