Debunking De debunking TMR’s anti C128 “less monitoring”

Recently, on the blog , which actually helps this blog get more publicity, TMR, who is fluent in 6502 Assembly Language, can probably remember all the hundreds or thousands of significant memory locations to POKE and PEEK on the Commodore 64, and may also have memorised the logarithmic tables…

Oh dear, more cheap “insults” from the author. Your correspondent has never memorised a logarithmic table and couldn’t actually explain what one is without some research, but can’t see why that would be a particularly bad thing to have memorised. And no, your correspondent doesn’t claim to know all of the hundreds (not thousands) of register locations on the C64, just the ones he uses on a regular basis.

We do have to note in passing that having traffic doesn’t make the content of the author’s blog any less useless, especially since most of the people your correspondent sends over are just going to laugh at the more moronic statements being made; of course, correcting those mistakes doesn’t make your correspondent “anti C128” or indeed anti anything for that matter.

Similarly, lots of or even most C64 Assembly Language routines are located at $C000, so we can call this address Code block.

Unsurprisingly, the author is yet again writing from a position of ignorance; $C000 is commonly used for assemblers and monitors so only a relatively small proportion of software developed without cross assembly actually resides there. It’s a fairly popular space for machine code supplements to BASIC because the interpreter doesn’t use that space, but machine code programs don’t have to worry about the BASIC interpreter.

We’ll just skip lightly over the pointless reminiscing about shops in London to get to…

