Jump to content

phaeron

Members
  • Content Count

    3,170
  • Joined

  • Last visited

  • Days Won

    16

phaeron last won the day on June 15

phaeron had the most liked content!

Community Reputation

5,527 Excellent

3 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. Yeah, you'll need to remove the dependencies on SETVBV and XITVBV and the RUN segment, and just let the SAP player invoke you via the INIT and PLAYER addresses.
  2. This is actually a bug in Altirra. The OS ROM isn't available in SAP files, and the reason you're crashing in the SAP players is due to the use of XITVBV. The reason why you're able to do this in Altirra, though, is that your executable has INIT/RUN vectors in it, which is also not supported in SAP but in Altirra prevents the type D player stub from running. The type D player stub normally sets up a proper SAP-like environment with RAM at $D800-FFFF, a title screen, and invokes the player VBI at the proper 50/60Hz rate regardless of whether the system is NTSC or PAL.
  3. The Atari 400/800 mode of the SCP 2.20 software does not produce a single-sided image, however. It double-steps a 96tpi drive to dump 40 tracks on both sides of the disk. You can see from the above hex dumps that the Atari 400/800 mode disk uses a mode byte of $10, which is disk_AtariFMSS. The linked conversation appears to confirm that the only way to determine the mapping from the TDH entries to physical tracks is to use the manufacturer/disk type. As I've mentioned previously, this is problematic for three reasons: The program reading the SCP image needs to know about all disk types. It would not be able to process any new disk types added after the program was written. a8rawconv can decode enough of any 177x/179x/279x compatible format to be able to determine splice points to rewrite tracks from raw flux. The SCP image specification does not indicate which of the disk types are 40/80 track or single/double sided. a8rawconv supports some disk formats that do not currently have a disk type mapping, such as Atari MFM enhanced density and double sided / double density, as well as blind imaging of disks with unknown format. The interpretation you've specified also prohibits dumping of half tracks for double-sided 40-track disk types, which seems like a strange limitation. Ideally, the TDH would either always have been spaced out for 80 tracks / double sided, or a flag in the header to indicate the track spacing. But if that isn't possible, then at least we need the track count and sides for each of the disk type definitions in order for SCP image interoperability between tools to be possible and reliable.
  4. Yes, it's easy to do in a SAP type R file. After the blank line is just a raw dump of $D200-D208 values per frame, so you can easily check the AUDF1 value and kill the corresponding AUDC1 volume when it is 0. Just search for the first instance of $0D/$0A/$0D/$0A in the file and then read/write the remainder of the file as an 9xN byte array.
  5. I finally got around to looking at this and trying to update a8rawconv's SCP image I/O routines, and I'm afraid I still don't understand how to distinguish between SCP images that have 40 tracks/side and 80 tracks/side stored in the image. Updating to SCP 2.20 software did not change the way the images were written out, so it's not an old-bug issue. With SCP 2.20, imaging the same Atari single-density disk on a 96tpi drive gives the following file headers: Atari 400/800 mode (40 tracks, 2 sides dumped): 00000000: 53 43 50 22 10 02 00 4F-06 00 00 00 C8 BA 40 2B IBM 360K mode (40 tracks, 2 sides dumped): 00000000: 53 43 50 22 40 02 00 4F-06 00 00 00 3C 59 3F 2B IBM 720K mode (80 tracks, 2 sides dumped): 00000000: 53 43 50 22 44 02 00 9F-06 00 00 00 C1 D6 4C 45 In all cases, the track list was densely packed, containing 80 or 160 track entries with no gaps. As can be seen from the header dumps above, all images indicate 96 TPI. The only difference between the 40 and 80 track images is the disk type and the track range. As you might expect, a8rawconv can decode the first two images but not the third, because on the third it sees the half-tracks and thus fails to decode anything beyond track 0. So the question remains -- how is a program reading an .SCP image supposed to determine the mapping between an entry in the track table and the physical track number on a 96 TPI drive? Presumably it can't be the track range, as it wouldn't be possible to distinguish between a full image of a 40-track disk and a half-image of an 80-track disk. I hope it's not the disk type, because then a8rawconv would have to have a lookup table of all existing disk types and wouldn't be able to handle new types, and it also isn't documented which disk types store 48 TPI or 96 TPI.
  6. Not with SAP type R. A Type R file only contains samples of AUDC1-4, AUDF1-4, and AUDCTL. It doesn't capture the SKCTL writes needed for two-tone mode.
  7. Nice. Minor issue in the __clock() code: RTCLOK ($12-14) is updated from the NMI-based VBI stage 1 handler, so SEI/CLI doesn't hold off updates. One fix is to read RTCLOK+1, RTCLOK, and RTCLOK+2 in that order, and then re-check RTCLOK+1 and repeat if it has changed.
  8. This is unfortunately the same problem that someone else reported earlier: your macOS-specific version of Wine is not setting up the Windows thread/process environment control blocks correctly and this is causing the core thread creation function in the C runtime library to fail.
  9. Hmm... that's code that shouldn't have changed. Try this version with /startuplog:hostdisp,hostui,hostwinmsg /gdi: http://www.virtualdub.org/beta/Altirra-4.00-test7.zip http://www.virtualdub.org/beta/Altirra-4.00-test7-src.zip This will log all window messages as well as attempt to do a manual crash dump to bypass Wine's busted dbghelp.dll. The log will be longer than usual, but only the part after "Creating display window" is needed. We'll see if this is enough to pin down where exactly the crash is occurring. (For anyone else -- test7 doesn't contain changes other than diagnostics for the above issue, so you can skip it.)
  10. http://www.virtualdub.org/beta/Altirra-4.00-test6.zip http://www.virtualdub.org/beta/Altirra-4.00-test6-src.zip Add new advanced configuration variable system for editing under the hood parameters. Currently only has a few dark mode colors, but the intent is to add more here that can be tweaked if necessary for unsupported parameters that don't need a full UI. Add additional startup logging. Centralize startup randomization. Randomization is now all chained off of a single seed, which is now exposed in the UI. You can lock to a specific seed to repeat the same behavior on each boot for debugging. Disks now have randomized starting rotational positions. Add load timing randomization option for executables, defaulted on. Try on -test6 with /startuplog:hostui,hostdisp. Something is going on in display pane init and there's more logging in this version to narrow down what's triggering the problem. What you're doing with the debugger is impossible in code as it requires the 6502 to run two pieces of code at the same time: you're trying to execute code to set A=0 at the same time as the loop that is waiting for RTCLOK to increment. You could run an interrupt to do this, but that would be silly compared to just editing the code to skip the loop that you don't want.
  11. LDA #0 does set A=0 as "r a 0" does, but LDA also sets the N and Z flags. There isn't a way in assembly to only set A without the flags.
  12. The help file has the full spec. You've basically got it, but you don't need the file source as you don't need to init the RAM data: option "name": "256b D500-RAM"; Segment ram: { size: 256 }; MemoryLayer wina: { name: "D500-RAM", address: $D500, size: $100, segment: { source: ram, offset: 0, mode: "rw" } };
  13. You can't just change the protection on an address space range, something has to provide RAM at that address. One way is to write a custom device that has a memory layer to map 256 bytes of RAM there.
  14. Yes and no. In the power-up testing that I've done, RANDOM ($D20A) is not typically random on power-up as POKEY typically powers-up either in init state or with the LFSR locked up. The value sequence after POKEY is initialized is also fully deterministic and so cartridges can't rely on this. Executables are a bit different because it depends on what medium you load them from. Auto-boot the executable from a cart and it will be fully deterministic. Loading from disk is non-deterministic, however, and the value in RANDOM is based on the number of machine cycles after leaving init mode. Even then it's not fully random -- keyboard scan can only report keys on specific cycles, for instance. I'm OK with adding an option to do this, as it comes up often enough that it'd be worth leaving on even. But I'd have to think about how to do it because not everything is completely randomized -- VCOUNT is synced in some cases due to a wait on vertical blank due to a timed out SIO command. I can either put in a random 0-1 frame delay or warp the polynomial counters, not sure which is better yet.
  15. Use a non-blocking breakpoint to trigger the command: bp -n address "db $50 L$10"
×
×
  • Create New...