mikediv said...
no matter what I do BST will not find the board????? Am I onto something or does BST need the other support chips to work with this board. if thats not the case can anyone figure out why BST would not work but the prop tool would wor just fine???
When you first press F7 on the Propeller Tool, and it has never seen a Propeller on your system before it will progressively hit every serial port that it thinks might have a propeller connected to it to try to detect it. bst does not do this. You will get a little dialog box saying that it's can't find the prop, and would you like to locate it (yes or no). If you press yes, it will take you to the port configuration box. The easy way is to click "Find Prop" and it will buzz through all the ports it knows about to try and locate the propeller (same way Propeller tool does), *or* you can select the port manually and click "Test" to see if it can talk to the Propeller you are telling it is on the end of that particular wire.
Either way, at some point it will communicate with the Propeller and you can close the box.
There are a number of reasons bst does it this way.
Firstly, it's not polite to just bang on serial ports without asking. Unix systems often have all sorts of goodies hanging off them, and you may not want to go shoving a Propeller LFSR sequence down the pipe of your Braille terminal.
Second, bst has the ability to assign a different propeller to each editor tab (and save this information in the project file), so you can develop multi-prop applications and when you press F10 on any particular tab, bst knows which Prop to send it to.
Thirdly, there can be some very bizarre serial port configurations on POSIX compatible systems, so you need the ability to ferret around for ports bst might not know about by default.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
@ mike, yes another one that gets me every time I code is when I have the proptool already using the serial port. Or a terminal program etc. So make sure other programs are shut down before trying BST.
Re BST let't take a typical object - eg the attached one which is the keyboard object. How much would it take to convert that to relocatable cog DAT code that you could put in a seperate file on an SD card. (For the moment, leave all the spin code as-is and just considering PASM)
There are the VAR statements at the beginning - would they go in the cog code or stay as they are? Would you add the locations of the buffers to the Start list? And what would be the best way to get data out of buffers if those are now internal in a cog?
@cluso - yes good point re moving the thread - I'll follow it along on the zicog thread.
Dr_Acula said...
Re BST let't take a typical object - eg the attached one which is the keyboard object. How much would it take to convert that to relocatable cog DAT code that you could put in a seperate file on an SD card. (For the moment, leave all the spin code as-is and just considering PASM)
There are the VAR statements at the beginning - would they go in the cog code or stay as they are? Would you add the locations of the buffers to the Start list? And what would be the best way to get data out of buffers if those are now internal in a cog?
No changes to that object really. Just compile the DAT section separately (or use bstc -c to dump it as a raw data block you can load from SD) and modify the startx routine to load the cog data from SD, and cognew() the same way it does now, but pointing to your temporary buffer. When the cog is loaded and running you can re-use the buffer for something else.
To test, comment out *all* the DAT block, and remove the cognew call. It still compiles.
This is an example of a nicely put together DAT section. All parameters are passed using the PAR block and some shared variables in VAR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Thanks guys, Thank you Brad I do know about the dialog box awesome program by the way and very cool you shared it with us.
Seems Dam Vista was my problem on my laptop Vista 64 bit even when you close down the prop tool if you look at processes running its still in there holding onto the com port
so for some reason I have to go in manually end process go figure ,, still does not change the fact that my stripped down DR_A board ran all night blinking LEDs but as soon as I installed all the support chips it ran CPM for a minute or 2 then space bar error ,, DR_A I can not thank you enough sir I can't wait to get going with CPM
Oh Dr_A the static Ram chip you use for the Drac baord is 512K X 8 is that why after config for 32 bit its only sees it as ·64K it is being used as 32 bits rght?
Re some programs holding onto the serial port, XP does that sometimes too. CTRL/ALT/DEL is your friend!
The ram chip is 512k and only 64k is used for CP/M. The rest is for future use. Paged memory for MP/M. You can peek and poke to the entire 512k using some little routines I just wrote a few days ago. You could use it as a ram drive. I don't think we have fully explored the options but it is nice to have *more* memory than you actually need. At least for the moment.
I'm running into a couple problems assembling the v4 board, especially with some of the overlapping silkscreening. Is there a schematic and parts list available? The ones linked on www.smarthome.viviti.com/propeller are for v2 and it looks like a few parts changed since then.
With the VGA connector facing you, the second resistor to the right of the 3V and 5V LEDs is the biggest problem - is that R16 with a value of 1K? And, the rest of the resistors to the right of that are all 10K? I'm hoping most of the parts still follow the v2 exported parts list from 11/30/2009.
This isn't a burning issue, futurlec.com is still looking for an elephant to load with some of my parts for this and I have to be at work with the big grey swimming beasts next week.
Sure, if you go to page 1 of this thread, first post at the bottom of that is a link to the build instructions for version 4. It is a .zip file that contains a .pdf and this has a series of photos including a number of closeup photos so you can see the resistor colors etc. Let me know if any problems. (Looking at the photo the second resistor to the right of the leds is 1k)
I've just added a patch release to the first post in the Catalina thread which adds XMM support for the DracBlade. It is probably not optimal in terms of speed, but it is fully functional.
As a demo, I have attached (to this post) a compiled version of the game 'Super Star Trek'. This program weighs in at 350Kb, and must be loaded from the SD card. I have therefore also included the Catalina Generic Program Loader that you will need to load it (which you can load using the normal Parallax Propeller tool).
See the README.TXT for more details.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Well that is truly amazing. A 350k program running on a Propeller. And it works perfectly - the StarTrek game is great fun. "We come in peace, shoot to kill etc"
Hi everyone I tried connecting the 3.3 version of ucam from 4D system to a propeller, however I cant even get it to send an acknowledge signal I posted my code below
My crystal is 8Mhz, baud rate = 115_200kbps, mcu frequency = 64Mhz, language = spin, debugging using the usb propeller plug connected to the computer and propeller serial terminal.
the code:
con
_clkmode = xtal1 + pll8x
_xinfreq = 8_000_000
ok = 2
fail = -1
var
byte sync_send[noparse][[/noparse]6]
byte sync_ack[noparse][[/noparse]6]
instead my computer screen just writes failed synchronization everytime
since the tabs are not so easy to see i have attached the code and serial driver that I am using. I would greatly appreciate if anyone could let me know what I am missing out
However, when I replicate this code in CP/M in Basic it does not initialise. As far as I can tell, the actual output is identical as it is coming out of a standard RS232 plug, and when I sniff it with a terminal program the bytes are identical from the prop vs vb.net. I'm running 14400 baud.
The only thing I can think of is that the PC is running a proper uart and that uart is crystal controlled. The propeller's uarts are software, and I suspect the uCam's might be too. So if there were some subtle differences in timing maybe that could be the problem. I was testing on a day that was 44C.
There is a 555 reset circuit in there as well which makes it easier than pulling the power plug all the time.
So maybe drop back to a slower baud rate for starters.
Didn't you mutter something about the VGA resistors being the other way around, from the demoboard. I seem to remember something about the Briel VDU being involved.
The reason I am asking is that in an effort to clear off one side of the Prop, I have been messing with the VGA pins etc. I tried to take the pin count down to 4 ie H,V, bacground and forground. Obviously this will be for text based output. Whilst doing this I noticed that the foreground is on the 470 Ohm and the background was on the 270 (240 ish). Green on black only uses 3. All this seems to leave the unused pins inactive and so next thing is to shift the SD over to 20-23. Then there is the possibilities of combined H+V on one pin, but that would be an extra chip...
Perhaps Clusso will get all the SD, EEPROM, MOUSE, KBD, and VGA all on the same pin, eventually. I was wondering about analog gates to allow the EEPROM to do its stuff, at reset, and then dissapear for the KBD etc....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Re saving pins, sure, there would be more to save if just using one color gun. I keep being indecisive between green on black, orange on black, white on blue and yellow on blue.
Sure, there would be ways to save more pins. What are you planning?
It's a learning by butchery course. You lot went off and produced Zicog, Blade1,2,3 ,Dracblade and I was trying to hold some understanding. So I thought that If I try and reorganize everything I might see the reasoning and quirks that made the originals. From the demos for VGA on PropBASIC I saw that the bits for the VGA generation were more obvious than I thought (probably they are not!) so I took it back to syncs and two others, being a bit kinder on the eye than coloured on black. I have at the present Cyan on blue by cross coupling the jumpers on my "lunchbox" demoboard. At 30mA per pin, two colours are no problem, but three for white, would be pushing the spec a bit ( as if we would).
Putting the SD onto the free "VGA" pins and changing the SD allocation pins on the front CON didn't work, so there must be other definitions elsewhere and/or pin masks. More learning ...
The main reason for starting this was to free up a strip of pins for the SDRAM experiments. As Clusso says it may be a complete waste of effort, but it's learning. It would allow for lower latching times, within a 64KB page. A bit like the 8051/8085 way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 2/7/2010 3:11:14 PM GMT
I'm pretty sure I went through the code and reduced it all back so it all loaded from the original CON, but maybe one slipped through. Since there is no pin sharing the code is fairly simple - just one initial load setting the pins that is fairly near the start of the program. I wonder if the pins were switched or something as this should have worked.
One man's butchery is another's 'learning by experimentation'. Which ram chips are you thinking of using, and how many pins do they need?
I've been using a number of boards every day for several weeks and occasionally a corrupted byte ends up on the sd card. The manifestation of this is it dumps out the registers, then a list of bytes and then the word "Unimplemented" and hangs.
I had similar problems with the triblade so I think it is an sd card issue. It has similarities to problems I had back in the mid 1980s with real disks occasionally getting corrupted bytes. Back then I think it was related to turning off the computer while still writing to disk, and even though the dracblade disables the sd card after 3 seconds of inactivity, I think this is a similar problem.
The problem can't be fixed by copying a new drive image (either BOOT.DSK or A.DSK). The only solution is to reformat the sd card and copy the disk image files over again. Even then I'm having issues with a USB2.0 card reader and finding only a USB1.0 is totally reliable.
Oh, and if you do reformat, make sure it is Fat16 and not the default Fat32. That one manitfests itself as the sd card not being readable at all, so you will get "Zicog with Dracblade" then "Err - Halt".
I've added a message so if it does crash in that way the message on the screen is a reminder about the FAT16
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer
r := sd.start(@ioControl) 'start the SD routines
CheckError(not r)
PrintStringCR(string("Mount FAT16 SD with .DSK files")) ' reminder about FAT16
r := \sd.mount(spiDO,spiClk,spiDI,spiCS) 'mount the SD
So - make backups regularly (as you always would anyway).
Meanwhile, I'm pushing the limits of the system with wireless networks. I've finally learn't enough about this to be able to articulate what the propeller can do that so many chips/boards can't do, and that is the ability to listen to several serial ports at once and also to buffer input in a decent sized buffer. This simply isn't possible with a real uart and a real Z80.
I've run out of boards but the next batch will be available soon. Mind you, Bill Henning is getting close to an even better solution using half the number of chips and a cache memory so watch this space!
Ah, writing to an unimplemented port might not be as bad as you think. The latch driver code is in a cog, and that gives a different error (I think it is the spacebar error). The unimplemented port error might imply it is actually booting up into CP/M and then doing an OUT. So more might be working than you think. Have a look through the port driver code in the Main spin routine. It captures the port number and then goes off and processes each one (0-255) and there is a catchall at the end if it doesn't find one and that gives the error you are seeing. You could add in a line of spin to print the actual port number. Then go back into CP/M and find a match for that one.
Though for building a new ram driver, I ended up not trying to run CP/M at all, but rather to run some very basic spin routines that write to a memory location, read it back and print the value.
When it was working in Spin, I transferred it to the pasm ram cog driver. Then when that was working, I copied that code into the zicog.
Ok, perhaps it's worth trying some more work. I was just trying to prove that the starting point was sound, and then bend it. When the error came up I wasn't too surprised, as the breadboard and all its feed wires underneath·and jumpers above, there is about a foot of wire.
I will be putting Iron to PCB this weekend to minimise thes problems. I had made the "speadout board" for this purpose but now I dont have the heart to start chopping it up!
With 3/4 wires for "VGA" and the analog switches on the EEPROM (etc) lines a lot of pin savings can be made,·more as·a self teaching aide, for me.
EDIT
Looking at my own picture I think I can see the problem(s). It shows that you can be too close to see the trees. Perhaps it will be my birthday after all. All I have to do now is wait 8 hours to get home
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 2/18/2010 9:56:04 AM GMT
Ok, so what are you doing - accessing a different type of ram chip? How many pins, what sort of chip, is there a schematic??
Sounds very exciting.
>I know I have asked this before but, your name, it is a joke, Isn't it ????
It is one of the characters used to confuse and obfuscate nigerian scammers www.scamorama.com/Smile_bloodbank.html A bit of a silly pasttime, though wasting their time means that maybe they have less time to scam gullible people. Dr Acula stars in a chapter in the book at the right side of the scamorama website www.scamorama.com/
Thats what I mean. The heavily modified demoboard cct feeding bunched up wires, feeding the breadboard's end strips, feeding the links, feeding the links ....
and then it lives, it's just not nateral.
The cct is, at present just a bog standard 2 latch DracBlade. Now the system has, somehow, proven itself I will start modifying it. I had tried to start from a moremodified start but then, when it didn't work I wasn't sure which bit was throwing a strop.
off to work now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Well you are one step ahead of me. I need to confess I never breadboarded the design. Darn lucky it worked!
Ok, if you have a breadboard design, what next? Pop in a different ram chip and start experimenting with some simple spin code to write one byte and read it back. I found once that was working that was about 90% of the work. As an aside, I'm intrigued by the concept of slow SPI ram and a cache in the propeller, and I very much suspect that the lack of postings over the last week on that topic is because some nifty coding work is being done.
I also think there are a number of ram chips that can do the job. I'm still pondering applications using drams. Toby, what is the ram chip you are going to use?
Still at work so the chip types are not known. They are to be a rag-tag bunch that have been pulled. If the system comes good then a current type would have to be found.
I was hoping that the latches would be internal but the CAS seems to have to be left up. Pre FPM drams would have been the best.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 2/19/2010 7:36:54 PM GMT
Dr_A sent me two of his V3 boards. I'm about able to find the correct side of the soldering iron, so please bear with me ...
I have ordered most of the components, but have trouble locating the LM2574HVN-3.3 regulator. What could I use in its place, if possible just drop into the socket meant for the original chip.
I have just finished assembling my V3 DracBlade. I used a LM2574N-3.3G from Mouser. I just looked and they have plenty in stock.
SO far I have only tested the switching supplies and both are working fine.
The 8 pin 3V switcher came from Futurlec, and they have very good prices. But shipping times in weeks and I imagine you want to get this working now! Fastest solution might be an external power supply. Next option might be a 5 pin simple switcher from the same family.
Good to hear Mouser have the 8 pin ones. More recent versions of the boards have sockets for three types of 3V regs and three types of 5V regs so that adds more flexibility.
Ok, after the switchers are working, next step might be the propeller and eeprom and max232 and see if you can find the propeller chip from the propeller tool program.
Comments
When you first press F7 on the Propeller Tool, and it has never seen a Propeller on your system before it will progressively hit every serial port that it thinks might have a propeller connected to it to try to detect it. bst does not do this. You will get a little dialog box saying that it's can't find the prop, and would you like to locate it (yes or no). If you press yes, it will take you to the port configuration box. The easy way is to click "Find Prop" and it will buzz through all the ports it knows about to try and locate the propeller (same way Propeller tool does), *or* you can select the port manually and click "Test" to see if it can talk to the Propeller you are telling it is on the end of that particular wire.
Either way, at some point it will communicate with the Propeller and you can close the box.
There are a number of reasons bst does it this way.
Firstly, it's not polite to just bang on serial ports without asking. Unix systems often have all sorts of goodies hanging off them, and you may not want to go shoving a Propeller LFSR sequence down the pipe of your Braille terminal.
Second, bst has the ability to assign a different propeller to each editor tab (and save this information in the project file), so you can develop multi-prop applications and when you press F10 on any particular tab, bst knows which Prop to send it to.
Thirdly, there can be some very bizarre serial port configurations on POSIX compatible systems, so you need the ability to ferret around for ports bst might not know about by default.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Re BST let't take a typical object - eg the attached one which is the keyboard object. How much would it take to convert that to relocatable cog DAT code that you could put in a seperate file on an SD card. (For the moment, leave all the spin code as-is and just considering PASM)
There are the VAR statements at the beginning - would they go in the cog code or stay as they are? Would you add the locations of the buffers to the Start list? And what would be the best way to get data out of buffers if those are now internal in a cog?
@cluso - yes good point re moving the thread - I'll follow it along on the zicog thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
No changes to that object really. Just compile the DAT section separately (or use bstc -c to dump it as a raw data block you can load from SD) and modify the startx routine to load the cog data from SD, and cognew() the same way it does now, but pointing to your temporary buffer. When the cog is loaded and running you can re-use the buffer for something else.
To test, comment out *all* the DAT block, and remove the cognew call. It still compiles.
This is an example of a nicely put together DAT section. All parameters are passed using the PAR block and some shared variables in VAR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Seems Dam Vista was my problem on my laptop Vista 64 bit even when you close down the prop tool if you look at processes running its still in there holding onto the com port
so for some reason I have to go in manually end process go figure ,, still does not change the fact that my stripped down DR_A board ran all night blinking LEDs but as soon as I installed all the support chips it ran CPM for a minute or 2 then space bar error ,, DR_A I can not thank you enough sir I can't wait to get going with CPM
Oh Dr_A the static Ram chip you use for the Drac baord is 512K X 8 is that why after config for 32 bit its only sees it as ·64K it is being used as 32 bits rght?
Post Edited (mikediv) : 2/1/2010 7:40:35 PM GMT
The ram chip is 512k and only 64k is used for CP/M. The rest is for future use. Paged memory for MP/M. You can peek and poke to the entire 512k using some little routines I just wrote a few days ago. You could use it as a ram drive. I don't think we have fully explored the options but it is nice to have *more* memory than you actually need. At least for the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm running into a couple problems assembling the v4 board, especially with some of the overlapping silkscreening. Is there a schematic and parts list available? The ones linked on www.smarthome.viviti.com/propeller are for v2 and it looks like a few parts changed since then.
With the VGA connector facing you, the second resistor to the right of the 3V and 5V LEDs is the biggest problem - is that R16 with a value of 1K? And, the rest of the resistors to the right of that are all 10K? I'm hoping most of the parts still follow the v2 exported parts list from 11/30/2009.
This isn't a burning issue, futurlec.com is still looking for an elephant to load with some of my parts for this and I have to be at work with the big grey swimming beasts next week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I have XMM RAM working under Catalina on the DracBlade. You can now have C programs up to 512K.
I'll put together a new target support package and post it tomorrow night.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I've just added a patch release to the first post in the Catalina thread which adds XMM support for the DracBlade. It is probably not optimal in terms of speed, but it is fully functional.
As a demo, I have attached (to this post) a compiled version of the game 'Super Star Trek'. This program weighs in at 350Kb, and must be loaded from the SD card. I have therefore also included the Catalina Generic Program Loader that you will need to load it (which you can load using the normal Parallax Propeller tool).
See the README.TXT for more details.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
My crystal is 8Mhz, baud rate = 115_200kbps, mcu frequency = 64Mhz, language = spin, debugging using the usb propeller plug connected to the computer and propeller serial terminal.
the code:
con
_clkmode = xtal1 + pll8x
_xinfreq = 8_000_000
ok = 2
fail = -1
var
byte sync_send[noparse][[/noparse]6]
byte sync_ack[noparse][[/noparse]6]
obj
ucam:"FullDuplexSerial"
com: "FullDuplexSerial"
pub main | i,j
ucam.start(8,9,0,115_200)
com.start(31,30,0,115_200)
sync_init
waitcnt(256_000_000 + cnt) ''2 seconds so that i can start my serial terminal software, not so necessary though
repeat j from 0 to 67
repeat i from 0 to 5
ucam.tx(sync_send)
if(sync_acknowledge == ok)
quit
if(sync_ack[noparse][[/noparse]0] == $AA)
repeat
com.str(string(" syncronization successfull "))
else
repeat
com.str(string(" failed syncronization "))
pri sync_init
sync_send[noparse][[/noparse]0] := $AA
sync_send := $0D
sync_send := $00
sync_send := $00
sync_send := $00
sync_send := $00
pri sync_acknowledge
if (ucam.rx == $AA)
sync_ack := ucam.rx
sync_ack := ucam.rx
sync_ack := ucam.rx
sync_ack := ucam.rx
sync_ack := ucam.rx
sync_ack[noparse][[/noparse]0] := $AA
return ok
else
return fail
instead my computer screen just writes failed synchronization everytime
since the tabs are not so easy to see i have attached the code and serial driver that I am using. I would greatly appreciate if anyone could let me know what I am missing out
Post Edited (ciamo) : 2/6/2010 4:53:19 PM GMT
What I do have is code working in vb.net - see the 4dsystems website in the forum section 4d.websitetoolbox.com/?forum=148814
However, when I replicate this code in CP/M in Basic it does not initialise. As far as I can tell, the actual output is identical as it is coming out of a standard RS232 plug, and when I sniff it with a terminal program the bytes are identical from the prop vs vb.net. I'm running 14400 baud.
The only thing I can think of is that the PC is running a proper uart and that uart is crystal controlled. The propeller's uarts are software, and I suspect the uCam's might be too. So if there were some subtle differences in timing maybe that could be the problem. I was testing on a day that was 44C.
There is a 555 reset circuit in there as well which makes it easier than pulling the power plug all the time.
So maybe drop back to a slower baud rate for starters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Way, way back at the start of tread ...
Didn't you mutter something about the VGA resistors being the other way around, from the demoboard. I seem to remember something about the Briel VDU being involved.
The reason I am asking is that in an effort to clear off one side of the Prop, I have been messing with the VGA pins etc. I tried to take the pin count down to 4 ie H,V, bacground and forground. Obviously this will be for text based output. Whilst doing this I noticed that the foreground is on the 470 Ohm and the background was on the 270 (240 ish). Green on black only uses 3. All this seems to leave the unused pins inactive and so next thing is to shift the SD over to 20-23. Then there is the possibilities of combined H+V on one pin, but that would be an extra chip...
Perhaps Clusso will get all the SD, EEPROM, MOUSE, KBD, and VGA all on the same pin, eventually. I was wondering about analog gates to allow the EEPROM to do its stuff, at reset, and then dissapear for the KBD etc....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Re saving pins, sure, there would be more to save if just using one color gun. I keep being indecisive between green on black, orange on black, white on blue and yellow on blue.
Sure, there would be ways to save more pins. What are you planning?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Putting the SD onto the free "VGA" pins and changing the SD allocation pins on the front CON didn't work, so there must be other definitions elsewhere and/or pin masks. More learning ...
The main reason for starting this was to free up a strip of pins for the SDRAM experiments. As Clusso says it may be a complete waste of effort, but it's learning. It would allow for lower latching times, within a 64KB page. A bit like the 8051/8085 way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 2/7/2010 3:11:14 PM GMT
One man's butchery is another's 'learning by experimentation'. Which ram chips are you thinking of using, and how many pins do they need?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I had similar problems with the triblade so I think it is an sd card issue. It has similarities to problems I had back in the mid 1980s with real disks occasionally getting corrupted bytes. Back then I think it was related to turning off the computer while still writing to disk, and even though the dracblade disables the sd card after 3 seconds of inactivity, I think this is a similar problem.
The problem can't be fixed by copying a new drive image (either BOOT.DSK or A.DSK). The only solution is to reformat the sd card and copy the disk image files over again. Even then I'm having issues with a USB2.0 card reader and finding only a USB1.0 is totally reliable.
Oh, and if you do reformat, make sure it is Fat16 and not the default Fat32. That one manitfests itself as the sd card not being readable at all, so you will get "Zicog with Dracblade" then "Err - Halt".
I've added a message so if it does crash in that way the message on the screen is a reminder about the FAT16
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer r := sd.start(@ioControl) 'start the SD routines CheckError(not r) PrintStringCR(string("Mount FAT16 SD with .DSK files")) ' reminder about FAT16 r := \sd.mount(spiDO,spiClk,spiDI,spiCS) 'mount the SDSo - make backups regularly (as you always would anyway).
Meanwhile, I'm pushing the limits of the system with wireless networks. I've finally learn't enough about this to be able to articulate what the propeller can do that so many chips/boards can't do, and that is the ability to listen to several serial ports at once and also to buffer input in a decent sized buffer. This simply isn't possible with a real uart and a real Z80.
I've run out of boards but the next batch will be available soon. Mind you, Bill Henning is getting close to an even better solution using half the number of chips and a cache memory so watch this space!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 2/14/2010 12:00:07 AM GMT
To try and bend the latching methiod, to a SDRAM sort of way, I tried to get the DracBlade (2 latches) to run on the lunchbox, to start with.
It just sits there wimpering on about " writing to an unimplimented I/O port ", I wonder why.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Though for building a new ram driver, I ended up not trying to run CP/M at all, but rather to run some very basic spin routines that write to a memory location, read it back and print the value.
When it was working in Spin, I transferred it to the pasm ram cog driver. Then when that was working, I copied that code into the zicog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 2/17/2010 11:03:07 PM GMT
I will be putting Iron to PCB this weekend to minimise thes problems. I had made the "speadout board" for this purpose but now I dont have the heart to start chopping it up!
With 3/4 wires for "VGA" and the analog switches on the EEPROM (etc) lines a lot of pin savings can be made,·more as·a self teaching aide, for me.
EDIT
Looking at my own picture I think I can see the problem(s). It shows that you can be too close to see the trees. Perhaps it will be my birthday after all. All I have to do now is wait 8 hours to get home
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 2/18/2010 9:56:04 AM GMT
It lives, it lives!
That birds nest of an attempt does run DracBlade CP/M !!!!!! It was me and the other eight missing links.
Now I am worried that it is still alive whilst all the laws of nature say that it shouldn't be.
I know I have asked this before but, your name, it is a joke, Isn't it ????
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Ok, so what are you doing - accessing a different type of ram chip? How many pins, what sort of chip, is there a schematic??
Sounds very exciting.
>I know I have asked this before but, your name, it is a joke, Isn't it ????
It is one of the characters used to confuse and obfuscate nigerian scammers www.scamorama.com/Smile_bloodbank.html A bit of a silly pasttime, though wasting their time means that maybe they have less time to scam gullible people. Dr Acula stars in a chapter in the book at the right side of the scamorama website www.scamorama.com/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
and then it lives, it's just not nateral.
The cct is, at present just a bog standard 2 latch DracBlade. Now the system has, somehow, proven itself I will start modifying it. I had tried to start from a moremodified start but then, when it didn't work I wasn't sure which bit was throwing a strop.
off to work now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Ok, if you have a breadboard design, what next? Pop in a different ram chip and start experimenting with some simple spin code to write one byte and read it back. I found once that was working that was about 90% of the work. As an aside, I'm intrigued by the concept of slow SPI ram and a cache in the propeller, and I very much suspect that the lack of postings over the last week on that topic is because some nifty coding work is being done.
I also think there are a number of ram chips that can do the job. I'm still pondering applications using drams. Toby, what is the ram chip you are going to use?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I was hoping that the latches would be internal but the CAS seems to have to be left up. Pre FPM drams would have been the best.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 2/19/2010 7:36:54 PM GMT
Dr_A sent me two of his V3 boards. I'm about able to find the correct side of the soldering iron, so please bear with me ...
I have ordered most of the components, but have trouble locating the LM2574HVN-3.3 regulator. What could I use in its place, if possible just drop into the socket meant for the original chip.
Thanks
Robert
I have just finished assembling my V3 DracBlade. I used a LM2574N-3.3G from Mouser. I just looked and they have plenty in stock.
SO far I have only tested the switching supplies and both are working fine.
Bob
Good to hear Mouser have the 8 pin ones. More recent versions of the boards have sockets for three types of 3V regs and three types of 5V regs so that adds more flexibility.
Ok, after the switchers are working, next step might be the propeller and eeprom and max232 and see if you can find the propeller chip from the propeller tool program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller