Drac: Just looked quickly at your code and have a few quick questions...
Nice way of naming your boards. You could then use this name to open a file "alpha.cfg" for pcb "alpha" to get configuration options, such as VGA, serial, baudrate, etc. You could even use this method to name the cpm disk files used.
The GetMyName I/O port concept has great possibilities also, such as reading/writing to FAT16 files.
You will require my driver addition "S"et command. It is a fill command for sram (lucky I did not use "F"!). You pass it one byte in the buffer (just like a read/write) and it will fill sram with that value for the length specified. Very quick for clearing memory, and later for setting $E5's for a ramdisk.
BTW, for the SD drive LED, you could have just connected the led to the -CS pin on the SD card. You should at least disable the card when not in use to save power and also to ensure nothing spurious can happen in power up/down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
S sounds good. Though I've never been a huge fan of ram drives ever since I excitedly installed one on my brand new '386 in the early 1990s and then promptly kept forgetting to save before turning off.
re "BTW, for the SD drive LED, you could have just connected the led to the -CS pin on the SD card." Yes, I guess so but every time I change something with the wiring of the sd card it stops working. The DO not having a pullup should not make a difference. But it does. In any case, we have moved on...
re "You should at least disable the card when not in use to save power and also to ensure nothing spurious can happen in power up/down."
That is a good question Cluso. A very good question!
Ok, here is the problem. If you enable/disable the sd card for every 128 byte packet (or ok, 512 byte packet) it slows down the emulation. What I give up in speed by having to latch the address lines every memory access (that the ramblade can do in one go), I make up for with faster sd card access as the sd card pins are not used for anything else.
BUT, as you say, not good leaving the sd card running all the time - both for power consumption reasons and in case the card is removed.
Well, I had a cunning brainwave, and it all came from a circuit my father designed for our very first computer ( A CP/M computer, of course) which was hand built but it had a design flaw in that it left the disk drives going round and round even when the system was not doing anything. My dad designed a little timeout circuit that turned the drives off after 30 seconds or so.
So - I wondered if such a thing could be done in software. We have a timer, in the form of cnt. We can check it periodically when service_io is called.
The logic is that whenever the sd card is accessed it sets a flag. When the counter ticks over zero (or thereabouts) it resets the flag. The timing is perfect for cnt as it is about every 30 secs or so. If the sd card has been switched off then turn it back on, but if it is still on then no need to re-initialise.
I've added the led in so the led gives a visual indication the drives are still "turning". The led also flickers when data is being transferred, so it does double duty (and hence is smarter than just being connected to the /CS line).
An awful lot of code has changed, but I'm pretty sure the .stop is actually stopping the sd card. It ends up running this code in sdspifemto.spin
spiDoStop
andn dira,spiMaskCS ' This is used for the situation
mov spiMaskCS,#0 ' where the pins used for the SD
andn dira,spiMaskDI ' card may be used for some other
mov spiMaskDI,#0 ' purpose when the card is removed
andn dira,spiMaskClk
mov spiMaskClk,#0
andn dira,spiMaskDO
mov spiMaskDO,#0
jmp #i2cGoUpdate
The timeout function is a bit crude. I could have a counter and then it would timeout after a fixed delay. But I ran into problems testing values (I'm still learning spin), as a value I was reading as hex $FFFFFFFF is coming up as a negative value for the purposes of subtraction and IF tests. This is the code, warts and all:
PUB SDTimeout | r ' uses SDRunning = 0 if not running, anything else = running
if SDRunning > 0 ' speeds things up if only test this and return if 0
if cnt > $0000000 AND cnt < $04000000
'vgatext.str(string("SD card stopped "))
'vgatext.hex(sdrunning,2)
'vgatext.str(string(" "))
'vgatext.hex(cnt,8)
SDRunning:=0
RamLatches.DoCmd("F",0,0,0) ' led off
r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running)
CheckError(r)
There are some other changes, particularly in the
PRI refresh_hd_cache
and
PRI in_hdskport_write
It all seems to be working fine. Code is attached. Maybe it could end up in the sd driver itself? Maybe the concept could be extented to blank the vga display as a screensaver?
It will be interesting to see the speed of the 3 pcbs. Since the RamBlade uses less code for sram access, I can inline the instruction fetch access saving the call/ret and increment instructions. Maybe I can extend this elsewhere - need to look.
I am unsure how much extra overhead will be added by deselecting the card. Certainly in the old fsrw it was huge because of the patch I installed. The new fsrw seems much faster. I see you are still using the old fsrw driver.
I see how you are reading the input ports using "on_input" and also GetName using "on_output" and placing the text in dma buff + $80. So we could add a port to get the prop "CNT" value, or indeed a date/time (using another cog to count it). We would only have to set the date/time on ZiCog startup. I noticed CPM3 asks for the date on bootup.
I saw the IM register has a seperate declaration, but didn't I see that it was the same as another register somewhere else??? or am I getting confused??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Got my board the other day and started to gather all the parts Doc on my board facing components above prop chip upper left it has a row of pins and says "F term Dowl "? what goes in those holes? does anyone have a finished board they can take a picture of showing all the components, thanks
@Cluso, I could write pages on FFFFFFFF. I find signed bit numbering systems quite confusing when it comes to working out differences. I'm an 8 bit chap, so FF is -1. Wait, no I'm not, I like 16 bits, so FFFF is -1. Hang on, FFFFFFFF is -1. How can three values be equal to -1? Is FF the same as 00FF or 000000FF? What is FF/2, is it 127.5, or is it -0.5. How about FFFFFFFF/2 I'm still trying to work this out, but I think when it comes to working out differences (eg with timers) there is a rollover at zero, and another rollover when the sign changes and I think you have to handle both. I'm sure there is a cunning Spin line of code that uses the counter to say 'if something hasn't happened for a while then reset a flag'.
I'll see if I can get the new fsrw code working - do you have a link to the code you are using?
Mikediv, that component is a D9 socket (female). There is a photo herewww.smarthome.viviti.com/propeller It is a bit tedious getting all the bits together and it would be frustrating if you got the wrong parts. Where are you going to be buying the parts?
Gee Dr_A I would love to get them from one place but I really don't know I use Jemco and Digikey a lot I also use Mouser do you recommend anyplace.. Some of the stuff VGA connector DB9 I can salvage from left over boards , I have resistors and caps, I will need to order chips
and sockets.
I bought a lot of MK380IN-06 I thought they were Z80 chips but now I am not sure they might just be some kind of 40 pin Z80 I/o peripheral .
All three of those suppliers should have a right angle D9, and, indeed, most of the other parts.
Re the D9, there are 4 wires that go into that socket - Tx, Rx, Gnd and the reset line, and those are the 4 lines for a prop plug. I use a serial connection directly into my PC as my PC is a bit older and has a real serial port. But if you have a prop plug, maybe there is another way to do this. Or you could just use a D9 female, then get a solder D9 male and make up an adaptor to go onto the prop plug?
The latest code I posted has it included (either TriBlade or ZiCog - IIRC version _rr137)
re the -1 issue, I always have to get my head around this when doing maths. If you look at it this way, taking 1 away from 0000 results in a ripple effect of the borrow. So if there are 8 bits the answer will be $FF, 16 gives $FFFF, 32 gives $FFFFFFFF. Take another 1 away and you get $....FE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm working on some background reading of the second serial port - with a view to only passing things through to CP/M if a data packet is for that particular board. I'm hoping this can lead to some networking protocols (which needn't just pass to CP/M - it could pass to propdos or anything really).
I'm getting stuck with some basic String syntax in Spin. Specifically, I seem to be able to send fixed values to strings but not variables. This little array feeds things in from the right and shuffles them to the left (thanks Sam for pointing that out!).
I can print the ascii values of characters but not the actual character.
I did have an idea of printing out an array that was zero terminated but I don't seem to be able to get the syntax right for that (lots of brackets and an @ maybe but I'm not getting them right)
So I had an idea of printing them out one at a time but the characters won't print - only their ascii values. Not that it hugely matters but it would be nice for debugging to print the characters themselves. I've commented what is working and what is not.
PUB Port1 | j,c
' byte Port1Buffer[noparse][[/noparse]16] ' data coming in from port1
' read port1 bytes into a small buffer
' if the buffer is 16 bytes (0-15) feed in from 15 and shuffle them all down one
' then can pattern match if know the length of the string to match
' and match from 15 backwards (if don't do this then the bytes are backwards)
if UART.rxavail(1)
vgatext.str(string("Port 1 Buffer equals:"))
c:=UART.rxcheck(1) ' get the byte in c
j:=0
repeat 15 ' n-1
Port1Buffer[noparse][[/noparse]j]:=Port1Buffer[noparse][[/noparse]j+1] ' shuffle all to the left
j++ ' add 1
Port1Buffer[noparse][[/noparse]15]:=c ' new character into 15
Port1Buffer[noparse][[/noparse]16]:=0 ' so strings display - zero terminator
j:=0
repeat 16 ' just display the characters not the 0 terminator
c:=Port1Buffer[noparse][[/noparse]j] ' can't seem to print an array directly
vgatext.str(string(c)) ' this won't print anything
vgatext.dec(c) ' this prints the correct value for c
vgatext.str(string(103)) ' this prints 'g' as expected
c:=103 ' set c to 103
vgatext.str(string(c)) ' this doesn't print 'g'
j++
vgatext.str(string(13,10)) ' this prints carriage return/linefeed
I'm sure this is just a syntax thing. Help would be most appreciated.
repeat j from 0 to 15
vgatext.out(Port1Buffer[noparse][[/noparse]j])
vgatext.str(string(13,10))
Also, vgatext.str(string(c)) is actually invalid as far as the prop tool is concerned, bst seems to let it pass but I don't know for sure what its meaning is.
Thanks kuroneko. The .out works brilliantly. And saved quite a few longs too. Good point too re invalid syntax not being flagged by the compiler.
I've now got a nice little buffer that prints text in the right order.
Next little job - I need some countdown timers. Maybe someone has already done these, but the code is a little different to the delay routines.
Ok, the propeller counter cycles about every 53 seconds. CP/Ms conin and other routines mean you can check the counter a lot more often than that. So, it ought to be possible to check the cnt at random times, and count down a clock until it reaches zero.
I've got three uses for this:
1) for a delay turnoff for the sd card
2) a delay to buffer radio output and send on a packet if no bytes have arrived for a while
3) possibly a screen saver
So, various routines might set the countdown timer (or keep resetting it). I'm doing this in milliseconds, and I think two variables are needed - the old cnt value, and also the countdown timer itself.
So to start a countdown timer,
CountDown1:=5000 ' set to 5 seconds
StartCountdown1 ' start the timer
...
PUB StartCountDown1 ' uses OldClock1. Pass CountDown1 = number of milliseconds
OldClock1:=cnt
and at random times check the timer and subtract the appropriate value.
PUB CheckCountdown1
if Countdown1<>0
Countdown1:=Countdown1-((cnt-OldClock1)/(clkfreq/1000)) ' subtract milliseconds since last check
OldClock1:=cnt ' store the current clock counter for next time
if Countdown1<0
Countdown1:=0 ' for quick tests only run the countdown if CountDown1 <>0
vgatext.dec(Countdown1) ' for debugging
I'm testing it with this code below and starting with 5000 and it returns 4000 and 2000 as expected.Occasionally it is out by 1 but it seems very repeatable and accurate.
Countdown1:=5000 ' milliseconds
StartCountDown1
delay.pause1s(1) ' 1 second delay
CheckCountdown1
delay.pause1s(2) ' 2 second delay
CheckCountdown1
Drac: The new fsrw has a date/time function for updating files on the SD. I am not sure if the program counts (wrong computer). However, the long used only has 2 second resolution. I would like to add a timer with say 1ms resolution in a cog - I don't think anything tighter is required.
Now, if the above were done... You could use it for what you require AND it would be a simple matter of doing a write to port (say $71) and reading the dma buf + $80 for the value - like you did for getname.
I see you have used the clkfreq so that it is independant of the xtal. (i.e. correct time for any xtal)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Is there a package of drive images that have been zipped for the Dracblade?
I finally got the last of the parts need to assemble my Dracblade. I grabbed the 27 december zip and was able to load code and have it boot till it need the SD. I popped the uSD from my triblade, stuck it into an SD adapter and tried again. It started the SD, but complained about the file name to drive mapping. Seems there has been a bit of divergence in the file naming/mapping.
Still scrounging a few parts - can you supply a mfg part number for the SD socket? Are the chokes radial? I've only been able to find axial packages but not clear if long leads will be a problem if they're mounted stack or bowtie style. Mike, did you find things at US suppliers?
I have stoped trying to build small ones, as they are a right ******** to experiment on. So this one is going to be the nearest to a real one yet. All four latches and access to the second '232 output.
Such is my faith I have sectioned the board into conector, Prop and memory areas. The gaps are for the Hacksaw based salvage system.
Keeps me off the streets (along with that thing around my ankle).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Yes, sorry, drive images for all the zicogs have always been a bit hard to come by, simply because they are big files and don't fit on the forum
** See attached ** This is a zip of the working sd card images. Most of the drives are blank, and the trick here is that these blank 8mb files compress down to almost nothing with a ZIP as all the bytes are the same.
Also contains the tiny 8 byte text file with the name of the board.
Re suppliers - this is just where I got parts and I'm sure there are other solutions, especially Jameco and Digikey.
sd card holder: Sparkfun
vga D15 socket and Alliance 512k ram chip : Future Electronics
Inductor: Rockby (but many suppliers have this - I think Future Electronics do)
Propeller chip/eeprom/crystal: R T Nollet (Only cheaper if you are in Australia. If in the US get them from parallax.)
All other components: Futurlec
Radial vs axial won't matter for the inductor (ditto capacitors) and longer leads don't matter. The only critical thing about the inductor is that it has a low DC resistance and can handle 1 amp. (there are tiny RF chokes for instance that are made of very thin wire and have the same inductance but a much higher DC resistance. These would get warm). Also the datasheets specify 330uH but on one board I only had 470uH ones and they worked fine. But I'd follow the spec sheets and get 330uH.
I should add that Futurelec do sell a lot of components that won't show up in a search. eg the switcher diode won't come up on a search but is in the diode section. It takes a bit of time browsing through all the menus in Futurlec, but I find it worthwhile just to browse every sub menu from time to time as the prices are very good.
More nice ironing from Toby, I have to try and get back into that.
I do like you approach to "fault tolerant design". First we had jumpers in case some wires were reversed now we allow for hacksaw maintenance of a any dud bits. This must come from years of experience[noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Far too many, and I have to keep the expence down to an invisible level. Shoes, clothes ..... all esential but little black things with copper legs, pure wantant waste. Hey-Ho.
Plus the act of hacking apart a failure is a form of therapy: twitch: twitch: ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
(without the debugging text, the difference between cnt and oldcnt1 is very tiny so the value rounds to zero so countdown1 never decrements)
I have finally got a countdown timer working on the sd card. I'm turning the drive off after 1 second, as reads tend to be clusters of data. There were a number of sdinit lines of code that were converted to smaller calls to the PUBs below, which ended up saving some longs as well.
By using different variables eg countdown2 and countdown3 I can add more timers for other things, eg a screensaver.
The timer code is below
PUB StartCountDown1 ' used by sd card
OldCnt1:=cnt
Countdown1:=1000 ' 1 second delay
PUB CheckCountdown1 | r ' used for sd card timeout
if Countdown1 <> 0
if cnt > (Oldcnt1 + 20000000) ' add a big value as numbers are too tiny as Spin is too fast! Otherwise the calculated value below ends up zero most of the time
Countdown1:=Countdown1-((cnt-OldCnt1)/(clkfreq/1000)) ' subtract milliseconds since last check
OldCnt1:=cnt ' store the current clock counter for next time
if Countdown1 =< 0 ' *** note the syntax is =<, not <= ***
Countdown1:=0 ' for quick tests only run the countdown if CountDown1 <>0
RamLatches.DoCmd("F",0,0,0) ' led off
r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running)
CheckError(r)
PUB CheckSDCard | r ' if SD card has timed out then restart
if Countdown1 == 0 ' if timed out
'vgatext.str(string("Reinitialise SD card"))
r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD - stopped if timeout
CheckError(r)
RamLatches.DoCmd("N",0,0,0) ' led on
StartCountdown1 ' restart the counter every time called
Added some minor tweaks to the vga driver and it now blanks the screen after 1 minute if no keyboard activity (this time can be changed to anything different if you want. Or disable it by commenting out the line that blanks the screen 'vgatext.stop'
Very handy for saving power and no 'A>' burn-in!
Also - fixed a bug where xmodem wasn't working. I've been adding more and more code to Service_IO and this has been slowing down the system and then xmodem times out at the beginning. So I've modified that code so it spends most of the time checking for zicog I/O and only a tiny amount of time decrementing the counters and checking for input from the other serial port. Of course, the 'propeller' way to do this would be to use another cog for the counters, but I've run out of cogs! So - this code works and puts high priority on checking for I/O and low priority on counters.
PRI service_io | d ' d=delay
repeat
port1 ' any input from port1?
CheckCountdown1 ' sd card timeout
CheckCountdown2 ' vga blank timeout
repeat 100 ' spend most of the time checking i/o
case io_command
io_cmd_break: ' 03
on_break ' Break (for single stepping)
io_cmd_in: ' 02
on_input 'An input operation
io_cmd_out: ' 01
on_output 'An output operation
Tested it with my automated xmodem transfer program and also with Teraterm. Use the xmodemf.com program, not the xmodem.com, as the f version (for fast) has the timing loops shortened so it doesn't spend so long starting up.
I've also been testing the baud rate but the 4 port driver seems to max out at 19200. At 38400 you get occasional errors and at 56k it is mostly errors. I very much suspect the problem is the buffer size in the 4 port driver software - and the solution is to make the buffer size bigger than an xmodem packet (which is 132 bytes).
Next little project is video capture using the 4dSystems serial video camera. I've got it working on a PC serial port so just need to code it up so it works on the dracblade serial port. I'm not sure if the code will be Spin or a language in CP/M - it depends on how much memory I have left (6621 longs - does BST report how much space is available, or is it 8192?)
DR_A I need some more help if you don't mind. on the PC board facing the component side so the Sram is on the right upper left hand corner has 3 rows of 16 pins right below the DB9 connector what goes there also for the LCD bottom right 14 pin connector are you using Parallel LCD or Serial I bought the 4X20 Parallax serial LCD??????? Also can I use a 6 Meg Crystal instead of 5?? Thank you sir
Can you describe the location of the 3x16 connectors more - on the left or right? Just below the D9 is a group of 10x6 holes which is a prototyping area for extra circuits.
The 20x4 is parallel. BUT - if you have serial - maybe you could connect it to the serial port (bypass the max232 or add another max232). I've not used serial LCDs though - it would need different software. The LCD is a 16 way connector, not 14. If you put an IDC header on it with 16 way ribbon cable, then the wires end up wire 1,2,3,4 etc and are easy to connect to the LCD display. But first, need to get it running.
Re 5Mhz vs 6Mhx - cluso is pushing the clock higher and higher. I've not tested it - and not 100% sure if all the keyboard and serial objects will work ok. Try 5Mhz first.
All of the momemade Dracs have worked at 6 MHz ok, but as Dr_A says get it going, then mollest it.
The latest of my copies is a spread out version. This is so that I can get at all of the bits easily. It has all four latches and I will try to graft on a 2 x 16 LCD (parallel) as I have some kicking around.
At first I got the "Spacebar ..." again, so I tried a couple of NOPs in the latching routines, and it sprang into live. BUT then I tried it again without the nops to double check that was the problem and it still worked, and has kept on working.
Dr_A I have just tried to compile the v3 code and it gives 152 longs too big.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/31/2009 2:59:34 PM GMT
However, if you compile it from the graphical program BST.EXE then it compiles fine
(6621 longs used)
I had an idea that they are using different engines, but looking in 'About' and looking at the printout from the batch file, they are both using a version created on the 20th July.
So this is a mystery. I switched over to the IDE because it ran out of space on the batch file.
What I'd really like to know is how many longs are left. Every time I add a feature I hope it won't push it over the limit. Theory says 8192, but why is the batch file version falling over at about 6000?
This question is becoming more important as I'm thinking of extra drivers, eg for networking and for video capture, and if there is lots of memory free I'll do those in spin, but if we are very close to the limit then they will have to be CP/M programs.
I was using the IDE BST. There will always be a ceiling to bang into, Hey-Ho. Another thing is that I was getting a list of the components on the LHS after a F8 etc, that seems to have beggered off, but I havent changed anything.
The 2 x 16 LCD got bolted on yesterday but just gets full blocks and then two flashing blocks. I expected to have to reorder things for the different line lenths an numbers, but a character or two would have raised the spirits. I will have to fix BST and check that the initialization codes fo my panel are the same as for yours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
f8 you say? Well f8 seems to be broken but Compile/Compile Information seems to still work and I just checked that, and, hey ho, it tells me:
Program 6617 longs
Variable 1421 longs
Stack/Free 150 longs
Thanks ++ for that. Now we know how close we are sailing to the wind. I guess it is time to start thinking about crazy Spin overlay code and/or putting stuff into CP/M BDS C/Mbasic/Sbasic rather than Spin.
As an aside, what version of BST are you using (Help/About)?
This involves a thinking cap. Probably one with a spinning propeller on top...
Comments
Nice way of naming your boards. You could then use this name to open a file "alpha.cfg" for pcb "alpha" to get configuration options, such as VGA, serial, baudrate, etc. You could even use this method to name the cpm disk files used.
The GetMyName I/O port concept has great possibilities also, such as reading/writing to FAT16 files.
You will require my driver addition "S"et command. It is a fill command for sram (lucky I did not use "F"!). You pass it one byte in the buffer (just like a read/write) and it will fill sram with that value for the length specified. Very quick for clearing memory, and later for setting $E5's for a ramdisk.
BTW, for the SD drive LED, you could have just connected the led to the -CS pin on the SD card. You should at least disable the card when not in use to save power and also to ensure nothing spurious can happen in power up/down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
S sounds good. Though I've never been a huge fan of ram drives ever since I excitedly installed one on my brand new '386 in the early 1990s and then promptly kept forgetting to save before turning off.
re "BTW, for the SD drive LED, you could have just connected the led to the -CS pin on the SD card." Yes, I guess so but every time I change something with the wiring of the sd card it stops working. The DO not having a pullup should not make a difference. But it does. In any case, we have moved on...
re "You should at least disable the card when not in use to save power and also to ensure nothing spurious can happen in power up/down."
That is a good question Cluso. A very good question!
Ok, here is the problem. If you enable/disable the sd card for every 128 byte packet (or ok, 512 byte packet) it slows down the emulation. What I give up in speed by having to latch the address lines every memory access (that the ramblade can do in one go), I make up for with faster sd card access as the sd card pins are not used for anything else.
BUT, as you say, not good leaving the sd card running all the time - both for power consumption reasons and in case the card is removed.
Well, I had a cunning brainwave, and it all came from a circuit my father designed for our very first computer ( A CP/M computer, of course) which was hand built but it had a design flaw in that it left the disk drives going round and round even when the system was not doing anything. My dad designed a little timeout circuit that turned the drives off after 30 seconds or so.
So - I wondered if such a thing could be done in software. We have a timer, in the form of cnt. We can check it periodically when service_io is called.
The logic is that whenever the sd card is accessed it sets a flag. When the counter ticks over zero (or thereabouts) it resets the flag. The timing is perfect for cnt as it is about every 30 secs or so. If the sd card has been switched off then turn it back on, but if it is still on then no need to re-initialise.
I've added the led in so the led gives a visual indication the drives are still "turning". The led also flickers when data is being transferred, so it does double duty (and hence is smarter than just being connected to the /CS line).
An awful lot of code has changed, but I'm pretty sure the .stop is actually stopping the sd card. It ends up running this code in sdspifemto.spin
spiDoStop andn dira,spiMaskCS ' This is used for the situation mov spiMaskCS,#0 ' where the pins used for the SD andn dira,spiMaskDI ' card may be used for some other mov spiMaskDI,#0 ' purpose when the card is removed andn dira,spiMaskClk mov spiMaskClk,#0 andn dira,spiMaskDO mov spiMaskDO,#0 jmp #i2cGoUpdateThe timeout function is a bit crude. I could have a counter and then it would timeout after a fixed delay. But I ran into problems testing values (I'm still learning spin), as a value I was reading as hex $FFFFFFFF is coming up as a negative value for the purposes of subtraction and IF tests. This is the code, warts and all:
PUB SDTimeout | r ' uses SDRunning = 0 if not running, anything else = running if SDRunning > 0 ' speeds things up if only test this and return if 0 if cnt > $0000000 AND cnt < $04000000 'vgatext.str(string("SD card stopped ")) 'vgatext.hex(sdrunning,2) 'vgatext.str(string(" ")) 'vgatext.hex(cnt,8) SDRunning:=0 RamLatches.DoCmd("F",0,0,0) ' led off r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running) CheckError(r)There are some other changes, particularly in the
PRI refresh_hd_cache
and
PRI in_hdskport_write
It all seems to be working fine. Code is attached. Maybe it could end up in the sd driver itself? Maybe the concept could be extented to blank the vga display as a screensaver?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It will be interesting to see the speed of the 3 pcbs. Since the RamBlade uses less code for sram access, I can inline the instruction fetch access saving the call/ret and increment instructions. Maybe I can extend this elsewhere - need to look.
I am unsure how much extra overhead will be added by deselecting the card. Certainly in the old fsrw it was huge because of the patch I installed. The new fsrw seems much faster. I see you are still using the old fsrw driver.
I see how you are reading the input ports using "on_input" and also GetName using "on_output" and placing the text in dma buff + $80. So we could add a port to get the prop "CNT" value, or indeed a date/time (using another cog to count it). We would only have to set the date/time on ZiCog startup. I noticed CPM3 asks for the date on bootup.
I saw the IM register has a seperate declaration, but didn't I see that it was the same as another register somewhere else??? or am I getting confused??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'll see if I can get the new fsrw code working - do you have a link to the code you are using?
Mikediv, that component is a D9 socket (female). There is a photo herewww.smarthome.viviti.com/propeller It is a bit tedious getting all the bits together and it would be frustrating if you got the wrong parts. Where are you going to be buying the parts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/28/2009 12:02:53 AM GMT
and sockets.
I bought a lot of MK380IN-06 I thought they were Z80 chips but now I am not sure they might just be some kind of 40 pin Z80 I/o peripheral .
Re the D9, there are 4 wires that go into that socket - Tx, Rx, Gnd and the reset line, and those are the 4 lines for a prop plug. I use a serial connection directly into my PC as my PC is a bit older and has a real serial port. But if you have a prop plug, maybe there is another way to do this. Or you could just use a D9 female, then get a solder D9 male and make up an adaptor to go onto the prop plug?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The latest code I posted has it included (either TriBlade or ZiCog - IIRC version _rr137)
re the -1 issue, I always have to get my head around this when doing maths. If you look at it this way, taking 1 away from 0000 results in a ripple effect of the borrow. So if there are 8 bits the answer will be $FF, 16 gives $FFFF, 32 gives $FFFFFFFF. Take another 1 away and you get $....FE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'm working on some background reading of the second serial port - with a view to only passing things through to CP/M if a data packet is for that particular board. I'm hoping this can lead to some networking protocols (which needn't just pass to CP/M - it could pass to propdos or anything really).
I'm getting stuck with some basic String syntax in Spin. Specifically, I seem to be able to send fixed values to strings but not variables. This little array feeds things in from the right and shuffles them to the left (thanks Sam for pointing that out!).
I can print the ascii values of characters but not the actual character.
I did have an idea of printing out an array that was zero terminated but I don't seem to be able to get the syntax right for that (lots of brackets and an @ maybe but I'm not getting them right)
So I had an idea of printing them out one at a time but the characters won't print - only their ascii values. Not that it hugely matters but it would be nice for debugging to print the characters themselves. I've commented what is working and what is not.
PUB Port1 | j,c ' byte Port1Buffer[noparse][[/noparse]16] ' data coming in from port1 ' read port1 bytes into a small buffer ' if the buffer is 16 bytes (0-15) feed in from 15 and shuffle them all down one ' then can pattern match if know the length of the string to match ' and match from 15 backwards (if don't do this then the bytes are backwards) if UART.rxavail(1) vgatext.str(string("Port 1 Buffer equals:")) c:=UART.rxcheck(1) ' get the byte in c j:=0 repeat 15 ' n-1 Port1Buffer[noparse][[/noparse]j]:=Port1Buffer[noparse][[/noparse]j+1] ' shuffle all to the left j++ ' add 1 Port1Buffer[noparse][[/noparse]15]:=c ' new character into 15 Port1Buffer[noparse][[/noparse]16]:=0 ' so strings display - zero terminator j:=0 repeat 16 ' just display the characters not the 0 terminator c:=Port1Buffer[noparse][[/noparse]j] ' can't seem to print an array directly vgatext.str(string(c)) ' this won't print anything vgatext.dec(c) ' this prints the correct value for c vgatext.str(string(103)) ' this prints 'g' as expected c:=103 ' set c to 103 vgatext.str(string(c)) ' this doesn't print 'g' j++ vgatext.str(string(13,10)) ' this prints carriage return/linefeedI'm sure this is just a syntax thing. Help would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Also, vgatext.str(string(c)) is actually invalid as far as the prop tool is concerned, bst seems to let it pass but I don't know for sure what its meaning is.
I've now got a nice little buffer that prints text in the right order.
Next little job - I need some countdown timers. Maybe someone has already done these, but the code is a little different to the delay routines.
Ok, the propeller counter cycles about every 53 seconds. CP/Ms conin and other routines mean you can check the counter a lot more often than that. So, it ought to be possible to check the cnt at random times, and count down a clock until it reaches zero.
I've got three uses for this:
1) for a delay turnoff for the sd card
2) a delay to buffer radio output and send on a packet if no bytes have arrived for a while
3) possibly a screen saver
So, various routines might set the countdown timer (or keep resetting it). I'm doing this in milliseconds, and I think two variables are needed - the old cnt value, and also the countdown timer itself.
So to start a countdown timer,
and at random times check the timer and subtract the appropriate value.
PUB CheckCountdown1 if Countdown1<>0 Countdown1:=Countdown1-((cnt-OldClock1)/(clkfreq/1000)) ' subtract milliseconds since last check OldClock1:=cnt ' store the current clock counter for next time if Countdown1<0 Countdown1:=0 ' for quick tests only run the countdown if CountDown1 <>0 vgatext.dec(Countdown1) ' for debuggingI'm testing it with this code below and starting with 5000 and it returns 4000 and 2000 as expected.Occasionally it is out by 1 but it seems very repeatable and accurate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/29/2009 3:34:10 AM GMT
Now, if the above were done... You could use it for what you require AND it would be a simple matter of doing a write to port (say $71) and reading the dma buf + $80 for the value - like you did for getname.
I see you have used the clkfreq so that it is independant of the xtal. (i.e. correct time for any xtal)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I finally got the last of the parts need to assemble my Dracblade. I grabbed the 27 december zip and was able to load code and have it boot till it need the SD. I popped the uSD from my triblade, stuck it into an SD adapter and tried again. It started the SD, but complained about the file name to drive mapping. Seems there has been a bit of divergence in the file naming/mapping.
Thanks,
Jack
I have stoped trying to build small ones, as they are a right ******** to experiment on. So this one is going to be the nearest to a real one yet. All four latches and access to the second '232 output.
Such is my faith I have sectioned the board into conector, Prop and memory areas. The gaps are for the Hacksaw based salvage system.
Keeps me off the streets (along with that thing around my ankle).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
** See attached ** This is a zip of the working sd card images. Most of the drives are blank, and the trick here is that these blank 8mb files compress down to almost nothing with a ZIP as all the bytes are the same.
Also contains the tiny 8 byte text file with the name of the board.
Re suppliers - this is just where I got parts and I'm sure there are other solutions, especially Jameco and Digikey.
sd card holder: Sparkfun
vga D15 socket and Alliance 512k ram chip : Future Electronics
Inductor: Rockby (but many suppliers have this - I think Future Electronics do)
Propeller chip/eeprom/crystal: R T Nollet (Only cheaper if you are in Australia. If in the US get them from parallax.)
All other components: Futurlec
Radial vs axial won't matter for the inductor (ditto capacitors) and longer leads don't matter. The only critical thing about the inductor is that it has a low DC resistance and can handle 1 amp. (there are tiny RF chokes for instance that are made of very thin wire and have the same inductance but a much higher DC resistance. These would get warm). Also the datasheets specify 330uH but on one board I only had 470uH ones and they worked fine. But I'd follow the spec sheets and get 330uH.
I should add that Futurelec do sell a lot of components that won't show up in a search. eg the switcher diode won't come up on a search but is in the diode section. It takes a bit of time browsing through all the menus in Futurlec, but I find it worthwhile just to browse every sub menu from time to time as the prices are very good.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/29/2009 11:12:50 PM GMT
I do like you approach to "fault tolerant design". First we had jumpers in case some wires were reversed now we allow for hacksaw maintenance of a any dud bits. This must come from years of experience[noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Plus the act of hacking apart a failure is a form of therapy: twitch: twitch: ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Nice work Toby. Can I ask, *where* are you ironing your boards and have you considered this? en.wikipedia.org/wiki/Extreme_ironing with pictures www.google.com.au/#hl=en&source=hp&q=extreme+ironing&btnG=Google+Search&meta=&aq=f&oq=extreme+ironing&fp=1868206da6a46cbc
After extreme hair pulling at my dumbness at insisting on writing invalid code like:
and
(neither of which are picked up as syntax errors)
and then finding that this line works with debugging text but won't work when you remove the debugging text
(without the debugging text, the difference between cnt and oldcnt1 is very tiny so the value rounds to zero so countdown1 never decrements)
I have finally got a countdown timer working on the sd card. I'm turning the drive off after 1 second, as reads tend to be clusters of data. There were a number of sdinit lines of code that were converted to smaller calls to the PUBs below, which ended up saving some longs as well.
By using different variables eg countdown2 and countdown3 I can add more timers for other things, eg a screensaver.
The timer code is below
PUB StartCountDown1 ' used by sd card OldCnt1:=cnt Countdown1:=1000 ' 1 second delay PUB CheckCountdown1 | r ' used for sd card timeout if Countdown1 <> 0 if cnt > (Oldcnt1 + 20000000) ' add a big value as numbers are too tiny as Spin is too fast! Otherwise the calculated value below ends up zero most of the time Countdown1:=Countdown1-((cnt-OldCnt1)/(clkfreq/1000)) ' subtract milliseconds since last check OldCnt1:=cnt ' store the current clock counter for next time if Countdown1 =< 0 ' *** note the syntax is =<, not <= *** Countdown1:=0 ' for quick tests only run the countdown if CountDown1 <>0 RamLatches.DoCmd("F",0,0,0) ' led off r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running) CheckError(r) PUB CheckSDCard | r ' if SD card has timed out then restart if Countdown1 == 0 ' if timed out 'vgatext.str(string("Reinitialise SD card")) r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD - stopped if timeout CheckError(r) RamLatches.DoCmd("N",0,0,0) ' led on StartCountdown1 ' restart the counter every time calledAdded some minor tweaks to the vga driver and it now blanks the screen after 1 minute if no keyboard activity (this time can be changed to anything different if you want. Or disable it by commenting out the line that blanks the screen 'vgatext.stop'
Very handy for saving power and no 'A>' burn-in!
Also - fixed a bug where xmodem wasn't working. I've been adding more and more code to Service_IO and this has been slowing down the system and then xmodem times out at the beginning. So I've modified that code so it spends most of the time checking for zicog I/O and only a tiny amount of time decrementing the counters and checking for input from the other serial port. Of course, the 'propeller' way to do this would be to use another cog for the counters, but I've run out of cogs! So - this code works and puts high priority on checking for I/O and low priority on counters.
PRI service_io | d ' d=delay repeat port1 ' any input from port1? CheckCountdown1 ' sd card timeout CheckCountdown2 ' vga blank timeout repeat 100 ' spend most of the time checking i/o case io_command io_cmd_break: ' 03 on_break ' Break (for single stepping) io_cmd_in: ' 02 on_input 'An input operation io_cmd_out: ' 01 on_output 'An output operationTested it with my automated xmodem transfer program and also with Teraterm. Use the xmodemf.com program, not the xmodem.com, as the f version (for fast) has the timing loops shortened so it doesn't spend so long starting up.
I've also been testing the baud rate but the 4 port driver seems to max out at 19200. At 38400 you get occasional errors and at 56k it is mostly errors. I very much suspect the problem is the buffer size in the 4 port driver software - and the solution is to make the buffer size bigger than an xmodem packet (which is 132 bytes).
Next little project is video capture using the 4dSystems serial video camera. I've got it working on a PC serial port so just need to code it up so it works on the dracblade serial port. I'm not sure if the code will be Spin or a language in CP/M - it depends on how much memory I have left (6621 longs - does BST report how much space is available, or is it 8192?)
Zip is attached.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/30/2009 5:17:50 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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Considering that my ironing aims to melt plastic, I will leave the fragiles to others ( mental note to self: Do not mention "Womens work" )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The 20x4 is parallel. BUT - if you have serial - maybe you could connect it to the serial port (bypass the max232 or add another max232). I've not used serial LCDs though - it would need different software. The LCD is a 16 way connector, not 14. If you put an IDC header on it with 16 way ribbon cable, then the wires end up wire 1,2,3,4 etc and are easy to connect to the LCD display. But first, need to get it running.
Re 5Mhz vs 6Mhx - cluso is pushing the clock higher and higher. I've not tested it - and not 100% sure if all the keyboard and serial objects will work ok. Try 5Mhz first.
Have you got it booted up yet?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The latest of my copies is a spread out version. This is so that I can get at all of the bits easily. It has all four latches and I will try to graft on a 2 x 16 LCD (parallel) as I have some kicking around.
At first I got the "Spacebar ..." again, so I tried a couple of NOPs in the latching routines, and it sprang into live. BUT then I tried it again without the nops to double check that was the problem and it still worked, and has kept on working.
Dr_A I have just tried to compile the v3 code and it gives 152 longs too big.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/31/2009 2:59:34 PM GMT
Do you have decoupling caps under the pcb???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
A bit more and the thing would take longer to shut down than windows.
LCD bit not working yet, but it does add a bit of colour.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Yes, I've just noticed something. If you compile with a batch program eg something like
bstc -p2 -d COM1 -e -Ox -or Main_Dr_Acula.spin
rem TERATERM.EXE
pause
Then it gives 152 longs too many.
However, if you compile it from the graphical program BST.EXE then it compiles fine
(6621 longs used)
I had an idea that they are using different engines, but looking in 'About' and looking at the printout from the batch file, they are both using a version created on the 20th July.
So this is a mystery. I switched over to the IDE because it ran out of space on the batch file.
What I'd really like to know is how many longs are left. Every time I add a feature I hope it won't push it over the limit. Theory says 8192, but why is the batch file version falling over at about 6000?
This question is becoming more important as I'm thinking of extra drivers, eg for networking and for video capture, and if there is lots of memory free I'll do those in spin, but if we are very close to the limit then they will have to be CP/M programs.
Maybe Brad has the answer to this one?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I was using the IDE BST. There will always be a ceiling to bang into, Hey-Ho. Another thing is that I was getting a list of the components on the LHS after a F8 etc, that seems to have beggered off, but I havent changed anything.
The 2 x 16 LCD got bolted on yesterday but just gets full blocks and then two flashing blocks. I expected to have to reorder things for the different line lenths an numbers, but a character or two would have raised the spirits. I will have to fix BST and check that the initialization codes fo my panel are the same as for yours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Program 6617 longs
Variable 1421 longs
Stack/Free 150 longs
Thanks ++ for that. Now we know how close we are sailing to the wind. I guess it is time to start thinking about crazy Spin overlay code and/or putting stuff into CP/M BDS C/Mbasic/Sbasic rather than Spin.
As an aside, what version of BST are you using (Help/About)?
This involves a thinking cap. Probably one with a spinning propeller on top...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/1/2010 12:20:52 PM GMT