Oswald

double post. deleted.

Again: He had a 1541-I. No switches. Got that everyone??!?! read it again. also no master/slave/cs switches on todays hdds either, and nobody gives a fuck. once you set it and forget it. thanks god you are mr objective, who can objectively decide that blowing up ics are less of a problem than no switches for device nr. obviously they werent designed to be stacked. just like not to be put into water. they had the PSU inside which delivered the heat.

<bryan mode>I don't think those issues are equal. I've never known a 1050 to break from flipping disks, and Atari never said to try it.<bryan mode>

and some atari drives blew when you plugged cables without turning them off, and some others had non compatible RPM. but who cares? not me. hairsplitting. I don't think those issues are equal. I've never known a 1050 to blow from unplugging the cable, and Atari never said to try it. just like I've never known anyone with a misaligned drive nor with overheating problems. if he didnt know about the jumpers he wouldnt have known about the switches either. RTFM. and once unscrewing a drive to cut a trace to change drv nr, is not a huge problem. similar to setting master slave jumpers on ide drives. once you do it and forget about it. what other hand my dear? like on your first hand a c64 guy were sitting not being able to run 6 stacked 1541 drives without a hitch. yet to hear such a sad tale. c64 had more bbs setups, never heard a complaint about drives being faulty.

guess it was like: "ok guys we have the sprites, the char bitmap modes, letz see what else fits in - umm lets make lightpen! - it will be not so accurate but it we can fit it - lets use 256 colors! - nah no it takes up too much silicon space, and 8 sprite would be better than reducing them for more colors, also you can fit 2 colors on a byte with 16 colors so, 256 colors scrapped - lets have a collision register! - cool! but we dont have much silicon space left, lets consider some compromises here"

probably you mean that all '0x' pixels are threated as background. that causes all the problems, but hey democoders like it, you can do interference circles with them with new color where the circles meet

and some atari drives blew when you plugged cables without turning them off, and some others had non compatible RPM. but who cares? not me. hairsplitting.

or you can use timer AND wsync. hand stabilization may be some cycles faster when you need to the stable part of the code be in some other place than where wsync achieves it. but practically no gain, similarly to atariskis stupid "faster I/O" claims.

perfectly suitable against ppl arguing a8 came in 1978, but when it comes to tech specs, they use a 5 year later modell as a basis. I don't argue that way. Here's my position: The 800 had the best abilities from 79-82. The 64 was more bang for the buck and had more capable hardware, although I feel it was a little rough around the edges. The 64 was the best choice until the ST/Amiga days (82-85). Atari began to lose focus and engineers and the 1200XL was a serious mis-step. The Atari 800XL was a good value and had a good software library, but probably wasn't the best choice for a first-time buyer. I hate the design of the XE's. In my opinion, it makes both machines leaders but at different times. As a caveat, I think the Atari has an unusual range of capabilities and you can squeeze more out of it with clever programming than with most systems which makes it fun for those who like cycle-counting and whatnot. I also think Atari fans are nuts if they think everything can be done in high-res with 256 colors if only someone would code it. However, I'm all for trying everything and seeing what works. I also (also) think that the Atari 800 never got the respect it deserved for being such a powerful and well-crafted machine (mostly due to Atari's bungling of it), so maybe I code the A8 for chivalrous reasons. The 64 is pretty well respected the world over. -Bry damn. all I can do is agree.

perfectly suitable against ppl arguing a8 came in 1978, but when it comes to tech specs, they use a 5 year later modell as a basis.

me and my friends probably had an updated drive-head mechanism. google is my friend: ==> Atari 1050 "You've been plugging and unplugging the SIO cable with the 1050 power pack plugged in, right? That's a no-no. Most of the time it's Okay, but about 1 in 10, 20 times, it will blow out 'U-1'. It's a CA/LM 3086 I.C. at the right, rear of the main board. A 14 pin DIL chip." ==> Atari XF551 Rotaton rate: 300RPM. Since all other Atari-specific drives run at 288RPM, this results in rare compatibility issues. Specifically, these commercial disks do not load in, and can be damaged by, the XF551:

Two are, yes: 1541C and 1541-II. The third is a FD-2000 (A 1581 compatible drive). Garak Well, I would consider that a "no." I know they eventually fixed it, but the 1541-C came out in 1986, and the II was after that. its ammusing how the atari fans all had a c64/128 and know everything even about the drives. why so if the a8 was so much better ?

It's cool how forward-thinking the A8 engineers were in this regard. Atari didn't invent these things, but they did consider how to eliminate problems for the user. Ever try to connect two 1541's to the C64? yeah, they can copy a whole disk without any c64 interaction. great stuff I'm gonna call this an urban legend. Not the bit about copying without C64 interaction. The part about two 1541 drives both staying in alignment long enough to copy a disk. I have never saw or heard about a disaligned drive only of datasettes so I'm gonna call yours an urban legend.

