(re-sending from a different account, I sent this earlier but it never
showed up)
Desklink is fine, and that checksum message is probably about the
initial ascii transfer of RX#U1.DO . It's easy to get a corrupt copy
with a manual ascii transfer, and so it has a self-check that it runs
before doing anything else, to prevent running a corrupt copy.
Expanding on that,
The old dos desklink works perfectly well, but that doesn't neessarily
ensure it will work with rex/rex# setup, because rex setup doesn't even
work with a real tpdd1 or tpdd2.
There is a weakness in the tpdd routines in the rex tools, which makes
"bad choice?" a complicated question to answer. It's a perfectly fine
choice for everything else, but may or may not be a good choice for this
specific task.
Steve has a few times in the past that he only tests against Laddie
himself. If you use anything else, it may or may not work, but if it
doesn't he doesn't care.
I use dlplus on linux and it always works also on most machines, but I
have one old laptop where it doesn't. (works for everything else but
just not for rex setup) The only thing notable about that laptop is that
it's an old netbook with an atom cpu, so it's slow. Works fine on every
other machine I have, and dlplus works fine even on that netbook for
everything but the rex or rex# setup util. So if you have an ms-dos
machine, that is probably old and slow also, although that should still
be fine for doing this because of just running dos with no other
processes at all stealing cpu and a real com port, vs a full multiuser
linux os with 500 other processes plus using a usb adapter for the com port.
So, all in all, I'd say desklink on dos should work fine, even with the
rex utils pickiness.
However I think that is all beside the point. Your problem is probably
not the tpdd server but the initial ascii transfer of the setup program
itself. There is an initial self-check that verifies the initial
transfer of the RX#U1.DO program itself to the 100 in the first place.
If you're using a plain comm program to manually send the program
instead of using a dedicated bootstrapper program that nails down all
the variables and details just for exactly this reason, then it's very
easy to get a corrupt transfer. So Steve has a self-check to catch that.
In another post which possibly hasn't posted yet or possibly went to
spam, I gave a lot of links and details to garanteed ways to do it,
which uses a dedicated bootstrapper program to send the initial RX#U1.DO
and either dlplus or laddiealpha for the tpdd server. These are known to
work. Anything else is "might work". But the bulletproof simple ways
currently need windows or linux or mac. There is no bootstrapper for
ms-dos. (Well, the original dos desklink does supposedly have a
bootstrapper function by creating a file named loader.ba and then you
can issue a command from the 100 to trigger it, but I've never got that
to actually work)
So if you still want to use ms-dos on the host side, you'll have to do
so trial & error to figure out why you're getting a corrupt transfer of
the initial RX*.DO file. Doing it manually leaves many opportunities for
leading junk, trailing junk, bad line-endings, and dropped characters
from gpoing too fast. You'll have to say *exactly* what you did or else
there is no way to guess what might have gone wrong.
Also if the host is not really dos but is really windows, then try with
laddiealpha for the tpdd server and tsend.ps1 for the bootstrapper.
See my other post for all the details on that.
--
bkw
On 4/13/22 18:15, Cedric Amand wrote:
Yes,
Bad choice ?
Le 2022-04-14 00:14, John R. Hogerhuis <jho...@pobox.com> a écrit :
" TPDD emulator run on MSDOS"
Desklink?
-- John.
--
bkw
