DE BUNKING TMR’S “THE AUTHOR’S GRIP ON REALITY SLIPS”   5 comments

DE BUNKING TMR’S “THE AUTHOR’S GRIP ON REALITY SLIPS”

A little C64 demo which prints a greeting and flashes the border

TMR has had the cheek to try and debunk my last post “TMR GIVES THE GAME AWAY!” in his childish post on https://c64crapdebunk.wordpress.com/2015/09/16/the-authors-grip-on-reality-slips/

In spite of refusing to list any programming techniques on his blog (apart from one video of a polyphonic piece of music without a breakdown of the program) for three years now, He has also had the cheek to finally claim that he has been releasing source code for nearly twenty years, although when I was looking round to find out how someone might have been able to learn to actually program the C64 if that was their only computer not long after it was released, I couldn’t find any really useful source code and none by TMR.

In his debunk, although there are no graphics in his 20 column scroller, he confesses that some graphics he did for the C64 (I don’t know what graphics he means) “were created with Pro Motion on Windows”, so this is obviously CHEATING, because I’m only interested in what people could have achieved and how it was done with what was available to them up until the time I sold my C64 in about April 1985. I seem to remember reading somewhere at the time I owned a C64 about a technique to create larger text, but I don’t think this was in Assembly Language.

There’s some more source code of another demo by TMR on https://github.com/C64CD/Hello-Github-C64/commit/65f3cf2be7ed3f6da180b4c26f36221583b04c42 , which seems to contain a greeting, sprites and music, but I haven’t got my Commodore 128 set up at the moment, so I haven’t run it.

Optical illusion

Are you losing your grip on reality?

On September 1, 2015 I was shocked to find a short Commodore 64 Assembly Language course by TMR (who makes no secret of the fact his real name is Jason Kelk), called “The Hex Files”, which starts on http://www.oldschool-gaming.com/view_article.php?art=c64_hex_files_1 and may have been written in 2004. I think everyone reading this should visit that site and save it to their hard drives before it gets deleted. This 9 part course introduces readers to Assembly Language programming on the C64, as well as including techniques on how to print text on the screen, and even write a scroller, complete with sprites and music! He doesn’t explain what led him to this knowledge, though. Unfortunately, I’m not sure how anyone would move on from just printing or scrolling text, displaying sprites and playing some music. I wonder why the course stopped after 9 parts as well.

Jack Tramiel

Jack Tramiel the main culprit

Obviously, Commodore and Jack Tramiel in particular, f***ed things up pretty badly with the Commodore 64. They should have included documentation with every single Commodore 64 which started off something like “Dear Commodore 64 Owner, I hope you enjoy programming and using your new Commodore 64. Unfortunately, my way of doing business means that I could only justify the expense of including an old version of the programming language BASIC with the Commodore 64, because I got a good deal on it from Microsoft way back in 1977, when computers had only LED, printed out, or at best monochrome screen displays and weren’t designed to play music, although a few people managed this. The improvements we’ve made since then don’t include any commands for writing programs which use the colour, graphics, or sound on your Commodore 64, so you can only use this BASIC to write programs that are text only, although the text can be in various colours. To use 16 colour graphics, play sound effects, music, and lots of other things we at Commodore haven’t even thought of yet, you must learn 6502 Assembly Language. You need a program called an Assembler to bypass your Commodore 64’s BASIC interpreter and write in mnemonics which stand for its native Machine Code language. We have included a simple Assembler on a cassette tape in the package containing your Commodore 64 to get you started. In the accompanying ‘Microcomputer User Manual’ you must read about how to get started programming in BASIC as well as getting started in 6502 Assembly Language. At the back of this book is a list of other books published by Commodore which will enable you to take things further with these languages if you choose to do so. Of course, you may decide not to continue programming, then you can still use programs and games written by other people. Yours faithfully Jack Tramiel”

Commodore never included any such documentation with the C64, so it was not only the crappy BASIC, but also their many convoluted, mind bending, nervous breakdown causing, Commodore BASIC V2 listings, each containing multiple PEEK and POKE commands, to do things that version of BASIC was never ever designed to do, which drove me and others to the verge of a nervous breakdown, making some people lose all interest in programming, or forcing them into selling their Commodore 64 computers to get a computer from another manufacturer complete with a reasonable version of BASIC. I remember my Dad asking me “How is it that some people have managed to write programs for the Commodore 64?”, meaning programs such as anything with graphics, etc which we were talking about. I replied “I don’t know”, then his conclusion was “They must be exceptional”. I now know that it was because they had been given information I hadn’t had. I feel much better knowing that it wasn’t MY fault, but the fault of Commodore, especially Jack Tramiel, for not supplying this information in their manuals. It was also caused by Jack Tramiel being too miserly to pay Microsoft more money or include the Super Expander BASIC, as well as my Dad being miserly by not coughing up £399 for a BBC Micro Model B, which I asked for, saving him about £200, but costing me an unknown amount of money in magazines, books, and software, as well as all the stress involved, to find out what a disaster the C64 was.

