Atari v Commodore

[atariksi]

You can copy/paste if you have uploader on PC -> Atari set up w/CR conversion.

You can then do: ENTER "C:" as one option if doing cassette simulation; that will read in a text file.

Whatever I try I get "ERROR- 130" ?

 

Im using Atari800Win plus, Mydos disk image, even tried to use H1 as hard drive, used "makeAtr.exe" tool to extract or insert files on and of disk image...

I can not save basic file, I can not load file from disk....

What is the proper way to do it ? In small steps please...

 

I thought you were trying on real Atari so I was suggesting doing input via cassette input.

[NRV]

But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ?

Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do..

There's never any large copies, just updating new data at the edge of the screen as required..

I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP

But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges..

 

Two questions.. can you do those same techniques in an Atari? (and if you don't know, can you point to a webpage with info, or describe them a little ) and.. do you have a limit to the scroll speed that you can use with those techniques? something like "1 character per frame"? (or maybe you only need more setup time if you go over "that" limit)

 

thanx

 

NRV

[Jetboot Jack]

Demonstration can also mean just an experiment to show it working in a particular case so I treat "PROOF" as a more solid case.

 

So show me proof by your definition...

 

sTeVE

[atariksi]

Demonstration can also mean just an experiment to show it working in a particular case so I treat "PROOF" as a more solid case.

 

So show me proof by your definition...

 

sTeVE

 

And what atari feature exactly are you looking for proof which you think it's just an unsubstantiated claim?

[popmilo]

I thought you were trying on real Atari so I was suggesting doing input via cassette input.

Don't have TV in my computer room... yet!

[Heaven/TQA]

But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ?

Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do..

There's never any large copies, just updating new data at the edge of the screen as required..

I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP

But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges..

 

Two questions.. can you do those same techniques in an Atari? (and if you don't know, can you point to a webpage with info, or describe them a little ) and.. do you have a limit to the scroll speed that you can use with those techniques? something like "1 character per frame"? (or maybe you only need more setup time if you go over "that" limit)

 

thanx

 

NRV

 

why? you can do that by default.... no need to "cheat"... just setup 2 screens and you can do that or use the MWP technique to minimise ram usage...

[popmilo]

... people would have optimized toward its hardware and it would be harder to port to other machines at the time. But if you want to port C64 games and find it hard it port some things, it doesn't mean C64 is better machine.

Don't know about others, but I'm not only thinking about porting or comparing C64 games on Atari ...

Its more about possibilities for certain types of games...

 

For example, good game to port on Atari would be "Sentinel"... I wonder why nobody tried it so far... ?

 

Bad decision would be to try to port Ruff'n'tumble from Amiga to Atari... But I bet it could be ported to C64 beautifully...

 

You don't need to port Turrican from C64 to Atari...

Port Gameboy version... Yes maybe it works only in shades of grey, but its still damn good game...

 

IMHO Atari has many good features, but what it lacks is uniformity of them...

And those "Special cases" killed more than one project...

 

Yes C64 has those limits as three colors in 4x8 block, but - blocks are same all over screen....

Yes it has "only" 8 sprites, but - they are all same size!

 

Atari has this much of that sized players, and has this much more in different size, and 0 works with 1 and 2 works with 3 but 1 does not work with 2 or 3... And if you use those few as one then they use same color as one from rest of screen, and if charno is higher it changes color and if its over it and priorities are 0 then it changes color again, but not any change.. you have to do logical or between luminance1 and 2 and have to do logical or between hue1 and hue2 ....

 

Headache if you ask me ...

 

But Im not giving up!

At least those "features" are well explained and consistant...

Any deterministic system can be programmed to do what programmer wants as long as it is in its hardware capabilities...

 

p.s.Anyone for Sentinel like game for Atari ?

[Wrathchild]

p.s.Anyone for Sentinel like game for Atari ?

Work outstanding on remapping the screen drawing code needs to be resolved.

 

XXL, do you other implementations running under emulation code (e.g. spectrum)?

[Jetboot Jack]

And what atari feature exactly are you looking for proof which you think it's just an unsubstantiated claim?

 

Well...

 

So just replicate say P1 five times and update it's GRAFn register so you get 4*12+6 = 54 cycles at most (since you can registerize a couple of STA/STX/STYs prior to kernel. So you would have just P1 of size 160*248 and be able to enable/disable any 4*1 of P1. When enabled, you get the P1 color + the 2 ORed colors based on PF0/PF1. So you get a uniform 160*240*7 mode and have P0 and P2/P3/P4 still available with their own 4 colors.

 

OK - the above, I don't believe is possible in a real world game situation.

 

Replicating P1 5 times across the screen - not do-able, without slaving the CPU to the screen draw in such a way that virtually eliminates any CPU for game logic...

 

I am sure that superficially you believe such numerical twiddling, but having tried horizontal sprite multiplexing I found it near impossible to do...

 

sTeVE

[frogstar_robot]

OK - the above, I don't believe is possible in a real world game situation.

 

Rather than the oft quoted 23 colors per scanline, how many colors can be used without excessive developer pain? In non-GTIA modes, 5 can be gotten through naive use of the hardware and with slightly more informed use a different 5 can used on every scanline and those 5 can even be somewhat fine shades of one hue if desired....a true strength there. Like many, I believe 23 per to be a special case of limited practical use and it does the A8 community no good to continually assert that any ole game can utilize such color easily.

 

It is a help that the PMG can be different colors entirely from the playfield but using them to augment playfield graphics leaves less for moving objects. It is a valid but severe tradeoff.

 

It is a help that higher color GTIA modes can be used on alternate lines or frames but that is a set of tradeoffs that costs flicker and difficulty in planning a display.

 

If one does not use PMGs or flickering between frames/lines to enhance then what realistically can be done in the 160 and 320 modes? For that matter one can flicker two different pallettes but well...it flickers. Since games are brought up as a point against static pictures and mockups, it seems a valid question to me.

[Jetboot Jack]

Exactly...

 

These theories all sound exciting, if bits of them could be shown working you could color me impressed...

 

I think there is no instance where alternate lines of 160 then GTIA would look acceptable IMHO, but again I might be wrong, I just can't see it...

 

Another example is emkay's oft shown example game, tbh it looks far uglier than most games despite the fact it appears to use a bunch of techniques claimed to make an impressive visual.

 

sTeVE

Edited June 30, 2009 by Jetboot Jack

[andym00]

But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ?

Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do..

There's never any large copies, just updating new data at the edge of the screen as required..

I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP

But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges..

 

Two questions.. can you do those same techniques in an Atari? (and if you don't know, can you point to a webpage with info, or describe them a little ) and.. do you have a limit to the scroll speed that you can use with those techniques? something like "1 character per frame"? (or maybe you only need more setup time if you go over "that" limit)

 

thanx

 

NRV

 

There's no need for these techinques on the A8, you have them essentially built in..

 

You're limited only by how much new data you can get to the screen and colour memory, since double buffering doesn't help here..

Scrolling horizontally at 8 pixels a frame means copying in 200 bytes of Bitmap data, 25 bytes of character data (used for colour data in bitmap modes) and optionally 25 bytes of colour Ram if you're using multicolour bitmap mode..

So 250 bytes need to be copied for 8 pixels per frame..

Double that for 16 pixels a frame and so on and so on..

Vertically it's the same thing... 320 bytes of bitmap data 40 bytes of character memory, 40 bytes of colour memory..

So, 400 Bytes per frame when scrolling at 8 pixels a frame..

32 Pixels a frame would be manageable horizontally, and probably 24 vertically... And in combination in a freescroll, 16 pixels a frames is easily manageable in a real game scenario, probably more, but when was the last time we saw a game that was scrolling a those speeds..

 

Obviously if you do this in character modes, then you're data movement requirements are minimal, like (horizontall) 25+25 bytes and (vertically) 40+40 bytes per 8 pixels moved, so the world is your oyster.. It's still useful in character modes, because it saves on having to move the Vics on chip colour ram in one block which is without these techniques a pain because it means updating a whole 1K of colour ram data in one go otherwise, and that colour ram can't be double-buffered[1]..

 

For more reading, try this... But it's very code orientated..

http://codebase64.org/doku.php?id=base:vic

 

And for a full description of LineCrunch https://sh.scs-trc.net/vic/vic_article_3.14.htm#3.14.4.

And for a full Description of VSP (aka DMADelay) https://sh.scs-trc.net/vic/vic_article_3.14.htm#3.14.6.

In fact chapter 3.14 of the Vic Article explains most of the tricks the Vic can be made to perform..

 

[1] Well not unless you do clever tricks to fool Vic into producing 8x16 character cells by aborting every second Badline, and switching character sets to generate this mode, then you can use linecrunch to essentially swap between to colour ram buffers..

So you've created a 40x13 display composed of 8x16 character cells, with a double buffered colour RAM.. The only overhead is interupting every 16 scanlines, and aborting the badline there, but the cost reclaimed of not having half the bad lines more than makes up for this..

A very nice idea this indeed

Edited June 30, 2009 by andym00

[andym00]

...So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well..

I'm all for commodore but have to correct you

In every line where you use sprites VIC has to read pointer and sprite data...

So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins...

So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles...

It's not without cost

 

And as I know one line is 63 cycles long on PAL system ?

25 badlines = 25 * 21 (23 cpu cycles remaining per BL)..

175 normal lines = 175 * 63

112 blanked lines = 112 * 63

So we get 18606 cycles per frame..

 

But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution...

 

As Rybags stated in post #6443, it's not just cycles you have to look at but uniformity of it and being able to sync up to particular cycles and I would say exactness of them. I can play back a digitized audio file knowing DMA is pretty much uniform in graphics modes (no bad lines). So what happens when you play audio with bad lines on C64? What's the worst case latency? And then of course those sprites and color RAM don't always use up same number of cycles so writing kernels would be a much more difficult task. Atari CPU clock syncs up with video color burst.

 

PAL/NTSC have same number of CPU cycles/scanline on Atari so one version of kernel will work on both machines. And you can use sprites in replicate mode w/screen off and get 105 cycles/scanline (27510/frame NTSC or 32760/frame PAL) for applications that need the time.

 

Easily handled, but since we've less CPU power, this is more of a pain.. The easy way to handle the jitter is to point the NMIs directly at the CIA registers.. Set a counter that counts down from the desired cycle count, and when it triggers, (we've programmed the previous timer register to hold a jmp abs opcode) the NMI will jump to the correct routine based upon the cycle count.. You simply have 8 routines that are coded to each be 0 to 7 cycles of jitter..

This also means that we don't have to waste those cycles.. I mean that if the jitter is at least 4 cycles or more then we can ack the nmi.. So useful work is done instead of just burning cycles.. Clearly what work is app specific... So you're pointing the NMI vector directly at the hardware registers ) It's very evil, but a lovely solution..

By correct initial triggering of the timer, you have more than enough time to execute your sample playback even on a badline (which has 23 cycles left) as long as you align the initial interrupt point nicely.. Yeah, we burn some cycles, but it's a simple and easy way to handle the jitter..

 

But as for playing audio on badlines.. You just simply wouldn't.. I wouldn't dream of trying 15.6Khz playback on the c64 in a games (without a cycle fixed kernel).. 7.8Khz no problem, you just make sure you don't interrupt on badlines when you fire up the interrupt

 

But you're right.. The sprites are a pain when it comes to handling cycle exact stuff, especially a badline with all 8 sprites enabled.. But you work around that in whatever you're building.. And the benefits of them more than outweigh the downsides.. If you really must, you can always stretch (not multiplex!) the sprites down the screen completely to ensure consistent timing, and then through judicious use of sprite pointers change the sprite pointer to change data in a line by line basis, so even if the sprite wasn't displayed, you'd still be setting it to empty sprite data.. But this is exploiting more bugs in Vic so it probably doesn't count in your books since it's not a 'hardware' feature

 

Or another way, in your multiplexor, just ensure that unused sprites are re-enabled immediately with an empty pattern, a little more work for the plexor (and adds a few minor potential restrictions), but then you have absolutely uniform cycle availability over the displayed frame..

 

But we're way outside of typical game scenarios here and firmly into demo land now with sprite stretching..

 

But in answer to your question the handling of interrupt jitter is a no brainer really..

Edited June 30, 2009 by andym00

[oky2000]

But you're right.. The sprites are a pain when it comes to handling cycle exact stuff, especially a badline with all 8 sprites enabled.. But you work around that in whatever you're building.. And the benefits of them more than outweigh the downsides.. If you really must, you can always stretch (not multiplex!) the sprites down the screen completely to ensure consistent timing, and then through judicious use of sprite pointers change the sprite pointer to change data in a line by line basis, so even if the sprite wasn't displayed, you'd still be setting it to empty sprite data.. But this is exploiting more bugs in Vic so it probably doesn't count in your books since it's not a 'hardware' feature

 

Bugs are used on both sides quite a lot nowadays, and if the A8 programmers used no tricks/hacks/bugs then their games would look like 4 colours total on screen 1982 crap that we had to endure on the C64 due to programmer ignorance

[Rybags]

PMSL.

 

It's funny how the C= guys hassle the Atari for the couple of things that have to be done in a complex way, but with the C-64, it comes down to fiddly time critical stuff just to perform simple functions like changing the screen base at byte granularity.

 

What puzzles me is - what happens when you're doing this V-Scrolling with a wraparound screen that starts 200 bytes later than normal? Aren't you going to have the Sprite Data Pointers appearing onscreen... so you've got the problem where you can only have one thing or the other.

[andym00]

PMSL.

 

It's funny how the C= guys hassle the Atari for the couple of things that have to be done in a complex way, but with the C-64, it comes down to fiddly time critical stuff just to perform simple functions like changing the screen base at byte granularity.

 

What puzzles me is - what happens when you're doing this V-Scrolling with a wraparound screen that starts 200 bytes later than normal? Aren't you going to have the Sprite Data Pointers appearing onscreen... so you've got the problem where you can only have one thing or the other.

I don't think we're hassling you over this, I'm just finding it mind meltingly complex to envision the idea of splitting sprites horizontally (edit: as Jetboot Jack seems to think also (sorry I got you two confused there for a minute)) in the context of a game and this 23 colour overlay mind-melt mode.. That's something I really wouldn't want to get into.. And if there was anyway we could re-use sprites horizontally of the 64 I'm sure it would have been used already, unfortunately we can't because once the sprite graphics shift registers have emptied there's no way to reload them until the next normal sprite DMA takes place, which is a bit of a bummer.. Timing on the 64 is more of a pain since we have no lovely WSYNC, but with the CIA timing method mentioned before, it's not really so much of a problem, or in fact with any of the multitude ways of obtaining stable timing.. I just happen to like the elegance of the CIA method personally

 

As for the sprite pointers being shifted into the visible screen there's two ways to deal with it.. Some games just design the levels around that, and ensure they're not visible in the level (either via colour ram if in char mode or bitmap data if in bitmap mode), but another way is to have a another character screen that holds the correct sprite pointers, and then swap banks over the single line where the sprite fetches would be otherwise be wrong.. There's only exactly one line on screen where this needs to be done, so it's not exactly a show-stopper in anyway at all..

Edited June 30, 2009 by andym00

[Rybags]

One line? I had the impression that the Sprite Data Pointer was fetched whenever a sprite was about to be displayed... otherwise reuse would be kind not so useful because you'd get the same sprite design. And, that would mean multiple instances since you don't typically have them all starting on the same line.

[andym00]

One line? I had the impression that the Sprite Data Pointer was fetched whenever a sprite was about to be displayed... otherwise reuse would be kind not so useful because you'd get the same sprite design. And, that would mean multiple instances since you don't typically have them all starting on the same line.

 

During the frame you let the incorrect character data exist and use them as sprite pointers.. One the single raster line where VIC would fetch incorrect character data (on the raster line where the sprite pointers are in the character screen) we momentarily switch to the other screen which has correct character data, then switch back to the one with the correct sprite data.. There's only a character fetch every 8 lines, the badline.. The character fetch is made, and buffered internally in VIC until the next badline condition, where upon it fetches again..

Sprite data is reloaded via the sprite DMA, beginning the right hand side of the screen, if sprite DMA is enabled, which is started if the sprites y position matches the raster line.. And starts shifting out once the x-position matches.. It can't be switched off until the sprites internal data address is equal to 63, the normal termination condition.. Through voodoo you can break the address mechanism and make it add only 1 or 2 on a sprite line (instead of the normal 3), hence getting sprites that are taller than normal..

[frogstar_robot]

Exactly...

 

I think there is no instance where alternate lines of 160 then GTIA would look acceptable IMHO, but again I might be wrong, I just can't see it...

 

It doesn't have to be GTIA though. Once can just alternate 160 with two different palettes. If the additional palette isn't too different from the first then the flicker is hardly noticeable. That isn't as useless as it sounds as it does allow finer shading. If doing a background that is mostly reds then think additional shades of red to accentuate detail with maybe even a touch of orange here and there. Throw blues or greens into that mix then the flickery jig is up though even there it is tolerable on small areas of a picture especially for things like stars and water. Though I don't mind super obvious flicker in demos, it is probably best for games to resort to it with judicious care.

[Jetboot Jack]

If the additional palette isn't too different from the first then the flicker is hardly noticeable.

 

I'd rather have a way to deploy more solid useable colors useable across more of the screen - flickering can work (look at Space Harrier) - but I cannot imagine a scrolling Platformer like that for instance (like Mayhem or Mario)

 

sTeVE

[emkay]

Another example is emkay's oft shown example game, tbh it looks far uglier than most games despite the fact it appears to use a bunch of techniques claimed to make an impressive visual.

 

 

Sometimes I cannot believe that you're anyhow involved into computergraphics development.

 

In fact : I looks impressive by the used techniques, compared to 99% of all Atari software.

The main spot was to put as many informations as needed for the game into one screen. Actually, til today, still no other game exists that does some graphical presentation beside the game itself...

 

 

 

May I introduce other games with a similar game rule?

 

 

 

 

 

I guess they fit more to your taste.

[Irgendwer]

p.s.Anyone for Sentinel like game for Atari ?

Work outstanding on remapping the screen drawing code needs to be resolved.

 

You proceed with the translation? Unfortunately I wasn't able to something useful with the code in the meantime.

Could you give me an update?

 

CU

Irgendwer

[Jetboot Jack]

Sometimes I cannot believe that you're anyhow involved into computergraphics development.

 

I guess that is the difference, I have been involved in games development for over 20 years - rather than sitting on the sidelines criticizing...

 

 

 

In fact : I looks impressive by the used techniques, compared to 99% of all Atari software.

 

And yes I reckon my assessment (whilst only my opinion) is pretty accurate. I don't doubt it's technical merit, just the visual experience it has created - I don't find it pleasing...

 

In fact other simpler screen design creates more coherent visuals....

Edited June 30, 2009 by Jetboot Jack

[emkay]

Sometimes I cannot believe that you're anyhow involved into computergraphics development.

 

I guess that is the difference, I have been involved in games development for over 20 years - rather than sitting on the sidelines criticizing...

 

 

Blablabla....

What do you think who has it easier to drink some water? A Fish or a Camel?

I tell you

While a Camel can hold water in the desert for a longer timespan, the fish only has to open his mouth for drinking Water the whole day.

 

In fact : I looks impressive by the used techniques, compared to 99% of all Atari software.

 

And yes I reckon my assessment (whilst only my opinion) is pretty accurate. I don't doubt it's technical merit, just the visual experience it has created - I don't find it pleasing...

 

In fact other simpler screen design creates more coherent visuals....

 

Well, sometimes I know why the Atari was lost...

[Heaven/TQA]

One line? I had the impression that the Sprite Data Pointer was fetched whenever a sprite was about to be displayed... otherwise reuse would be kind not so useful because you'd get the same sprite design. And, that would mean multiple instances since you don't typically have them all starting on the same line.

 

During the frame you let the incorrect character data exist and use them as sprite pointers.. One the single raster line where VIC would fetch incorrect character data (on the raster line where the sprite pointers are in the character screen) we momentarily switch to the other screen which has correct character data, then switch back to the one with the correct sprite data.. There's only a character fetch every 8 lines, the badline.. The character fetch is made, and buffered internally in VIC until the next badline condition, where upon it fetches again..

Sprite data is reloaded via the sprite DMA, beginning the right hand side of the screen, if sprite DMA is enabled, which is started if the sprites y position matches the raster line.. And starts shifting out once the x-position matches.. It can't be switched off until the sprites internal data address is equal to 63, the normal termination condition.. Through voodoo you can break the address mechanism and make it add only 1 or 2 on a sprite line (instead of the normal 3), hence getting sprites that are taller than normal..

 

aehm... and that's more easy compared to atari hardware???