TMR of the blog “C64 Crap Debunk” has recently been making posts about an Apple ][ demo called “Lantern of D’gamma” https://c64crapdebunk.wordpress.com/2016/05/12/code-notes-lantern-of-dgamma/ , as if this is supposed to somehow prove that the C64 isn’t crap. I’ll try to explain here why this is totally irrelevant to the C64.
It was established well before the author started posting to his pathetic little bash blog that the C64 wasn’t crap and nothing written there since has done anything to change that. The only person who seems to have a problem understanding that is the author and, it has to be noted, that he struggles to comprehend quite a few other things too; for example, we’ve noted on a few occasions previously that your correspondent doesn’t have to stay within any boundaries defined by the author when posting here but that still hasn’t sunk in!
Whilst there’s not much point explaining for the author, we’re examining programs from both the C64 and its contemporaries because, if the C64 is supposedly “so difficult or impossible for [him] to program” in comparison to other “amazing” platforms, it makes complete sense to look at some of the user-created programs on said computers as well to see how the amateur programmers fared.
Unfortunately, the basic Apple ][e had only a beeper instead of a synthesiser chip, so it wasn’t what I was looking for. It would have been even more expensive to buy an upgrade on a a plug in card.
And the author would have needed to use POKE commands to program said expansion card, although that fact is apparently being ignored by him for some reason and your correspondent rather sarcastically wonders why that would be…? Perhaps because the author would have to admit that the computer he described as “amazing” has similar issues to the C64 when using sound from BASIC.
In the USA, Apple ][e users could plug into a TV and get colour graphics. I thought the computers and their green screen monitors looked quite professional, but I didn’t know that they couldn’t display colour on European PAL TVs without a graphics card.
That colour is generated through NTSC artefacts and it’s a more difficult system to work with compared to something like the C64’s multicolour character of bitmap modes since two set bits next to each other will always produce a white pixel regardless of if they start in an odd or even column of the display! Your correspondent wrote a quick and very dirty conversion utility for images which was used for F15 D’Gamma Clone, but it only partially takes these extra caveats into consideration.
The Apple ][e had a 32K ROM compared to the C64’s total of 16K ROM, including BASIC and an Assembler/Monitor, but as the system was mainly or entirely disk based, it was possible to load other versions of BASIC and other languages from disk.
Please remember dear reader that similar disk-based alternative languages were also available for the C64 but, despite ranting about them quite frequently in the past, the author has rather conveniently “forgotten”! There’s also a simple but rather worrying mathematical error in the above paragraph as well; on the C64, 8K of BASIC ROM plus 8K of Kernal and the 4K of character ROM – the author mentioned it in another post from the same day as the one we’re covering so presumably hadn’t already forgotten – is 20K rather than 16K.
 The utility isn’t “user friendly” either, in the same way a feral dog wouldn’t be considered “good with children”. Your correspondent has pondered rewriting it from scratch to make things a little easier to work with, that still won’t take all the Apple II’s quirks into consideration but might at least be approachable enough to release to the public. Possibly.