Atari v Commodore

[emkay]

here is the youtube of c64 Hard Drivin circa 1989!

Check the guys funny commentary! So funny!

 

 

Hehe.... It's the same guy who stated the A8 version of RoF is as good as the C64 version

 

PAL A8 version still can remain 4 times faster than that interactive slideshow.

 

It's so crap what they produced there, it isn't funny

 

Well, in some cases the A8 only has the half colour resolution of the C64, but C64 has the far more worse "CPU cycles per pixel" ratio. To handle those VIC II gfx well enough, a 4MHz CPU must have found place in the C64.

If it only got a 2MHz CPU, you could call the C64 a "rounded" computer....

Beeing released in 1982 with a less than 1MHz clocked 6502, you easily can name the C64 a half computer

[atariksi]

It's really easy to understand brand loyalty! It like football teams or cars. Mine is great and yours sucks till the day we die! Fan ism is all around us everyday. People love to fight and argue. It's just the way the majority of people are.

 

[scratches head] That's the thing... i'm not particuarly brand loyal as such, i've owned, programmed for and sold both Atari and Commodore kit over the years and, whilst i preferred the latter, it doesn't preclude me having an interest in any other platforms. i don't hate the A8 in the slightest (if i did, it'd be incredibly hard to explain all the code i've written and time spent playing games), i just like the C64 more and personally believe it's the more rounded machine overall... but you try having that opinion round these parts.

 

It's more rounded physically on the corners compared to Atari 800, but that's not important really. I think people who want the better computer would want a more rounded machine technically (hardware-wise) like Atari 400/800/XL/XE:

 

1. CPU Freq 1.78979Mhz

2. Rock solid timing and more accurate (No indeterminate signals to throw off cycle-exactness)

3. Easy overscanning

4. LMS -- easy to access more video memory, mirror images, repeat scanlines, etc.

5. VScroll/HScroll on per scanline basis (8-dir scrolling windows)

6. More priorities and playfields (and GPRIOR mode 0 mostly unexplored)

7. Linear and easy to use high color depth modes (GTIA)

8. Fast keyboard reading

9. Faster joystick I/O and SIO I/O (16-bit reads/writes)

10. Display lists w/various modes (use by themselves or for speeding up screen updates)

11. WSYNC for easier to start writing cycle-exact code

12. DLIs (more optimal than raster IRQs)

13. BOOT Up to cassette files or disk files (without user intervention)

14. A lot more collision detection combinations (60-bits)

15. 4 DACs w/more accurate sampling rate (lower latency)

16. Better interlace (due to more shades to reduce flicker)

17. More colors/shades (bigger palette)

18. Horizontal re-use of hardware registers (much easier)

 

Okay, updated now:

 

1. CPU Freq 1.78979Mhz

2. Rock solid timing and more accurate (No indeterminate signals to throw off cycle-exactness)

3. Easy overscanning

4. LMS -- easy to access more video memory, mirror images, repeat scanlines, etc.

5. VScroll/HScroll on per scanline basis (8-dir scrolling windows)

6. More priorities and playfields (and GPRIOR mode 0 mostly unexplored)

7. Linear and easy to use high color depth modes (GTIA)

8. Fast keyboard reading

9. Faster joystick I/O and SIO I/O (16-bit reads/writes)

10. Display lists w/various modes (use by themselves or for speeding up screen updates)

11. WSYNC for easier to start writing cycle-exact code

12. DLIs (more optimal than raster IRQs)

13. BOOT Up to cassette files or disk files (without user intervention)

14. A lot more collision detection combinations (60-bits)

15. 4 DACs w/more accurate sampling rate (lower latency)

16. Better interlace (due to more shades to reduce flicker)

17. More colors/shades (bigger palette)

18. Horizontal re-use of hardware registers (much easier)

19. Backward compatible with all A8 computers

20. Easy 2000+ sprites multiplexor for image enhancement

[emkay]

On NTSC, it's optional. When it is done, even scans are in phase, odd scans are 180 degrees opposite phase. Both produce the same "color", but at a different location on the screen.

 

When viewed on a monochrome device, or on a PC capture card with good resolution, the non-interlaced, Atari style color, appears as vertical stripes. Interlaced color appears as a checkerboard, alternating each frame.

 

 

Interesting how you defend this "Never The Same Colour" workaround...

[atariksi]

Does anybody have any views on where any titles were launched on both Atari and Commodore - and the Atari version is the better of the two?

 

