Atari v Commodore

[PeteD]

Feel free to code something better from that point of view with 3 layers of OVERLAID (ie 3 playfields) type parallax at any time

Oky, why do you keep saying that Enforcer 2 has 3 layers of overlaid parallax? Can you explain how you arrived at three, because I only see two - all the red stuff being the 'back layer', and everything else being on the 'front layer'.

 

 

 

 

I think he's talking about the level 1 demo where it's got the parallax ala the red stuff on level 2, the foreground AND some fast moving star looking 2 character wide stuff over the background ooooooo

[Barnacle boy]

Armalyte is a classic example also of an example in coding excellence with useless game play.

I only just read this post, but wha...? That is so wrong it hurts!

 

I'm in pain right now. Why do you do this to me?

 

@barnacle boy

 

You're right, my bad there are more than 8 sprites on screen. The reason why I presumed it was 8 was the movement isn't very complex and so I'll still stand by it not having a multiplexer (something that by the logic itself can take a fair bit of cpu), and whilst playing it didn't see any more than 8, didn't get round to pausing it every few frames.

OK, I shall climb down from my Enforcer 2 high-horse now.

 

(In fact, after reading Oky's comments, I am now sitting firmly astride my Armalyte high-horse. It's very high indeed. I think it might actually be a giraffe.)

 

I too presumed the lightning in Enforcer 2 was chars at first, and was a bit surprised to find they had used sprites, but I guess it's kind of a non-essential frill. Because it only has to flash on the screen so briefly, the coders probably thought: why not just slip it in when there are some sprites free? If there aren't enough sprites free, just don't show the lightning, or show one of the shorter ones instead.

 

In regards to Enforcer 2 not displaying many enemy sprites per split, I guess part of the problem is that they used up 3 sprites just for the player ship. Add to that a couple of 'free roam' sprites needed for enemy bullets, and you're not left with much to play with. Yeah, the ship looks nice and all... but 3 sprites!? You can make a pretty nice looking ship with just one! Still, at least they didn't make it 2 sprites wide, Katakis style.

 

And I agree that Armalyte is a more impressive example, sprite-wise (and gameplay-wise too!). Sure, it might rely heavily on fixed sprite paths, but it works so damn well.

 

Feel free to code something better from that point of view with 3 layers of OVERLAID (ie 3 playfields) type parallax at any time

Oky, why do you keep saying that Enforcer 2 has 3 layers of overlaid parallax? Can you explain how you arrived at three, because I only see two - all the red stuff being the 'back layer', and everything else being on the 'front layer'.

I think he's talking about the level 1 demo where it's got the parallax ala the red stuff on level 2, the foreground AND some fast moving star looking 2 character wide stuff over the background ooooooo

I wondered if he's somehow interpreting the blue and purple stuff in level 2 as being on a separate layer to the metallic stuff. I thought maybe the fact that the blue and purple stuff serves as kind of a background (being non-collidable) made him overlook the fact that it scrolls at the same speed as the metal foreground stuff. I see now that he has been banned for a week, so I guess it will remain a mystery forever more. Or for a week.

Edited July 17, 2009 by Barnacle boy

[PeteD]

Armalyte is a great example of something that's impressive but doesn't try to show off about it, you just end up with a better experience. Even older stuff like Rambo (Ocean) in fact a lot of Ocean games use multiplexers and other tricks before I even knew what one was.

 

Is it just Vice or do the sprites that "stand" on the background also not sync with the scroller? Not a major issue but another one that just lacks polish.

[popmilo]

Here is something new for comparisson :

I have been told, that my focus on 'platform' games narrows my judgement for A8 features because of color ram being so good for that particular type of games.

 

So I found something else

 

One of my favourite games, C64s BMX simulator series:

Games consist of more single screen levels with simple but addictive game mechanics and great multiplayer value...

First game had two players, each standard multicolor sprite (12 pixels wide, 3 colors - black, red or green, and yellow).

Background is normal c64 multicolor bitmap...

Background could be done with some color limits but it could look good enough.

Players are tougher nut to crack... But José gave me idea

Black is the color of the bike, but yellow and rider color are used only in middle part...

So why not put P0 and P1 in the middle and M0 and M1 on the left and right side to extend sprite to 12 pixels ...

So all the PMs would be used for Two riders, wich means background would have to be done in 5 colors and DLIs for more than that...

 

Here are some static screens for you G2F fans

 

And then we come to the BMX simulator 2

4 player version.

4 Hires definition two color 24 pixels wide players....

Sorry to say, but IMHO that is impossible on A8....

 

 

So in my opinion, riders could be done using 4 standard PLAYERS like in first example, but I would make black parts from 12 pixel wide software sprites

That would leave 4 missiles to improve color a bit....

 

But what is most important for me is that gameplay can be copied 100% and even could be improved...

 

So what do you say? Agree or not and why not ?

[PeteD]

Hey, be careful that I don't tell Ste you A8 guys are converting his loading screens, he'll want some money

 

 

*edit*

 

Forgot to say, yeah I agree.

Edited July 17, 2009 by PeteD

[Jetboot Jack]

BMX simulator was AWFUL on the A8...

 

Typically tawdry 4 color half effort, not even the odd DLI, cheapest possible port...

Edited July 17, 2009 by Jetboot Jack

[José Pereira]

Hello people.

 

Probably not as bad as almost the others.

Some good music from David Whitaker.

 

Now I see that the 2 Players are in PM1/PM2 and PM3/4 overlap, so the hair it's the third colour (O.k., I think that when i bought it, I don't even know what was a Player, Missiles,...)

 

It could be with 1 more colour (one grey, like c64), and probably, being static screens, some GED mode or Super IRG mode would go very good in here. Probably, a simple straightway to change. A simple G2F with GED enebled can put more colours on this. And by the way, Grand Prix Simulator also.

 

In version 2,the only way it's like Pop say4Players+Missile overlap in eachone).But again GED or Super IRG.

Which games you know with GED Mode? And Super IRG?

 

José Pereira.

[Heaven/TQA]

well.... BMX Simulator could be a good candidate for a remake? that sounds good...

[atariksi]

The equivalent of FLI on the Atari is to use the VScroll trick to produce shortened characters.

 

You can't necessarily say a given software trick on one machine has an equivalent on the other. Many of the software tricks on the C-64 are utilised to produce effects that on the Atari are available by default, such as "Sprites in the Border" and arbitrarily having the screen memory at any location.

In similar fashion, the Atari has to resort to software tricks to do some things the C-64 can do by default, such as our use of horizontal screen Kernals to allow mixing of hires graphics with GTIA and 160 pixel multicolour mode on the one scanline.

 

Enhanced colour modes like TIP and APAC are a combination of software-driven graphics modes and the way PAL TV receivers combine hue from adjacent scanlines.

Such modes are possible on almost any computer that outputs to TV, so long as a sufficiently flexible palette and means of displaying a reasonable number of colours is available.

 

There's a difference in that FLI pumping out more color choices is not as good as Atari pumping out more colors since you get more accuracy of the colors. It's better to have 12 colors from palette of 256 than 16 from 16.

 

As far as horizontal kernels, Atari obviously wins there as it can sync up without having to deal with non-deterministic BA signals thus lowering the software burden. And DLIs/WSYNCs are not Atari tricks-- they were purposely put in hardware so colors/sprites can be changed on scanline basis. Even IRQ is perfectly synched with the video using the 15Khz (scanline rate) or 1.78979Mhz color clock/2 rate.

[atariksi]

DK - Donkey Kong

RR - River Raid

PM - Pac Man

Ms PM - Ms. pac Man

SI - Space Invaders

DI - Deluxe Invaders

CP - Centipede

MP - Millipede

SLP - ?

BP - ?

J - Jumpman?

Q - Q*Bert?

F - ?

 

That was SLB not SLP. It's Star League Baseball. Blocky graphics but excellent playability-- you can control most of the things and exactly. Hard to catch fly balls as the shadow is in 3D.

 

BP = Backyard Pong.

 

J can't be Jumpman since that would be JM. J is joust, a good example of having 10+ sprites horizontally w/missiles used as lances.

Q can't be QBert since that would be QB. Q is qix, a good example of nondeterministic game play-- no fixed pattern.

F = frogger.

[atariksi]

Good nioght to all of you.

 

I'm I wrong, or you, on the above mail, don't explain PMs. multicolour properly.

 

I think that you could have more than 8 pixels wide.

P0/P1 it's eight pixels if it is on the same cell the 2 Players.

But, I think I'm right if say that could be more:

For example:P0 on(horiz.,vertical position) "pos. 1,0 until 8,0 and P1 pos. 7,0 until 14,0. You get 15 pixels horizontal wide, but only get the third colour on place 7,0. The dimension depends how mucl pixels a Player is above the other.

