I have ram chips for 102 if you want. Or you can get them on ebay pretty cheap and easy. There is a whole list of compatible chips actually.
http://ebay.com/itm/252217107997 -- bkw On Feb 5, 2017 5:42 PM, "Josh Malone" <[email protected]> wrote: > 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 >>> >>