Steve

 

Yes, agreed. The City have the best music ever. Also think M.U.L.E. because of the 4-ports ... better all round feel too. Also Lucasfilms Ballblazer and especially Rescue on Fractalus (at least here in Norway PAL ... C64 version is way slower). Mostly also liked Synapse better on Atari, with the exception of Survivor maybe ...

 

Also liked Bounty Bob Strikes Back better on the Atari

 

Stinker on Atari too though ... Talladega and Pitstop was better on C64 ... Talladega is probably not even the same game. Like Blue Thunder too ... not same game at all

 

Now playing Hobgoblin :-) Got my cart today ... Wish I had enough for an EE version too :-/

 

Take Atarian care

 

Is that Bounty Bob continuation of Miner 2049er? I have the latter on cartridge.

[analmux]

...C64: better screen resolution w/ varying modes, better collision detection, tighter gameplay, more discrete or apparent colours and MUCH better sound (thanks SID) - HORRIBLE load times, goofily shaped computer sits too high, superior keyboard with non-intuitive cursor control, cheaper feeling case, but superior PCB materials/design and excellent compatibility with software and peripherals.

 

Atari 8-bit: super quick load times, blocky/chunky graphics, good collision detection, universal<>familiar & generic looking character font/number/scoring graphics (letters and numbers), mediocre (but again, familiar) sound that is adequate, superior case and plastic material design (not talking PCB), horrible compatibility (hardware, but especially software) within its own family...

C64 has no better collision detection. Atari has 60 bits in hardware to check for any 'Player or Missile' to 'Player or Playfield' collision. The GTIA (chip in A8) wins hands down compared to VIC II (chip in C64) on this.

 

The C64 Keyboard however, even if some of the controls are a bit weird, is (indeed) far superior. It really has an 8*8 matrix to check. So, any key can be used as an independent button; several keys can be pressed and checked at once. Atari has big problems with that. OK, on A8 the keyboard debounce can be cancelled, and then we CAN in fact use multiple keys, but this will only allow some key groups together. Still no individual/independent control. However, sometimes the C64 keyboard can be 'too sensitive', as it's easy to type 2 keys together, and there'll appear 2 characters on screen. Especially on the C64 classic (breadbin: high keyboard) this is something working on my nerves.

[TMR]

here is the youtube of c64 Hard Drivin circa 1989!

Check the guys funny commentary! So funny!

 

Yup, Hard Drivin' is piss poor... but i don't remember anyone arguing that everything on the C64 was good and there's not even an A8 version to compare it to - considering your opinion of A8 programmers, the odds are it would've been equally pants had they done a port.

 

PAL A8 version still can remain 4 times faster than that interactive slideshow.

 

Again you're making calls on programming without anything even approaching the knowledge to back them up.

[roland p]

If all hours put in this topic, where put in homebrewing, you would get a lot of cool games.

[TMR]

If all hours put in this topic, where put in homebrewing, you would get a lot of cool games.

 

i'd like to think the A8 game i'm writing simultaneously to posting here will come out quite cool when it's done, i can't speak for the Atarians though...

[frenchman]

 

Yes, i know it's a UK magazine... i've been writing for them since issue 51, it's sort of hard to avoid noticing after about eighteen months. =-)

 

 

 

Yes, I know that there are some really unknowledgeable people working for that mag, incl. the awful Stuart Campbell, who never does any research (the Neo Geo blunder was pretty bad, here's a DP posting from a member: ".......I was pretty sickened by the crap Stuart Campbell pulled over at Neo-Geo.com a few months back. Basically he was called on some errors in an article he wrote, but instead admitting to it or entitling everyone to their own opinions he created this giant ego driven mess, registered multiple accounts to defend himself with against the infamous neo-geo.com slaughter house, and never once attempted to save any face.

It's the only time I've seen a 40 year old man devolve into a 10 year old boy. You could make a top 50 list he said so many stupid things there, telling your readers to "die in chemical fires" sticks out for me though."

Edited October 6, 2009 by frenchman

[andym00]

C64 has no better collision detection. Atari has 60 bits in hardware to check for any 'Player or Missile' to 'Player or Playfield' collision. The GTIA (chip in A8) wins hands down compared to VIC II (chip in C64) on this.

 

It doesn't.. Reading your docs and measuring bits maybe, but in the real world ?

Okay, technically better, but practically it's debatable and mostly a moot point since your players normally spend most of them time underlaying/overlaying software sprites or combined with other sprites or being used to provide additional colours on the background, it's not a whole lot of use in all practicality those 60bits..

On the other hand, VIC collision is simple but straight forward and useful.. Not a whole lot useful when examined once per frame (which is the only advantage the A8 has on this count), but when you grab the collision register at the end of each displayed sprite on the screen (in your multiplexer) you have all the information that you could ever wish for, all handily packed up into a nice 8bit value

 

On the A8 it's kind of odd, but the most useful (and fastest) way I've found to use them in a multiplexer is (funnily enough!) to use them exactly how you do on a 64 Odd isn't it, that I have to make the A8s better collision emulate the VICs worse collision to get better performance

 

I'm not on either side with this, just saying that you're voicing an opinion on the 64 without properly understanding how they can be used properly..

 

I have to fess up and say that it was only in the last 12 months when I went back to some 64 coding that I realised myself just how useful the collision registers are when used correctly.. On the games I wrote in the 80s I never used it.. But on my recent 64 dabblings I was looking for collisions for different PoCs of between 32 and 64 sprites and software wasn't cutting it, and then it clicked just how to use the 64s collision stuff properly (which also led to entirely different and faster model of handling collisions logically), so (no offence meant here) it's no surprise you don't see how useful they are in the real world..

 

So.. My opinion.. If you're programming in BASIC or just using players/missiles once per frame, then fine the A8 collision does all you want and more and is way better than 64s collision.. But throw in multiplexing, underlays/overlays PRIOR stuff and those collision registers aren't exactly a lot of help amidst the collision armageddon that's happening on the screen and you end up spending addtional time reading registers around and processing that data to essentially get to the same solution the 64 just hands you..

Edited October 6, 2009 by andym00

[+Philsan]

If all hours put in this topic, where put in homebrewing, you would get a lot of cool games.

 

i'd like to think the A8 game i'm writing simultaneously to posting here will come out quite cool when it's done, i can't speak for the Atarians though...

 

 

I agree with Roland.

But if this thread can be a sort of amusement for someone while programming, well, long live to this thread!

[andym00]

Yup, Hard Drivin' is piss poor... but i don't remember anyone arguing that everything on the C64 was good and there's not even an A8 version to compare it to - considering your opinion of A8 programmers, the odds are it would've been equally pants had they done a port.

 

There was a NES version in development that used character based techiniques and it looked mightily impressive.. Many of those techinques could have made it to the 64 version (if it had come first) for a far better framerate.. Though technically it was no longer a complete drive anywhere thing any more, you were fairly limited how far off the road you could travel.. I even (for fun over a couple of days, well more in the hope I'd get to do a PCE port of it) ported the technique over to the PC Engine, where it's 7Mhz processor made mince-meat of it and the hence ran at 30FPS without any real optimisation.. I've always been curious how that techinque would have been recieved versus the abortion that shipped on the 8bits..

A8 would have been stuck a bit.. The 128 character character sets would have meant far far more data copying around over the split sets, so would have been slower than a 64 version.. Just for the record

Edited October 6, 2009 by andym00

[emkay]

Again you're making calls on programming without anything even approaching the knowledge to back them up.

 

Well, I don't need to get into a car and to race against the next stonewall, to know that a crash will happen.

Do you need to do so to know it? Then you're having the problem, not me

[emkay]

A8 would have been stuck a bit.. The 128 character character sets would have meant far far more data copying around over the split sets, so would have been slower than the 64 version.. Just for the record

 

Hey, TMR , this is a very good example of drivelling.

[Bryan]

 

Bryan mentioned early VIC II chips did not alternate the color phase.

 

I don't quite get this...

 

I didn't think NTSC did any such thing anyway... on PAL, you have to keep the Phase Alternation in step otherwise you get the wrong colours.

 

I think it was established that GTIA doesn't do Phase Alternation, it's supposedly done externally. It came up a bit when I was developing the Interlace (480i) mode... in some cases I'd get every second field with the wrong colours, and it was because I was sending too many Sync pulses which upset the even/odd, up/down relationship that a PAL TV expects.

It gets confusing...

 

On NTSC, you set the phase (PLL) with the colorburst then the color is always determined by the degrees of shift from that reference. You can change the reference phase from line to line to keep the color signal from forming vertical bands in the picture.

 

On PAL, the colorburst reference changes its relationship to the color signal from line to line, so that any HUE errors tend to blend and cancel rather than being uniform over the screen.

 

In other words, both systems let you pick any reference phase once per line, but on PAL it's relationship to color alternates from line to line.

 

I hope that made sense... It's 6:30 AM.

[analmux]

C64 has no better collision detection. Atari has 60 bits in hardware to check for any 'Player or Missile' to 'Player or Playfield' collision. The GTIA (chip in A8) wins hands down compared to VIC II (chip in C64) on this.

 

It doesn't.. Reading your docs and measuring bits maybe, but in the real world ?

Okay, technically better, but practically it's debatable and mostly a moot point since your players normally spend most of them time underlaying/overlaying software sprites or combined with other sprites or being used to provide additional colours on the background, it's not a whole lot of use in all practicality those 60bits..

On the other hand, VIC collision is simple but straight forward and useful.. Not a whole lot useful when examined once per frame (which is the only advantage the A8 has on this count), but when you grab the collision register at the end of each displayed sprite on the screen (in your multiplexer) you have all the information that you could ever wish for, all handily packed up into a nice 8bit value

 

On the A8 it's kind of odd, but the most useful (and fastest) way I've found to use them in a multiplexer is (funnily enough!) to use them exactly how you do on a 64 Odd isn't it, that I have to make the A8s better collision emulate the VICs worse collision to get better performance

 

I'm not on either side with this, just saying that you're voicing an opinion on the 64 without properly understanding how they can be used properly..

 

I have to fess up and say that it was only in the last 12 months when I went back to some 64 coding that I realised myself just how useful the collision registers are when used correctly.. On the games I wrote in the 80s I never used it.. But on my recent 64 dabblings I was looking for collisions for different PoCs of between 32 and 64 sprites and software wasn't cutting it, and then it clicked just how to use the 64s collision stuff properly (which also led to entirely different and faster model of handling collisions logically), so (no offence meant here) it's no surprise you don't see how useful they are in the real world..

 

So.. My opinion.. If you're programming in BASIC or just using players/missiles once per frame, then fine the A8 collision does all you want.. But throw in multiplexing, underlays/overlays PRIOR stuff and those collision registers aren't exactly a lot of help amidst the collision armageddon that's happening on the screen..

Well, using different criteria of comparison, things always turn out differently. Just looking at the hardware specs, there are more possibilities using A8 collision features. It's up to the user to make good use of them. Specific usage will always distort the comparison.

 

When we have multiple collisions of VIC-II sprites, we can't figure out which one collided which other. You'll have to find out manually. F.e. collision of sprite 0 & 1, 4&6 will write 01010011 to register 30 of VIC. Now it's up to you to find out which of them collided with which: At least 3 possibilities: 0&1 and 4&6, or 0&2 and 1&6, or 0&6 and 1&4, or even a cobination. That won't be the case on GTIA. GTIA doesn't have that problem.

I.e. the hardware spec itself is clearly better.

 

But, using arguments similar to yours we could say f.e. Pokey only has 11 relevant registers, vs. SID with 32 registers. Software using Pokey will be simpler than software using SID....but we both know SID has finer control for its sound/music features. It's up to the user to make it simple or complicated.

 

We could as well have advantage of PM underlaying software sprites. There's no such thing as gfx to gfx collision, but underlaying a pair of swsprites with players (or missiles) we have immediate collision control. We could as well to PM underlay under static parts of a playfield part in a gameplay scenario, etc.

[andym00]

Well, using different criteria of comparison, things always turn out differently. Just looking at the hardware specs, there are more possibilities using A8 collision features. It's up to the user to make good use of them. Specific usage will always distort the comparison.

 

Of course, and I assume we're talking about games and techniques that push the hardware.. If we're not and are in fact talking about basic use of the hardware and not from a gaming point of view then just say so and you evidently are correct..

 

When we have multiple collisions of VIC-II sprites, we can't figure out which one collided which other. You'll have to find out manually. F.e. collision of sprite 0 & 1, 4&6 will write 01010011 to register 30 of VIC. Now it's up to you to find out which of them collided with which: At least 3 possibilities: 0&1 and 4&6, or 0&2 and 1&6, or 0&6 and 1&4, or even a cobination. That won't be the case on GTIA. GTIA doesn't have that problem.

I.e. the hardware spec itself is clearly better.

 

Yes, and just by storing the collision results at the end of each displayed sprite (coincidently the time we load the next sprite) we're only seeing collisions that have happened since the last sprite was started, resulting in a known number of bits in the collision register being of interest, specifically those X bits to the left (or right) of us.. And maintaining the eor'd version in the next interrupt, you can at any point, check the number of multiple collisions with one lookup, and (as in 99% of cases) if there's one, then it's a lookup and a load to get the collision result.. In this case it's faster since we only have to process only one byte of information.. If there's multiple collisions we have to process more (but in these cases it's more passes of the same data stepping back by one in the array to resolve it)..

 

Now, onto the downer.. I found (even on the A8) having all the collision registers packed into one, led to a faster collision resolve.. But that's not counting the additional cycles spent reading those registers, which isn't insignificant.. With 64 sprites, you're looking at per sprites reading 4 registers storing them, and clearing the collision register, so minimum of ~36 cycles (versus 8 on 64).. And that's assuming you're only interested in Player to Player collisions, you throw the Missile to Player collision registers in there as well (for a total of 8 moving objects) and you're expending ~68 cycles just to read your collision registers each time..

 

My point is this.. With 64 sprites (only player to player collision), you've got an instant cost of nearly ~2300 cycles which is just the data moving cost of your collision registers before you've even started to process them.. On the 64 it's more like ~512 cycles.. You're ignoring the fact that every data move on this pissy little processor costs us, and some techniques don't scale well.. Having collision registers like you have is great, but there's times when they're not the best solution..

 

And with that brings one of my bugbears with the A8 since I've started programming it.. The additional cost incurred in baby-sitting the players makes them really very unattractive.. Not only the copying cost involved just to setup a tiny 8 pixel wide object.. But then the cost incurred reading the collision registers for it..

All round this is one thing the 64 does so much better.. In what I'm writing at the moment I'm spending half my available time baby sitting bloody Players.. A 16 byte Single Colour object that incurs a total of ~200 cycles each frame is bordering on being useless from my point of view.. Even if they were bigger they still make you pay through the nose by the baby sitting required.. The only reason you have to go that route and pay that cost is to make things more colourful, one extra colour (or 2 extra shades) in a sprite for all that cost! I understand now why the A8 has that certain distinctive look about it in many games now..

Anyway, that's just todays gripe that one

It feels like the A8 is kind of stuck in the middle.. Just not enough CPU power to really drive the players really well, and just not quite enough to bang out a lot of software sprites.. I might as well ramble a bit here, because I've been trying to implement the scrolling now, and getting increasingly flustered by the 4K limit on the screen.. Once you get a really good sprite routine that meets your requirements, you find that it's increasingly hard to handle the split in the screen addresses sensibly when they cover the line where you need to force the screen to wrap, unless you use nice screen widths, which chomp through memory like there's no tomorrow.. Unless you go for Narrow mode, which is lovely, and would do the job fine, but then that means waving goodbye to you missles since otherwise it means an additional 2 cycles in the Player copying to mask the copied data.. Some amazing stuff is possible, but the machine doesn't go out of it's way to help you at all in anyway, but I'm sure it's just a case of finding its sweet spot and utilising that to the max.. And it's become very clear now why a lot of stuff hasn't been done on it..

Anyway, rant over

 

But, using arguments similar to yours we could say f.e. Pokey only has 11 relevant registers, vs. SID with 32 registers. Software using Pokey will be simpler than software using SID....but we both know SID has finer control for its sound/music features. It's up to the user to make it simple or complicated.

 

My argument didn't say quite that.. It simply said that there's a disparity in cycles expended resolving a collision to the virtual sprites involved.. And I stand by that.. That in heavy sprite use scenarios the 64s collision provides the same information at the end of the day with less cycles expended on the task..

 

You stated the rather arbitrary point of view that the A8 collision is better.. You didn't say under what conditions.. I merely contested that (in the domain of high performance games) that they's not much in it in reality..

 

You then decided I was being too specific.. Obviously there's scenarios where the A8 collision is better, in fact most simple uses of them it's better.. But forgive me I'm wrong but we're not talking about simple uses are we ? If we were the whole made-up screen debate would have been much shorter, and like-wise the sound debate would have been shorter.. The direction of the discussion implies we were discussing cutting edge techniques to push the hardware to the max..

 

We could as well have advantage of PM underlaying software sprites. There's no such thing as gfx to gfx collision, but underlaying a pair of swsprites with players (or missiles) we have immediate collision control. We could as well to PM underlay under static parts of a playfield part in a gameplay scenario, etc.

 

Of course you could, in fact I think you'll find I already pointed that out.. And of course playfield to playfield collisions are pointless, if not infact actually impossible since neither platform has multiple playfields Though not doubt there's some GTIA malarkey that allows that

Underlaying you only have full collision control if the underlayed sprite contains a suitable collision mask shape.. If you're implementing wacky PRIOR modes, the underlayed/overlayed sprites won't necessarily contain the collision shape you're interested in because of graphical shortcomings.. Even more so with expanded sprites..

Edited October 6, 2009 by andym00

[TMR]

Yes, i know it's a UK magazine... i've been writing for them since issue 51, it's sort of hard to avoid noticing after about eighteen months. =-)

 

Yes, I know that there are some really unknowledgeable people working for that mag

 

And you have no idea if i'm "really unknowledgeable", so that's just a petty little insult.

[ANTIQ]

Of course you could, in fact I think you'll find I already pointed that out.. And of course playfield to playfield collisions are pointless, if not infact actually impossible since neither platform has multiple playfields Though not doubt there's some GTIA malarkey that allows that

 

I've been looking at the GTIA schematics and I think I've found a way of making it generate a truecolour mode at a resolution of 1x1 pixel.

[TMR]

Again you're making calls on programming without anything even approaching the knowledge to back them up.

 

Well, I don't need to get into a car and to race against the next stonewall, to know that a crash will happen.

Do you need to do so to know it? Then you're having the problem, not me

 

What a stupid analogy. Of course we don't need to crash a car into a wall to see what happens, but that's because we've seen the results enough times to be able to work from that knowledge; in the case of copying data around, the CPU on the A8 isn't even twice the speed of the C64 so your guess that it'd somehow be able to refresh things four times faster is the equivalent of expecting the car to burst into song.

[andym00]

I've been looking at the GTIA schematics and I think I've found a way of making it generate a truecolour mode at a resolution of 1x1 pixel.

 

Given the lunacy that's been ever-present in this thread I have no idea if you're joking or not

[roland p]

But if this thread can be a sort of amusement for someone while programming, well, long live to this thread!

That's right. The irony is, while arguing which computer is the best, is that the limitations of these computers is what makes them interesting. But maybe this is already mentioned somewhere in this thread.

[frenchman]

Yes, i know it's a UK magazine... i've been writing for them since issue 51, it's sort of hard to avoid noticing after about eighteen months. =-)

 

Yes, I know that there are some really unknowledgeable people working for that mag

 

And you have no idea if i'm "really unknowledgeable",

 

Well judging by some of your replies so far.....

 

but if you are one of the few knowledgeable contributors to RG, glad to hear it.

Edited October 6, 2009 by frenchman

[emkay]

What a stupid analogy. Of course we don't need to crash a car into a wall to see what happens, but that's because we've seen the results enough times to be able to work from that knowledge; in the case of copying data around, the CPU on the A8 isn't even twice the speed of the C64 so your guess that it'd somehow be able to refresh things four times faster is the equivalent of expecting the car to burst into song.

 

 

Well, 60Hz Ataris ARE 3 times faster in RoF than the C64. RoF is bound on vertical sync on the A8 , while it runs free on the CPU on the C64. Changing this fact will make RoF on the A8 even quite faster. Using the more freed cycles of the PAL A8, will result in ~25% speedup aswell.

Possibly the PAL Version of RoF could run at even more than 4 times faster than the C64 version.... easily.... and without additional tricks, such as using charmode movement or else.

 

A custom mode with 4x4 pixel (80x60 res.) will add the 16 colours for the 3D scene, and it will run even faster than the 2x2 pixel gr. 7 ....

And, if all will not help, we can use the double height charmode, or a charmode with only 20 bytes of DMA per scanline.... or a low res one bit mode.... or.... or....

Edited October 6, 2009 by emkay

[TMR]

Yes, I know that there are some really unknowledgeable people working for that mag

 

And you have no idea if i'm "really unknowledgeable",

 

Well judging by some of your replies so far.....

 

Ah, so you feel that because i dared to disagree with you that makes me "really unknowledgeable"... not much ego going on there, then.

 

but if you are one of the few knowledgeable contributors to RG, glad to hear it.

 

In other words, you were trying to insult me without even being aware of which bits of RG i write... i'm not surprised in the slightest of course and, as i said, it was a petty insult on your part.