And, you can join Player+Missile with correspondent 1: and have 10 and 10 pixels.

 

 

José Pereira.

 

If you mix two players and two missiles, you can position them, change the width of missiles, etc. to make them appear to be wider sprites and still have 4 colored objects since not all 4 colors are used uniformly in most cases.

[andym00]

As far as horizontal kernels, Atari obviously wins there as it can sync up without having to deal with non-deterministic BA signals thus lowering the software burden. And DLIs/WSYNCs are not Atari tricks-- they were purposely put in hardware so colors/sprites can be changed on scanline basis.

Even IRQ is perfectly synched with the video using the 15Khz (scanline rate) or 1.78979Mhz color clock/2 rate.

 

Firstly, so what do you think a Raster interrupt is synced to then ? Bored cats ?

Secondly, what on earth do you think the timer interrupt clock source is from ? Sleepy donkeys ?

 

And we won't even touch on the fact that you've glossed over (some would say wholly misrepresented) the fact that your syncing argument, with regards to you implying useful horizontal changes being made during the display of a single scanline, are applicable in bitmap mode only, not in character mode from what I recall in this thread..

Edited July 17, 2009 by andym00

[andym00]

J is joust, a good example of having 10+ sprites horizontally w/missiles used as lances.

Yup, a stunning example

[atariksi]

As far as horizontal kernels, Atari obviously wins there as it can sync up without having to deal with non-deterministic BA signals thus lowering the software burden. And DLIs/WSYNCs are not Atari tricks-- they were purposely put in hardware so colors/sprites can be changed on scanline basis.

Even IRQ is perfectly synched with the video using the 15Khz (scanline rate) or 1.78979Mhz color clock/2 rate.

 

Firstly, so what do you think a Raster interrupt is synced to then ? Bored cats ?

Secondly, what on earth do you think the timer interrupt clock source is from ? Sleepy donkeys ?

 

And we won't even touch on the fact that you've glossed over (some would say wholly misrepresented) the fact that your syncing argument, with regards to you implying useful horizontal changes being made during the display of a single scanline, are applicable in bitmap mode only, not in character mode from what I recall in this thread..

 

Your interrupts have to be stabilized with software; it's not in hardware. I can also do software sprites. You are misrepresenting things. Get a life. We already argued this already. Perhaps, you didn't read the reply.

You can sync up IRQ on exact pixel in char mode.

[atariksi]

J is joust, a good example of having 10+ sprites horizontally w/missiles used as lances.

Yup, a stunning example

 

You are DEAD wrong. I just played it. There are instances where there are 8 enemy birds, two player birds and dragon. Now go take all the possible snapshots and come back with a more decent reply.

[Irgendwer]

This screenshot, taken from near the start of the level 2 demo, shows 24 sprites on the screen. I wonder if the posters here can spot them all:

...

 

Regarding the technical abilities of the A8, this would be a piece of cake if you just turn the screen by 90 deg.

Providing the background pattern constellations and a DL which chooses the correct lines in ANTIC mode 15.

Player reuse with DLI HPOS change...

 

If I had to do it, I would do it that way (could be 239 lines high in PAL) and if you need some more free cycles just

use the narrow screen...

 

CU

Irgendwer

 

PS: Regarding a 'BMX Simulator-fresh-up': There are so many new interesting games that could be done

on our machine - why enhance an existing which IMHO has a good playability? (Yes, the graphics are a

shame, but who cares now?)

Edited July 17, 2009 by Irgendwer

[andym00]

Your interrupts have to be stabilized with software; it's not in hardware. I can also do software sprites. You are misrepresenting things. Get a life. We already argued this already. Perhaps, you didn't read the reply.

You can sync up IRQ on exact pixel in char mode.

Really now.. You're just saying things now in the hope that no-one will contradict you because they're tired of you, well think again..

 

Sorry to quote Rybags on this, but...

Atari = 114 cycles per line. "Badline" = 81 cycles lost, 33 free, other lines = 49 lost, 65 free (50/64 or 52/62 for Dlist fetches)

C64 = 65 cycles per line. "Badline" = 40 lost, 25 free, other lines = 65 free

So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

Well, that's some pretty damn tiny screen you must have then...

 

