Ongoing issues with XMODEM

[Alexander Rowsell]

Hey folks! Got my Altairduino a few days ago, and immediately spent 2 hours or so assembling it after it arrived... and it worked, first go! I guess my soldering experience has paid off in the long run...

Anyway, one of the major reasons why I wanted to get this kit was to use CP/M and write assembly programs. I want to be able to transfer files back and forth, and so I noticed that (very kindly) the CP/M disk has two transfer programs included, PCGET and PCPUT.

Most of the information I've seen on this forum pertains to using TeraTerm, which is a Windows-only serial terminal. I use Manjaro. So, I figured it couldn't be that difficult, and started poking around with the many serial terminals I've used under Linux.

The first issue is, as others have pointed out, the Arduino can't seem to keep up with 115200 baud when sending large amounts of data. The advice I've seen is to add an inter-character delay (a feature on TeraTerm that has worked for some people). Well, almost none of the serial terminal packages available on Linux support this feature. I finally found one that does -- CuteCom. I also tried sending using moserial, but it doesn't support character delay and it immediately fell over upon trying to send a file.

However. I've now run into another issue. When the serial connection is established, the Altairduino seems to reset itself. This is making things really difficult, as all the serial packages I've used seem to reset the serial interface before starting an XMODEM transfer. In the past, I've used zmodem to send files to my Windows 3.11 laptop, and that worked great using the sz program. But because it's necessary to first connect, type "PCGET filename" and then hit enter, I have no choice but to reset the serial connection.

Earlier today I started writing a python script to make transfers easier. It was going to connect, type out PCGET followed by the filename, and then send the file. Python actually has an xmodem package, which surprised me. However, I ran into the same issue -- the xmodem package doesn't support inter-character delays. So, frustrated, I thought "How hard can the xmodem protocol be?" and started implementing it so that I can control the byte timing. Well, this also has failed -- it does seem to send the PCGET command, but then the Altairduino seems to either crash or reset. The lights stop blinking, it doesn't respond to commands, and then I need to reset and re-load CP/M from scratch (even the reset switch doesn't do a warm boot, which is odd).

So I'm really at my wits end. My final idea is to grab my USB to serial converter, and then send the file on the second port of the 2SIO, as PCGET seems to support that. But that's a bit clunky... however, I may not have much choice.

Any suggestions or tips would be greatly appreciated!

[Gwen Patton]

I know this is a silly question, but did you try lowering the baud rate? Say, to 9600? Expecting an emulated CP/M to keep up with 115200 seems a little optimistic to me. Since all you're doing is moving your own work back and forth, what does it matter if it takes milliseconds or seconds? My first serial terminal was a 110 baud printing terminal with an acoustic coupler. I was just glad data was flowing intelligibly. It's better than zero transmission speed.

Just don't use 1200 baud -- at that speed, the Arduino goes into program mode and essentially wipes itself. You'd have to reload the .ino if that happens. (I had to do that. *facepalm*)

A bunch of years ago, with some tips from Ward Christensen (I was a member of The Ward Board back then), I made an Xmodem program for the Tandy Model 100, in BASIC. It worked fine at the 1200-2400 baud I was using, but I wouldn't expect it to go 115200.

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

--
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/cabb7da7-760e-476b-829a-6ca0606f9dc6n%40googlegroups.com.

[Alexander Rowsell]

Well, the reason I didn't bother trying a slower baud rate was I was under the impression that the simulated baud rate between the Arduino and the "Altair" was already limited to 1200 baud. So I assumed the Arduino was using its RAM to buffer the transferred data and then sending it at 1200 baud to the Altair. This is why the buffer overflow/dropped characters didn't make much sense to me.

I had tried at 19200 and still didn't work. I have it turned down to 2400 baud and it's now sending. And, in a way, it feels a bit more authentic at that baud rate.

It's possible my xmodem implementation actually *is* working, so I'll try it again. At the moment I'm using moserial and it's working at 2400 baud -- I guess the serial interface resetting the Altair only happens sometimes?

Also, 73 de VA3XMR :)

