cas files not working in atirra

[Mclaneinc]

Every time I see requests for tape / turbo tape additions on the Altirra blog I simply see the words "But why???" repeating time after time in my head.

 

Would these additions ever be used bar the initial "oh new feature" buzz.

 

For me its like Toni Wilen of Winuae adding support for the old VHS data backup system that was made for the ST and Amiga, its an old unfriendly and rarely purchased let alone used item requiring lots of research and programming to please a handful of purists.

 

Worth doing, not in my book, BUT its not my emulator nor my free time...

[Kr0tki]

All in the name of emulation accuracy and authentic feel, I suppose.

For me it's rather in the name of preservation of the software in its original form, for future generations. Various tapes contain parts like custom loaders with graphics or animations, or interesting forms of copy protection - these are things worth preserving. But preservation itself would be worthless if there'd be no means of actually running the preserved software. Hence the need for support in an emulator.

Edited October 5, 2011 by Kr0tki

[charliecron]

Don't worry tape lovers, we have perfectly good sio2pc emulation of tape drives to play with our .cas and wav files!

[phaeron]

I've run into an interesting snag with Henry's House. It doesn't boot correctly on my dev tree in NTSC mode and SIO patch off because the OS misdetects the baud rate. The reason appears to be a race condition in the OS. This is where it measures the time at the beginning of the block sync:

 

 31165:248:  5 | A=00 X=02 Y=C0 S=EA P=36 | ED56: AE 0B D4		 LDX VCOUNT
 31165:248:  9 | A=00 X=7C Y=C0 S=EA P=34 | ED59: A4 14			LDY RTCLOK+2
+ NMI interrupt (VBI)
 31165:249: 59 | A=00 X=7C Y=33 S=EA P=34 | ED5B: 8E 0C 03		 STX TIMER1
 31165:249: 63 | A=00 X=7C Y=33 S=EA P=34 | ED5E: 8C 0D 03		 STY TIMER1+1

 

And here's where it measures time at the end:

 31166:253: 54 | A=00 X=01 Y=00 S=EA P=36 | ED8A: AD 0B D4		 LDA VCOUNT
 31166:253: 59 | A=7E X=01 Y=00 S=EA P=34 | ED8D: A4 14			LDY RTCLOK+2
- 31166:253: 62 | A=7E X=01 Y=35 S=EA P=34 | ED8F: 20 C8 EC		 JSR $ECC8
31166:253: 68 | A=7E X=01 Y=35 S=E8 P=34 | ECC8: 8D 10 03		 STA TIMER2
31166:253: 72 | A=7E X=01 Y=35 S=E8 P=34 | ECCB: 8C 11 03		 STY TIMER2+1

 

The problem is that the OS considers VCOUNT >= $7C (scan 248-249) to be the rollover point for the RTCLOK bump, and this isn't the case as there is a small window between the VCOUNT increment and the VBI with VCOUNT=$7C. This causes the OS to think that two entire VBLANKs have gone by and thus to produce a garbage baud rate determination. Worse yet, the timing for the load of this tape in Altirra just happens to be exactly right in NTSC + XL/XE OS to hit this 100% of the time on a particular portion of the load, while on a real Atari you'd rarely hit this and if you did you'd probably just curse tape and try the load again.

 

Sadly, I think that if Atari had simply used >= $7D as the check, this might not have been an issue.

 

I'm trying to think of good ways to solve this, but so far the only thing that comes to mind is to patch the OS, and I really hate doing that. My standard way of hooking the OS won't work because Altirra uses address hooking, which is disabled in RAM for safety reasons and thus it will fail if a loader copies the OS into RAM as some do. I'd have to actually modify the OS code and fix the checksum, which I really hate doing (it can cause programs to fail custom OS checks).

[Rybags]

What about the automatic keypress that starts the load? I assume you inject that in when the user selects Autoboot from the menu.

 

Could having some sort of random delay fix that?

[serj]

Avery, but after all game "Henry house" is perfectly loaded with cassette player with included SIO-PATCH in modes NTSC and PAL.

In what in general a problem?

Edited October 6, 2011 by serj

[Kr0tki]

I've run into an interesting snag with Henry's House. It doesn't boot correctly on my dev tree in NTSC mode and SIO patch off because the OS misdetects the baud rate. The reason appears to be a race condition in the OS.

 

What a coincidence - we discovered the same issue at AtariArea just a month ago. Roughly estimated, the baudrate-detection failure happens about once every few thousand blocks. We were pretty amazed that it kinda explains the widespread opinion of tapes being unreliable - every 20-30 tries your tape just fails to load, seemingly without reason.

 

Worse yet, the timing for the load of this tape in Altirra just happens to be exactly right in NTSC + XL/XE OS to hit this 100% of the time on a particular portion of the load, while on a real Atari you'd rarely hit this and if you did you'd probably just curse tape and try the load again.

I don't know about Altirra's inner workings, but in Atari800-a8cas the "curse/try again" solution works as expected. The issue is 100% reproducible only when the initial conditions are exactly identical, and that generally happens only on start of the emulator.

 

Sadly, I think that if Atari had simply used >= $7D as the check, this might not have been an issue.

AFAIK it wouldn't be enough. During loading (CRITIC set) the VBI routine ends before end of scanline 249, ie. before VCOUNT increments to $7D. It would still be possible that the baudrate routine reads $7C from VCOUNT after RTCLOK has been increased by VBI, which would cause a bad result.

 

If I didn't mess up the computations, the window between VCOUNT increment and the start of NMI is min. 12 cycles (NMI can fire later, depending on the "current" instruction) and the only soultion that works would be to waste exactly 11 cycles between end of LDX/LDA VCOUNT and start of LDY RTCLOK+2. That way, if the value read from VCOUNT is $7B then we are sure that RTCLOK+2 will be read before NMI; and conversely, if the value read from VCOUNT is $7C then we are sure that RTCLOK+2 will be read after NMI.

 

I'm trying to think of good ways to solve this, but so far the only thing that comes to mind is to patch the OS, and I really hate doing that.

The same problem with Atari800-a8cas. Currently "curse/try again" is the official solution. We don't want to deprive the users of reliving the "be quiet or the tape won't load" experience, do we?

Edited October 6, 2011 by Kr0tki

[phaeron]

What about the automatic keypress that starts the load? I assume you inject that in when the user selects Autoboot from the menu.

 

Could having some sort of random delay fix that?

 

Ew. Yeah, a random delay would do it, but I really hate doing that... and it'd be an unreliable solution.

 

Avery, but after all game "Henry house" is perfectly loaded with cassette player with included SIO-PATCH in modes NTSC and PAL.

In what in general a problem?

 

SIO patch works because in that case the baud rate is being computed by native code instead of 6502 code. Also, the Fast Boot option will also change the timing since it accelerates the checksum and memory test phases (I have this on usually).

 

Worse yet, the timing for the load of this tape in Altirra just happens to be exactly right in NTSC + XL/XE OS to hit this 100% of the time on a particular portion of the load, while on a real Atari you'd rarely hit this and if you did you'd probably just curse tape and try the load again.

I don't know about Altirra's inner workings, but in Atari800-a8cas the "curse/try again" solution works as expected. The issue is 100% reproducible only when the initial conditions are exactly identical, and that generally happens only on start of the emulator.

 

Altirra has a deterministic cold reset, so this doesn't work -- beam position, memory contents, all registers, and all random number seeds are set to constant values.

 

Sadly, I think that if Atari had simply used >= $7D as the check, this might not have been an issue.

AFAIK it wouldn't be enough. During loading (CRITIC set) the VBI routine ends before end of scanline 249, ie. before VCOUNT increments to $7D. It would still be possible that the baudrate routine reads $7C from VCOUNT after RTCLOK has been increased by VBI, which would cause a bad result.

 

If I didn't mess up the computations, the window between VCOUNT increment and the start of NMI is min. 12 cycles (NMI can fire later, depending on the "current" instruction) and the only soultion that works would be to waste exactly 11 cycles between end of LDX/LDA VCOUNT and start of LDY RTCLOK+2. That way, if the value read from VCOUNT is $7B then we are sure that RTCLOK+2 will be read before NMI; and conversely, if the value read from VCOUNT is $7C then we are sure that RTCLOK+2 will be read after NMI.

 

Rats, you're right. I measured the VBI handler with CRITIC set and it takes 139 unhalted cycles to execute in the best case. ANTIC won't normally do DMA in that window, so that delay sounds like a stable solution. (It is possible to get playfield DMA in this region, but it isn't normal behavior by any stretch.)

 

The VCOUNT increment is first visible 13 cycles before the earliest point at which the 6502 can begin acknowledging the VBI, so I think it'd require 12 cycles of delay between the instructions. I should try that and see if it passes The Curse of a Tape Player.

 

I'm trying to think of good ways to solve this, but so far the only thing that comes to mind is to patch the OS, and I really hate doing that.

The same problem with Atari800-a8cas. Currently "curse/try again" is the official solution. We don't want to deprive the users of reliving the "be quiet or the tape won't load" experience, do we?

 

We want to provide the option to relive the full experience, not to forcibly inflict it. That's why we allow SIO patching.

[Rybags]

OK, how about randomised beam position on coldstart then?

 

We have a blank display anyway, so there shouldn't be any garbage. The bug would still creep in on that 1 in 2,000 blocks or whatever but it would be an authentic reproduction of reality.

[Mclaneinc]

 

We want to provide the option to relive the full experience, not to forcibly inflict it. That's why we allow SIO patching.

 

ROTFL.....

 

Hear hear...

[Kr0tki]

The VCOUNT increment is first visible 13 cycles before the earliest point at which the 6502 can begin acknowledging the VBI, so I think it'd require 12 cycles of delay between the instructions.

 

Huh? I might be missing something. If I'm reading Altirra Hardware Reference Manual correctly, then VCOUNT increment is visible at cycle 111 of a scanline and NMI handler starts execution at cycle 9 of the next scanline (or later). 9+114-111 gives 12 to me.

[ijor]

Very interesting stuff...

 

What a coincidence - we discovered the same issue at AtariArea just a month ago. Roughly estimated, the baudrate-detection failure happens about once every few thousand blocks. We were pretty amazed that it kinda explains the widespread opinion of tapes being unreliable - every 20-30 tries your tape just fails to load, seemingly without reason.

 

I doubt this explains why A8 tapes are not too reliable. The issue is, again, very interesting, but doesn't seem too significant. I did a lot of work with tapes back on the day. Most failures had no relation to this. I wasn't then aware about this issue, but many errors originated right at the tape ADC interface (the bit was already wrong at the SIO interface).

 

Don't worry tape lovers, we have perfectly good sio2pc emulation of tape drives to play with our .cas and wav files!

 

Do we? Most SIO2PC interfaces don't have the motor control signal signal. Can't have perfect emulation without it.

[ijor]

Ew. Yeah, a random delay would do it, but I really hate doing that... and it'd be an unreliable solution.

...

Altirra has a deterministic cold reset, so this doesn't work -- beam position, memory contents, all registers, and all random number seeds are set to constant values.

 

Phaeron, I can understand you hating introducing randomization, but IMHO it is the correct thing to do. I had similar issues with protections that required some randomization. Of course, this must be configurable, because a constant deterministic power up is important for such purposes as debugging.

[phaeron]

The VCOUNT increment is first visible 13 cycles before the earliest point at which the 6502 can begin acknowledging the VBI, so I think it'd require 12 cycles of delay between the instructions.

 

Huh? I might be missing something. If I'm reading Altirra Hardware Reference Manual correctly, then VCOUNT increment is visible at cycle 111 of a scanline and NMI handler starts execution at cycle 9 of the next scanline (or later). 9+114-111 gives 12 to me.

 

Apologies, this is an error in the current version of that doc. I had forgotten to change this reference from 111 to 110 when I adjusted all of the cycle numbers to be one lower. Acid800's antic_vcount test verifies this increment timing and the two critical cycles are the 7th and 8th cycles after an INC WSYNC in vertical blank, or equivalently the 8th and 9th after 2x STA WSYNC. Unfortunately, I can't verify the doc on an Atari like I can the test code.

 

I'm seriously considering adjusting the cycle numbers back, though, because I can't find any actual basis for the numbering I'm currently using. I originally changed it because someone told me that those were the correct numbers for the ANTIC horizontal position counter, but after ijor reversed the ANTIC schematics, I don't see any basis for it in the schematic. The current numbers are a pain for me because they're one off from Altirra and I never could justify reworking the entire code base just to shift the hpos numbers down one.

Edited October 12, 2011 by phaeron

[Kr0tki]

The "NTSC and PAL Display" drawing in the Atari 400/800 Hardware Manual (p. VI.2) counts ANTIC cycles from 0 to 227. I'm thinking that counting CPU cycles from 0 would be consistent with that.

[HiassofT]

Hi phaeron!

 

I'm seriously considering adjusting the cycle numbers back, though, because I can't find any actual basis for the numbering I'm currently using. I originally changed it because someone told me that those were the correct numbers for the ANTIC horizontal position counter, but after ijor reversed the ANTIC schematics, I don't see any basis for it in the schematic. The current numbers are a pain for me because they're one off from Altirra and I never could justify reworking the entire code base just to shift the hpos numbers down one.

This is indeed a tricky issue. Last year I hooked up my logic analyzer to the CSYNC and LUMx lines and captured the states while displaying an ANTIC mode E line (alternating colors 1 and 2) with player missile DMA enabled:

One can see that the LUMx and CSYNC change states somewhere at PHI2+400ns. With the tPD of the 4050 (typ. 60ns, max 110ns) the actual output of the video circuit occurs almost at the end of the PHI2 cycle. Therefore shifting all cycle numbers by one, with the first PM DMA in cycle 113 and the first display list DMA in cycle 0 could be justified. Having an offset of -100ns is smaller than +460ns.

 

OTOH having negative offsets seems somewhat unnatural - in electronics you usually don't have negative delays . So keeping the old numbering (PM DMA in cycle 0) and noting that actual display output is delayed by some 460-500ns would be the better solution, IMHO.

 

so long,

 

Hias

[ijor]

I always considered absolute cycle numbers to be completely meaningless. They are, in the best case, a conventional issue. Even relative numbers aren't always completely unambiguous. The only thing that matters is the relation, distance and displacement between two events.

 

The "NTSC and PAL Display" drawing in the Atari 400/800 Hardware Manual (p. VI.2) counts ANTIC cycles from 0 to 227.

 

I don't think that would be accurate. In first place most ANTIC logic is clocked by the "slow" PHI0 clock, not by the fast (color) clock. This includes the actual horizontal counter, which is 7 bits only. That means that ANTIC counts from 0 to 113. In second place I think that diagram, and actually as explicitely mentioned, is based on the PMs horizontal position register values, not exactly on cycles.

 

The PM horizontal registers do have an absolute meaning, but there is not an unique anambiguous relation between those register values and actual cycles. You know that anything at the left of horizontal position (not cycle) 34 won't be displayed. But you can't establish which exactly is the cycle number 34. There is a pipeline and several delays both at ANTIC and at GTIA.

 

One can see that the LUMx and CSYNC change states somewhere at PHI2+400ns.

 

I'm not sure this is relevant. Who cares (for this purpose of deciding absolute cycle numbers) about the delay of the final video output? Furthermore, and as you know, GTIA output is not even synchronized with PHI2. It is synchronized with the fast "OSC" input. And there is a huge shift between the fast color clock and PHI2.

[phaeron]

I always considered absolute cycle numbers to be completely meaningless. They are, in the best case, a conventional issue. Even relative numbers aren't always completely unambiguous. The only thing that matters is the relation, distance and displacement between two events.

 

The "NTSC and PAL Display" drawing in the Atari 400/800 Hardware Manual (p. VI.2) counts ANTIC cycles from 0 to 227.

 

I don't think that would be accurate. In first place most ANTIC logic is clocked by the "slow" PHI0 clock, not by the fast (color) clock. This includes the actual horizontal counter, which is 7 bits only. That means that ANTIC counts from 0 to 113. In second place I think that diagram, and actually as explicitely mentioned, is based on the PMs horizontal position register values, not exactly on cycles.

 

The PM horizontal registers do have an absolute meaning, but there is not an unique anambiguous relation between those register values and actual cycles. You know that anything at the left of horizontal position (not cycle) 34 won't be displayed. But you can't establish which exactly is the cycle number 34. There is a pipeline and several delays both at ANTIC and at GTIA.

 

That would be true, except that Atari also put the ending position for STA WSYNC on the chart as well, which would tie the values together. "END WSYN" is at HPOS=208 on the chart, and cycle 104 is the correct cycle for this if cycle 0 is the display list DMA. This also matches the "Horizontal Blank DMA Timing" diagram on page II.22 of the Hardware Manual, which shows ten cycles from WSYNC to the end of the line.

 

What isn't clear to me is whether the association between the display coordinates and the DMA/WSYNC cycles is correct in any way. It doesn't seem to match anything that is program visible, since pretty much everything I can think of happens earlier than the timing chart would indicate: VCOUNT increment, playfield DMA, and deadlines for changing CTIA/GTIA registers to hit a point on the screen. The closest I can think of is color register changes and those are off by half a clock in GTIA. I wonder if this was originally calibrated against a CTIA system?

[HiassofT]

I always considered absolute cycle numbers to be completely meaningless. They are, in the best case, a conventional issue. Even relative numbers aren't always completely unambiguous. The only thing that matters is the relation, distance and displacement between two events.

Sure, but sometimes those absolute cycles numbers are quite helpful so you don't have to add all relative cycles by yourself

 

For me, the most confusing part about this is that the docs use different numbering/reference schemes and often don't mention which scheme they actually employed. For example some datasheet talks about when a chip asserts it's interrupt line, but some other docs talks about when the CPU starts executing the interrupt - bummer, here you have the implicit 2-cylce delay. Or, as we have it here, setting the start of a scanline to either the missile- or display-list-DMA cycle (+/-1 cycle difference). Sometimes the docs also just contain unnoticed errors and typos (like the "famous" serial overrun bit in SKSTAT which every doc since the Atari 400/800 hardware manual and even the driver in the 850 ROM had wrong).

 

Putting all these (partially contradicting) information together is very confusing and frustrating, and this is also the main reason why I started distrusting all docs and investigating things by myself (using the logic anaylzer etc).

 

One can see that the LUMx and CSYNC change states somewhere at PHI2+400ns.

I'm not sure this is relevant. Who cares (for this purpose of deciding absolute cycle numbers) about the delay of the final video output? Furthermore, and as you know, GTIA output is not even synchronized with PHI2. It is synchronized with the fast "OSC" input. And there is a huge shift between the fast color clock and PHI2.

I was interested where the 1-cycle shift in the timing charts could have come from.

 

Without having a closer look at GTIA or ANTIC internals I'd just blame most of the ~400ns delay on GTIA and/or the communication between ANTIC and GTIA.

 

And if we do this, everything comes nicely together:

 

antic.pdf page 5 mentions that HSYNC is active (LOW) in color clocks 0-15. In the CPU cycle where CSYNC goes low ANTIC does it's first PM DMA.

 

And: most video timing docs set the start of a scanline to the point where HSYNC becomes active (LOW).

 

So, setting the reference CPU cycle "0" of each scanline to the cycle where ANTIC does it's first (missile) DMA and where CSYNC goes low just seems natural to me - and this is also how the older Altirra hardware reference manual had it.

 

Even if most of us are still used to the numbering from the old Antic_Timings.txt (or the current Altirra refman), I'd say it's better to forget about it and use the correct, more natural, numbering from now on.

 

That would be true, except that Atari also put the ending position for STA WSYNC on the chart as well, which would tie the values together. "END WSYN" is at HPOS=208 on the chart, and cycle 104 is the correct cycle for this if cycle 0 is the display list DMA. This also matches the "Horizontal Blank DMA Timing" diagram on page II.22 of the Hardware Manual, which shows ten cycles from WSYNC to the end of the line.

Since I'm not sure if the hardware manual is correct at all (it wouldn't be the first error in it), I think it's best when I hook up my logic analyzer again and check the RDY timing against CSYNC. While I'm at it, I guess I should also capture some traces with NMI and CSYNC in it, just to be sure.

 

@phaeron: anything else you'd be interested in?

 

so long,

 

Hias

[HiassofT]

OK, here are the first two captures.

 

First: "STA WSYNC" timing, followed by "LDA #0", "#LDA #1", ..., run with only PM DMA enabled (DMACTL=$1C):

 

If we number the cycles so that #0 is the one where missile DMA occurs and where CSYNC goes low the numbering in this capture is as follows:

97: STA WSYNC is executed, $D40A written

98: CPU fetches "LDA" opcode

99: ANTIC pulls RDY low, CPU is halted

105: ANTIC releases RDY, CPU fetches "$00" operand of "LDA #$00" instruction

...

114/0: ANTIC fetches missile data, CSYNC goes low (at ~60% of the cycle).

8: CSYNC goes high (at ~60% of the cycle)

 

Now the VBI timing:

 

0: CSYNC goes low, obviously no DMA

8: NMI goes low, CPU fetches "LDA" opcode

9: CPU fetches "$19" operand

10: NMI goes hi, CPU has finished the last instruction so the 7-cycle interrupt sequence begins

 

Obviously everything is shifted by exactly one cycle from the numbers in antic.pdf or the hardware manual...

 

BTW: I've also attached the raw VCD data (use gtkwave to view it) in case you are interested.

 

so long,

 

