Jump to content

phaeron

Members
  • Content Count

    3,219
  • Joined

  • Last visited

  • Days Won

    16

phaeron last won the day on June 15

phaeron had the most liked content!

Community Reputation

5,686 Excellent

4 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. It's because your jump instruction is within the scroll region, so it is fetching multiple jump addresses. See 4.6 Display list, Jump command. The mode line after the last mode line with the vertical scrolling bit set ($20) is still within the vertical scroll region and has its height modified by VSCROL. This is true even for blank and jump instructions that don't have vertical scroll bits. You can get away with this for JVB because it turns off display list DMA anyway and no additional jump addresses can be fetched. You can't get away with it for a jump instruction, which will fetch garbage. The last time I tested this, what happens is that ANTIC re-runs the two address fetch cycles on each scanline of the jump instruction without the instruction fetch. So on the first scanline it'll read and jump to the address you specified ($BC34), but then it will fetch $0202 from $BC34 and jump to that, then read $C0CD from there and jump to that, etc.
  2. It would help if you provided some explanation instead of just dropping an executable that I have to disassemble and guess what you are referring to. In this case, you're stretching a jump instruction to multiple lines through vertical scrolling, which is causing ANTIC to load multiple jump target addresses. It is reading uninitialized memory all over the place including location 0, so I am having trouble getting a matching memory environment between the emulator and the Atari because the executable loaders aren't the same (emulator vs. RespeQt).
  3. 2020-10-23 edition: Couple of 80-column cards, the Bit-3 and the Atari 1090 80CVC. New disk drive stuff: Atari 815, Percom AT88-S1, and Percom AT88-SPD. Some specific firmware revision related behavior for the 1050, Indus GT, and Percom RFD. 1050 diagnostic commands. How various drives respond to read commands when no disk is inserted (turns out a couple return NAK!). Hopefully everything in the doc is OK. I had a failed attempt to upgrade to LibreOffice 7 which I had to roll back because it was way too buggy, and it autosaved with several drawings damaged that I had to manually fix in LibreOffice 6.3 again. The attached copy is the same as the updated file on my website. HWMan-20201023.pdf
  4. http://www.virtualdub.org/beta/Altirra-4.00-test18.zip http://www.virtualdub.org/beta/Altirra-4.00-test18-src.zip Fixed disassembler opcode length table for COP n instruction. Added support for double-sided ATX images. Currently this only works for XF551-style double-sided images; ATR8000-style or PERCOM-style is problematic because ATX files use physical layout and there's no way to tell how it should be mapped to logical layout. Fixed a bug with physical sectors not being reversed properly, causing the XF551 to format side 2 slowly. 815 track materialization routine now supports sector sizes other than 256 bytes. Fixed height of JVB instruction repeats when ending a vertically scrolled region.
  5. It's a bit tricky because of the way the GTIA audio is rendered: square waves are now rendered through a trick that fuses the integration of the square wave edges with the differentiator in the high pass filter, so there isn't actually a normally rendered version of the GTIA's audio output in the same domain that the POKEY output is currently shown in. I could tap downstream of the high pass filter but that would show different POKEY output than now (after the second high pass instead of only the first). Ah, yup, that's a bug in the disasm instruction length table. Fix queued for next build. Well... dumping raw memory to a tape image seems like a bit of a niche. Could you elaborate on your use case?
  6. The suggestion is essentially to fudge the disk to work around limitations in the Greaseweazle software (it looks like the hardware is capable). This changes the disk and can break some protected disks, so it's not an idea I'm fond of.
  7. Sure the timing information in this disk image is correct? The sectors on track 0 only have timing values up to $2D78 (11640), which is only up to half what ATX images normally use for a full revolution. This is causing boot to fail in Altirra with 815 emulation enabled as the track materialization routine is overlapping sectors.
  8. The software you are using to write back the disks from SCP images isn't handling sectors crossing the index mark, causing those sectors to be corrupted. Your Zaxxon image has its tracks index-aligned, which is why it writes back OK, while the Lode Runner and Shamus images aren't. I wrote your Lode Runner image to a disk with a8rawconv and a SuperCard Pro device and it booted fine on my 800XL, so your image is OK. This works because a8rawconv can re-analyze the track to use a splice point in the middle of the track between sectors, which generic SCP tools don't necessarily do.
  9. http://www.virtualdub.org/beta/Altirra-4.00-test17.zip http://www.virtualdub.org/beta/Altirra-4.00-test17-src.zip Fixed horizontal scrolling issues with IR mode 3 (was caused by overdecoding). Added an option to invert data for the 815, to emulate the way it reads/writes data inverted from other drives.
  10. http://www.virtualdub.org/beta/Altirra-4.00-test16.zip http://www.virtualdub.org/beta/Altirra-4.00-test16-src.zip AltirraOS bumped to 3.29: NOCLIK is now implemented in XL/XE mode. Megacart (3) 512K banking fixed to only use bit 7 for disable. Fixed a crash that could occur if somehow a disk image got persisted in settings with an empty path. The Wine64 on macOS bug workaround has now been enabled by default -- it activates on the x64 build whenever a bad TEB pointer is detected and the program is running under Wine. Debugger: .diskreadsec command now always uses the virtual sector size, for consistency with .diskwritesec. Removed an unnecessary stat call in most file open paths and fixed some cases of poorly buffered disk image I/O. Fixed bug where some portions of the emulator like the Disk Explorer could not write to double-density boot sectors when formatted by a full drive emulator. Fixed bug where XFD image files were always completely rewritten on the first write instead of being incrementally updated. Fixed the FDC to use proper write track limits for 300 and 360 RPM disk drives. Removed a hack that had been put in to make the 1050 work, as it now properly runs the FDC in 8" mode as the real drive does. Fixed an FDC issue preventing the 1050 Duplicator firmware from formatting disks (waiting too long for initial byte write). ATX: Sectors are now properly sorted by ascending position when writing. ATX: Fixed bug where an unmatched extra sector info chunk would cause the parser to hang. ATX: Added experimental support for double density images. The specification for this is not yet finalized, so this is gated in Tools > Advanced Configuration > image.disk.atx.full_sector_support.
  11. It has, but I haven't done much on this for a couple of reasons. Creating and maintaining such an interface would take some effort, and also create a support dependency with other projects. I haven't been able to justify the complexity and cost of this. These functions are available internally but they're not interfaces that have to remain stable. Another reason is that I'm not very interested in making it too easy to integrate Altirra as part of another product. I've had some mediocre experiences with this on another project where this created some support nightmares, because I would get contacted for issues caused by the way my program was being driven by another program, and the authors of that program did nothing to mitigate this while using packaging that often bypassed any instructions I had and/or violating the license. Some of this can be done through a custom device, however. You cannot control the emulation but you can interact with it, particularly with controllers, and it does support a network connection. It's mostly oriented toward features that an actual device could provide, so it doesn't provide access to things like the video output or main memory. This looks like an issue with M/X mode prediction that may be difficult to solve. The way the disassembly view works in 65C816 mode is that it uses the current M/X/E bits as a starting point and then predicts the M/X mode forward while disassembling instructions. In particular, it watches for REP, SEP, CLC, SEC, and XCE instructions. This allows it, for instance, to disassemble this sequence: 01:0001: C2 20 REP #$20 01:0003: A9 00 00 LDA #$0000 01:0006: E2 20 SEP #$20 01:0008: A9 00 LDA #$00 01:000A: 4C 00 00 JMP $0000 However, this can fail if REP/SEP instructions are picked up from adjacent routines not connected to the code flow leading to the current instruction. Another factor is that the disassembly view only regenerates the view whenever the focus address (PC) gets too far out of the view or the mode changes, both for efficiency and to avoid resetting the selection and scroll position of the view. You can see this by the location of the "reverse disassembly mismatch" notes, since that appears at the location where the view was originally centered. Due to previous control flow, your first image is actually using a higher address for view anchor than the second, as mode change from the REP reset the view anchor. My guess is that there was a REP/SEP instruction that just barely shifted into the view range after the REP instruction and then shifted out after the SEP. In theory, the disassembler should be able to do a better job here as the previous instructions have straight-line flow to the PC and thus should share the X bit mode as the current state, which can then be projected backwards. This is tricky for the reverse disassembler, though, which has to try to disassemble backwards to get to a reasonable state for the start of the disassembly, above the PC. For instance, given a view anchor of $1080, the reverse disassembler's job is to try to find a starting point around $1000 or so that leads to a clean disassembly through $1080. Right now it simply assumes the current M/X/E bits for 65C816, and to do a better job with context-sensitive decoding it would need to follow multiple control flows backwards with independent states. This is also made harder by the 65C816 having no invalid opcodes. I'd have to think about this and try some approaches -- I'm not sure it would work out better than manual override or history-sensitive decoding.
  12. Interesting, I may have to look into a setup like this as I have a 1030. I'm pretty sure the last time I tested Altirra's replacement 1030 handler that I was able to tone dial out over a landline and actually connect to Earthlink at 300 baud.
  13. It is as smooth as it can get for me, given that in PAL the emulator needs to resample from 50Hz to 60Hz. In NTSC, it is overrunning the frame and dropping to 30Hz due to the huge scroll blit: By my reckoning VBXE only just barely has enough memory bandwidth to brute-force scroll a 320x240 SR screen in NTSC and not enough to do further rendering. There are 114 * 8 * 262 = 238,944 local cycles per frame, of which 153,600 are needed for the blit and 76,800 are needed for display (overlay) DMA. 153,600 + 76,800 = 230,400, with 8,544 local cycles left over. It might actually be faster to redraw the entire landscape from scratch with a large blit list of lines since the blitter can fill at 1 cycle/byte vs. copy at 2c/b. Hardware scrolling would be much faster than either, though.
  14. Altirra -3.00: creator $0002 version 0 Altirra 3.00+: creator $5441 ("AT") version 0 a8rawconv -0.93: creator $0002 version 0 a8rawconv 0.94+: creator $5241 ("AR") version 0 I don't think keeping non-mnemonic numeric codes for creators is a good idea as there's not good precedent for keeping such a global registry. The best example we have is cartridge type IDs and it still isn't managed in a way that anyone could easily allocate a new ID and disseminate that information to everyone who needs to implement it. Also, such a system makes it impossible for tools to identify creators added after the tool was made. Best action IMO would be to deprecate the 16-bit creator fields and just put it in a string metadata chunk at the end of the file. MD5s cannot be incrementally updated by design and thus using them would necessarily require that metadata to be outside of the region covered by the MD5s. You can do the exclusion trick for one MD5 but the moment you have two MD5s covering each other you are screwed. IMO integrity checksums don't belong in the file -- we have this for the .CAR format and it's only been a headache while not catching anything, when it's even verified at all. Traditional archive formats are better for both integrity checking and compression, and if you really want to be able to still use the files directly it's better to support transparent gzipping on the files. A general problem with metadata is that it's hard for automated processes to figure out how to deal with it when resaving the disk. If an emulator or disk editing tool needs to update or rewrite a file, it's not convenient to pop up a big dialog asking how to handle the metadata. Best and simplest way I know of to handle this is what PNG does and just have one bit for each metadata item indicating whether to keep or drop that item on save.
  15. I believe that the 6502 will always execute the first instruction of the NMI handler before starting to handle the next one, based on IRQ/BRK testing. NMI handling should be similar as the 6502 uses common behavior to begin handling an interrupt and only later in the 7-cycle sequence actually decides which vector to use. As for the earliest point where the internal NMI flag is cleared and can be retriggered by signal, though, that I'm not sure. visual6502 should reveal this.
×
×
  • Create New...