If you're lucky,  it might just be a cap - Or two...

...


On 2/9/17, Christopher C <[email protected]> wrote:
> Thanks for letting me know that it went to a good home.
>
> I have a similarly ‘damaged’ machine, with slightly different symptoms.
> I will have to check on whether or not the disk is functioning, but it
> starts up to the menu, the clock at the bottom is working, but it does not
> respond to keystrokes, other than the power button.
> The history of this one is that it was ‘exposed’ to a 12V center positive
> adapter by mistake.
>
> I was kinda happy that the damage wasn’t worse, until I noticed that the
> keys would not move the cursor. :-(
>
> cmc
>
> On Feb 9, 2017, at 11:10 AM, Brian White <[email protected]> wrote:
>
>> I appreciate that offer to fix it and return it, but I was asking if
>> someone just plain wanted it, to keep. And sorry for this, someone claimed
>> it a couple days ago.
>>
>> It's going to Jayeson Lee-Steere, the guy who designed the new ram module
>> and made it public domain.
>>
>> --
>> bkw
>>
>> On Feb 9, 2017 12:36 AM, "Christopher C" <[email protected]> wrote:
>> 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 <[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
>>
>> Regards,
>>
>> Chris
>> [email protected]
>>
>>
>
> Regards,
>
> Chris
> [email protected]
>
>
>

Reply via email to