Geoff Oltmans

I haven't done much with the emulator in a while. As hardhat said, most of the emulator is already documented (minus the new bits of support I added) via the command line. My original goal was to make the emulator work natively in Windows XP, as one of the zillions of patches that were automatically installed via Software Update on my XP machine at the time rendered ADAMEm unusable. I used MinGW/GCC along with SDL (a cross-platform graphics/sound/controller library) in order to make it more portable (Dale Wick has it running on a Sony PSP for example). After that initial push, I ended up getting a MacBook and decided to get the port working on there, and as a result of tinkering with XCode decided it would be fun to try and get a proper UI working on it. It is still possible to drive the mac version via the CLI. From there, it seemed like it would be nice to add a few features to the emulator, like PowerMate IDE hard disk emulation in particular, and one of the Adam group members was having trouble with the existing release of ADAMEm running an old program (SEQuel) since it probed for a MIDIMite adapter. I added a tiny bit of support for that just to get it past the software probe for that program so it would at least start up. Also added support for scale 2x for the video, and got the sound working via a new driver (although there are a few bugs in that). So, 6 years into all that it's still not in the best shape. It does at least run on a wider variety of systems than it used to, and has a few new nice features (and also a couple bug fixes in the original code). I need a kick in the pants to finish up what's started before continuing any further improvements. I'd like to rip out the SDL and make a proper OS X port which would make GUI support a little bit easier.

Ah ha! I feel somewhat vindicated now, because I was FOR SURE that such a package existed! Back when the ADAM was originally sold, one of our family friends bought one from a local store that sold them. He bought it and he and my dad set about to set it up the first time at our house (my dad was the local computer guru then). We found that it wasn't the standalone version, but one including the CV, just as this one was, in a box similar to the Expansion Module #3 box. He ended up boxing it back up and taking it back to the store and getting the standalone ADAM version the same day and that was that.

Steve Perlman actually started his own company after his Coleco days and developed a number of hardware add-ons for the ADAM Computer including an ADAMnet 5 1/4" Floppy Disk Drive that plugged-in between the Printer and Memory Console... unique design and idea as the Printer ADAMnet/Power Cord plugged into the drive and an included cable ran from the drive to the Memory Console (saw it for the first time at ADAMcon 23). He also developed numerous Memory Expanders that plugged into the Expansion Bus Interface (where the EM#1 - Atari Adapter plugs in). It would be great to hear from him again as well as any of the others that you mentioned... Good Luck! BTW, tell Walter Banks to release all those goodies already, no one has to know they came fom him. Would love to see pics of his warez as well!!! I thought the name Steve Perlman was familiar! Maybe he'll be willing to talk to me.

No, I didn't ever find out if his friend still has the stuff, although it might not be a bad idea if I followed up with him to see. I did contact another person that I was able to locate that worked on several bits of the ADAM system, Walter Banks. He indicated that he and his company were responsible for the printer software (and donated a prototype SmartWriter to a museum), ADAMNet, and also the Tape File System (one of the tape markers is that designer's initials GRW - Gary Wheeler who passed away a couple years ago). According to him at the peak of the ADAM project about 100 people were working on it. He indicated that he still has preproduction unit #2 (#1 he said was scrapped, and only 12 were made). He also said he has all of the development software backed up on tape and has been working to track down the copyright holders to release the stuff into PD. Also sent out another email to another guy (Steve Perlman) to ask him if he has any anecdotes to share. I don't have a direct email for him though.

My money would be on bad RAM. Hard to tell if it's system or video RAM from the testing you've done. Do you have pictures of what the display looks like in Jungle Hunt?

Very cool!

I think probably your best bet would be to put the roller controller in joystick mode. Under that mode it should work to control direction for any normal joystick game. That will eliminate the optical sensors as the problem. The fact that both are not working to me makes the ColecoVision system itself suspect as the roller controller/driving controller input on the joystick port is the same for both. If you swap the roller controller joystick connectors, it will swap the X and Y directions. Are you powering both the driving controller and roller? Both require power to work... batteries for the driving control or the tap off the main system power for the roller. If you have a copy of slither or another roller controller game which works in roller mode, you should be able to test your driving controller as well (it will only operate the X or Y direction, depending on which you use). EDIT: Oh yeah, a super game that uses the spinner should work as well.

