Any routine using Voxels on Atari ?

[Any routine using Voxels on Atari ?]

I recall there being some space game on the 8bit using some clever voxel(esque) technology...

I don't remember its name at all now, or even it it was ever shipped or if I found it on some prototypes site, but it reminded me of something like Zaxxon, but flying into the screen.. Quite blocky, and in grey scales if I recall correctly..

A quick google hasn't turned up anything, but I'll have another hunt again in a bit, I could do with seeing this again myself

I really can't remember the name at all, but someone will remember it I'm sure..

I did look chuffing good though...

Not voxels as such, but it's the closest thing I can think of...

[New game port on the way - Gr......er]

well, I'm back from my trip earlier than expected so I'll get back on to the title screen tonight.

 

The colours are dark again on that WIP! I'll have to lighten them again on the final pic. You can hardly see the green grid lines at all. I must stop messing with the G2F palette.

 

Here's closer to how it will look......

 

Great job on that, I think that looks absolutely fecking ace )

[Atari v Commodore]

What is the connection between all this 6502 talk and Atari v Commodore ?

 

I used a 6502 from Commodore 1541 drive to fix a Atari 400 machine. I increased value of C1541 drive.

 

Nope, you increased the value of the A400

[Atari v Commodore]

What is the connection between all this 6502 talk and Atari v Commodore ?

Nothing what so ever, apart from watching atariski throw internet cliches (the chewbacca defence, the straw man argument and when all else fails the fanboy suckerpunch) around as he drowns..

It's a popcorn movie, enjoy

[Last Ninja - the making]

Weird, I thought the Olliveti version would be just the CGA DOS version.. But apparently not..

edit:OOps, just saw Jose's post up above..

 

Didn't CGA give you a choice of two different (yet equally garish and pathetic looking) CGA screen modes on all PCs?

 

Yes, and those 2 pictures above are your 2 palettes Well there's 2 different intensity palettes available as well..

Palette 0

default background

2 — green

4 — red

6 — brown

 

Palette 0 in high intensity

default background

10 — light green

12 — light red

14 — yellow

 

Palette 1

default background

3 — cyan

5 — magenta

7 — white

 

Palette 1 in high intensity

default background

11 — light cyan

13 — light magenta

15 — white (high intensity)

 

There was a 3rd palette available as well, achieved by disabling the colour burst as well.. But only showed in colour on RGB monitors, Composite monitors saw it in greyscale as you would expect..

Palette 3

default background

3 — cyan

4 — red

7 — white

 

Palette 3 in high intensity

default background

11 — light cyan

12 — light red

15 — white (high intensity)

 

It was possible to swap palettes during the frame.. Not used very often sadly on PC games, but easily achieved with the timers, but California Games used this to good effect and it really doesn't look so bad as you might expect.. Well, almost anyway..

 

There's also the lovely 160x102 mode as well (created by setting character height to 2 lines then filling the screen with a character the showed background on the left, and foreground on the right), where all colours can be used freely by just updating the attributes..

If you were lucky enough to play games on your CGA card on a composite monitor your eyes usually suffered less than those on their RGBi monitors

 

See the below comparison of the difference you might enjoy

What you might see on an RGBi monitor (left hand side) Vs. what you'd see on a composite monitor (right hand side)..

 

In the both the shots above, you can very clearly see where the palette switching is taking place..

 

Anyway, so so so so so very far off topic right now

[Last Ninja - the making]

Weird, I thought the Olliveti version would be just the CGA DOS version.. But apparently not..

edit:OOps, just saw Jose's post up above..

[Atari v Commodore]

I believe the Apple IIc used the 65C02 (cmos). That's a lot of "C"s

And the Enhanced IIe used it as well..

[Last Ninja - the making]

Don't worry too much about copying hires sprites of the C64 version, other colour machines made do with 160x200 Ninja graphic like the Amstrad CPC

 

That looks remarkably like the PC version I think, it just smells of EGA colours

It's not certainly not an Amstrad, which looks like this unfortunately..

And I don't think there were any other 160 resolution versions, only the C64..

 

edit: Oops, it appears there was an Apple II version, but looks atrocious!

[Ghost'n'Goblins map]

I'd never seen those sites before.. Nice one, thanks

[Atari v Commodore]

The real son of 64 would have been the C65, which was probably too little too late...[snip]

 

I don't know how it could be "too little, too late" when it was just vaporware. I'd characterize "too little, too late" as developments that made it to marketplace yet were ultimately not as successful as hoped. Perhaps the C128? Perhaps Apple IIgs? Perhaps Atari's 32-bit efforts? I don't see how vaporware can be considered anything but.

 

I said it would probably have been too little too late.. Primarily due to being perceived as a poor mans Amiga, given it's slated price of 200UKP when the Amiga was still going for 400UKP at the time.. Though who knows for sure...

Either way, it's not important...

[Ghost'n'Goblins map]

Is there any chance of posting those ?

I'm investigating doing a port of a game to the 64, but redone completely in hi-res bitmap mode with sprite overlays and underlays, partly fuelled by this whole discussion in the other thread, and I think Ghosts'n'Goblins could be interesting..

SNES maps would be even betters And then looking at trying some similar on other beginning with the letter A.. Okay, I'm not going to manage 320 resolution except maybe on the 7800, but I'm game

So far I've investigated R-Type as an option, and it's looking very very viable to remake the entire thing in 320x200x16 colours utilising every trick in the book

 

Ah.. I've just found the SNES Super Ghouls and Ghosts on vgmaps, but I'd still love it if you could share the NES G'n'G map

[Atari v Commodore]

Apparently, it isn't.

 

About the only similarity between C64 and ST is the 8 MHz pixel clock, and the joystick ports which are recognised as Atari types anyway.

 

Completely agree with you on that, I can't think of anything else they have in common, apart from RF ports (one some models)

 

But as came up earlier, the 64 does have it's own heritage.. Pet, Vic, Max/Ultimax/VC-10), C64, C128, CBM B Series etc..

 

The real son of 64 would have been the C65, which was probably too little too late (especially in regards to a 4Mhz 4510[1] (based on the 65ec02) cutting it in 1991), but you never know.. Again this machine had a lot of graphics hardware (VIC-III) to back it up.. Good graphics modes, good colors, a dma controller that functioned as a simple blitter, dual SIDs.. Plus it's dual data busses meant parallel data access by CPU and VIC with no contention..

Anyway, it never was to be, and as I said, I'm sure it was too little too late in 1991, especially in the context of the Amiga being around for so long.. But I sure as hell would have loved to program on it..

 

Anyway, I only mention this for and where the commodore 8bit family should have gone if the plans had worked.. They didn't so I will shut up now..

 

And yes, I realise there were lots of Atari prototypes that were developed.. The only one that really got my attention was the model (65XEM I think???) that featured AMY in it.. That was an example of Atari thinking ahead (I mean with its original plans to put AMY into a dual 68K machine) and god I love additive synthesis[2].. If they'd produced this and got it into the mainstream who knows where we might have ended up now.. But as usual, the Tramiels fucked it all up by firing the ATG team, and then trying to wedge it into the 65XEM and not getting it working for whatever reasons..

 

Anyway, no matter which side of the hedge we sit own, or on the fence itself, I think we're united in a loathing of the Tramiels So lets all have a pint and unite in our love affair of all things 8bit

 

 

[1] So this included a lot of non 6502 instructions and features, like the Z register and 16bit stack pointer (plus relocatable zeropage mode) 16bit inc/dec, plus other niceties.. And it's 25% speed improvement over the regular 6502 due to the microcode optimisations is a nice bonus too..

Page 2 of this doc has a list of the enhancements of the regular 6502

http://archive.6502.org/datasheets/mos_65ce02_mpu.pdf

The 4510 was just this, but with two 6526 CIAs on board..

Interestingly, the 4510 designer (Victor Andrade) went on to later design the K7 for AMD

 

[2] This is from someone who owns two Kurzweil 150 FS, plus an Apple IIe just to run the editing software for these beasts And yes, I love my Apple IIe as well And maybe I'm a IIe fanboy as well.. Who knows

[Atari v Commodore]

The "not so colorful" picture has actually 16 colours. But this is not the point.

 

You must be colour blind or else..

The whole picture has 15 colours..

[Atari v Commodore]

And the reading of Colour RAM causes Cycle Stealing, as the Sprite reading does with the already slower CPU.

 

Okay, listen now.. VICs Colour Ram fetches do not steal cycles from the CPU.. It happens on the cycles where the CPU couldn't run anyway.. The character matrix fetches steal from the CPU.. 40 character matrix fetches equals the 40 cycles we lose on a badline..

