As of 10 minutes ago I have tested that the Prop tool sees the Propeller, that I can load the eeprom and that I can use the serial port via the max232. I love it when it all goes smoothly!
Before getting too disheartened about the memory changes not working, I went back to basics and re-instated the '138 and two latches ( L and M ). That worked again as expected, but as soon as I tried to shift the P8 - P11 for the '138 nothing but "Spacebar" would happen. I suspected that there might be another set of DIRAs apart from the obvious ones in the ram handling routines, but didn't find any that would affect it. Even moving P8 - P11 to P9 - P12, and readjusting the longs for masking, doesn't work. I am pretty sure that the P12 -P15 bunch are entirely free now the SD is shoved over to P20 -P23. The pins just do not come out of Hi Z, according to the hum pickup on the 'scope prob, induced by finger poking. Any thoughts ??
Perhaps I will have to go your route and start with the ram access bits, as a separate, and then build a computer onto that. It will probably be more informative.
I have left the VGA as four pins as the background (blue) wasn't happy unless it maintained the H + V blankings, various monitors reacted differently to monostable based line blankings, and I couldn't be .... to start putting on frame bits as well (my old Sanyo would work, as would a Philips but my LGs hated it). So until desperation for just one more pin .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Brief reply as I'm still at work. Yes, two places that do ram driving code so one might be overriding the other. There is custom dracblade ram driver pasm, and there is ram driver in the zicog. Once you kick off the zicog there is virtually no chance of tracing anything, so better to get the dracblade ramdriver code working and copy it into the zicog. At least you have a chance of debugging it.
You always need one more pin! Look at the convolutions cluso has gone through to get one pin video and one pin keyboard.
Forget even starting the zicog code till you can write a byte to ram and read it back. That will involve code with lots of delays so you can watch the pins change one at a time. That was the way I got it working - very tedious and working right back at the bitbang level.
If pins are hi Z and shouldn't be, try disabling cogs one at a time. Forget keyboard, sd vga and serial. Just start up the propeller and get it to put a pin high, then wait a second then put it low, write one byte, read it back, then light a led if the bytes match up, and not light a led if they don't match. That way there is no potential interference from other objects.
Write one byte and read it back is 95% of the work.
Addit - a batch of version 5 boards just left the factory. I'll need to solder one up to check it works, but main difference is lots of different pads for different types of regulators. Plus the board is a little smaller, and the tracks to the VGA are shorter so I'm hoping the VGA display wont have as much interference.
Thanks for the reply, sorry not to respond until now. The internet connection at work decided to stop and then run slightly slower than a slug fixed down with a couple of salted nails ( no actual slugs were harmed in the making of this metaphor ).
I'll have a nose at Zicog now I am at home. I have found 8 EDO DRAMs from an old PCI VGA card which look, on paper, as though they will suffer address and data being paralleled, so possibly no latches. They are 256KB x 16 (with separate /CASL and /CASH) so will do for first trials
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Right, I have made a nice cup of tea and looked in Zicog for thos DIRAs.
Fancy hiding them under a four line banner, like that.
I can only assume that I had got code blindness by then
Addit
Ahh, I start to see big problems. These routines use literals, which are ok for #$100, just, but not for #$1000. So I am starting to see why you chose P8 for the Gate. I just thought that it happened to be the next one up from the bottom 8 bits. I was hoping to get 9++ clear bits for the rows and columns and use the others up to P15 for the control bits.
And another thing, could you leave more than just one spare long available !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/1/2010 8:28:48 PM GMT
andn outa,#$100 ' set gate low
nop ' NOP needs at least one due to 138 propogation delay
or outa,#$100 ' set it high again
Could only be done with pins 0-8 and because 0-7 are the data bus that only leaves pin 8. So that pin had to be the one. I'm going to go off and have a minor rant now about how we had 8 bit microprocessors in the 1970s and now in 2010 we have a 9 bit microporcessor. I want a 32 bit microprocessor *bangs fists against floor*
There, I feel better now.
It took a lot of work to get it to just fit. Heater and Cluso had made it only just fit anyway and Cluso's ram driver routine was slightly smaller than mine, so it was a matter of trying to find spare longs in the zicog code. But heater had already optimised the code (no doubt before trying the overlay solution). Finding spare longs in someone elses already optimised code is a real challenge. Though I have a feeling there might still be one oor two lurking there.
There is a solution however. In the setup defs, make it 8080 instead of Z80 code. Most of CP/M is 8080 anyway so wordstar and basic should still work. (In the end it is just BBC Basic and Z80 assembly that uses Z80 opcodes, and even then only a subset. Plus half the Z80 codes haven't even been added yet). So if the Zicog is really an 8080cog then may as well leave it as an 8080 cog. Then you save quite a few longs and you can start experimenting.
Having said that, I'd set aside the zicog cog altogether and try getting things working in spin first. Debugging spin code is much easier than pasm, and the first step I did when getting the latch ram working was to write a pure spin driver, with lots of delays and lots of 'halts' (ie repeat). I found it easier to then translate spin to pasm rather than trying to debug pasm.
Yes I was trying desparately, last night to not just go 8080. It is the dream of the Nascom resurection, I suppose, it uses a few real Z80 op-codes that are not in the Zicog lot, yet.
Still it would be better to get this memory interest rolling along, and the worry about niceities later on, when a deeper understanding has been developed (but that all sounds like good sence, doesn't it, I want to tweek just one thing and everything to fall into place at once).
Blade2 and a separate VGA etc Prop, which I also have built might end up being the one for the Nas.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
8080 is only a temporary fix. I had it 8080 only for a while when I was taking working inefficient code and making it smaller. You have to go backwards before you can go forwards. Delete/destroy/vaporize the zicog, keyboard, vga, sd, serial. Strip it right back to just the 'main' program, and jump straight in to writing one byte to ram within that main program. Then in pasm in a seperate cog, and finally port it over to the zicog.
It is entirely possible you might end up with shorter code than the dracblade latch code.
I'm only saying this because this was the only way I got it to work. I don't think it is possible to debug new ram driver code in the zicog. There are too many variables and too many unknowns. For instance, that one NOP between a read and a write. If there had been another error then it would have been impossible to even find how many NOPs it needed. You can't simulate this stuff either, and even adding halts or pauses doesn't work because it adds artifical delays.
And, like you say, it only just fits, so how does one debug with extra NOPs if it only just fits? Answer is to drop it back to 8080 to free up space. With different ram chips it is quite likely there will be a need for other NOPs and you might even have them all over the place and then delete them one at a time.
I note the comments on the zicog thread about overlays. I think I wrote that up a month or two ago - it is hidden away in the zicog thread somewhere. There are about four things you have to add for an overlay. Adding an overlay would come way after getting a memory chip working.
To start with it will be some old M11B416256As (256KB x16) lifted from an old PCI VGA card. They are EDO and on the datasheet shows that it would be possible to do ROWs and COLUMNs on the same pins as data, as I originally wished. If so then no (external) latches or '138 would be needed. They are 256K x 16 rather than 512K x8 but they have separate /CAS low and high so more possibilities. This could mean one ram, one Prop, one EEPROM and one SD for a DracBlade. I'll get the b***** into a match box, yet·!
If all that could be proven, then the syncronous sort could be tried.
But as Clusso said, the static ram·with pins or latches is the most definite, and probably·best route.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
That is a 40 pin chip with 16 data lines. So ? latches, or ? use more prop pins, but then you have to work out which things you don't need. You could drop the second serial port. And go for Cluso's 1 pin keyboard. And also drop vga and go for cluso's 1 pin TV.
So some tricky questions there before you even start looking at coding. Do you have an idea for a schematic?
You can still buy EDO DRAM? I use a board with a 1MB EDO SIMM. The refresh depends on a down counter in the command loop of the device driver COG. The only time more than one instruction is required in the loop is when the counter expires. Works like a champ. I'm an advocate of more than one byte at a time fetch when reasonable [noparse]:)[/noparse]
Refresh was always going to be one of the problems, the old DRAMs would hold the rows and columns as internal latches and an artical on Jespers AVR pages showed the data mplx onto those address lines too. That was what I recognized on DracBlade. These EDO rams appear tol do /RAS only and hidden refreshes along with a latched /CAS, the SDRAMs have a better integration of the refreshing bits but work around the fast page mode into cache ram, and as far as I can see not allow the use of common lines for data.
This particular chip is 16 bits but has separate high and low /CASs so it could be fiddled to be 512KB x 8
I was hoping for a slightly modded DracBlade as a test bed, for the 256KB only 9 address lines would be needed, with 8 of them also for the data, so not too much of a change, BUT .....
I ran stait into the double wammy of 9 bit literals and Zicogs total useage of the 512B in it's cog. I had not thought that the ram access was from the two places. I might not be acheiving what I want, but I am learning, and it keeps me off the streets, which is never a bad thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Over on the zicog thread heater has had a sudden explosion of brilliant ideas that may well free up some space in the zicog. Space you could add more code to for the ram driver.
And if you are only using the lower 8 bits of 16 bits, hey, maybe this can work with a limited number of prop pins. In a general sense, the way dram works with "rows" then "columns" means it ought to not need as many latches.
As an aside, I'm doing some field tests now to see how long I can run a dracblade in the field. Hopefully no glitches, resets from stray cosmic rays etc!
@Toby, a week is good news. FWIW I never got a N8VEM to run more than 4 days, though that was with RF modules nearby. I think the ram was being corrupted by the RF. Propeller Dracblades work out cheaper, and cheaper means you can have more, and with more boards then you can drop the RF power down to 10mW and that means less potential for interference.
@cluso - "I have my zapper aimed at the hills from my brother-in-laws house LOL"
Hmm. That's odd. The power led just lit up on the triblade, but it isn't connected to anything...
For those waiting on some boards, they arrived today and I soldered one up just to test it works.
The new board is version 5. Changes from previous versions:
1) sockets for 3 types of 3V regulator and for 3 types of 5V regulator. Choose linear or switching.
2) leds for Tx and Rx on both ports (watch the blinkenlicht during an xmodem file transfer!)
3) Slightly smaller board
4) Better decoupling - two 0.1uF underneath the propeller right at the propeller power supply pins.
5) A couple of 22uF tantalums on the power supply at strategic points.
6) The big change - the VGA driver pins now go via the shortest path to the VGA resistors and then the VGA plug. Lines driving the ram chip and sd chip are routed some distance away. This has resulted in a much clearer screen with minimal waviness and minimal noise on the screen - a vast improvement on version 4.
$10 for one including shipping and $15 for two including shipping - PM me for other quantities.
(as an aside, see the Zicog thread for some brainstorming on making this run faster)
I was concerned about bumping this thread, the top page will start to look as though the Z80 crew are intent on world domination.
I am trying the EEPROM through 4053 switches, to see if the KBD can be made to use use those pins, after boot. There is a simularity to the "spacebar" thing cropping up in that with the reset button all goes as expected, but with raw power up there is a neg going glitch from P27 before the Prop should have got going. I was hoping for the first falling edge of the KBD clk line to switch out the EEPROM and the KBD in.
Whilst it probably has nothing to do with (my) "spacebar" probs on power ups I thought I would flag it, in case that others see simular things. Perhaps the glitches are affecting the '138 and '374s. I will try to put a long (1 second) reset hold onto my lashup to see if it is power line settling and/or the Prop doing its initial housekeeping.
EDIT
I have just seen the fatal error in this wooly thinking. The falling edge on P27, will not be on P27 if I combine the EEPROM and KBD onto P28-29. D'OH
Sync pulses next (they seem to be less glitched too)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/6/2010 10:01:25 PM GMT
New code on page 1 - managed to save about 150 longs. The wireless test setup has been running for four days now. Three dracblade boards, two with vga displays and one with no vga or keyboard (just a 20x4LCD). There is a little CP/M program written in sbasic called NET and you run this and it gives some options to talk to other boards, or discover other boards, or do file transfers. Commands are by little 4 byte messages eg #RES will reboot any boards nearby. #WHO tells a nearby board to reply with its name after a random time delay. #ALP logs into board ALPHA and #BYE disconnects. Boards only reply if they are logged in, so this means only two boards are talking at any one time.
Radio modules are from Yishi and are RS232 transceivers worth about $25 each. They sit on the serial port 2.
So new software can be sent to a board by issuing a reset, then opening a link, downloading a program, changing the autoexec program to run the new program then issuing another reset.
Now the Propeller can be reprogrammed via wireless!
More new code on page 1. Heater and Juergen are completely rewriting the zicog emulation so this new code has been ported to (and now merged with) the dracblade. Code is now the same but with #ifdef commands to select which memory driver code to use.
Wireless links now very stable - boards have been running for 10 days now. Can remotely reset boards, ask for nearby board names, log into a remote board (so can run Wordstar from 3km away), and transfer files.
I have 26 of the version 5 boards if anyone wants one (or more). $10 including postage anywhere in the world.
The parts from Futurlec finally arrived and their 45 cent 330 uH inductors worked just fine in the switching power circuits in my v4 board.
Following the 'How-to-build' PDF was pretty straightforward until I got to step 12 where it says 'Compile using the spin compiler and download'. This being my first Propeller project, that seemed a little cryptic. Luckily, I found in the PropArchive from the smarthome.viviti.com site not only the bstc.exe command-line compiler, but a batch file, "BST.bat", that took care of the compile and download auto-magically.
You might want to point that out in future versions of the 'how-to' for those of us who are still trying to assimilate all this at once. Also, the same step says to put MYNAME.TXT on the SD card, but that file isn't in the archive. Leaving it out doesn't seem to hurt anything.
Now, if I want to use the newer code you recently posted, do I just re-run the batch file subbing the new code files? And, to retain the original download, would I just swap in a new eeprom or would it require a new eeprom and an new SD card?
Thanks, Dr_A for solid, well thought out, working project!
Great to hear it is working. I'm not 100% sure about the inductors - maybe you are getting away with it because the overall current consumption is only tens of milliamps. Just check if they are getting warm.
The BST spin compiler is a bit complex and I need to rewrite that. Initially we got it working as a batch file, but it has now evolved into a proper program. The thread is here http://forums.parallax.com/showthread.php?p=755835
There is a setting you have to add as it is not in the default but you only have to do it once. I'm at work and I can't quite remember it but it is in the options and it is a check box that deletes all code that is not referenced by anything. Otherwise it won't fit.
Then what I do is put all the spin files in a new directory along with the program BST.EXE and when I double click the BST program it loads those spin files. Then double click the Main program, and then compile and download.
But I'll bet there is a bit missing here.
To go back to old versions, I tend to just create directories, copy the BST program into that directory and then the associated spin files. It is mildly messy as there are many copies of BST, but on the other hand, each directory is self contained.
MYNAME.TXT is a text file you can make with notepad, and it needs 8 characters so if you call it something with less than 8 characters then add spaces or something. But it will compile ok without it (I think). It is mainly there for networking.
You may as well get the latest spin code as it is getting smaller all the time.
I need to do a parts list for v5, but having said that, the list is almost identical to v2. There are 4 leds and a resistor array for those leds but the leds are not really needed (for the serial comms) so you could leave them out. The main parts are all the same. Which are the ones that are 'odd'?
A part named M_PORT2, by a process of elimination I guess this is the serial port so a 9-way D type (male). Also C14 in the parts list is a 2200uF electrolytic and looks like a 0.1uF decoupler on the schematic?
The parts list only shows 1 LM2575 but the circuit diagram looks like I could use 1 for +5V and one for +3.3V.
I should just check the PCB, just wondered if there was a link somewhere I'd missed.
I have just posted an updated version of my Debug 1-pin TV driver. Thought you may be interested since it uses the hub cog space for the screen buffer and the font is in the cog, so minimal footprint. It will run 80*25 (if overclocked) but it's not a full-blown VT100 and that's in the cog as well.
Don't try and load 2 copies though - if you want 2 copies you will have to copy & rename (remember it is using the hub space immediately after it loads).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks cluso, I might see if I can fire up the little TV screen I've got.
Re parts - on the website (link below) is the v5 parts list and schematic uploaded last night. Some of the caps might have changed numbers - and you can customise things if needed - eg if the input power supply is AC that has been rectified with 4 diodes then you need a bigger cap eg 2200 or 4700. But (as would be quite likely) you are using a wallwart, they have caps in them eg 4700uF in the ones I have pulled apart, so really you don't need much at all on the input. I put 470uF on the board.
There is one male D9 and one female D9.
There is one 2575 for 5V. The 3V is a 2574. But you can use one of three types of regulators for each supply. eg you could use a 7805 if you wanted as the board has the pads now. Obviously only put one type of 3V and one type of 5V regulator in. (The parts list has all 6 listed).
Comments
As of 10 minutes ago I have tested that the Prop tool sees the Propeller, that I can load the eeprom and that I can use the serial port via the max232. I love it when it all goes smoothly!
Thanks
Bob
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Before getting too disheartened about the memory changes not working, I went back to basics and re-instated the '138 and two latches ( L and M ). That worked again as expected, but as soon as I tried to shift the P8 - P11 for the '138 nothing but "Spacebar" would happen. I suspected that there might be another set of DIRAs apart from the obvious ones in the ram handling routines, but didn't find any that would affect it. Even moving P8 - P11 to P9 - P12, and readjusting the longs for masking, doesn't work. I am pretty sure that the P12 -P15 bunch are entirely free now the SD is shoved over to P20 -P23. The pins just do not come out of Hi Z, according to the hum pickup on the 'scope prob, induced by finger poking. Any thoughts ??
Perhaps I will have to go your route and start with the ram access bits, as a separate, and then build a computer onto that. It will probably be more informative.
I have left the VGA as four pins as the background (blue) wasn't happy unless it maintained the H + V blankings, various monitors reacted differently to monostable based line blankings, and I couldn't be .... to start putting on frame bits as well (my old Sanyo would work, as would a Philips but my LGs hated it). So until desperation for just one more pin .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
You always need one more pin! Look at the convolutions cluso has gone through to get one pin video and one pin keyboard.
Forget even starting the zicog code till you can write a byte to ram and read it back. That will involve code with lots of delays so you can watch the pins change one at a time. That was the way I got it working - very tedious and working right back at the bitbang level.
If pins are hi Z and shouldn't be, try disabling cogs one at a time. Forget keyboard, sd vga and serial. Just start up the propeller and get it to put a pin high, then wait a second then put it low, write one byte, read it back, then light a led if the bytes match up, and not light a led if they don't match. That way there is no potential interference from other objects.
Write one byte and read it back is 95% of the work.
Addit - a batch of version 5 boards just left the factory. I'll need to solder one up to check it works, but main difference is lots of different pads for different types of regulators. Plus the board is a little smaller, and the tracks to the VGA are shorter so I'm hoping the VGA display wont have as much interference.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/1/2010 12:33:24 PM GMT
I'll have a nose at Zicog now I am at home. I have found 8 EDO DRAMs from an old PCI VGA card which look, on paper, as though they will suffer address and data being paralleled, so possibly no latches. They are 256KB x 16 (with separate /CASL and /CASH) so will do for first trials
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Fancy hiding them under a four line banner, like that.
I can only assume that I had got code blindness by then
Addit
Ahh, I start to see big problems. These routines use literals, which are ok for #$100, just, but not for #$1000. So I am starting to see why you chose P8 for the Gate. I just thought that it happened to be the next one up from the bottom 8 bits. I was hoping to get 9++ clear bits for the rows and columns and use the others up to P15 for the control bits.
And another thing, could you leave more than just one spare long available !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/1/2010 8:28:48 PM GMT
Yes,
andn outa,#$100 ' set gate low nop ' NOP needs at least one due to 138 propogation delay or outa,#$100 ' set it high againCould only be done with pins 0-8 and because 0-7 are the data bus that only leaves pin 8. So that pin had to be the one. I'm going to go off and have a minor rant now about how we had 8 bit microprocessors in the 1970s and now in 2010 we have a 9 bit microporcessor. I want a 32 bit microprocessor *bangs fists against floor*
There, I feel better now.
It took a lot of work to get it to just fit. Heater and Cluso had made it only just fit anyway and Cluso's ram driver routine was slightly smaller than mine, so it was a matter of trying to find spare longs in the zicog code. But heater had already optimised the code (no doubt before trying the overlay solution). Finding spare longs in someone elses already optimised code is a real challenge. Though I have a feeling there might still be one oor two lurking there.
There is a solution however. In the setup defs, make it 8080 instead of Z80 code. Most of CP/M is 8080 anyway so wordstar and basic should still work. (In the end it is just BBC Basic and Z80 assembly that uses Z80 opcodes, and even then only a subset. Plus half the Z80 codes haven't even been added yet). So if the Zicog is really an 8080cog then may as well leave it as an 8080 cog. Then you save quite a few longs and you can start experimenting.
Having said that, I'd set aside the zicog cog altogether and try getting things working in spin first. Debugging spin code is much easier than pasm, and the first step I did when getting the latch ram working was to write a pure spin driver, with lots of delays and lots of 'halts' (ie repeat). I found it easier to then translate spin to pasm rather than trying to debug pasm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Thanks for all the clues
Yes I was trying desparately, last night to not just go 8080. It is the dream of the Nascom resurection, I suppose, it uses a few real Z80 op-codes that are not in the Zicog lot, yet.
Still it would be better to get this memory interest rolling along, and the worry about niceities later on, when a deeper understanding has been developed (but that all sounds like good sence, doesn't it, I want to tweek just one thing and everything to fall into place at once).
Blade2 and a separate VGA etc Prop, which I also have built might end up being the one for the Nas.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
It is entirely possible you might end up with shorter code than the dracblade latch code.
I'm only saying this because this was the only way I got it to work. I don't think it is possible to debug new ram driver code in the zicog. There are too many variables and too many unknowns. For instance, that one NOP between a read and a write. If there had been another error then it would have been impossible to even find how many NOPs it needed. You can't simulate this stuff either, and even adding halts or pauses doesn't work because it adds artifical delays.
And, like you say, it only just fits, so how does one debug with extra NOPs if it only just fits? Answer is to drop it back to 8080 to free up space. With different ram chips it is quite likely there will be a need for other NOPs and you might even have them all over the place and then delete them one at a time.
I note the comments on the zicog thread about overlays. I think I wrote that up a month or two ago - it is hidden away in the zicog thread somewhere. There are about four things you have to add for an overlay. Adding an overlay would come way after getting a memory chip working.
Can I ask which memory chip you are considering?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
If all that could be proven, then the syncronous sort could be tried.
But as Clusso said, the static ram·with pins or latches is the most definite, and probably·best route.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
That is a 40 pin chip with 16 data lines. So ? latches, or ? use more prop pins, but then you have to work out which things you don't need. You could drop the second serial port. And go for Cluso's 1 pin keyboard. And also drop vga and go for cluso's 1 pin TV.
So some tricky questions there before you even start looking at coding. Do you have an idea for a schematic?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This particular chip is 16 bits but has separate high and low /CASs so it could be fiddled to be 512KB x 8
I was hoping for a slightly modded DracBlade as a test bed, for the 256KB only 9 address lines would be needed, with 8 of them also for the data, so not too much of a change, BUT .....
I ran stait into the double wammy of 9 bit literals and Zicogs total useage of the 512B in it's cog. I had not thought that the ram access was from the two places. I might not be acheiving what I want, but I am learning, and it keeps me off the streets, which is never a bad thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
And if you are only using the lower 8 bits of 16 bits, hey, maybe this can work with a limited number of prop pins. In a general sense, the way dram works with "rows" then "columns" means it ought to not need as many latches.
As an aside, I'm doing some field tests now to see how long I can run a dracblade in the field. Hopefully no glitches, resets from stray cosmic rays etc!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/4/2010 9:53:34 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Whilst not a rugged test, I left my baby Drac running for over a week, accidently. It was there blinking it's little cursor, patiently.
( a bit like my pc whilst I am trying PASM )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
@cluso - "I have my zapper aimed at the hills from my brother-in-laws house LOL"
Hmm. That's odd. The power led just lit up on the triblade, but it isn't connected to anything...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The new board is version 5. Changes from previous versions:
1) sockets for 3 types of 3V regulator and for 3 types of 5V regulator. Choose linear or switching.
2) leds for Tx and Rx on both ports (watch the blinkenlicht during an xmodem file transfer!)
3) Slightly smaller board
4) Better decoupling - two 0.1uF underneath the propeller right at the propeller power supply pins.
5) A couple of 22uF tantalums on the power supply at strategic points.
6) The big change - the VGA driver pins now go via the shortest path to the VGA resistors and then the VGA plug. Lines driving the ram chip and sd chip are routed some distance away. This has resulted in a much clearer screen with minimal waviness and minimal noise on the screen - a vast improvement on version 4.
$10 for one including shipping and $15 for two including shipping - PM me for other quantities.
(as an aside, see the Zicog thread for some brainstorming on making this run faster)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I am trying the EEPROM through 4053 switches, to see if the KBD can be made to use use those pins, after boot. There is a simularity to the "spacebar" thing cropping up in that with the reset button all goes as expected, but with raw power up there is a neg going glitch from P27 before the Prop should have got going. I was hoping for the first falling edge of the KBD clk line to switch out the EEPROM and the KBD in.
Whilst it probably has nothing to do with (my) "spacebar" probs on power ups I thought I would flag it, in case that others see simular things. Perhaps the glitches are affecting the '138 and '374s. I will try to put a long (1 second) reset hold onto my lashup to see if it is power line settling and/or the Prop doing its initial housekeeping.
EDIT
I have just seen the fatal error in this wooly thinking. The falling edge on P27, will not be on P27 if I combine the EEPROM and KBD onto P28-29. D'OH
Sync pulses next (they seem to be less glitched too)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/6/2010 10:01:25 PM GMT
Radio modules are from Yishi and are RS232 transceivers worth about $25 each. They sit on the serial port 2.
So new software can be sent to a board by issuing a reset, then opening a link, downloading a program, changing the autoexec program to run the new program then issuing another reset.
Now the Propeller can be reprogrammed via wireless!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Wireless links now very stable - boards have been running for 10 days now. Can remotely reset boards, ask for nearby board names, log into a remote board (so can run Wordstar from 3km away), and transfer files.
I have 26 of the version 5 boards if anyone wants one (or more). $10 including postage anywhere in the world.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The parts from Futurlec finally arrived and their 45 cent 330 uH inductors worked just fine in the switching power circuits in my v4 board.
Following the 'How-to-build' PDF was pretty straightforward until I got to step 12 where it says 'Compile using the spin compiler and download'. This being my first Propeller project, that seemed a little cryptic. Luckily, I found in the PropArchive from the smarthome.viviti.com site not only the bstc.exe command-line compiler, but a batch file, "BST.bat", that took care of the compile and download auto-magically.
You might want to point that out in future versions of the 'how-to' for those of us who are still trying to assimilate all this at once. Also, the same step says to put MYNAME.TXT on the SD card, but that file isn't in the archive. Leaving it out doesn't seem to hurt anything.
Now, if I want to use the newer code you recently posted, do I just re-run the batch file subbing the new code files? And, to retain the original download, would I just swap in a new eeprom or would it require a new eeprom and an new SD card?
Thanks, Dr_A for solid, well thought out, working project!
The BST spin compiler is a bit complex and I need to rewrite that. Initially we got it working as a batch file, but it has now evolved into a proper program. The thread is here http://forums.parallax.com/showthread.php?p=755835
There is a setting you have to add as it is not in the default but you only have to do it once. I'm at work and I can't quite remember it but it is in the options and it is a check box that deletes all code that is not referenced by anything. Otherwise it won't fit.
Then what I do is put all the spin files in a new directory along with the program BST.EXE and when I double click the BST program it loads those spin files. Then double click the Main program, and then compile and download.
But I'll bet there is a bit missing here.
To go back to old versions, I tend to just create directories, copy the BST program into that directory and then the associated spin files. It is mildly messy as there are many copies of BST, but on the other hand, each directory is self contained.
MYNAME.TXT is a text file you can make with notepad, and it needs 8 characters so if you call it something with less than 8 characters then add spaces or something. But it will compile ok without it (I think). It is mainly there for networking.
You may as well get the latest spin code as it is getting smaller all the time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The parts list only shows 1 LM2575 but the circuit diagram looks like I could use 1 for +5V and one for +3.3V.
I should just check the PCB, just wondered if there was a link somewhere I'd missed.
Don't try and load 2 copies though - if you want 2 copies you will have to copy & rename (remember it is using the hub space immediately after it loads).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Re parts - on the website (link below) is the v5 parts list and schematic uploaded last night. Some of the caps might have changed numbers - and you can customise things if needed - eg if the input power supply is AC that has been rectified with 4 diodes then you need a bigger cap eg 2200 or 4700. But (as would be quite likely) you are using a wallwart, they have caps in them eg 4700uF in the ones I have pulled apart, so really you don't need much at all on the input. I put 470uF on the board.
There is one male D9 and one female D9.
There is one 2575 for 5V. The 3V is a 2574. But you can use one of three types of regulators for each supply. eg you could use a 7805 if you wanted as the board has the pads now. Obviously only put one type of 3V and one type of 5V regulator in. (The parts list has all 6 listed).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller