Atari v Commodore

[atariksi]

unfortunatly we can not ask Jay Miner....

 

I think that divide by 10 of the CIA frequency is a Commodore doing not Jay Miner's.

[Heaven/TQA]

unfortunatly we can not ask Jay Miner....

 

I think that divide by 10 of the CIA frequency is a Commodore doing not Jay Miner's.

 

 

I ment why the Atari chipset was designed like it was...

[Crazyace]

unfortunatly we can not ask Jay Miner....

 

I think that divide by 10 of the CIA frequency is a Commodore doing not Jay Miner's.

 

 

I ment why the Atari chipset was designed like it was...

 

Actually I think most of the Atari chipset makes sense. It improved the 2600 capabilities, and then added the 40 column mode for computer use

[atariksi]

unfortunatly we can not ask Jay Miner....

 

I think that divide by 10 of the CIA frequency is a Commodore doing not Jay Miner's.

 

 

I ment why the Atari chipset was designed like it was...

 

Actually I think most of the Atari chipset makes sense. It improved the 2600 capabilities, and then added the 40 column mode for computer use

 

It looks like they did a lot more work on GTIA than ANTIC (ANTIQUE); things look incomplete on the ANTIC. PMBASE pointer is 6-bits but could have been 16-bits as 54278 is unused.

[Crazyace]

6 bits is all that is needed to provide the 1k page resolution. I sometimes think that the 4 missiles were meant to be fetched from seperate locations ( thus filling the 1k/2k memory block ) - but the combination did save 384/768 bytes.

[atariksi]

6 bits is all that is needed to provide the 1k page resolution. I sometimes think that the 4 missiles were meant to be fetched from seperate locations ( thus filling the 1k/2k memory block ) - but the combination did save 384/768 bytes.

 

But you see you easily get a lot more flexibility if PMBase allows for the LSB bits just like DList Ptr uses 16-bits. They could have used only upper 6-bits on Dlist ptr as well. With PMBase at 16-bits, you can VSCroll, the entire full screen sprite overlay (or a big multicolor sprite).

It seems Jay Miner was just organizing things but didn't spend much time with GTIA; ANTIC certainly could have helped GTIA produce better results.

 

Oh, I just remembered Amiga Corp. was before Commodore so they must have done that divide by 10 of CPU Freq. to get the CIA freq and prevent sync. IRQ with the video beam.

[Rybags]

The DList system is kinda flawed - they could have had an addressable mode register for changing graphic modes on the fly.

 

Then instead of DLists, have Copper Lists like on Amiga, with instructions like store to register, create Interrupt etc.

 

Something like that would cater for automated colour changes, repositioning of PMGs etc.

[Crazyace]

But you see you easily get a lot more flexibility if PMBase allows for the LSB bits just like DList Ptr uses 16-bits. They could have used only upper 6-bits on Dlist ptr as well. With PMBase at 16-bits, you can VSCroll, the entire full screen sprite overlay (or a big multicolor sprite).

It seems Jay Miner was just organizing things but didn't spend much time with GTIA; ANTIC certainly could have helped GTIA produce better results.

Oh, I just remembered Amiga Corp. was before Commodore so they must have done that divide by 10 of CPU Freq. to get the CIA freq and prevent sync. IRQ with the video beam.

 