the 1541 went trough numerous disasters in its design phase. the smallest problems of all was inconvinient the device nr setup.

Spoken like a true 2600 programmer. true bullshit indeed. defeats the whole purpose of having an interrupt and a main code which should be able to do something useful apart from synching itself to the irq. which is I doubt is possible other then some dumb loops synched to the irq, and why would you want an irq and a "main" program when both of them is synched to the same event anyway. you can rather just busy wait to some event then.

It's cool how forward-thinking the A8 engineers were in this regard. Atari didn't invent these things, but they did consider how to eliminate problems for the user. Ever try to connect two 1541's to the C64? yeah, they can copy a whole disk without any c64 interaction. great stuff

no it cant because that would be totally wrong color combinations!!!!!1111

omg, c64 pictures use totally wrong colour combinations !!!!!!1111 totally right color combinations has no compromise!!!!111 its the very same colour!!!!!1111

You just desperately refuse to admit that the Atari version of the table looks better; there's no other explanation why would you use Turrican as argument. I never said that this Ping Pong game on atari would look better than any other game on the C64. I admit that the atari version of a gfx 20 years later and using pc tools looks better than the 20 year older c64 counterpart tho it would have been a 4 color table if it were ported at the same year, speaking of a fair comparison...

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive. yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64 I don't see a problem with this, as far as the scene looks overall better. Compared to it, the C64 screen looks like a poor relative. Of course the colour attributes add quite some nice possibilities to colouring an image (and I really wish atari had this feature), but you're still heavily restricted by the limited palette, while Atari is not. that c64 screen is ~20 years old. I could similarly pick a 20 year old a8 screen and compare to something done today on the c64... whats the use of a palette you can not display in regular modes. its a bad engineering compromise not an advantage. But as I already said, you could hardly make it look much better than that. Perhaps you could use some hi-res optimization, but the colours would still be flat. If I'd had to choose if I want a colorful (well sort of... a few colors more than on c64) ping pong table or turrican.. guess which one would I choose

sure it can, but there are better methods: a) set a timer to the scan line length, then check the timer upon irq entry and add nr of cycles needed to get stable raster. ( bne selfmodthis bit $ea bit $ea you jump on either a 3 or 2 cycle instruction effectively adding up cycles in 1 steps) b) on c64 its possible to have the irq vector on the CIA chip regs so that the timer with another register makes up a jmp instruction, automatically selecting the routine which w8s enough cycles c) wsync will be the best for the a8 I guess

Don't some C-64 raster tricks do that anyway? Have the raster IRQ that then sets a second one. CLI, then loop with 2/3 cycle instructions only. That way the subsequent IRQ is guaranteed not to be delayed too long. code aligned on bounderies what does this mean? if memory boundaries then totally wrong.. rybags, yeah, but only with 2 cycle instructions, so the subseq irq has only 1 jitter left which it can kill with some trickery to 0. only reducing the jitter has no benefits, you need either 0 cycle synch or none.

I doubt you can do that without wsync, or the corresponding c64 techniques. 6510 will finish the current instruction before serving an irq so you will have a jitter. no matter whats the irq source. Only if IRQ occurs in middle of the instruction. If you know your code, you can avoid the jitter. In fact, if you run the code in post #757 (on 800XL), you won't see jitter. Haven't tried on earlier systems which may have a different OS to handle IRQs, but you can easily modify it so there's no jitter. The whole purpose of the IRQ was to factor out the WSYNC (which can cause some cpu cycles to be lost). It's stable w/o WSYNC. sure, do anyting more complex than jmp * in the mainloop and show me how you would make the irq not appear in the middle of an instruction. good luck!

whats the definition of a normal red color ? http://eosweb.larc.nasa.gov/EDDOCS/Wavelen...Colors.html#red Better yet, on an RGB triple I'd expect to see a maximal R component and minimal G and B. so a8 doesnt even has a normal red color either. cheers maximal R and minimal G and B = eye cancer speccy colors.

Ofcourse they can. One scanline is exactly 114 cycles on A8, and you just have to set the timers to 114 cycles too since they run from the same clock. On C64 it's similar: One scanline is 63 cycles, just set timer to 63 so you get 1 IRQ per scanline too (many demos use one timer irq every 8 scanlines to create those big pixel modes). What I mean is - the Timer will be synched to whatever part of the scanline you initiate it at. Despite having the countdown mode that's exactly one scanline in duration, Pokey doesn't have any idea of the H/V position of the screen draw. do you think the CIA chip timers have any idea of the H/V position of the screen draw ? big suprise: naturally the whole system is based on the same clock even on the c64.