I wrote that most Apple ][ software was written in BASIC. I was actually talking about applications, not games.

The author originally claimed that he had “recently heard that Apple ][ programs were often or even mostly written in Applesoft BASIC” so no, he wasn’t discounting games. But even if we take into consideration the author’s rather pathetic backpedaling for a moment to note that it still doesn’t hold water because the article at the Apple II history website he points to merely states that a “large library of Applesoft-specific software” was available, that doesn’t comment in any way on what percentage of the entire Apple II library was in Applesoft BASIC so the author’s claim remains debunked.

I never said that I approved of Commodore failing yet again to provide BASIC commands to control new hardware. I was just stating a fact.

But, dear reader, the author failed to highlight it in the way he does with the C64’s BASIC so his bias is still there.

We’ll have another light skip over the author’s uneducated opinion of VDC programming books because that isn’t relevant to the point at hand either and, since he hasn’t actually programmed for it yet, useless.

 Of course, Commodore were making a big profit on every C64 they sold. According to ads in old magazines, the Commodore 64 was selling in Britain during 1983 for around £344, then came down to £199 in 1984.

This is quite interesting; the author believes that Commodore made a “big profit” but…

Commodore owned the chip manufacturer MOS who made most of the chips in the C64, and there’s no real way of knowing how much profit they were making on it.

can’t actually prove that claim because he’s got nothing to back it up with.

A lot of the Commodore 64 computers sold in Britain were actually made here, so they avoided import duties as well.

Commodore also built the Corby plant to assemble C64s in the UK so that cost had to be factored into each unit’s price tag; not paying import duties doesn’t necessarily mean there’s a “big profit” being made on those machines at all.

 It would certainly have been possible to produce a computer with at least some of the features of the C128 as prices of RAM and other costs came down, but Commodore didn’t do this, because they just didn’t care. Sinclair discontinued its 48K Spectrum, replacing it with the Spectrum 128K, Atari replaced its 400 and 800 models, replacing them with their XL range, while Apple had various upgraded versions of their original Apple ][ computer.

These two sentences are actually at odds with each other. Sinclair, Atari and Apple’s first machines with 128K “out of the box” were the Spectrum 128 (released 1985 and the 48K model wasn’t discontinued on release), the 130XE (again 1985 and a 64K machine was available too) and the Apple IIe (a bit earlier in 1984). Presumably these companies “didn’t care” either since none of them had a machine shipping with 128K when the C64 was released and two didn’t even have a 64K model at that time.

Just to reiterate, your correspondent said that a machine like the C128 wasn’t commercially viable when the C64 was released and not that it wasn’t workable technically.

I’m basing this on the examples in the book “Machine Language foe Beginners” on , as well as the knlowledge that software houses often or usually developed software for various computers which shared the same or compatible processors.

So not using any actual experience or knowledge of the machines in question then. Again this is almost painfully naïve because, unless the plan is to create something hideously simple that just PRINTs simple text strings to the screen, large chunks of the code will need tailoring for specific platforms.

TMR wrote…

“The irony is that in the author’s fantasy the Spectrum Simulator couldn’t save or load files in a form compatible with a real Spectrum whilst in reality it could do exactly that; BASIC programs or even SCREEN$ files could be exchanged between the two machines”.

It’s a pity this wasn’t widely known. This information was obviously covered up!

Yes of course it was covered up because nobody would want the masses knowing the facilities of a piece of software like that so the government/GCHQ/Commodore/[delete as applicable, check for tinfoil hat] made sure the information didn’t go any further than the program’s user manual, the copy of a couple of internationally published magazine reviews or amongst users. Your correspondent had to sign the official secrets act, perform three secret handshakes and know two very cryptic passwords just to read about it in the manual!

Your correspondent doubts that you, dear reader, need to be told that the previous sentence was sarcasm but we shall mention it for the author’s benefit. We are talking about a fairly obscure bit of software of course, but people with an interest in the simulator had a couple of means to find out what it was capable of; your correspondent merely asked to read the manual in a local computer shop for example.

I read that even the Commodore 16/Commodore Plus/4 cassette data recorders were incompatible with the C64, which prevented me from buying a third party extended BASIC that was “language compatible” with BASIC 3.5.

They were incompatible in the sense they had a different connector on the computer’s end of the cable, but a C16 cassette unit with an adapter works on a C64.

Your correspondent can’t vouch for being able to load 264 series BASIC programs into an extended BASIC on the C64 however, that would depend greatly on if the extension was properly compatible or not.

The BBC Micro, and Amstrad CPC both used the 6845 video chip, which the Acorn Electron used a compatible chip. These chips all had a feature called “individual pixel clarity”, meaning that however many or few colours there are on the screen, each pixel can be any one of these colours, regardless or what colours the neighbouring pixels are.

And as your correspondent has already said there is a trade off for that flexibility; the display takes significantly more memory so requires more CPU horsepower to process.

This means no colour bleed, although the Commodore 64, Spectrum, and Commodore 128 all had this. MSX computers, as well as other computers which used the same or compatible Texas Instruments 9918/9928/9929 video chip, also suffered from colour bleed/attribute mode, but only in horizontal 8 pixel lines, instead of 8×8 pixel squares. These are all  much better systems than the Commodore 64.

The Spectrum only has a 256×192 display and limits on which two colours from its range can appear in each attribute cell so no, that’s not “much better” either. If the author perhaps spent some actual time programming on these machines rather than trying to make himself appear knowledgeable with random snippets of information from the internet and some very poor guesswork…

(Amusingly, the author has also stated the quoted paragraph that the C128 is “much better” than the C64 despite having the same system.)

TMR wrote…

“The VDC has only two colours per 8×8 pixel attribute cell, but they’re half the width of the C64 ones and it’s worth remembering, however, that all of the other machines with a comparable mode (the Amstrad CPC or BBC Micro for example) only have two colours where the C128 VDC has sixteen”.

I haven’t been criticising the VDC, because that chip wasn’t used in the Commodore 64, so this comment is irrelevant.

The author had previously commented that he hadn’t “seen any display from the higher resolution VDC chip” but mentioned that it was “approaching 16 bit graphics quality” so your correspondent’s comment was relevant because it was rather helpfully correcting that glaring mistake. The author still mistakenly believes that your correspondent is limited to directly responding to his gripes.

It’s not possible to use just the RUN STOP key without calling $FFE1. I’m writing fairly simple 6502 Assembly Language programs so far, which means that I don’t want to reset everything by pressing RUN STOP and RESTORE.

It is possible and there are many programs reading the key without $FFE1 because they’ve disabled the Kernel ROM where that subroutine resides. What the author is struggling to understand is that his program is dealing with the Run/Stop key and handling the ungraceful quit to BASIC, $FFE1 merely provides the trigger for that.

Finally, TMR shows us a screen shot of five POKEs to consecutive RAM locations starting at 8192, followed by a SYS 8192 call, which cause a flashing ripple border effect. I think this shows clearly how difficult Commodore BASIC V2 on the C64 is to read and understand and how 6502 Assembly Language is easier in this case.

It was six POKEs rather than five and if it proves anything at all it’ll either be that things stick in a person’s memory with enough repetition or possibly that the author doesn’t really understand what’s going on; the program was 6502 machine code, BASIC was merely the delivery mechanism so the readability is completely and utterly irrelevant.

Well, since we’re going to have to do this almost painfully slowly for the author’s benefit, here’s a similar program entered with a passing copy of John Twiddy’s DisMon (a monitor with one pass assembler available as a type-in listing). We should note dear reader that DisMon lives in that $C000 area of memory and that it traps for the Restore key so there’s no need to check Run/Stop:

INC $D020 / JMP $2000

INC $D020 / JMP $2000

I hope to crack the Commodore 64’s secrets in the near future. I now see this as a challenge to restore my confidence before I move on to bigger and better things. This may include writing a replacement BASIC for the C64, which could be similar to the BASIC on another computer, instead of Commodore BASIC 3.5. It should run faster than extended BASICs, because C64 BASIC is very slow.

This is probably the single funniest thing the author has ever said. It really isn’t worth holding your breath dear reader, the C64 will probably be old enough to claim a bus pass before this happens.

This entry was posted in Debunking and tagged , , , , . Bookmark the permalink.