Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


phaeron last won the day on June 15 2020

phaeron had the most liked content!

Community Reputation

6,048 Excellent


About phaeron

  • Rank
    River Patroller

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. You have the recorder set to use low video bitrate, 1Mbps. Raise that for better quality. Hardware video encoders aren't as good as software encoders, especially if you have an older card, so you will need more bitrate than you may be used to for a regular non-realtime encode. The only catch is that this will make the output file bigger, so check it to make sure you don't end up with a file too big to upload.
  2. http://www.virtualdub.org/beta/Altirra-4.00-test34.zip http://www.virtualdub.org/beta/Altirra-4.00-test34-src.zip Implements Bit 3 transparent access timing and a fix for the VBLANK timing issue which caused periodic pauses. Altirra doesn't have a CRT effect feature. It can be implemented via the custom effect system, but such an effect isn't included and it only currently works with Direct3D 9 mode. I haven't prioritized this both due to time and also because I don't find most CRT effect shaders to be compelling. Most of the effects I've seen that attempt to emulate CRT phosphors end up either way overdoing it or reducing contrast too much, the latter of which is already a problem when trying to maintain reasonable color accuracy. I keep an old Commodore 1702 monitor for comparison purposes and the fact is that a reasonably adjusted CRT monitor of the era doesn't show that much curving of the image or color convergence artifacts. That makes it a lot more likely that different people want different things out of a CRT effect, and exposing settings is additional complexity on top of the work to implement that effect (which is typically already complex enough as a multipass effect).
  3. You can also resave the disk as ATX from Altirra, which will bake in the sector timing that Altirra uses for ATR images into the ATX image. Atari800 should then boot it.
  4. AFAIK the 810 firmware does not recalibrate when coming out of idle, it retains the current track and seeks directly to the track containing the requested sector. The 810 specifications don't give the motivation behind parking the head, but it may be to place it above the least risky track. The 1050 doesn't do this and leaves the head at the last position, and there are warnings in several places to never power the 1050 on with a disk in the drive.
  5. Only if the transfer can't keep up on average. With DMA transfers it is possible to buffer multiple frames ahead and the frame can be 16 sectors instead of 17. Data rate for 320x192 is 480KB, so at peak rate the DMA engine can pull from the SD card at >3x rate.
  6. Sorry, no port yet. I've had requests for doing so and have a SIDE3 cart but haven't had time to try. It needs a rewrite since the storage interface is completely different (SD vs CF/IDE). The hardware is well suited to it though, DMA engine makes it trivial compared to with raw IDE.
  7. I actually had both of these emulated already as custom devices, though I hadn't shipped the Bit 3 version much (the 1090 80 CVC is one of the samples in the extras folder). As these versions are implemented natively in the emulator, they have integration into the firmware manager and the CRTC support is improved with video timing computation. The 80 CVC has a jumper in the schematic to switch between the halves of the character set ROM for standard and international ATASCII; this is not yet exposed. The Bit 3 does vertically overscan with 240 vertical lines in the display region. It uses a 6845 derivative, so its video timing is more flexible than the XEP80's NS405 and comparable to many other 80 column video displays of the time. There would be no issue with programming a shorter character cell for NTSC, but it's a question of whether the font would be cut off. PAL should be easily doable, and if you can reprogram the EPROMs it would be permanent (though possibly sacrilege). The Bit 3 also scrolls faster than the 80 CVC, because it uses hardware scrolling. However, operations that move lots of text and don't scroll the whole screen, like insert/delete line, are slower because the Bit 3's access to VRAM is relatively slow through a transparent access latch. The 80 CVC uses a unique write-through window where main memory shadows VRAM and both reads and writes are full speed, and from the schematic it seems to fully interleave CPU access for snow-less writes. This means that the 80 CVC has a regular framebuffer in main memory like the E:/S: device. Unfortunately the firmware is a bit half-baked, as it locks up under certain screen editor operations. It also has overhead for entering and exiting through the PBI interface, though it also has a flat 2K firmware window vs. Bit 3's cramped 256 byte bankswitching scheme.
  8. http://www.virtualdub.org/beta/Altirra-4.00-test33.zip http://www.virtualdub.org/beta/Altirra-4.00-test33-src.zip Fixed a bug with BOOT850 on the Additions disk leaving CRITIC set on failure, which manifested as key repeat not working. New experimental debug link device and ATDEBUGX.SYS driver for SDX, which uploads SDX symbols to the debugger. Added XEP80 prefetch quirk emulation and fixed incorrect horizontal sync value. Added Atari 1090 80CVC and Bit 3 Full-View 80 emulation. Improved support for additional video outputs, which are now enumerated in the Video Outputs sub-menu. There is now also a command for switching to the previous video output. Added detection for 1050 rev. H firmware. Fixed a couple of issues with tape sample/second timestamping in the History view, and it now also works after the tape has been stopped. The cassette tape indicator now switches from Play to T-Play when KSO Turbo 2000 is activated. Added a new turbo tape decoder that is level-based instead of slope-based and uses a linear phase high pass filter. There is now also an advanced configuration variable for the cutoff of the old slope filter HPF.
  9. It's not actually the disk handler that determines this behavior, it's the emulator's SIO patch or device emulation. The disk handler is actually not involved as this code is calling SIOV and not DSKINV. On a real SIO-based disk drive, this "works" because the drive doesn't know the length that was passed to SIO and will send 128 bytes back regardless. SIO copies the requested 44 bytes into the buffer, and then inteprets byte 45 as the checksum. Altirra's SIO patch simulates this behavior. I say "works" because this also results in SIO retrying the command and returning a checksum error, which are ignored by the above program. It also causes the drive to continue chattering on the SIO bus after the OS has stopped listening, which can result in another quickly issued command failing. For these reasons, it's much better to just use a correctly sized buffer. The behavior you're seeing in Atari800Win is from its SIO patch, which rejects the short read entirely. If you disable the SIO patch, then it too will return sector data. However, the former behavior is not unprecedented on real hardware since it is possible that D1: is implemented by a PBI device that does see the transfer length specified to SIO, such as a BlackBox / IDE+2 / U1MB. It is possible for the PBI software handler to reject the request outright in the same way as the A8WP SIO patch.
  10. Offset 8 should help a lot if not suffice completely. Altirra detects SDFS by the JMP instruction there, which will be to $xx80 for a SD/ED/DD disk and $xx40 for a DD 512 disk. On a DOS 2 or MyDOS disk it will jump around the BCB to a low $07xx address. You could also cross-check the first few bytes after that since they have defined meaning for both SDFS and DOS 2 disks.
  11. Ah, thanks, I'll fix that. The way Atari BASIC does this is a bit weird, so I'll have to review all of the I/O paths for this (ugh).
  12. Unmounting the disk is not enough as the caching is in DOS and not in the disk drive. DOS does not even know that a disk change has occurred, it can only see changes in the disk contents, and SpartaDOS 1.x does not adequately check if the disk contents have changed before reusing cached directory and file structures. SpartaDOS 2.0 added the volume change serial number to fix this and the Disk Explorer increments that to avoid the problem on SDFS 2.0+ volumes. It implements a binary load XIO call for Atari DOS format executables. Try copying a SpartaDOS 1.1 executable like MEMLO.COM to the H: drive and running it there and it will crash. This is because SpartaDOS's own binary loader can't be used with the H: device due to SpartaDOS's design. MyDOS doesn't report an error because the H: device didn't report one, it succeeded at getting the file length. Sorry, you're right, I messed up converting hex to decimal.
  13. Operative word is started, need to do a bunch of work on it. Found several errors in the SDX executable format section a couple of days ago, for instance. I think the version above is the only one I've posted so far.
  14. SpartaDOS 1.x is prone to overly caching sectors and seeing or causing disk corruption if you modify disks on another computer or in the emulator's Disk Explorer while SD1.x is running. This is because the SpartaDOS 1 filesystem lacks a change number in the superblock and thus there isn't a way for the emulator to tell it that the disk has changed. This was fixed in SpartaDOS 2.0 and I don't recommend using SpartaDOS 1. This is the limitation of the way that some DOSes interact with CIO devices like H:, namely that they expect the device itself to implement EXE loading. This is not possible in the general case for a couple of reasons. First, DOSes use conflicting XIO numbers for such services. MyDOS 4.5 uses XIO 47 to load executables, while SpartaDOS 1.1 uses XIO 48. But XIO 47 in SpartaDOS is Get File Length. The H: device does not know what DOS is running. Second, for this to work the H: device has to reimplement the EXE loader, and this isn't possible in all cases. SpartaDOS has an extended file format that requires access to some memory allocation variables that aren't public and change between versions. Please read the CIO docs in the Atari Operating System Manual and inspect the CIO calls being made to the H: device by these DOSes before making a judgment like this. You are making unfair statements without full knowledge of the limitations of the CIO interface.
  15. You can add external logic to drive extra attributes to add color, but that's not really the same as the NS405 handling it. It's basically using the NS405 as an address counter. You could do the same thing with ANTIC and add extra RAM banks that are addressed in parallel to drive 24-bit RGB, but that wouldn't really be ANTIC supporting 24-bit color. The XEP80 supports a virtual screen with up to 256 columns, and it has commands to horizontally scroll. There's not really much use for it, though. The 120 character limit is from the standard E: device, which has a limit of three physical lines per logical line. The XEP80 doesn't have this limit, but the input line buffer in BASIC is only 255 bytes.
  • Create New...