AllanHiggins

It's been years since I've actually owned any physical machines, but my old brain thinks that you can tell by looking at the design of the slot, whether it is a slanted design or not. I had both, and I think that the slanted design was single-sided and the one with right angles was double sided.

Have you tried checking the amount of available RAM when the machine is running its own TOS from ROM?

The fact that he's getting bombs at all is still a good sign, since the drawing of the bombs requires the CPU, ROM, and video to be working, at least working to some extent. If the machine got better, albeit marginally, after reseating the chips, then oxidation is at least one of the problems. Tell your friend to remove the chips again, but before plugging them back in wet the pins with WD40. Don't spray the WD40 directly on the pins, it's too messy and you don't want to create a short -- wet a cotton swab and brush the pins liberally. Don't leave any cotton fibers on the pins. The WD40 will aid conductivity. Another thing you can tell your friend to do is leave the machine turned on for a while. 24 hours, perhaps. Just to get the blood flowing, so to speak. Circuitry wants to be used.

Depends upon your motherboard (I'll call it a motherboard, but it's likely the only board in the machine). I had a 520 back in Canada about 20 years ago, and when I opened it up I found that the board already had the circuits laid out for the extra RAM. Maybe it was a late model 520 and was simply a 1040 missing the RAM, I don't know, but it was a lucky break. I added the chips which I bought from a local electronics store, and a couple of diodes or resistors (I forget which, but there were already spaces for those too and they were clearly labelled). I shouldn't actually make it sound that easy, though it should have been easy if I was more skilled with the soldering iron. I had to do the whole thing twice, because the first time I tried it I soldered the chips directly onto the board, and fried some of them because of the heat from the soldering iron. I un-soldered and replaced them with sockets, into which I then plugged a new set of chips. *THEN* it worked. If I were to do it again today I could likely avoid the sockets just by using the proper heat sinks or simply just by avoiding soldering all the pins on a chip at once - solder one pin, then move onto the next chip, solder one pin, etc. just to give the chip a chance to shed some heat before you get back to it.

You could try to contact Dr. Noonan through Facebook. He may still have the source code. Maybe he'll even consider releasing it into the public domain. No harm in asking: http://www.facebook.com/profile.php?id=762339343&ref=search&sid=1443594574.3853918788..1 -Allan

Collecting all ST-Log Magazine cover disks! Send me your disk images, any format. They will scanned and organized and sent to Kevin Savetz here in California for upload to AtariMagazines.com and also to TOSEC and PlanetEmu. If you maintain an archive and would like a copy at the same time just let me know. Allan Higgins ( allan_higgins@hotmail.com ) [ allan_higgins (at) hotmail (dot) com ]

I just received a photocopy of the LaserC manual (600 pages). I was planning to do the scan, but I admit that it would take me a very long time since I'm a complete novice and I don't really have very good scanning software. If you think that you might have the time to get it done faster I would consider sending it to you. We wouldn't have to destroy another book. The only thing about my copy is that it is slightly reduced in size because the person who made it copied the original book double-paged onto 8 1/2 x 11 paper (i.e. two pages per sheet, landscape). Let me know. Otherwise, maybe some advice on software and technique. As for the LaserDB manual, Poobah has one that he would like to hang onto, but since the manual is only about 50 pages maybe he might consider making a copy or scan. The LaserDB manual is wire bound, not latex bound, so it's not as fragile as the LaserC manual and could actually be disassembled for easy scanning and reassembled later if you were careful with the pliers (or had a binding machine).

Speaking about rationing out the bepesterments, I'm about a week away from sending Michael Bunnell another email. He and his brother Mitch wrote Megamax C and Megaroids. I'll ask if he still has the source code. I bothered him recently (Jan 22nd) so I'm waiting until a month passes so as not to be a pest. Any other questions anyone wants included?

Understood. I sorely regret throwing mine away. I should have just stuck my tongue out at my wife and said "nyeah" when she started on me yet again about my "clutter". My *BELOVED* clutter, DAMMIT WOMAN!!! I've got a photocopy of the main manual which I can start on. Being several hundred pages, it should keep me busy for quite a while. And being a photocopy already means that it will be easier to scan and I won't have to abuse the binding on another fragile book. If ThumpNugget has some recommendations for performing the scan, then I'm all ears. And thanks for the v2.1 disk. Original file dates still intact - I love that in a disk. I almost have enough forensic evidence to post a release history on the Megamax wikipedia page. Still need dates on Laser v1.0 and the original Megamax C package. I noticed STart ads for Megamax C v1.0 in the Summer 1986 edition, which jives with the copyrights inside the binaries. Speaking of history, anyone recognize these? Maybe they were only used in Germany, for ads perhaps, or maybe as part of a localized package. They were IMG files that I found on pigwa.

Poobah, Charles sent me the v1.1 disks, LaserDB v1.0, and the v2.0 upgrade disk. I still need the v2.1 upgrade disk, and the LaserDB manual or a copy thereof. You can contact me at allan_higgins@hotmail.com

The only disk image from your set that I have so far is the Laser C 2.0 Upgrade disk. I'm very interested in the LaserDB manual. I recently purchased a photocopy of the Laser C manual on Ebay, it's not the greatest copy in the world but at least I have the information - I'm hoping to scan the manuals as part of the archive. Are you looking to keep the originals? You can send me an email if you would like to allan_higgins@hotmail.com - I tried to use the forum message facility to send you a message but it may not be working. -Allan

I imagine that this technique was discovered in someone's fit of rage: they got so annoyed by their machine's unpredictable behavior that they grabbed the machine and smacked it around and were surprised to discover that it no longer gave them any grief. ...and were divorced shortly thereafter upon discovering that this approach did not work on women... And speaking of inexplicable repairs, I had one yesterday: the night before I left my iMac G3 on all night and it seriously overheated because I had something on top of the machine which covered the ventilation holes. By morning the machine was totally dead. I let the machine cool for a couple hours, downloaded a repair manual on another computer and started running tests with a multimeter. After taking some components out and putting them back in I noticed that there was a spark of life: the firmware started talking. Still, the machine was seriously bugged, no disk or CD would boot, and the Apple hardware test program would crash and dump me out to the firmware's built-in monitor. But I kept running the prescribed tests, thinking that I would at least determine what parts I needed. But after another 2 or 3 hours of running tests, the machine gradually started passing more and more of them for no reason. I hadn't done anything that would have fixed it, other than let the machine warm up again. It's still working again today. -- this is the Macintosh version of trying to cure a hangover by having another drink the next morning.

I wasn't thinking about limitations in emulators so much as I was thinking about possible cool things that could be done with ST software that was "emulator aware". i.e. ST software running inside an emulator, detecting that it is in an emulator and being able to then communicate with the emulator in order to interact with the host environment in ways not defined by the emulator. The emulator would ideally be cooperative, of course. Adding host interaction capability into the captive compiler's libraries would then make it easier to recompile old ST software to be emulator aware and perhaps interact more seamlessly with the host, at least at the source level. It would turn the emulator into something more resembling a subsystem in NT, like the Win32 or POSIX or OS2 subsystems (I suppose that it would actually more resemble the DOSVDM). I think that it would be cool. I developed a desire to do this while toying with the idea of using Steem and TOS 2.06 as my desktop under Windows XP. I wrote a Win32 "shell redirector" that picked up extra parameters in my boot.ini and launched a specified shell instead of explorer.exe. I was then able to select Steem as my Windows shell during boot. It was pretty cool, but there are limitations, of course. You see files in 8.3 format, you can't launch Win32 programs, etc. I mentioned the Windows DOSVDM above - notice how the DOSVDM will allow you to launch Win32 programs. Imagine being an over-the-hill computer geek, unemployed or underemployed or "mis-employed" because your job was transferred overseas or because you weren't able to keep upgrading your skills every year, and it makes you happy to reminisce about the "good old days" when you thought that you knew everything that there was to know about everything. And you boot your computer in the morning to look for a job, or to do some freelance telecommuting assignment that tortures you, and you have the opportunity to think to yourself "Will I work from my Atari ST today? Or my Apple IIGS? Or maybe my Commodore 64? Or my Heathkit H-89? Or my TRS-80 CoCo3?". Imagine.