Jump to content

phaeron

Members
  • Content Count

    3,314
  • Joined

  • Last visited

  • Days Won

    16

phaeron last won the day on June 15 2020

phaeron had the most liked content!

Community Reputation

5,919 Excellent

6 Followers

About phaeron

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Bay Area, CA, USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Check the description in the Add Devices dialog -- the SDrive emulation only covers the small portion of functionality around raw SD card access. You can't run the parts that require mounting disks or browsing the filesystem.
  2. Your re-schematics show the refresh counter being tied to the synchronized reset signal, is that not correct?
  3. VisiCalc jumps directly into the Atari OS SIO routines at $E959. It working previously would have been by chance, sorry. This demo requires the XL/XE OS version 2 and a PAL machine. The version I pulled off of pouet.net doesn't run for me in Xformer 10, it fails to recognize keystrokes at the info screen. The main demo section has a bug with leaving the keyboard enabled with the IRQ handler pointing to garbage. Pressing space bar will act differently depending on how the demo is started. It also doesn't work once the drums start sounding as the drums lock out the keyboard IRQ. I'm not sure what the space bar is supposed to do in this demo but it doesn't seem to be hooked up to anything in the version I have. This depends on the black level of the monitor you are trying to emulate since Ataris output blacker-than-black. A properly calibrated monitor using NTSC will subtract the black pedestal and show the dark colors that you are seeing, whereas a monitor using NTSC-J or an altered black level will show a brighter colors at the low end. The default settings reflect this pedestal and the brightness setting is there if you want to emulate a monitor that didn't have it.
  4. You can print both values whenever either is written to. You can't do this on a per-cycle basis, though, because that's too fine-grained and would also produce a stupidly large log file. This is probably too niche of a case to directly support in the performance analyzer, partly because of how hard it would be to even tell the emulator what your threshold is, and partly because of how tiny of margins you're dealing with (handful of cycles). You're also looking for the worst case instead of the average case. What would probably be more appropriate for this is asserts, as you can tell the debugger to fire a breakpoint when a condition fails at a PC address. This includes checking the ANTIC position counters to see if your routine has blown past where it needs to stop. The help file explains how to set this up -- basically, you emit specially formatted comments in the MADS listing that the emulator picks up to set the conditional breakpoints for you. For instance, if a specific point needs to be reached before the end of vertical blank, you can set the assert condition to (@vpos < 8 or @vpos > 248) and it'll fire if ANTIC has already gone beyond scanline 8. That having been said, the performance analyzer can still help you if it can see code that it identifies as busy looping. LDA zp / BNE *-4, for instance, is picked up as idle code because it does nothing other than poll an address that has to change by interrupt. You'll see this in the timeline as the CPU flow jumping from Main to Idle, and how much Idle time you have. VBI routines can also be assessed this way as the timeline will jump from VBI to Main or Idle before the next DLI. Clicking on any point in the timeline will bring up the execution history in the CPU History pane, which you can use to see exactly what code was executing at that time. As a side note, the vertical blank interrupt is often later than needed and you can sometimes recover some time by chaining the VBI code off of the end of the last DLI instead of using the actual VBI. Not everything needs to actually run in the blanking region and music routines definitely don't.
  5. The MSRLE codec is installed with Windows 10, but Altirra doesn't use it, it has its own internal encoder for the format because I don't want to deal with broken codecs in the emulator. MSRLE only supports 8-bit and 16-bit video, so if you have any scaling options or video effects enabled that require 24-bit RGB output, you can't use this format and the emulator will throw an error. Also, YMMV will vary on whether programs can open it since many programs no longer use codecs installed in Windows and don't bother supporting such an old format. It's included mainly because it's a dirt simple format for how effective it generally is on Atari graphics, though ZMBV is much more effective as a lossless format.
  6. View > Display selects the display pane, opening it if it has been closed. Since the default window configuration only has the display pane, it does nothing.
  7. Yes, 2.81 is four years old and there was a major upgrade for video recording capability in 3.90. The original thinking was that video recording in the emulator was minimal and you would be post-processing the video anyway, so it only recorded raw video. 3.90 adds enough video processing capability that you can go direct to publishing in some cases with the output. However, the Media Foundation encoder is not always the best, so you can still get faster and higher quality encoding with an external editor or encoder. If you are going to post-process the video, it's better not to do the aspect correction in the emulator as this will require more CPU time and produce a bigger video file during recording. The aspect ratios used for correction are 0.857:1 for NTSC and 1.04:1 for PAL, with an additional 2:1 or 1:2 depending on artifacting, interlacing, and VBXE options.
  8. You can do this now through debugger logging if you want, by setting a non-stopping conditional breakpoint that prints those locations to the console, then enabling console logging. You'll have to be less vague about what you're looking for here. The Atari hardware doesn't have much in the way of independent units that can be usefully monitored in utilization like this, they tend to either be always active all the time or necessarily only active when in use. If you're looking for traditional CPU code profiling then there is already a profiler that can be enabled both for live execution and in the Performance Analyzer, and offers both instruction/function level profiling as well as call graph profiling.
  9. http://www.virtualdub.org/beta/Altirra-4.00-test29.zip http://www.virtualdub.org/beta/Altirra-4.00-test29-src.zip Fixed a crash when disabling instruction history while viewing coprocessor execution in the history window. .diskdumpsec debugger command now has -i option to invert the data. Added support for the Indus GT CP/M 2.2 file system in the Disk Explorer. This is lightly tested, extents may or may not work. Fixed a number of Z80 emulation bugs including some missing IX/IY based instructions, broken DAA, and miscellaneous flag bugs. Fixed Z80 disassembly of some instructions with extraneous prefixes, e.g. DD/FD with LD D,E instruction. I think that should be doable, it's not a stack breakpoint like JSR but I can do it with an address range step like the source step mode uses.
  10. I think this is mainly due to the difference in default palette in the emulators, though there are also differences in the video signal produced by the two systems. When I port the game, the color values are untouched, so color $10 on the 2600 becomes $10 on the 800. This is necessary because the games frequently have dependencies on the exact color values used, even reusing the same data for non-color values. You can make Altirra's display brighter in Adjust Colors by using brightness 0%, contrast 100%, saturation 33%. Seaquest uses luma 0 for the sea green so it is very sensitive to the color settings here. This will of course also affect other program displays, and is a bit more saturated than you would ordinarily see. Boosting the overall intensity of the palette will also brighten the seabed but will also cause the high end of the palette to blow out unless you have HDR display enabled. Part of the reason for the overall slightly dark default palette is to avoid unwanted color shifts due to this; for this reason, one of the easiest ways to improve reproduction of the original colors is to raise your monitor brightness so there is more headroom for bright saturated colors (which is essentially what most low-end HDR monitors do).
  11. http://www.virtualdub.org/beta/Altirra-4.00-test28.zip http://www.virtualdub.org/beta/Altirra-4.00-test28-src.zip AltirraOS 3.31: Move Left and Delete char E: commands fixed at column 0 with LMARGN=0; SIO now accepts ACK for Complete in SIO commands for compatibility. Added autodetection of the 1200XL rev. 12 OS. Debugger: gf (go frame) now has a quiet option. Fixes for a couple of configurations where copying or recording frames would produce a low-contrast image due to the wrong range being used. Disassembly window now has options for overriding the M/X mode used when disassembling 65C816 code. Added missing names for SlightSID and SoundBoard layers in the debugger's .map output.
  12. That it is shipping in quantity does help, but it's still work to write and maintain the emulation. Feasibility is one concern which looks fine here; the other is mood. Quite frankly, whether I implement a device often depends on mood, and I'll often implement devices just because I randomly feel like doing so. So, sorry, but I can't really give an answer right now. Even if I said yes to emulating the device, I haven't been working on it and don't have anything to release, so the most that I can say is that I'm not opposed on principle or infeasibility. If I do implement it, you will see it here on AtariAge in the test releases.
  13. I'm sorry, what are you talking about? I added SID emulation because SlightSID was actual hardware being prototyped with an actual Atari computer, not just virtual hardware on a PC.
  14. No current plans, and unlikely. I've been burned in the past by implementing add-on sound devices that had very low uptake but high complexity in the sound chip. Nobody has these devices because they're low production run and only of use in games or demos, and no one writes software for them because nobody has them.
×
×
  • Create New...