[Brian Decker]

I don't think you understand what the Altairduino actually is - it's not an Altair and it's not really running CP/M.  "When the serial connection is established, the Altairduino seems to reset itself " - this is implemented in the hardware.  You might be able to use a cap on the reset line to keep it from going low or a pullup resistor to hold it high but either way will be a pretty ugly hack.

[Tom Wilson]

The fastest you can reliably receive with XMODEM on the Altair is 9600bps. 

The reset is part of the programming interface on the on the Arduino Due board. The board resets the Arduino when you open a serial connection. If you need the system to stay running, you need to use the physical serial port or wire a TTL interface to the second serial port (which is usually used by the Bluetooth adapter.)

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/f687d1b4-4f34-4483-a958-a9412f96b8can%40googlegroups.com.

--

Tom Wilson
wils...@gmail.com
(619)940-6311 
K6ABZ

[Frank P.]

Just as a FYI... Bluetooth at 9600 works great for XMODEM transfers to CP/M PCGET. For whole hard disks via the configuration menu, it's too slow, so I usually use the USB for that and it works fine because it's talking directly to the Due, not to the emulated Altair.

To unsubscribe from this group and stop receiving emails from it, send an email to altair...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/f687d1b4-4f34-4483-a958-a9412f96b8can%40googlegroups.com.

[Mark Moulding]

I don't think you understand what the Altairduino actually is - it's not an Altair and it's not really running CP/M.  

Well, it's certainly not really an Altair, but I'd have to say that it is really running CP/M.  The 8080 it's running on is emulated, but the CP/M is dead stock; it's not like Z80MU or the other PC CP/M emulators that simulate the CP/M environment as well as the 8080/Z80.

I didn't have any problem making XMODEM work on my AD at 9600 baud (no chance at 115,000).  I initially used PCGET, then sent down a bunch of CP/M software including a hacked up version of MODEM7.  I hacked it a bit more (on the AD itself) and now use that for transfers.

~~
Mark Moulding

[Brian Decker]

" The 8080 it's running on is emulated, but the CP/M is dead stock; it's not like Z80MU or the other PC CP/M emulators that simulate the CP/M environment as well as the 8080/Z80. "

It's exactly like those emulators - with the added issues of running on a much slower processor with far less memory than emulators running on a PC.  The OP wants to "use CP/M to write assembly programs" - and the way it is being approached is pretty crazy.  It's like saying "I want to copy an LP by recording my record player to reel-to-reel to a cassette, then play it back on a Walkman I'm recording to MP3 via a microphone glued to an earbud."  If you are running an emulated version of CP/M you are interacting with the emulator, not CP/M.  It's just an illusion - which is great fun but a terrible environment for developing Assembly programs.

[Richard Deane]

Brian, what do you consider is the best environment for Z80 assembler development, for programs to run under CP/M?

Richard

p.s. I did a lot of software development under CP/M with MagicWand editor /word-processor and the British Transam/TCL Pascal interpreter, which hands-down beat Pascal MTPlus, Pascal/Z and several others (prior to Turbo Pascal being available). Only a little assembler for interfacing into dBase II. Really sad that I can't find a copy of TCL Pascal for CP/M now.

[Tom Wilson]

I'm just going to chime in here with - I don't think it's appropriate to shame anyone for how they choose to use the Altairduino. I bought mine for the same reason, and I still use it to test assembly and BASIC programs (although now I actually write the code in a homebrew editor and load it into RunCPM for initial testing.)

There are also some other nice emulators for PC and Arduino boards.

If you want general CP/M emulation, look at RunCPM. It can run on PC as well as the Arduino. However, it doesn't use the front panel. 

Zeus may be the most advanced assembler/emulator I've seen. It can load both CP/M and ZX Spectrum operating environments, and it has integrated assembly, debugging, and execution environments. 

Tom Wilson
wils...@gmail.com
(619)940-6311 
K6ABZ

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/bbaf9c3f-f16a-4156-ba1d-d5a60293fa9fo%40googlegroups.com.