I dont think that flexibility would have been worth it - You would have needed 4 16 bit adders , with logic to reset them at vblank. That's a lot more gates on Antic - for something that wouldn't improve the machine. ( It's not beyond the 6502 to scroll players )

 

 

About Copper - It's just an evolution of dlists anyway - and I'm not sure that there were enough cycles to support general data movement.

Maybe a subset of loads.. changed the DLI bit, so it's a 2byte command. And then have seperate enable bits to load subgroups?

However it would again add a lot of complexity to Antic

[atariksi]

The DList system is kinda flawed - they could have had an addressable mode register for changing graphic modes on the fly.

 

Then instead of DLists, have Copper Lists like on Amiga, with instructions like store to register, create Interrupt etc.

 

Something like that would cater for automated colour changes, repositioning of PMGs etc.

 

To make it simpler, just DMA DList byte into a "GRAFn" type register before being used so you can still use DLists to reduce/enlarge/mix graphics modes w/o any DLIs yet allow for on-the-fly changes.

[atariksi]

But you see you easily get a lot more flexibility if PMBase allows for the LSB bits just like DList Ptr uses 16-bits. They could have used only upper 6-bits on Dlist ptr as well. With PMBase at 16-bits, you can VSCroll, the entire full screen sprite overlay (or a big multicolor sprite).

It seems Jay Miner was just organizing things but didn't spend much time with GTIA; ANTIC certainly could have helped GTIA produce better results.

Oh, I just remembered Amiga Corp. was before Commodore so they must have done that divide by 10 of CPU Freq. to get the CIA freq and prevent sync. IRQ with the video beam.

 

I dont think that flexibility would have been worth it - You would have needed 4 16 bit adders , with logic to reset them at vblank. That's a lot more gates on Antic - for something that wouldn't improve the machine. ( It's not beyond the 6502 to scroll players )

 

 

About Copper - It's just an evolution of dlists anyway - and I'm not sure that there were enough cycles to support general data movement.

Maybe a subset of loads.. changed the DLI bit, so it's a 2byte command. And then have seperate enable bits to load subgroups?

However it would again add a lot of complexity to Antic

 

If the chip is fully packed already (which I doubt), you can decrease # of bits in DList ptr like making it a requirement to align to page boundaries and have 8-bits of LSB of PMBase. You don't need the adders as the 8-bit offset is the same for all players. But you get the software capability to set the offset within the 256 bytes of player data where data fetch occurs. And to support Y-axis motion of each player independently, you would need some additional circuit to switch between the 5 players' 8-bit offset (no adders though). And these offsets are packable into the same address space that ANTIC currently uses by using unused registers and by writing to read-only registers.

[Crazyace]

Still quite a lot of extra logic for no visible gain. If you align to page you need adders to generate the p0-p3/missile offsets, rather than fixed bits combined with pmbase.

Same thing for different Y offsets, you then need seperate adders, rather than just using the linecount. ( And if you support Y offset for players you also need seperate Y offset for missiles )

I think a much more productive improvement would have been to make the missiles 8 bits wide

[atariksi]

Still quite a lot of extra logic for no visible gain. If you align to page you need adders to generate the p0-p3/missile offsets, rather than fixed bits combined with pmbase.

Same thing for different Y offsets, you then need seperate adders, rather than just using the linecount. ( And if you support Y offset for players you also need seperate Y offset for missiles )

I think a much more productive improvement would have been to make the missiles 8 bits wide

 

You misunderstood the part of page alignment. I stated that you can get the 8-bit register from DList Ptr to use for LSB 8-bit of PMBase if the chip had no room left. Currently, data to player data is formed by:

 

PMBase (upper 5/6 bits), 3-bits formed by ANTIC depending on player, 8/7 bits based on line count = 16 bit ptr.

 

The lower 8/7 bits will be taken from the new 8-bit offset and will increment every line like vcount, LpenV, POTs, ...

 

So far just same amount of total logic for the gain of being able to VScroll the entire sprite overlay or have one big multicolor sprite with Y-motion. Yeah, that's VISIBLE GAIN.

 

Now if you have 5 8-bit offset counters, you need some logic but it's similar to the 3-bits formed by ANTIC. Instead of just forming the 3-bits to decide which player data to read, it also puts in the correct 8-bit offset counter into lower bits. No adders. Yeah, missiles cannot be moved in y-direction independently, but all 5 players can. It's visible gain. You can still use VCount for one of the players as well to reduce number of offset registers.

[Heaven/TQA]

btw... since school I want to understand basics in computer science... is there any chance nowadays to get info how ALU, Microcode etc work? Any ideas to get a nice explanation how first 6502 systems work? oh...just remember that there was an A8 tool called "6502 simulator" which showed little animation etc....

 

A PC tool would be good, too... to "model" a very simple system...

 

Wikipedia only showed "general" bla bla...

[Crazyace]

I dont think that Vscrolling the entire sprite overlay is something worth wasting h/w other ( Or even scrolling a big sprite ) - as it's not general purpose enough.

I can see that having seperate offsets for each sprite would be nice for multiplexors ( change the offset in the dli to point to the same data ) but in h/w terms you might as well make a jump to proper sprites.

 

More resolution on the PM graphics would be a visible gain - I dont think PM offsets will.

[Fröhn]

I think that divide by 10 of the CIA frequency is a Commodore doing not Jay Miner's.

LOL, yeah sure. Suddenly some guy from Commodore management entered the room and said "I want that CIA frequency divided by 10" and then he left again

 

6 bits is all that is needed to provide the 1k page resolution. I sometimes think that the 4 missiles were meant to be fetched from seperate locations ( thus filling the 1k/2k memory block ) - but the combination did save 384/768 bytes.

I guess the PM locations are directly taken from the horizontal counter of the ANTIC. Changing memory locations of those would also require different X-position of the DMA fetches and that might interfere with other fetches.

[atariksi]

I think that divide by 10 of the CIA frequency is a Commodore doing not Jay Miner's.

LOL, yeah sure. Suddenly some guy from Commodore management entered the room and said "I want that CIA frequency divided by 10" and then he left again

...

 

Read post #2756 where I stated it was Amiga Corp.

 

>

6 bits is all that is needed to provide the 1k page resolution. I sometimes think that the 4 missiles were meant to be fetched from seperate locations ( thus filling the 1k/2k memory block ) - but the combination did save 384/768 bytes.

>I guess the PM locations are directly taken from the horizontal counter of the ANTIC. Changing memory locations of those would also require different X-position of the DMA fetches and that might interfere with other fetches.

 

You guessed wrong. Missile DMA is last cycle (113) and it's followed by Instruction fetch.

[atariksi]

I dont think that Vscrolling the entire sprite overlay is something worth wasting h/w other ( Or even scrolling a big sprite ) - as it's not general purpose enough.

I can see that having seperate offsets for each sprite would be nice for multiplexors ( change the offset in the dli to point to the same data ) but in h/w terms you might as well make a jump to proper sprites.

 

More resolution on the PM graphics would be a visible gain - I dont think PM offsets will.

 

Vscrolling is same as setting Y-position since you have values from 0..255 available and they wrap around. It's general purpose but general purpose of moving each sprite individually, you need 5 8-bit offset registers. It's useful that it would fit into the same chip as a plug-in and be backward compatible. You can leave offsets at default value (0) and still use sprites as they are currently. You can't jump to each sprite horizontally as DMA will not reoccur until exact cycle positions occur on the scanline. Yeah, you should be able to replicate sprites vertically using the offset method or the HPOS method.

 

I am sure if you looked at the schematic of ANTIC after the modification, you'll see a visible gain.

And I am sure if you set the offset to some different value, you will see sprite move up/down.

 

More resolution would definitely require major modifications to the timing.

[Crazyace]

I very much doubt that I'd see a visible gain on the schematic

 

Your vscroll mechanism is inelegant - as the missiles aren't supported. It's just my opinion though - I think if the missile's were fetched independantly it might be workable, and it would be backwards compatible when set to 0 ..

I think if I used 4 or 5 8 bit registers , instead of offsetts I'd make them Y comparators, and have them trigger the vertical position of a shorter sprite, rather than scrolling a full height sprite. The sprites would then be fully positionable objects, like the c64 and TI/MSX.

 

 

 

For a visible gain I was thinking about an effect on the screen. Your offset mechanism is more of a programmer aid. I was thinking of 8 bit wide missiles - as that would effectively give you 4 16pixel wide sprites, rather than 4 10pixel wider sprites ( or 4 multicolour 8pixel sprites rather than 2 )

[Crazyace]

Was a divide by 10 for the CIA needed to give a better match to serial baud rates? or was it to avoid h/w bugs?

[atariksi]

I very much doubt that I'd see a visible gain on the schematic

 

Your vscroll mechanism is inelegant - as the missiles aren't supported. It's just my opinion though - I think if the missile's were fetched independantly it might be workable, and it would be backwards compatible when set to 0 ..

I think if I used 4 or 5 8 bit registers , instead of offsetts I'd make them Y comparators, and have them trigger the vertical position of a shorter sprite, rather than scrolling a full height sprite. The sprites would then be fully positionable objects, like the c64 and TI/MSX.

 

 

 

For a visible gain I was thinking about an effect on the screen. Your offset mechanism is more of a programmer aid. I was thinking of 8 bit wide missiles - as that would effectively give you 4 16pixel wide sprites, rather than 4 10pixel wider sprites ( or 4 multicolour 8pixel sprites rather than 2 )

 

You can still use missiles as they are by moving them in memory. However, at least you get the 5 players with y-motion without having to move them in memory. Yeah, if they doubled the ANTIC sprites and had 8 players and 8 missiles where the missiles were preset shapes via GRAFn registers and their own color registers that would also fit into the 2K PMBase block. I just don't see it that beneficial to have 2-bit missiles being DMAd where the shape is very restricted-- so I always think of it as just 5 players.

[atariksi]

Was a divide by 10 for the CIA needed to give a better match to serial baud rates? or was it to avoid h/w bugs?

 

I don't think it was due to serial baud rates or floppy rates as floppy drives use the 500Kb/second which doesn't divide evenly into 716Khz. And serial baud rates are better with higher frequency and this CIA frequency is 709Khz for PAL systems so you would wind up with a PAL Serial Port vs. NTSC Serial Port.

 

Two reasons I have heard for slowing down the frequency-- to get slower interrupt frequency for maintaining time so it does not hog up too much CPU time. So 716Khz / maxval = 11Hz. Another reason I heard was to get some real time comparison for the tick count so the original PC timer has 1/1.19318Mhz * 16 bit count * 16 bit register giving 3600 seconds (1 hour) without overflowing the 16 bit register.

 

Of course, the chip has to be able to handle the 7.16Mhz.

[Thorsten Günther]

Sure the Amiga OS liked to meditate on that Yoga mat but when it was working....wow! That trick with sliding desktops and fullscreen apps over top of each other was just amazing. That and it was really first out the consumer gate with multi-tasking.

 

Funny, I always thought that the first consumer oriented computer with a multi-tasking OS was the Sinclair QL in 1984.

 

 

Thorsten

[carmel_andrews]

Just to correct the person that said the BBC computer used a z80, it used a 6502A or B as far as i recall, i think it also had an 'off the shelf' VDC chip as well

 

The BBC master series i think used wdc's 65SC12 processor as i recall it had 128 - 512k of memory

Edited January 19, 2009 by carmel_andrews

[youki]

Another games that looks better on Atari XL compared to the C64 version.

 

It is the excellent : Henry's House

 

the XL version is more colored , but i prefer the game play of the C64 one (both are very close, but i don't know it seems smoother on C64 and i prefer also the C64 sounds)

 

Anyway , excellent game on both plateform but nicer on XL

 

Atari XL version :

 

http://fr.youtube.com/watch?v=9GaYpeuVGQ8

 

Commodore 64 Version :

 

http://fr.youtube.com/watch?v=k7kR4H6l4bY

[frogstar_robot]

Another games that looks better on Atari XL compared to the C64 version.

 

It is the excellent : Henry's House

 

the XL version is more colored , but i prefer the game play of the C64 one (both are very close, but i don't know it seems smoother on C64 and i prefer also the C64 sounds)

 

Anyway , excellent game on both plateform but nicer on XL

 

The player character moves about the screen faster on C-64 but many of the screen objects appear to be coarser in their animation. Still being able to whip your guy about the screen faster means the C-64 version will play different and not just look different. Some people will like being able to scoot through the screens faster on C-64 and that may be worth overlooking that the visuals and animation aren't as pretty as the XL.