30 replies to this topic

[Robert M]

Okay, so the documentation says that there are 456 - 7.16 MHz clock cycles per scanline.  The worst case DMA startup is 9 cycles, and the worst case DMA shutdown is 13 cycles.   There are 7 - 6502 cycles per scanline which translates by my calculation to 28 DMA cycles lost per line. So I calculate:

456 - 9 - 13 - 28 = 406 guaranteed DMA cycles per scanline.  

Is that correct?

Thanks,

[Rybags]

That's just the pixel clock (half the master clock).

CPU clock is master /8, which is same as for the computer line, 114 cycles per scanline.

[GroovyBee]

Robert M, on Tue Jun 15, 2010 8:12 AM, said:

Is that correct?

Nope! There are 452 MARIA cycles per scan line.

DMA startup takes between 5 and 12 cycles - so assume 12 worst case.
DMA shutdown takes between 9 to 23 cycles - so assume 23 worst case.

=452-12-23 MARIA cycles.
=417 MARIA cycles.

[Rybags]

What speed can Maria access RAM though?  Is it at 3.6 Mhz effective, or is it the same as the CPU?

[GroovyBee]

Rybags, on Tue Jun 15, 2010 9:24 AM, said:

What speed can Maria access RAM though?  Is it at 3.6 Mhz effective, or is it the same as the CPU?

MARIA can access the RAM every 2 of its 7.16MHz cycles. To access ROM it takes 3.

[Robert M]

GroovyBee, on Tue Jun 15, 2010 9:12 AM, said:

Robert M, on Tue Jun 15, 2010 8:12 AM, said:

Is that correct?

Nope! There are 452 MARIA cycles per scan line.

DMA startup takes between 5 and 12 cycles - so assume 12 worst case.
DMA shutdown takes between 9 to 23 cycles - so assume 23 worst case.

=452-12-23 MARIA cycles.
=417 MARIA cycles.

None of your numbers match mine.  So I am wondering where your information came from?  Where is the missing manual!

Cheers!

[GroovyBee]

Robert M, on Tue Jun 15, 2010 11:35 AM, said:

None of your numbers match mine.  So I am wondering where your information came from?  Where is the missing manual!

The Atari manual has mistakes and MARIA DMA cycles is just one of them. For the best reference you need the MARIA manual from GCC.

[Robert M]

GroovyBee, on Tue Jun 15, 2010 12:14 PM, said:

Robert M, on Tue Jun 15, 2010 11:35 AM, said:

None of your numbers match mine.  So I am wondering where your information came from?  Where is the missing manual!

The Atari manual has mistakes and MARIA DMA cycles is just one of them. For the best reference you need the MARIA manual from GCC.

Ah, very good.  Thanks for the info.   Its nice to have a few extra DMA cycles.  Every pixel helps!

Cheers

[gdement]

I had a more pessimistic calculation in my notes.  I still think this looks correct according to the Maria spec, but I'd love to be wrong:

Maria Acceptance Specs pg18 said:

End-Of-VBlank DMA is initiated on the trailing edge of VBlank.
Regular DMA is initiated on the leading edge of HBlank.
DMA will be aborted (to shutdown) on the leading edge of Border.
(See screen definition for counter values associated with these times.)

pg23 (Maria II Screen Layout) said:

(diagram shows 452 "HCount" per scanline.
leading edge of HBLANK is at 34.
leading edge of right Border is at 413.)

pg17 said:

DMA Startup    5-12 cycles

So DMA startup occurs at cycle 34, and consumes up to 12 cycles, giving a worst case start time of cycle 46.
DMA is aborted to begin shutdown at cycle 413.
413-46= 367 usable cycles.

I haven't experimented with it though.

[GroovyBee]

gdement, on Wed Jun 16, 2010 10:02 PM, said:

I had a more pessimistic calculation in my notes.  I still think this looks correct according to the Maria spec, but I'd love to be wrong:

I don't think you are correct. Using your figures it wouldn't be possible for MARIA to handle a full screen width of 160B indirect in 2 char width mode and a sprite on top (which I know is possible).

e.g. For the background alone using 2 of the 5 byte headers.