That's not even to broach the old subject of 'yes, we can do that too!!' regards getting synced up nicely.. So you burn some cycles wasting with your WSYNC, and (what a surprise) so do we burn a few cycles syncing up.. I mean really, surely you should be counting your cycles and not even relying on WSYNC that like real VCS programmers do Smacks as just plain lazy, and not pushing the hardware anyway..

[atariksi]

The equivalent of FLI on the Atari is to use the VScroll trick to produce shortened characters.

 

You can't necessarily say a given software trick on one machine has an equivalent on the other. Many of the software tricks on the C-64 are utilised to produce effects that on the Atari are available by default, such as "Sprites in the Border" and arbitrarily having the screen memory at any location.

In similar fashion, the Atari has to resort to software tricks to do some things the C-64 can do by default, such as our use of horizontal screen Kernals to allow mixing of hires graphics with GTIA and 160 pixel multicolour mode on the one scanline.

 

Enhanced colour modes like TIP and APAC are a combination of software-driven graphics modes and the way PAL TV receivers combine hue from adjacent scanlines.

Such modes are possible on almost any computer that outputs to TV, so long as a sufficiently flexible palette and means of displaying a reasonable number of colours is available.

 

There's a difference in that FLI pumping out more color choices is not as good as Atari pumping out more colors since you get more accuracy of the colors. It's better to have 12 colors from palette of 256 than 16 from 16.

 

As far as horizontal kernels, Atari obviously wins there as it can sync up without having to deal with non-deterministic BA signals thus lowering the software burden. And DLIs/WSYNCs are not Atari tricks-- they were purposely put in hardware so colors/sprites can be changed on scanline basis. Even IRQ is perfectly synched with the video using the 15Khz (scanline rate) or 1.78979Mhz color clock/2 rate.

 

Read the original message. DLIs/WSYNCs work in all modes. There's no unstable BA signals to worry about in any mode. Whatever DMA cycles there are, are well-defined. And if you need to make it more accurate, you can switch modes for the lines where you need the extra cycles. Atari wins in Horizontal kernels even with char mode; there's a lot more choices for Atari. There's no way you can tell me your software algorithm is better than hardware that's already perfectly in sync with video beam.

[atariksi]

Your interrupts have to be stabilized with software; it's not in hardware. I can also do software sprites. You are misrepresenting things. Get a life. We already argued this already. Perhaps, you didn't read the reply.

You can sync up IRQ on exact pixel in char mode.

Really now.. You're just saying things now in the hope that no-one will contradict you because they're tired of you, well think again..

 

Sorry to quote Rybags on this, but...

Atari = 114 cycles per line. "Badline" = 81 cycles lost, 33 free, other lines = 49 lost, 65 free (50/64 or 52/62 for Dlist fetches)

C64 = 65 cycles per line. "Badline" = 40 lost, 25 free, other lines = 65 free

So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

Well, that's some pretty damn tiny screen you must have then...

 

That's not even to broach the old subject of 'yes, we can do that too!!' regards getting synced up nicely.. So you burn some cycles wasting with your WSYNC, and (what a surprise) so do we burn a few cycles syncing up.. I mean really, surely you should be counting your cycles and not even relying on WSYNC that like real VCS programmers do Smacks as just plain lazy, and not pushing the hardware anyway..

 

Go run the IRQ example posted in this forum. Once you sync with STA WSYNC, you know exactly what is happening cycle by cycle. No need to resync or re-use WSYNC but you can if you wanted to.

[atariksi]

Firstly pete...welcome to our small huddle....nice to see a fellow brit here (how are things in the valley's, are the coal mine's still open or did you kick scargill out)...I hope you stay a while, stay forever (as they said in some non descript commie 64 game)

 

 

As i am sure you will agree that comparing atari with commodore is like apples and oranges

 