Hias

vcddata.zip

[phaeron]

Wow... this ties lots of things together nicely. If I understand it, what we've got is:

• The vertical counter increments at the start of horizontal blank.
  
• Special DMA starts at the beginning of horizontal sync.
  
• Special DMA ends and DLIs are triggered at the end of horizontal sync.
  

Missile DMA = 0 does seem more natural in this model. Plus, the RDY signal timing explains the observed behavior of STA WSYNC and INC WSYNC around refresh cycles.

 

I wish I had something that needed a trace, but I don't think I do. :-/ So far I've been able to verify just about everything I need in code. Probably what I'm missing the most is an accurate analog model of the audio path, which is hard to estimate.

 

(like the "famous" serial overrun bit in SKSTAT which every doc since the Atari 400/800 hardware manual and even the driver in the 850 ROM had wrong).

 

I'm interested in this and would like to know more. I had understood that the Hardware Manual description of bits 5 and 6 of SKSTAT were correct, i.e. they fire when POKEY tries to raise the corresponding IRQ when it is already active. The schematics seem to reflect this.

[HiassofT]

(like the "famous" serial overrun bit in SKSTAT which every doc since the Atari 400/800 hardware manual and even the driver in the 850 ROM had wrong).

 

I'm interested in this and would like to know more. I had understood that the Hardware Manual description of bits 5 and 6 of SKSTAT were correct, i.e. they fire when POKEY tries to raise the corresponding IRQ when it is already active. The schematics seem to reflect this.

The Hardware Manual had the definitions of bit 5 and 6 swapped (page III.18), saying D5 is keyboard and D6 serial overrun, although the comment on the right "D5 and D6 are set to zero when new data and same bit of IRQST is zero" indicates how it should be: bit 5/6 of SKSTAT correspond to bit 5/6 of IRQST.

 

The pokey.pdf (p.22) contains the correct definition, D5=serial overrun, D6=keyboard.

 

All other books etc. seem to just have copied the wrong decription from the hardware manual saying D6=serial overrun and D5=keyboard overrun.

 

The SIO code in the Atari (old and XL) OS ROMs use the correct bits (D7 checking for framing errors, D5 for overruns), but the 850 R: handler code in the 850 ROM checks D6 for serial overruns:

  0B2F  AD0FD2			  LDA	 SKSTAT
 0B32  8D0AD2			  STA	 SKRES		   ;FETCH AND RESET SYSTEM ERROR BYTE
 0B35  49FF				EOR	 #$FF
 0B37  29C0				AND	 #$C0			;INVERT AND MASK XMISSION ERROR BITS
 0B39  AEBD0D			  LDX	 ACTSTR
 0B3C  1D980D			  ORA	 RERROR-1,X
 0B3F  9D980D			  STA	 RERROR-1,X	  ;SET LOCAL ERROR BITS

