Kermit for file transfers about runcpm HOT 8 CLOSED

Btw ... I have created a discord channel for RunCPM.

https://discord.gg/7aQAGG

I know Discord is a gaming platform, but I use it on a daily basis for both gaming and other projects, so it would make it easier for me to be available there.

from runcpm.

I wonder if transferring MBASIC.COM fails because of 8th bit stripping?
I wrote some programs long ago which are supposed to switch the console between 7 and 8 bits, they are called CONSOLE7 and CONSOLE8 (source code is there).
This is for when I was trying to have a zmodem transfer work between RunCPM and Putty. Which failed basically because I was never able to find a zmodem implementation, so I stuck to xmodem.
Give it a try there ...

from runcpm.

Btw ... I have created a discord channel for RunCPM.

:-(

I don't think that is a good idea. Spreading RunCPM related discussions over too many media will result it being incomplete everywhere. And stuff like Discord is less under our control than Git and friends.

What about a GitHub/GitLab-Wiki instead? It just would be a repository too so storage would be redundant and no evil provider could kill al the talk there.

from runcpm.

We can keep these here for our "offline" discussions, I thought of Discord to be more of an "online" channel, which GitHub lacks.
I have extreme OCD (just kidding), so seeing issues marked as open gives me itches ... lol.
Well ... between this and code compilation warnings ... I might actually have some level of OCD.

from runcpm.

Wouldn't IRC be easier to log and convert if something worth to be keept happens there? And those who are interested in CP/M sure can live with a pure text chat...

https://xkcd.com/1782

from runcpm.

Unload and Load seems to be a solution to the 7th bit problem. One thing that is nice about having several serial ports is I can swap between various terminal emulations and real terminals - eg STAT CON:=BAT: or STAT CON:=TTY:
In terms of OCD and issues being "open", you can close this one as it is 'resolved'. I'm working now on building several little terminals. I have a tiny 1" OLED display that only costs a few dollars and runs on the I2C bus and arduino nano - fantastic for quick testing. Working on larger VT100 terminals using various LCD screens. Today managed to get a PS2 keyboard remapped so the arrow and Home/End/Insert keys output Wordstar commands.
So you can close this issue as resolved.
The one that isn't fully resolved is moving in the official ESP32 SD driver into RunCPM so all the SD cards work properly. I have a feeling based on the demo code it might also run faster. I guess I have a bit of OCD too :)

from runcpm.

This is pretty cool. You should blog about it. (or brag about it, :))
The ESP32 boards are really cool. I think they can be considered the most useful platform RunCPM runs on.

from runcpm.

Update re Kermit. Using the generic version as no need to change things. At one end
KERMIT SEND MYFILE.TXT and at the other end
KERMIT RECEIVE MYFILE.TXT
But sometimes it would work and sometimes not. Of course, it helps to read the instructions (and to use some debug code). The answer is on page 16 of the Kermit Users Guide:
"The key point is to start the receiving end first -- some microcomputer Kermits do not include a timeout facility, and if the receiver is not ready to receive when the sender first sends, there will be a protocol deadlock."
Another thing buried in the instruction manual is that if you do start the Kermit programs in the wrong order and both programs are hanging, hit Enter on the sending Kermit. This wakes the receiver up by resending the start packet.
KERMIT.zip

from runcpm.