Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

atarimac

Members
 View Profile  See their activity

  • Content Count

    219

  • Joined

  • Last visited

Posts posted by atarimac

  1. Posted

    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

  3. Posted

    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.

    • Like 1

  4. Posted

     

    Yeah, I guess we know about the carts but the OP was specifically asking about emulators.

     

    Flashjazzcat was right BTW Atari800MacX does support pass through carts amongst its many other great features.

     

    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

  5. Posted

    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

  6. Posted

    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.

  7. Posted

    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

  8. Posted

    Being able to toggle most of the common emulator GUI features like the disk patch would be on my short list.

     

    Steve

     

    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

  9. Posted

    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?

  11. Posted

    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

  13. Posted

    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.

  14. Posted

    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

  16. Posted

    and joyride works again... so it definitly were the missing roms... sorry... I was not aware of that when overwriting an existing folder it deletes the difference files, too... ???

     

    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

  17. Posted

    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

  18. Posted

    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

  19. Posted

    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

  21. Posted

    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

  22. Posted

    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:

     

    * After playing some games, it seems like this thing is running about 1.5x - 2x "normal" speed on my MacBook Pro. The speech from Robot Attack (a Berzerk clone) is definitely at a higher pitch than I remember, and I was getting killed at Super Nova (Asteroids clone). Is there a speed control option for this?

     

    A look through an old TRSDOS6 manual I had lying around indicates that the M4 had a fast and slow speed, so maybe the emulator is running the M1 in fast speed mode, which the M1 never had? The crazy thing is that the SYSTEM command in LDOS 5.1.2 (the M1 version) actually has the SLOW and FAST options, and they actually WORK, so the M1 mode must be emulating a speed switch from the Lobo Max-80 or LNW-80. I can live with this now that I know I can control it.

    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.

     

    * Keyboard key list in the documentation does not say that ESC is the BREAK key, and it really should.

    I agree that Esc should be that, in fact I've hit it expecting that too. Next update.....

     

    * XTRSHARD/DCT whines about needing to be run from the SYSTEM command (when it is)... because it's looking at a flag bit (cflag$ bit 3) backwards. I don't know how ANYONE ever used that thing. Ever. This is not exactly an obscure bug that would only affect a few people... the same bug appears to exist in all three code paths (M1, M3, M4). I just hex-edited over the jump with some NOPs as the quickest fix.

    I'll let Tim Mann know this, and see if he will update it....

     

    * TRSDOS/LDOS numbers drives starting at 0, right? So why does the Media window number drives starting at 1? Ditto for the hard drive units. This is confusing enough to be annoying.

    Good point. The only answer is Atari numbers their drives from 1, and I stold the code from my Atari800MacX emulator :P . I'll fix it next update.

     

    * DMK disk images seemed to be read-only, even when created from the disk image creator. Trying to run the AUTO command on a single-density disk gave a "GAT Write Error" message. I also got the idea that I couldn't make a mixed-density disk (which is needed to make a bootable double-density M1 disk), but maybe that's what the "ignore density flag" option is for. I'm mostly interested in reading DMKs and writing to HD images, so I'll just use JV3s as necessary for temp floppies, and leave it at that.

    I've mainly tested JV3's also, but will take a look at the DMK issues as time allows.

     

    * The screen text copy function can leave selection rectangle garbage on the screen. I'm not exactly sure how I did it.

    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

  23. Posted

    By the way, should the "Emulator Colors" function in Preferences > Display set the color of the monochrome display? Right now, when I change the foreground to green, nothing seems to change, and when I quit and restart, my prefs aren't saved.

     

    Also, is there any option to speed things up, i.e. disable the emu's speed limiter?

     

    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

  24. Posted · Edited by atarimac

    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

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...