Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


phaeron last won the day on March 10 2019

phaeron had the most liked content!

Community Reputation

5,156 Excellent

1 Follower

About phaeron

Contact / Social Media

Profile Information

  • Gender
  • Location
    Bay Area, CA, USA

Recent Profile Visitors

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

  1. Nope, you just give a8rawconv the SCP image instead of the SCP device: a8rawconv image.scp disk.atx
  2. KryoFlux format support is read-only, SCP format support is read/write. It's best to archive in two-step by imaging to SCP first and then converting the SCP image to ATR/ATX. SCP is a raw flux dump of the disk as produced by the SCP hardware, while converting to ATR/ATX requires some interpretation of the flux data. Using a two-step process ensures that everything is captured in one pass on the disk so that no further reads are needed if something turns out to be busted or missing with the decoded image. This is particularly important with disks that are old and brittle or limited access. a8rawconv can image 5.25" Apple II disks, though it is not well tested. It will overdump tracks when imaging to SCP -- 40 instead of 35 -- but this is harmless. You can then convert the image to DOS 3.3 sector order (DO/DSK) or raw nibble (NIB) images for emulator usage. ProDOS order images are not currently supported. My limited experience is that the Apple II disk checksum algorithm is extremely flimsy and prone to missing errors, so it is very necessary to manually check decoded images. You should be able to image a TRS-80 disk to SCP if it is 40 track, single sided. There is currently no decoded image support for this type of format.
  3. What firmware do you have in the drive? Atari and Happy 810 firmware should do two-pass format and verify, but the 810 Archiver does single-pass with interleaved format and verify per track. One thing you could try is formatting a disk as enhanced density on the 1050, then trying to reformat it on the 810. Unlike the write verify command, the format command on the 810 doesn't actually check the data it reads back on the verify pass, it just checks that the sector can be read with a valid CRC. It's possible that the drive is not actually writing anything on the format pass, then verifying the existing sectors. The subsequent writes then fail because the write-with-verify command does actually check the read data against what was written. If I'm right, then trying to format over an enhanced density disk should fail on the format because the verify pass won't be able to read the MFM sectors on the disk. Also, if this is the case, then editing DOS to turn write verify off should also change the behavior: it should get farther or even complete the write "successfully."
  4. Not sure if this was changed as the original versions I made don't specifically have Mac support, but you should be able to override the device path directly on the command line: a8rawconv scp0:48tpi:/dev/cu.usbserial-SCP_JIM test.atx
  5. Should be 1773446/(2*440) - 7 = 2008. The closest divisor is 1773446/(2*440) = 2015, and then 7 is subtracted off to get the POKEY value. Of that 7, 1 cycle is because the counter resets when it goes below zero instead of hitting zero, and 3 cycles each for the low and high timers to roll over. Subtract 7 to convert a division ratio to a DSOUND value, and add 7 to convert a DSOUND value to a division ratio.
  6. There is an issue with the formula that you have found. PAL and NTSC computers differ in master clock rates by 0.9%, and thus different values are needed to produce the same pitch. The formula you have is for NTSC, and the value is slightly inaccurate. It should be 1789773 for NTSC and 1773446 for PAL -- derived from dividing the master clock at 14.31818MHz or 14.18757MHz by 8. Regardless, the values needed should be exact ratios of two, once the -7 bias is taken into account. POKEY's timers run in deterministic logic driven off of the master clock, so a period value of 2011 will produce exactly half the frequency of a value of 1002 (2011 + 7 = 2*(1002 + 7)). Even if the master clock varies, the frequencies produced should still be in perfect relative pitch because they will all be scaled together. That it would seem to require otherwise is odd.
  7. Y=$90 is the status code returned by the SIO routines in the OS when a peripheral fails a command with Error ($45) instead of Complete ($43) in the SIO protocol sequence. This occurs for errors that only happen after the peripheral has started a long operation. It is distinct from Y=$8A, which is returned for a NAK ($4E), which is returned for command errors or data frame checksum errors that are detected quickly. If the drive successfully reads or writes disks but can't format them, then I wonder if the problem might be the connection from the RIOT to the index pulse (IP) input on the floppy drive controller. The 810 doesn't use a real index pulse, it fakes it under RIOT control. For normal reads or writes, this is only needed to force the FDC to time out when a sector doesn't exist, and so the drive can probably work without it. When formatting a disk, though, the FDC requires index pulses since the Write Track command runs from index to index.
  8. Error 10K happens when the format command is failed by the drive. It seems there is some strange code in DOS 2.0S that checks specifically for the device error case (Y=$90) and tries to report the first bad sector as an error code, but many drives don't report a bad sector list and DUP just ends up printing 10K for $FF.
  9. http://www.virtualdub.org/beta/Altirra-3.90-test25.zip http://www.virtualdub.org/beta/Altirra-3.90-test25-src.zip Fixed a couple of crashes in the video recording path in the 32-bit build and for CPUs without SSE4.1 support. Launch help file in dark theme if the emulator is configured for it. Screenshots now have software effects applied when hardware effects are enabled. Fixed SAP type R recorder checking the wrong registers for initial silence detection: it was using AUDFx bits 0-3 instead of AUDCx. Fixed a rare crash when ejecting a disk at a specific time during an unaccelerated disk read. Custom device support updates: Local variables are now supported in script. Fixed broken ! operator in script. Added loop statement. Added support for script cooperative threading. Added support for custom PBI devices. Added support for raw (byte-level) SIO. Added support for asynchronous events between the emulator and network server. Device cold reset is now forced after hot-reload. Added new sample custom devices: R-Verter and raw SIO based disk drive.
  10. You should have until the full command timeout to send back COMPLETE. Floppy disk drives don't send it until the disk I/O is complete as it's the only way for the computer to know when it can send another command. Check if you are sending back the data frame ACK too quickly. The SIO protocol spec requires a minimum delay of 850us between the end of the checksum byte of the data frame and the beginning of the data frame ACK, which is needed for the OS to reconfigure itself to read the ACK. The OS can drop a byte if it is sent before the SIO routine can flip from sending to receiving. It also has a bug with accepting $43 for ACKs, so it's possible that your ACK is getting dropped and your COMPLETE is being checked as an ACK with command timeout (1-2 VBIs).
  11. It's an issue with the hardware accelerated screen effects path -- since some of the effects are handled by the graphics card, they aren't getting applied to the screenshot. I need to force a software FX path on the screenshot buffer to fix this. The reason for the low contrast is that when hardware accelerated screen FX is enabled, the palette range is remapped to preserve overshoot outside of the RGB cube and expanded in the pixel shader. This avoids minor chroma clamping that otherwise occurs.
  12. Rebiasing the unsigned value to signed might work: LDA unsigned_value EOR #$80 ADC signed_value EOR #$80 BVS overflow It's a trick I occasionally use in vectorized code since SSE2 is annoying non-orthogonal for byte ops.
  13. The standard IRQ dispatcher tail-calls into your routine, so yes, you can drop out of IRQ level by clearing the I flag. This effectively drops you to a priority level between mainline code and interrupt handlers. Afterward, you just RTI back to the original caller. Calling into SIOV should be perfectly fine from this as long as only application code was interrupted. Interrupting an OS routine may be less safe since that routine may be using variables overlapping with SIO. I'm not sure if interrupting E: or K: this way is safe. This can be done from an NMI routine as long as you check the I flag of the interrupting routine. The OS SYSVBL does this and skips VBI stage 2 if an IRQ routine was interrupted. In theory it is possible to make this reliable by using the serial output complete IRQ to force an IRQ to happen under software control, thus allowing your routine to 'continue' after the interrupted IRQ routine has exited. Never had an opportunity to actually try this. A 65C816 OS will throw an additional monkey wrench in here as it will have to do additional thunking between native and emulation mode to call your interrupt routine. This is more likely if you interrupt the OS display handler as it is likely to be written in native mode. When this happens, the native interrupt handler will push the full native state onto the stack before switching to emulation mode and calling the handler, then restore the native state on return. If you care about compatibility with these, then you should expect additional stack usage and ensure that you exit normally with RTI and don't attempt to bypass directly back to mainline from your interrupt code.
  14. 53252 ($D004) is P0PF, the player 0 <-> playfield collision register. If a GTIA is present, the POKE 623,65 statement switches the display to Graphics 9, which doesn't support playfield collisions and so PEEK(53252)=0. If a CTIA is present, the POKE 623 does nothing and the display stays in Graphics 0, which then causes a P0<->PF2 collision against the text banner (which is an essential part of the test!). You don't need a comparison for IF statements, as they implicitly test the condition against zero. It looks like there are a couple of race conditions in this test program that could cause false CTIA detections. Lines 150 and 160 should be swapped, and line 190 should be moved after line 220. Otherwise, there is a period of time where the the GTIA is running in the same mode that a CTIA would and could flag playfield 2 collisions.
  15. ...Did you turn them on (System > Configure System > Video > Scanlines)? They don't have to be placed in any particular folder, they just have to be registered in the Firmware Manager. However, if you move the files or the emulator, they may need to be re-registered there.
  • Create New...