As for me, I chose the Amstrad CPC 464 computer (rebadged as Schneider CPC464 in Germany), but then actually ended up buying the improved, short lived, compatible Amstrad CPC 664. The built in Locomotive BASIC had over twice the number of commands as Commodore BASIC V2, and double the size of video RAM, giving it individual pixel clarity, resolutions of 160×200 with 16 colours, 320×200 with 4 colours, and 640×200 with 2 colours, all from a palette of 27 colours.

Now I’m finally going to face moving two desktop PCs around so I can transfer some picture and video files from my mobile phone and compact digital camera onto a computer I built running only the Linux Mint operating system, free of Windows altogether. I have to move two desktop PCs around because I have recently had to use an emulator to transfer some other files under Windows, both my laptop’s USB ports are broken and I can’t afford a replacement. Both my mobile phone and compact digital camera are full up, causing some of the files not to save properly and be corrupted. I can then delete the original files from these devices, creating some space to take pics of my MSX2 computer’s display on a CRT screen. After this, I’ll continue with my series “Oh, that would be VERY difficult!”, showing how bouncing sprites off each other and developing this into a game is fairly easy on MSX computers.

This blog has no means of funding, I’m actually quite skint or broke, and my life is in danger from eviction by a property speculator, probably taking place in January 2016. If you’d like to make a donation, please send me an email on paul.londoner@gmail.com , then I’ll tell you how to do that.

Advertisements

Posted September 17, 2015 by C64hater in Uncategorized

5 responses to “DE BUNKING TMR’S “THE AUTHOR’S GRIP ON REALITY SLIPS”

