I have posted some vb.net code on the 4dsystems forum so now need to 1) port it over to this board (any language) and 2) get the code written for the second port. I've almost finished #2 (just need to add the instruction to change the baud rate) and then will start working on #1.
Dr_A I coming into the home stretch I agree I am trying to get the prop circuit running first but where does the prop plug go I am trying to use the only picture I have but when I blow it up it gets very distorted Yes 373 I just made a typo I think I have everyhting for the prop circuit but the max chip
Dr I also had a problem with my SD card socket the one they sent me had 11 pins the very end had 2 pins they were so close I thought they were connected but they were not so I just used the first 10 I did not hook up the very last pin pin 11 is that ok I will try and show you a picture
If you look at the very last pin where my pen is pointing that pin is not connected to anything???
Thank you very much for all the help
I have a couple of full size sd card sockets and in that cormer the very close together contacts are the "card present" and "protect" switched contacts. They looke like thin brass/gold strips edge on to the PCB. The contacts on the SD you need are 1-7(inc). Pin 1 is the first contact that is on the front edge of the card, next to the set back one by the champher (pin9, just accept it!). Along the top strip you use the central lot as the end one (or two half width ones) on the "square corner" is pin8.
Pinouts.ru has a pic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
1) The sd card looks fine. So that bit is ready to go.
2) The latches are HC374. Not 273 or 373. There is a 4 on the end and that is really important.
3) The board doesn't use a prop plug. It uses the female D9 socket at a standard serial connection. Or a USB to serial adaptor ($2 on ebay). The reason for this is that once it is programmed, you can remove the programming serial cable and then use that D9 socket as a standard serial port to talk to other boards/devices. But if you do have a prop plug and want to use it, it could be possible by leaving out some components and adding a small socket. First question, do you have a serial port on your computer?
Thanks Clusso I am sure you right that's what I thought but I am not sure if its the last pin or the next to last. I got this from spark fun by using the link DR_A sent me I can not seem to be able to get a data sheet from spark fun it shows a mechanical sheet but no electrical ??
Dr I do have a serial port and just finished soldering up my DB9 connectors.. Of course you are right I don't know why I keep posting the wrong part number. I am just finishing up the caps right now then its all ready for the chips.
I even added the power plug , I am going to power it up when I am done even without the chips I have the prop chip, 256 eprom, and figured I could at least check out that part of the circuit.
Oh I put a the Keyboard connector and a new VGA The one I had on initially was really crappy
See attached:
1) Added port 2 code. Now using single mbasic/c/assembly commands you can output a byte, test for a byte, input a byte and change the baud rate for port 2 all via CP/M, eg in mbasic (mbasic is quicker to test, though c and sbasic look neater)
10 BAUD = 1200
20 OUT (&H7C),BAUD/1200
30 OUT (&H78),65 REM prints A
I am using port 2 to talk to a video camera (14400 baud) or to a wireless transceiver (1200 baud) or to other boards with wired connections (19200 baud). Port 1 can also be used for comms if required.
2) Tweaked the vga driver font for the " character. This leant to the left, now it is straight up and down, ie not a beginning or end quote. Editing the font was quite fun!
3) Tweaked the keyboard object so it skips caps lock as a character. Caps lock was passing a character ^ to CP/M. Now nothing is passed when you hit caps lock - it just changes to caps.
4) Note to myself and others - uses BST to compile and needs Tools/Compiler Preferences/Optimisations/Eliminate Unused Spin Methods, otherwise runs out of memory
5) Added screen blanking after 5 minutes of no keyboard input. Saves considerable power for a CRT display and prevents burnin of the A>
6) Added SD card disable after 3 seconds of no SD card activity. Makes inadvertant disk corruption less likely and also saves power.
I heard on the radio tonight about a program www.energyrating.gov.au/pubs/2006-sb-hak-do-kim.pdf to reduce standby power for all electronic devices to 1 watt by 2010. I'm rather pleased to say that the Dracblade complies with this new ruling!
Toby thank you .. you nailed it I called spark fun and they said the same thing so thanks guys. I am pretty much done with my board I am just waiting for ships now to finish it, Thanks again everyone Dr_A I downloaded the zip file do I just put all those files on the SD card and boot the system or is there some way I have to program the board first? For the diodes can I use 1N914 or plain Jane power Diodes the ones you buy in bulk at Radio Shack??
It was one of those, anyway...*bites little finger*
@mikediv, that last zip is the program that goes into the propeller. Once you get a prop working, put all those files in a folder on the PC, open BST, point it to the files, open the Main one and hit F11 to program the propeller.
You should then get something on the screen but it will fail on the sd card read. In an earlier post are the .dsk files that go on the sd card.
Re the diodes, no, they have to be the ones specified. 1A 4001 power diodes are not fast enough, and 914 diodes are fast enough but only good for 10mA. Those ones specified are both fast and good for 1A.
Also, I'd suggest testing the power supply first, with no chips inserted. Then you could try just the eeprom, max232 and propeller and see if you can program it.
Addit: First real programming session today writing code on a Dracblade, independent of a PC. I'm using Mbasic as it is quick to test each little bit of code. It is not the best looking language, what with line numbers and all, but you can indent loops and if you don't put multiple statements on lines with : between them, and with rem comments and dividers like '******** it can be made more like a structured program. sbasic and C are better but the edit/compile/run cycle is too long.
Anyway, the uCAM is sending back its first acknowledge. This was the hardest part of writing the uCAM software in vb.net, so from now on it is just a matter of porting the vb.net over to the dracblade. Soon the Propeller will be taking Photographs. Do you like Photography? eh, eh, nudge nudge...
10 ' Capture a frame from the uCam and save
20 GoSub 180: ' set baud rate to 14400
30 GoSub 310: ' wake up ucam
40 End
50 ' ******************************
60 ' Send 6 bytes to synch
70 Print "=>";
80 A$ = "AA0D00000000"
90 For I = 1 To 6
100 B$ = Mid$(A$, (I * 2) - 1, 2)
110 OUT (&H78), Val("&H" + B$)
120 Print B$;
130 Next I
140 Print
150 Return
160 ' *****************************
170 ' set the baud rate
180 OUT (&H7C), 12: ' set baud rate to 14400
190 Return
200 ' *****************************
210 ' wait for 6 bytes to come back
220 A = INP(&H7D): ' any characters?
230 If A = 32 Then Print "Timeout waiting for character"
240 If A = 33 Then Print "Got a character!"
250 Return
260 ' *****************************
270 ' get 6 characters
280 Print "Get 6 characters"
290 Return
300 ' *****************************
310 ' check sync up to 60 times
320 For S = 1 To 15
330 GoSub 60: ' send 6 synch bytes
340 For D = 1 To 100: ' this delay is important
350 Next D
360 GoSub 210: ' wait for bytes to come back
370 Next S
380 Return
390 ' *****************************
As one in the uk that is removed from the central thoughts of the GODs that form this project,.
The sd should have the files that are in the archive that do NOT have anything to do with the terminal program or BST (etc) It is to big to upload to this board but comes to about 72MB+ expanded ( not the latest version anyway. Format a suitable SD and, staight away, copy over from the PC. The EEprom on the PCB wil have to be loaded with a BST compiled program. The rascals that run this thread put loads of conditional IFDEFs etc throughout the code. PropTool doesn't like it up'um. If you get stuck then a binary could be throw your way.
I have never built a true DracBlade, only my copies, so I know your pain (99.99% of which is nothing but self doubt) I have taken this back to 64KB with only two of the '374 latches and it fired up ok.
If you get sd not mounted then the SD card you have is probably not suitable, SANDISK SEEM TO WORK EVERY TIME, but other not (general, not just this project)
If you get " Spacebar for next instruction ..." then the ram is not online, I have had problems.
Finish the build and fire up, the good folk on the thread will fall over themselves to help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Now it isn't something past midnight I will remember to list the files on my SD -
A.DSK through to H.DSK
BLANK_E5.DSK
BOOT.DSK
CPMBOOT
DELPASSW.TTL
DIALUP.TTL
ZIBOOT
ZIBOOT.MAC
ZIBOOT.PRN
zicog_cpm2_files
I am sure that the two XXXX.TTL ones are not required as they look like something to do with teraterm. I haven't deleted them as it would spoil the contigious files.
Fresh format the SD to Fat ( not Fat32! ), and transfer the files over one after the other.
As Dr_A says if the SD isn't there, or isn't recognised, the prog will let you know, as it will with the KBD. I have had some "press spacebar for next instruction" error come up when the Ram isn't ok or sometimes when the power is first applied, Dr_A hasn't had this on his boards, a reset button push cures it, fo me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Guys I am looking over the schematic and I am wondering what is the purpose of the inductors??? I can not seem to understand if there is some timing delay I am missing I have not installed them yet (I dont have them) but I powered up my board and I have the 5 and 3 volts its stable and if I jump them out all the IC sockets are getting clean power???? What am I missing
The inductors are part of the switching power supply. You can't leave them out! They store energy and are part of the clever circuit that takes a higher voltage and converts it to a lower voltage with hardly any energy loss (ie hardly any heat).
and click on the picture near the bottom right for a bigger view of the schematic.
These are very easy to use - just don't substitute different diodes (futurlec sell them for 18c each) and make sure the inductor is rated for 1 amp.
If you happen to have another source of regulated 5V and 3.3V then you can use that and leave out the on-board regulators. Remember though that linear regulators such as the 7805 will probably need a heatsink.
DR_A here they are also quick question. My board has two C1 one C1 right next to the giant capacitor the 2200 and th eother C1 at the top left under the DB9 connector was both of them suppose to be .01 caps?
Yes bit of a muddle there, the one near the big capacitor has been overwritten.
The one up by the D9 is 0.01 This is from the parallax download circuit for the reset.
All the others are 0.1uF (bypass caps for the chips). But I've probably gone a bit overboard putting those 0.1uF caps everywhere, so if you have already soldered in a 0.01 near the ram chip, that won't matter.
And re the PM, if that is an inductor you are holding (the blue thing) then that looks perfect.
As an aside, the 2200uF cap is possibly overrated. If you are running off a transformer then bridge, it probably needs 4700uF. But if you are running off a wallwart, the wallwart very likely has 4700uF inside anyway, so the 2200uF could be decreased to, say, 470uF.
The rest of the board looks great. I gather you are just waiting on components now?
The uCam has beaten me for the moment. Very fickle bootup that almost seems temperature dependent (? timing on Uart. It is 43C today).
Anyway I'm very excited to annouce the first successful xmodem file transfer between two Dracblade boards. See photo.
The port addresses for the first port are &H68 for bytes and &H6D for the "ready" flag. The second port uses &H78 and &H7D. So it was just a matter of compiling a new version of xmodem with the two new port settings. Xmodem is working to and from a PC, so this new program was compiled on the PC, then sent via xmodem to both boards. Then the boards were connected to each other and on one:
XMODEM2 S MYFILE.TXT
and on the other
XMODEM2 R MYFILE.TXT
Working at 19200 baud (any faster and it overloads the little 16 byte buffer on the 4 port serial object by Tim Moore is just a bit fast for Zicog).
Also version 4 of the DracBlade has a red and green led for the second port so you can see the data going across.
Just one small snag (isn't there always one?) - the D9 male and female sockets are too close to fit some plugs at the same time, so you have to unplug the download cable. The IDC ribbon cable plugs are ok - just my USB to serial one is a bit fat!
But now we have file transfer working between propellers.
Next step - replicate the same thing with wireless...
so there is only about 50C temp difference between here and at yours, I am nowhere near Scotland -22C, but we have -8C. Heater is bound to beat that, but it's his lot that's chucking it all at us.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
>>Just one small snag (isn't there always one?) - the D9 male and female sockets are too close to fit some plugs at the same time, so you have to unplug the download cable. The IDC ribbon cable plugs are ok - just my USB to serial one is a bit fat!
I think I have finally got some code stable enough to call this a network.
Ok, the model is either a common RS232 bus (everyone listens to everyone else, all outputs are 'Wire-OR') or a wireless network where everyone is listening. The problem with both these models is that only one board can talk at once (especially with wireless).
This started off as a pretty simple idea. Take two microcontrollers (picaxes) and get them talking via wireless. That was easy.
Next problem, once you get up to a certain number of boards out in the field, it becomes difficult to upgrade them, especially since network testing involves lots of incremental rewrites. So you need some way of sending upgrades via the network itself. So then along comes the problem of what happens if a file transfer fails half way through? You now have a board with a new broken program and it may not respond at all to send a new copy.
So that leads to consideration of an operating system, where you can be running an old version, send a new one, run it, get some diagnostics to say it does actually run properly, and finally you can delete the old program.
But even an operating system is not quite enough. If a board is running a program (say a comms program) and you want to stop that program and drop back to the operating system, then it needs some sort of layer running underneath the operating system that is looking for certain messages.
It was at this point that I found real Z80 boards could not handle the multitasking and they needed more than one uart chip. Fortunately, at just the right time, along comes heater and cluso with the zicog and the hardware to run it.
Each board has two serial ports. The first one is for downloads and for connection to a terminal program.
The second port connects to a wireless RS232 module. CP/M is running and most of the time CP/M is checking to see if there is any keyboard input. Meanwhile, the 4 port serial port driver byTim Moore is listening in the background for anything out in the aether, and it collects bytes in its 64 byte buffer. Every 500 checks of the keyboard, there is a little bit of spin code that goes off and checks if there is a byte in the port 2 buffer. If there is, it looks for a sequence of 4 bytes (one Long) that must match a pattern. The pattern is # plus the first three letters of the board's name, which are Greek letters eg ALPHA, BETA, GAMMA. To wake up board EPSILON, send a message #EPS
This is simple enough you can type this on a terminal program connected to a serial port connected to a wireless RS232 module. So you don't need any complicated software to log into a board.
Once a connection is established, a board can send a command to the other board to run a comms program, eg
send XMODEM R MYFILE.TXT to the remote board which then runs xmodem and waits.
then run XMODEM S MYFILE.TXT on the local board and that starts the link and sends the file.
All we really need now is a tiny "terminal" program for CP/M that displays the local and the remote board, maybe on a split screen.
The key to this is every board has a unique name and only the board that has been switched on can talk. This keeps the airwaves clean.
If there is no activity for a number of minutes then the connection is lost (when the screen saver is activated).
One can envisage other little commands, eg a hard reset that resets a board regardless of its name.
I've even been compiling little programs on the propeller itself, eg this program which disconnects the board:
; File PORT2OFF.MAC Turn off control from Port 2
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E
START: OUT (71H),A ; send anything to port 71 to disable
RET ; back to CP/M
END
I compiled that on the propeller and used xmodem to send the compiled file back to the PC (rather than the other way round).
Added two new ports, background and foreground color change
eg in mbasic (or assembly)
OUT (&H72),E0 sets the foreground color to orange and
OUT (&H73),&H8 sets the background to blue where the color is RRGGBB00 and convert the binary to hex or decimal
So now you could have a tiny batch file to set the colors to how you want them rather than recompiling each time. (I did this with the idea that a terminal program would run in a different color when it was talking to a remote board)
The vga driver can change each row color (but not each individual character) so there could be something useful there.
So next little job is to think about a terminal program for CP/M. Should be fairly simple. Capture keypresses and direct to port 2 instead of the vga screen. Then look at port 2 for input and pass that to the vga screen. Change the color while it is running. And a key to 'escape', maybe ~. I've just written about half of it in 5 mins in MBASIC.
(sorry about bumping my own thread, but even though this topic has been quiet for a little while, I posted off 4 boards yesterday so this is partly for those people who will be getting boards soon)
1) Photo. Attached is a picture. On the left is the controlling Propeller CP/M board. On the right is the board being controlled. Normal boards are green on black (I'm getting some shimmering with solid background colors like blue and white). The screen on the left is orange to indicate it is logged into the remote board. This is running Wordstar wirelessly. Also at the bottom is a pdf of the build instructions, with 12 steps with photos.
2) Radio Link. Radio link is 1200 baud, but modules can go to 19200 and beyond. I just chose 1200 as slower baud rates have longer range. Modules are from Yishi (433Mhz) and go up to 3km with line of sight. They use RS232 signals so just plug into the serial port of the Dracblade.
3) Login. You can only log into one board at a time, and you need to log out of one board before logging into another (unless you use two different RF frequencies) Login command is #BET for board BETA, and logout is PORT2OFF (or LOGOUT). There are other network protocols I've had working such as ones that send tiny packets to each other. These work well but are harder to debug out in the field when a particular board has stopped working. Easier to build this up in layers and logging into boards remotely is a very useful first step.
4) Buffering. One big problem going from wired to wireless links is buffering. Let's say you type "DIR". If you type that in, then the D goes out, and the remote board echoes it back and it goes to the local screen. But what if you type the I and that goes out at exactly the same time as the D comes back? Then the data will get corrupted and likely neither character gets to its destination. The symptom is dropped characters. And the solution came to me while studying the Spin code for the keyboard driver (Thanks Chip!). This uses circular buffers with a Head and a Tail, and maybe this sort of code is common knowledge, but I had never seen such a solution. Particularly the way you test if Head = Tail to see if the buffer is empty, and the way you can make it circular by doing an AND with a number like 0FH. So - the key with a wireless terminal program is to buffer keyboard input for half a second or so and to send all the characters out at once. CP/M (or mbasic or whatever) then sends back a response, but the key is that that response comes back while the local keyboard is buffering more characters. So no data clashes. The characters appear on the screen with a slight delay which takes a little getting used to, but the delay is no worse than the delay typing into Google with the autosearch function on.
5) Wireless module buffering. Another feature of wireless modules is they have their own buffering. Most brands buffer 32 characters and send them out every 30 milliseconds or so. Unfortunately, xmodem sends in 132 byte packets, so either you need to modify xmodem to put in delays every 30 characters or so, or use modules like the Yishi ones that have bigger buffers.
6) Raw RF processing Ideally I'd like to do raw RF processing using the Bell Modem object in the Obex. Unfortunately I've run out of cogs (and almost out of hub memory), so more code is having to be moved over to CP/M rather than PASM/Spin. I guess that is one of the nice things about CP/M is the almost unlimited memory (if you run out of hub space, put it into a CP/M program. If that fills up the 64k space, write several programs and chain them with Submit files and pass variables via small text files. If you run out of 8mb space on a drive, chain programs onto different drives. It only runs out of space at 64mb of program, and that is a pretty big program!) But it would be nice to use the Bell Modem as it means you can use cheaper RF modules, even a standard CB radio and audio via a speaker and microphone. The ability to put big programs in SpinPASM with >8 cog programs and >32k hub code is why I am intrigued by Sphinx and PrEditor and PropDos. Eg while the orange screen terminal program is running, it doesn't need the SD card code in the cog. So replace that with the Bell Modem code. Ditto on the remote machine, it doesn't need the local keyboard cog running.
7) Code. So the above is the justification for posting a huge slab of Z80 code here on the Prop forum *grin*. This is the terminal program that logs into any board within RF range. This program is compiled on the Dracblade itself. Run programs remotely, write programs, transfer files. You can even compile the terminal program on a remote machine, wirelessly. I'm still amazed by what the Propeller can do!
; TERMINAL.MAC program for wireless login to CP/M boards
; changing from tasm mnemonics - replace all $nn with nnH
; remove . in front of equ
; remove : in equ lines
; must have a CR/LF after END
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E
; tasks - check port2 until empty and send on to local display, then keyboard and send to port2
; ports 74H = a key ready on keyboard, 75H = keyboard data, 11H= output to local display, 7D port2 test
; 78H=port2 data, 7C=port2 baud. To transfer files, run XMODEM2 R MYFILE on the remote machine, log out
; of this terminal program with ~ then run XMODEM2 S MYFILE on the local machine
FDOS EQU 0005H ; COMMON ENTRY POINT FOR BIOS AND BDOS
START:
CALL CLS ; clear screen
CALL ORANGE ; screen to orange on black
LD DE,STRING1 ; welcome screen
CALL PRINT ; print this string
LD DE,STRING2 ; welcome screen line 2
CALL PRINT ; print second line
LD DE,STRING3 ; welcome screen line 3
CALL PRINT ; print third signon line
CALL BAUD1200 ; port 2 to 1200 as radio modules use this
CALL RESETCOUNTER ; counter for buffering keyboard input
JP MAIN
MAIN:
CALL DECCOUNTER ; subtract one off counter and clear the keyboard buffer if any characters
IN A,(7DH) ; check port2 has a byte
CP 32 ; 32=no byte, 33=a byte
JP Z,KEYBOARD ; jump to keyboard test if no byte
IN A,(78H) ; get the character from port2
OUT (11H),A ; send to local display
JP MAIN ; back to beginning
KEYBOARD:
IN A,(74H) ; local keyboard 0 if no keypress, 255 if keypress
CP 0 ; loop until a keypress
JP Z,MAIN ; back to beginning if no keypress
IN A,(75H) ; get the key byte
CP 126 ; is it ~ (this is the exit character)
JP Z,FINISH ; jump to finish and end the program
CALL KEYADD ; add characters to the 16 byte circular buffer
JP MAIN ; back to beginning
FINISH:
CALL GREEN ; screen to green on black
CALL CLS ; clear the screen
; BAUD19200 ; port 2 baud rate back to 19200 (commented out, may as well leave at 1200)
RET ; to cp/m
; ************** subroutines ************************
PRINT: ; prints string at DE
LD A,(DE)
CP 0 ; zero terminated strings
RET Z ; finish if zero
OUT (11H),A ; print to screen
INC DE ; subtract 1
JP PRINT ; loop around
ORANGE:
LD A,0E0H ; screen to orange on black rrggbb00B
OUT (72H),A ; set foreground colour to orange
LD A,0 ; set background colour to black
OUT (73H),A ; output to background port
RET
GREEN:
LD A,34H ; screen to green on black
OUT (72H),A
LD A,0 ; set background colour to black
OUT (73H),A ; output to background port
RET
CLS:
LD DE,STRING4 ; clear string
CALL PRINT
RET
BAUD1200: ; port 2 to 1200 baud
LD A,1 ; a=1=1200,2=2400 etc. 16=19200
OUT (7CH),A
RET
BAUD19200:
LD A,16 ; 1200*16=91200
OUT (7CH),A
RET
KEYADD: ; add a character to the circular keyboard buffer (head/tail)
LD D,A ; temp store to D for the character passed in A
LD A,(KEYHEAD) ; get the head counter
LD HL,KEYBUFFER ; get the location of the 16 byte keyboard buffer
LD B,0 ; B=0
LD C,A ; set up for adding the head to the buffer
ADD HL,BC ; add them - answer in HL
INC A ; add one to the head counter
AND 0FH ; and with 00001111B so cycles at 16 to 0
LD (KEYHEAD),A ; store the new counter
LD A,D ; get the character back from register D
LD (HL),A ; store it in the location HL calculated above
RET
KEYCLEAR: ; clear the keyboard buffer
LD A,(KEYHEAD) ; get the head counter
LD B,A ; store it in B
LD A,(KEYTAIL) ; get the tail
CP B ; is the head equal to the tail
RET Z ; if yes then return - buffer is empty
LD HL,KEYBUFFER ; set up for getting the tail character
LD B,0 ; B=0
LD C,A ; A contains the tail counter => C
ADD HL,BC ; add the buffer and the tail counter
INC A ; add 1 to the tail counter
AND 0FH ; and with 00001111B so cycles at 16
LD (KEYTAIL),A ; store the tail counter
LD A,(HL) ; get the character
OUT (78H),A ; output it to the appropriate port
JP KEYCLEAR ; repeat until head = tail
DECCOUNTER: ; subtract 1 from counter, runs last few lines if = to zero
LD HL,(COUNTER) ; get counter value
DEC HL ; subtract 1
LD (COUNTER),HL ; store the new value
LD A,H ; test the high byte
CP 0 ; is HL equal to zero, if not then return
RET NZ ; return if not zero
LD A,L ; test the low byte
CP 0 ; is it zero
RET NZ ; return if not zero
CALL RESETCOUNTER ; counter is zero, so reset to a nominal value
CALL KEYCLEAR ; clear the keyboard buffer out to the port
RET
RESETCOUNTER:
LD HL,1000H ; adjust for the buffer delay (less than a second, 1000H is about right)
LD (COUNTER),HL ; reset the counter to a nominal value
RET
; ***************** debugging rountines *******************************
; print registers 00000 to 65535 (A is 00000 to 00255) for debugging
REGISTERS: ; Print all the registers
PUSH HL
PUSH DE
PUSH BC
PUSH AF
PUSH HL
PUSH DE
PUSH BC
CALL PRINT_A
POP BC
CALL PRINT_BC
POP DE
CALL PRINT_DE
POP HL
CALL PRINT_HL
LD E,13
CALL WRITE_CONSOLE
LD E,10
CALL WRITE_CONSOLE
POP AF
POP BC
POP DE
POP HL
RET
PRINT_A:
PUSH AF
LD E,'A'
CALL WRITE_CONSOLE
LD E,'='
CALL WRITE_CONSOLE
POP AF
LD B,0
LD C,A
CALL PRINTHEX
RET
PRINT_HL:
PUSH HL
LD E,' '
CALL WRITE_CONSOLE
LD E,'H'
CALL WRITE_CONSOLE
LD E,'L'
CALL WRITE_CONSOLE
LD E,'='
CALL WRITE_CONSOLE
POP HL
PUSH HL
LD B,0
LD C,H
CALL PRINTHEX
POP HL
LD B,0
LD C,L
CALL PRINTHEX
RET
PRINT_DE:
PUSH DE
LD E,' '
CALL WRITE_CONSOLE
LD E,'D'
CALL WRITE_CONSOLE
LD E,'E'
CALL WRITE_CONSOLE
LD E,'='
CALL WRITE_CONSOLE
POP DE
PUSH DE
LD B,0
LD C,D
CALL PRINTHEX
POP DE
LD B,0
LD C,E
CALL PRINTHEX
RET
PRINT_BC:
PUSH BC
LD E,' '
CALL WRITE_CONSOLE
LD E,'B'
CALL WRITE_CONSOLE
LD E,'C'
CALL WRITE_CONSOLE
LD E,'='
CALL WRITE_CONSOLE
POP BC
PUSH BC
LD C,B
LD B,0
CALL PRINTHEX
POP BC
LD C,C
LD B,0
CALL PRINTHEX
RET
; ************************************************
; bdos calls that preserve registers
WARM_BOOT:
LD C,0
CALL FDOS
RET ; probably doesn't need a RET!
READ_CONSOLE: ; returns answer in A
LD C,1
CALL FDOS
RET
WRITE_CONSOLE: ; prints letter in E
LD C,2 ; FUNCTION NUMBER
CALL FDOS
RET
WRITE_STRING: ; prints string at DE (ends with $)
LD C,9
CALL FDOS
RET
WRITE_STRING_CR: ; prints string and new line at end
LD C,9
CALL FDOS
LD DE,CRLF
LD C,9
CALL FDOS
RET
READ_BUFFER: ;like input in basic, reads a string from keyboard
LD C,10
LD DE,READBUFF
CALL FDOS
RET
OPEN_FILE: ; if opening a file for write to drive A etc, need to call create_file first
CALL SET_DMA
LD C,15
LD DE,FCB
CALL FDOS
RET
CLOSE_FILE:
LD C,16
LD DE,FCB
CALL FDOS
RET
DELETE_FILE:
LD C,19
LD DE,FCB
CALL FDOS
RET
READ_SEQ:
; returns a=0 for success, a=1 for fail (a=1 for eof as well)
; 128 bytes at set_dma location (80H)
LD C,20
LD DE,FCB
CALL FDOS
RET
WRITE_SEQ:
LD C,21
LD DE,FCB
CALL FDOS
RET
CREATE_FILE:
CALL SET_DMA
LD C,22
LD DE,FCB
CALL FDOS
RET
GET_DRIVE:
LD C,25
CALL FDOS
RET
SET_DMA:
LD C,26
LD DE,080H ; STANDARD DMA ADDRESS IS 80H
CALL FDOS
RET
FILE_SIZE:
LD C,35
LD DE,FCB ; PASS FCB CONTAINING FILE NAME
CALL FDOS ; RETURNS RECORDS IN FCB+33,35,35
; ALSO RECORDS IN CDE
LD DE,FCB ; MOVE BYTES TO CDE 24 BIT NUMBER
LD HL,33 ; BUT WOULD ALWAYS BE A 16 BIT NUMBER
ADD HL,DE ; AS 65535*128 IS 8MB
LD A,(HL) ; SO ANSWER REALLY IS DE RECORDS
LD E,A
INC HL
LD A,(HL)
LD D,A
INC HL
LD A,(HL)
LD C,A
RET ; answer in DE number of records
PRINTHEX: ; print the hex value in C to the display
; Hex to Ascii. Hex value in C. Answer in hl then print it. preserves other registers
LD A,0F0H
AND C
RRCA
RRCA
RRCA
RRCA
CALL PHEX1
LD HL,STRING1 ; Put answer here in string array
LD (HL),A ; store A
LD A,0FH
AND C
CALL PHEX1
INC HL ; Add one to string array
LD (HL),A ; store low nibble
INC HL
LD A,'$'
LD (HL),A ; Store end of string marker
LD DE,STRING1
CALL WRITE_STRING
RET
PHEX1:ADD A,30H
CP 3AH
RET M
ADD A,7
RET
; *************** data here **************************
CRLF: DB 13,10,'$'
READBUFF: DB 'ABCDEFGHIJKLMNOPQRSTUVWXYZ$'
FCB: DB 0,'FILENAMECOM',0,0,0,0,0
STRING1: DB 'Connects to port2 @ 1200 baud. Hit ~ to finish',13,10,0
STRING2: DB '#BET<Enter> to log into BETA',13,10,0
STRING3: DB 'Run PORT2OFF on remote computer to disconnect',13,10,0
STRING4: DB 27,'[noparse][[/noparse]2J',0 ; for clear string
KEYBUFFER: DB '0123456789ABCDEF'
KEYHEAD: DB 0
KEYTAIL: DB 0
COUNTER: DW 0
END
Much of this probably seems a bit esoteric, but I'm hoping to demonstrate useful things soon. eg take a picture and send it wirelessly round a network.
Anything you can do manually you ought to be able to do automatically. Just pretend someone typed in various things and put in the appropriate delays.
This is a quick and simple mbasic program to demonstrate an automatic login to a remote board, get the A> back and then logout. (mbasic is the quickest to write and debug. I'll translate to sbasic once it is working)
Next step, do an xmodem file transfer automatically.
10 GOSUB 360:' Clear the port 2 buffer
20 A$="#BET"+CHR$(13)+CHR$(10)
30 GOSUB 110:' output A$
40 GOSUB 320:' Longer delay
50 PRINT "Connected to remote board"
60 GOSUB 200:' get response
70 IF A=33 THEN GOTO 60:' more bytes to get back
80 A$="LOGOFF"+CHR$(13)+CHR$(10)
90 GOSUB 110
100 END
110 ' **** output A$ to port 2 *****
120 FOR I=1 TO LEN(A$)
130 A=ASC(MID$(A$,I,1))
140 PRINT CHR$(A);
150 GOSUB 270:' delay
160 OUT (&H78),A
170 NEXT I
180 PRINT
190 RETURN
200 ' get characters from port 2
210 A=INP(&H7D)
220 IF A=32 THEN RETURN
230 ' there is a byte ready to collect
240 B=INP(&H78)
250 PRINT CHR$(B);
260 RETURN
270 ' *** short delay ****
280 ' line below 50 too fast, 75 works, 100 to be sure
290 FOR J=1 TO 100
300 NEXT J
310 RETURN
320 ' *** longer delay ****
330 FOR J=1 TO 400
340 NEXT J
350 RETURN
360 ' *** Clear port 2 buffer ***
370 A=INP(&H7D)
380 IF A=32 THEN RETURN
390 A=INP(&H78):' get the character
400 GOTO 370
410 RETURN
Ok
It works!!! A huge thank you to DR_A for all the help believe me I bugged the poor man to death, anyway I have finally gotten my board to work as far as connecting to the prop TOOL , I can load spin programs and save to eprom or ram my next
big task is getting the whole board to run now with all the chips and CPM I am just waiting for an 74HC138N chip to arrive I did not know the N meant it was a different part than just a plain 138 .. Anyway any advice or help will be greatly appreciated
I have copied all of the DR_A files from his site and unzipped them onto a 1 gig sd card will this automatically boot or is there a step I need to do to get it to read the SD card?
Thanks guys
Dr I ended up using a 2n2222 but put it in backwards as the pin outs are reversed. Also as you can see from photos I used LM7805 and LM240 +5 and +3 voltage regulators but ran them through all the caps just like the original circuit
Also I might add an on off switch once I get everything working properly.
Right now I just need to know where to get spin files and how to load CPM so I can test the SD card circuit and make sure that's now working.
mike: I have posted the code for autobooting the RamBlade. You can change the SD pin numbers and burn to eeprom. That will mean that the prop will always boot from the sd card, so you do not have to reload the eeprom again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re spin files, if you go back to page 9 of this thread, the very last post on the 7th Jan has a zip at the bottom with all the files. See if that runs. Without all the chips you won't get much but hopefully some sort of error message on the screen.
I'm at work at the moment but when I get home I might post a binary of Catalina too, and maybe you can get that running as well. That will work with the board as you have it.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Dr I also had a problem with my SD card socket the one they sent me had 11 pins the very end had 2 pins they were so close I thought they were connected but they were not so I just used the first 10 I did not hook up the very last pin pin 11 is that ok I will try and show you a picture
If you look at the very last pin where my pen is pointing that pin is not connected to anything???
Thank you very much for all the help
Post Edited (mikediv) : 1/6/2010 3:40:30 PM 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
I have a couple of full size sd card sockets and in that cormer the very close together contacts are the "card present" and "protect" switched contacts. They looke like thin brass/gold strips edge on to the PCB. The contacts on the SD you need are 1-7(inc). Pin 1 is the first contact that is on the front edge of the card, next to the set back one by the champher (pin9, just accept it!). Along the top strip you use the central lot as the end one (or two half width ones) on the "square corner" is pin8.
Pinouts.ru has a pic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
2) The latches are HC374. Not 273 or 373. There is a 4 on the end and that is really important.
3) The board doesn't use a prop plug. It uses the female D9 socket at a standard serial connection. Or a USB to serial adaptor ($2 on ebay). The reason for this is that once it is programmed, you can remove the programming serial cable and then use that D9 socket as a standard serial port to talk to other boards/devices. But if you do have a prop plug and want to use it, it could be possible by leaving out some components and adding a small socket. First question, do you have a serial port on your computer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Dr I do have a serial port and just finished soldering up my DB9 connectors.. Of course you are right I don't know why I keep posting the wrong part number. I am just finishing up the caps right now then its all ready for the chips.
I even added the power plug , I am going to power it up when I am done even without the chips I have the prop chip, 256 eprom, and figured I could at least check out that part of the circuit.
Oh I put a the Keyboard connector and a new VGA The one I had on initially was really crappy
Post Edited (mikediv) : 1/7/2010 1:51:41 AM GMT
See attached:
1) Added port 2 code. Now using single mbasic/c/assembly commands you can output a byte, test for a byte, input a byte and change the baud rate for port 2 all via CP/M, eg in mbasic (mbasic is quicker to test, though c and sbasic look neater)
I am using port 2 to talk to a video camera (14400 baud) or to a wireless transceiver (1200 baud) or to other boards with wired connections (19200 baud). Port 1 can also be used for comms if required.
2) Tweaked the vga driver font for the " character. This leant to the left, now it is straight up and down, ie not a beginning or end quote. Editing the font was quite fun!
3) Tweaked the keyboard object so it skips caps lock as a character. Caps lock was passing a character ^ to CP/M. Now nothing is passed when you hit caps lock - it just changes to caps.
4) Note to myself and others - uses BST to compile and needs Tools/Compiler Preferences/Optimisations/Eliminate Unused Spin Methods, otherwise runs out of memory
5) Added screen blanking after 5 minutes of no keyboard input. Saves considerable power for a CRT display and prevents burnin of the A>
6) Added SD card disable after 3 seconds of no SD card activity. Makes inadvertant disk corruption less likely and also saves power.
I heard on the radio tonight about a program www.energyrating.gov.au/pubs/2006-sb-hak-do-kim.pdf to reduce standby power for all electronic devices to 1 watt by 2010. I'm rather pleased to say that the Dracblade complies with this new ruling!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
It was one of those, anyway...*bites little finger*
@mikediv, that last zip is the program that goes into the propeller. Once you get a prop working, put all those files in a folder on the PC, open BST, point it to the files, open the Main one and hit F11 to program the propeller.
You should then get something on the screen but it will fail on the sd card read. In an earlier post are the .dsk files that go on the sd card.
Re the diodes, no, they have to be the ones specified. 1A 4001 power diodes are not fast enough, and 914 diodes are fast enough but only good for 10mA. Those ones specified are both fast and good for 1A.
Also, I'd suggest testing the power supply first, with no chips inserted. Then you could try just the eeprom, max232 and propeller and see if you can program it.
Addit: First real programming session today writing code on a Dracblade, independent of a PC. I'm using Mbasic as it is quick to test each little bit of code. It is not the best looking language, what with line numbers and all, but you can indent loops and if you don't put multiple statements on lines with : between them, and with rem comments and dividers like '******** it can be made more like a structured program. sbasic and C are better but the edit/compile/run cycle is too long.
Anyway, the uCAM is sending back its first acknowledge. This was the hardest part of writing the uCAM software in vb.net, so from now on it is just a matter of porting the vb.net over to the dracblade. Soon the Propeller will be taking Photographs. Do you like Photography? eh, eh, nudge nudge...
10 ' Capture a frame from the uCam and save 20 GoSub 180: ' set baud rate to 14400 30 GoSub 310: ' wake up ucam 40 End 50 ' ****************************** 60 ' Send 6 bytes to synch 70 Print "=>"; 80 A$ = "AA0D00000000" 90 For I = 1 To 6 100 B$ = Mid$(A$, (I * 2) - 1, 2) 110 OUT (&H78), Val("&H" + B$) 120 Print B$; 130 Next I 140 Print 150 Return 160 ' ***************************** 170 ' set the baud rate 180 OUT (&H7C), 12: ' set baud rate to 14400 190 Return 200 ' ***************************** 210 ' wait for 6 bytes to come back 220 A = INP(&H7D): ' any characters? 230 If A = 32 Then Print "Timeout waiting for character" 240 If A = 33 Then Print "Got a character!" 250 Return 260 ' ***************************** 270 ' get 6 characters 280 Print "Get 6 characters" 290 Return 300 ' ***************************** 310 ' check sync up to 60 times 320 For S = 1 To 15 330 GoSub 60: ' send 6 synch bytes 340 For D = 1 To 100: ' this delay is important 350 Next D 360 GoSub 210: ' wait for bytes to come back 370 Next S 380 Return 390 ' *****************************▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/8/2010 2:37:37 AM GMT
As one in the uk that is removed from the central thoughts of the GODs that form this project,.
The sd should have the files that are in the archive that do NOT have anything to do with the terminal program or BST (etc) It is to big to upload to this board but comes to about 72MB+ expanded ( not the latest version anyway. Format a suitable SD and, staight away, copy over from the PC. The EEprom on the PCB wil have to be loaded with a BST compiled program. The rascals that run this thread put loads of conditional IFDEFs etc throughout the code. PropTool doesn't like it up'um. If you get stuck then a binary could be throw your way.
I have never built a true DracBlade, only my copies, so I know your pain (99.99% of which is nothing but self doubt) I have taken this back to 64KB with only two of the '374 latches and it fired up ok.
If you get sd not mounted then the SD card you have is probably not suitable, SANDISK SEEM TO WORK EVERY TIME, but other not (general, not just this project)
If you get " Spacebar for next instruction ..." then the ram is not online, I have had problems.
Finish the build and fire up, the good folk on the thread will fall over themselves to help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Now it isn't something past midnight I will remember to list the files on my SD -
A.DSK through to H.DSK
BLANK_E5.DSK
BOOT.DSK
CPMBOOT
DELPASSW.TTL
DIALUP.TTL
ZIBOOT
ZIBOOT.MAC
ZIBOOT.PRN
zicog_cpm2_files
I am sure that the two XXXX.TTL ones are not required as they look like something to do with teraterm. I haven't deleted them as it would spoil the contigious files.
Fresh format the SD to Fat ( not Fat32! ), and transfer the files over one after the other.
As Dr_A says if the SD isn't there, or isn't recognised, the prog will let you know, as it will with the KBD. I have had some "press spacebar for next instruction" error come up when the Ram isn't ok or sometimes when the power is first applied, Dr_A hasn't had this on his boards, a reset button push cures it, fo me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
www.national.com/mpf/LM/LM2575.html#Overview
and click on the picture near the bottom right for a bigger view of the schematic.
These are very easy to use - just don't substitute different diodes (futurlec sell them for 18c each) and make sure the inductor is rated for 1 amp.
If you happen to have another source of regulated 5V and 3.3V then you can use that and leave out the on-board regulators. Remember though that linear regulators such as the 7805 will probably need a heatsink.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The one up by the D9 is 0.01 This is from the parallax download circuit for the reset.
All the others are 0.1uF (bypass caps for the chips). But I've probably gone a bit overboard putting those 0.1uF caps everywhere, so if you have already soldered in a 0.01 near the ram chip, that won't matter.
And re the PM, if that is an inductor you are holding (the blue thing) then that looks perfect.
As an aside, the 2200uF cap is possibly overrated. If you are running off a transformer then bridge, it probably needs 4700uF. But if you are running off a wallwart, the wallwart very likely has 4700uF inside anyway, so the 2200uF could be decreased to, say, 470uF.
The rest of the board looks great. I gather you are just waiting on components now?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Anyway I'm very excited to annouce the first successful xmodem file transfer between two Dracblade boards. See photo.
The port addresses for the first port are &H68 for bytes and &H6D for the "ready" flag. The second port uses &H78 and &H7D. So it was just a matter of compiling a new version of xmodem with the two new port settings. Xmodem is working to and from a PC, so this new program was compiled on the PC, then sent via xmodem to both boards. Then the boards were connected to each other and on one:
XMODEM2 S MYFILE.TXT
and on the other
XMODEM2 R MYFILE.TXT
Working at 19200 baud (any faster and it overloads the little 16 byte buffer on the 4 port serial object by Tim Moore is just a bit fast for Zicog).
Also version 4 of the DracBlade has a red and green led for the second port so you can see the data going across.
Just one small snag (isn't there always one?) - the D9 male and female sockets are too close to fit some plugs at the same time, so you have to unplug the download cable. The IDC ribbon cable plugs are ok - just my USB to serial one is a bit fat!
But now we have file transfer working between propellers.
Next step - replicate the same thing with wireless...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
so there is only about 50C temp difference between here and at yours, I am nowhere near Scotland -22C, but we have -8C. Heater is bound to beat that, but it's his lot that's chucking it all at us.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
You could probably use one of these slim DB9 MM and FF connectors back to back to extend one connector past the adjacent connector.
www.pccables.com/cgi-bin/orders6.cgi?action=Showitem&id=ID10188776&partno=00301&search=DB9_M-M&rsite=pccables.comcgi&rcode= and www.pccables.com/cgi-bin/orders6.cgi?action=Showitem&id=ID10188776&partno=00302&search=DB9_F-F&rsite=pccables.comcgi&rcode=
I think I have finally got some code stable enough to call this a network.
Ok, the model is either a common RS232 bus (everyone listens to everyone else, all outputs are 'Wire-OR') or a wireless network where everyone is listening. The problem with both these models is that only one board can talk at once (especially with wireless).
This started off as a pretty simple idea. Take two microcontrollers (picaxes) and get them talking via wireless. That was easy.
Next problem, once you get up to a certain number of boards out in the field, it becomes difficult to upgrade them, especially since network testing involves lots of incremental rewrites. So you need some way of sending upgrades via the network itself. So then along comes the problem of what happens if a file transfer fails half way through? You now have a board with a new broken program and it may not respond at all to send a new copy.
So that leads to consideration of an operating system, where you can be running an old version, send a new one, run it, get some diagnostics to say it does actually run properly, and finally you can delete the old program.
But even an operating system is not quite enough. If a board is running a program (say a comms program) and you want to stop that program and drop back to the operating system, then it needs some sort of layer running underneath the operating system that is looking for certain messages.
It was at this point that I found real Z80 boards could not handle the multitasking and they needed more than one uart chip. Fortunately, at just the right time, along comes heater and cluso with the zicog and the hardware to run it.
Each board has two serial ports. The first one is for downloads and for connection to a terminal program.
The second port connects to a wireless RS232 module. CP/M is running and most of the time CP/M is checking to see if there is any keyboard input. Meanwhile, the 4 port serial port driver byTim Moore is listening in the background for anything out in the aether, and it collects bytes in its 64 byte buffer. Every 500 checks of the keyboard, there is a little bit of spin code that goes off and checks if there is a byte in the port 2 buffer. If there is, it looks for a sequence of 4 bytes (one Long) that must match a pattern. The pattern is # plus the first three letters of the board's name, which are Greek letters eg ALPHA, BETA, GAMMA. To wake up board EPSILON, send a message #EPS
This is simple enough you can type this on a terminal program connected to a serial port connected to a wireless RS232 module. So you don't need any complicated software to log into a board.
Once a connection is established, a board can send a command to the other board to run a comms program, eg
send XMODEM R MYFILE.TXT to the remote board which then runs xmodem and waits.
then run XMODEM S MYFILE.TXT on the local board and that starts the link and sends the file.
All we really need now is a tiny "terminal" program for CP/M that displays the local and the remote board, maybe on a split screen.
The key to this is every board has a unique name and only the board that has been switched on can talk. This keeps the airwaves clean.
If there is no activity for a number of minutes then the connection is lost (when the screen saver is activated).
One can envisage other little commands, eg a hard reset that resets a board regardless of its name.
I've even been compiling little programs on the propeller itself, eg this program which disconnects the board:
; File PORT2OFF.MAC Turn off control from Port 2 ; use zasm.sub with supersub ; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the ; mac in the instruction - m80 knows it is implied) ; zasm.sub is the following two lines ;M80 =$1 /Z/C/L/M ;L80 $1,$1/N/E START: OUT (71H),A ; send anything to port 71 to disable RET ; back to CP/M ENDI compiled that on the propeller and used xmodem to send the compiled file back to the PC (rather than the other way round).
Added two new ports, background and foreground color change
eg in mbasic (or assembly)
OUT (&H72),E0 sets the foreground color to orange and
OUT (&H73),&H8 sets the background to blue where the color is RRGGBB00 and convert the binary to hex or decimal
So now you could have a tiny batch file to set the colors to how you want them rather than recompiling each time. (I did this with the idea that a terminal program would run in a different color when it was talking to a remote board)
The vga driver can change each row color (but not each individual character) so there could be something useful there.
So next little job is to think about a terminal program for CP/M. Should be fairly simple. Capture keypresses and direct to port 2 instead of the vga screen. Then look at port 2 for input and pass that to the vga screen. Change the color while it is running. And a key to 'escape', maybe ~. I've just written about half of it in 5 mins in MBASIC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/11/2010 5:53:52 AM GMT
(sorry about bumping my own thread, but even though this topic has been quiet for a little while, I posted off 4 boards yesterday so this is partly for those people who will be getting boards soon)
1) Photo. Attached is a picture. On the left is the controlling Propeller CP/M board. On the right is the board being controlled. Normal boards are green on black (I'm getting some shimmering with solid background colors like blue and white). The screen on the left is orange to indicate it is logged into the remote board. This is running Wordstar wirelessly. Also at the bottom is a pdf of the build instructions, with 12 steps with photos.
2) Radio Link. Radio link is 1200 baud, but modules can go to 19200 and beyond. I just chose 1200 as slower baud rates have longer range. Modules are from Yishi (433Mhz) and go up to 3km with line of sight. They use RS232 signals so just plug into the serial port of the Dracblade.
3) Login. You can only log into one board at a time, and you need to log out of one board before logging into another (unless you use two different RF frequencies) Login command is #BET for board BETA, and logout is PORT2OFF (or LOGOUT). There are other network protocols I've had working such as ones that send tiny packets to each other. These work well but are harder to debug out in the field when a particular board has stopped working. Easier to build this up in layers and logging into boards remotely is a very useful first step.
4) Buffering. One big problem going from wired to wireless links is buffering. Let's say you type "DIR". If you type that in, then the D goes out, and the remote board echoes it back and it goes to the local screen. But what if you type the I and that goes out at exactly the same time as the D comes back? Then the data will get corrupted and likely neither character gets to its destination. The symptom is dropped characters. And the solution came to me while studying the Spin code for the keyboard driver (Thanks Chip!). This uses circular buffers with a Head and a Tail, and maybe this sort of code is common knowledge, but I had never seen such a solution. Particularly the way you test if Head = Tail to see if the buffer is empty, and the way you can make it circular by doing an AND with a number like 0FH. So - the key with a wireless terminal program is to buffer keyboard input for half a second or so and to send all the characters out at once. CP/M (or mbasic or whatever) then sends back a response, but the key is that that response comes back while the local keyboard is buffering more characters. So no data clashes. The characters appear on the screen with a slight delay which takes a little getting used to, but the delay is no worse than the delay typing into Google with the autosearch function on.
5) Wireless module buffering. Another feature of wireless modules is they have their own buffering. Most brands buffer 32 characters and send them out every 30 milliseconds or so. Unfortunately, xmodem sends in 132 byte packets, so either you need to modify xmodem to put in delays every 30 characters or so, or use modules like the Yishi ones that have bigger buffers.
6) Raw RF processing Ideally I'd like to do raw RF processing using the Bell Modem object in the Obex. Unfortunately I've run out of cogs (and almost out of hub memory), so more code is having to be moved over to CP/M rather than PASM/Spin. I guess that is one of the nice things about CP/M is the almost unlimited memory (if you run out of hub space, put it into a CP/M program. If that fills up the 64k space, write several programs and chain them with Submit files and pass variables via small text files. If you run out of 8mb space on a drive, chain programs onto different drives. It only runs out of space at 64mb of program, and that is a pretty big program!) But it would be nice to use the Bell Modem as it means you can use cheaper RF modules, even a standard CB radio and audio via a speaker and microphone. The ability to put big programs in SpinPASM with >8 cog programs and >32k hub code is why I am intrigued by Sphinx and PrEditor and PropDos. Eg while the orange screen terminal program is running, it doesn't need the SD card code in the cog. So replace that with the Bell Modem code. Ditto on the remote machine, it doesn't need the local keyboard cog running.
7) Code. So the above is the justification for posting a huge slab of Z80 code here on the Prop forum *grin*. This is the terminal program that logs into any board within RF range. This program is compiled on the Dracblade itself. Run programs remotely, write programs, transfer files. You can even compile the terminal program on a remote machine, wirelessly. I'm still amazed by what the Propeller can do!
; TERMINAL.MAC program for wireless login to CP/M boards ; changing from tasm mnemonics - replace all $nn with nnH ; remove . in front of equ ; remove : in equ lines ; must have a CR/LF after END ; use zasm.sub with supersub ; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the ; mac in the instruction - m80 knows it is implied) ; zasm.sub is the following two lines ;M80 =$1 /Z/C/L/M ;L80 $1,$1/N/E ; tasks - check port2 until empty and send on to local display, then keyboard and send to port2 ; ports 74H = a key ready on keyboard, 75H = keyboard data, 11H= output to local display, 7D port2 test ; 78H=port2 data, 7C=port2 baud. To transfer files, run XMODEM2 R MYFILE on the remote machine, log out ; of this terminal program with ~ then run XMODEM2 S MYFILE on the local machine FDOS EQU 0005H ; COMMON ENTRY POINT FOR BIOS AND BDOS START: CALL CLS ; clear screen CALL ORANGE ; screen to orange on black LD DE,STRING1 ; welcome screen CALL PRINT ; print this string LD DE,STRING2 ; welcome screen line 2 CALL PRINT ; print second line LD DE,STRING3 ; welcome screen line 3 CALL PRINT ; print third signon line CALL BAUD1200 ; port 2 to 1200 as radio modules use this CALL RESETCOUNTER ; counter for buffering keyboard input JP MAIN MAIN: CALL DECCOUNTER ; subtract one off counter and clear the keyboard buffer if any characters IN A,(7DH) ; check port2 has a byte CP 32 ; 32=no byte, 33=a byte JP Z,KEYBOARD ; jump to keyboard test if no byte IN A,(78H) ; get the character from port2 OUT (11H),A ; send to local display JP MAIN ; back to beginning KEYBOARD: IN A,(74H) ; local keyboard 0 if no keypress, 255 if keypress CP 0 ; loop until a keypress JP Z,MAIN ; back to beginning if no keypress IN A,(75H) ; get the key byte CP 126 ; is it ~ (this is the exit character) JP Z,FINISH ; jump to finish and end the program CALL KEYADD ; add characters to the 16 byte circular buffer JP MAIN ; back to beginning FINISH: CALL GREEN ; screen to green on black CALL CLS ; clear the screen ; BAUD19200 ; port 2 baud rate back to 19200 (commented out, may as well leave at 1200) RET ; to cp/m ; ************** subroutines ************************ PRINT: ; prints string at DE LD A,(DE) CP 0 ; zero terminated strings RET Z ; finish if zero OUT (11H),A ; print to screen INC DE ; subtract 1 JP PRINT ; loop around ORANGE: LD A,0E0H ; screen to orange on black rrggbb00B OUT (72H),A ; set foreground colour to orange LD A,0 ; set background colour to black OUT (73H),A ; output to background port RET GREEN: LD A,34H ; screen to green on black OUT (72H),A LD A,0 ; set background colour to black OUT (73H),A ; output to background port RET CLS: LD DE,STRING4 ; clear string CALL PRINT RET BAUD1200: ; port 2 to 1200 baud LD A,1 ; a=1=1200,2=2400 etc. 16=19200 OUT (7CH),A RET BAUD19200: LD A,16 ; 1200*16=91200 OUT (7CH),A RET KEYADD: ; add a character to the circular keyboard buffer (head/tail) LD D,A ; temp store to D for the character passed in A LD A,(KEYHEAD) ; get the head counter LD HL,KEYBUFFER ; get the location of the 16 byte keyboard buffer LD B,0 ; B=0 LD C,A ; set up for adding the head to the buffer ADD HL,BC ; add them - answer in HL INC A ; add one to the head counter AND 0FH ; and with 00001111B so cycles at 16 to 0 LD (KEYHEAD),A ; store the new counter LD A,D ; get the character back from register D LD (HL),A ; store it in the location HL calculated above RET KEYCLEAR: ; clear the keyboard buffer LD A,(KEYHEAD) ; get the head counter LD B,A ; store it in B LD A,(KEYTAIL) ; get the tail CP B ; is the head equal to the tail RET Z ; if yes then return - buffer is empty LD HL,KEYBUFFER ; set up for getting the tail character LD B,0 ; B=0 LD C,A ; A contains the tail counter => C ADD HL,BC ; add the buffer and the tail counter INC A ; add 1 to the tail counter AND 0FH ; and with 00001111B so cycles at 16 LD (KEYTAIL),A ; store the tail counter LD A,(HL) ; get the character OUT (78H),A ; output it to the appropriate port JP KEYCLEAR ; repeat until head = tail DECCOUNTER: ; subtract 1 from counter, runs last few lines if = to zero LD HL,(COUNTER) ; get counter value DEC HL ; subtract 1 LD (COUNTER),HL ; store the new value LD A,H ; test the high byte CP 0 ; is HL equal to zero, if not then return RET NZ ; return if not zero LD A,L ; test the low byte CP 0 ; is it zero RET NZ ; return if not zero CALL RESETCOUNTER ; counter is zero, so reset to a nominal value CALL KEYCLEAR ; clear the keyboard buffer out to the port RET RESETCOUNTER: LD HL,1000H ; adjust for the buffer delay (less than a second, 1000H is about right) LD (COUNTER),HL ; reset the counter to a nominal value RET ; ***************** debugging rountines ******************************* ; print registers 00000 to 65535 (A is 00000 to 00255) for debugging REGISTERS: ; Print all the registers PUSH HL PUSH DE PUSH BC PUSH AF PUSH HL PUSH DE PUSH BC CALL PRINT_A POP BC CALL PRINT_BC POP DE CALL PRINT_DE POP HL CALL PRINT_HL LD E,13 CALL WRITE_CONSOLE LD E,10 CALL WRITE_CONSOLE POP AF POP BC POP DE POP HL RET PRINT_A: PUSH AF LD E,'A' CALL WRITE_CONSOLE LD E,'=' CALL WRITE_CONSOLE POP AF LD B,0 LD C,A CALL PRINTHEX RET PRINT_HL: PUSH HL LD E,' ' CALL WRITE_CONSOLE LD E,'H' CALL WRITE_CONSOLE LD E,'L' CALL WRITE_CONSOLE LD E,'=' CALL WRITE_CONSOLE POP HL PUSH HL LD B,0 LD C,H CALL PRINTHEX POP HL LD B,0 LD C,L CALL PRINTHEX RET PRINT_DE: PUSH DE LD E,' ' CALL WRITE_CONSOLE LD E,'D' CALL WRITE_CONSOLE LD E,'E' CALL WRITE_CONSOLE LD E,'=' CALL WRITE_CONSOLE POP DE PUSH DE LD B,0 LD C,D CALL PRINTHEX POP DE LD B,0 LD C,E CALL PRINTHEX RET PRINT_BC: PUSH BC LD E,' ' CALL WRITE_CONSOLE LD E,'B' CALL WRITE_CONSOLE LD E,'C' CALL WRITE_CONSOLE LD E,'=' CALL WRITE_CONSOLE POP BC PUSH BC LD C,B LD B,0 CALL PRINTHEX POP BC LD C,C LD B,0 CALL PRINTHEX RET ; ************************************************ ; bdos calls that preserve registers WARM_BOOT: LD C,0 CALL FDOS RET ; probably doesn't need a RET! READ_CONSOLE: ; returns answer in A LD C,1 CALL FDOS RET WRITE_CONSOLE: ; prints letter in E LD C,2 ; FUNCTION NUMBER CALL FDOS RET WRITE_STRING: ; prints string at DE (ends with $) LD C,9 CALL FDOS RET WRITE_STRING_CR: ; prints string and new line at end LD C,9 CALL FDOS LD DE,CRLF LD C,9 CALL FDOS RET READ_BUFFER: ;like input in basic, reads a string from keyboard LD C,10 LD DE,READBUFF CALL FDOS RET OPEN_FILE: ; if opening a file for write to drive A etc, need to call create_file first CALL SET_DMA LD C,15 LD DE,FCB CALL FDOS RET CLOSE_FILE: LD C,16 LD DE,FCB CALL FDOS RET DELETE_FILE: LD C,19 LD DE,FCB CALL FDOS RET READ_SEQ: ; returns a=0 for success, a=1 for fail (a=1 for eof as well) ; 128 bytes at set_dma location (80H) LD C,20 LD DE,FCB CALL FDOS RET WRITE_SEQ: LD C,21 LD DE,FCB CALL FDOS RET CREATE_FILE: CALL SET_DMA LD C,22 LD DE,FCB CALL FDOS RET GET_DRIVE: LD C,25 CALL FDOS RET SET_DMA: LD C,26 LD DE,080H ; STANDARD DMA ADDRESS IS 80H CALL FDOS RET FILE_SIZE: LD C,35 LD DE,FCB ; PASS FCB CONTAINING FILE NAME CALL FDOS ; RETURNS RECORDS IN FCB+33,35,35 ; ALSO RECORDS IN CDE LD DE,FCB ; MOVE BYTES TO CDE 24 BIT NUMBER LD HL,33 ; BUT WOULD ALWAYS BE A 16 BIT NUMBER ADD HL,DE ; AS 65535*128 IS 8MB LD A,(HL) ; SO ANSWER REALLY IS DE RECORDS LD E,A INC HL LD A,(HL) LD D,A INC HL LD A,(HL) LD C,A RET ; answer in DE number of records PRINTHEX: ; print the hex value in C to the display ; Hex to Ascii. Hex value in C. Answer in hl then print it. preserves other registers LD A,0F0H AND C RRCA RRCA RRCA RRCA CALL PHEX1 LD HL,STRING1 ; Put answer here in string array LD (HL),A ; store A LD A,0FH AND C CALL PHEX1 INC HL ; Add one to string array LD (HL),A ; store low nibble INC HL LD A,'$' LD (HL),A ; Store end of string marker LD DE,STRING1 CALL WRITE_STRING RET PHEX1:ADD A,30H CP 3AH RET M ADD A,7 RET ; *************** data here ************************** CRLF: DB 13,10,'$' READBUFF: DB 'ABCDEFGHIJKLMNOPQRSTUVWXYZ$' FCB: DB 0,'FILENAMECOM',0,0,0,0,0 STRING1: DB 'Connects to port2 @ 1200 baud. Hit ~ to finish',13,10,0 STRING2: DB '#BET<Enter> to log into BETA',13,10,0 STRING3: DB 'Run PORT2OFF on remote computer to disconnect',13,10,0 STRING4: DB 27,'[noparse][[/noparse]2J',0 ; for clear string KEYBUFFER: DB '0123456789ABCDEF' KEYHEAD: DB 0 KEYTAIL: DB 0 COUNTER: DW 0 END▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/19/2010 2:48:41 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
Much of this probably seems a bit esoteric, but I'm hoping to demonstrate useful things soon. eg take a picture and send it wirelessly round a network.
Anything you can do manually you ought to be able to do automatically. Just pretend someone typed in various things and put in the appropriate delays.
This is a quick and simple mbasic program to demonstrate an automatic login to a remote board, get the A> back and then logout. (mbasic is the quickest to write and debug. I'll translate to sbasic once it is working)
Next step, do an xmodem file transfer automatically.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/20/2010 9:48:44 PM GMT
Fancy posting Z80 code on a prop forum to be run on the prop !!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 looking at some BASCOM AVR code at the moment. Two sins for the price of one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
big task is getting the whole board to run now with all the chips and CPM I am just waiting for an 74HC138N chip to arrive I did not know the N meant it was a different part than just a plain 138 .. Anyway any advice or help will be greatly appreciated
I have copied all of the DR_A files from his site and unzipped them onto a 1 gig sd card will this automatically boot or is there a step I need to do to get it to read the SD card?
Thanks guys
Also I might add an on off switch once I get everything working properly.
Right now I just need to know where to get spin files and how to load CPM so I can test the SD card circuit and make sure that's now working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 at work at the moment but when I get home I might post a binary of Catalina too, and maybe you can get that running as well. That will work with the board as you have it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller