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 >
