Atari v Commodore

[Atari v Commodore]

200

 

I think the winner of the knifes is atariksi.

[Atari v Commodore]

You already see Barnacle Boy who was done with this issue come back with a revised explanation.

 

[Atari v Commodore]

I know you have some emotional bias toward bounding boxes t

 

[Atari v Commodore]

This thread makes me want to hook up my 64, but I'm still not sure about the best affordable way to get games over to it. The 1541 Ultimate is a little out of reach.

 

for casual gaming you dont need 1541u, you need an 1541&X1541 cable or one of its descendants, and uhmm forgot... Fröhn will tell you what software.

[Atari v Commodore]

I think the fact that the 8-bit computer makes us feel so connected in some way (either to Atari or Commodore or both) is a real strength of the 8-bit era, when people were pretty much divided into "computer user" (which meant enthusiast) and "non computer user" which meant they did not know jack shit.

 

 

nice post. just a sidenote:

 

the connection ppl feel to 8bit machines has not much to do with the technology it offered IMHO. Simply most ppl was a kid at that time, and what someone had as a kid will be always memorable. Most c64 users were like computer users today, they knew how to type run the games, and thats it. and when the amigas pcs came moved on. Only we think it special. For us it really is.

[Atari v Commodore]

...

Stuff like "Jumpan" or "Miner 2049er" (sorry but I do not remember which I was comparing now) looked EXACTLY the same, and I was hoping for just a little difference just for fun. The game Boulderdash looked so close, I could not believe it. I was just amazed at how close they are. I have not looked at many games for C64 yet, but I am planning on it because it is a new 8-bit world to explore.

...

A major part of the discussion has been which hardware is superior which is not related to what games exist on each machine and how similar they are. There can be many reasons for similar games-- one ported to another, time invested to develop, etc. I know for one Boulderdash that you mentioned has better color scheme on Atari.

 

indeed, "color scheme" or "gameplay"comes always to the rescue when the games are pixel perfectly the same.

[Atari v Commodore]

Nicely played Wolfram!!!

 

I don't waste my time mocking anyone-- it's a waste of time.

 

 

yeah or maybe think for a moment. I've seen you arguing with 4 different guys. and you accused all 4 of them with the same sins. chewbacca argument, changing subjects, etc.

 

Cant be everyone doing the same to you, regardless a8 or c64 fan, lives in Europe or USA, is this old and that old. and while being all different people, loving different machines, from different countries, they all commit the same crimes against you? Maybe the problem is with you ?

[Atari v Commodore]

You haven't read all the posts then. He stated I am lier, most deceptive poster, jumped all over the 8-pixel wide example, etc. etc. Defends people with points unrelated to what they stated. Purposely trying to find fault. Changing subjects from bounding box to recursive bounding box. I don't know what you read. Anyone who disparages someone without any proof is just emotionally imbalanced.

 

[Atari v Commodore]

I just save this one here, so next time I can show it to the one who says cheap=bad.

 

Same moron who brought you the crappy c64 came up with that. Certainly the XE chipset was better that the c64,just the quality suffered as it was Jack Tramiel aka mr c64.

 

talking about crappy, 30 million people picked c64, and 4 million a8s sold all models put together, now how many a8 models there were ? atleast 8. so that makes it 30 000 000 vs 500 000.

 

the single model c64 outsould single a8 models at a ~60x rate.

 

and there were plus4, c16, c128, etc etc in the C= 8 bit line, which we havent even counted in yet for an all models vs all models fight. the vic20 alone outsold the entire a8 line aswell.

[Atari v Commodore]

So if you have sprites moving around, you have to self-modify the code in the kernel to maintain same total cycle time.

That's what IRQs are for.

 

If you had a kernel running, then BAs would have to occur outside the kernel even if you started kernel with IRQ.

 

 

"realistic" scenario. in the REALITY only demos do stuff that needs cycle exaxt timing AND sprites moving in the same area. the only appliction of it being showing off big coder dicks.

[Atari v Commodore]

btw... discussing old computers is much more fun when you don't give a shit who wins.

 

Yes, it's like bragging about the "most advanced steam engine"-award in the age of space-flight

 

actually that would be an interesting topic. I'd like to see why and how one is better than the other, what are the slight tweaks that brings advantages

[Atari v Commodore]

I'm gonna distract everyone by having at look at the peripheral line:

 

In 400/800 beige we have:

 

410 cassette drive

810 diskette drive

820 drum printer (a very *interesting* 40 column printer)

822 thermal printer (nice & quiet)

825 80 column printer (full-on Centronics model)

830 300b acoustic modem (WarGames!)

835 300b direct connect modem

850 rs-232 & printer interface module

also...

CX-85 keypad

 

In XL Brown/White we have:

 

1010 cassette drive

1050 diskette drive

1020 color plotter

1027 LQ printer

1025 80 column printer

1029 80 column programmable printer

1030 300b modem

also..

CX-77 touch tablet

CX-75 light pen

CX-22 trackball

 

XE gray:

XC11 and 12 cassette drives

XF551 DS diskette drive

