phaeron

flashjazzcat, on Fri May 25, 2012 12:13 PM, said:

I was able to find and fix one cause of this:
http://www.virtualdu...2.10-test25.zip
http://www.virtualdu...-test25-src.zip

The behavior of put/write/format commands in Altirra changed between 2.0 and 2.1-test. In 2.0 and prior versions, attempting to write to a write protected disk results in a NAK of the command. After some analysis of the 810 firmware, I changed this behavior to ACK the command and send a device error ($45) as the operation result. It appears this behavior is what is tripping up SpartaDos 3.2, which doesn't seem to care whether its writes succeeded (!). DOS 2.0S and SpartaDOS X do detect and report the error.

Marek Konopka, on Wed May 16, 2012 4:50 AM, said:

Well, I wrote the latter, but I'm pretty sure 12 is the correct number. My Acid800 test suite has a test that checks the DMA pattern, and I also have a cycle dump from a hardware analyzer that shows 12 unused cycles after the two LMS address load cycles and before the first playfield DMA cycle.

itaych, on Wed May 16, 2012 9:33 AM, said:

Drat... yeah, this'll happen with either the OS-B or built-in HLE kernels. It should work with an XL/XE kernel. The problem is that Atari switched around the order of HATABS and CIO initialization between OS-B and XL/XE, and the built-in RS-232 handler is set up in a way that only works with XL/XE order. The HLE kernel was written according to the OS-B order in the OS manual, so it also overwrites the R: handler entry. I'll have to look for a different hook to add to HATABS.

As for the Ice-T compatibility fix, the problem was that the built-in RS-232 handler was reading from the originating IOCB through the IOCB base and the X register instead of going through the zero-page IOCB, and Ice-T makes status calls directly to R: using only the ZIOCB. I had broken this while fixing Atari BASIC, which does the opposite by jumping to the PUT BYTE vector without setting up the ZIOCB. Most other calls originate through CIO and are documented in OS manual section 9 as taking arguments through the ZIOCB, so Ice-T seems to be in the clear here.

I dug some more into the Diablo sprite stripe problem, and it looks like RastaConverter has uncovered sprite handling bugs in all emulators.

There are two bugs in current versions of Altirra. One is that it doesn't properly handle a sprite that starts in horizontal blank and is retriggered again in the visible region on top of that image. That's not too bad to fix.

The other problem is nastier and has to do with what is actually displayed when a sprite is retriggered, particularly in quad width as RastaConverter uses. This is the bug that nobody appears to get right. It's best shown with a test program, which tests timed changes to the sprite registers (the sections are HPOSP0, GRAFP0, and SIZEP0):

Altirra 2.0:
 midsprite-altirra20.png   2.59K   12 downloads

Atari800 2.2.0:
 midsprite-atari800v220.png   3.21K   12 downloads

Atari++ 1.6.0:
 midsprite-atari++160.png   2.78K   12 downloads

From what I can tell, RastaConverter simulates what I implemented, which is to reload the sprite's shift register whenever the position counter matches. Atari800 and Atari++ are drawing both sprite images in full. Neither behavior is correct. Based on tests I've done on the real hardware, this is what should happen:

 midsprite-altirra21.png   2.61K   14 downloads

Basically, the contents of the sprite data latch should be ORed into the shift register in its current state at the point of the retrigger. This mostly resembles and overlap of the images, but for double or quad width sprites there is jitter depending on the difference in LSBs of the positions. Ordinarily you'd have to work really hard to find a program affected by this. That is, unless someone would be crazy enough to write a generator that happens to try millions of iterations of random raster programs.

In order to support this in RastaConverter, its inner raster program loop would need to be modified to remember the previous sprite positions so that on a retrigger it could determine how much, if any, of the previous image remains in the sprite's shift register. After that, there is the usual quandary of producing executables which are correct according to real hardware behavior, but don't work correctly on emulators. I hope to at least rectify this soon for at least one of them.

I have also noticed an oddity in the position comparator behavior where the deadline for a new sprite image seems to be one cycle off from where I would expect, but I haven't been able to nail down the exact behavior.