SIO protocol

[atariksi]

I transmit at about 52 us and receive at 52 us per bit. That's the simple way to look at it. If you think that means one is 9600Hz and the other is 19200Hz, that's your interpretation or misunderstanding (not the rest of the world's). For me, even if I used both transitions of the clock (9600Hz), I can phase shift receiver by 26us and receive the samples at 9600Hz.

I think there is a misinterpretation of "Hertz" on your side. Hz doesn't mean "full sinus wave" or something, it simply means "per second". So if you sample a bit every 52 µs, then you are sampling 19200 times per second which means: 19200 Hz.

 

You can get 19200 bps using 9600Hz clock. You can also get 19200 bps using 19200Hz clock. Regardless, it's the same for both sides. If you define it as "per second" of anything, then bps = Hz.

[roland p]

You can get 19200 bps using 9600Hz clock.

Can you illustrate this in a picture?

[atariksi]

You can get 19200 bps using 9600Hz clock.

Can you illustrate this in a picture?

 

Last time I tried posting a diagram, all the spacing got screwed. But it's easy to see for digital signals that you can send one bit when clock is high and one bit when clock is low. I suppose if you knew EXACTLY how the waveform behaves, you could take advantage of the analogicity of the clock wave and send a bit on various phases of the wave and get 19200 bps using one Hertz clock!

[Fröhn]

I think there is a misinterpretation of "Hertz" on your side. Hz doesn't mean "full sinus wave" or something, it simply means "per second". So if you sample a bit every 52 µs, then you are sampling 19200 times per second which means: 19200 Hz.

You can get 19200 bps using 9600Hz clock. You can also get 19200 bps using 19200Hz clock. Regardless, it's the same for both sides. If you define it as "per second" of anything, then bps = Hz.

If you sample at the rising and the falling edge, you still get 19200 Hz sample rate even if the clock has a 9600 Hz frequency.

[Bryan]

You can get 19200 bps using 9600Hz clock.

Can you illustrate this in a picture?

 

Last time I tried posting a diagram, all the spacing got screwed. But it's easy to see for digital signals that you can send one bit when clock is high and one bit when clock is low. I suppose if you knew EXACTLY how the waveform behaves, you could take advantage of the analogicity of the clock wave and send a bit on various phases of the wave and get 19200 bps using one Hertz clock!

 

Just learn a litte bit of bbcode. [quote] and [/quote] around blocks of quoted text (instead of >) and [code] and [/code] around stuff you want to be monospaced.

 

You're right. You can invent all kinds of crazy ways to send data but for the purposes of communicating with the A8, it only makes sense to talk about simple clocking.

[atariksi]

You can get 19200 bps using 9600Hz clock.

Can you illustrate this in a picture?

 

Last time I tried posting a diagram, all the spacing got screwed. But it's easy to see for digital signals that you can send one bit when clock is high and one bit when clock is low. I suppose if you knew EXACTLY how the waveform behaves, you could take advantage of the analogicity of the clock wave and send a bit on various phases of the wave and get 19200 bps using one Hertz clock!

 

Just learn a litte bit of bbcode. [quote] and [/quote] around blocks of quoted text (instead of >) and [code] and [/code] around stuff you want to be monospaced.

 

You're right. You can invent all kinds of crazy ways to send data but for the purposes of communicating with the A8, it only makes sense to talk about simple clocking.

 

________________________
________________________
_OOOOO__kkk_____________
OO___OO__kk_____________
OO___OO__kk_____________
OO___OO__kk__kk_________
OO___OO__kk__kk_________
OO___OO__kk_kk__________
OO___OO__kkkk___________
OO___OO__kk_kk______,,__
OO___OO__kk__kk_____,,__
_OOOOO__kkk__kk_____,,__
___________________,,___
________________________
________________________
________________________
________________________________________________
________________________________________________
BBBBBB__________________________________________
_BB__BB_________________________________________
_BB__BB_________________________________________
_BB__BB_rr_rrr__yy___yy__aaaa___nn_nnn__________
_BBBBB___rr__rr_yy___yy_____aa___nn__nn_________
_BB__BB__rr_____yy___yy__aaaaa___nn__nn_________
_BB__BB__rr_____yy___yy_aa__aa___nn__nn_________
_BB__BB__rr_____yy__yyy_aa__aa___nn__nn_________
_BB__BB__rr______yyy_yy_aa_aaa___nn__nn____..___
BBBBBB__rrrr_________yy__aaa_aa__nn__nn____..___
________________yy___yy_________________________
_________________yyyyy__________________________
________________________________________________
________________________________________________
________________________
________________________
KK___KK__SSSSS____IIII__
KK___KK_SS___SS____II___
KK__KK__SS_________II___
KK_KK___SS_________II___
KKKK_____SSS_______II___
KKKK_______SSS_____II___
KK_KK________SS____II___
KK__KK_______SS____II___
KK___KK_SS___SS____II___
KK___KK__SSSSS____IIII__
________________________
________________________
________________________
________________________

 

I am testing out the "code" and "/code"...

[atariksi]

I think there is a misinterpretation of "Hertz" on your side. Hz doesn't mean "full sinus wave" or something, it simply means "per second". So if you sample a bit every 52 µs, then you are sampling 19200 times per second which means: 19200 Hz.

You can get 19200 bps using 9600Hz clock. You can also get 19200 bps using 19200Hz clock. Regardless, it's the same for both sides. If you define it as "per second" of anything, then bps = Hz.

If you sample at the rising and the falling edge, you still get 19200 Hz sample rate even if the clock has a 9600 Hz frequency.

 

Yeah, I would state that as well but some people want to interrelate the data rate with the clock. I won't mention names but he's doing 110kbits/second testing (I guess that means 55kbits/second testing for him which becomes 110kbits/second when it goes from one point to another).

 

So your stating that the color carrier at 3.579545Mhz can only display colors at 160*200 then on the C64 not 320*200 in color.

[Wildstar]

In early 1980s I/O, you could not send more bits than the number of clock cycles you have. The only way you can send more "bits" than the clock was through modulation/demodulation which in its own right would have another clock involved in many implementation. It would be analog which is not a binary state logic.

 

Digital logic is only one of two values per clocl cycle. There is no double or quadruple data pumping. There wasn't multiport memory. Part of reason things worked a certain way is because of RAM. You have to send every bit to memory before you can retrieve the next bit. No double port memory. There were systematic limits to the system architecture. You can dump data as fast as your hearts content from a PC, the Atari isn't going to keep up because the Atari has a system architecture that is its own bottleneck and there is overhead. Theoretical limit for POKEY with absolute zero overhead would be half of 1.79 MHz assuming you can send a byte every two clock cycles. But you are looking at less than that. Lets assume 1/4th of 1.79 MHz. But you would be essentially running a largely dumb synchronous protocol that is so simple and basically trying to attempt a serial DMA stream. Your likely only going to get CLK/8 or 1.79MHz / 8 with a custom protocol that is so dumb simple with a signal on the control line from streaming device to indicated END OF TRANSMISSION from that direction. These protocols were usually half-duplex. If you can work a strategy for full duplex, you will want to make things into stream blocks like a packet large enough that the switching direction is small. Full duplex can be

 

Yeah, I would state that as well but some people want to interrelate the data rate with the clock. I won't mention names but he's doing 110kbits/second testing (I guess that means 55kbits/second testing for him which becomes 110kbits/second when it goes from one point to another).

So your stating that the color carrier at 3.579545Mhz can only display colors at 160*200 then on the C64 not 320*200 in color.

 

The C64 has nothing to do with this but C64 had limitations on the number of colors it can generate. It wasn't 320x200 color changes. It had color attributes limitations per character cell/tile.

[thorfdbg]

The C64 has nothing to do with this but C64 had limitations on the number of colors it can generate. It wasn't 320x200 color changes. It had color attributes limitations per character cell/tile.

 

This has no relation to the original topic, namely SIO, but anyhow: The question here is not how many colors per element the C64 or Atari can possibly generate. This is just a question of the design of the graphic engine and its DMA limitations. The C64 had an additional side-memory (the color-RAM) from which the VIC could pull data, in addition to character/graphics data. The Atari had nothing like that (it's an older design anyhow).

 

However, the question is rather on bandwidth limitation of color TV per se. NTSC and PAL use horizontal subsampling, i.e. the bandwidth for the chroma signal in horizontal direction is only half of the luma resolution. For PAL, vertical resolution of the chroma signal is reduced by another factor of two. These are limitations you cannot circumvent by clever chip design, or DMA design. It is just how the TV signal works. From that follows that you have really only a chroma resolution of 160 cells per line (without overhead). While the C64 "attempts" to create color of 320 pixels per line, you will also notice that the luminance signal will interfere with the color carrier and create artifacts. Thus, you surely don't get the color you attempted to get if you create a color with a resolution of 320 pixels per line. You have to have larger areas of constant chroma to make the chroma visible. The C64 cannot do magic either and bypass the limits of the TV norm.

[Wildstar]

Hold on for a second.

 

Firstly, the VIC-II has only one "RAM" and it is a 16K RAM area. The Atari uses a two chip system for generating image... being ANTIC and GTIA/CTIA. The VIC-II is a single chip system... one part for handling the bitmap data (on/off of pixels) and color ram is for an additional color value per character cell. It is because the VIC-II sub-divides the video ram space (16K viewing window of main RAM) into screen ram which would contain the bitmap data for character cells and therefore two colors. A character cell foreground and background color. Then there is the screen ram which requires two pixel clocks to generate whatever color on that... effectively reducing horizntal resolution in half.

 

The VIC-II is a continuation of the architecture of VIC from the VIC-20. It is somewhat akin to the TMS9918 but that 6502 and the VIC-II share the same RAM.

 

The Atari graphics is a more complex graphics chip. It is more sophisticated than the VIC-II in an overall sense. The C64's VIC-II is a single chip video chip which is possibly more advance than either the ANTIC or GTIA (in some ways) but not the combination of ANTIC and GTIA and the VIC-II does not equal the sum of ANTIC and GTIA because there is certain attributes in the Atari video chips that is not found in the VIC-II chip.

 

They are not equal. It would be comparing apples & oranges. Atari has an actual "video processor" ie. it has an instruction set. While the VIC-II is a "video controller" which happens to not be a "processor". Hence the Atari has the ability to have "gpu instructions" creating something called "display list". The VIC-II is just a register based state machine so to speak.

 

I argue they are different.

 

The Atari isn't necessarily a less capable system because it is older while the VIC-II although newer is adapting an older display technology called the VIC (6560) -

 

http://en.m.wikipedia.org/wiki/MOS_Technology_VIC

 

Which original designs goes back to 1977 but subsequently revised prior to mass production with the VIC-20 in mind.

 

While CTIA alone predates VIC (6560) by a short bit. ANTIC was designed in 1977-78 and the combined attributes and ultimately the GTIA featured in the 400/800 models except the relatively few early units, is a later design and also was targeted to be a more advance end application of graphics than what VIC (6560) which was originally designed to be a low cost color display technology and the idea of video games was more an afterthought during design revision in the finalized production version used in the VIC-20.

 

It wasn't really any more advanced than the CTIA alone in a sense other than they integrated sound but at the cost of not having hardware sprites that the Atari systems had. It wasn't until Commodore developed the VIC-II for Commodore 64 and seperated the sound from the video controller and hence the SID chip was born that Commodore had a comparable graphics system to the Atari 400/800 systems and even the 2600.

 

From a gaming features perspective, Commodore was way behind Atari in its graphics architecture because Commodore was transitioning from a business machines market to a home computer market with video games being among the main 'apps' but Atari from day 1 was about video games and their chips were designed explicitly for that target end use even with their computers.

 

Lets remember that NTSC video resolution on the vertical is up in the 525 scanline range. While the horizontal pixel resolution is a timing and B&W resolution can be up to close to 720 pixels with certain video controllers.

 

As for how many pixels samples that can be generated within a scan line were limited in those days. Color pixels usually require longer sampling time than monochrome (B&W) pixels. Video chips were limited somewhat in those days in their ability to process color sampling.

[Wildstar]

In the case of the C64, a cell or tile or historically on the Commodore called 'cards' were 8x8 hires pixels or 4x8 (multicolor bitmap mode) pixels.

[thorfdbg]

Again, you are confusing two things: The bandwidth of the video signal that leaves the circuit, which is limited by the TV norm, and the bandwidth of the RAM bus required to feed data into the display processor. 320 pixel luma resolution means 160 pixel chroma resolution for a NTSC color signal, no way around that. The same limit applies to VIC as it does to ANTIC concerning the generation of a color signal with pixel resolution - you cannot do that with NTSC, the color is subsampled in horizontal direction (and in vertical, too, for PAL).

 

Second, no, the VIC *does* have *two* RAMs, not one. Please improve your research. It has a 16KB RAM area for video data, and *in addition* a four bit color RAM that is read by additional pins (DB8-DB11) *in parallel* to the video data. Thus, the bandwdith of the video bus is increased from 8 bits to 12 bits. Hence, you can select additional colors per character, something ANTIC could not do. It has a linear video RAM model, unlike VIC, which has two RAM segments: Video data, and color RAM.

[Eyvind Bernhardsen]

Not to be a curmudgeon or anything, but while I'm interested in SIO timings (don't ask), I don't care at all about the relative video timings of Commodore 64s and Ataris. Any chance you two could create a new thread for the video bandwidth discussion?