XM301 300b modem

SX212 1200b modem

XEP-80 80-column adapter (with a MOS 6551!)

XMM801 80-column printer

XDM121 80-column daisy wheel printer

 

So Atari certainly gave you a lot of choice.

 

this is just a list of disk drives not that not made it into production:

 

SFD 1001

1541D

1542

1543

1551

(SFS 481)

1561

1563

1565

1570

1571-II

1571CR

1572

1582

1590

1591

8060

8061

8062

8280

[Atari v Commodore]

So if you have sprites moving around, you have to self-modify the code in the kernel to maintain same total cycle time.

 

 

that heavily depends on what you want to do. for a game multiplexer you dont need "same totaly cycle time". for moving sprites around opened sideborders/horizontally splitted rasters it has to be done and there are other methods.

[Atari v Commodore]

For the BA mumbo jumbo, I was under the impression that if you stagger all 8 sprites vertically (eg. first at Ypos 0, next at 21, 3rd 42 ...) you get the overhead for each line of each sprite? But I might be wrong again.

 

yeah. but if you put all 8 sprite on the same Y pos BA stuff will happen only once each line again, as sprite DMA is hard wired, first it reads sprite 0 (if needed), then sprite 1 (if needed) etc. now if you use every 2nd sprite 4x you're fucked with 4x BA shite. if you use sprites 0 1 2 3 only one BA is needed. all this is happening in a rasterline on the left/right sides of the screen.

[Atari v Commodore]

You want to give a breakdown for all DMA cycles used on C64 with and without ALL sprites; it's worth hearing from a different person than Frohn all the time.

 

Well, ok. This is off memory for PAL timing, so Wolfram or Fröhn may correct me if I get something wrong:

 

Theoretically, you have 312 scanlines a 63 cycles = 19656 cycles total.

 

For each of the 25 character rows, VIC has to steal 40 cycles for fetching color nibbles from color ram and character pointers from screen ram (that also applies to bitmap mode, the screenram data will then serve as additional color information instead of character pointers).

 

Actually, VIC tries to take over the bus by setting BA low 3 cycles before it actually needs it for DMA, but in the end the total number of stolen cycles depends on what the CPU is doing at that point. If it is performing a memory write accesses, it can continue operation, so it can be anything between 40-43 cycles.

 

Assuming the worst case without sprites you got 19656-25*43=18581 cycles/frame (?).

 

With sprites it gets a lot more complicated. Sprite data fetch takes 2 DMA cycles + 3 cycles overhead per sprite line. That overhead is again caused by BA going low 3 cycles before the DMA takes place, but the total overhead will vary depending on which sprites are used and where they placed vertically. In the best case, all sprites take 21*8*2+21*3=399 cycles, tn the worst case 21*8*5=840 cycles/frame.

 

you got the sprites wrong. 312 lines * 8 sprites * (3 byte wide + 1 sprite pointer access) + 312* the BA mumbo jumbo 0-3 cycles, best case would be be using 200 lines? my calculation definitly show worst case - theoreticalc . bear in mind the BA behaviour happens only once if you use all 8 sprites, VCII will know it has the bus already when getting to do the DMA of the next sprite and no need to re-request it from the cpu.

 

oh forgot that VICII will perform these sprite readings at 2mhz, so numbers should be halved by two... I'll leave it to Fröhn to do the correct math

[Atari v Commodore]

This is ludicrous.

 

Atariksi, you're like the guy who keeps dropping farts in a room and sits there loudly blaming someone else.

 

It's ammazing how atariksi turns almost every argue into a debate of who said what, and then it all gets lost in hell. TMR, me, now you. atariksi is the chuck norris of all forums. He'll strangle you in the who said what in 3-4 posts, and then you'll die a slow and painful death

[Atari v Commodore]

Now if you start enabling scrolling, overscan, etc. you see Atari has to do a lot less work from the CPU perspective.

 

Now lets add sprites and colors and music. c64 hands down.

[Atari v Commodore]

Does not count if a Atari run 2x or 1.5x or 1.3 more faster than a C64. After all the waste for graphics, Atari have 7000 extra cycles per frame over C64 can get. It's a lot of additional programming can be done in there, and that's why Atari can do more advanced games as Yoomp! out of the possibilities of a C64.

 

Yoomp is not what I'd call advanced. The code is less complex than what's needed for an average platformer. also we have seen this gameplay in the mid80s just in 2d already (in fact gameplay wise yoomp is 2d aswell just the display is more twisted...)

out of possibilities? check the many c64 demos with similar tunels.

[Atari v Commodore]

Also, the basic problem is not just the C64 palette if you want to talk moving objects, the cell-based color selection in 320*200 makes moving graphic objects harder unless you don't mind colors changing...

 

yeah like the c64 dont have sprites to do that. its truly ammazing deliberately how stupid you can get, to proove somehing that is simply not true.

[Atari v Commodore]

And why the Atari having 128/256 colors , most of effect in demo are mainly in shade of gray , or shade of red, or shade of blue or shade of green? Can we not put Red , green , yellow and blue together??

