Jump to content

phaeron

Members
  • Content Count

    3,395
  • Joined

  • Last visited

  • Days Won

    16

phaeron last won the day on June 15 2020

phaeron had the most liked content!

Community Reputation

6,175 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. If you soft-load Altirra BASIC from disk, then it has to load 4K lower to avoid getting overwritten by a bug in the OS screen editor. That can cause the problems that you describe, as it sounds like the program may be hardcoding the address of the screen. However, if you run it from a cartridge ROM, then it will have the same documented memory layout as Atari BASIC, as it intentionally matches that for compatibility reasons (there are some games that are extremely tight on memory).
  2. Fast boot does two things: it speeds up the memory clear and checksum routines in the OS, and it installs an SIO hook to do an immediate return on access to nonexistent disk and type 3 poll devices. Eliminating both of these days, combined with SIO patch, makes many programs start instantly. You may not have noticed it because there are several ways it which it can be partially or completely disabled: if it can't locate a standard memory clear or checksum routine, or if SIOV is not used for disk access. Booting a custom OS into SDX in particular will show less effect unless OS-level SIO is enabled. It also tends to be a no-op when full disk drive devices are used because the Auto power-on delay will force an additional delay on startup anyway so the drive firmware can init in time. The SIO patch override function forces the first disk access to a drive to bypass the fast boot hook to detect if anything is intercepting the request. It's better to use the PBI device mode when possible since that allows the emulator hook to be properly placed at low priority, but IIRC there were issues with PBI priorities in SDX -- I think PBI.SYS might interpret PBI priorities backwards from the XL/XE OS.
  3. Enable the "SIO override detection" option.
  4. It still works, but in 3.90 I changed the debugger to defer symbol loading by default for performance and security reasons, so if you are not launching with the debugger open from the start it will not load the listing file to get the traces. There's a notice about it in the console window on start and an option to always load symbols.
  5. https://atariage.com/forums/topic/257578-happy-810-resources/?do=findComment&comment=3622330 It is a v7 ROM that has had the copyright notices zeroed out (which is odd, as it was found on an actual Happy PCB).
  6. Here's a disassembly of the XEP80 firmware I did a while back. xep80.s
  7. This is a compatibility issue with the built-in OS with an unusual screen configuration (split-screen GR.0). Switch to the Atari XL/XE OS and the game should work.
  8. https://www.virtualdub.org/beta/Altirra-4.00-test37.zip https://www.virtualdub.org/beta/Altirra-4.00-test37-src.7z Fixed a rounding problem in the PAL high artifacting engine that was causing excessive banding. Fixed an issue with the windowing on the audio low pass filter and added kernel interpolation to the resampler, for reduced aliasing from ultrasonic audio (which causes you to hear sounds that should be inaudible). The disk drives dialog now asks for a save path if saving a disk that doesn't have a image path set yet, and blocks saving of dynamic disks. Improved the performance of the raw turbo tape decoder. Turbo tape modes have a bit better descriptions. The Tape Editor now has the ability to view and edit the turbo decoder side of the tape, as well as to show the waveform input to the decoder (if waveform caching is enabled on load, which is off by default). For the turbo signal, this shows the post-filter output. The analysis tool now also has rudimentary Turbo 2000 decoding capabilities: You can also see the distortion in the source waveform due to high frequency attenuation, which is what the compensating HPF is for:
  9. You can't rely on VBXE to completely fix this issue. It'll fix the visual glitch, but collisions are still handled by GTIA and at least some versions of this problem result in bogus playfield collisions in Graphics 10. On the other hand, Sophia 2 will fix the collision issue as well, provided that you're either using PAL or can tolerate the change in aspect ratio for NTSC.
  10. After recv_raw_byte(), the cycles per byte is in the thread-local $aux variable. For a standard 19200-baud frame, it'll be 94.
  11. https://www.virtualdub.org/beta/Altirra-4.00-test36.zip https://www.virtualdub.org/beta/Altirra-4.00-test36-src.7z Builds are now hosted over HTTPS, so the links should work directly again. Older builds are also available over HTTPS, but they won't redirect due to annoying behavior in some browsers. I can't edit the old posts, but you can edit the links manually to https. Debugger: 65C816 BRL instruction is now treated as ending a block in the disassembly. Raw tape audio can now be loaded in FLAC format. Fixed regression in loading CAS format tapes with FSK blocks, and fixed the read error message also always reporting position 0. Tape editor has also received a few upgrades. It now has commands to convert selected ranges between standard (decoded bytes) and raw FSK, and also to extract files stored in standard C: format. It also has two analysis features. The first is an Analyze tool that, when dragged over a selection, decodes and displays bytes in that selection. The second is an option to capture bytes as decoded dynamically through POKEY. Together, these can be used to diagnose boot errors: In this case, the problem is a poorly encoded CAS file containing a transition from a standard 'data' block (green) to an 'fsk ' block (blue). The gap in between (gray) is of the wrong polarity, causing a framing error from the start bit being shortened (red byte). We can fix this by using the Draw tool to repair the start bit: ...only to run into a problem later in the tape: Here the analyzer is able to successfully decode the block with a valid checksum (blue bytes), but the boot fails with a framing error. The cause is a slight difference in estimated baud rate that causes the analyzer to just barely squeak by, whereas the OS boot is just slightly off enough for the stop bit sampling position to spill over into the next start bit (gray ticks). This is caused by another data/fsk split within the block, which causes timing problems since 'data' blocks can only specify baud rates to the nearest integer: ...but since the analyzer can decode the block, we can have it rewrite the entire block as clean standard data to avoid the mid-block change in baud rate and the marginal bit sampling timing: ...and now that the tape boots properly, resave a repaired .cas file. Please include the specific test release when reporting versions, since we're up to 4.00-test36. The save states you have work for me, make sure you're on the latest test release since I fixed a couple of save state restore bugs in 4.00-test31.
  12. In order for this configuration to work, you need to attach the SpartaDOS X cart as the primary cart and the MAC/65 cart as the secondary cart to emulate the cartridge stacking. The SDX cart also has to be one of the original SDX cart types that supports the pass-through, not one of the other formats that SDX has been ported to. You can't do proper pass-through with SDX on a MaxFlash cart, for instance; the real MaxFlash cart doesn't support pass-through and has no pass-through port, so the only way you'd get both it and the MAC/65 cart into the cartridge slot of a real computer is with a hammer.
  13. So, the thing about the XEP80 is that it runs nearly the whole screen editor by itself. It's rare for the Atari to desync from the XEP80 in any way because the XEP80 manages the entire framebuffer, cursor position, and logical line state, and sends the cursor position back after every character. Lines entered with the XEP80 are retrieved by actually reading back from the XEP80. One thing that can invisibly cause errors is hidden characters on-screen, which can cause line splices that you wouldn't otherwise get with the standard E: device. This is because the XEP80 handles logical lines differently, by using invisible EOLs in the framebuffer instead of a bitmap. Some of the symptoms you are seeing could be explained by a line splice, especially since the XEP80 is also responsible for moving the cursor back to the start of the logical line. But if this were the case, a good clear-screen should fix it up, it shouldn't be able to persist beyond that. It is possible to visualize this state by activating the internal character set ( The other thing that could cause problems is ANTIC DMA getting turned back on. Check if ANTIC is producing a screen the next time this happens. The ultra-speed driver forces DMACTL off if it sees it turned back on but the standard speed driver doesn't; it tries to coexist with ANTIC in this case though it hasn't been extensively tested. Last thing, in your screenshots you have POKE 83,80. This sets RMARGN to 80, but RMARGN is inclusive, so this is actually extending the right margin behind the normal screen to make 81 columns. Is this intentional? The contents of the 81st column may not be well defined, and furthermore, the XEP80's clear screen routine only clears 80 columns. This may result in strange behavior as the XEP80 relies on the contents of the right column for managing logical lines.
  14. Jerzy Sobola's site has them: http://www.jsobola.atari8.info/dereatari/schematy.htm
  15. The truncated 7x9 character cell is a compromise due to limitations with the NS405 and the built-in firmware. NTSC only has around 240 max active scanlines with reasonably visible being more around 220-230, so using a 10-high character cell would be pushing it heavily with overscan even if you ignore the status row. However, there is a more pressing issue, which is the inflexibility of the NS405's vertical timing parameters. The NS405 requires vertical sync to occur within the first blank character row in vertical blank. This, combined with the hardcoded end-of-row interrupt handling in the firmware, limits the timing parameters that can be used since moving the row interrupt can scramble the regular displayed rows. This is why for NTSC XEPVHOLD actually configures the display for 26 rows and adjusts the VINT register to insert an additional active row off-screen to delay vertical sync. Without doing this it is basically impossible to get the NTSC vertical overscan situation under control since the last non-status row has to be within a dozen lines or so of vertical sync.
×
×
  • Create New...