Re: [M100] CSS issue on Wiki
John,
This was indeed a tricky one :o)
The problem is caused by the rule on lines 1602-1604 of load.php (I
don't know the internals of Mediawiki, but I suppose this PHP script
is generating a CSS file):
.mw-hide-empty-elt .mw-parser-output:not(.mw-show-empty-elt) .mw-empty-elt {
display:none
}
I see two ways to fix the problem:
* First solution:
Your graph is in a table with the CSS class "graph".
The parent element of this class is a div with class="mw-parser-output".
If you can modify the class attribute of this div for
"mw-parser-output mw-show-empty-elt" that will solve your issue.
* Second solution:
Just before the table element of the graph, there is a style element
containing the CSS rules for the graph extension.
If you can edit this element, you can add the following rule:
table.graph .mw-empty-elt {
display: block !important;
}
You could also try removing the "mw-hide-empty-elt" class from the
page body, but I cannot be sure that this wouldn't have side effects
on other Mediawiki features.
Cheers,
Eric
Re: [M100] VIDEO - Dial-A-ROM for the Model T computers (and others)
I've just seen the video, and this is definitely a great idea. If I understand correctly, the working principle is that the rotary encoder sets the higher bits of the eeprom's address pins. The "classic" RC2014 (the original model with 32KB RAM and 8KB ROM, not the new fancy ones with 512+KB that run CP/M) uses something like that with jumpers (it has a 64KB EEPROM and 3 jumpers allowing to choose 1 of 8 ROM images). I didn't like having to mess with jumpers everytime I wanted to switch ROM, so a couple of years ago I made a small PCB to replace them with an Attiny13A (the cheapest available MC with enough pins at the time). I wonder if something like that could be implemented on top of the Dial-A-ROM because this is incredibly convenient to use on the RC2014. Basically, the Attiny selects the ROM by setting the higher bits of address of the EEPROM. It also monitors the reset signal, and whenever it's low for more than 2 seconds it selects the next ROM image (it keeps switching image every 2 seconds while RESET is low) and when you release the RESET button, it saves the newly selected ROM number in its internal EEPROM for the next cold boot). Here is a picture (this is the green PCB) : http://pics.lefauve.org/PXL_20230226_224656582.jpg The 3 LED show the currently selected ROM number. They're always on but I think that if we connect their cathode to RESET instead of GND, they will just light up while the RESET button is pressed so it shouldn't have too much impact on the battery life. The one jumper on the PCB is just here to force A15 to Vcc, which is convenient for me because I'm using a 32KB EEPROM at the moment; that shouldn't be needed with the M100. The main issue I can see is that it would still require removing the trapdoor to see the leds when switching ROM image, which kind of defeats the "instant option ROM switch by the press of a button" but perhaps one of you guys will come with a solution for this? ;o) Cheers, Eric
Re: [M100] Pinenut Wifi / BLE
Hiraghm wrote: > I came across this tiny little board on the Pine64 site, and I wonder... I considered the same thing with an ESP-01 ( https://www.ebay.com.au/itm/195354250177 ). The idea was to find a couple of resistors on the M100 motherboard that could be lifted to isolate the actual modem from the uart in a non destructive way, and then use one of those tiny level shifters for the interface ( https://www.ebay.com.au/itm/174302572365 ). The default firmware of the ESP-01 recognizes AT commands so it should be easy to use it like a modem, and it is possible to set its baud rate so it should work at 300 Bauds which IIRC is the M100's speed when communicating with the modem. I had the parts around for a couple of years now (ESP-01 were very cheap back then) but before I attempt anything, I'd like to hear from you guys with way more experience than me if it has a tiny chance of working, or if I've totally overlooked something that would make this hack impossible. Cheers, Eric
Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated
I wrote: >FWIW, I also tried "caching" the result of "PEEK(P+1)" but again, >it didn't change the result (in all 3 implementations, 1000 >iterations took 14 seconds, so those modifications aren't really >interesting, except for the brain picking exercise ;o)). Well, I managed to (almost) half this time :o) : 8 seconds for 1000 iterations! I'd like to say I found a very innovative solution, but it's so simple I wonder how we didn't think of it before... Just let the BASIC do the work for you :o) 10 DEFINTP-Q:DEFSTRH 20 H=CHR$(201) 30 P=VARPTR(H)+1:Q=VARPTR(P) 1000 POKE Q,PEEK(P):POKE Q+1,PEEK(P+1) 1010 PRINTP "John R. Hogerhuis" wrote: > As to type sigils on variables... Don't know how much it changes ram use > or execution time. Some! Maybe look at the tokenized output difference > for the space difference. Thanks, I may give it a try. BTW, is there a good documentation of the tokenized format (and of the variables encoding) for the M100? I learned a lot about the ZX-Spectrum BASIC by reading the user guide which gives a lot of implementation details about this, but I don't remember the M100 user manual going so deep. > If it goes over 32767 on any permutation of peek'd values it will fail. > Probably worth generating every permutation and confirming it > works. I suspect the integer conversion is only made when the value is stored in the integer variable. For example, this totally works: A%=1E15/1E14:?A% The only thing to be careful with is using functions that can only work with integer arguments like \ or AND: ?1E15\1E14 => OV Error ?!E15AND1E14 => OV Error Eric
Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated
"John R. Hogerhuis" wrote: > 10 DEFINTP:DEFSTRH > 20 H=CHR$(201) > 30 P=VARPTR(H)+1 > 1000 P=PEEK(P)+256%*(PEEK(P+1)+256%*(PEEK(P+1)>127)) > 1010 PRINTP Very nice. That seems a little more optimized than the solution I used for my "direct file access from RAM" implementation :o) You could skip the second multiplication by using AND instead: 1000 P=PEEK(P)+256%*(PEEK(P+1)-(PEEK(P+1)>127AND256)) (Note that the sign has been reversed) but... somehow the execution time isn't really impacted (I suppose multiplying by -1 is fast) FWIW, I also tried "caching" the result of "PEEK(P+1)" but again, it didn't change the result (in all 3 implementations, 1000 iterations took 14 seconds, so those modifications aren't really interesting, except for the brain picking exercise ;o)). If I may ask a question, I almost dever used DEFINT and DEFSTR: I just use "%" or "$" prefixes for my variables. Are DEFINT and DEFSTR faster or is this a question of personal preferences? I kind of like that I can tell the type of variables by their name, but if the other solution gives a performance boost I'm ready to reconsider. Eric
Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated
"John R. Hogerhuis" wrote: > ?MID$(H$,A/16+1,1);MID$(H$,AMOD16+1,1);" "; It would be slightly faster with: ?MID$(H$,A\16+1,1);MID$(H$,(AAND15)+1,1);" "; 1 iterations takes 5:43 vs 7:23 with your version (I tested on VirtualT, so it may not be 100% accurate but that should be a good estimate). The biggest difference is the integer division, which to be honest surprised me, since the variables are already integers. Perhaps they are cast into regular (float) values before the division is attempted? While we're into BASIC optimizations, another good trick is to declare your variables (just assign anything into them at the beginning of your program) in reverse order of use (i.e. the ones you access the most often first). When I wrote my version of Conways Game of Life, it saved me more than 10 seconds per generation. Eric
Re: [M100] parallel printer
Peter Noeth wrote: >I use a Seiko DPU-414 thermal printer with my T102. It has both parallel >(Centronix) and serial (9 pin female D-sub) connections. It runs off 6v >external (same power barrel connector and polarity as the M100), and has >provisions for an internal rechargeable Ni-Cd type battery (4x AA cells). >Got it off eBay a number of years ago as a "pull" from some sort of ATM >machine. They can still be found around the internet. It takes a 4-3/8" >thermal paper roll (available on Amazon), and is a nice size match to the >computer, if you want portability. I got about the same idea, except since I couldn't find one with a parallel interface I got a serial/BT one with the idea to use an Arduino Pro Mini to do the parallel to serial conversion. The big advantage being that since there is software running on the Arduino, I can do some interesting things like emulating the escape sequence of the most popular printers of the time, or the special characters of the M100. But it didn't work on my first try and I kind of lost interest... I'm still glad to see I'm not the only one coming with this idea. I may try to look into this Seiko DPU-414 someday since it seems to work out of the box ;o) Cheers, Eric
Re: [M100] Writing binary files from BASIC
B 9 wrote: > For public domain databases, what occurs to me are: >- The CIA World Factbook >- MAME arcade games >- Various genomics and scientific nomenclature for the tree of life Thanks for the idea. I found a MAME database that could be what I need. No way to fit all the DB in 32KB, but I can probably fit all the games released until 1983, which is if I remember correctly when the M100 was released :o) Don't hold your breath, though, since I still need to fix at least one of my M100 before I even think about starting. Cheers, Eric
Re: [M100] Writing binary files from BASIC
B 9 wrote: > Good idea, but I can't as I am going to be indexing into the file given a > fixed record size. I wrote a "very simplified" DB system where I used CO files for my data. Basically, I just peek and poke directly when into the files without loading them into BASIC. It works well, allows you to use most of the available ram for your data, and is very fast to seek a record from its number (or its name if you go the extra mile to have an index file). Of course, you have to be careful because any misplaced poke may screw your whole filesystem, but if you have a REX for baking everything up before trying your code it's doable. Also you shouldn't write any other file (using regular BASIC files functions) after you fetch the base addresses of your CO files because it may change the file position in RAM (it will probably work if you refetch this base address, but I didn't try it). The only thing I didn't do was allow creation of new records (I have a fixed size DB of records I consult and/or edit). >> If you want to create a binary file, you need to create a CO file by >> saving a range of memory to a CO file. To create the initial contents you >> would POKE your bytes into a reserved region of memory. > >That would be the simplest way, but I'm trying to avoid duplicating the >file in memory. Has anybody ever tried first creating a .DO file of the >correct size in BASIC and then twiddling the RAM Directory's attribute byte >so that it is a binary file? Once I have the file's address, I could just >poke directly into it and save the copy. Right? Or am I missing something? >(For example, after creating a file, does the Ram Directory get updated? I >already noticed that I need to use CLEAR at the start of my program since >the file pointers are stale after doing an EDIT in BASIC.) I did this with a CO, not a DO. To be clear, you don't have to "load" it before PEEK/POKE into it because it's already in RAM. So basically: - you create a CO file of the size you want (you only do this once) - you wrote a BASIC subroutine that finds its position in RAM by parsing the files directory in RAM (note that it may change every time you run your program so you have to do it at runtime) - Then your BASIC program can POKE directly into this file I may try finding some of my code if you want something to start from. (also I did that a few years ago, so I may be forgetting some details about how it works) Cheers, Eric
Re: [M100] M100 freezes at menu
Joshua O'Keefe wrote: > After cutting out (and not replacing) the battery, the machine > starts, prints the menu, and then freezes. In this state the > clock is not advancing. My second M100 has this exact problem. I found out that the pin 10 of M18 (D1990AC) wasn't outputting a 256 Hz clock like it should, but I didn't get a chance to fix the issue yet. I'm thinking to just change M18 with the one on my donor motherboard but if you find another fix I'm interested. Note that the Service Manual says pin 10 clock should be 250 Hz but it's actually 256 Hz. Eric
Re: [M100] my m100
Peter Vollan wrote: > My Model 100 keeps getting into that state where the menu items call up the > wrong program. Why does this happen? I did have the same problem for a while. I kept refreshing the memory from a REX backup, but after a few days the problem was back. I thought it was my fault at first because I was doing some unnatural things to the filesystem, but I eventually found out one of my Memory modules was faulty. I'd like to say that changing the module fixed the issue but I did find the faulty memory module while trying to fix another issue (bad Vee and unusable display) so I still haven't had a chance to confirm the problem is solved. Eric
Re: [M100] Need help fixing VEE on M100
"Jeffrey Birt" wrote: > Welcome to the fun world of leaking electrolytic capacitors. Trace damage > like this is > very common and if someone replaces the capacitors without properly > mitigating the > damage the corrosion will continue to spread and get worse. 'Half-way' > repairs cause > as many problems as the original failures. Thanks for confirming what I was afraid of :o) Well, I guess I'll just have to do this then. I have everything except the paste flux and nail polish, but that should be easy to find. Thanks again for the very detailed instructions! Eric
Re: [M100] Need help fixing VEE on M100
Le lun. 22 mars 2021 à 19:05, Eric LK a écrit : > > I didn't recapped this unit because the seller I purchased it from > told me he did it a couple of years ago, but I think I'll just follow > your advice on this (also, I'm not sure he did clean the flux). > > I already have the caps so I guess I know what I'll do next week-end :o) I eventually freed some time to look into recapping this unit, but I kind of stop in the middle to ask for some advice: Looking at the PCB, I could confirm that the unit has been recapped recently as the previous owner said, so I tried to first change only the caps near the power supply (C82, C83, C84 C85, C86, C90 and C92). I tested all of them, and they appear to be in specs, so I had a good look at the PCB under the caps I removed, and I think that may be the problem... I put some pictures on http://pics.lefauve.org/Recap2021/ (that were taken after using IPA, an "electronic cleaning solvent", more IPA and a glass fiber pen; it was looking worse before...). I'm a little concerned about some of the caps pads and their connecting traces like C82, C85 and C86. I've never come across this kind of damage before and I'm not sure how to continue. My first thought would be to replace the caps, and to use the schematics to check the continuity between each of those cap legs and whatever they're supposed to be connected to, bridging any non-conductive trace with some wire but I could really use any advice you have before risking to make everything worse :o) Eric.
Re: [M100] Cassette-emulator
Steven Ranft wrote: > Has anyone tried using a Digital Voice Recorder? I actually tried and was successful using a TASCAM DR-05 digital recorder to save and load programs from a Jupiter Ace last week-end (full disclosure, that was an Omni128HQ in Jupiter Ace mode; I'm not the lucky owner of a real Jupiter Ace :o)). The tricky part is that the output signal from the computer is quite high compared to voice, and even at the lowest available recording level, I still got some "peak" alerts (the led that blinks when the signal is too loud). Also I had to disable all automatic "sound improvement" features but it did work reliably in the end. I couldn't try with a M100 because I don't own the needed cables but it should work if you can find the correct recording level. I used 24bits WAV mono files at 44.1k sampling rate (you can probably be good with lower settings, but I didn't want to take any chance to lose the saved data). Now, this is not exactly great on the "user friendly" side. I suppose you could connect the recorder to a PC and rename the files you saved so you can find more easily which one contains what, but if I had to use this on a daily basis I'll try to find some cheap TZXDuino and adapt the firmware to support the M100. Eric
Re: [M100] Need help fixing VEE on M100
"Jeffrey Birt" wrote: > On the M100s I have found most of the caps tend to leak (and cause PCB > damage). > While I am NOT a proponent of 'recapping' every piece of vintage gear out > there on > the M100 I do a full recap on every one of them. I didn't recapped this unit because the seller I purchased it from told me he did it a couple of years ago, but I think I'll just follow your advice on this (also, I'm not sure he did clean the flux). I already have the caps so I guess I know what I'll do next week-end :o) Thanks for the advice :o) Eric
[M100] Need help fixing VEE on M100
About 6 months ago, my M100's LCD contrast was very weak and impossible to use. Following your advice, I changed C82 and C85 . That gave me a solid -5V for VEE and the contrast was back to normal. My problem is that 6 months later, I can still read the screen (mostly) but my VEE is now back to -3V. I'm tempted to replace C82 and C85 again, but I think it's weird to get the same failure so quickly after a fix (both new capacitors were new from mouser). Do you see anything else I should check regarding this issue? Eric
Re: [M100] vga monitor solutions
Message: 9 Date: Wed, 20 Jan 2021 19:28:40 -0500 Stephen Adolph wrote: > Eric, thanks for pointing this out: No problem Steve, I spent a lot of time playing with those when I was a student :o) I don't have a real vt100 to test, but I tried on putty and if you can lock/unlock the last line (line 24 iirc) with ESC+[;23r and ESC+[;24r , to prevent it to be overwritten when the text scrolls, it doesn't survive a CLS :o( Also the cursor position is reset, but something like ESC+7+ESC+[;23r+ESC+8 should fix the issue (ESC+7/8 saves/restore the cursor position) > Other commands > *lock and unlock scroll > * delete line at cursor > * insert blank line > > I scanned those codes again and did not see for example "delete line at > cursor", which erases all characters in the line and scrolls the screen up > at that line. I found a clumsy way to emulate the "delete line" (you have to insert the line number in the sequence) but couldn't think of anything for the other commands. If you have implemented them in the MVT100 firmware, I think that's the best solution :o) Eric
Re: [M100] vga monitor solutions
Since we're thinking outside of the box, couldn't we replace the FTDI with a small arduino board? Something like an Arduino Micro or even a Digispark should do it. Then, it should be possible to convert the M100 additional ESC codes to their VT100 equivalent on the fly and we will just have: M100 ---> Arduino ---> Android tablet (that will only work with the BCR mod, but you could add a max232 if you want to use the serial port instead) If the Android OTG doesn't recognize the Arduino as a serial port, I suppose we could just add a Digispark between the FTDI and the M100: M100 ---> FTDI ---> Arduino ---> Android tablet. Stephen Adolph wrote: > In M100 BASIC, you can lock the bottom row of the screen to show the > setting of the Function keys. Such a function does not exist in standard > VT100. We should be able to do this by setting the bottom margin of the scrolling window using the DECSTBM escape sequence ( https://vt100.net/docs/vt100-ug/chapter3.html#DECSTBM ). That being said, since I don't have a spare Android tablet, I think I'll go with a MVT100, a 7" LCD module from eBay (like this one: https://www.ebay.com.au/itm/7Inch-Lcd-Display-Module-mi-Vga-Socket-50Pin-1024X600-Ips-Monitor-Screen-K9W3/184527783134 ) and some 3D printing. Since the LCD and the MVT100 will be very close, I think I can ditch the VGA connectors and cable, and directly solder the MVT100 to the LCD controller board, which should make a compact solution. I'm hoping to build something comparable to the Omni128HQ monitor, which can be screwed under the M100 using the existing screw holes, but it will take some time before I can start looking into it (I need to fix my M100s first...). (https://retroradionics.co.uk/#!/OMNI-128HQ-LAPTOP-SCREEN/p/116017737/category=0) Eric
Re: [M100] life
Gregory McGill wrote: > http://ftp.whtech.com/club100/gam/life1.ba > http://ftp.whtech.com/club100/gam/life1.do > http://ftp.whtech.com/club100/gam/life2.ba I tried them on VirtualT. I love the board editor, but they don't handle screen wrapping at all :o( For example if you have a glider, it will stop working as soon as it will reach one border. Here is my take at the Game Of Life in case someone is interested: http://lefauve.org/M100/Conways/CONWA3.BA And here is a ready to use glider for testing: http://lefauve.org/M100/Conways/GLIDER.DO The "BA" is a real BA (not an ASCII file) saved by VT. Again it has been tweaked for being fast so please wear adequate protective gears before looking at the code :o) There is no menu or documentation but when the BA starts, you can enter either a number of living cells for a random starting state or a DO filename (without the ".do" extension) like the provided GLIDER.DO. It takes about 1:12 minutes per generation, but it's a lot more fun using VirtualT and the "Max speed" setting (I got about 2 FPS). For the DO files, don't have more than 16 lines of 80 characters in them or it will crash; anything which isn't a space will be a living cell; you don't have to complete the lines or even to have 16 of them. Eric
Re: [M100] life
I wrote one in BASIC a couple months ago. It's pretty simple (80x16 cells, can load a DO as starting generation or generate a random one) and... very slow (about 1:15 minutes per generation). The code is pretty awful because I used every trick I could to make it faster, but I could upload it somewhere if you want. I made a Z80 assembly version for the RC2014 but I didn't have time to do the same for the M100 version (and both my M100 are currently not working :o( ). Eric
Re: [M100] PC file transfer fun..
Hi Desi,
Desi Villaescusa wrote:
> 1: Is there a good character to add to the end of my BASIC programs when I
> transfer them? ("." is working, but if there is a more apropriate one)
If you're copy/pasting your basic files into putty, you need to press
Ctrl+Z after you pasted (or typed) the BASIC code.
That will send the proper EOF character (ASCII code 26) and you won't
have to kill anything or have an error message.
But be careful to not directly append the EOF to a text file
containing your basic source because if you later try loading it using
TR-Dos and a proper transfer software (mcomm or laddie alpha) that
would corrupt your M100 RAM filesystem (I think recent versions of
laddiealpha would strip it for you but don't quote me on this).
> 2: I take it I need a new USB serial adapter? I probably should be able to
> do more
> than 600 baud??? Recommendations?
I think the problem is your serial cable and or
nullmodem/genderchanger adapter, not the USB-serial adapter. There is
a schematic in the mcomm manual which worked for me.
(you'll find it on this page:
http://www.club100.org/memfiles/index.php?direction=1=mod=Kurt%20McCullum
)
You need some pins to be connected, and some others to be unconnected
(I had to drill into my gender changer adapter to make it work at full
speed). If you don't have the correct pin to pin mapping, it will
"kind of work" but you'll have issues at high speed (also on some
machines you may notice the contrast will decrease dramatically as
soon as you connect the cable to the M100).
While searching for the mcomm link, I found this wiki page that may be
useful to you (I didn't tried it) :
http://bitchin100.com/wiki/index.php?title=Diagnose_DTR/DSR_and_RTS/CTS_issues
> 3: Is there a program to de-tokenize an M100 BASIC program? I have found
> some BA files that are tokenized, and I am thinking detokenizing them might
> be the easiest way to transfer them over?
The easiest way would be to use a real TPDD emulator on your PC, like
mcomm or laddiealpha and something like TS-DOS on the M100. A search
on the list will give you everything you need to know about those, but
keep in mind they may not work at all until you have a proper cable.
Good luck!
Eric
PS: I just seen John has replied some of your questions already, but I
already typed this so please excuse the small overlap with his reply
:o) )
Re: [M100] Need some advice for fixing a couple of M100
Well, it seems that changing C85 and C82 did the trick :o) I got a chance to unsolder one of D14 legs and it gave a more sensible reading (0.7V in one direction, open circuit in the other). I tried testing C85 after removing it (with a cheap chinese components tester) and it registered as a diode so I think that was the failing part. I also replaced C82, and got -5.2V for Vee. The only trouble is I got a few contrast flickering in the first few minutes (normal, then very low again, normal again, etc...). It seems normal now but I'll keep an eye on it (it may not be related but testing D14 and D15 still gives a different result than on my other "working" M100). Also because I didn't used it for a while, I obliterated one of my REX banks trying to restore it (totally my fault, I should have read the message before pressing "Y", but if I may suggest a new feature to Rex Manager, perhaps displaying a warning when it's launched with caps-lock on could help). It's a good thing I had backups :o) Thanks again Josh for pushing me in the right direction! Your advice was very helpful :o) I'll probably post some questions about my second broken M100 in a couple of weeks, but for now it's time to have some M100 fun. Eric
Re: [M100] Need some advice for fixing a couple of M100
Thank you Josh! Yes I'm testing them in-circuit, but that was the case in both the tests, and I get different readings, which makes me think they were faulty. I did consider lifting one leg, but the reason I didn't is I'm not sure how to re-solder it after testing because it's cut really short. Is there a "trick" to do this kind of very short lead re-soldering (that's probably a skill I'll need if I want to keep my old computers in working order :o) ) I have a few C82 spares too so I guess I'll start swapping them and see how it goes. If it's not too much trouble to look into your last order, that would be nice to get a replacement reference for those diodes just in case (and also I have another M100 board where D15 is missing) Eric PS: In case it matters I also tested on two non-working M100 boards and I got the same readings than the "working contrast" M100 (except for the missing D15) Josh Malone wrote: > Are you testing the parts in-circuit? You need to at least disconnect one > leg to check them reliably. I'd recommend replacing C85 and C82 regardless. > There are others I'd suggest if that doesn't help. > > I can look and see what parts I last ordered for these if you want.
[M100] Need some advice for fixing a couple of M100
Hi, About one year ago my two "good" M100 stopped working almost at the same time. I haven't got any time to look into them yet, but I really miss taking notes on a M100 so I'm trying to get them working again. The first one kind of works but the contrast is ridiculously low, and you can only see anything if you look almost perpendicular to the screen with contrast dial to the maximum. I had a look at the Service Manual, and find out the issue is probably caused by Vee being at -2.4V instead of -5V. The same service manual says to check D15, C85 and D14. That's where I'm starting to be out of my comfort zone... My multimeter has a diode testing function, and I definitely get suspicious reading of D14 and D15: For D14 I get 0.1V in both directions (black lead on the cathode, or black lead on the anode) and for D15 I read 0V in both directions too. On my second M100 (which has another issue but the contrast and Vee are fine) I read respectively 0.5V and 1.4V for D14, and 0V and 1.5V for D15. I don't know how to check C85, but having recaped the second M100 a couple years ago I have some spare left so I suppose I can just change it if fixing D14 and D15 desn't work. At this point I think (tell me if I'm wrong :o) ) that the next step is replacing D14 and D15, but I wasn't able to find the exact same reference listed in the service manual. Is there an unofficial list of available modern parts for the M100 somewhere? Here are the closest things I have found so far. Could someone tell me if they have a chance to work? (or recommend a known working alternative?) D14 is listed as "DIODE, SILICON, ZENER, RD5.1 EL1 (QDZ5R1EL1A)" and I found some "Fairchild BZX79C5V1 5.1v Zener Diode" ( https://www.ebay.com.au/itm/Fairchild-BZX79C5V1-5-1v-Zener-Diode-x-10-/164107867434 ) D15 is listed as "DIODE, SILICON, 1S2076 (QDSS2076#B)" and I found "1S2076A HIGH SPEED SWITCHING DIODE DO35" ( https://www.ebay.com.au/itm/50pcs-1S2076A-HIGH-SPEED-SWITCHING-DIODE-DO35-/252644110156 ) Thanks! Eric
Re: [M100] MIDI with the Model T
Tom Wilson wrote: > Some other devices, such as certain models of Sound Canvas and a > few varieties of Yamaha XG sound models actually have a serial port > interface built right into the machine. So you could send MIDI data to > one of those without needing the level conversion. > > The only issue is that I'm not sure if or how the serial port can be set > to the correct baud rate. MIDI runs at 31250 bps. I'm not sure how the > T100's UART is programmed at the machine level, so that could be a > concern. Not sure about the MT-32 or other models but I own a Roland SC-88 and there is a switch on the back of the unit allowing to chose between 31250 and 38400 bps. Note that the serial connector is a mini-din and you will need a specific cable, but Roland was kind enough to give the cable's wiring diagram in the SC-88 owner's manual Hiraghm wrote: > I've been reading recent threads about someone using the cassette > interface as a secondary display interface. I suppose maybe that > could be used, instead, too... The Roland serial cable uses handshake signals so you may need to simulate that to know when the MT-32 is ready to receive the next midi frame, as the cassette interface hack only gives you one TX line (unless I missed something :o) ). > So is this idea crazy? Impossible? Waste of time? As long as you're having fun figuring it out, that's never a waste of time ;o) Eric
Re: [M100] M100 only displays black blocks
Hi again! John R. Hogerhuis wrote: > That doesn't always do the trick, if it's crashed it will ignore the > keyboard. Meanwhile the "memory power" NiCd keeps the corrupt zombie RAM in > its corrupted state. Thanks for the advice John. It actually unfroze it but only for a couple of minutes during which the M100 did a few weird things, most notably removing the BASIC entry from the menu. After it got stuck again, I tried to use the memory power switch again, while (trying to) shot a video of the result: https://youtu.be/LbVGxcP0OpA I apologize for the shaking camera and... for the unexpected visit and support of my cat :o) As you can see, every time I power cycle the M100 or press reset, something different happens. BASIC is missing, but it seems I was able to open TEXT and create a text file. Most of the time, parts of the menu display are missing, or replaced by black blocks, and every now and then the M100 froze after beeping or displaying some prompt text like "FILE TO UPLOAD?". After reading the "Recovering an unresponsive laptop" page, I made a last attempt leaving the memory power switch off for 15 minutes (I only waited 30 seconds on my first attempts). It didn't help. > Since it only took a months to corrupt your RAM I would also be suspicious > of the internal NiCd. If you haven't replaced it chances are it's 20 some > years old and needs replaced. According to its previous owner, this M100 was recapped and the NiCd battery was changed about 2 years ago, but I'll look inside and try to find something wrong (I'm not that good with hardware...). Fugu ME100 wrote: > Must be the fall season?.. Sorry to read this :o( Did you try the memory power switch trick? Eric
[M100] M100 only displays black blocks
Hi, I usually use my M100 at least once or twice a week but I was away for almost a full month, and when I turned it on yesterday, it decided to take a break :o( When I turned it on, it was OK for about 3-4 seconds (the time for me to look at the menu clock, and to check on my watch it was still on time) and then the screen become white with a few black lines (notably the first and last lines). I pressed a few keys, hoping for a refresh problem, and then used the RESET button, which cleared the screen (I could still see the white pixels when turning the contrast dial all the way up though). I tried a few time to power OFF/power ON, or to do a cold reset (Shift+Break+RESET) but the result didn't change: Every time I got either a totally white screen or a white screen with a few black blocks (here is a picture: http://pics.lefauve.org/M100-Blocks.jpg ). I tried to press ENTER + beep + ENTER to check if only the display was affected but I got no beep. I also tried to remove the REX but it didn't have any effect at all. I checked the batteries (5.5V) and tried new ones. Still no changes. Any idea what I should try next? That was my "good" M100, so I really hope I'll be able to fix it. Eric PS: The whitish square visible on the picture was already there before the problem. It's usually clearer than the rest of the screen, but the text is still visible (probably one of the LCD controllers about to die...).
Re: [M100] pcb2molex8878
Brian White wrote: > Astonishingly, I was just able to print a functional carrier in PLA on a > Creality CR-10S. (A very common home $400 fdm printer from a year ago.) Very nice result! It looks like you printed it flat on the bed. If I may make a suggestion, you may try to print it on the side (rotated 90º along the long side). I'm saying this because thin printed parts like the side bits (which I assume are used to remove the carrier and PCB from the M100) can easily break along the layers separation. It looks like it could be a problem to remove the carrier if one or both of them would break. If you print on the side, it will probably take more time and you'll need a few supports but at least if the part break, it would be parallel to the long side of the PCB, and you'll still be able to pull the side bits to remove it (also, I think it would be a lot less likely to break). You may want to use a brim or a raft to avoid bed adhesion issues since there will be a lot less contact between the bed and the carrier. Gary Hammond wrote: > If the layers delaminate, the hot end temp is too low. > If the bridging sags, the hot end temp is too high, or you don?t have > sufficient cooling on the job. > If you see ?ripples? in the vertical sides, the drive belts need tightening, > or tolerances on the X/Y axis are sloppy. > If you see stringing, try more retraction. A good guide to diagnose and fix printing quality issues is the Simplify3D one: https://www.simplify3d.com/support/print-quality-troubleshooting/ They give good advises and you don't need to use Simplify3D to apply their solutions. Eric
Re: [M100] Serious REX Problem
Peter Noeth wrote: > I was doing some BASIC programming on my T102 using the Text editor. I > put it down to attend to the laundry, and came back 15 or 20 minutes later > to continue on with the T102, where I found that typing on the computer > produced garbage characters on the screen and then the computer locked up. > REX was enabled at the time. I did have the same behavior a couple of time on my M100 except I didn't lost any data. What happens IIRC is that when the auto power off kicks in while TEXT is running, when I switch the M100 back on (with power off/power on) the screen is covered with garbage characters. However only the display is corrupted so if I press F8 it exits normally to the MENU, and if I reopen my text file everything is fine. I never had the problem before I got a REX so it's probably related, but it's (at least in my case) a very small problem compared to all the comfort added by the REX. I'm using version 4.9 by the way, and the option ROM was probably TSDOS100 (that's the one I use the most). Eric
Re: [M100] Small REX issues
Thanks for your advises! I think I'll start by backup everything on the PC, and "reformat" the REX (deleting all RAM images). It seems easy enough to backup whole RAM images as "BY" files from the REXMGR so I'll do this regularly in case anything goes wrong in the REX's flash :o) I'll also have a look at TBACK when I get a chance . I think I already asked this on the list, but is there an easy way to create a new empty RAM image for the REX? The only way I found to create a new image is to clone an existing one, and to delete every files in it. I tried to save an "Empty" RAM image for this purpose, but I'm starting to wonder if that wouldn't be the cause of my problems... Eric
[M100] Small REX issues
Since there is some talk about REX on the list, it may be a good time to ask a few questions I have about it :o) I've been using the version 4.9 of the firmware with a M100 for a few months. First, there is this thing in the documentation that I'm not sure to understand: > REXMGR has to be located as the FIRST .BA program in RAM for the embedded ML > code to function. Does that means that the REXMGR should be listed in the menu as the first program right after SCHEDL? I'm asking because this isn't always the case for me, and I wonder if it could be related to the "file swapping issues" I have every now and then (opening a program from the menu opens another one instead). Also, I noticed a few error in text files from time to time (i.e. a character is changed to a "n" with tilde; It's pretty unlikely that it could be a typo). That worries me a little because since I got a REX, I've become a little lazy with RS232 backups :o) (I just press Ctrl+B from the menu after a day of work, hoping that even if something goes wrong with internal RAM I could still do a cold reset and reload the image from the REX). Is that supposed to be a reliable enough backup solution? Could those problems indicate there are other issues with my REX, or with the M100 itself? Eric
Re: [M100] hterm
>> 3. I downloaded two files: HTERM.CO and HTERM.lst. I'm guessing I only >> need >> the .CO file and my question is how will I get it transferred into the >> M102? >> Using the built in terminal ap? It seems I need to get it on the menu some >> how. >> > > Well, that can be tricky. Depends on what you're working with. > > REX/TS-DOS and a TPDD-emulator (LaddieAlpha, Mcomm, DLPlus) is the best > way. But there are other ways like we could make a ASCII BASIC poker, or we > could use TBACK.EXE. Before I got my Rex, I used the DOS100.DO file provided with Mcomm. It works well but you may need to send it at a very slow speed since the M100 serial buffer is easily flooded with xon/xoff (that may work better with the M102 though). Once you get this working, transferring hterm.co should be easy You may try this method first but on the long term a Rex will make your life ways easier. Oh, and check and recheck that your serial cable has the right pinout (that's the number one issue :o) ). Eric
Re: [M100] Using HTERM on a M100
Eric LK wrote: > I was using the "?" character[...] That wasn't the question mark character of course but the "Latin Small Letter E with Acute" which was scrapped by the mailing list :o) You can type it on the M100 with Code+d. John R. Hogerhuis wrote: > Well if I did it, I'd probably create a .NET command line app. Then it > would be cross platform and I could reuse the code in other projects. I'll have a look, but don't hold your breath since I'm a little short of free time at the moment. I'll probably go into some simple C program just using stdio, though. That should be portable enough and I won't have to find out how to install a .NET development environment. > Whatever works :-) That's the spirit :o) Eric
Re: [M100] "Smart" watch fun
John R. Hogerhuis wrote: > But the coolest thing about it for me is that it lasts for almost a week > and has an always-on transflective color display That sounds like a PebbleWatch screen :o) It's good to know there are alternative out there since Pebble is now out of business. > If someone made a Model T today, I think a display like this would be a > good fit. Low power, sunlight readable, longer battery life without the > need for backlight in some conditions. By the way, is there any work in progress to find a replacement screen solution for the existing M100? I'm just asking because my two working M100 has more and more screen issues everyday, and I'd like it if we could just retrofit a new more reliable screen (I don't say the original one wasn't reliable, since it's still usable after 30 years, but you see what I mean :o) ). Eric
Re: [M100] Using HTERM on a M100
John R. Hogerhuis wrote: > It does map in both directions... what are you seeing? > I don't map every UTF-8 character :-) There are a lot. I was using the "é" character, but I found the problem: Since I'm using a QWERTY keyboard, I use numpad code ALT+130 to type this character. When I do this in a text editor, the correct character is displayed and when I save the file, the correct UTF8 encoding is used, but it seems that PuTTY literally sends the character 130. When I use the "Character Map" Windows application and paste the character in PuTTY, I receive the correct character on the M100. > [...]I'd like to add some UI to set the baud rate but haven't gotten around > to it. If it helps until you do this, I've wrote a short basic program that displays the current baud rate of HTERM, and allows to change it by poking into the CO file (of course, that will only work with the same version of HTERM :o) ). I suppose I could stretch it to also allow setting parity, number of bits and stop bits if needed, but I'm not sure that would add a lot of value. > In the meantime, maybe you or another member would consider writing a > stand-alone filter program or script to convert UTF-8 to M100 ASCII based > on the mappings above? I actually started an AWK script for that, but I never finished it since I used an easier workaround (typing my notes in English, so I don't need any non-ASCII character ;o) ). I suppose I could finish it, but I'm not sure how to turn that into an actual stand alone application (I have a few ideas for Windows and Linux but the last time I used a Mac, we were in the 80s). Eric
Re: [M100] Using HTERM on a M100
Thanks for all your replies! I just wasn't using the correct baud rate. I thought that even with the wrong serial settings I should see some kind of garbage characters on the other side, but it seems I was wrong :o) John R. Hogerhuis wrote: > - Match baud rate... you can rebuild with a different baud rate. It > supports all rates including 19200, 38400, 76800. I'd like to add some UI > to set the baud rate but haven't gotten around to it. I'm pretty sure your > version is set for 38400. Thanks John, that was indeed 38400, 8 bits, 1 stop bits and no parity. I tried to have a look at the lst file to figure how to change those settings. If I understand what I see on lines 92-98, and the pages 178-179 of "Hidden Powers of the M100", the maximum speed seems to be 153600, but it seems impossible to set the speed to 115200 which is what I was looking for in the first place. Is that really impossible? If the characters transition works well from the M100 to the PC (putty, using UTF-8), it doesn't seem to work on the opposite direction. Did I miss a setting on the PC side or is it supposed to be this way? Also I couldn't not notice that in the source you have some parts about the directory structure of the M100. Does that mean there is a way to save session to a file, or to send a file over the RS232? (I'd love this feature, if just to translate the special characters into readable UTF-8 :o) ). Thanks again! Eric
[M100] Using HTERM on a M100
Hi, I'm probably missing something very obvious, but I've tried everything I could think of and I'm out of ideas :o) I've been trying to use HTERM on my M100, but all I get is a white screen, until I press F8 which exits the application and returns to the menu. I found the application on the http://bitchin100.com/wiki/index.php?title=HTERM page and didn't had any issue loading or launching the HTERM.CO file (I don't think this is an HIMEM issue). I just cannot figure out where are the instructions to configure and use the application... I even tried sending DATA from the connected PC at various speeds, and nothing happen. I may just be very tired, but I would appreciate if someone could push me in the right direction. Eric
Re: [M100] Tandy Assembly 2019 Sep 27-29, 2019 in Springfield, OH
On Sun, Jun 2, 2019 at 5:13 PM Jeffrey Birt wrote: > I splurged a few weeks ago and picked up that Microcolor unit on eBay. It > will be a few more > weeks before I can get to it but I would love to get it working and bring it > to show. Jeff, I happen to use the TMS9928A a lot at the moment (working on a Colecovision Homebrew). You probably won't need it :o) but feel free to ask if you have any issue with the Mikrokolor's video chip or its supported video modes. Cheers, Eric
Re: [M100] Tandy 200 azerty rom
VANDEN BOSSCHE JAN wrote: > Q to list: how can I make a ROMdump from BASIC? Here is how I did this on my M100 using TS-DOS and mComm on the PC side (probably also works with LaddieAlpha or other disk emulators) : - Launch TS-DOS and activate the dos extension (press F5 until it says "DOS-ON") - Go to basic - Use savem to save it in two halves (it seems savem won't let you write 32KB at once) : SAVEM"0:rom1.co",0,16383,0 SAVEM"0:rom2.co",16384,32767,0 - On the PC, use a tool of your choice to remove the first 6 bytes of those two files (that's the header of co files) and save them with a ".bin" extension (or anything you fancy, but you'll have to change the last step accordingly) - Then, concatenate them into one file (from Windows shell : copy /b rom1.bin+rom2.bin rom.bin) If someone knows a "smart" way to remove the header, I'd like to hear it (I used emacs but it has to be a better way :o) ) Cheers, Eric
Re: [M100] 100/102 to USB?
Mike Stein wrote: > That's something you read in many places, but as long > as you've selected XON/XOFF handshaking at both ends > there shouldn't be an issue using 19,200 baud, especially > when uploading from the M100. I thought this too, but I couldn't get sustainable transfer using anything above 58e1e (I also tried without the parity check but it didn't work better). It seems the serial buffer of the M100 is too small for reliably use xon-xoff. However you do have a very good point about uploading the data. Assuming that the Mac on the other end has a a proper xon-xoff support you should be able to go full speed in this direction (you probably don't even need xon-xoff since this would be a very slow speed by today standards, but it shouldn't hurt to use it :o)). > You'll also find it will go faster if you use TEXT to load/save > (using "COM:98N1E" as the file name) instead of TELCOM > because the M100 won't have to scroll the screen which > really slows things down. Thanks for this trick. I'll try to remember it next time I cannot use TS-DOS. Eric
[M100] DB API for M100 BASIC (was Re: 100/102 to USB?)
John R. Hogerhuis wrote: > I suggest for data entry just use TEXT. You can use tabs or commas as field > separators, CRLF as record separator and then import using tab separated > CSV on your desktop. Very little overhead this way, maximizing use of your T's RAM. Thanks for the advice. That was the first version I made, but it had a few problems for my case. - Not all data I wanted fitted in the 32KB - Loading it in a basic program to do data reports took about one minute (and also limited the data volume since they had to fit twice: once in the file and once in basic's RAM) I ended up using CO files to store my data in binary. It's very interesting for integers since they take only two bytes each instead of 1-5 bytes + 1 byte for the separator. Also I stored my strings in a separate CO file, so the main data file has "fixed length records". This allowed me to implement a simple random access file support. And most important, I no longer load the files in basic RAM, but instead parse the directory structure to find the file's address in storage RAM and peek/poke directly in it. >If you want to get really fancy you could make a BASIC program that > would process the DO file and format search results on screen. I actually re-implemented the "DO files forms" from Lucid-Database as I found it was a very clever way to do this. I cheated a little with "formula fields" by basically using them as "hooks entry points" for basic subroutines (so it's more an DB API for BASIC than a stand alone DB engine) but it does the job. At the moment I have 809 records and 15430 bytes of data + 1682 bytes of index and the "loading" takes about one second (the slower part is the loading of the form.do which uses basic files functions). Finding a record by record number is too quick to me measured, and searching a record by string search takes between 0 and 4 seconds (I'll probably try rewriting this part in assembly as soon as I read a good book about it). This is a fun project so far and since it's really a pet project and I have no deadline I tried to do the maximum only using the M100 instead of using the PC to pre-process the data files for the fun of it :o) Because of this, when I calculated the index files used for alphabetic research it took the M100 about 7 hours (it's a good thing I had an AC power adapter). It's not totally finished yet but if someone is interested in how I did this I'd be happy to share the code and share things I've learn in the process. Eric PS: Before starting this, I also tried T-Base but it wasn't as nice to use as Lucid, and also entering/editing data was very slow
Re: [M100] 100/102 to USB?
Thomas Morehouse wrote: > Thanks gentlemen. I'd used serial cables (null modem) for transferring > files between DOS and Windows machines before. Forgot about the 100/102 > Telcom method. If you use TELCOM, I'd recommend you keep the speed at 1200 or 2400 bauds. While the M100 can do 19200, I had a few issues using faster speed until I got a proper cable and started using mComm/TS-DOS. > I'm creating a database of all the aircraft we have at the New England Air > Museum. Sounds cool. :o) > Much easier to use my 100, walking from plane to plane, than my Win10 > laptop. Once created, I'll import the data into our main ResourceMate > cataloguing system. Are you using Super-rom? I was puzzled by the features of Lucid and Lucid DB. I tried to use them for a pet project of mine but the 250 records/table limit made it impossible :o( Eric
Re: [M100] BA files got swapped
Thanks for your reply John! I'm not sure however what LNKFIL is? (is that a rom subroutine? I didn't finish reading "Hidden powers of the M100" yet :o) ). Shortly after my last message the two files got swapped again and this time I made a copy of the directory structure using "savem". It took a few days but the files eventually came back to their original position and I saved again the directory structure so I could compare them. Here is the diff : http://pics.lefauve.org/M100-Directory-diff.png We can see that: - an empty file slot (file type = 0x00, used to be "TS-DOS") became "DIRC.CO" which is the file containing the corrupted directory, so that's normal - both MKAX.BA and PGKOD.BA entries actually exchange their address and nothing else (0x813c and 0x8785) So that's weird... Also I'm not 100% sure but I think I may have read somewhere that the REXMGR should be the first file entry in the list after the builtin ones (basic, text, telcom, addrss and schedl) and in my case. I cannot find this again and I may be mistaken but it seems there are two hidden files (types 0x88 and 0xc8) and a deleted file/unused slot (type=0x00) before the REXMGR entry. Could this be the issue ? John R. Hogerhuis wrote: > More likely you loaded a corrupted file I didn't load any file into this REX bank but I didn't find an easy way to create a new empty bank with REX... So basically when I want to create a new empty bank I duplicate an entry without too many files and I delete them one by one. Could this be the reason I ended up with a corrupt structure ? (and those two hidden files?) Is there a better way to do that? At some point I emptied a bank image, and duplicated it with the name "EMPTY" trying to use it as a startup empty image but I got some issues so I stopped doing it. Also I'm not sure if it's related but when I make a backup in the REX bank (using Ctrl+B from the menu) I got two progression bars: one which says "copying RAM to image" and just after it's completed a second one without text. On most (but not all) of my other banks the second progress bar doesn't happen when I refresh the backup). I'm not sure there is a solution to the problem, so perhaps I'll try to backup/restore using mcomm or the REX bank as soon as I know what is the best way to get a new "factory empty" REX bank. I'd still like to understand what happened, though :o) Eric
[M100] BA files got swapped
I got a weird behavior this morning: Two of the files in my M100 got swapped. I mean that when I load one of them I get the other one... Those are files I've been working on for a few weeks already, and I've no idea how it has happen. Are those issues common? Should I worry about the integrity of the other files? I know it happened today or yesterday because yesterday I made a batch backup using TSDOS and MCOMM for the first time since a few weeks ago (I usually rely on REX to backup the whole RAM image). In case it's relevant, file names are PGKOD.BA and MKAX.BA (I didn't saved MKAX.BA with TSDOS because it's a file from another project that was just there so I could copy/paste some part of the code). Another thing I did which I usually don't is I activated the DOS extension of TSDOS for a couple minute so I could get an ASCII backup of two of the BA files using SAVE "0:PGKOD.DO",A I did this for two BA files, and deactivated the DOS extension right away. Should I just try to rename them or should I go cold reset and re-upload from the PC backup? Eric
Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
Mike Stein wrote: > I'm curious: how did you find that page? I was looking for a disassembler for the M100. I used Google and this page was one of the first results. Fwiw, DEBUG.CO is working great once you manage to install it. Eric
Re: [M100] ADVENT (was Weird "bug" with TS-DOS 4.0 (ROM version))
Gary Weber wrote: > As a text adventure, I think it's pretty good. There's the potential of > creating a completely different adventure by writing your own set of > ADV#.DO files, so that sort of thing was pretty unique at the time. > > Check it out! Thank you Gary! I will give it a try tonight (as well as other games on this page). Eric
Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
John R. Hogerhuis wrote: > I used the mappings in Hterm. > Hterm maps all m100 characters to/from utf8. > >A Unicode filter for LaddieAlpha is a good idea Thanks for the information. I'll have a look in HTerm sources (unless you plan to implement the LaddieAlpha filter in the near future? ;o) ) If you do this, may I suggest you add a BOM character at the beginning of translated DO files? That will allow to easily test if the file is in M100 ASCII or in UTF8 (that will also be convenient to know if you need to translate a file from UTF8 to M100 ASCII before sending it back to theM100). Eric
Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
Gary Weber wrote: > I corrupted my file system over and over trying to figure out what was > going on when loading in the various ADVx.DO files for the ADVENT adventure > game using TS-DOS. Turns out those .DO files had an EOF character at the > end. And that ended up in the files because I'd manipulated them on an OS > at the time that appended the character to each file. Thanks for the feedback Gary! Since the only weird thing I've seen on the file itself was the presence of the EOF character, I assume that's exactly the same case. By the way, is this ADVENT game any good? I didn't really look into games on the M100 yet but I'd like to find something nice to try. John R. Hogerhuis wrote: > I have some hooks in LaddieAlpha to fix some stuff like filenames or do > filters, I could fix that in LaddieAlpha. I already show file ASCII files > misnamed as .BA as .DO to prevent corruption. > > I don't think I do any banned control character checks yet. That may be a nice thing to have, especially if it just silently corrupt the whole filesystem :o) I'm using mComm at the moment but I may give LaddieAlpha a try someday. Kurt McCullum wrote: > It could be something as simple as a CR vs CR/LF problem at the end of > every line. mComm doesn't change the file when sending it. That's > something laddieAlpha does do which I probably should add to mComm. > Open the file with something like Notepad++ and turn on invisible > characters. If every line ends with just a CR instead of a CRLF then you > have to file the file. I'm not sure if bad CRLF can cause issues (except perhaps in TEXT; In basic I had no issues with any special characters except $00) but the trailing ^Z is definitely something to filter out. Did you guys consider having a plugin API so we can write simple scripts for this kind of things? I have been working (very loosely) on a "Tandy ASCII" / Unicode conversion of special characters (everything above 127) so the files can be edited on the PC and be re-imported to the M100 without any issues (that's probably a feature only non-English speakers would require (for é è ê à ç and friends)). That's something I'd like to be transparent when I transfer files to/from the PC, so a mComm and/or LaddieAlpha plugin would be great. Eric
Re: [M100] Dust Covers
Eric wrote: > Also after looking into Shapeways prices, we're looking at a cost of > at least $60/$80 each for a plastic piece of this size. I found a "3d printing & Price Comparison Service" so I quickly made a mock-up version of the cover (changing the size by 1 or two millimeters shouldn't change the price much). I've gone for something covering the white part of the M100. We could do smaller, but if you have windows, that would probably cause a non-uniform yellowing of the non-covered parts which would look terrible. The price is... well, it starts at $58 for ABS (That's what LEGO are made of... so basically indestructible plastic) up to $9400 for Titanium (you can print in nylon for a little less than $200, all other material are either very expensive or impractical) I used a 3mm thickness (5mm for the top) because we wanted some strength but while I was there, I tried a 1mm thickness version (I never successfully printed anything less than 2mm thick but with a $400,000 printer that may be possible). Price "drops" from $50 for ABS to $2700 for titanium ($98 for Nylon). So my conclusion is... let's look into vacuum forming solutions :o) Eric
Re: [M100] Dust Covers
Gary Weber wrote: > Possibly a better approach than getting exact dimensions of an M100 would > be to try to replicate an existing protective cover that someone already has > (either the black or the clear). Might be tough to get someone to give > theirs > up for a period of time though. ;-) It would be equally difficult to get an accurate measurement from the cover than from the M100. Also after looking into Shapeways prices, we're looking at a cost of at least $60/$80 each for a plastic piece of this size. I'm not an expert in vacuum forming but it seems a better choice for this kind of application. I can still try modeling something if someone wants to try it but I'm pretty sure there is no way at the moment to reach a viable production price via professional 3D printing (unless one oy you guys have access to a SLS printer). Eric
[M100] Weird "bug" with TS-DOS 4.0 (ROM version)
I found yesterday Adrian Ryan's DEBUG program on this page: http://www.club100.org/cgi-bin/blosxom2011_06.cgi That's when things started to go weirdly wrong. I'm using a Rex with FW 4.9 and the TS-DOS ROM with mComm 2.50. I've never had any issue with those before but to make it short, loading "DEBUG.DO" which is a plain ascii file ends up corrupting the filesystem of the M100. I tried again after a cold reset (Ctrl+Pause+reset), and the problem is really easy to reproduce: - go to basic and type CALL63012 to open TS-DOS - Download the DBMAKE.DO text file and press F4 to check its size after the download (should be 886 bytes as expected) - Download the DEBUG.DO text file and test again the size of DBMAKE.DO which should now be 0 If I re-download it, I'll be able to generate the debug.co but saving the file and loading it I get very weird Top/End/Exe values (not always the same). Also when I check the sizes of existing files I got totally random filesizes (including a 39000+ bytes file at some point) Could a bad character in a DO file compromise the M100 filesystem after a simple download (weird stuffs starts just after downloading, without even opening or trying to execute the file). The only thing I noticed with DEBUG.CO is that the file includes and EOF byte at the end of the file (chr$(26)). I think it's ignored as the transferred file is one byte smaller than the one on the mComm server but could that be the issue? I haven't been using mComm/TS-DOS for very long so I may miss something obvious here but could someone with more miles behind them confirm this is a bug or should I look into a fault on my M100? Here is a short video where I reproduce the problem (sorry for the shaking, I was hand holding the camera while trying to type) : https://youtu.be/RPhuwlKhuAM Eric PS: I also tried to switch the "Memory Power" switch off to have a real cold reset but to my surprise, even after removing the AA batteries, my files were still there when I switched on the M100 again.
Re: [M100] Dust Covers
Gary Weber wrote: > I just wish someone still could make that. As > it stands now I think "reverse engineering" and then printing with a 3D > printer might be the only option these days. I wouldn't do something like that with a "home" 3D printer because PLA (the most common "plastic" used for 3D printing) has a tendency to leave small microscopic particles all over the place, which could eventually be a problem for a mechanical keyboard. And printing something that big in ABS would require a very expensive printer. You may however have this kind of things printed by a professional service like Shapeways (I've never used them so this isn't a recommendation). Just keep in mind it's not always easy to get the dimension tolerances right on the first try so you may have to print 2 or 3 of them before getting the fit you want. Also it's not that easy to get precise measurement of something like the M100 (unless someone has a complete and accurate 3D model?). I personally don't own calipers large enough to accurately measure the exact size of the top rim but if someone could provide those dimensions I can probably make a 3D model so whoever is serious about getting one of those could have it printed professionally. Eric
Re: [M100] Cleaning the motherboard of a M100
Stephen Adolph wrote: > It would be good to post a list of caps used to do the recapping. Is that > posted somewhere? I used Jeff Birt's list. The list link is in the description of his youtube video "TRS 80 Model 100 Repair Part 2". (I tried to post the direct link but my ISP rejected the mail because "High score Spam detected"...) Eric
[M100] Contrast problem with a M100
I've finish recapping my M100, and also replaced the thermistor that was fried. I didn't have the clock display/freeze problem since then but the contrast of my unit is still way to high and the contrast dial has almost no effect. When I turn it on after a long break, the contrast is OK for 2 to 3 seconds before it goes to the maximum. I also tried to clean the contrast pot with an air can and some contact cleaner spray but it had no effect. My VEE is now at -5.00V, VDD is at 5.06V. Where should I look next in order to fix this problem? The service manual says "Check the LCD waveform" but I'm not sure what they mean by that... Eric
[M100] Cleaning the motherboard of a M100
This week-end, I re-capped my M100 almost completely (C86 was out of stock, but I should get one this week). The good news is that my voltages are now looking a lot better (especially VEE that went from -4.5V to -5.05V). The bad news is that despite re-heating the RTC's pins, I'm still having the intermittent keyboard/clock/cursor issue (a lot less since in the last few days I wasn't able to use it at all, but I still got it) and the contrast dial is still unresponsive. When re-capping I found out that at least one cap has leaked badly, but I was able to clean the motherboard area completely using white vinegar first, and isopropyl alcohol next. However there was a large corroded area next to the power supply area which I was not able to clean (picture: http://pics.lefauve.org/M100_Corrosion.jpg). Since I'll have to re-open the M100 to change C86, I'd like to try cleaning this better (the picture is after the white vinegar/isopropyl alcohol cleaning) but I'm not sure how to proceed. Should I go strongly at it (the first time I used q-tips, but I've seen peoples on youtube using toothbrushes very aggressively for cleaning PCB) or should I use another kind of cleaning product? Cheers, Eric
[M100] Installing 8K modules in M100
So yesterday I bought the collection from Scotty, which was I must say in even better condition that the pictures show :o) Not only I'm now the proud owner of a mint condition fully functional M100 with its TPDD2, but I should have enough parts to fix my original M100. Among other spare pieces, there was a couple of 8KB ram modules, looking either like vintage products or DIY hack (picture: http://pics.lefauve.org/M100_8k_ram.jpg ). My problem is that they don't look like the other installed modules, and I have no idea in which orientation I should install them. Is there a trick to find out which side goes where? There's only two possibilities but I wouldn't want to fry anything. Eric
Re: [M100] Unable to Load TEENY to MT
Kurt McCullum wrote: > Teeny can also be injected from mComm. It's quite a bit smaller too > so it loads faster. I'm not sure why that error would be coming up > with TS-DOS. Did you use the command "RUN COM:98N1E" from Basic? The > dos injector uses xon/xoff so the flow control lines don't matter > when loading. Kurt, I didn't asked about it yet because my M100 is having a lot of other issues and I didn't want to flood the list with too many different topics but if I did manage to get mComm 2.5 running, the "inject TS-DOS" feature never worked for me (and yes, I have eventually tested every single pin of my DB9 to DB25 adapter and it is totally matching the cable described in mComm documentation). I'm pretty sure the issue is my dodgy cheap USB to RS232 interface having issues with xon/xoff, but here is how I managed to get TS-DOS on the M100: - I opened the file dos100.do from the mComm directory in a text editor and copied it in the clipboard - I opened a 1200 bauds serial connection with even parity and xon/xoff using Putty on the PC - I typed LOAD "com:58e1e in the basic prompt - I pasted the clipboard content into putty - I pressed CTRL+Z in putty (that sends the EOF to the M100) - After one eternity (3-4 minutes) the loading completed, I typed RUN and it did the trick Note that using TS-DOS, I can transfer files at at full speed and I got no error so far so the problem only occurs at the initial step. Also to be transparent I had to try 3 times before getting TS-DOS transferred without any corrupted content so perhaps you may try an even slower speed (it usually works fine at 1200 bauds but I've never transferred a file that big before). Note that if you're using 600 bauds you'll have to wait for 6-8 minutes to get the file. Perhaps in the next revision of mComm you could add an option to reduce the speed for TS-DOS injection? (and if possible some kind of progress indicator because it's a little nerve breaking to look at the M100 for 3+ minutes while nothing changes at all :o) ) Greg Swallow wrote: > Yeup, using RUN"COM:98N1E" alright. Have tried to inject TEENY, but it stalls. > I RESET, go to BASIC, and RUN and gives a Checksum error. Am beginning to > wonder about my RS-232 port. Is it one of those $4 USB to RS232C interfaces from eBay? That's what I'm using and I'm pretty sure that's where the problem comes from... Eric
Re: [M100] Very stupid question?
Peter Vollan wrote: > That is just what I was gonna say: you are draining more power, thus > the drop in screen contrast. The solution is fresh batteries or a wall > wart adaptor. No need to recap your whole unit. Well, the first thing I tried when starting to have issues was to use brand new batteries... it didn't help (even if a wall wart solves the issue, I like using batteries). Also my caps are 30+ years old, and at least one of them already leaked, so it sounds a good time to recap the unit (also I'll have to disassemble the M100 in order to change the NiCAD battery and the totally destroyed TH1, so while I'm there why not do the whole job at once :o) ). I also intend to add some solder to the RTC chip which has been causing me issues in the last few weeks. Eric
Re: [M100] Very stupid question?
Mike Stein wrote: > Sounds like a handshaking issue; what are you using at the other end of the > cable to save & load those programs, and are they tokenized .BA versions or > .DO plaintext? I just use Putty. Basically, I open a connection on the com port with the same speed, parity, etc, change the default encoding (UTF8) for ISO-8859-1 and save the basic files with: SAVE "com:58e1e" When sending files to com:, SAVE is actually untokenizing them (same as SAVE,A) On the PC, I just select everything and past it in a text file. That's very basic but it does work (I still hope getting mComm working though, but so far it made the job). For the CO files I wrote a small Hex converter (main reason being I couldn't get the ones on club100.org working). > But yeah, the common use of the term "RS-232" to describe TTL level signals > is very confusing. Yes it is! I understand most "Arduino programmers" (the ones with Dupont connectors) use TTL levels but I thought one coming with a DB9/DB25 connector would be RS232C compliant... I found out when I got issues trying to talk to a serial printer (at the moment, the M100 and this printer are the only two RS232 devices I have access to). Eric
Re: [M100] Very stupid question?
Thanks for the replies, I'll let you know if the replacement of caps help the problem! (that may also be caused by my exploded TH1 thermistor... I'll try changing it too) Kurt McCullum wrote: > cable and my Model-T. If the RTS/CTS or DTR/DSR lines are crossed, you > end up with major contrast issues on the screen which is a dead give > away that the cable isn't right. That's been my experience. Thanks! That seems a good possibility. I noticed my first adapter had issues with the pins 6 and 1 being tied up, so I got a new one which allowed me to cut this (by removing the pin 6 completely as instructed on mComm's documentation) but I didn't check other pins yet (but since communication with mComm still doesn't work, it's likely I got some other issues). > 7 Wire Cable PC DB9 > > Model-T DCD 1 NC > > > RX 2 ? 2 TX TX 3 ? 3 RX DTR 4 ? 6 DSR GND 5 ? 7 GND DSR 6 ? 20 DTR RTS 7 > ? 5 CTS CTS 8 ? 4 RTS RI 9 NC That looks like a copy/paste from the cable.html file of the mComm documentation. My next try will be to check that I have those connections, and no other ;o) Eric
[M100] M100 stuck on the menu with weird date :o(
Hi, I'm still waiting for my replacement Ni-Cad battery but I've been continuing using my M100 without any other issue... until tonight. When I turned it on, the "low battery" light was on, and the date displayed on the first line was wrong: ◥5ÿ 00,1919 Sun 00:00:00 I switched it off and on again, and it stayed this way. That's when I noticed the keyboard wasn't responsive. Also the first 3 characters flash every now and then (here is a 11 seconds video: https://www.youtube.com/watch?v=jjUw2XpB0Gw ; it happens around 00:03) I verified the voltage of the AA batteries and found 5.9V. Should be OK but I still changed them. Now the first line displays something like this: ros ??,1920 ñ)s ??:??:?? ...and the keyboard is still non-responsive I tried the reset button, which had no effect (the computer restarts in the same state), and the whole reset (Ctrl+Break+Reset), which removed all files from the ram filesystem but it's still stuck. After a quick look inside, the Ni-Cad battery didn't seem to have started to leak, and I measured about 4.9V to its pins; I also noted a faint buzzing sound coming from the LCD area while it was open. I also tried to switch the "memory power" switch off, remove the batteries, replace the batteries, switch everything on again... same result. At this point, I'm out of ideas... Any suggestion about how to diagnose and fix this problem? Eric PS: There is a kind of battery leak damage around a screw on the motherboard, but it's nowhere near any battery (it's located on the left of the power switch). I noticed it when I first opened it a few days ago, and I planned to give it a clean with isopropyl Alcohol when I'll change the Ni-Cad but I didn't touch it yet. Could it be related to today issue? Here is a picture : http://pics.lefauve.org/20-32-45.jpg
[M100] Changing the Ni-CAD battery
Hi, I got a 24KB Model 100 about one year ago and I've been using it a lot, but after some loss of the internal data in the last month, I've checked the Ni-CAD battery and it seems to show signs of imminent leaking. So I ordered a new one (3.6V / 80mA) and I would like to know if there are some advice I should know before jumping in and switching the battery, or some tutorial about this. Also, the user guide is not very clear about how long I should let the Model 100 switched ON to fully charge the Ni-CAD, which I assume I will have to do once it's installed before I start transferring back my files to the internal memory. And since we're on the topic, can someone tell me how long the internal memory can last without turning the model 100 on ? (User guide says about one week, but I've been away for work for 30 days, and my data was still there when I came back...) By the way, this is my first mail on this list, so I'd like to thank you in advance for your precious help! Cheers, Eric PS: Fun fact, the data loss was probably caused by a bad batch of AA batteries, but I still prefer to change it since it looks like it has never been changed before :o)
