Atari v Commodore

[atariksi]

So the above code won't cause any bad lines? I think I used to set up writing to $D011 and $d016 but can't remember right now, but it did cause bad line (40+ consecutive DMA cycles).

All standard gfx modes on C64 cause badlines. Avoiding badlines is possible but is only used for a number of demo effects. I've never seen a game without badlines.

 

Not monochrome, but they chose the shade instead of the color meaning shade must be the better choice.

If there is only one chroma used for all 4 colors, it's monochrome.

 

I would need to avoid bad-lines at all costs as audio is more significant than getting more colors on the screen. So perhaps, writing to scroll register $D011?

[Lazarus]

I would need to avoid bad-lines at all costs as audio is more significant than getting more colors on the screen. So perhaps, writing to scroll register $D011?

Audio on C64 is done by calling a player routine once a frame (or in some cases: 2 or 4 times a frame). The rest is done by the SID, and SID is not interrupted by badlines.

 

There's no deficiency-- it's more to do with a different approach and RAM contraints. You don't need 24*21 sprites to do good games.

But it helps.

Edited September 12, 2009 by Lazarus

[atariksi]

I would need to avoid bad-lines at all costs as audio is more significant than getting more colors on the screen. So perhaps, writing to scroll register $D011?

Audio on C64 is done by calling a player routine once a frame (or in some cases: 2 or 4 times a frame). The rest is done by the SID, and SID is not interrupted by badlines.

 

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

[Lazarus]

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

It can always be resampled. But I'd suggest you simply set up a 11 kHz timer IRQ and live with the badline jitter.

[atariksi]

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

It can always be resampled. But I'd suggest you simply set up a 11 kHz timer IRQ and live with the badline jitter.

 

Resampling introduces distortions and won't sound like it does on PC for sure (since frequency and bit depth is distorted). I already tried playing with 40+ consecutive DMA cycle latency and it's too much of a loss in quality not just some jitter of a few cycles. You should try resampling 11Khz to 7.9Khz and see what it sounds like. Integer divisors work okay.

[TMR]

In the case of Draconus the A8 colours are inaccurate, the C64 was the original version.

 

You can have inaccurate colors and be the original.

 

Well, it's a matter of semantics, but since the game was designed by C64 bunnies those colours are accurate since that's what they chose to make them. Unless you're arguing somehow that they're inaccurate to real world objects, these are 8-bit computers running a fantasy-based game, in that world the colours are right. =-)

 

Any partial or full screen scrolling algorithm should be faster on A8.

 

It's swings and roundabouts (getting a new column of data ready with full screen scrolling is 24 bytes of data on the C64 and 192 if you're using a bitmap on the A8 and if you're matching scroll speeds like Zybex is you're dropping every other frame on the A8 as well which looks slower), the scrolling isn't the issue but the software sprites and the extra calculations required to work around wrap-based scrolling (does it have an official name...?) and multiple LMS lines - speaking of which i was thinking about Zybex some more, it has to be using two LMS lines, the play area is 86 pixels high. i've been thinking about a 128 by 80 pixel play area just using one LMS and trying to get my soft sprite routine going as fast as possible into it... maybe i should write a shoot 'em up just to see if i can draw graphics at that res!

[TMR]

More likely they would sell fewer atari versions therefore less effort. Lazy programming or low budget.

 

