Wolfram

I think the winner of the knifes is atariksi.

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.

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.

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.

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 ?

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.

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.

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

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

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.

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.

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

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

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

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.

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.

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.

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.

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

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

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.

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