Atari Vs C64 --- 80s Computer scene etc chat...

[emkay]

porting over amiga's Desert Dream to c64 is enough technical achievement for you? check it on youtube. and what have you done mr ? you cant even get basic atari 8 bit facts right, which is your beloved machine. I have seen you turned down by heaven not twice, not three times... that is your technical achievement.

 

 

Sure, I don't know how far you are involved into the Desert Dream demo. I also don't know what you are doing in your real life and how far this is involved with computing.

But, let me explain my point

In my job I had nothing to do with computers. But when learning my job, I really was the only one who wrote programs to draw math functions we learned before in school, just for rechecking the correctness.

I learned coding just for fun, not for money making purpose.

So back in the 80s-90s I wrote the only game that uses hires colour... even today there is no other game doing so. That game also uses 3 resolutions at one scanline.... and it uses instruments on pokey, you may recognize are the same in a demo you have posted in this thread. Even the G2F takes usage of my ideas for a "new" graphicsmode in the 80s...

 

Have you seen my post with the "XL-ST Schiffeversenken" game? It's from '88 ... all my ideas and all my code. To write this game on both, the XL and the ST took (including networking stuff) around 3 weekends. Not 3 years...

 

Looking at the Desert Dream demo, you also haven't done it alone. So, when doing bigger projects, you have to build groups to go ahead further... particular when your real life hasn't much to do with such things.

 

 

And, heaven turned me down nowhere. He is also no coder in profession and don't know all. He is arguing by his point of view, which is the right of all in my opinion.

 

 

But, when people lose focus on good argues, they get personal and start insulting people, like you do.

Edited April 23, 2008 by emkay

[Oswald]

Boulderdash is a "lossy" port. Anytime you lose something like colors, resolution, sound effects, timer resolution, etc. it's a lossy port.

 

that means 100% ports are impossible. a slightly different color or sound fx, and boom: you're doomed: a lossy port.

[Oswald]

Do the 1541, 1571 boot up or does one always have to write the LOAD "*',8,1 or something similar?

 

c64 has no auto boot up. a c128 does. you can use modern cartridges on c64 to do that, or hack a program on c128 which switches to c64 mode at some point. that approuch sounds extremely cool tho. no emulator, still having the real machine and controlling everything from the pc. wow maybe with 1541 ultimate (1541 emulating fpga with mmc, d64 images, and other goodies) the 64 arrived to the point that this can be done.

[Oswald]

But, when people lose focus on good argues, they get personal and start insulting people, like you do.

 

I have lost focus on my behaviour, and not on argues. I have told you that handshaking is not to support faulty HW as you stated, even SIO uses it. Also not a single c64/1541/CIA chip whatever broke down because of a fastloader as you stated. Also the reason for slow loading is not that anything would break down if it was faster. Software fastloaders goes up to 20x of the original loading speed exceeding what atari is able to, still no c64 breaks down coz of it.

[Thomas Jentzsch]

Boulderdash is a "lossy" port. Anytime you lose something like colors, resolution, sound effects, timer resolution, etc. it's a lossy port.

Then everything is a lossy port.

 

Okay, it is simple but an Atari coder would use and design according to what's available rather than try to get 24*21 sprites.

So even the two 2600 sprites are as good as the 8 Atari 8-Bit sprites because a 2600 coder would do the same, right?

 

You can cover the screen with sprites on Atari as well by quadrupling the sprite size...

But not in full resolution.

 

...but why bother-- they are mostly needed for fast moving objects since there are more than enough graphics modes on the Atari that can be updated fast.

I don't think you can compare graphic modes with sprites. Sprites are way more flexible than graphics modes.

 

Fact is, the C64 has better sprites and the 8-Bit has more graphic modes. Which is more important on average is a matter of opinion (= subjective).

 

In my subjective opinion, the C64 is doing better on average.

[Thomas Jentzsch]

Also not a single c64/1541/CIA chip whatever broke down because of a fastloader as you stated.

Actually it was vice versa.

 

IIRC the 1541s regularily became faulty due to the reading head becoming decalibrated due to a fault in the original OS software. Many fastloaders fixed this problem.

[Heaven/TQA]

Thomas, you are a Blasphemer...

[Thomas Jentzsch]

Thomas, you are a Blasphemer...

Nah, I am just not lead by ideologies.

[Heaven/TQA]

now another story of my "short" c-64 live... with my knowledge of A8 was painfull to spend hours with Graham/Oxyron getting my "4x4"-mode (similar to mode9++) right just by cycle exact triggering of $d011... coming from A8... i never needed to "trigger" things cycle exact (except of the "new" mode9++)... so i am not a fan of doing such "strange" tricks... but maybe strange to me simply because i have no 20 years experience on that machine...

 

but when coding games... i am sure i would make quick progress as the machine is build for sprites & games (colour ram) plus SID...

 

the c64 basic is crap, here Atari has an advantage as there are many "custom" commands for graphics and sound... but Atari left out the player/missle commands (anybody any rumor why?)... so for basic beginners i guess c64 is kind of pain...but for assembler geeks not a problem at all...

[Bryan]

the c64 basic is crap, here Atari has an advantage as there are many "custom" commands for graphics and sound... but Atari left out the player/missle commands (anybody any rumor why?)... so for basic beginners i guess c64 is kind of pain...but for assembler geeks not a problem at all...

 

Making PMG's easy for a BASIC programmer to use probably would have exceeded an 8K ROM.

[Oswald]

Heaven, why havent you simply borrowed a source? I hate cycle exact timings aswell, and even with all the years behind my back it would take me aswell to write a 4x4 timing from scratch.

 

basic: as I didnt know anything else before, and didnt know anything else later either, I didnt found c64 basic any pain, simply had no idea it could have been better. I do remember designing sprites on paper entirelly, adding up the bits, and then entering them into data statements in basic.

 

home computer pioneering years were simply like that imho. there were times when people built their own computers, there were times when people coded their own monitors in basic, when people had no backup devices and typed in the listing of the game when they wanted to play, etc.

 

also dont forget the great number of basic extensions on the c64. best one being graphics basic in my eyes, built in sprite editor, sprite animations&movements / music can be done entirelly driven by machine code interrupt with a few simple commands. configurable split screen modes, hispeed screen scrolling by asm routines, redefinable origo/scale for gfx commands (line,point, circle whatever you dream off). the list goes on forever.

 

I have used this basic extension to precalc stuff for demos for a long time. for exampe soiled legacy's intro zoomer, bump mapper, weird caleidoscope plasma, chessboard stretcher, dot tunel, textured tunel, twister, were ALL precalculated on a real c64 in graphics basic !!

Edited April 23, 2008 by Oswald

[TMR]

the c64 basic is crap, here Atari has an advantage as there are many "custom" commands for graphics and sound... but Atari left out the player/missle commands (anybody any rumor why?)... so for basic beginners i guess c64 is kind of pain...but for assembler geeks not a problem at all...

 

Making PMG's easy for a BASIC programmer to use probably would have exceeded an 8K ROM.

 

From what i read in "Hackers", Atari kept quiet about the players for a few years when they weren't telling people about what the hardware could do... the cynical part of me has always assumed that they didn't make them available from BASIC because then would be machine code programmers would go looking too... but as i said, that's me being cynical. =-)

[frogstar_robot]

Do the 1541, 1571 boot up or does one always have to write the LOAD "*',8,1 or something similar? I'm not trying to find fault-- just for comparison as I have an atari behind my PC and never touch it-- just power it on and the PC controls the disks/keyboard/joystick/etc. but that requires that it boot directly into my application. I'd be interested in the smallest possible boot sector that I can transmit to a C64 so I can control it from a PC.

 

The 1541 is pretty much a self-contained computer. It "boots" from ROM pretty much instantly. For the most part, a C-64 doesn't have anything comparable to the DOSes we run on A8s because the computer need only issue instructions to the drive and just have a few simple routines to receive what comes from the drive. Assuming you somehow account for the non-RS232 protocol, those commands can issued from something that isn't even a C64. Software like "Star Commander" can be a lot simpler than software like APE because of the smarts in the drive.

 

You typed commands like LOAD "*",8,1 because the DOS built into the 1541/1571 isn't menu driven.

 

Granted, there is some serial handling code that by default sucks but that is addressable with fastloaders.

[TMR]

Boulderdash is a "lossy" port. Anytime you lose something like colors, resolution, sound effects, timer resolution, etc. it's a lossy port.

 

