Re: [M100] CRC error & misc : UPDATE
The possibility of having a wrong main rom installed didn't even occur to me. That is like a huge variable that throws everything else out the window and all bets are off. Patching for y2k is one thing, but you can't just pop the US rom in a UK machine. The only mis-match you can really get away with is you can safely run a T102 rom on a M100 (of the same country) However someone did just recently actually hack a US rom to work on a UK machine, as well as squeezing TEENY into it somehow. https://twitter.com/sarahkmarr/status/1503342266148134912 They didn't post the rom itself anywhere in that twitter thread that I saw anyway, but they did on their facebook post give a link to a copy on bitchin100 https://bitchin100.com/wiki/images/8/84/Sklm100rom.ZIP https://www.facebook.com/groups/Model.T.Computers/permalink/5463538800373253/ https://www.facebook.com/groups/Model.T.Computers/permalink/5400646646662469/ https://www.facebook.com/groups/Model.T.Computers/permalink/5384516054942195/ https://www.facebook.com/groups/Model.T.Computers/permalink/5371746809552453/ So if you have UK hardware and for whatever reason don't want to run it's correct rom, (for instance, because REX only supports US/NA machines) you may possibly be able to run this one since it just happens to also target UK hardware. Though I'm not sure if that one works with REX or REX# either. If they had a REX or REX#, then I presume they wouldn't have been very motivated to build TEENY into the main rom since they'd have the even better TS-DOS in option rom already. It purports to be specifically compatible with US software that needs a US main rom, so maybe. But if what you have right now is a UK hardware with a normal US main rom, then you can't expect it to work. If it runs at all, it's just lucky. Any problems are to be completely expected. -- bkw On 4/14/22 10:15, Cedric Amand wrote: Just wanted to post an update about my recent issues. As I kinda suspected, not knowing the history behind my M102 with a REX# (that I bought "as is"), has been a huge hassle. After trying to play with ROMs today, suffering from many crashes, CRC errors, and such, the M102 suddenly lost all it's RAM, including my files, the time was lost, and the REXMGR vanished. It was back in january 2000 and l lost all of my stuff. Luckily I did use REX to save a memory dump a couple of days ago. Now... Having an empty M102 ( not my doing ) I thought "ho , hell ; let's go for it" and I did a complete reset, and reinstalled the REX software from scratch, then made an update from 2.0 to 2.1/ (all of that with a DOS pc running Desklink) And I had no issue whatsoever in the whole process (apart from guessing filenames) And now : everything works properly. I think my REX# was in a semi broken state causing all kind of weird issues. Also I now have "program names" in the main menu for ROMs, so obviously I understand how to enter them now (I didn't have that!) Switching between ROMs seems to work as it should (it starts right away) and you hit F8 you're back in main menu; and then you have a "shortcut" to restart your ROM program. None of that was working properly. I really don't know in what "state" my REX# was, maybe it was corrupted in some way, but I guess I'll now have less stupid questions as the freaking thing seems to work as it should now. I'll I think spend some time creating a youtube video (if nobody did that) to explain how to install/upgrade REX# , using vintage tools ( DOS/desklink ) I'll also try to make my own ROM as I'm kinda sad that I lose my built-in modem capabilities (this is a european model with an US ROM because of REX). I'll try to overwrite the modem section of the ROM and see what this does. Thanks again to Brian, John & Stephen for their support, some of which I printed :) -- bkw
[M100] CRC error & misc : UPDATE
Just wanted to post an update about my recent issues. As I kinda suspected, not knowing the history behind my M102 with a REX# (that I bought "as is"), has been a huge hassle. After trying to play with ROMs today, suffering from many crashes, CRC errors, and such, the M102 suddenly lost all it's RAM, including my files, the time was lost, and the REXMGR vanished. It was back in january 2000 and l lost all of my stuff. Luckily I did use REX to save a memory dump a couple of days ago. Now... Having an empty M102 ( not my doing ) I thought "ho , hell ; let's go for it" and I did a complete reset, and reinstalled the REX software from scratch, then made an update from 2.0 to 2.1/ (all of that with a DOS pc running Desklink) And I had no issue whatsoever in the whole process (apart from guessing filenames) And now : everything works properly. I think my REX# was in a semi broken state causing all kind of weird issues. Also I now have "program names" in the main menu for ROMs, so obviously I understand how to enter them now (I didn't have that!) Switching between ROMs seems to work as it should (it starts right away) and you hit F8 you're back in main menu; and then you have a "shortcut" to restart your ROM program. None of that was working properly. I really don't know in what "state" my REX# was, maybe it was corrupted in some way, but I guess I'll now have less stupid questions as the freaking thing seems to work as it should now. I'll I think spend some time creating a youtube video (if nobody did that) to explain how to install/upgrade REX# , using vintage tools ( DOS/desklink ) I'll also try to make my own ROM as I'm kinda sad that I lose my built-in modem capabilities (this is a european model with an US ROM because of REX). I'll try to overwrite the modem section of the ROM and see what this does. Thanks again to Brian, John & Stephen for their support, some of which I printed :)
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
