Attached are the two programs I've been using to network two dracblade boards. I'm wondering about turning them into spin or even pasm.
What this can do is quite useful.
print "1 - Send file to peer"
print "2 - Receive file from peer"
print "3 - Talk to peer"
print "4 - WHO - search for peers"
print "5 - RES - Reset all nearby boards"
print "9 - BYE - Logoff"
input2 "Enter your choice: ";a
The above is fairly self explanatory. Option 3 changes the screen from white on blue to yellow on blue as a reminder that the display is actually that of the remote board. ESC disconnects.
With some careful adjustment of timing and small buffers it is possible to type on a local board and not get interference from the characters coming back.
But this system still does not scale well for multiple boards. The main problem is there are three types of data out on the airwaves:
1) Magic packets #RES and #WHO and the like
2) Raw bytes, eg the listing coming back from a DIR
3) Bytes wrapped up in packets
Already I've run into problems with magic packet interference, specifically where I put comments in a program describing the magic packets and then did an xmodem of that compiled program. The comments were not changed and when the xmodem transfer got to the #RES comment it reset the board. This would be a problem with any ascii string one might want to use.
But the main issue is raw bytes vs packets. Sooner or later they are going to interfere, particularly when a board is listening to raw bytes and is susceptable to random data from packets a long way away, or someone opening their garage door.
So I am thinking that the neatest solution is to only use option 3) = packets.
This leads to the next issue, and that is the inefficiency of wrapping up a single byte in a packet that might be 8 or 9 bytes long. That slows down communication. So packets ought to be of variable length. If bytes are coming through slowly one at a time, wrap them up in individual packets. If there is a whole lot of data in a buffer, put it in one packet.
This is just one format I came up with:
0 start of text = ascii 02 "start of text"
1 number of bytes
2 source
3 destination
4 message type
5 random number (or a counter)
6 to n data,data,data
checksum
endpacket = ascii 03 "end of text"
The smallest packet transporting 1 byte ends up 9 bytes long.
The next issue is where to put this code. In CP/M there is lots of space so as with the attached code, it is possible to write it in a high language like Basic and it will all fit. On the dracblade board there is not much spin space left, and at the rate spin uses Longs, it is unlikely even a simplified version of these two sbasic programs would fit.
But, thanks to the amazing efforts of hairymnstr, there is a cog free. I don't want to steal a cog so soon after it is created, but with the power of BST's #ifdef command, it is possible to add this code and easily remove it later with one '
Magic packets can be 9 byte packets and can be message type 1 and the type of message is the data byte
Data packets for talking to a board as if it was a user at the keyboard can be message type 2
Pieces of programs (using a bittorrent process) can be message type 3, and are always 128 bytes of data
One can envisage two pasm objects
Object 1 accepts data from within the program and sends it out the serial port as packets. It has an internal counter and sends bytes if x milliseconds have elapsed since a character arrived OR if a buffer is getting full. It sends data to the board that it last received a packet from.
Object 2 receives data from the serial port as packets and translates those packets into 'keyboard' input.
Whether data is processed in this way can be switched off under software control via an OUT port as with things like changing baud rate/screen color etc.
The complex part is translating BASIC into pasm. For instance, a packet might go via many routes in a network and the same packet might arrive multiple times. So the program needs to keep a list of recently arrived packets and only process new ones. Also there needs to be error checking. This is all working in BASIC but I can say that it was not the easiest code to debug and it took quite a few debug messages (now commented out) to get it working. So it may be easier to go for a simplified version, eg just packets containing one data byte, don't try to do 'store and forward' routing as well etc.
Dr_A are these programs for wireless controllers or will they work with just the Dr_A boards and have you written any code that will let us use the second RS-232 port yet?
Yes these programs will work on any of the dracblade boards. They use the second serial port. The modules are pretty easy to connect - 4 wires, 2 for serial and 1 for ground and 1 for 5V. The only catch is you need to program them from RS485 to RS232 and for that you need a max232. If you are doing that please let me know as it needs a quick protoboard circuit (you only have to do this once).
I'm in the middle of version 6 that has the wireless module on the board and a few jumpers for that setup. But it isn't hard to do manually.
But - if you don't have wireless no problems. You can test all this out with two dracblade boards. Connect the port2 ports together with wires that swap pins 2 and 3, and a common ground on pin 5. People call this a 'null modem' cable but really it just swaps pins 2 and 3.
I've been thinking a lot about the protocol layer, which is critical to efficient use of mesh networks. Your packet scheme looks very suitable for the purpose. A couple of comments;
1) Byte counting in noisy RS232 systems can be problematic, although if packets are kept short (less than 256 bytes total) it's less of a worry. One way to counter this is to have the start and stop bytes globally unique and escape other instances of them. Take a look at the Serial Line IP wrapper (SLIP) on wikipedia.
2) I'd like a two byte address scheme where the first byte indicates which network segment the target address is in. E.g. If some nodes in the mesh have wireless, some RS485 and some both, nodes with both could route packets destined for one network from another. This is probably getting a bit more complicated than you were planning. If we limit the number of devices per segment to 128 and number of segments to 128 then the MSB of the first byte of the source and dest address could indicate whether the address is a one or two byte address. So if bit 7 is clear the address is one byte and the packet may not be routed to another segment.
3) What's the checksum you're using?
Toby: No, the original twitter widget no longer works because the twitter API was changed. There is an xml based twitter widget that implements the new REST API. You'll have to get it from the YBox forums on the Adafruit website. (Sorry, I don't have a link as I'm on my Blackberry on the road at the moment.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
DR_A I do have some leftover Max-232 chips I would love to see the add on can I build it myself?? Toby no I didn't want to bug you about it I figured you got busy . The only thing is I salvaged the SD card socket funny thing is it will run most all the prop software just fine
it just dose not seem to care for CPM
Well, after raiding my spare parts and placing orders with four different vendors I now have all the parts on the way to complete a couple Dracblade boards.
One change I made to the build so far is that for the .1 and .01 caps I used some of the small axial lead ceramic parts. The advantage with these is that they are a little smaller and the two for the propeller chip can mount on the top side of the board (like the rest of the parts) and still clear the DIP socket.
If you are still working on the layout for the V6 board there is one change I would recommend. That would be adding one extra pad for the resistor pack used for the serial status LED's. The V5 board is setup for a 5-pin SIP resistor pack. That is an odd size that is harder to come by. I did finally find a place that stocked them but most of the vendors carry 6, 8, and 10-pin SIP resistor packs. By having the extra pad we can just use the 6-pin version which is much easier to obtain.
In the meantime people could still use a 6-pin version and just cut off the lead for the extra resistor.
Robert
Post Edited (RobotWorkshop) : 4/9/2010 7:29:33 PM GMT
After numerous delays I have got the memory test bed up and runing. The KBD and EEPROM swap pins after start up and the VGA is 4 pins P24-27. SD is on P20-23, but plugable, leaving P0-19 free. With Clusso's OnePinstuff the free count could be 3 more ( or 4 more with tweeks ).
Here it is with a "standard" 64KB top board.
And yes I did get the syncs the wrong way around !!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Guys, I tried the latest build last night but I wasn't successful. There seems to be a problem with the SD Card access. I keep getting Er1 at various stages of the boot when the .DSK files are loaded. I dropped back to a previous build and it worked fine. I'm using a Sandisk 2GB SD card.
MaxS: That is interesting as I think the latest version is using the new fsrw2.6 Can someone confirm? I am seeing a similar problem with RamBlade and a user has reported a similar problem with the TriBlade. Maybe it is the driver that is marginal. I thik this requires further investigation.
I now have some time as my Easter visitors have left and I have all my hardware here with me now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I can confirm that the latest version of the DracBlade code is using FSRW2.6 and mb_small_spi (modified to include RAM drivers).
I've seen this error once before, it was caused by me trying the new code using the F10 key and the card being half way through startup with the old driver.
I don't have the hardware to do testing right now, I've not tested 2GB cards, they have some peculiarities which may be causing the unexpected behaviour. (Still definitely a bug that needs fixing though)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr: I am using 2GB SanDisk uSD cards. I did not have any problems with the older femto code. However, I struck problems with a 1GB SanDisk and fsrw2.6. It would just not work reliably at all. I am seeing intermittent problems although today I had 13.5MHz (108MHz) running on the TriBlade without problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I had a homemade DemoBoard running at 14.3MHz early on, but I think that that was the one that I toasted. Now the other four on double sided PCBs with decoupling coming out of their ears, will not go above 12MHz reliably.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Cluso99: Indeed they do for all the data access, however in 2.6 the somewhat convoluted startup procedure now employed to ensure that all variations on the SD card theme (MMC, SDv1, SDv2, HCSD) start up correctly runs in the SPIN layer using write_spi_slow. Once a card has been found and initialised the PASM is started in a new cog and control of the pins passed over. This may be even more important to understand where the SD card is multiplexed with the RAM bus. Check out the start method in the low level sdspi object you're using. This is definitely different from the way FSRWfemto was working, the initialiisation was done in PASM in that version if I remember correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I just put the lastest (I think) version onto the "memory tester", after changing all the pin allocations. On first firing up the A disk showed a string of Hex and for the B disk just a Er1. This was on one of my usually reliable SDs (512MB Integral), I put the files onto a 2GB SanDisk and tried that, which worked. I tried the 512 back again and it fired up ok, this time. Hey-Ho.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I think I fooled myself (not difficult) into using the original code, when I thought it had sprung into life. I have my usual two SD cards just giving Er1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Hmm, this is getting more and more worrying. For now all I can suggest is to use the fsrw femto version until I can get to look at my hardware next week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Just testing the new sd card code. Old code = the only cards I could get to work were 1Gb san disk with fat16.
New code - works with both Fat16 and Fat32. Also I just tested some 512Mb Legend cards which never worked with the old code, but work perfectly with the new code.
A brilliant effort with that sd card coding!
I'm not sure this helps solve the problem others have having. I'm not overclocking. On dracblade v5 the sd card is fairly close to the prop chip.
Re "That would be adding one extra pad for the resistor pack used for the serial status LED's."
Ok, done that. Changed from a 5 pin sip to a 6 pin sip (the last pin is unused).
v6 has a RCA socket for TV, and has room for the RF module. Now I just need to write the code. I'm thinking of some quite complex packet handling code and running this in another CP/M on a seperate 64k memory bank.
With packet networking I've been writing code and the problem is the code ends up rather large. At the very least, one needs to store the last 10 or 20 packets in case that packet has already been forwarded, and with packets up to 256 bytes or more, the buffer to store recent packets could be a few kilobytes. Plus the code in either C or Basic will come to maybe 10kb or more.
So I'm not sure this can fit in spin or pasm. And there is all this unused ram = 448k. So I'm thinking of running two instances of CP/M.
Good point pullmoll re locking. I presume locking is referring to files on the sd card?
Ah, you are thinking of running two cogs with zicog in each? I was thinking more of having one zicog, but with seperate memory for each, and keep the registers for each local. Then you just need to store the registers when changing between them. Later, one can prioritise processing time too - the network processing would be lower priority as it doesn't matter if it runs a bit slow. And we might need to include that line you already have that does the interrupt??
I think there is a special case with the network code. It loads once and then never accesses the SD card again. All input comes from the second port (in the form of packets). All output goes back out the second port, or is passed into the program once the packets have been processed (as if the user had typed something on a keyboard).
So I don't think locking is needed for this case.
I wrote some test code. See attached. Everything is in an #ifdef BankedCPM and this is commented out at the moment. Uncomment it for testing.
Search through for BankedCPM to see the code.
1) There are 26 bytes to store each set of registers. 26 for bank0 and 26 for bank1
2) The location of these are in the recycled keyboard hub code as there is lots of space there, so this takes no more hub space.
3) At bootup, there are #ifdefs to send the same data to both banks, eg boot.dsk gets passed to both banks
4) registers on the second bank are set to zero (otherwise they are the leftover bytes from the keyboard code)
5) switch between banks using OUT statements in any language, eg mbasic OUT &H7F,0 changes to bank 1
I think this is close to working. What I was hoping was to start up in bank0, then run mbasic and type OUT &H7F,0 and it would load up the bank1 registers
PUB SetBank1 ' mbasic 10 OUT &H7F,0
print_regs
bytemove(Registers0,reg_base,26) ' store current registers to reg1
bytemove(reg_base,Registers1,26) ' get bank1 registers
print_regs
'memm.sethighlatch(1) ' bank to bank 1
'vgatext.str(string("Bank 1")) ' send to vga display
(as an aside, @ is not needed as reg_base is already set with an @ and registers0 is set using offsets calculated previously)
and indeed it does do that correctly as the little test code 'print_regs' prints the new registers. What I was hoping is that PC would be zero on this second bank, and the first time this was done it would start up CP/M on bank1.
But I have run into a small problem. I think that not all the registers are held in hub any more. Specifically, in the zicogLMM at the beginning are three lines of code in the pub start
For those interested in the packet protocols, I've been writing some test code in vb.net, with a view to translating it to sbasic or C once it is debugged.
The screenshot below probably explains it better than the code. Take some raw bytes and turn them into a packet. At the other end, decode them.
1) All packets can go via multiple paths.
2) Many copies of a packet might arrive at a node, so the program keeps a list of packets and only adds new packets to the list.
3) Periodically (eg if the airwaves or RS485 cable is quiet) all packets are forwarded on.
4) Any packet that is new and for me is decoded. Bytes might be passed through as if typed on a keyboard.
5) Packets might contain just one byte, or a whole 128 byte record.
6) Destination is a Long which can be decoded to an IP address, so potentially packets could go via the internet if wrapped up properly.
Simple packet 'store and forward' could be done in Spin on a propeller with no external memory or sd card. It is about 100 lines of code.
The process of logging into a remote board, typing DIR, getting the result and logging out involves:
1) A packet that turns on reply on a particular board and gives the return address
2) A program that takes DIR and wraps it up into a packet and sends it out.
3) Decode this at the other end and wait for a response. Bytes that are outputted to the remote screen are also wrapped up into packets and sent out, either when a buffer is full or, for partial packets, when a timer runs out.
4) Collect up the directory listing, which will have come via multiple paths with many copies and possibly not even with the packets in order.
5) Turn these packets into a listing on the screen.
6) Send out a packet that turns off the remote board.
There are a number of different packet types:
1) Simple 'type as if from keyboard' data packets
2) WHO to ask if a board is alive
3) RESET a remote board
4) Turn on a remote board for a session
5) Turn off a remote board
xmodem file transfers ought to work using this protocol though they would be slower than with a direct wireless link.
The aim is to have this code running in an MP/M session so it behaves as if it is in the background for a CP/M user. I have an sbasic version of the vb.net code running ok, but only in CP/M2.2, so the next challeng is to get Juergen's qZ80 code to run MP/M.
Having had no luck with any of the three SD cards, that I usually use, I decided to dig out the "spreadout DracBlade " I made a few months back. This is the nearest to a true DracBlade that I have, it has all four latches and access to the secong serial channel. All the pin allocations are as original too.
On this board the SDs work with the new software so I am assuming that just as there were different points of access to RAM in the DracBlade there must be other point of accessing in the modified SD code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I'm a bit confused with the schematic you are using, but yes, the code hairymnstr wrote includes ram driver code. What is the schematic of the board that does not work?
I am using the v5 version, as a base. As usuall with me I, have bent it a lot to try and free up a load of pins (futile DRAM dreaming).
The Prop part has a couple of 4053 gates to swap the EEPROM pins over to the KBD, after boot up. This is switched by the start of the H syncs ( ok if the VGA fires up before the KBD )
This leaves P0- P27 free, so far. Then I have a four pin (H,V,background and foreground) VGA running on P24-P27, P25 drives the diode pump to swap over the 4053. This leaves P0 -P23 going begging. Then there is the SD which is removeble but has a perch on P20-P23. Leaving me with all the usual stuff and 20 free pins. Serial is the P30-P31 pair.
To prove that the above had not destroyed any chance of DracBlade ever working I made the first top board to be a normal two latch, one '138 decoder 64KB static, all on the usual pins. With suitable mods to the sofware to move all the other pin allocations etc it fired up first time, using old software (pre SD access changes by Hairy etc ). The latest software just sits there with an Er1, although I did see an attempt at mounting A: but then an Er1 for B:
The mb_small_spi.spin uses "Basepin", which is used by the VGAs too, I scanned through to see if that was the problem but I havent seen the answer as yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Well, it's built! Now I just need to set aside some time to setup the Propeller tool again (after rebuilding my laptop) so I can try out some of the code for this.
RobotWorkshop said...
Well, it's built! Now I just need to set aside some time to setup the Propeller tool again (after rebuilding my laptop) so I can try out some of the code for this.
FWIW for the TRS80 and M100 emulators you need a resistor to the TV out and a NTSC or PAL monitor. I don't know if it'd perhaps be possible to write a VGA driver for these two candidates...
I'm currently working on the VT100 terminal for TV out and VGA_HiRes_Text for CP/M, so the next version hopefully supports VGA.
Comments
Attached are the two programs I've been using to network two dracblade boards. I'm wondering about turning them into spin or even pasm.
What this can do is quite useful.
print "1 - Send file to peer" print "2 - Receive file from peer" print "3 - Talk to peer" print "4 - WHO - search for peers" print "5 - RES - Reset all nearby boards" print "9 - BYE - Logoff" input2 "Enter your choice: ";aThe above is fairly self explanatory. Option 3 changes the screen from white on blue to yellow on blue as a reminder that the display is actually that of the remote board. ESC disconnects.
With some careful adjustment of timing and small buffers it is possible to type on a local board and not get interference from the characters coming back.
But this system still does not scale well for multiple boards. The main problem is there are three types of data out on the airwaves:
1) Magic packets #RES and #WHO and the like
2) Raw bytes, eg the listing coming back from a DIR
3) Bytes wrapped up in packets
Already I've run into problems with magic packet interference, specifically where I put comments in a program describing the magic packets and then did an xmodem of that compiled program. The comments were not changed and when the xmodem transfer got to the #RES comment it reset the board. This would be a problem with any ascii string one might want to use.
But the main issue is raw bytes vs packets. Sooner or later they are going to interfere, particularly when a board is listening to raw bytes and is susceptable to random data from packets a long way away, or someone opening their garage door.
So I am thinking that the neatest solution is to only use option 3) = packets.
This leads to the next issue, and that is the inefficiency of wrapping up a single byte in a packet that might be 8 or 9 bytes long. That slows down communication. So packets ought to be of variable length. If bytes are coming through slowly one at a time, wrap them up in individual packets. If there is a whole lot of data in a buffer, put it in one packet.
This is just one format I came up with:
0 start of text = ascii 02 "start of text"
1 number of bytes
2 source
3 destination
4 message type
5 random number (or a counter)
6 to n data,data,data
checksum
endpacket = ascii 03 "end of text"
The smallest packet transporting 1 byte ends up 9 bytes long.
The next issue is where to put this code. In CP/M there is lots of space so as with the attached code, it is possible to write it in a high language like Basic and it will all fit. On the dracblade board there is not much spin space left, and at the rate spin uses Longs, it is unlikely even a simplified version of these two sbasic programs would fit.
But, thanks to the amazing efforts of hairymnstr, there is a cog free. I don't want to steal a cog so soon after it is created, but with the power of BST's #ifdef command, it is possible to add this code and easily remove it later with one '
Magic packets can be 9 byte packets and can be message type 1 and the type of message is the data byte
Data packets for talking to a board as if it was a user at the keyboard can be message type 2
Pieces of programs (using a bittorrent process) can be message type 3, and are always 128 bytes of data
One can envisage two pasm objects
Object 1 accepts data from within the program and sends it out the serial port as packets. It has an internal counter and sends bytes if x milliseconds have elapsed since a character arrived OR if a buffer is getting full. It sends data to the board that it last received a packet from.
Object 2 receives data from the serial port as packets and translates those packets into 'keyboard' input.
Whether data is processed in this way can be switched off under software control via an OUT port as with things like changing baud rate/screen color etc.
The complex part is translating BASIC into pasm. For instance, a packet might go via many routes in a network and the same packet might arrive multiple times. So the program needs to keep a list of recently arrived packets and only process new ones. Also there needs to be error checking. This is all working in BASIC but I can say that it was not the easiest code to debug and it took quite a few debug messages (now commented out) to get it working. So it may be easier to go for a simplified version, eg just packets containing one data byte, don't try to do 'store and forward' routing as well etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes these programs will work on any of the dracblade boards. They use the second serial port. The modules are pretty easy to connect - 4 wires, 2 for serial and 1 for ground and 1 for 5V. The only catch is you need to program them from RS485 to RS232 and for that you need a max232. If you are doing that please let me know as it needs a quick protoboard circuit (you only have to do this once).
I'm in the middle of version 6 that has the wireless module on the board and a few jumpers for that setup. But it isn't hard to do manually.
But - if you don't have wireless no problems. You can test all this out with two dracblade boards. Connect the port2 ports together with wires that swap pins 2 and 3, and a common ground on pin 5. People call this a 'null modem' cable but really it just swaps pins 2 and 3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Did you get mu address etc, for the board? I would like to look at it sooner than later as the new job is only two weeks away now.
Hairymnstr
Did you use the standatd Twitter Widget for your YBOX2, when I tried it (a while back now ) it just sat there. Perhaps the URL was wrong.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
1) Byte counting in noisy RS232 systems can be problematic, although if packets are kept short (less than 256 bytes total) it's less of a worry. One way to counter this is to have the start and stop bytes globally unique and escape other instances of them. Take a look at the Serial Line IP wrapper (SLIP) on wikipedia.
2) I'd like a two byte address scheme where the first byte indicates which network segment the target address is in. E.g. If some nodes in the mesh have wireless, some RS485 and some both, nodes with both could route packets destined for one network from another. This is probably getting a bit more complicated than you were planning. If we limit the number of devices per segment to 128 and number of segments to 128 then the MSB of the first byte of the source and dest address could indicate whether the address is a one or two byte address. So if bit 7 is clear the address is one byte and the packet may not be routed to another segment.
3) What's the checksum you're using?
Toby: No, the original twitter widget no longer works because the twitter API was changed. There is an xml based twitter widget that implements the new REST API. You'll have to get it from the YBox forums on the Adafruit website. (Sorry, I don't have a link as I'm on my Blackberry on the road at the moment.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I still think that using a unique character for the stop bit and escaping the bytes in the data stream that match the special end character.
I found the SLIP RFC (it's fairly light reading and short, well for an RFC anyway) tools.ietf.org/html/rfc1055
Seems pretty simple, I especially like the sending stop before the message to flush the buffers, that's a really neat bit of code re-use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
it just dose not seem to care for CPM
I wouldn't mind. it would just take a bit longer, perhaps.
Sometimes fresh eyes can spot the problem in Nano seconds (that always annoys me)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
One change I made to the build so far is that for the .1 and .01 caps I used some of the small axial lead ceramic parts. The advantage with these is that they are a little smaller and the two for the propeller chip can mount on the top side of the board (like the rest of the parts) and still clear the DIP socket.
If you are still working on the layout for the V6 board there is one change I would recommend. That would be adding one extra pad for the resistor pack used for the serial status LED's. The V5 board is setup for a 5-pin SIP resistor pack. That is an odd size that is harder to come by. I did finally find a place that stocked them but most of the vendors carry 6, 8, and 10-pin SIP resistor packs. By having the extra pad we can just use the 6-pin version which is much easier to obtain.
In the meantime people could still use a 6-pin version and just cut off the lead for the extra resistor.
Robert
Post Edited (RobotWorkshop) : 4/9/2010 7:29:33 PM GMT
Here it is with a "standard" 64KB top board.
And yes I did get the syncs the wrong way around !!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Anyone else had this problem?
I now have some time as my Easter visitors have left and I have all my hardware here with me now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I've seen this error once before, it was caused by me trying the new code using the F10 key and the card being half way through startup with the old driver.
I don't have the hardware to do testing right now, I've not tested 2GB cards, they have some peculiarities which may be causing the unexpected behaviour. (Still definitely a bug that needs fixing though)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The mount code can't be failing because of speed issues because the SPI routines for that run in SPIN.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
New code - works with both Fat16 and Fat32. Also I just tested some 512Mb Legend cards which never worked with the old code, but work perfectly with the new code.
A brilliant effort with that sd card coding!
I'm not sure this helps solve the problem others have having. I'm not overclocking. On dracblade v5 the sd card is fairly close to the prop chip.
Re "That would be adding one extra pad for the resistor pack used for the serial status LED's."
Ok, done that. Changed from a 5 pin sip to a 6 pin sip (the last pin is unused).
v6 has a RCA socket for TV, and has room for the RF module. Now I just need to write the code. I'm thinking of some quite complex packet handling code and running this in another CP/M on a seperate 64k memory bank.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/10/2010 9:20:29 AM GMT
You'll have to use locking then to grant access to the memory to either cog running z80 code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
So I'm not sure this can fit in spin or pasm. And there is all this unused ram = 448k. So I'm thinking of running two instances of CP/M.
Good point pullmoll re locking. I presume locking is referring to files on the sd card?
Ah, you are thinking of running two cogs with zicog in each? I was thinking more of having one zicog, but with seperate memory for each, and keep the registers for each local. Then you just need to store the registers when changing between them. Later, one can prioritise processing time too - the network processing would be lower priority as it doesn't matter if it runs a bit slow. And we might need to include that line you already have that does the interrupt??
I think there is a special case with the network code. It loads once and then never accesses the SD card again. All input comes from the second port (in the form of packets). All output goes back out the second port, or is passed into the program once the packets have been processed (as if the user had typed something on a keyboard).
So I don't think locking is needed for this case.
I wrote some test code. See attached. Everything is in an #ifdef BankedCPM and this is commented out at the moment. Uncomment it for testing.
Search through for BankedCPM to see the code.
1) There are 26 bytes to store each set of registers. 26 for bank0 and 26 for bank1
2) The location of these are in the recycled keyboard hub code as there is lots of space there, so this takes no more hub space.
3) At bootup, there are #ifdefs to send the same data to both banks, eg boot.dsk gets passed to both banks
4) registers on the second bank are set to zero (otherwise they are the leftover bytes from the keyboard code)
5) switch between banks using OUT statements in any language, eg mbasic OUT &H7F,0 changes to bank 1
I think this is close to working. What I was hoping was to start up in bank0, then run mbasic and type OUT &H7F,0 and it would load up the bank1 registers
PUB SetBank1 ' mbasic 10 OUT &H7F,0 print_regs bytemove(Registers0,reg_base,26) ' store current registers to reg1 bytemove(reg_base,Registers1,26) ' get bank1 registers print_regs 'memm.sethighlatch(1) ' bank to bank 1 'vgatext.str(string("Bank 1")) ' send to vga display(as an aside, @ is not needed as reg_base is already set with an @ and registers0 is set using offsets calculated previously)
and indeed it does do that correctly as the little test code 'print_regs' prints the new registers. What I was hoping is that PC would be zero on this second bank, and the first time this was done it would start up CP/M on bank1.
But I have run into a small problem. I think that not all the registers are held in hub any more. Specifically, in the zicogLMM at the beginning are three lines of code in the pub start
and I think what this means is that when I switch to bank1, the PC, flags and SP are still at the bank0 values, because they are local to the cog.
Any ideas or suggestions would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/10/2010 11:34:07 AM GMT
The screenshot below probably explains it better than the code. Take some raw bytes and turn them into a packet. At the other end, decode them.
1) All packets can go via multiple paths.
2) Many copies of a packet might arrive at a node, so the program keeps a list of packets and only adds new packets to the list.
3) Periodically (eg if the airwaves or RS485 cable is quiet) all packets are forwarded on.
4) Any packet that is new and for me is decoded. Bytes might be passed through as if typed on a keyboard.
5) Packets might contain just one byte, or a whole 128 byte record.
6) Destination is a Long which can be decoded to an IP address, so potentially packets could go via the internet if wrapped up properly.
Simple packet 'store and forward' could be done in Spin on a propeller with no external memory or sd card. It is about 100 lines of code.
The process of logging into a remote board, typing DIR, getting the result and logging out involves:
1) A packet that turns on reply on a particular board and gives the return address
2) A program that takes DIR and wraps it up into a packet and sends it out.
3) Decode this at the other end and wait for a response. Bytes that are outputted to the remote screen are also wrapped up into packets and sent out, either when a buffer is full or, for partial packets, when a timer runs out.
4) Collect up the directory listing, which will have come via multiple paths with many copies and possibly not even with the packets in order.
5) Turn these packets into a listing on the screen.
6) Send out a packet that turns off the remote board.
There are a number of different packet types:
1) Simple 'type as if from keyboard' data packets
2) WHO to ask if a board is alive
3) RESET a remote board
4) Turn on a remote board for a session
5) Turn off a remote board
xmodem file transfers ought to work using this protocol though they would be slower than with a direct wireless link.
The aim is to have this code running in an MP/M session so it behaves as if it is in the background for a CP/M user. I have an sbasic version of the vb.net code running ok, but only in CP/M2.2, so the next challeng is to get Juergen's qZ80 code to run MP/M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
On this board the SDs work with the new software so I am assuming that just as there were different points of access to RAM in the DracBlade there must be other point of accessing in the modified SD code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The Prop part has a couple of 4053 gates to swap the EEPROM pins over to the KBD, after boot up. This is switched by the start of the H syncs ( ok if the VGA fires up before the KBD )
This leaves P0- P27 free, so far. Then I have a four pin (H,V,background and foreground) VGA running on P24-P27, P25 drives the diode pump to swap over the 4053. This leaves P0 -P23 going begging. Then there is the SD which is removeble but has a perch on P20-P23. Leaving me with all the usual stuff and 20 free pins. Serial is the P30-P31 pair.
To prove that the above had not destroyed any chance of DracBlade ever working I made the first top board to be a normal two latch, one '138 decoder 64KB static, all on the usual pins. With suitable mods to the sofware to move all the other pin allocations etc it fired up first time, using old software (pre SD access changes by Hairy etc ). The latest software just sits there with an Er1, although I did see an attempt at mounting A: but then an Er1 for B:
The mb_small_spi.spin uses "Basepin", which is used by the VGAs too, I scanned through to see if that was the problem but I havent seen the answer as yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Robert
FWIW for the TRS80 and M100 emulators you need a resistor to the TV out and a NTSC or PAL monitor. I don't know if it'd perhaps be possible to write a VGA driver for these two candidates...
I'm currently working on the VT100 terminal for TV out and VGA_HiRes_Text for CP/M, so the next version hopefully supports VGA.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects