atarimac

goldenegg, Thanks for the offer, but it only seems to be occurring on a 2009 MacBookPro with a Nvidia graphics. He also has a MacMini, and has no issues there. I don't know if it is specific to his graphic controller, or something about his system. I'll see if I have any issues when I switch (we have 2010 and 2011 MacBook Pro's, a Mac Mini, and a Mac Pro), or if any other users see an issue, let me know. Thanks, Mark

Have any Mac users who have upgrade to Lion tried running Atari800MacX yet? I have one user reporting crashes, but I'm no where near ready to switch to Lion on my machines for probably another month, due to needs to complete projects for summer school. I did install Lion in a VMWare machine, and Atari800MacX ran fine there, but that's not real graphics hardware, and it might make a difference. If you do try it, please let me know what type of machine, and if you had or did not have success. Thanks, Mark

All, I finally got around to doing the release for Atari800MacX with the 512 byte sector feature in it (nothing like 4 months late The description is in this topic. And as it says there, the new release can be found at http://www.atarimac.com. Thanks, Mark

All, I've released a new version of Atari800MacX, and as usual, it can be found at www.atarimac.com. It's been a year and a half since a release, and this is long overdue. It is mainly a bug fix release. There are some features still on the todo list (for those of you who have asked for them), but I'm afraid between work and school, I have little time for hobbies at the moment. I decided this needed to get out before summer school started, or it might never happen. The changes are listed below. Mark Features Added/Changed: * Added support for 512 byte sector SpartaDos X ATR disk images. Bugs Fixed * Fixed bug where erroneously long frame sleeps caused emulator to lock up. * Fixed issue with window miniaturization buttons. * Fixed issues with some special characters not being able to be entered in the emulator as well as some international key sequences. * Fixed issue with super/subscript modes in Epson Printer emulation. * Fixed issue with R: network emulation and incoming connections, BBS Software will now work.

The Atari800 emulator's latest release should have the dual cartridge feature also. I checked my Atari800MacX dual cart code in there about a year or so ago, and I think the team just did an updated release. Speaking of releases, this week was my last week of school for this semester, so if work allows, I should get around to releasing a Atari800MacX bug fix/maintenance release in the next week or two. Mark

Rybags, When you are talking about a XEP80 emulator, are you talking about one being part of a Atari emulator (in which case Atari800 and Atari800MacX already have that), or are you talking about a hardware interface and "terminal" program on the PC, that would allow a real Atari to output to it? Mark

One other comment. Steve mentioned toggling the disk patch, and I don't disagree that might be one of the things that should be changeable. The thing to be aware of is that doing this on most emulators causes a reboot of the emulated atari, so the Atari program that did it would have to know that would happen, and perhaps be rerun through some sort of autorun.

One of the advantages the CIO idea has is that there is a way to pass parameters, and to get information back from the emulator. We are going to get one shot at this idea, and it needs to be a generalized interface. If we ca get the general idea flushed out, I can take it to the other emulator authors (I do Atari800MacX, and contribute to Atari800, so I would contact the Altirra and Atari++ authors) and try to get it standardize. It should be extensible as well with new commands in the future, as I'm sure we can't anticipate everything. I totally understand Steve's comments if the OS is not there. The issue is getting command codes and parameters/return values in and out, being limited to only the A, X, and Y registers. Perhaps we could use the IOCB structure in zero page that CIO would be using normally, since we shouldn't expect to be doing a CIO operation at the same time if we are doing the special opcode sequence. One of the other reasons for the parameter exchange is a return value, since I want it to do more than not do anything on real hardware, I want it to be detectable that it did nothing (in other words, the emulator would change a register that wouldn't get changed on real hardware), so the program could detect that the operation failed on the real hardware, and know that it is running on real hardware. So for example, different commands would be present for getting from the Emulator: Emulator Type you are running on. Emulator version number you are running on. Host Type you are running on. Separate commands for various settings of the emulator And then to send to the emulator: Seperate commands for various settings of the emulator. Comments? Mark

I agree, that seems like a really good use of the feature to me as well. However, I would like to brink back the idea of using a new device letter in the emulator as a method implementing the interface. The earlier comment about the device table not being present without DOS is not true. It doesn't include D: devices, DOS adds support for those, but E:, S:, K:, C: etc exist as those are part of the basic OS. Now DOS does rewrite the table, and may remove it, but the emulators (at least those based on Atari800) detect this, and reset up devices they are inserting. I really think this is the cleanest interface. Anything in memory space is going to have a conflict at some point or another. And it's going to be easy to tell if you are on a real machine, and IO operation to the new letter device will fail, as it's not there. Mark

The idea of the emulator device sounds like a good one, if we can get the feature coordinated across the emulators. I can speak of course for Atari800MacX (and am one of the authors of Atari800, so unless someone on that team objects, I can do it there as well). That would leave Altirra and Atari++. It would be nice to have some read XIO functions on the device as well, you could use those to determine which emulator you were running on, etc. As for the device name, we might need to be careful with the letter selection. I seem to remember M: being used for some sort of memory device, and of course E: is out. Any suggestions?

Yes, you could use the keyboard viewer until I get it worked out, as it should show the slash key from the keypad. (Unless it doesn't do that for the small keyboard, I don't have a way of checking that).

Guys, It looks like a bug. It should be Shift-7 on a German keyboard, but unfortunately, that returns a Question mark instead. I looked at the code, and the SDLK_Slash returns AKEY_SLASH + Shift, when it should only be AKEY_SLASH. I can't believe that one hasn't been found before now. The problem is my code base is not real stable, I was adding the Austin-Frankin 80 col card support from Atari800, and I've never finished it. I've had very little time for my Atari hobby between work and house things in the last few months. I'll try to get it sorted out in the next few days if I can, Heaven/TQA, I'll let you know when I have a version for you to try. Thanks, Mark

According Wikipedia, http://en.wikipedia.org/wiki/Marc_Benioff, if you look in the career section, it is one in the same person.

All, I've release a new version of Atari800MacX, and as usual, it can be found at www.atarimac.com. The changes are listed below. Mark Features Added/Changed: * Added new synchronized sound support, which increases sound accuracy, removes noise from some games, and allows things such as the WoofWoof demo to work which did not work in older versions. The Hi-Fi audio is not selected all the time, but the user is now able to selected between 16 bit and 8 bit sound, with 16 being the default on Intel machines, and only 8 bit sound is available on PPC machines. * Now being built with Snow Leopard, therfore OSX 10.3.9 is no longer supported. Bugs Fixed * Fixed issue SpartaDos X piggyback cartridges which was introduced in version 4.0 * Fixed issue with Cmd-Option shortcuts for window resizing, etc. * Added fix from Atari800 core emulator for mouse emulation handling.

Heaven, try the Atari800WinPlus version they posted in the PM1.5 thread. It will show the colors correctly on the Mac. I'm not sure why it is different on those emulators and the other Windows one. You might want to ask the author of the demo (I will do that also, but may need to forward any responses to the core emulator guys on the Atari800 team, as I'm not that familiar with the the GTIA and ANTIC emulations). Both Atari800MacX and Atari800WinPlus are based off of the Atari800 emulator core (atari800.sourceforge.net), although Atari800WinPlus is severely out of date. Mark

I am sorry, I did not see the additional post here (I was out of town on business last week). Which demo are you referring to? Can you point me to a thread or web link? Thanks, Mark

Yes, sorry, that is what happens with the folders. I probably put a warning the readme's, but then probably no one reads those. For upgrading the best way is to just grab the application file and copy it instead of the whole folder. Eric is still having issues with the debugger window staying open, but I am unable to duplicate it here. If anyone else can duplicate it, please let know. Thanks, mark

All, I'm not able to repeat the issues that Heaven/TQA is seeing with 4.2 on my 10.5 machine either. I'm really starting to suspect that both of the issues may be Snow Leopard related. I stopped by the Apple store this afternoon, and got my Snow Leopard upgrade, so after a backup, I'll do the install and see if I can duplicate the issues on 10.6 here. Thanks, Mark

Eric, Doing the exact sequence you use, I do not get your behavior, at all, but instead the window goes away as it should. It may be Snow Leopard related, as I am still running on 10.5. Is there anyone else out there running Snow Leopard that can try it for us? I will be updating very soon, but it may be a week or two. Heaven, when you say your Gridrunner project will not run on 4.2, can you be more specific? The only thing that has really changed is the debugger in 4.2. And I am already working on 4.3, I can't fix what I don't know about. Can you describe the exact symptoms, or give me a way to repeat it, including disk images or binaries? You can PM them or email them if you like. Thanks, Mark

Eric, I'm not able to repeat what you are seeing here. Is this only happening with the cont command, or does the same thing happen when you press the GO button. I did add some code to keep the window open for the STEP, so it did not flash, but not for the GO/cont. The debugger works as a modal window, so when the emulator is running , no keystrokes will work in it, which is why it is normally closed. (This is really a libSDL implementation issue, it's not designed to work with multiple windows, so I am pushing the envelope with using it here.) Could you tell me what type of Mac and what OS version you are using? Mark

All, For the programmers out there on the Mac, Atari800MacX now has a new graphical debugger. I'm attaching a screen shot of the debugger. The new version can be found at http://www.atarimac.com. Mark

All, I just released a new version of Atari800MacX. The major new feature is a graphical debugger. I'll post a pic in the Programming forum, or download the manual for full details. As usual, it can be found at http://www.atarimac.com. Features Added/Changed: * Added a Graphical Debugger. For a full list of debugger features see the manual or built in help. Bugs Fixed * Fixed issue with Cmd-key menu shortcuts when using International keyboard mapping. * Reverted to Atari800 CVS code for PRO disk image handling, as it hands some images mine would not. Mark

Bruce, Thanks for the feedback. I'm sure there are some bugs lurking out there, as I said I left this thing mostly completed, but untouched for a couple of years. And even back then, I'm not sure I tested everything, my knowledge of Atari systems is a lot better than Tandy's. I'll take into these, and work on an update, but it may be a few weeks. I'm in the middle of a adding a big new feature to Atari800MacX. There is going to be a update sooner for PPC Mac users (I'm assuming you are using an Intel Mac, since it sounds like you didn't have the issues other's did), as I currently suspect I had an error in how the Universal binary was getting built. See other comments inline: There is defiantly a speed switch being emulated, I think there is some documentation on it in the manual, but I will take a closer look at it. I agree that Esc should be that, in fact I've hit it expecting that too. Next update..... I'll let Tim Mann know this, and see if he will update it.... Good point. The only answer is Atari numbers their drives from 1, and I stold the code from my Atari800MacX emulator . I'll fix it next update. I've mainly tested JV3's also, but will take a look at the DMK issues as time allows. Yes, I've seen the same thing. It's present in Atari800MacX too (once again borrowed code ). I haven't narrowed it down to exactly when it happens, but I think it is when you have another window on the screen (like disk management) and it's in front of the main window and you close it. It takes the mouse down from the close action and makes it into the start of a copy action. The main reason, is I'm trying to make libSDL do things it wasn't designed for, it thinks you only have one window open at a time. The bug is very annoying, and it's definitely on my to do list on both emulators. I'm glad you are able to get use out of the emaultor. Thanks again, Mark

Yes, the color change should work, sounds like you found a bug, and I will take a look at it. I will also take a look at removing the speed limit function, and allowing it to run as fast as the host will allow. Atari800MacX has that function, but I think the core emulators (atari800 and xtrs) handle timing differently. Mark

I know it's not Atari related, but I've just finished documenting my new TRS-80 emulator, and it's released at http://sdltrs.sourceforge.net. It is a port of the excellent UNIX TRS80 emulator xtrs. It runs on Macintosh OSX, Windows, and Linux. The Mac version has similar features to my Atari800MacX emulator. The TRS-80 was one of the 3 vintage computers I cut my programming teeth on, third in line behind the Atari and the Apple ][. I've had this emulator essentially done for two years, but never had gotten around to writing the documentation, but finally did. Mark