Re: [M100] CRC error in 57600 Y
Thanks Brian that is perfectly clear, Just one question if I may ; what's the relationship between having the file "RX#U1.DO" loaded in my M102 (I did that with a serial link, asici upload, to test the upgrade procedure which I didn't finish yet) and the fact to use REXMGR to just load ROM files ? What's the relationship between the two ? I should maybe simply remove the RX#U1 as I don't plan to upgade just yet (I still don't feel I understand the platform enough) and gain more experience with REX# and the M102 regular ASCII uploads first. Also it is unclear why some ROM seem to "start right away" when they are loaded in REX# whereas some other do not. And last question, if I hit F8 I'm back in my M102 files and out of the ROM, but how do I get back in the ROM (like back in multiplan for example) I really apologize for my newbie questions but I'm sure there's a lurker somewhere also learning something thanks to me :-) Le 2022-04-14 04:27, Brian K. White a écrit : > > (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 a écrit : > > > > " TPDD emulator run on MSDOS" > > > > Desklink? > > -- John. > > > > > -- > bkw
Re: [M100] CRC error in 57600 Y
On Wed, Apr 13, 2022, 6:20 PM Brian K. White wrote: > > > 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. > I saw your original post that covered a .PS1 injector and whatnot Might just open it with a text editor and see if there's anything obviously misaligned. The usual corruption of ASCII transfers is because of dropped characters due to no flow control or flow control that is not working reliably. -- John. >
Re: [M100] CRC error in 57600 Y
(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 a écrit : " TPDD emulator run on MSDOS" Desklink? -- John. -- bkw
Re: [M100] CRC error in 57600 Y
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 a écrit : " TPDD emulator run on MSDOS" Desklink? -- John. -- bkw
Re: [M100] CRC error in 57600 Y
Not many people are using it so with limited test time it gets left out of the test matrix. Looks like the client has some dependency on latitude that Laddiealpha and dlplus give that desklink and a real TPDD do not. Maybe max request length? -- John. On Wed, Apr 13, 2022, 3:15 PM Cedric Amand wrote: > Yes, > Bad choice ? > > > > Le 2022-04-14 00:14, John R. Hogerhuis a écrit : > > " TPDD emulator run on MSDOS" > > Desklink? > > -- John. > > >
Re: [M100] CRC error in 57600 Y
I never test with that. Only LaddieAlpha. would be better to cover every possible TPDD, but... I don't have that kind of time! On Wed, Apr 13, 2022 at 6:15 PM Cedric Amand wrote: > Yes, > Bad choice ? > > > > Le 2022-04-14 00:14, John R. Hogerhuis a écrit : > > " TPDD emulator run on MSDOS" > > Desklink? > > -- John. > > >
Re: [M100] CRC error in 57600 Y
Yes, Bad choice ? Le 2022-04-14 00:14, John R. Hogerhuis a écrit : > > > " TPDD emulator run on MSDOS" > > Desklink? > > > > -- John. > > > > >
Re: [M100] CRC error in 57600 Y
" TPDD emulator run on MSDOS" Desklink? -- John. >