that means 100% ports are impossible. a slightly different color or sound fx, and boom: you're doomed: a lossy port.

 

To my mind, a "lossy" port would be like Zybex from the C64 to the Atari, where half the pixels went missing [smiles sweetly =-]

[Heaven/TQA]

Oswald... First I borrowed code snippet but it was kind of 4x4 iFLI and not what I wanted but Graham thought, come on...it's easy...let us do that from scratch...and so 4 hours went by and the next evening again... Graham giving me each line of code via IRC and in parallel explaining me the internals of the VIC... hahaha... and again parallel explaining me the code details to his parts of http://noname.c64.org/csdb/release/?id=48037 (esp. the rotozoomer and the "exit code" trick with PIA RTS... )

 

so "mine" 4x4 is similar to the one in the rotozoomer while not using IRQs but using rasters instead... and I am using his dithered font...

[Oswald]

For the most part, a C-64 doesn't have anything comparable to the DOSes we run on A8s because the computer need only issue instructions to the drive and just have a few simple routines to receive what comes from the drive. Assuming you somehow account for the non-RS232 protocol, those commands can issued from something that isn't even a C64. Software like "Star Commander" can be a lot simpler than software like APE because of the smarts in the drive.

 

APE is simpler for what I know (not much) . Coding anything thats fast and drive related on the c64 is a timing HELL. as the bit shifting mechanism from the CIAs is missing you have to handshake before each damned bit. and you have to do it fast, and time it correctly. as the c64 is slightly slower than 1 mhz and the 1541 is exactly 1mhz you can not also just sync once. the best you can get is only handshaking for each byte, but in that scenario you have to avoid all extra VICII DMA which stops the cpu (sprites&socalled badlines)

 

so you can have the drive to format a disk alone by itself, or you can even make two drives to copy one disk to another (without any c64 interaction!) but as the transfer protocol is absolutely software driven on both sides, its not a very easy task to do a loader.

Edited April 23, 2008 by Oswald

[Oswald]

heaven, hey kewl, then you can explain me how that rotzoom works I've once spent half an hour examining it, but I couldnt find out the basic trick, something is somehow precalculated but I dont get it ) also if you would implement that code on a8 you could do 50fps fullscreen rotzoom which wasnt done so far I guess

[frogstar_robot]

APE is simpler for what I know (not much) . Coding anything thats fast and drive related on the c64 is a timing HELL. as the bit shifting mechanism from the CIAs is missing you have to handshake before each damned bit. and you have to do it fast, and time it correctly. as the c64 is slightly slower than 1 mhz and the 1541 is exactly 1mhz you can not also just sync once. the best you can get is only handshaking for each byte, but in that scenario you have to avoid all extra VICII DMA which stops the cpu (sprites&socalled badlines)

 

Maybe so but I was talking about interfacing a 1541 to a PC through the PC's parallel port. So it may indeed be problematic as you say but even an old slow PC can bit bash a parallel port faster than that. So the PC author does have the job of implementing a serial protocol but then he had that job already. What's more, you are likely only interfacing that drive to create disk images. So while fast is nice, you don't have to beat your brains out for it because any given disk need only be read once.

 

On the other hand a 1050 can be plugged into a PC serial port with a fairly simple adaptor. So the PC author doesn't have to do much in the way of writing a low level serial protocol but he does have to talk to the drive with low level SIO commands because with Atari drives most of the smarts were in the computer rather than the drive.

[Heaven/TQA]

Oswald... I can not tell you everything HERE... Graham would kill me...

[Fröhn]

a) the CIA chips were faulty, so all the handshaking and shifting bits one by one had to done by software instead of lightning fast chip hw

The CIA chips are not faulty, only the VIA chips have a bug in the serial shift register.

 

It's not the electronics faults, it's strictly the OS'es fault. The electronics can easily do 125 kHz bit transfer (the maximum you can do in software) without a single bit failure for days. People have been using 10x - 20x fastloaders since 1985 without problems.

Since no one can really proof history, you can tell all you want, trying someone to believe it or not

It's proof enough when you can do billions of bit transfers without a single transfer error.

 

Fact: Big C did all necessary to push their Product. But the biggest problem-> the low data transfer <- they never could handle any better?

