I'll stick to getting the RAM working on my 102. :) On Feb 5, 2017 5:37 PM, "Brian White" <[email protected]> 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" <[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 >> >