No, that's actually a huge amount of effort and probably more than a "dirty" port would've taken; the sprites and backgrounds have all been redrawn to allow for the change in resolution (i'd have to check but i'm pretty sure they didn't just remove every other byte of each character), the map data for all the screens would need redesigning to allow for the change in character ratios (it's not as simple as it might appear, again i've been thinking about it) and despite what some people say a decent software sprite routine is always a bugger to do and both Draconus and Zybex fare quite well on that front all things considered.

sorry I must disagree, look at some of the great stuff written for appleII series. Now that is a POS from a graphics point of view and yet the effort was put into it. So again I say the effort put into it was probably less as by that time in history they expected to sell fewer copies of that version. Not saying it is easy but enough money and time most things can be done.

 

Zybex does 86 scanlines of bitmap scrolling and a significant number of software sprites over the top (especially when there are two players on the go with charged weapons) and there aren't many full-pricers on the A8 claiming similar specifications to that. Seriously, try coding it if you don't believe me because the more i think about it the more impressed i am by what it's doing; it might just be a budget shoot 'em up, but you Atarians are seriously selling it short y'know...

 

Also my experience in my store with customers was that if they knew it was a port from c64 they would not buy the product. I would end up stock balancing the game.

 

That's a slightly odd thing for them to do... a lot of C64 users didn't like the practise of porting Spectrum graphics that a few firms got into for a while (the term "Speccy port" was an insult) but they'd at least try the games themselves rather than writing them off arbitarily.

[emkay]

If you're doing two LMS commands and changing the address to handle coarse scrolling, it's a far more complex thing to process in software sprites or columns of arriving data than you seem to reckon, for a start you need to leave a gap between the two halves of the screen so there's "travel distance", so for example the first byte line 81 of the bitmap doesn't follow directly from the last byte of line 80; that means all the software sprite plots and column writes need to "step over" the gap and you're either constantly checking for exceptions or using tables containing the address of each bitmap line which in turn need to be constantly "nudged" whenever the LMS changes.

 

 

Not sure of what complex programming routines you write.

LMS is only limited to 4k due to the AMTIC limit there. So you just have to add a second LMS for a bitmap screen, to gain up to 8k. For a scrolling screen with 48 bytes width, you need a 3rd LMS when using more than 170 lines for the gamescreen.

The LMS commands can be set to result in a fully linear frame buffer for the screen. Why should there be a gap between both of the LMS parts?

Edited September 12, 2009 by emkay

[emkay]

Zybex does 86 scanlines of bitmap scrolling and a significant number of software sprites over the top (especially when there are two players on the go with charged weapons) and there aren't many full-pricers on the A8 claiming similar specifications to that. Seriously, try coding it if you don't believe me because the more i think about it the more impressed i am by what it's doing; it might just be a budget shoot 'em up, but you Atarians are seriously selling it short y'know...

Using double scanline mode is a solution to save a lot CPU powers and to have a lot of moving objects on the screen. The Atari could do the game in a higher resolution for sure, but that is not the point that was throwing game parts into a garbage can.

50% of the game logic is not working due to the fact that scrolling and object movement has the same horizontal speed.

Edited September 12, 2009 by emkay

[Heaven/TQA]

you could use the Analmux MWP technique but I would first use LMS "gameboy style"... maybe would vote for 128 bytes scanlines? does it simplify calculations?

[andym00]

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

 

It's not realistically going to happen on the 64.. The 11Khz just sits badly against the badlines that occur.. And there's nothing you can do about that unless you want to get really messy You can abort the badlines, which means in text mode that you'll have the same character line and colour ram repeated down the screen, which isn't so useful since you run of out character sets very quickly.. In bitmap mode, it's a bit different, you can abort the DMA on each bad line, and the graphics fetches still take place, just no new colour fetches, so you end up with a 320x200 or 160x200 with no badlines, just in interrupts every 8 lines to abort the DMA.. You can have more colours, since you can allow a one off fetch of colour data, which is then held for every line of the screen, so in bitmap mode, you could have a vertical scrolling game with nice colour graduations going our horizontally, and still no bad lines.. This really isn't used very often and it's a royal bugger to setup

 

Practically, 7.8Khz is your limit.. The 64s CPU is just to slow to go to 15.6Khz using IRQs and having the screen on, *AND* having zero cycle jitter on the interrupt.. We have only 23 spare cycles on a bad line, which just doesn't cut it.. and the interrupt overhead is too much for a 1Mhz processor.. 7 cycles to enter, 6 cycles to preserve a register, then 9 to ACK + RTI from the interrupt (assuming your using the jmp $DD0C[1].. That's not including the jitter from the previous instruction, so add another possible 7 onto that, and we've got a minimum of 29 cycles, and that's before we've done anything.. There's just no practical way to deliver 15.6Khz audio on the 64, we just don't have the cycles for it.. And if you want to go for 8bit playback you can stick an extra 24 cycles onto each sample outputted, 30cycles if you go for 12bit playback, though the crappy 4bit volume stuff is of course only 4 cycles..

 

One option to do it though, is to have the sample playback in 8 line kernel chunks[3], but then you burn too much CPU time, and then you'll have to do whatever computation you need in the IRQs to make up for raping the CPU like that.. And the interrupt code on the last line to get the sample out, and to bail from the irq is critical to how much time you get left with because there's a big angry bad-line coming for your arse just cycles away.. But then you could squeeze 15.6Khz out of it, but (if I remember rightly the last time I tried this) I ended up with 12 (maybe 11) spare cycles per 8 lines of display, which isn't particularly useful to do anything with.. Lol, 468 cycles per frame left, enough to run a very minimal music driver for the task in question but fecking useless for anything else..

 

I know I've just handed a nice arsenal of ammunition to the hostiles, but that's life, and we all know we've got a crappy CPU on the 64, that's what actually makes life fun in some ways.. Already in the short few days that I've been playing on the A8, I'm feeling like I've got more CPU power than I know what to do with[4]

 

So there you go.. 11Khz (which to be fair doesn't sit nicely on the A8 either), just shouldn't be done, unless you switch the screen off.. There's far to much jitter you'll be fighting against.. 3.9Khz, 7.8Khz, 15.6Khz are your best options... And doing the bad line aborts[2], with samples playing (at non-scanline ratios) I don't think has even been done before, so maybe you'll be the first

 

Another option is to disable screen DMA completely, and put the VIC into a state whereby it will only display sprites[5], then there's no badlines, and what you want is doable, but again the sprite DMA will cause jitter with you 11Khz desire, but with 15.6Khz it's very doable, especially if you fill the screen with sprites since it'll provide you with the interrupt stabilisation source you need through the 19cycle sprite dma block..

 

[1] You place the RTI instruction into the serial shift register on the CIA, then jump to it to exit the interrupt, and due to 6502 behaviour it will hit the ack register after the RTI instruction which saves 1 cycle

[2] Though thinking about it now, I've a vague memory of a way to do this in a one off fashion without using stacks of IRQs, hmmmm, should go check, though maybe it's my addled memory letting me down.. I'm sure one of the demo gods will correct me on this

[3] The added benefit of this is that you use the end of the previous bad-line dma to stabilise your interrupt perfectly, since you set the timer to occur during the badline period, the cpu will be perfectly aligned and the interrupt start the cycle dma finishes, which saves a few cycles on stabilising your interrupt.. This can also be down with using the sprite dma period as well..

[4] And I've started to keep a diary of my real-world observations of programming the A8 versus C64, the pros & cons of both, from a programmers point of view, which I'll put somewhere sometime

[5] Only one interrupt per frame with a lot of leeway in terms of scanlines so it can be disturbed by audio interrupts with no problems, but it *HAS* to be done each frame once you've started the process otherwise VIC will vanish up it's own arse and shutdown totally until you reset the machine..

Edited September 12, 2009 by andym00

[Rockford]

 

 

Hm...

This time I have to stand on the point that ingame draconus on the A8 looks better. The color usage of the C64 version turns the neck of a frog 360°

 

Title of the C64 is clearly better.

 

I don't think so. As for C64 version a Zzzap 64 reviewer described it perfectly.

"Beautifully animated sprites complement the subtle use of shading and colour throughout"

 

Alternatively, it may look like on Atari.

 

A beautiful vivid purple that burns your eyes. I'd rather stay with the C64 colour scheme

Edited September 12, 2009 by Rockford

[Rockford]

13 - Trolls and Tribulations

 

C64

C64

C64

 

The C64 version has more colours, better sound/music and scrolling. The Atari version doesn't have any music and the colours are awful (dirty reddish). The scrolling on Atari is so horrible that makes your eyes hurt. C64 does it much better

 

ATARI

ATARI

ATARI

[andym00]

ATARI

ATARI

ATARI

 

Stone the crows... Whoever let that ship should be damned for all eternity.. How on earth does a game ship with sprites like that ???

 

edit: And for the potential comedians I meant the Atari sprites

Edited September 12, 2009 by andym00

[emkay]

 

A beautiful vivid purple that burns your eyes. I'd rather stay with the C64 colour scheme

 

Matter of taste.

[popmilo]

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

It can always be resampled. But I'd suggest you simply set up a 11 kHz timer IRQ and live with the badline jitter.

 

Resampling introduces distortions and won't sound like it does on PC for sure (since frequency and bit depth is distorted). I already tried playing with 40+ consecutive DMA cycle latency and it's too much of a loss in quality not just some jitter of a few cycles. You should try resampling 11Khz to 7.9Khz and see what it sounds like. Integer divisors work okay.

My professor at colege tought me to try to do it properly, and if it is not possible then cheat!

So I have two possible solutions for you

 

1. Proper method:

Use C64 routines discovered last year...

Example:

 

Easiest would be to make it play at 7.9KHz (It can be resampled... anything can be resampled...)

If not then we should try to make it play at 11KHz using sort of kernel routine ...

Badline Jitter doesn't influence sound much because technics involved are not simple "Put sample value in volume register every X microseconds...".

Sample values get "antialiased" and filters remove high pitch carrier...

 

2. Cheating

C64 has Audio in pin on Audio/video connector !

(A8 does not have one ? Does it count as C64 adventage ? )

 

Take the sound from PC directly to c64 and let it play it on TV

 

-----------------------------------------------------

Maybe you should open new topic about this with more details about it ?

I would love to help, and others would probably have some ideas...

[STE'86]

PLEASE stop posting screenshots of games from "www.shitc64andatarigames.com"

 

if u cant post something decent just give it up.

 

i think most of us have no real enthusiasm for comparing an abortion of a 64 game with an even bigger abortion of an atari one (or vice versa)

 

Steve

[popmilo]

@Atariksi:

Correct me, but do you do something else while playing samples and displaying pictures ?

Are you grabing sound and image info from data streamed on serial port ?

How much data is it and how does it work ?

That would make it even more difficult on C64...

[popmilo]

PLEASE stop posting screenshots of games from "www.shitc64andatarigames.com"

 

if u cant post something decent just give it up.

 

i think most of us have no real enthusiasm for comparing an abortion of a 64 game with an even bigger abortion of an atari one (or vice versa)

 

Steve

Problem is that he can not find any of the good c64 games on a8, to compare with

[oky2000]

I think seriously the point is that there simply wasn't enough exceptional coders to replicate C64 standard hardware features using the more restrictive colour resolution of 160x192 displays and the smaller more restrictive PM graphics.

...

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8. 160*192 is restrictive if you don't learn how the rest of the hardware works.

 

But that is how you get 4 colours per 4x8 char block and then any colour within the Sprite system on top of that, which clearly produces some very colourful 16 colour games on the C64 as opposed to 4-7 colour games on the A8.

 

In the case of the A8 the majority of games look as you would expect of a machine that can do 4 colours total + basic horizontal colour graduations via DLIs. The problem simply is that there was no 3rd or 4th generation of games programmed for the A8 because the restrictions the hardware placed were very difficult to break and even then could only be used in certain situations etc.

 

No, the color changes are not limited to horizontal color graduations. GPRIOR mode 0 doesn't care if it's horizontal or vertical and GTIA modes allow vertical and horizontal color graduations. Most games did not use GTIA modes and even without resolution enhancement, the moving sprites would still be at 160*200 on GTIA graphics.

 

For fast action games you can't waste PM on colour underlays or start sapping CPU time just to equalize a deficiency in the hardware to try and replicate the more colourful look of a 16 colour on screen C64 game.

 

My problem is not with the movement resolution of the PMs, just the overall smaller size than the 24x21 x8 per scanline system in VIC-II plus the ability to mix sprite modes so you can have a hires sprite overlay and the colour for the character with an underlying sprite underneath. If you can get this into you multiplexing routine it provides sprite graphics as detailed as a Nintendo game in some ways.

 

Mixing modes and having any of the 16 colours within some basic restrictions gives you quite a lot of flexibility, the A8 Last Ninja project highlights these difficulties really that need to be worked around whereas on the C64 it's all down to an artists drawing ability and not much technical trickery to achieve the lush graphics of that game

 

However doing something like Rainbow Islands as well on the A8 as the C64 version would be difficult to say the least, simply a sign of the times.....the C64 chipset was designed for use as an arcade motherboard first and foremost and these game styles were the ones that lasted all the way up to Virtua Racer by SEGA with just bigger bobs/sprites more colours and faster movement...same basic game design though.

I believe arcade motherboards were superior at the time to what the C64 chipset had to offer.

 

The cost effective chipset was designed for Jack Tramiel by MOS in 1980-81 so in some cases I would beg to differ, plus there is an excellent versions of some of those early arcade games too like Rabbit Software's Skramble (different to Rockford's linked Skramble) and Ocean's Donkey Kong. Both damned close all things considered. You have to remember the R&D investment and changes in arcade chipsets could be measured on a monthly basis not yearly or half a decade like with Atari/Commodore home computers. What Jack was going for was similar to Nintendo's re-usable Playchoice 10 arcade board...profit <> cutting edge expensive monthly chipset designs.

maybe,but in 80-81 Atari ruled the arcades,it would have had little to no chance. Though the thought of commodore as a game system instead of atari seems kind of funny,like as in the companies changing places in the perception of the public. That would have been interesting.

 

Atari arcade chipsets had nothing to do with the limitations (PM graphics size/vertical unique colour resolution on screen) of the A8 chipset. Atari/Namco did make some good arcade games for sure...one of my all time favourite games Gauntlet is Atari after all

[Bryan]

2. Cheating

C64 has Audio in pin on Audio/video connector !

(A8 does not have one ? Does it count as C64 adventage ? )

 

Atari has audio-in for SIO devices. The Atari tape drive has a stereo head can play audio from one track while loading from the other.

[atarian63]

Also my experience in my store with customers was that if they knew it was a port from c64 they would not buy the product. I would end up stock balancing the game.

Strange attitude. On C64 people never cared if it was an Atari port or not. That's why some of the most popular C64 games are ports from Atari: Boulder Dash, Bruce Lee, Moon Patrol etc.

Yeah, I would like to have sold the stuff and made the money,however the customer vote with his $$$ and I suppose was punishing the vendor for doing a bad job. Probably also was with those early atari to c64 ports software quality was still on the rise for c64. By the time that there were c64 to atari ports atari games had already seen better quality and people wouldnt accept sub standard games from the c64 ports. What games I saw during that time could have been lots better had they been written for the machine and not a port.

[atarian63]

More likely they would sell fewer atari versions therefore less effort. Lazy programming or low budget.

 

No, that's actually a huge amount of effort and probably more than a "dirty" port would've taken; the sprites and backgrounds have all been redrawn to allow for the change in resolution (i'd have to check but i'm pretty sure they didn't just remove every other byte of each character), the map data for all the screens would need redesigning to allow for the change in character ratios (it's not as simple as it might appear, again i've been thinking about it) and despite what some people say a decent software sprite routine is always a bugger to do and both Draconus and Zybex fare quite well on that front all things considered.

sorry I must disagree, look at some of the great stuff written for appleII series. Now that is a POS from a graphics point of view and yet the effort was put into it. So again I say the effort put into it was probably less as by that time in history they expected to sell fewer copies of that version. Not saying it is easy but enough money and time most things can be done.

 

Zybex does 86 scanlines of bitmap scrolling and a significant number of software sprites over the top (especially when there are two players on the go with charged weapons) and there aren't many full-pricers on the A8 claiming similar specifications to that. Seriously, try coding it if you don't believe me because the more i think about it the more impressed i am by what it's doing; it might just be a budget shoot 'em up, but you Atarians are seriously selling it short y'know...

 

Also my experience in my store with customers was that if they knew it was a port from c64 they would not buy the product. I would end up stock balancing the game.

 

That's a slightly odd thing for them to do... a lot of C64 users didn't like the practise of porting Spectrum graphics that a few firms got into for a while (the term "Speccy port" was an insult) but they'd at least try the games themselves rather than writing them off arbitarily.

not everyone did,some people bought, but it was hard to make the sale after years of "A" grade software them on "c" grade software being available. Good titles still sold but by 86/87 they were rare and least at the retail level. Even a decent title in cheap packaging would not sell well. People were willing to spend the money,but companies like EA shut stopped writing. Very sad.

[atarian63]

13 - Trolls and Tribulations

 

C64

C64

C64

 

The C64 version has more colours, better sound/music and scrolling. The Atari version doesn't have any music and the colours are awful (dirty reddish). The scrolling on Atari is so horrible that makes your eyes hurt. C64 does it much better

 

ATARI

ATARI

ATARI

all titles written after 1985, atari dev pretty much stopped after 85,compare title from 83/84 and you will see it the other way round.

Again poor programming on the atari version.

[carmel_andrews]

All this talk of Zybex and Draconus....I did'nt realize that either Brian Jobling or Kevin Franklin had Joined these boards