Nothing like a test in the real world to iron out the bugs. It was stuck on drive D (which doesn't exist). I've done a hard reset. I should point out that there is absolutely nothing you can do to this board that would do any permanent damage. Indeed, this particular board was just a pile of chips only 3 days ago. You can even delete files or corrupt them if you feel so inclined.
It has drive A and B only. Drive B just has 3 programs on it that are needed to get the board talking and downloading.
I guess one could think about a reboot circuit that sends a hard reset to the CPU if something doesn't happen for a while.
Then there is the other approach which is to always stay within a BBS program, and set it so that any exit to cp/m just restarts the bbs program.
Addit: I needed some exercise so I took a pick and shovel and dug a few more metres of road. Doing it by hand because it is too steep to get machinery in. Should take about 2 more years at this rate. But my typping muscles don't work properly any more!
I do like logging in and getting the message "the connection is busy, please try again in a few moments".
@MikeS - is the cromenco repairable? Also, nice looking computer there in the photo. I've got 20x4 LCDs which are a little too small for a lot of things. What is yours - 40x8?
Yes and yes: It's an 8x40 Tandy M100; now that I can log in and get a directory the screen is a little messy. Looks like partly the 40 col screen but also a handshaking problem at this end I think, the M100 uses XON/XOFF and I haven't found that option in the Server. More research is needed.
Just logged in with an 80 col terminal and it looks perfect. Going to try xmodem.
Cromemco should be OK if I can find another HD; lots of spares.
Downloaded a couple of files OK with xmodem. Tried to upload Chuck's files and it started well with no errors, but partway through ADVENTUR.COM it got very confused. Could use STAT on that disk to see how much space is available. Tried again to upload to b: but it said there was a disk read error.
but in general it seems to work quite well; I'm running Procomm on a DOS system at 9600bd - no echo and no dropped characters.
Tried another upload of ADVENTUR.COM; out of ~25KB it got to around 5000 without any errors, started having errors, and at ~6000 died and crashed the system with the spurious crap that xmodem was still sending (to the CP/M prompt).
Wonder why file size should matter... anyway, have fun!
Cool - more things are working. I rebooted out of the drive M error - looks like I need to go back to the eprom and redo some code there to block non existant drives. Drive B is read only so this board only has drive A. There are N8VEM boards with hard drives around so this can always grow once the basics are working.
Stat isn't on the board but DIRX will do a DIR and give you the amount of space left. There are several hundred k so disk full is not the problem.
I got HELLO. Thanks for the message!
XMODEM will give up after 10 errors I think, so the probability of a file not going through increases with file size.
I'm looking through some vb.net code I wrote last year and it may have the things needed to hand code a bridge - ie w3sock and all the serial comms. But better if Leif can help us out. It could be that he is batching up a packet after 32 bytes and we need to make it >132. Or something like that.
It looks like xmodem crashes the board and it looks like we have enough info to show xmodem isn't 100% either, so I'm wondering maybe no xmodem for the moment as I'm going out for a bit and won't be able to reset the board. In the next day or two I'll rewrite the CP/M code so it doesn't crash if it gets xmodem data (need to block drive C to Z, and maybe also ignore characters with an ascii value 128 to 255.
I'll also look at BBS software and maybe Leif might be able to be contacted? I might head over to the commodore forum. (as an aside, all these boards are being powered by Commodore 16 wall warts - I got a job lot of 50 when I was a kid for $1 each).
No worries here; I think I've done all the testing I'm going to, at least for now, so if it crashes again it won't have been me.
I may play with the Cromemco a bit; should probably archive some of those 140 MB if I can bring the HD back to life, and while I'm playing I might as well fool around with putting it on the 'Net.
Had the AIM-65 connected but it needs 7bits with parity and I don't think that's an option, so I'm gonna have to dig in the basement for a protocol converter.
Anyway, glad I could help a little bit; it's been fun. Leif's usually at the monthly TPUG meetings but he happened to miss the last one; if/when I see him I'll talk to him, but you can also find his email address at the bottom of his personal page: http://home.ica.net/~leifb/
Ok, it looks like we need some work on xmodem. Henk had the same issue - he says "My experience was that a transfer from pc to n8vem succeeded for about half of the file and then stopped with an error. Sending a file from the n8vem to a pc didn't succeed at all. "
So, we need to work out what is going through Leif's program. It would only need one byte to get missed for it to all fail. Maybe there is a timing issue - eg a program can't listen to a com port and a telnet port at the same time. It ought to be possible to put delays in and also to capture data. I might take this board down (I'll need port 23 free) and see if I can get some simple winsock code working that can echo back some data - maybe send it through a com port and echo it back with a simple loopback cable. Then a remote user could send a pile of data at it and see if it comes back ok.
The other option would be for someone else to try this program and see if the problems come up the same.
Have you got any other protocols that we could try? Xmodem was never the most robust anyway. Ymodem/zmodem/kermit?
It certainly takes more than just one byte; all the transfer protocols have error checking and correction (up to a point). As I said, when I tried it it was flawless for the first few thousand bytes, then it would get the occasional error or two which it corrected, and then finally around 5000-6000 there was a sudden stream of errors which finally crashed xmodem.
The fact that the data is sent as packets within packets could well be a problem; we've had the same problem elsewhere trying to transfer data wirelessly between the M100 in the above picture and a PC since the protocols like Bluetooth etc. also all use packets. Have you tried exchanging data using xmodem over your wireless links?
I'll try to find time to play with it a bit; I did download a file *from* your system without error, but it was very small.
Sorry, xmodem is the only one I've got. Coding a transfer protocol is getting right inside the operating system because you have to grab that packet and save it quickly. It is a long story, but suffice to say that it took many people working over several months last year to get it working. Before July last year getting a program onto a N8VEM meant putting it into an eprom. I can't take credit for fixing xmodem for the n8VEM but more recently I have subsequently coded both the Tx and Rx halves of xmodem in vb.net so I have an understanding how it works. It would be one of the simplest protocols around so if it doesn't work then more complex ones probably won't either. It sends a packet then waits for a NAK or ACK byte. If either of those two bytes didn't go through then it would wait 5 secs or so and then resend. So you would see it slowing down. I don't think that is what we are seeing. Rather, I think the 128 byte packet plus the checksum is not going through. I got two errors - one said "short packet" and the other said "checksum error". The short packet one is interesting because it suggests that the first bit of the packet went through, and the last bit with the checksum, but there were not the full number of bytes. So some bytes went missing somewhere in the middle.
Where would they go? Maybe they didn't get all round the world via the internet. But then again, I get the same errors logging in locally. So maybe they are getting lost in Leif's program somewhere. Perhaps the program polls the serial port, and in that brief moment it misses the next byte coming in via winsock.
At least I can replicate this error locally so I can work on it.
Re wireless, I do have xmodem sending files wirelessly between boards at 1200 baud. That works really well all through the house and outside as well. Uses these modules http://www.yishi.net.cn/index.asp?id=47 (eg the YS-1020U#) Lots of modules have been tried but only these ones in this series can do file transfers because they have a 256 byte buffer. Most modules are 32 or 64 byte, which is too small for xmodem. All the ones on that page are interchangeable - all that is different is the power rating. The 10mW ones are fine round the house. The 500mW ones are overkill and indeed won't work less than 2 metres apart and tend to make CRT displays wobble when they transmit. But they work great outside when you put them up on a high pole. And all the modules in that series have the same plug so you can drop in the right power one for the job. I made a little adaptor board to convert to a D9 RS232 plug. If you are going down that road let me know because I've got 100 of those little boards and I'll never use them all and would be happy to give some away.
I have pondered coding a bittorrent protocol. Ie one that can be terminated in the middle of a file and resume whenever a connection is there, and can handle noisy lines and won't crash on long files on the very last packet. It could be a fun project.
Looks like the protocol's not the issue anyway; I hooked up a couple of PCs locally, i.e Terminal PC A <> Bridge PC A <> Internet <> Bridge PC B <> Terminal PC B (I'm running out of cables/null modems/gender changers ;-) ) and all protocols failed. As a matter of fact xmodem was one of the better ones... ASCII transfer seems OK though.
Unfortunately with my fiddling I seem to have disabled one of them so I can't do any more diagnosing at the moment.
Have you tried any XMTR/RCVR pairs that don't have any buffering at all? I've been meaning to try a set for the M100<>PC link as well as some control/monitor stuff.
Another thing: are you available on MSN or some other immediate chat place? Might be useful to be able to communicate in real time some day while testing this stuff.
Well bad news that it doesn't work but good in that we are both getting the same sort of problem, and it ought to be possible to narrow it down.
Do you mean raw RF modules? The problem with those is that when nothing is transmitting, you get white noise coming out of the receiver. I gather that at 433Mhz this is left over noise from the universe cooling from the big bang. Anyway, UARTs don't seem to like white noise - every now and then they interpret it as a valid byte. So I've had to move up one notch to these modules that output a steady logic level (high) when nothing is coming through. There is a simple picaxe circuit that could act as a raw rf module to serial converter and for $4 for a picaxe chip and $2 for a RF module, and another $4 for another picaxe and $4 for a RF Rx, at $14 that could be cheaper than a Yishi module for $23. But picaxe only has a buffer of 14 bytes which is far too small.
Re instant messaging - search for james moxham on skype. But the problem is I'm only on my home machine a few hours a day - mostly I log in from a large variety of machines all over the city depending on where I am and none of these let you install instant messaging software. This forum works pretty well as a form of instant messaging. If I'm not replying I'm probably asleep!
Looking forward to talking to the cromenco.
re "ASCII transfer seems OK though." - could you try a big pile of ascii in a format like
.. so you can spot a missing character? It would be odd for big slabs of ascii to work but xmodem not to.
I'll be snoozing by then and dreaming of ACKs & NAKs...
Hmm, just saw something interesting: I guess handshaking's working - both systems stopped for a moment and then the receiver "unspooled" 20 or 30 lines or so at (relatively) high speed, the transmitter started up again and they're continuing on their merry way...
Have transferred about 120K of ASCII so far and don't see any errors. Sounds like the same issue we had with Bluetooth: we could transfer ASCII no problem, but the transfer protocols didn't like the packets being chopped up and the relatively long turn-around time.
Hmm, there are differences but I think one of the terminal programs is doing some CR/LF conversion (although I've never seen it quite like this). Will investigate further tomorrow.
Yeah, that was it: LF/CR and pacing; turned off all the ASCII options and the files are identical. Pretty quick too, but then they're both on the same ISP.
Well a big thankyou to all the people who have attempted to and succeeded in crashing the board, because this is the best way to find errors and fix them!
I've got into CP/M and changed a few lines and reburned an eprom:
1) any attempt to access invalid drives now does a warm boot. So it can't get stuck on an invalid drive.
2) I've done an AND 127 after reads from the uart input. This masks out invalid characters 128 to 255 which CP/M chokes on. (xmodem has its own uart read so it won't mind). Hopefully an aborted xmodem transfer will just send stuff for a while then time out after a minute or so and go back to A>
Re the suggestion on the other thread running at the moment on this topic, searching for Lantronix on ebay briings up all sorts of interesting devices. Some as low as $15. It is a matter of knowing what these things are called - 'Terminal Server' is one such term. There appears to be lots of surplus equipment out there. There are also some that don't appear to be quite what they seem - eg they have a row of 8 or 16 RJ45 plugs on the front and look like a router, but the RJ45 are serial ports. Some use a D25 pin plug and use some of the pins for power in and out. It is a matter of going through the documentation for each one, but there do seem to be a lot of choices. They all would use a lot less power than leaving a PC on all the time. The multiport ones might be only $5 or less per port. One could have a whole row of boards running bbs software - cue crazy world domination laugh...