[Alexander Rowsell]

Any chance I could get a copy of your hacked up MODEM7? :)
That would be awesome. I'm still going to finish writing my transfer program in python - it's actually a GTK+ app so when it's done it should be very easy to use to quickly transfer files.

[Gwen Patton]

Perhaps one of those one-board Z80 CP/M machines available as maker projects might be a potential environment for Z80 assembler development? There's a few at Hackaday. Tindie and Crowd Supply typically have at LEAST one available at any given time.

Here's a sample search on Tindie: https://www.tindie.com/search/?q=CP%2FM

Doesn't look like Crowd Supply has anything right now.

My first few shareware products back in the 80's were written in Z80 Assembler, though I did have a particular love for Turbo Pascal. When Borland came out with Turbo Assembler, I snatched it up, making mad scientist sounds. I got a payment for one of my shareware programs from as far away as Australia. It was quite a hoot. The two most popular were quadprint, a program that would print a specified text file 4 up on an Epson printer, provided it supported elite compressed superscript printing. The font was painfully small, but pretty legible, and it cut down on the size of program dumps and documentation prints. A lot of people registered that one. But the favorite was Foldir. That was a program that would print your floppy directory on a sheet of standard 8-1/2x11 printer paper, with a series of dotted lines and instructions on how to fold along them to make a floppy disk envelope, with the directory listing right on the front face where it was clearly accessible. It replaced the programs that printed your directory, but required you to cut it out with scissors and stick the slip of paper into the regular envelope the disk came in. Inevitably, you'd lose the slip, or it'd get shoved in the wrong envelope, or you'd have to reprint it over and over as you added or deleted files.

With Foldir, there was a lot of room for writing additional filenames on the front, or you could cross out a filename if you deleted it and not lose legibility. When it started to get too crowded or far from the original listing, you could print another one and throw out the old one. This was especially useful if you bought floppies in bulk, as many bulk floppy sales didn't include envelopes. You had to buy those separately. This at least reduced the need to buy additional envelopes. That's the program that was registered by my Australian customer.

Good times, good times.

(I developed these on an NEC PC-8001, with a special 62K TPA version of CP/M. I worked with one of the original US engineers who made their CP/M, and he still had this advanced version, so he gave me a copy. He also gave me a bunch of other stuff, including a second floppy drive, since he was standardized on 8" floppies and I was using 5 1/4". I got the entire computer system from the company I was working at for $50.)

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/bbaf9c3f-f16a-4156-ba1d-d5a60293fa9fo%40googlegroups.com.

[Mark Moulding]

