Brian, I would be able to take a whack at curing the problem 600, it as long as you’re not expecting it back right away. Let me know.
cmc On Feb 5, 2017, at 4:37 PM, Brian White <bw.al...@gmail.com> wrote: > 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" <goo...@sdc.org> 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 <bw.al...@gmail.com> > Date: 02/05/2017 12:42 PM (GMT-07:00) > To Model 100 Discussion <m100@lists.bitchin100.com> > 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 Regards, Chris court...@comcast.net