Will keep you up to date. If it's anything like the other Coleco made ADAM utilities, CopyCart probably won't handle it and I'll have to try the CP/M cart copier. If that fails, I guess we'll need someone with a Cart Dumper or (E)Prom Reader... which I assume you just might have. I have access to one at work that does all sorts of EPROMs, so if you need help let me know.

When the A600 came out it was seen by the Amiga community at large as a big step backward in terms of expandability. Nowadays they are somewhat desirable in part because they are much smaller and they have a hard disk interface built in. The A500 is a bit more expandable and serviceable, if you can find the upgrade stuff for it. Stateside A600s are harder to find it seems. At the time it didn't make much sense to buy an A600 if you had an A500, because if you wanted an internal IDE hard drive, an AdIDE interface could be added to the A500. AFAIK, the A600 still uses programmed IO for the internal IDE interface, so it was no faster. There are also no drivers for the IDE interface in <KS2.05, so if backward compatibility with older games was important, you'd have to use a ROM switcher if you wanted to be able to use it with them. The chipset could be upgraded on the A500 to the same spec as the A600's...both Super Denise and 2mb Agnus, although depending on the model A500 you have to use a Meg-a-chip (A500+ didn't but they weren't common in North America). Plus you could use a bunch more Zorro sidecar peripherals with it that you can't use at all with the A600. In fact, most of the chips in the A500 are socketed so it's easy to replace blown components (ram excluded). If you inevitably blow a CIA chip on the A600, you're going to have to whip out your soldering iron and replace some surface mounted chips. CPU accelerators are also more plentiful for the A500, and depending on the model you don't even have to open up the case to install them. There was really very little reason for A500 people to "upgrade" to the A600, and as a cost-reduced A500 with no expansion port it severely limited its upgrade path. These days there's probably more availability of drivers for PCMCIA, but at the time about the only use PCMCIA was for most people was expansion RAM. Since A500 was the more plentiful machine, most ECS games are targeted toward that so 2MB vs 1MB chip RAM was not as crucial except for probably some obscure demos. There were only two models of Amigas that shipped with 2MB Agnuses pre-AGA, the A600 and A3000... the A3000 was EXPENSIVE and the A600 came out just before the A1200 came out. I probably wouldn't even bother with putting a Super Denise in a 500 because the "enhanced" modes are mostly weird resolutions that matter more for Workbench instead of games and slow the system down dramatically when you use them due to the increased bandwidth requirement for the video display. PCMCIA is nice to have for networking, but if you use any expansion memory in the PCMCIA slot then you're stuck if you want to use it simultaneously with the network card unless you can find a rare A600 accelerator card and put memory on that instead. To be sure, the A600 is a nice spec out of the box, but you can make the A500 do everything it can do minus PCMCIA, and you will never be able to put a Zorro slot on the A600.

Sorry I missed you as well! It was a treat to get to meet all the ADAM peeps in person. I was a bit bummed that I missed you and Drushel (yeah, I know he didn't make it at all this time). Who knows when/if I'll make another.

That is great! Thanks for offering to share the ROMs. I'm particularly interested in the test code.

Late reply I know... There is a Visual Studio project included. The Win32 version is compiled in Vis Studio.

I have also used the Atari brick with no problems on a couple different drives.

Coming from an area of embedded system design, I can see why designers in the 90's built hardware the way they did. Even if a game's hardware requirements are relatively modest, sometimes it makes sense to build a platform that can scale up reasonably well for several reasons: some of these cabinets could run different games through a ROM/kit upgrade so that an operator could incrementally upgrade the game so that more kids pump quarters in to them. The other is that if the game is too specialized, it limits its usefulness to one game or class of games...whereas a more universal design has the capability to replace multiple designs and scale production costs in your favor. If a design scales up nicely too, it alleviates any problems with painting yourself in a corner capabilities-wise 5 years down the road when you design your next, more sophisticated game. By then you've already absorbed all those hardware development costs, and hopefully have a robust platform with all the kinks worked out. Now, as far as 90's arcade hardware being a joke... I have to contend with that. There were a number of systems that had some pretty stellar 3D hardware accelerators in them (Solvalou, Hard Drivin', STUN Runner, etc.) that you would never have been able to play on a home system with any degree of satisfaction. Every arcade game that was 3D at the time either had in-house designed 3D hardware with reasonable-to-high polygon counts which were either unmatched or unavailable on home systems (game consoles or PC's alike).

I haven't put together a package for that yet, but I have compiled the emulator in Ubuntu as well. I'll have to figure out how to make a .deb package.

OS X users... you will need to install the SDL library if you haven't got it installed already. This can be downloaded here... http://www.libsdl.org/release/SDL-1.2.14.dmg

bump for an old topic... check out ADAMEm/SDL 1.8... now available through my website. See this thread for details: http://www.atariage.com/forums/topic/175295-adamemsdl-18-released/

Cut and paste from the coladam mailing list... ell, there are a few differences between this one and the DOS version. Firstly, the program runs natively under Windows and Mac OS X instead of being run through a dos VM like Dosbox or (if it works for you) the DOS prompt (which Windows 95/XP is a VM itself). It should support all the command line switches that the DOS program supports if you run it from the command line, including loading cartridge images and disk/ddp images, and then a few extra new ones: -harddisk <filename> or -hd <filename> will specify the file to use for hard disk emulation. -exprom or -er <filename> specifies the filename of the slot 2 boot rom. I have successfully used the PM IDE boot rom with this to boot to the hard disk directly -scale2x or -2x will start the emulator with scale2x turned on. This is a scaling algorithm to smooth out the video at higher resolutions If no filename is specified for the hard disk file or expansion rom it will look for hdisk.img and exp.rom respectively from the same directly the program is launched in. For the hard disk image, you need to create a hard disk file from scratch. I don't include a utility for this yet. From a linux or OSX machine you can create one using dd. dd if=/dev/zero of=hdisk.img -count 131072 will create a disk image that's 64MB large. You then have to use the PM IDE setup utilities to partition the file as you would a normal hard drive and load software to it. Apparently I neglected to include these in the -help output, but they do work from the CLI. EDIT: From the OS X version, you can load and detach disk images from the menus, and there is a preferences window you can set several options in. Most of the options in the preferences pane require you to save the changes and reboot at this point. Also, you can automatically load ROM images by double clicking on them in the Finder, and then use game reset to start the game.

Sorry... looks like my text editor clobbered my file links. Give it another shot if you had trouble (may have to manually reload the page in your web browser).

Hey all: Due to all the crappy weather we've had around here (7" of snow two days ago and 3" over Christmas!) and some downtime between now and Christmas, I've had the chance to do some fixing to ADAMEm/SDL! Doug Slopsema fixed the project so that it will compile using Visual C++ instead of gnu gcc under MinGW, and a few improvements have been made in the interim: Powermate IDE emulation has been added center slot boot roms supported scale2x support rudimentary support for MIDIMite apps (just enough to get stuff like SEQuel to start up) OS X menus and GUI sound support Visit my web page to download... let me know what you think. The downloads include the Win32 binary (thanks Doug S) and OS X universal binaries, as well as the source code. http://bellsouthpwp2.net/o/l/oltmansg/adam/adamem.html

I'd say this all depends on which Amiga model, and also what monitor you're using. You can use a PAL or NTSC model on an analog RGB monitor with absolutely no problems. However, if you're planning to hook up to a TV or use composite video, then it absolutely matters. You should get NTSC in that case. People think that PAL/NTSC are easily switched on the Amiga. Problem is, PAL and NTSC *color encoding* matter not one bit for Analog RGB. For an Amiga 500, it really doesn't matter too much if it's a PAL or NTSC model, since it doesn't have: color composite out or an RF modulator built in. The exception is what Agnus it's equipped with. I'd try to get one with a 1MB Agnus since that gives you the most software compatibility. The Amiga 1200 does have an RF modulator and color composite out though, so you should stick with a North American one if you're not doing Analog RGB out.

Greetings, programs... Geoff Oltmans checking in. I just happened to come across this in a google search of Adamem to discover my name as well so I had to have a look. First, let me say that I'm not dead yet, I'm getting better. Likewise, I haven't ceded the port of Adamem/SDL to anybody, although I welcome help with it. It's fair to say that I haven't done much to it lately, but I haven't finished tinkering with it. The last things that I did with the emulator were to add support for center slot expansion roms, powermate IDE hard disk emulation (via IDE code I borrowed from the BlueMSX project), and also some rudimentary MIDIMite support... enough to fake out a program called SEQuel so that it will start up. These days my main project of interest is my 18 month old daughter... she's just a lot more interesting than any ol' computer program. Plus, when the weather is nice outside, most of my programming work outside of actual work comes to a screeching halt. Once the weather turns crappy, I'll probably fire up the compiler again. I started Adamem/SDL back in 2006 because like some of you folks I was frustrated that the DOS version of Adamem suddenly stopped working in Windows XP after one of multitudes of updates to XP. Never could get it to work except on a fresh XP install after that. Also, I was interested in getting some desktop application experience (I am an embedded programmer by trade), so it seemed like an interesting project. I decided that SDL was probably a better choice than DirectX since it would run on more stuff. After doing the XP port, I bought a MacBook and got interested in trying to get it working there. Within a couple weeks I had the emulator running natively in OS X, albeit with no GUI (all CLI switches worked from the terminal however). I added some GUI functionality to it later on to reset the emulator, load disk/tape/cartridge images and so forth. I also did my own sound driver which interops with the SDL libraries since the sound emulation for the old DOS emulator talked directly to different sound cards rather than through the OS or an abstraction layer. Today, the SDL version will compile (or should, excepting the makefiles are currently busted) on Windows, Linux, and Mac OS X (and presumably any other environment where SDL is available... Dale Wick took my code and adapted it to run on a Sony PSP, so it is at least possible with the PSP). Doug Slopsema decided to take the code and try to make it work within Visual C++. I used GCC running in MinGW for my Windows port. I have yet to incorporate Doug's changes which he graciously shared with me to include in the main source for VC++. He also fixed my busted IDE emulation so that you can run hard disk images now. I am sorry to all those who have been looking for updates to the emulator and haven't been able to find it on the web. There are a couple of reasons for this, not the least of which is my wife and daughter. Aside from them however, I felt like early on the emulator wasn't very usable or "finished" until relatively recently and I really didn't want to release an unfinished product. The driver code isn't very well-documented. I started with the X drivers included with Marcel's source code distribution as a starting point to get to where I am now, so it's a little messy. I always wanted to go clean up my work before wide distribution. Also, I had intended to replace the Blue MSX implementation with my own since I wasn't sure about the licensing for that, but the source and project comments for their code seem to allow for this, so I think I'll leave it in unless otherwise requested not to. Even with it's current bugs right now (or lack of support for some things altogether) I think that it's plenty useable now, and even has some nice features not available in mainline Adamem (see: hard disk emulation). Probably my next order of business will be to finally merge Doug's changes in with mine, fix (or get from Dale) the makefiles so that they work properly, and then build the OS X version and either get Doug or compile myself the Windows version via VC++ (Linux users are on their own to compile it themselves). Then put it out for general consumption on a website somewhere. I did see the comment at the beginning of the thread about changing the color palette of the VDP. That's an interesting idea. Maybe a user definable color palette would be a welcome feature for inclusion into my OS X gui changes... hmmm...