There's an additional 40 colour fetches but these are interleaved with the character matrix fetches that take place, but the CPU pays no penalty for those 40 colour ram fetches..

 

edit: Check the first timing table.. https://sh.scs-trc.net/vic/vic_article_3.6.htm#3.6.3.

the 'c' cycles are what's of interest to you..

 

Scrolling on the A8 is a bit odd. First it takes more DMA cycles , but when scrolling is working, the CPU gets cycles back.

 

Care to explain that more ? I'm curious..

[Atari v Commodore]

Another speculative remark on your part: "only one throwing inaccurate facts around is you". I suppose you read all the bullcrap that so many C64 fans wrote in this forum and drew this conclusion? I don't know why you can't accept facts as they are stated and want to resort to attack people based on something unrelated to C64 vs. Atari. But let's get the posting # for the Pet stuff so I can see what you are referring to.

 

I have heard from many people about memory corruption using these DMA delay tricks.

 

Okay okay, the choice of saying 'the only one' maybe wasn't the best first choice.. I've read most of this thread over it's life, and I've ignored most of the clearly wrong stuff because it wasn't being picked up on, or simply wasn't relevant, or simply didn't want to get involved.. I just feel that you're being overly vocal here and were thoroughly mispresenting the 64, and think it fair that it be pointed out that you've made mistakes in your statements before.. Though on the whole, bar being a bit wonky, you've done a fair job when not splitting hairs.. I'm not digging for that post, you can find it if you want.. It's where you're going on about pets and their cpu configurations..

 

I've also heard from many people about the memory corruption (I've also heard the moon is made of cheese), but that fact of the matter is there's a work around.. Demos don't care that the memory might corrupt, as long as it survives the duration of the effect.. Games obviously have different criteria.. No go figure why commerical games featuring these effects work fine.. Big cluestick time.. It's nothing to do with the memory refresh being altered by the dma-delay..

[Atari v Commodore]

Lovely is when it's simple and exact and relies less on software and more on hardware. It's good that you have some workarounds but not as good as hardware support for it.

 

And the point of this is ? I'm not biased here at all.. If I knew the A8 as well as I know the 64, or the 7800 or the 2600 then I would be posting pro's and cons on both sides.. Since I don't, we're left in an ever decreasing circle of petulance from you..

 

You do need to play audio on badlines-- most of audio files/audio recorders nowadays are on Windows which uses 11Khz, 22Khz, etc. so if you use 11Khz, you end up with playing audio on badlines.

Umm, we don't in the context of what we're talking about.. So, why would you use 11Khz or 22Khz ? Instead of 7.8Khz or 15.6 Khz then ? Go on, I'm dying to hear this answer.. I believe you're just being deliberately obtuse here now..

Next you'll be saying that the 64 fails because we can't have a 320x256 or 256x256 screen, because that's a common size of images on Windows..

I did hold you in some high regard up until now, but you've really just blown it with that

 

Stretching sprites by constantly modifying some register every scanline is still not as good as GTIA automatically replicating the sprites for you. You have more software burden involved. In my book if hardware can consistently do it, it's a feature even if happens to be not the intention of the designer.

 

I didn't say it was in this context.. I simply gave one of many ways of ensuring a constant set of cycles over the screen.. Your choice of word here, replicating, is deliberately chosen to mislead.. GTIA doesn't replicate sprites for you at all.. It has no idea of a sprite in the context of an isolated on screen object occupying a fixed vertical region, just an array of memory that it blindly displays down the height of the screen.. You're required to put the data in the right place, and handle the interrupts for positioning and colours, and that overhead of putting the data in the right place is not going to be insubstantial in a busy game.. Granted I'll give you the idea of a sprite being the full-screen height, but in the context you've chosen to write that and chosing to use the word replicating here you're trying to misconstrue again.. You're implying more than the hardware is capable of..

Anyway, by your own definition, the Vic supports variable hardware sprite stretching

I don't believe this, but this is what your rules now say is possible..

Life in the world of Atarski could be fun

So does this mean, that by messing with the sprite addressing hardware, and forcing it not to add 3 to each sprite line, and 2 instead (or the other possibilities, there are many!) that we support hardware sprite distortion ? Or maybe at a pinch, (holy crows!!!) hardware texture mapping!!!

After all, we're just setting a register at the right time, and the hardware does the rest for the duration of the sprite..

And please, for the love of god, don't answer this

 

It's a "no brainer" at the cost of complexity; it more complex than the DLIs I posted earlier in this thread which execute cycle-exact code without relying on WSYNC. It requires that code be all exact in the background.

 

It's not.. I've told you once already how to ensure jitter free interrupts, you've chosen to ignore that..

[Atari v Commodore]

I don't think sprite replication on Atari or 23 color GPRIOR is as complex as doing time critical things on C64 given no hardware support for them and giving burden to software to deal with it. GPRIOR can be used even in BASIC as I gave the code already. Delaying DMA cycles to get some effects isn't your normal coding especially when you have to deal with the BA signals caused by color RAM and sprite motion. And now you combine stuff like line-based scrolling and overscan/underscan and your timing can't be used anymore. You are blaming me for claiming things impossible but I already gave code for them in BASIC yet you are trying to explain things that would require cycle-exact coding and more overhead in software than Atari doing it via it's DL and hardware registers.

 

I beg to differ because the code involved is fairly constant, and very easy to set up.. Far far easier then this pie in the sky idea of horizontally multiplexing players.. I'm ready to be proved wrong on this, and would love to be..

Colour Ram doesn't incur any overhead on the 64.. Colour Ram is connected via a seperate bus to VIC internal 1k x 4bit memory..

Scrolling doesn't affect timing at all.. Timing is exactly the same..

You're BASIC example is exactly that.. It shows 23 colours, now do something sensible with if you please...

[Atari v Commodore]

That's a typical fanboy argument. "1982 crap". Your subjective biased opinion. I think many of the 1982 and before games are excellent. Games don't have to use all the capabilities of the hardware to be good. By the way, andym00 made a straw-man argument and you supported it which means another fanboyish mentality. I never said anything about not being able to use "bugs" in hardware. I was talking about consistency of making it run on all machines. Go read it yourself.

 

Please don't confuse me with a fanboy here Atariski, like both, I have owned both for a very long time.. I'm simply trying to get some balanced view of what both are capable of technically.. Apparently it's fine for the A8 team to throw around ideas that are nigh on impossible to implement if not impossible, only to be greeted by the cheer of the supporters.. You questioned some facts I stated, I answered all of them.. The only one throwing blatently inaccurate facts around is you, and people choose to ignore when you do so.. Ie: with regards to your statements on the multiple processors configurations of Pet computers..

 

Anyway regards your straw-man distraction I'm not playing your games, you've had your questions answered..

Regards your point about VSP ? I suggest you go read up.. The only issues are with demos (no surprise really there).. The games that use this don't have a problem.. You go figure why, it's not rocket science really..

 

I figure the only way to answer this is to build a technical prototype for a game on both and then see.. I guess 3D is out because we've a weaker processor as has been agreed on.. Both since it's clear from the rational discussion here that the A8 can match the 64 on all other aspects if not exceed it in many areas, pick your poison..

 

edit: I don't really expect any sensible outcome to come from this, but I'm open to this if it remains civil..

[Atari v Commodore]

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..

[Atari v Commodore]

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..

[Atari v Commodore]

...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..

[Atari v Commodore]

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

[Atari v Commodore]

You know I agree horizontally both Atari and Amiga have lesser sprite coverage, but some games are planned to use the advantage of the taller sprites (like River Raid). Similarly, you can target the machines strengths like hardware scrolling and mixing modes which would end up costing you a lot more cycles when porting to C64. Just like when you take horizontally wider sprites and try to port on Atari/Amiga, it costs the latter machines more cycles of CPU time by replicating horizontally or substituting with software versions. Amiga can also replicate sprites horizontally using it's similar GRAFn registers.

 

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..

[Atari v Commodore]

Something completely different

 

What about trying to adapt "MOOD" to the A8?

It's a good candidate for either gr. 9, gr. 10 and gr. 11.

 

Okay Emkay, how about showing us something that's actually viable and can work instead of spouting repeated 'theoretical' ideas.. Really this whole thread comes down to 'in theory' the A8 is better, but we can't in practic prove it..

Your move sunshine.....

edit: I'm a bit tipsy and maybe regreting what i said..

[Atari v Commodore]

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...

Of course you're right.. That'll teach me to be thinking in NTSC land before writing that.. Don't notice I'd mixed PAL (63) with NTSC (65) there...

Oops..

 

And yes, I'm guilty of forgetting to take the multiplexed sprite cost into the frame when saying it's almost no cpu cost..

Oops