Ofcourse they could, they did in the C128 and 1571/1581 disk drives.

 

Making the slow machine more suitable for business usage by doing really nothing but change the code?

Good Lord...

They simply did not care. Why improve something which sells good already, especially if you are working on the next product: Amiga

 

The only assumption here is that they have seen problems during the development of the hardware. So they used the "handshake" methode to assure either the communication or the stability of the chipset.

No the software protocol was only a temporary protocol. Infact they were working on hardware serial transfer but the C64 was sent in for PCB optimization before the software to implement this serial transfer was ready. The optimizing team simply removed the wires from the CIA to the serial port because they were "unused".

 

Have a look at the manifold defective C64s in the first time. Possibly caused by fastloaders...

Those quality problems only appeared in the beginning. No fastloaders existed at that time. First fastloaders appeared around 1985. Also, fastloaders do not harm the hardware, in fact they even use the hardware LESS than the original software because the drive has to rotate the disk 10-20 times less which means 10-20 times less disk and disk mechanic abuse.

 

Boulderdash is a "lossy" port. Anytime you lose something like colors, resolution, sound effects, timer resolution, etc. it's a lossy port.

No colors lost since it's still a 4 color game, just different colors. It's a matter of taste which ones are better. If different colors mean a "lossy port", then also A8 NTSC -> PAL ports are lossy because of different colors

 

You can cover the screen with sprites on Atari as well by quadrupling the sprite size but why bother-- they are mostly needed for fast moving objects since there are more than enough graphics modes on the Atari that can be updated fast.

It's not about "graphics modes" only: What about a fast moving fullscreen enemy sprite like many arcade games and a few c64 games have it?

 

PMBASE is also like a sprite pointer

One pointer for all PMs, but on C64 you have 8 pointers, one for each of the 8 sprites.

That can have advantages like in sprite multiplexing.

No it has advanteges everywhere. Whenever you want to animate a sprite on A8, you need to copy over it's entire gfx data. On C64 you only need to change 1 byte to show the new data.

[analmux]

Making PMG's easy for a BASIC programmer to use probably would have exceeded an 8K ROM.

 

So that's why the LOGO cartridge was 16kB?

[atariksi]

Boulderdash is a "lossy" port. Anytime you lose something like colors, resolution, sound effects, timer resolution, etc. it's a lossy port.

>Then everything is a lossy port.

 

If an aspect like timing did not make a difference to the application, then it's not a lossy port. But colors do make a difference in this case. It's also true the other way going from C64 high-res to Atari res.

 

Okay, it is simple but an Atari coder would use and design according to what's available rather than try to get 24*21 sprites.

>So even the two 2600 sprites are as good as the 8 Atari 8-Bit sprites because a 2600 coder would do the same, right?

 

If the game only required 2 sprites and same resolution, it would be just as good. Seems Atari was after getting pac-man working so 5 player sprites was sufficient for them without tricks.

[atariksi]

Do the 1541, 1571 boot up or does one always have to write the LOAD "*',8,1 or something similar?

 

c64 has no auto boot up. a c128 does. you can use modern cartridges on c64 to do that, or hack a program on c128 which switches to c64 mode at some point. that approuch sounds extremely cool tho. no emulator, still having the real machine and controlling everything from the pc. wow maybe with 1541 ultimate (1541 emulating fpga with mmc, d64 images, and other goodies) the 64 arrived to the point that this can be done.

 

Okay, is there a link to the 'faulty' but working protocol that I use with LOAD that will work with all C64s/C128s? Speed is not important as once it loads, it will use it's own protocol. Is the VIC also compatible with C64 disk drives?

[Thomas Jentzsch]

If the game only required 2 sprites and same resolution, it would be just as good. Seems Atari was after getting pac-man working so 5 player sprites was sufficient for them without tricks.

Ok.

 

So the 8-Bit was as good as the C64 regarding Pac-Man and all games with less than 5 sprites. But that's not the question. And I am pretty sure there are way more (possible) games which require more than 5 sprites than those with 5 or less.

[vdub_bobby]

Just to kick in 2 cents here - when you are comparing gaming computers/consoles, it is fun to talk about the technical stuff but the proof is in the pudding: concrete examples (i.e., games/screenshots) should be given.