Well, this may be a matter of semantics at this point.  The 8080 is certainly emulated, and hence the whole thing could be considered to be emulated.  However, I maintain that the CP/M itself is not being emulated, but is running in its stock form.  (The Z80MU application and others *do not* work this way - in their case, the whole CP/M environment is emulated, with BDOS calls being emulated as well to access actual files on the host computer; there isn't a single chunk of real CP/M BDOS or CCP present, and most of the BIOS is also a complex simulation.)

I agree that it may not be the most productive environment on which to develop 8080 assembly programs; if I were doing it for real income, I'd certainly use a modern IDE, or at least a modern editor that could be configured to act as sort of an IDE (I do this with an ancient version of Franklin C-8051, which is actually a DOS application).

However, I wrote a whole lot of code on CP/M machines (assembly, Turbo Pascal, and various Basics), and I got pretty efficient at working within the 24x80 terminal screen.  WordStar in non-document mode made a pretty good editor for the time, and I could totally see writing or modifying some decent-sized chunks of code on the Altairduino, just for the fun of it.  In fact, I've already done so, and I found the performance as an 8080 felt pretty familiar.  I do notice that when compiled for Z80 it's a bit sluggish, but that's required to use the Turbo products.  Still, the whole experience was really quite nostalgic - in a good way.

~~

Mark

[Tom Wilson]

I do notice that when compiled for Z80 it's a bit sluggish, but that's required to use the Turbo products. 

 

Don't forget the settings change that optimizes for speed, rather than size. That makes something like a 20% difference - on my system, I get slightly more than 2MHz effective with throttling turned off.

Tom Wilson
wils...@gmail.com
(619)940-6311 
K6ABZ

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/225af8e0-9b72-4b05-80dd-b70361067f05n%40googlegroups.com.

[Gwen Patton]

Hey, all!

All this discussion regarding what's emulated and what isn't prompted me to take my own advice, just because it might be useful. I went to Tindie and bought a kit for the SC131 retro Z180-based RomWBW-CP/M SBC. It looked cute, the price was reasonable, and it looks like a decent device. If it works, I'm ahead. But even if it doesn't, I still think I'm slightly ahead, because the website for this SBC pointed me at the site ASM80.

It's an online development site for...well, it's easier just to copy the "About" page to describe it:

About ASM80

 

ASM80 is an Integrated Development Environment (IDE), aimed on assembler development for 8bit microprocessors, mainly 8080, 8085, Z80 and 6502.
ASM80 contains two main parts: Editor + assembler and Debugger. The whole IDE is web-based, which means you can work with it on every computer where modern browser is installed. You haven't download or install anything; all you need is a browser.
All your files are stored directly in browser, so you need no "account" to "access your files online". They resides in your browser and you can download them as a ZIP file and store to your local computer.
Assembler uses common core, which contains common preprocesor and parser, and specific translation modules for each processor. So the main directives (ORG, EQU, IF-ELSE-ENDIF, MACRO, REPT, DUP) are usable in all source codes for every processors.
You can use inline debuggers in assembler window, which provides basic debugging functionality (i.e. stepping or registry access). There are real computers emulators too, so you can test your programs directly in them.

I thought it bore exploration. Perhaps this might be useful to some of you, who might want something more unified to do development work on. I only just discovered it, so I'm still going through it, but it looks really interesting and useful to anyone doing *80 programming (and 6502 as well? bonus!)

Here's the Tindie page for the SC131 Pocket CP/M Computer Kit: https://www.tindie.com/products/tindiescx/sc131-pocket-sized-z180-romwbw-cpm-computer-kit/

I can see this kit working alongside the Altair-Duino, to help with development and debugging, as well as both dovetailing with ASM80.com to help round out the development tools for the 8-bit environment. I'm looking forward to building this kit, and I'll keep everyone updated on how it goes and how well it works (or not). Looks like I'll have to get a PROM programmer, though.

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/CALt8mqR9ZGd8Uyc%3DyF9Rwvp2EBmu6PkgUNz9oB4SA8J2_Z2Xeg%40mail.gmail.com.

[Mark Moulding]

I have the SC131 - it's just as cool and cute as it appears in the description.  I leave it plugged into my main computer all the time, and when I need a break I'll go fire up my H-19 emulator and play a bit of Adventure, or tinker with some old code.  It's a really nicely-done implementation.

@Tom Wilson - thanks for the pointer about changing the compiler optimization; that sounds like just what I need.

~~
Mark Moulding

[Richard Deane]

Some handy tips if you have an sc131:

From memory, so if I miss anything you can get back to me and I will look up the detail.

1) SC131 has no rtc so if you want to set cp/m3 time and date you can use a teraterm macro to pull down the time date from the host pc, saves  a lot of typing. Then don't power the sc131 off. I posted details in either rc2014 or retrocomp group - can't remember which.

2) There is an easy change in romwbw build process for sc131 (186 cpu) to tweak clock multipliers to run the system at double speed.

3) Only port A (default console) has hardware handshake, sometimes you might prefer the other port to have handshaking to support peripherals when the console doesn't really need it. The trick is to tweak romwbw to switch use of port A and B so B is the default console, and port A is left for your peripherals that need the handshake.

Steve Cousins wrote good doc so you shouldn't have any problem building SC131.

If you use the dev build of romwbw you can boot from any slice number,  the release build doesn't have that fix and is restricted to the first few slices.

Richard

To unsubscribe from this group and stop receiving emails from it, send an email to altair...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/225af8e0-9b72-4b05-80dd-b70361067f05n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.

To unsubscribe from this group and stop receiving emails from it, send an email to altair...@googlegroups.com.

[Gwen Patton]

Sounds like I made a good choice, then!

I love retro computers. Like I said, some of my earliest programming was 8080/Z80 under CP/M. I also did some Z80 work on multi-user Oasis (later called Theos), mostly on Altos iron, but some on IBC iron. Those were fun systems to work on. I almost bought one used and put MP/M on it, but I would have had to get terminals for it, and those were too pricey for my tastes at the time.

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/781b0e15-92e6-4dcb-b075-32a9617b1ebfo%40googlegroups.com.

[fred]

Alexander

xmodem uses 128 byte packets. CP/M systems "back in the day" would support 9600 baud (1000 cps) just fine.

I would use minicom or picocom. 

xterm -fa APL2741 -fs 20 -ti 340 -j -u8 -e sudo picocom -b 115200 /dev/ttyACM0

is what I use... rx/sx for file transfer -- works out fine. And, notice that the connection IS at 115200

But, using USB cable.

[Andy]

I'd be very interested to run MP/M... I wonder if we'll ever see it supported on the Altair Duino or the IMSAI 8080esp... even though purists may disapprove :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/781b0e15-92e6-4dcb-b075-32a9617b1ebfo%40googlegroups.com.

[Mark Lawler]

Thanks!  Setting the baud rate down to 9600 is what got my XMODEM program finally working.  Was able to use PCGET and XMODEM to transfer master Wordstar files to a floppy disk image and patch / install for VT100 emulation.

Best,

-Mark

[Gwen Patton]

Another good terminal program I've started using is ExtraPuTTY, a fork of PuTTY that contains some very nice features, including multiple file transfer protocols and a session manager. Unfortunately, it's a Windows-only program. I just mention it here because some Windoze users might find it useful. I use it with my SC131, and will probably use it with my Altair-Duino, when I hook it up again. (My computing/radio stack is a bit haphazard right now, and I'm in the process of tearing it down and rebuilding it. When I get it rebuilt, I'll have the AD back online, along with the SC131.)

http://www.extraputty.com/

Not to try and hijack anything, but I just want to mention that I have had good results in my first tentative steps in cross-development in Pascal. I've got Turbo Pascal working on the SC131, and have successfully transferred the same program over to my Windows platform, where I compile the same program using Lazarus, Free Pascal, and a DOSBox version of Turbo Pascal.

(The mermaid on the desktop is actually my own avatar in Second Life.)

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/cfa4b6e4-b70c-4cfd-93fb-0a7a147d4fa8n%40googlegroups.com.

[Mark Lawler]

Thanks!  I failed to mention that I was using the XMODEM capability within ExtraPutty.  That said it works great for downloads vs PCGET on the Altair, but when I do a PCPUT with ExtraPuTTY using XMODEM receive feature I'll be damned if I can find where the file lands up on my laptop.  Although the dialog box claims it is going to C:\Program FIles\ExtraPuTTY\Bin I don't see any files there.  Trying to put a path in the receive filename doesn't seem to work either.  

Best,

-Mark

[Gwen Patton]

I haven't tried doing transfers from the Altair-Duino because I don't have it set up right now (probably sometime after I build the Plus expansion), I instead was using XM.COM on the CP/M distro that came with my SC131. Since the SC131 uses a Z180 processor, it's optimized for Z80 CP/M, and I don't know that it would run on the 8080 emulating Altair-Duino version. It uses the RomWBW distro, which can be found here: https://smallcomputercentral.wordpress.com/firmware-romwbw/ The applications supplied include XM.COM, so if you think it might help to give it a try, you could see if XM.COM would run on an Altair-Duino. No idea if it uses any Z80-specific code, but I guess it might be worth a look.

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/77b034cd-4b0b-4238-bb67-2916583cc6f3n%40googlegroups.com.