And thus the description of the error bits in the Atari 850 technical manual on page 44 is also incorrect - the 850 handler will never report a real serial overrun, but wrongly indicate a serial overrun if a keyboard overrun occurred...

 

so long,

 

Hias

[HiassofT]

I took some more captures, this time including the ANx lines and the OSC input of GTIA.

 

For these tests I used ANTIC mode E, with a LMS on every scanline, plus PM DMA (DMACTL = $3E), so all 8 "special" cycles are used. I took the captures on the same PAL 800XL as before and, also as before, shifted the display of the HALT line by 400ns (so the halt-cycles line up with the actual "stolen" cycles), just for convenience. Also as before cycle "0" is the one with the missile DMA.

 

Here's the capture around CSYNC=low, the end of the previous scanline and the beginning of the new scanline:

 

110 + 230ns: ANTIC sets AN=010 (beginning of hblank)

110 + 390ns: OSC goes high, GTIA picks up AN

0-7: ANTIC fetches PM and DL data

0 + 370ns: CSYNC goes low (start HSYNC)

8 + 430ns: CSYNC goes high (end HSYNC)

16 + 240ns: AN changes from 010 (hblank) to 000 (background)

16 + 390ns: OSC goes high, GTIA picks up AN

 

So this is basically what was expected. 4 cycles front porch, 8 cycles HSYNC and 8 cycles back porch.

 

Now let's have a look at the first pixels in the scanline:

20: ANTIC reads first byte of screen memory

22: ANTIC reads second byte of screen memory

23 + 230ns: AN changes from 000 (background) to 100 (COLR0)

23 + 390ns: OSC goes high, GTIA reads AN

23 + 510ns: AN changes from 100 to 101 (COLR1)

24: ANTIC reads third byte of screen memory

24 + 110ns: OSC goes high, GTIA reads AN

25: ANTIC halts CPU for a refresh cycle

 

The timing is also consistent with the Altirra HW refman, but the Antic_Timing.txt has 13 unhalted cycles (instead of 12) between the last "special" DMA and the first playfield DMA cycle.

 

I also took a capture of VBLANK timing (I removed the address/data/clock lines from the picture, but they are included in the attached VCD data).

 

It's basically as one would expect the PAL timing to be: 27 HBLANKed lines, 3 VSYNC lines, another 42 HBLANKed lines. In the VCD files you can see the VBI executing at the beginning of the first HBLANKed line.

 

so long,

 

Hias

antic-e-vcd.zip

vblank-vcd.zip

Edited October 14, 2011 by HiassofT

[Rybags]

Hi Hias.

 

My memory is a bit fuzzy on this but could you test - Antic multicolour mode followed by hires mode, e.g. E then F.

 

The HBlank command should change from "normal" to "hires" after a short time once the next DList instruction implies that a 320 mode is in use after a normal mode.

[HiassofT]

My memory is a bit fuzzy on this but could you test - Antic multicolour mode followed by hires mode, e.g. E then F.

 

The HBlank command should change from "normal" to "hires" after a short time once the next DList instruction implies that a 320 mode is in use after a normal mode.

Your memory was correct :-)

cycle 1: ANTIC fetches $4F display list instruction

cycle 2 + 340ns: AN changes from 010 to 011

 

so long,

 

Hias

antic-e-f-vcd.zip