i.e so the c64 has all these hardware tricks like fli/ifli, sprite multiplexing etc...(stuff that is as 2nd nature to you as picking your nose etc) tell me, is there an equivalent routine or hardware trick on the A8 (being a non coder i would'nt know)

 

Or on the c64, is there an equivalent routine or hardware tricks like the A8's gtia bug, hip, tip, cin, apac etc hardware tricks (stuff that you will no doubt immerse yourself with as you get fam. with the a8 hardware)

 

Now look at it from this way, ask any c64 user (that doesn't own an atari) beit a programmer or just a regular games player whether they have heard of things like gtiabug, hip, cin, tip or apac (from a c64 perspective)...chances are that they will give you a blank stare and ask you what you're going on about...as it doesn't relate to a c64 or to any element of it's programming, unless by some twist or quirk of fate some c64 code head has 'split the sillicon' and found/coded equivalent hardware tricks on the c64 (by equivalent i mean the c64 version of that atari hardware trick will perform in same or similar fashion as it was originally rendered on the atari)

 

And conversely...Ask any atari user (that does not own a c64) beit a programmer or just a regular games player whether or not they have heard of things like fli/ifli/sprite multiplexing etc etc (from an atari perspective)....again just like the c64 user did, the atari user will probably give you a blank stare and ask you what your on about...as it doesnt relate to atari or any element of it programming, and unless by a twist or quirk of fate, some atari code head has 'split the sillicon' and found/coded equivalent hardware tricks on the atari (by equivalent i mean the atari version of that c64 hardware trick will perform in same or similar fashion as it was originally rendered on the c64)

 

I think we both know the chances of such things happening are remote as both systems are two entirely different architectures (the only things that connects them is 650x compatibility and the joystick ports)

 

Now the question is....just because the c64 has such and such a hardware trick (where the atari equivalent doesn't exist) does that make the c64 a better machine...tell you what, lets widen it a bit and encompass all classic 8bit systems

 

Or conversely just because the atari has such and such a hardware trick (where the c64 equivalent doesn't exist)...does that make the atari a better machine....lets widen it a bit and encompass all classic 8bit systems

 

The point i am making is that unless such and such a commodore hardware trick has an equivalent hardware trick on the atari (or any of the other classic 8bit systems) and can display that trick in same or similar fashion as per how it was rendered on the machine that hardware trick was first found on...just because the commodore trick has no equivalent or similar trick on the atari (or other classic 8bit system) doesn't neccessarily make the c64 a better machine, it simply means that the c64 is capable of that hardware trick and that's it...i.e unless another machine (like atari) has a similar hardware trick and does it similar or the same as the commodore hardware trick it is pointless comparing both systems on the basis of what hardware tricks you can do with that machine (i believe it's called making a fair comparison)

 

which is why i made the point about finding a commodore hardware trick/s that has an equivalent hardware trick/s on the atari and can output or render that trick/s in a same /similar fashion as it was rendered on the machine that hardware trick/s was found on and make some games (same games on both systems) and let the user/consumer decide which is a better system based on the same hardware tricks used on the same game for both systems

 

 

Ultimately, while it may be nice, fantastic and nice window dressing that the atari or the c64 has all these hardware tricks, it means not a jot if your comparing the systems based on what hardware tricks you can do on that system, if the competing system does'nt have that feature or similar feature, unless by a twist of fate both systems have exactly the same or similar trick/feature and a fair comparison can be made...just saying the c64 is a better machine because it can do 1000 spites on a screen with this trick is no argument if there is no equivalent trick on a competing system (like atari)...where's the comparison...where's the argument...what point is being made...wow, the c64 gives you this many sprites using this trick...so what, yes, it's good but what's the point, what you competing against...apart from nothing (as no equivalent trick or technique is available on a competing system, like atari)

 

Just to point out ofcourse i am only using that hyperphetical trick as an example

 

perhaps we can try and get back on track and focus on the point and post the OP actually made, i.e. finding commodore and atari versions of the same game discusssing the merits of each version and deciding which version is the better

 

quiet a few examples like alternate reality, shamus, a.e, koronis rift, ballblazer, rainbow walker, pitstop, pitfall 2, and hundreds if not 1000's of others

 

You can't assume both machines have equal number of hardware features undoable on the other. Atari has a lot more and that's why it's superior overall. Even with FLI, you have to restrict your screen size and how you use sprites and use complex programming whereas Atari software driven modes can be in overscanned and use more colors/scanline. Actually, Atari can do more independent sprites per screen than C64 because it's easier to multiplex vertically and because of faster CPU. Atari is more accurate in timing w/more hardware timing support, faster in I/O, faster CPU, better palette, better looking pictures, etc.

 

Some people draw conclusions based on their limited run of some software rather than the hardware.

[Bryan]

So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

Well, that's some pretty damn tiny screen you must have then...

 

During the first char line you have interleaved char fetches and 1st line gfx fetches which shut down all CPU activity during the active part of the line. The remaining cycles are in the off-screen area (porches).

[andym00]

So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

Well, that's some pretty damn tiny screen you must have then...

 

During the first char line you have interleaved char fetches and 1st line gfx fetches which shut down all CPU activity during the active part of the line. The remaining cycles are in the off-screen area (porches).

 

So a very tiny, and invisible window

That's all I was trying to get him to come clean with.. His claim that:

"you can sync up IRQ on exact pixel in char mode."

is not entirely truthful, again..

 

It should really say like the c64, we have to write off the idea of doing any cycle exact interrupts on a badline.. Instead of making it sound like it can interrupt anywhere, anytime with exact cycle accuracy..

 

And I guess this also rather blows the idea of doing any of the much talked horizontal colour changes, mode changes, sprite plexing and other fancy shenangians in character modes since it'll look a bit poor not being able to do anything on every 8th line.. I'm sure you could work some design into it, but I'm just being baffled with all this talk of what you can do, but then it turns out it's not quite as Atariski, Emkay and Co. make out or there's some fairly large restrictions that someones deliberately forgotten to mention..

[andym00]

Read the original message. DLIs/WSYNCs work in all modes. There's no unstable BA signals to worry about in any mode. Whatever DMA cycles there are, are well-defined. And if you need to make it more accurate, you can switch modes for the lines where you need the extra cycles. Atari wins in Horizontal kernels even with char mode; there's a lot more choices for Atari. There's no way you can tell me your software algorithm is better than hardware that's already perfectly in sync with video beam.

No, you read, and properly this time and don't go mis-quoting me and making out I said things I didn't..

I didn't dispute that DLIs or WSYNCs work in all modes.. You've just made that up..

I didn't say there were unstable/undeterminisitic/subjective/random/pink/alien-generated 'BA signals' in any mode... You just made that up again..

 

And of course you can switch modes where you want the cycles back, I didn't say you couldn't.. Ummm and for that matter, so can the 64.. Want a character screen with no badlines ? No problem, just abort the DMA on every 8th scanline, viola, no badlines and a display too boot[1]..

 

The fact is that you're not portraying a clear picture here at all, willy-nilly deciding to leave out details of critical importance..

 

As for your question of "software algorithm is better than hardware that's already perfectly in sync with video beam", it seems like you have similar restrictions to the 64 the real difference being just a faster processor to do shit with when it comes to monkeying around with registers on those scanlines..

 

[1] Whereas Atariski would choose to leave it at that, there is the issue that doing that means the character matrix is repeated from the first fetch, as is the colour ram, so you have to change character sets every 8th line, but it does what it says on the tin.. A display with no badlines, and a display with stable/deterministic/objective/non-random/blue/hardware-generated 'BA signals'...

[Bryan]

So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

Well, that's some pretty damn tiny screen you must have then...

 

During the first char line you have interleaved char fetches and 1st line gfx fetches which shut down all CPU activity during the active part of the line. The remaining cycles are in the off-screen area (porches).

 

So a very tiny, and invisible window

That's all I was trying to get him to come clean with.. His claim that:

"you can sync up IRQ on exact pixel in char mode."

is not entirely truthful, again..

 

It should really say like the c64, we have to write off the idea of doing any cycle exact interrupts on a badline.. Instead of making it sound like it can interrupt anywhere, anytime with exact cycle accuracy..

 

You get the advantage of knowing exactly where the beam is after a WSYNC but no, it won't give you access to the middle of a badline. If you want to do a bunch of free-form mid-line stuff you're probably better off in a straight graphics mode.

 

There are a few neat things you can do like extend the height of a char row using VSCROL so you have fewer (or no) badlines. You can dynamically change the character set pointer to make every line of the extended characters unique.

Edited July 17, 2009 by Bryan

[andym00]

You get the advantage of knowing exactly where the beam is after a WSYNC but no, it won't give you access to the middle of a badline. If you want to do a bunch of free-form mid-line stuff you're probably better off in a straight graphics mode.

 

There are a few neat things you can do like extend the height of a char row using VSCROL so you have fewer (or no) badlines. You can dynamically change the character set pointer to make every line of the extended characters unique.

I'm very familiar with the WSYNC stuff from my many years spent on the 2600 and also on the 7800 with DLIs and co

That's all I wanted from him, rather than the incomplete pictures that have been painted by him..

And yeah, in bitmap modes you have way more freedom, of that I'm very envious and so are my interrupts

 

What was interesting to just find out was that on A8 you must write to WSYNC before cycle 100 ?? Does this mean that you lose the remaining 14 additional cycles, or would they have been consumed by other memory accesses anyway ?