In theory, this person has the Model 600 26-3901 service manual and BIOS reference on DVD. (But it isn't cheap either.)
http://www.ebay.com/itm/Ultimate-Tandy-Radio-Shack-TRS-80-Operation-Repair-Service-Manuals-DVD-manual-/252456781419?hash=item3ac798c66b:g:VbsAAOSwBahVeB8e If they managed to get it on DVD for resale then it has to be out there 'in the wild' some place. I expect though it will be very much like the 102 reference manual - it will explain what everything is in great detail but you aren't going to find any service notes in there. --- Rick ----- Original Message ----- > > Are you up to a little component level repair? I have 2 600's > > > My first one was working except for the floppy drive, and some > keyboard keys were corroded. > > > I took it apart to replace the batteries and clean up the keyboard > keys. > > > Afterwards, the machine boots up and the system manager loads, but > there is no response from any keyboard keys except the power button, > and the clock on the screen does not advance. > > > I have a 2nd fully working 600, and I have verified that the > keyboard, it's cable, screen, it's cable, and the daughter card the > screen connects to, are all good. They all function fully when > connected to my other 600. > > > Similarly, plugging the known good copies of all those from the good > 600 into the bad 600, I get the same locked up behavior. > > > I haven't yet swapped the floppy drives to see if the floppy drive > problem was in the drive or on the motherboard. I will, but that's a > separate issue. Previously everything worked fine aside from the > floppy drive, and that includes both with and without a 96k ram > board installed, that includes after I had replaced both the memory > battery and the main battery. > > > So, the problem is on the motherboard, and somehow allows the boot > process to go far enough to load the system manager. The main cpu > clock must be ok or else that couldn't happen. A lot of things must > be ok or else that couldn't happen. Yet once the manager loads and > draws the initial screen, that's it. No further action. The clock > doesn't even advance. The keyboard which might have been > questionable since I had it out and apart and drenched in DeoxitD5, > has been proven good. Same for the screen and daughter card, though > I never messed with those so they weren't suspect anyway. > > > If you think you have a shot at diagnosing that (without any model > 600 service manual, since no one has one these days), you can have > this machine. Same goes for anyone else reading this if not you. > > > I have to say, even having a fully working unit, WITH basic > installed, this thing is terrible. 9 1/2 lbs and almost useless, > even compared to other machines of the day. > > > > > Everything is incredibly slow for a machine with an 8088 in it. There > is almost no software for it, and there might have onlybever been a > single 3rd party machine language program for it, which we don't > have a copy of, just a review describing it. What little software > there is is a mix of interesting but very low level utils, like > utility.lib, and utter crapware games. I should make a video of > actually using art.bas and playing spider.bas . There isn't even a > ram test app, which I would like to test the new ram modules > designed by Jayson Lee-Steere after I build the first set. > > > The development kit is lost to time. Although we have a manual that > describes it and it seems to be tantalizingly simple. So there are > no 3rd party machine language programs, nor the tools to make them > any more. > > > But *almost*. The way the manual describes the executable format, > it's basically compiled with a standard DOS 8086/8088 compiler, but > your code just does things that wouldn't actually work on a dos > machine, and a post-processing step strips off a dos exe header. So > it's like it might be a very small step from a ms-dos 8088 compile > to a model 600 compile. > > > We do have a small handful of executables to examine to reverse > engineer. There are all the files from the utility floppy. There is > basic.!55. There are all the "files" in the system roms and > multiplan rom which can be copied to stand-alone files from the > system manager. So it might be possible to make a new toolchain to > produce new machine language programs, in theory. > > > We also have a full proper manual for BASIC now (I scanned it and > uploaded to archive.org last week). So, BASIC.!55 plus UTILITY.LIB > (which provides peek and poke and similar) and the basic manual, and > the new ram modules so no one needs to be stuck with 32k or 96k any > more, means at least the stuff is available now to make the most out > of basic at least. > > > One positive factor when it comes to trying to diagnose and fix the > hardware without any service manual, apparently it is all 100% > generic parts. No asics, fpgas, cplds, gals or pals. So no mystery > chips or unobtanium chips. Should be possible in theory to debug it > 100%. I don't claim it would be worth the time it might take, only > that it falls on the right side of possible vs not-possible. > > > -- > bkw > > > On Feb 5, 2017 4:13 PM, "Willard Goosey" < [email protected] > wrote: > > > > > Just when I'd convinced myself that I don't need more old computers, > you have to go and get me all interested in the T600! ;-) > > > I was sort of interested anyway, because it's the only 8088 box I've > ever heard of that runs neither MSDOS or CP/M-86. OTOH it was such a > failure! > > > I don't actually have anything useful to say, besides "good luck". > Now I'm going to go *stay off ebay*. :-) > > > Willard > > Sent from Samsung tablet > > > -------- Original message -------- > From Brian White < [email protected] > > Date: 02/05/2017 12:42 PM (GMT-07:00) > To Model 100 Discussion < [email protected] > > Subject [M100] Model 600 basic rom > > > > I started to try to tease apart whether the basic.!55 file is maybe a > copy of the option rom, even though it's too large to fit on a chip. > > > I was thinking, maybe someone copied the option rom to disk via the > system manager, and the disk/ram copy just gets some kind of headers > or tails added to it which could be stripped off to get a rom image. > > > To find out, I looked at the multiplan rom. I took a direct dump of > the multiplan rom in an eprom programmer, which makes a guaranteed > exact and working copy, because I then flashed that image back to a > new eprom on a molex carrier and it worked. > > > Then used the system manager to copy plan.!50 from rom to disk. Then > removed the rom. Then copied from disk to ram. Then used xmodem to > copy to a modern machine. > > > Then compared those two images. Also armed with a tiny bit of info > about rom structure from one of the developer manuals scanned in > archive.org > > > I seem to have found the opposite of what I was hoping. The the rom > dump of multiplan is larger than the ram copy of the very same > physical rom chip. > > > The bulk of the two images are identical in the middle, but the rom > image has 64 bytes of header prepended and 64 bytes of tail > appended. And both versions have some dead space at the end, though > the ram copy fills it with spaces and the rom image fills it with > nulls. > > > So basic.!55 remains a mystery. It's a ram/disk executable, which is > larger than a rom image is possible to get. > > > https://drive.google.com/folderview?id=0Bys6eLbSbYyhNHBIdk1rSlZORlk > > > > https://drive.google.com/folderview?id=0Bys6eLbSbYyhSFhFZ29TSEZkTUk >