=(2x10)+(40x(3+(2x3)) MARIA cycles.
=380 MARIA cycles.

[gdement]

That's good to hear.. but now I wonder if the spec is wrong or if I misunderstood something in it.

[EricBall]

I wonder whether the GCC document timings were for the original prototype and the Atari document reflects optimizations made to later revisions.  In nearly all cases the Atari timings are less than the GCC times (ignoring the Indirect/Character Map confusion).  The only exception is the 5 byte header which is either 10 or 12 cycles.

Now if I were to design it to maximize the DMA time per line while providing the 7 post-HSYNC CPU cycles:
HSYNC start, CPU enabled, wait 7 CPU cycles (28 MARIA cycles), wait for CPU to finish bus access to start DMA (5-9 MARIA cycles), fetch headers (2 cycles per byte), fetch character map (3 cycles), fetch graphics (3 cycles per byte).  Continue until last possible cycle given worst case shutdown (13 cycles).  If DMA finishes early, enable the CPU.

It might be possible to get more info by scoping the HALT pin.

[doppel]

I'm not exactly sure where GCC got the 452 cycles figure for their specs, but yeah, that seems a little less than there should be, if the MARIA is clocked at 7.16 Mhz (3.58 Mhz * 2), and there are 228 3.58 Mhz clocks per scanline.

[SeaGtGruff]

GroovyBee, on Tue Jun 15, 2010 9:12 AM, said:

Robert M, on Tue Jun 15, 2010 8:12 AM, said:

Is that correct?

Nope! There are 452 MARIA cycles per scan line.

The picture of the screen display shows 0 at the left (beginning of HSYNC) and 452 at the right (end of horizontal front porch HBLANK), but the document also says "SYNC counters define the screen layout as 454 cycles of the internal 7MHz clock per scanline" (page 8 of "General Computer MARIA TECHNOLOGY," General Computer, October, 1984). But then it says "the horizontal and vertical counts delineating border, BLANK and SYNC are shown in Figure 6 on page 13"-- which is the picture that shows from 0 to 452. It seems like one of those must be a typo, or maybe both.

I can see how they might say there are 453 cycles, then give a picture showing the cycles ranging from 0 to 452 (just like the 76 CPU cycles on the TIA are labeled from 0 to 75, with "cycle 76" becoming "cycle 0" of the next line). But following that same logic/labeling, if there are 454 cycles, then they should range from 0 to 453.

And if there are 228 color clocks (which isn't stated anywhere that I can see), there should be 456 cycles. If there are 454 cycles (as stated on page 8 ), that would be 227 color clocks. Since there are 227.5 color clocks in the NTSC signal, they might have gone down to 227, instead of up to 228-- a slightly shorter line, instead of a slightly longer line than the NTSC standard. And they say the crystal is 14.318080 MHz, whereas the actual NTSC color cycle rate times 4 should be 14.318181 repeating 81 MHz. If correct, that would mean the Maria color clock is slightly slower/wider than a standard NTSC color clock.

Michael

Edited by SeaGtGruff, Tue Jul 27, 2010 11:17 PM.

[nichtsnutz]

Hello all,

I had posted some timing diagrams in the other thread "PAL frame timing" and I can say from what I have measured that the PAL-MARIA makes 454 Clocks per line.With a sampling rate of 200MHz I get exactly 64us (+/- 5ns) accuracy and that is (14.1875 / 2) * 64us = 454 Clocks per line.This is 227 PAL color clocks or 113.5 CPU Clocks per line.The PAL FRAME is 313 lines.

I have no NTSC VC7800 but I think that they have taken the same horizontal timing for both standards to reduce the hardware cost.The nominal line length of NTSC is 63.55us * 7.16MHz = 455 Clocks,this is one more than in PAL,so I think they just took also 454 Clocks per line for NTSC to have the same DMA hardware for both systems.They had only to change the vertical counter that is perhaps easier than changing the whole DMA logic for 1 clock more per line !!! So the NTSC line length drops to 454 / 7.16 = 63,4us that should be tolerable from the analog TV of that time.

Greetings,
Vassilis

[Rybags]

Sounds reasonable.  But, wouldn't the CPU be offset by half a cycle each scanline?  I guess it probably isn't apparent unless you do stuff like colour register changes on the fly mid-scanline and I'd guess practically no 7800 games would do that.

The 263/313 scanlines is also kinda odd... although supposedly the ST is the same, and it'd make sense that the 7800 would do that if the scanlines themselves are slightly shorter than the 228 colour-clocks that the 8-bit computers use.

[nichtsnutz]

Hello Rybags,

yes,I think that the CPU is offset by half cycle on each line.I had also recorded the CPU clock that gets out of MARIA and I could see that every time I had triggered,it was shifted with respect to the csync.I could not get a stable timing between the cpu clock edge and the csync edge,but I have to look at this again.
Vertical blank is on PAL 21 lines that leaves 313-21=292 lines for the image.I think using 192 lines is the standard on the 7800.

Unfortunately the small logic analyzer that I own is not able to record a whole video line with all the maria signals,so I am trying to build an external trigger logic based on decoding the maria csync and counting lines.If I succeed with this I could also trigger the position of the DMA transfers.This could be interesting for emulator writers getting the cycle counts exact.But doing this is not so easy as it sounds...

Greetings,
Vassilis

[Rybags]

I found (with the computers) that analysing the video signal with my oscilloscope was made a whole lot easier with software triggered sweeps - I just used a 1->0 transition on a joystick port output bit as a trigger.

If you have the means to be able to do that with the 7800, then you'd make it a much easier job.

[nichtsnutz]

Hello Rybags,

thank you for the tip! Unfortunately I do not own an EPROM Emulator hardware nor a dev kit for the 7800,so I can not write my own assembler code right now.But I am working on it...

Greetings,
Vassilis

[Rybags]

Another poss... find a cartridge that you know only uses a VBlank Interrupt.  Use that as the trigger then just monitor the CSync pulses.

[doppel]

Okay, I see what I did wrong.  When I looked at the 7800 MARIA specs doc (posted a link to it in a thread about PAL frame timing) I mistakenly took the 68 cycles between the beginning of HSYNC and the end of HBLANK to mean 68 color clocks, when in fact the chart was measuring MARIA clocks.

This should hopefully clear everything up.

The 7800 Maria Specs, specifically, the NTSC and PAL screen layouts chart on page 13, states that there are 68 MARIA clocks (NOT color clocks!) of HBLANK during which 34 of those are in HSYNC.  The screen border starts displaying at the end of that, after the 93rd MARIA clock the defined screen proper begins (where our 160/320 pixels lie).  The display area ends at MARIA clock number 413 which gives us 320 MARIA clocks (or 160 color clocks).  Now, between that and the end of the frame we have 39 more MARIA clocks, 27 of which are border, 12 of which are either HBLANK or simply horizontal overscan.  Atari's MARIA document (which states 228 color clocks per scanline) doesn't clarify where in the blanking area HSYNC even begins, so we're led to believe it starts immediately after the last visible color clock.

Now, 93 + 39 = 132 border/offscreen MARIA clocks.  132 * 2 = 66 color clocks.  Couple that with 320 pixels * 2 and that gives us 160 color clocks, giving us 226 total color clocks, which corresponds to 452 MARIA clocks more precisely.  227 isn't too far off, which would correspond precisely to 454, or roughly to 452, give or take an extra clock somewhere.

Edited by doppel, Wed Jul 28, 2010 2:41 PM.

[nichtsnutz]

Hello doppel,

Quote

This should hopefully clear everything up.

This confuses me a bit more  

The MARIA screen layout shown on page.13 has one mistake.The number of clocks per line should be 454 and not 452.All other horizontal timings are the same with the ones I have measured.(At least for PAL.)

I also do not understand what you mean with "color clock".For me one PAL color clock is one cycle of the 4.4336...MHz clock on MARIA_PIN_3 that is used for the PAL color burst.This is only used for the color coding of the chroma signal that is output on the COLOR pin.It is not used for anything else.

The CPU can be clocked with two different frequencies either 14.1875/8=1.773MHz or 14.1875/12=1.182MHz so there is no fixed number of CPU cycles per scanline.

MARIA is clocked by 14.1875MHz and this is internally divided by two to get 7.09MHz.The 7.09MHz (140,9ns) clock is used internally for all the raster timing.
I have attached the measurment.Line length from A-E = 64us.

Quote

Now, 93 + 39 = 132 border/offscreen MARIA clocks. 132 * 2 = 66 color clocks. Couple that with 320 pixels * 2 and that gives us 160 color clocks, giving us 226 total color clocks, which corresponds to 452 MARIA clocks more precisely. 227 isn't too far off, which would correspond precisely to 454, or roughly to 452, give or take an extra clock somewhere.

What should this 226-227 color clocks mean? This is not a PAL Atari XL with 3.54MHz fixed clocking where the CPU clock is the half of it and fixed!

Greetings,
Vassilis

Attached Thumbnails

• 

[doppel]

Hmmmm...well things seem to be slightly different on the PAL 7800.  When I referred to "color clocks" I was referring to the 3.58 Mhz clock used both for the NTSC chroma sub-carrier and the TIA timing.  I'm not at all clear on how the external PAL chroma clock affects the output versus NTSC.

I never actually said the CPU clock was fixed, in fact I don't recall mentioning the CPU clock cycles at all.  But the figure of 114 (or is 113 or 113.5 now, these damn figures keep changing) should apply to the maximum speed of 1.79 MHz, naturally going down for any cycles spent accessing slow RAM or the TIA.

It was you as I recall that mentioned there being 227 PAL color clocks per scanline (which, as I stated in the previous post, corresponds precisely to 454 MARIA clocks).  How the external PAL clock of 4.43 MHz affects things, again, I have no clue, since I don't have any PAL hardware or any way of measuring any of this stuff.

And as far as to why the hardware in a PAL 7800 would be clocked different from an NTSC 7800, I also have no idea.  I'm gonna go ahead and stop right here, since I'm obviously not a hardware person...

<throws his hands up in frustration and walks away>

Edited by doppel, Thu Jul 29, 2010 11:42 AM.

[nichtsnutz]

Hello doppel,

doppel, on Thu Jul 29, 2010 11:42 AM, said:

Hmmmm...well things seem to be slightly different on the PAL 7800.  When I referred to "color clocks" I was referring to the 3.58 Mhz clock used both for the NTSC chroma sub-carrier and the TIA timing.  I'm not at all clear on how the external PAL chroma clock affects the output versus NTSC.

Ok,I understand now,I have to say that I do not know for sure what a "color clock" is.I'm sorry my false! On the atari XL I think the GTIA clock is the color clock!?

Quote

I never actually said the CPU clock was fixed, in fact I don't recall mentioning the CPU clock cycles at all.  But the figure of 114 (or is 113 or 113.5 now, these damn figures keep changing) should apply to the maximum speed of 1.79 MHz, naturally going down for any cycles spent accessing slow RAM or the TIA.

I think the same,with the CPU speed changing there will be always a different number of cycles.

Quote

It was you as I recall that mentioned there being 227 PAL color clocks per scanline (which, as I stated in the previous post, corresponds precisely to 454 MARIA clocks).  How the external PAL clock of 4.43 MHz affects things, again, I have no clue, since I don't have any PAL hardware or any way of measuring any of this stuff.

I am sorry for that,I have used the term without knowing what it really means and I have just used it because others also use it   .On the PAL MARIA the PIN_3 has a different function from the NTSC MARIA because PAL needs this 4.433 "color clock"! This is only needed for the color coding and I think is not used for something else.

Quote

And as far as to why the hardware in a PAL 7800 would be clocked different from an NTSC 7800, I also have no idea.  I'm gonna go ahead and stop right here, since I'm obviously not a hardware person...

I only have a PAL machine and maybe they have done things different with NTSC.I have also no definitive answer!

I have measured many other things like the DLL fetch transfers,DMA Startup/Shutdown,and I must say that the more I measure the more I am confused.It is really not easy stuff,the ones who design such things are real experts.I will take a rest for some days,maybe one day things will clean up...

Quote

<throws his hands up in frustration and walks away>

I am sorry I have not wanted that,I respect your opinion! My measurements were for PAL and yours for NTSC! Also my englisch is "machine" like and reads "hard" because I am no native speaker! But I do not want to blame anyone.I am sorry if it feels so.



Greetings,
Vassilis

[doppel]

nichtsnutz, on Thu Jul 29, 2010 12:46 PM, said:

Ok,I understand now,I have to say that I do not know for sure what a "color clock" is.I'm sorry my false! On the atari XL I think the GTIA clock is the color clock!?

Yeah, the GTIA pretty much gets the last word as far as video on the 8-bit computers and the 5200 are concerned.

Quote

I am sorry for that,I have used the term without knowing what it really means and I have just used it because others also use it   .On the PAL MARIA the PIN_3 has a different function from the NTSC MARIA because PAL needs this 4.433 "color clock"! This is only needed for the color coding and I think is not used for something else.

The two documents from GCC appear to be in conflict over what pins 3 and 4 do.  In the 7800 Maria Specs document pin 3 is mentioned as being 14.3180 MHz clock output on the NTSC version (GCC1702) and the 4.43 MHz PAL chroma sub-carrier input on the PAL version (GCC1712), whereas pin 4 is mentioned as being the 14.3180 MHz input.

The Maria "Acceptance Specification" document, on the other hand, mentions pin 3 clock input rather than output (which is listed under pin 4), and nothing at all is mentioned about the PAL version.

Quote

I only have a PAL machine and maybe they have done things different with NTSC.I have also no definitive answer!

I have measured many other things like the DLL fetch transfers,DMA Startup/Shutdown,and I must say that the more I measure the more I am confused.It is really not easy stuff,the ones who design such things are real experts.I will take a rest for some days,maybe one day things will clean up...

I'm not so concerned about the exact number of MARIA cycles DMA uses for things like DMA startup and shutdown, since there's really no way to avoid timing uncertainty that doesn't involve assuming the worst case.  On the plus side your measurement of 64 microsecs is precisely the same measure specified as the upper limit of DMA in one of the GCC documents.

Quote

I am sorry I have not wanted that,I respect your opinion! My measurements were for PAL and yours for NTSC! Also my englisch is "machine" like and reads "hard" because I am no native speaker! But I do not want to blame anyone.I am sorry if it feels so.



Greetings,
Vassilis

Naw, it's all right.  This thread was originally about available DMA clock cycles, and I think we both sorta led it off track, though the count of MARIA cycles per scanline does affect DMA.