I have the same feeling when watching A8 stuff. The larger palette seems to lead people to choose more similar (often monochrome) colors.

 

I guess you meant the larger palette seems to lead people to choose more accurate colors.

 

no. he meant this I think:

 

Original:

 

 

colors changed by me:

 

 

 

the original has many similar colors which are hard to distuingish. In the new one I have changed this, tried to give a "correc" contrast "graph" to the whole. I guess the author thought: "lets show how cool we can have very close shades of green/blue/etc". But that just made the picture flat and look dull/monochrome.

[Atari v Commodore]

it is not... for "normal" game coding it is perfect... no twin IRQs plus additional code and runstop/restore blocking simply to avoid flickering rasters...

 

for demo coding yes... one wsync is enough, rest running in a cycle exact kernel...

 

for "normal" game coding you dont need cycle exact irqs, the flickering can be pushed by nops to the horizontal invisible area without much effort. no twin irqs and additional code needed. runstop/restore: my opinion: if the user deliberately wants to kill the game let him do so. to avoid it: its just a matter of pointing an interrupt vector to an rti, not a big deal.

 

wsync is really only needed for demo stuff on the c64. opening sideborders, splitting raster colors horizontally, etc.

[Atari v Commodore]

I used the word trickery before we had a looong discussion with Oswald year ago... and I knew that you will jump on it...

 

you are polemic... I can trigger rasterlines everywhere via IRQs, too... If I am using the DLI feature of ANTIC then it depends on the display list... simple as it is...

 

 

huh? Yeah, I know you havent used here the word trickery, I am basing this on conversations with atariksi/emkay and dont know who else was claiming this.

 

you can use IRQs too. You can thank god I am not atariksi, because I would go on until the end of the world that you can use only DLI's for that, and that would be still more fair than as he wants to force c64 "joystick I/O" be compared with a8 "joystick I/O". because DLI's are ment to do that, but c64 joystick port is not

[Atari v Commodore]

The Atari only does DLIs coinciding with just before mode lines. So what?

 

That's 95% of the application of such interrupts, or more. In the other cases, you might sit there burning a few cycles.

 

C-64, you're burning cycles in many cases since you have no WSync and need to do a double-trigger with the first one executing short instructions, and even then you only land on something like a known 2 or 3 cycle boundary.

 

 

full ack. I agree

 

nitpicking1: you dont need wsync for a simple gfx mode change (not even for simple raster color bars) just enough nops to push the flickering to the invisible horizontal area

nitpicking2: you can "stablize" an irq within a line, but it needs a lot of effort

[Atari v Commodore]

I think the C128 suffered from the same problems that the atari 130xe did...i.e very few companies were prepared to support the higher ram format (given that the c64 and the atari 800 and xl series were already accepted formats (not that much was specifically released for the XL series anyway)

 

Lovely sexy machine though (especailly the 'D' version) shame that tramiel didn't do likewise for the 130xe

 

Imho the c128 was simply too compatible, this made it not possible to offer more features. what was there as new features was not enough. It should have been using a VIC3 (least new features: VIC2 modes extended to 640x, the 16 colors selectable from a palette). and the 658c16 at atleast 4 mhz.... and maybe a dma for the icing on the cake. The 1571 drive was o.k. it could have supported such a machine nicely.

[Atari v Commodore]

f.e. attachted a display list code:

 

.byte $4f,vram lo, vram hi ; Gr. 8 line highres

.byte $0f,$0f ;2x graphics 8 line

.byte $47,textline lo,textline hi ;gr.2 charmode line 16 scanlines hi

.byte $4e,vram2 lo, vram2 hi ; gr.15 line 160x 4 colour mode

.byte $0e ;another line

.byte $42;textline2 lo, textline2 hi ; gr.0 charmode line 8 scanlines hi

.byte $41, dlistplaylist lo, displaylist hi ; wait for VBL and restart displaylist

 

nothing special here...

 

you can multiply scanlines by triggering VSCROL register to duplicate scanlines by using internal ANTIC buffer.

 

 

the simple display list shows few features you can not do or only with trickery on VIC2... mixing modes, several different video ram... (here I am loading 3x times data from different adresses... no VIC bank limits here)

 

Graphics textline 2 has 20 bytes lines while the others have 40 bytes...

 

when I am doing a simple LDA #35 STA $d400 I am in overscanmode so each scanline has 24 bytes visible or 48 bytes visible...

 

 

So, the end of the line says: c64 can trigger raster irq anywhere, a8 can only do it if you adjust the mode lines so that only 1 line of them is visible everywhere. in the "real life" cases a8 does a dli only each 8 pixel. I was far from being wrong.

 

 

"the simple display list shows few features you can not do or only with trickery on VIC2"

 

you just said it. the forbidden word! "trickery" ! A8 users insist that G2F and such modes are not a trickery, and they also insist that there is no difference between "built in" and "cpu driven" modes, everything is built in there's no trickery they say...

 

So now why should I accept that there are things on the VIC2 that can be called trickery ? Everything is built into the VIC2 aswell, just need to make use of it with the cpu