Subscribe to comments with RSS.

  1. ” I now know that it was because they had been given information I hadn’t had. I feel much better knowing that it wasn’t MY fault, but the fault of Commodore, especially Jack Tramiel, for not supplying this information in their manuals.”

    C64 came with “Commodore 64 Users Guide” that had information, one just had to apply it. Blame is not on commodore if someone were incapable to do so.

    Or do you believe on being privileged and everything should be handed to on silver platter?

    C64 manual did provide pretty much all information needed to produce atleast sprite graphics and music etc. There’s nothing wrong using Peek and Poke to achieve things, after all, it’s all just manipulation of certain hardware registers and memory adresses (be it basic command BORDER 0 on amstrad or poke 53280, 0 on C64).

    —–

    Commodore 64 User’s Guide (1982, commodore) ( https://archive.org/details/Commodore_64_Users_Guide_1982_Commodore )

    Chapter 5. ADVANCED COLOR AND GRAPHIC COMMANDS
    – give 16 color codes C64 had, from 0 to 15
    – give memory addresses for border. etc. colors
    – has screen & color memory map

    Chapter 6. SPRITE GRAPHICS
    – explain sprite graphics
    – give memory addresses for sprite registers
    – give VERY basic explaining of binary arithmetics for designing sprites

    Chapter 7. CREATING SOUND
    – explainADSR, waveform etc. information
    – give memory addresses for sound registers

    Appendices through A to P gave bit extra information and register maps etc.

    —–

    With information in those chapters of user guide you were all set to actually do something. You had register/memory maps, you had taught commands like poke/peek to manipulate those registers etc.

    If you wanted to do those things fast, __then you had to bother actually DO something by yourself__ and go beyond the scope of users guide. Like actually learn 6502 assembly programming from assembly programming manuals and also learn more about character/multicolor/hires graphics of C64 from other manuals intented for that.

    I agree though commodore should have provided atleast bit better list “what to learn next” after one was done through user’s manual. There is Appendix N with list of Bibliography to get you started beyond user’s manual , sadly stuff listed was not mainly for C64

    I do have to agree C64 basic was slow and lacking compared to some other basics of the time though.

    But then again… Basic, no matter what kind, was not proper or good solution to make truly realtime _complex_ graphics/effects on C64 (or pretty much any other home computer of that time) because CPU’s were slow and Basics were mainly interpreted so they added slowness to things. There are some exceptions to those, like Atari ST had GFA Basic, Amiga had AMOS…

    Don’t blame the tools if you can’t be arsed to do something by yourself and learn how to use em.

    Old C64 etc. programmer
  2. The Commodore manuals are very poorly written. The accompanying manual doesn’t seem to mention hires graphics at all. The Commodore manuals I had were the accompanying Microcomputer User Manual, An Introduction to BASIC (Parts 1 and 2) and the Programmers’ Reference Guide. These manuals all described the nightmare of using lots of PEEK and POKE commands to create colour, graphics, and sound. The nightmare started with POKE 53280 and POKE 53281 for the border and text screen background. If only a handful of POKE and PEEK commands were required, like on Sinclair ZX Spectrum and Atari 8 bit computers, then that would have been OK, but it seemed there was NO END to the number of 5 digit memory locations I was supposed to remember to do things covered by simple BASIC commands on any non Commodore computer. I bought third party books, hoping desperately that one of them would enable me to understand my C64, but it was always the same story of a long list of PEEK and POKE commands. Once computers started having disk drives built in, this allowed all users of those particular computers to load programming languages from disk. If the C64 had come with a built in disk drive, then it would have been quite different. The Amiga was supplied with AmigaBASIC, which was discontinued in 1991-1992, but it wasn’t that difficult to get hold of a copy from somewhere if you bought an Amiga without it. The Atari ST was supplied with ST BASIC, which was capable of creating colour, graphics, and sound using its own commands, but was buggy. Obviously, that evil miser Jack Tramiel was also responsible for this. Some time later, Atari STs were bundled with GFA BASIC. I recently saw a video by Dan Wood of Kooky Tech which revealed that there was actually a version or distro of UNIX specially written for the Atari ST, but then Jack Tramiel was so tight fisted that he refused to pay the price for it, so that was why it came with CP/M 68K rebranded as TOS with the GEM Desktop. This makes THREE computers Jack Tramiel fucked up! First of all the VIC-20 with crap Commodore BASIC V2, followed by the C64 with the same crap Commodore BASIC V2, followed by the Atari ST with a hastily cobbled together design and a recycled CP/M (i.e. from a much less powerful CPU) instead of a powerful UNIX operating system, which although not a custom OS was much more fitting for the 68000 CPU. What a TOSser!

  3. “it seemed there was NO END to the number of 5 digit memory locations I was supposed to remember to do things”

    Not really that many at all.

    For example SID chip for sound had 29 registers and they are at one continuous block from 54272 (Hex $D400) to 54300 (Hex $D41C).

    Of those 29 registers three blocks of 7 registers had same function but just for different voices of the SID chip so all one had to remember was 7 registers and continuous block they were in memory. Rest had volume, filter etc. data and also 2 of SID registers were actually to read potentioneter values from paddles.

    So there were not that much to remember really for SID.

    Video chip had 47 registers. Of those 47 registers first 16 registers hold just simply coordinate pairs for screen location for hardware 8 sprites. 8 registers also hold color for each sprite. So that already is over half of the registers for 3 things only
    – x-coordinate of sprite
    – y-coordinate of sprite
    – color of sprite

    Besides those there are few registers to expand sprites in X and Y direction, etc. Two hardware scroll registers. etc.

    To change different graphics modes all one needed was to learn meaning of __THREE bits__ in __two registers__, 53265 ($d011) and 53270 ($D016).

    Besides those, if wanted/needed one had to learn one register 53272 ($d018) to select memory location of:
    – Video memory base address (character screen memory)
    – Bitmap base address (bitmap screen memory)
    – Character set base address (character set memory)

    And if further necessary, two bits of register 56576 ($dd00) to select memory location for 16kb video memory.if default was not suitable for you.

    Bitmap/character color memory is always located at 55296 ($d800).

    It wasn’t really any challenge to learn few register locations and few bits in those registers.

    Drawing pixels to hires screen required also knowledge of basic basic operations of arithmetics I assume they taught even there in schools.

    If one was incapable of remembering few registers and using reference manuals, one could always make very simple “cheat sheet” to some piece of paper.

    It didnt require rocket sciency really.

    I was around age of 12 to 14 (1984-1986) in that era when I learned all that stuff from very sparse resources I had access at back then (living middle of nowhere, podunk lil shit place, in Finland). I would have killed for “Commodore 64 Programmers’ Reference Guide” back then to ease up things.

    All I had was manual that came with C-64, photocopies of photocopied 6502 instruction set with OP codes to learn assembly language, few pages of photocopied articles from some foreign language (to me english was/is foreign) computer magazines explaining c64 video modes and metric fuckton of notebook sheets to “write code” down and then translate to numbers so I could poke them to C64 memory and see what happen.

    Luckily I managed to get hold of some machine language monitor (might been Jim Butterfields Supermon64 from Compute! magazine published early 1983) so things got easier. Later I got Laser Genius from Ocean, it had proper assemblers and all… But that point I had also moved learning Atari ST and 680×0 assembler etc…

    Only reason I ended up in your site was because I was doing some random googling and found your complaints of your failures, and passing blame for those to others, rather amusing 🙂

    Random googling was sparked after I did find few of my old papers from that era with 6502 asm code/routines I was “planning” on paper back then, and some sprite graphics I was designing for own games I was making. Also found some ancient tapes I saved some those early stuffs and some day I actually bother to see if any of that still works… I know atleast some floppies should have later game or two, crack intros and demoscene stuff I used to code at 80’s and 90’s and I have to get into those some these days to see if any of that stuff really has survived…

    So, learning few registers and few bits in them should not have been any real challenge. Me and countless number of others manged to just do that back then. And many of us didn’t even have luxury of getting hands on Programmers’ Reference Guide etc. in the beginning, just to some photocopies of computer mag articles. Roots of computer demoscene were concieved on those times by regular people just learning and not lazily passing blame of own failures to others…

    Thing could have been better, and commodore could have done better job, but in the end BASIC was always a wrong tool to really create realtime graphics etc. running 50 frames a second on C64 etc. anyway.

    As I said earlier, don’t blame the tools if you couldn’t be arsed to actually LEARN something by yourself, but demanded everything should have been handed to you on a silver platter…

    Old C64 etc. programmer
  4. Moi! (Finnish greeting) You point out that the SID sound chip has 29 registers and the VIC-II has 47 registers. That’s a total of 76 registers. It doesn’t say in the user manual or Programmers’ Reference Guide anything like “It might seem like you have to remember lots of numbers to use with PEEK and POKE, but actually you only have to remember 76 memory locations”. This is because the PEEK and POKE commands aren’t limited to those 76 locations. There are even one or two books dedicated to PEEK and POKE on the C64. One of these is called “PEEKs & POKEs For The Commodore 64” by HJ Liesert published by Data Becker in 1984, but the English language edition by Abacus not until January 1985. You can find a copy on http://www.bombjack.org/commodore/books.htm under the heading General. This book is 197 pages up until the Index, so it’s no good pretending that a page or two listing some memory locations would be enough. As I lived in Britain, the original German edition of this book wasn’t available there, neither were any German computer magazines to tell me it existed or where to order it from. Of course, by January 1985, even if the book was imported immediately from the USA I was no longer interested in trying to program the C64. By that time, I’d realised that it was causing me unnecessary stress. I was just looking forward to getting my hands on an Amstrad CPC. When I said it seemed like there was NO END to the number of memory locations I had to use with PEEK and POKE commands, I meant it. They seemed to be all over the memory map. I knew that the total number of memory locations was 65,535. I thought that MOST of these memory locations were used with PEEK and POKE. There was no indication of what the limit was. I came to the conclusion that this would be harder than learning the full set of 40,000 Chinese characters. Not only that, but the commands PEEK and POKE were also used with AND as well as OR, followed by a number, but Commodore didn’t explain why this was. I now know it was to select registers. These are the reasons I gave up trying to program the C64 and sold it.

    • Ever considered that you were just not up for the task to remember few memory addresses? Or to learn anything simple for that matter? It’s not shame to admit your short commings you know…

      I mean, 29 SID registersonly… Of what 21 are just block of 7 registerstimes 3, so basically there are 7 different registers unique for each channel and then 8 global ones for all… And for VIC II almost same thing because most registers are just duplicates for sprite registers…

      Mind telling how you had to set things as Amstrads sounds for? I recall it had Sound command that took metric fuckton of parameters. Why you feel it was different to separate them just after SOUND command with comma, instead of just poking them? So why you feel parameters for SOUND command were any different than registers for SID? After all, under the hood it’s all same 🙂

      Funny that you were learning this all in middle of where you had access to all things you needed, and still yet and u failed… And me and others were learning this stuff in middle of nowhere, english as our 3rd language (no, just saying 1 word you know dont mean you know shit about finnish language, I can say “hi!” in english aswell 😉 and we managed…

      Old C64 etc. programmer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: