Debunking TMR‘s “Prepare To Operate – Part 2“   Leave a comment

Debunking TMR‘s “Prepare To Operate – Part 2“

C64orac

Orac, one computer from “Blake’s Seven”, was a talking computer with just flashing lights and voice control

TMR of the blog “C64 Crap Debunk“ recently had the cheek in https://c64crapdebunk.wordpress.com/2017/12/23/prepare-to-operate-part-2/ to debunk my excellent post examining operating systems in general and what they have to do with the Commodore 64!

I haven‘t actually written an operating system yet, but I think I may be able write one at some stage in the future. To do this, I have to look at what other people have done, what operating systems have in common, and how they work. It‘s possible to create your own custom distro of Linux, using kits provided by groups such as Ubuntu, OpenSUSE, and Arch, but that‘s not the same as creating your own OS. These kits are limited to creating a branded personal version of the distro done by the group or company which provides the kit, you can rename it whatever you like, choose to include or exclude any software you like on DVD, although other software can still be installed later on, but the end result will be based on Ubuntu, OpenSUSE, Arch, or whatever distro it was based on. As for creating a distro of Linux of a new type or genus other than Debian, Red Hat, Slackware, or the much more recent Arch, you certainly can‘t do that with such a kit.

C64space1999

The computers in “Space: 1999” were made up of lighted panels and TV screens

I thought I expected computers to be absolutely amazing before getting one. This was based on what I‘d seen in sci fi series, such as Star Trek: The Original Series, Space 1999, Blake‘s Seven, and Doctor Who. Looking back at at episodes and clips from these series made before 1984, they show that none of the computers featured had a GUI, they were mainly voice controlled, could also speak, and either had lots of flashing lights, or panels with lighted switches, and could often display videos, but these videos were usually live and had no computer text or graphics overlaid. There was no frequently used standard computer in Doctor Who. I only remember the Chameleon Circuit system in “Logopolis“, where The Doctor typed in some Machine Code and it displayed a pyramid as the chosen new disguise for his TARDIS, as well as a fake TARDIS databank or instruction manual in the following story “Castrovalva“ which responded to commands such as IF for Index File, plus another database in the story “Arc of Infinity“ which gave details of that particular phenomenon. It seems that computers in sci fi with GUI systems may only have started appearing after they appeared in real life in the mass market. People were fascinated by the LCARS menu GUI in Star Trek: The Next Generation (created on colour Apple Mac computers in or before 1987) and have managed to produce something that looks like it running on top of other operating systems.

In Star Trek, keyboards and mice have been totally abandoned, although Scotty manages to type very fast on one in “Star Trek IV: The Voyage Home“ and Captain Katherine Janeway soon manages to pick up typing on a keyboard in the Star Trek: Voyager story “Future‘s End“, set in 1996. I think that the fictitious computers in these versions of Star Trek probably all contain a ROM or some equivalent RAM storage that can survive a reboot containing routines for graphics, so that creators of operating systems don‘t have to worry about doing this. Even the Atari 400/800 ROMs from 1979 and the Amstrad CPC ROMs from 1984 onwards contain graphics routines. Although these computers do display text, it‘s always on a graphic background and as we already know, modern computers and phones can input spoken text as well as be controlled by voice. I think that a future operating system could be entirely graphic, not bothering with any kind of typed commands at all. This goes against Linux and UNIX thinking, but the original Apple MacIntosh System Software had no shell or typed commands.

That‘s all for now! Look out for another amazing expose of the Commodore 64 soon.

Advertisements

Posted January 9, 2018 by C64hater in Uncategorized

The Commodore 64 and Operating Systems – Part 2     Leave a comment

The Commodore 64 and Operating Systems – Part 2

 

Games for GEOS on the Commodore 64

So, now we continue with this look at operating systems and how they‘re relevant to the Commodore 64.

Operating systems can be created either using Assembly Language/Machine Code for the CPU the hardware is based around, or by using a language which has a version running on that hardware, or on another system which can be used to produce code compatible for that hardware. How this is actually done can be quite complicated to understand.

The Commodore Kernal is a collection of routines which was used on all Commodore computers and updated for new models up to and including the Commodore 128, before Commodore abandoned it for the Amiga, as well as their own PC clones using third party PC BIOS ROMs and MS-DOS. You can read about this crap on http://sta.c64.org/cbm64krnfunc.html and https://www.c64-wiki.com/wiki/Kernal  The only really useful functions are to accept input, provide output, open files, load files, save files, and close files.

The way these calls are used has already been demonstrated in a previous post about the C128 built in MONITOR program. An example of this is below.

LDX #$00
LDA $1820,X
JSR $FFD2
INX
CPX #$0D
BNE $1802
JMP $1800
BRK

The program above uses $FFD2 CHROUT to output characters onto the text screen. These characters are held as data starting at address $1820 on the C128, but this should be $1020 on the C64, due to the different memory map. The program starts at $1800 on the C128, but this should be $1000 on the C64. You can read more about this in my post https://commodore64crap.wordpress.com/2013/10/29/the-commodore-128-the-fixed-and-upgraded-commodore-64-part-2/

CP/M only has 31 functions or calls, but the good excuse for this is that it came out in 1978, instead of 1982. The most useful calls are CONIN and CONOUT, to input and output characters from the keyboard. Apart from this there are functions for boot, both cold boot and warm boot. A cold boot starts from scratch, while a warm boot remembers what you were doing before your computer crashed and you reset the OS.

The “home computers“ such as the C64, Sinclair ZX Spectrum, Atari 8 bit, Acorn BBC Micro, Acorn Electron, Amstrad CPC and MSX, etc all booted into BASIC, but they also had a collection of ROM based routines. They were all coded in the Assembly Language/Machine Code for the CPU of each computer, meaning 6510/6502 for the C64, Atari, BBC Micro and Acorn Electron, but Z80 for the Sinclair ZX Spectrum, Amstrad CPC and MSX..

In 1969 onwards, years before the home computer boom, UNIX OS was created in some language on a PDP minicompurer which was probably Assembly Language/Machine Code, then rewritten in the C Programming Language. It was designed to be portable to different hardware. It has system calls or functions which have to be used in C. You can read about some or all of them on http://www.di.uevora.pt/~lmr/syscalls.html as well as http://www.tutorialspoint.com/unix_system_calls/ and http://www.csie.ntnu.edu.tw/~ghhwang/course_slices/OS/Unix_System_Calls.pdf

Years later, leading up to 1985, Amiga Workbench OS was also written in C, instead of in Assembly Language/Machine Code, but it was only designed for Amiga hardware, including a 68000, 68010, or 68020 CPU, as well as the custom chips Paula, Agnus, and Denise.

GEOS is an advanced GUI based OS for the C64, designed to look like the early Apple MacIntosh System Software or Digital Research GEM. It appears mainly as a monochrome system, but can use more than two colours at a time, unlike the early Mac. In spite of this, it never looks anything like as colourful as Atari ST GEM, or Amiga Workbench OS. It doesn‘t boot into BASIC, but into a desktop. It even fixes the C64 design faults by turning off the BASIC and Kernal ROMs, as well as loading a number of equates with meaningful names, similar to the Atari 8 bit computers. It contains functions including DrawPoint for plotting dots on the hires screen, HorizontalLine for drawing horizontal lines, VerticalLine for drawing vertical lines, DrawLine and i_Drawline for drawing diagonal lines! It was programmed in 6510/6502 Assembly Language. It allows users to run non GEOS C64 programs from the desktop, but also to write programs within GEOS. You can read more about it in “The Official GEOS Programmers Reference Guide“, as well as “GEOS Inside and Out“ (another Data Becker/Abacus book), both on http://www.bombjack.org/commodore/books.htm

I think that anyone out there wanting to create a brand new OS, not based on Linux, UNIX, or even on MS Windows, should get their hands on a Raspberry Pi computer, or a phone with an ARM CPU. This type of CPU is RISC (Reduced Instruction Set Chip), but I was surprised to read recently that it has lots of registers, a bit like the 68000 family, instead of the x86 family, or the 6502 family. While thinking up ideas for your new OS you could be watching lots of sci fi to see the way computers work there, then work out a way of actually doing it.

That‘s all for now! Look out for another amazing post about the C64 in the near future!

Posted December 22, 2017 by C64hater in Uncategorized

Debunking TMR‘s “Prepare To Operate – Part 1“   Leave a comment

Debunking TMR‘s “Prepare To Operate – Part 1“

A video comparing UNIX and Linux

In his post “Prepare To Operate – Part 1“ TMR of the blog “C64 Crap Debunk” criticised statistics for my blog which he can‘t identify the source of, claimed to live in an abolished county, thought he could challenge my native knowledge of London, and criticised Linux OS!

I‘ve been pleased to see an increase in the hits on this website, but I don‘t know where they‘re all coming from, except from various countries. As he hasn‘t even seen my stats, I don‘t see how TMR would know either!

TMR said he worked in London for a while in the late 1990s. This has nothing to do with what‘s been happening to London since then. The destruction of London has taken place just in the last few years.

TMR claimed to live in Yorkshire. This is a county which was abolished in 1974! Its territory was redistributed amongst three new counties containing the name Yorkshire, as well as some old and new counties. These were called North Yorkshire, South Yorkshire, and West Yorkshire. Some other Yorkshire territory was transferred to a few new counties not containing that name, as well as to some existing counties. Later still, the counties of South Yorkshire, and West Yorkshire were abolished and split up into lots of Unitary Authorities. The new Doctor Who Jodie Whittaker was born in Skelmanthorpe, Kirklees Unitary Authority (which was in West Yorkshire at the time). To put this into some context, I could claim to live in Wessex. This a historic county and former Kingdom in southern England, which existed even before England was formed in about 970AD under King Æthelstan or Edgar (according to different sources), then continued as a county in England. The name Wessex is still used by some fanatics, but I‘m not one of them. I live in Greater London, but this county has faced territorial claims undermining its status maintained by the post Office, as well as the cricket teams of Surrey, and the abolished county of Middlesex both being based here. At least Essex Cricket Club had the decency to move out after their grounds in Leyton became part of Greater London. Yorkshire Cricket Club still has the cheek to continue to exist.

Linux is an operating system which has been adapted for lots of different hardware. The way it boots up may be different on different hardware, but once booted, I don‘t think Linux depends on making any calls to a PC BIOS ROM, a Mac ROM, or any other ROM. It‘s known as a monolithic Kernel, meaning that it contains drivers for almost any hardware the user may want to plug in, instead of having to install special drivers. In this way it seems similar to the classic Amiga Workbench OS, but this required the command bindrivers in the file “startup-sequence“, so I suppose you could say that means it‘s not the same kind of operating system at all. This method on Amiga OS is called Autoconfig, pre dating Plug and Play on Windows. All Linux distros are built round the Linux Kernel, but have a choice of desktops and different package managers for installing new software. Linux used to be quite difficult to get into, but has now become fairly user friendly, although some distrtos such as Arch insist on making users type lots of commands to get everything set up. In spite of this, some Arch based distros such as Manjaro, and Antergos have added graphical installers. Linux is much better than Windows OS, because it‘s more carefully thought out, doesn‘t depend on typing in a licence number and new distros are available free, so Linux users tend not to use versions as old as Windows 7. Updates are also carried out quite easily and Linux doesn‘t make you wait ages to turn off your computer. I wonder how many thousands or millions of buses, other trips, etc, etc have been missed or fires caused because of Microsoft screens telling Windows users that they mustn‘t turn off their computers because Windows is installing updates? Any Windows user who in frustration turned off their computer by pressing the power button while this is going on have to wait until returning home from their trip to find out whether or not they can boot up their computer again.

That‘s all for now. Look forward to another post soon. This will either be more about operating systems, or about doing graphics on the C64 using techniques from “The Machine Language Book of the Commodore 64“.

Posted December 15, 2017 by C64hater in Uncategorized

The Commodore 64 and Operating Systems (Part 1)   2 comments

The Commodore 64 and Operating Systems (Part 1)

 

The CP/M Operating Szstem in action

Welcome to everyone who has recently been viewing this blog so much! Unfortunately, I‘ve had serious problems working out what to do next in the quest to find out how some people managed to program the Commodore 64, as well as being very depressed by the destruction of my home city of London. The city is still there, but has been made virtually uninhabitable to me, as well as its nightlife being decimated. If any of you are thinking of visiting London, don‘t bother! Also, as I indicated in my last post, I‘m now exploring a slightly different angle with the C64 for the moment.

Operating Systems are what makes computers go. There‘s some dispute about whether or not the C64 actually had an Operating System, though. Some books and magazines say it had, while other books and magazines say that an Operating System is something you boot into which isn‘t a language waiting for you to type a program in. As the C64 boots into BASIC with the Ready prompt, on that basis it doesn‘t have an operrating system. By this definition, an operating system contemporary to when the Commodore 64 first came out is CP/M or MS-DOS. Each of those systems present the user with a prompt (usually “A>“, “B>“, or “C>“), indicating which disk drive they‘re logged onto. The user can then carry out lots of operations by calling up programs from disk in a way actually designed to be convenient, unlike the botched Commodore DOS on Commodore 1541 disk drives, not including a directory command, as well as using just the commands OPEN or CLOSE followed by various numbers for handling the contents of disks. An MS-DOS or CP/M user with a drive prompt could then type a command such as BASIC, BASICA, or MBASIC to get into a version of the BASIC programming language, or some other command to manipulate files, explore the contents of RAM, etc. This is often called a DOS for Disk Operating System, but actually CP/M and MS-DOS each contain lots of routines loaded into RAM. These routines do things such as detect key presses, print text on the screen, save to files, read from files, and print out files. So to sum up, an operating system is a program which contains lots of useful routines to do everyday things, so that programmers don‘t have to write their own routines to perform these mundane tasks.

The Commodore 64 wasn‘t supplied with an operating system such as CP/M or MS-DOS, but it has what some people call an operating system on ROM. The lying buyers‘ guide “The A-Z of Personal Computers“ said it had “Cassette OS“. This is the Commodore KERNAL. Unlike MS-DOS, the Commodore KERNAL doesn‘t have lots of routines which can be called up. It has a total of 39 routines, as listed on http://sta.c64.org/cbm64krnfunc.html . I don‘t know what routines are contained in the very messy Commodore DOS. MS-DOS seems to have 86 routines it can call up, though. A summary of these can be viewed on http://www.eecs.wsu.edu/~ee314/handouts/dosref.pdf . Details of CP/M system calls can be viewed on http://www.seasip.info/Cpm/bios.html , but there are only 31 of them!

CP/M is made up of two parts, the BIOS (Basic Input Output System) and the BDOS (Basic Disk Operating System). This was an innovation it brought in, because previous operating systems had both these things combined. The CP/M BIOS managed the computer‘s hardware and each manufacturer usually had to write their own, which enabled the BDOS and all CP/M software to work on that system. With the original IBM PC, the BIOS which worked with IBM PC-DOS was put onto ROM. Microsoft had their own version called MS-DOS.

IBM‘s plan was to persuade lots of businesses to buy their IBM PC made from off the shelf parts, but with a custom Copyrighted BIOS on ROM. Microsoft‘s plan was to license MS-DOS to various manufacturers in a form with some kind of software BIOS like with CP/M. This meant that the hardware from different manufacturers could be quite different, but so long as software developers called MS-DOS functions instead of IBM PC BIOS ROM functions, then their MS-DOS software would run on any computer which could run MS-DOS. Some companies making MS-DOS computers which weren‘t IBM PC compatible were Apricot and Tandy. This concept didn‘t last for long, because other companies made ROMs which were compatible with the IBM PC BIOS, then IBM PC compatibles took over the business and home markets.

Of course, GEOS is a fully fledged third party operating system, which did its best to try and fix the Commodore 64 by making it behave like an early MacIntosh. It‘s much more sophisticated than the Commodore KERNAL, CP/M, or MS-DOS.

I think that nowadays a good way of exploring operating systems and what you can do with them is by using Linux OS. It‘s inspired by the older UNIX, but has been completely rewritten. Linux operating system is open source, which makes it highly customisable. It comes in lots of different varieties, called “distros“ (distributions) meaning that the software included with each distro and how to install new software varies greatly. I don‘t think it depends on any ROM, because it can run on PCs, Macs, and Raspberry Pi computers. When booting up or closing down Linux OS it displays hundreds or thousands of lines of text, unless the system is set to cover this with a graphics screen. In that case, you can choose to display them by hitting the ESC key. These lines are called the Linux Kernel.

Unfortunately, any OS shows signs of its origins. CP/M was originally for people building computers, as well as business users. MS-DOS was originally for business users and adding Windows to it didn‘t change this. The original MacIntosh with its System Software was originally for business users, then later versions of the Mac OS or Mac OSX continued in a similar vein. UNIX and Linux were originally for academics.

Well, that‘s all for now! I hope to make another post in the near future.

Posted November 30, 2017 by C64hater in Uncategorized

THE MACHINE LANGUAGE BOOK OF THE COMMODORE 64 – PART 4   Leave a comment

THE MACHINE LANGUAGE BOOK OF THE COMMODORE 64 – PART 4

The_Machine_Language_Book_for_the_Commodore_64

We’re still examining this book 

 

Now it‘s time to get on with actually doing something based on the knowledge in this book. There‘s also a follow up to this book, called “The Advanced Machine Language Book of The Commodore 64“, which continues in the same vein.

 

I‘m going to try and attempt to explain and demonstrate the very daunting tasks of drawing lines (the whole basis of graphics) and playing polyphonic music on the C64, which is child‘s play on other contempory computers, such as the Sinclair ZX Spectrum (drawing lines, but only playing monophonic music), Atari 8 bit, BBC Micro, Acorn Electron (one channel sound only), and MSX computers.

 

Readers are actually supposed to carry out these exercises for themselves instead of just sitting back, reading these articles, and looking at any accompanying pics and videos. To do this you‘ll need to either install an emulator such as VICE, or C64 Forever, or have a Commodore 128, or even a C64 at the ready.

 

How to install VICE

I think that VICE and C64 Forever are the worst (or best, depending on your opinion) C64 emulators out there, so here are the links.

http://vice-emu.sourceforge.net/

https://www.c64forever.com/

It‘s important to remember that the C64 graphics screens are bitmapped into character cells. This seems to make things more difficult when plotting lines, because you have to keep track of when your line passes a character cell boundary, entering a new section of RAM. This is just one way Commodore/Jack Tramiel made things more difficult.

We‘ll need to decide which 6502 opcodes to use in our line drawing programs. It‘s fairly obvious that they‘ll include LDA #number, LDA address, and STA address, as well as loops including the use of LDX #number, and LDA address,X but not clear what else. You should refer back to the previous posts on programming horizontally scrolling text on https://commodore64crap.wordpress.com/2013/10/29/the-commodore-128-the-fixed-and-upgraded-commodore-64-part-2/

 

There‘s also Bresenham‘s algorithm to consider. This was mentioned but never explained in some crappy C64 programming books I read, probably by Sunshine publications. It turns out that this was developed as long ago as 1962, on an amazingly advanced for the time IBM computer called the IBM 1401, connected to a Calcomp plotter. I don‘t know if the computer could display graphics on a screen, but it could plot them on the Calcomp plotter. Unfortunately, Bresenham‘s algorithm is a complicated algebraical formula. This means I can‘t understand it because I‘m useless at maths, so I‘ll have to design my own alrorithm, based on calculations as simple as possible, as well as tailor made for the C64 screen mapping where the graphics screens are divided into 40 x 25 character cells.

 

I think the C64 graphics screen can be located at any one of FOUR locations in Assembly Language, so I think first of all I need to decide where to locate it. After this, I must choose a pixel where I want the line to start. This start point shouldn‘t be at the top left pixel of a character cell, otherwise a line could be simulated just by printing backslash characters to the screen. Perhaps I could find out whereabouts this point is on the screen, meaning in which character cell by dividing it, but I don‘t think there are any 6502 Assembly Language instructions which do division. This was mentioned once by TMR of the rival blog https://c64crapdebunk.wordpress.com . All there seems to be are the instructions LSR meaning Logical Shift Right, and ROR, meaning Rotate Right, which are both ways of dividing by 2 each time they‘re carried out. This means an easier way of doing it is for me to choose whereabouts in a character cell I start. This could be 4 pixels across the 8 pixel wide cell. This means that after plotting 5 pixels, the line would definitely enter another character cell. As each row of pixels is a bit pattern, this means transferring the sequence of bytes $10, $08, $04, $02, and $01 into the relevant bytes of screen RAM. Following this, the sequence $80, $40, $20, $10, $08, $04, $02, and $01 would be placed into the next character cell, wherever that was. It could be the cell to the right, or diagonally right and down.

 

Don‘t forget that Commodore‘s own manuals were crap! It took lots of third parties, often from Germany, like the author of this book, to unveil the secrets of the C64!

 

As for my other learning activities, I‘ve been studying Japanese, as well as programming in Python. I have completed 75% of the Michel Thomas Method Japanese Foundation Course, so this proves that learning to speak Japanese is far easier than learning to program the Commodore 64.

 

That‘s all for now! Look out for another post in this blog very soon, about a different subject. This series of articles about “The Machine Language Book of the Commodore 64“ will continue ASAP though.

Posted August 25, 2017 by C64hater in Uncategorized

WHERE HAVE I BEEN?   Leave a comment

WHERE HAVE I BEEN?

Debunking “Learning by the book – part 3”

TheresaMayElection

Theresa May kept me busy part of the time

 

I thought I should post this as some kind of reply to the latest “C64 Crap Debunk” post by TMR on “C64 Crap Debunk” which you can find by clicking on https://c64crapdebunk.wordpress.com/2017/06/18/learning-by-the-book-part-3/

 

TMR starts off by wondering where I’ve been since February, in the light of “important events” since then. These were the triggering on March 29, 2017 of Article 50 of The Lisbon Treaty to start the suicidal process of the UK leaving the EU by British Prime Minister Theresa May, AND the snap British General Election of June 8, 2017, a process also started by Theresa May, although the final decision on whether or not to hold it had to be taken by Parliament.

 

This blog isn’t actually about current events, although I do sometimes mention them to make my posts more interesting. What I’ve been doing in connection with these events is as follows…

 

1. I’ve been going to meetings, demos, and a march to try and stop Brexit.

 

2. I was campaigning for one of the smaller parties which wants to stop Brexit by electing candidates, delivering leaflets for the local candidate, attending meetings, and going to the local count representing my party to sample votes which were being counted from certain Constituency Wards, meaning very small local districts. This means counting as many of the votes as possible while they’re being counted by the official counters. The purpose of this is to build a picture of which wards our support is strongest in. Before I started counting, I saw a TV exit poll predicting a hung parliament (i.e. no party getting a majority), so I was relieved that this meant a total isolationist permanent one party dictatorship was less likely. After sampling some votes, I mainly watched the actual results coming in on TV, but took the trouble to watch the local results being declared in the venue, and booed as loudly as possible at a re elected Labour MP who had actively supported the Leave campaign.

 

Since the election, I’ve been watching and reading lots of news, and trying to predict the date of the next General Election. It seems this will now be in about December or January, meaning about six months after the last election. It will probably be caused by defeats for the Conservative minority government, brought on by rebellions by some of its own MPs, and possibly a vote of no confidence. The result will be about the same as in June 2017, unless a Proportional Representation electoral system is introduced before the election. Some people refer to this as “the popular vote”, where for example if one party gets 30% of the votes, they get about 30% of the seats. More parties need to put up lots of candidates for this to make a big difference now. These parties may include Left Unity (who refused to stand against Labour in June 2017), The Women’s Equality Party (WEP), and The Pirate Party. A real possibility is also the formation of a new party with the main policy of staying in the EU, although I think they’d need some other policies as well.

 

Now back to the Commodore 64. Of course, not all dialects of BASIC apart from Commodore BASIC V2 supported hexadecimal numbers, but Locomotive BASIC on the Amstrad CPC range, as well as MSX BASIC did support them. Even Sinclair BASIC on the Sinclair ZX Spectrum supported binary numbers, but Commodore BASIC V2 and Atari BASIC only supported decimal.

 

I remember reading lots of Commodore BASIC V2 listings which assigned variables to the locations of the VIC-II and SID chips, then used two digit offsets for the different registers. In spite of this, the impression I got was that there were a lot more memory locations I needed to learn than all the registers of these chips. There was also the weird command sequences working on these registers using the commands AND as well as OR, without any explanation from Commodore about why this was. It was explained in a magazine article I found a few years ago as “bitwise programming”, meaning setting certain bits in the VIC-II and SID chip registers. Not only that, but it seemed to me that there was NO END to the number of locations to PEEK and POKE. I thought the total number of locations to PEEK and POKE may be as many as 65,535 or perhaps it might be 65,535 minus the number of locations occupied by BASIC, which had 38,911 bytes free, meaning a total of 26,624 locations left. There was no indication anywhere in the Commodore manuals how many memory locations I’d have to use, so faced with the nightmare scenario of having to deal with 65,535 or even 26,624 memory locations, I gave up.

 

Assembly Language makes things much easier, with techniques such as meaningful labels in a pre prepared text file standing for memory locations, as well as those locations in hexadecimal being more memorable, such as $D000 which I posted some time ago could stand for display block, meaning where the VIC-II chip starts.

 

As for books about Machine Code/Assembly Language which aren’t dedicated to a particular computer, before you can actually do anything with them on a specific computer, first off all you have to read up on your memory map to find the screen memory, a routine to print text on the screen, etc. Without this information, all you can do is carry out calculations and store them somewhere in the RAM, then examine the contents of those locations to see the results, which isn’t very interesting at all.

The artwork of the slum I grew up in was quite rough. It’s still early days of me using Multipaint, so I hope to do some better graphics in that package soon. Another program I’ve heard about is Swanky Paint, which is supposed to be based on the Amiga’s excellent Deluxe Paint, so I plan to try that.

C64Multisound

Multisound Synthesizer might have persuaded me to keep my C64, 

 

I’m now getting close to understanding the process of how other people managed to program the C64. In the near future, I hope to use Assembly Language to program lots of lines being drawn across the screen, then erased and replaced by some other lines, to produce simple animation, as well as to program a three channel polyphonic tune, without being dependent on specific software such as Synthy, or Multisound Synthesizer (my copy wouldn’t load and VicSoft failed to replace it, just sent a refund) and whatever restrictions they placed on how people could use the music they’d composed. That would be a proof of concept, then I may decide to stop writing this blog.

 

Other ideas of mine include a printed book based on this blog, as well as a graphic novel including my Dad with his “I know best” attitude (IKBA), the offices of “The A-Z of Personal Computers” with staff enjoying presents sent by Commodore in exchange for not mentioning that their BASIC was crap, etc. I may be setting up a crowd funder for these projects. There could even be separate crowd funders. One could be for people who want to see the book or graphic novel published, while the other could be for people who don’t want to see them published, such as the Tramiel family. Revenge is sweet!

LinuxWelt

“Linux Welt XXL” magazine, some previously forbidden knowledge from Germany

 

Some amazing news, is that I’ve recently gained access to some “forbidden knowledge” which the people who run newsagents in the UK don’t want me to know about. This lack of knowledge led a lot of people to vote to leave the EU. The forbidden knowledge is supplied by a service based in Sweden available on www.readly.com . I was very surprised to find about 305 Swedish magazines available, because I didn’t think Sweden with its population of just under ten million (plus another approximately 16.5 million people in other Scandinavian countries able to understand Swedish) could support that many magazines. What this means is that people in the UK now have access to the same current magazines and a few back issues as everyone else using this service anywhere else in the World. Countries covered include Germany, Sweden, and France, but not 100% of all magazines from anywhere seem to be available, based on the UK magazines on offer. It doesn’t include many magazines from France, but I found 586 magazines from Germany!! These include “Linux Welt” and “MagPi”. From “Linux Welt”, I’ve read that virus creators AND malware programmers are now targetting Linux, so it’s time to install some virus protection software and back up all my data. Apart from this, I read an article on the up and coming Linux distro Manjaro Linux which made me decide install it. A really important feature it has is that it’s not based on the Debian or Red Hat varieties of Linux, but on Arch Linux instead. This is important because Linux isn’t supposed to be controlled or dominated by any particular group. Unfortunately, in recent years Ubuntu and Mint, which are both Debian based, have been the most popular distros, as well as lots of other Debian or even Ubuntu based distros (e.g. Elementary OS, Zorin, Lite, Kali, KDE Neon, etc, etc) being released. What makes them Debian based is mainly that they use .deb package files and the apt or Aptitude package installer from the command line. The packages and the knowledge from using apt under one Debian based distro can be used with another. Arch Linux itself uses text based commands to install, which was the usual method at the turn of the Century, although distros such as the Red Hat based Mandrake soon started having graphic installers. Manjaro has a user friendly graphical installer. After that, you just have to learn a few different commands from the ones used in apt and be satisfied with a basic Synaptic like package installer called Octopi, without any equivalent to the Software Centre of Ubuntu or Software Manager of Mint. Not only that, but some more good news from the German “MagPi” is that the Raspberry Pi computer looks set to outsell the C64 in the near future, so then I’ll no longer have to listen to C64 fanatics crowing that their crappy computer was the largest selling “home computer” or whatever the term is. Meanwhile, in the latest (August 2017) issue of Linux Format (UK) there’s an article about how to make a custom distro based on Arch Linux. This may sound daunting, but after having read it, I can assure you it’s easier than trying to program the C64!

 

So that’s what I’ve been doing. In the near future I hope to get down to the depths of the C64 and explain to you how some people managed to program it! Look forward to that.

Posted July 25, 2017 by C64hater in Uncategorized

THE MACHINE LANGUAGE BOOK OF THE COMMODORE 64 – PART 3   Leave a comment

THE MACHINE LANGUAGE BOOK OF THE COMMODORE 64 – PART 3

The_Machine_Language_Book_for_the_Commodore_64

The actual book cover

We’re now really getting down to understanding how the Commodore 64 works and how some people managed to program it, in spite of its totally crappy built in Commodore BASIC V2 language, which had no dedicated commands for colour, graphics, or sound, and didn’t support the Hexadecimal numbering system either, as well as Commodore’s crappy manuals totally leading people off track by telling them to PEEK and POKE to 5 digit decimal memory locations, instead of having the locations stored in files as hex labelled by EQU directives.

This year (2017) marks the 35th anniversary of the C64 being released. It also marks the 35th anniversary of me and my Mum running away from the home my Dad had turned into a slum with lots of unfinished DIY jobs and hoarding. Neither of these events is anything to celebrate, especially as my Mum and me ended up having to return to that slum after only about six months.

Some big news on this subject is that since my last post in this series, the companion disk image to this book has been made available on http://www.bombjack.org/commodore/books.htm , so you should be able to download that and run it on either a C64 emulator, or on a real C64 or C128 using an SD2IEC device. This means it should be possible to use the programs in the book with the exact syntax used, instead of having to convert them for use in another Assembler. In spite of this, readers should familiarise themselves with the syntax of other Assemblers, otherwise they’ll be stuck using the LEA Assembler.

Some more news, is that I’m going to list a few more 6502 Assembler directives, this time from yet another book about 6502 Assembly Language programming. This is called, surprisingly enough “6502 Assembly Language Programming”, was published by John Wiley & Sons Inc, and was written by THREE WOMEN! You can find it on ftp://ftp.apple.asimov.net/pub/apple_II/documentation/programming/6502assembly/6502%20Assembly%20Language%20Programming.pdf and elsewhere if you look round. Their names are Judi N Fernandez, Donna N Tabler, and Ruth Ashley. According to Amazon this book was published in 1983, before computers became really popular and there were a lot of women involved in programming computers before then. The book is about Assembly Language, but not on any specific computer. The Introduction/Preface mentions Commodore, Apple, and Atari computers as being 6502 based and that it applies to all those computers as well as to any other 6502 based computer, so it wouldn’t enable you to write any C64 demos. The Assembler Directives used in this book are called DS, ASC, DFB, ORG, and EQU. The labels used in programs in this book are all in upper case text without any characters to indicate that they are labels. Some examples are how the directives are used are as follows…

DS means Define Storage. This can be for any kind of data. One example of this is DS 10 , which reserves 10 bytes of storage.

ASC stores any ASCII text contained in single quotes. An example of this is ASC ‘WHY’

DFB means define byte. Examples given are DFB 3, $15, 12, 7 and DFB ‘H’ , ‘I’

ORG means where to store your code. An example of this is ORG $8000

EQU means equate or equals. An example of this is VIDEO EQU $D000

So, that’s all you need to know for now! This book has a chapter called “Extending BASIC”, but actually there are no extended BASIC commands in the book. All it shows you is how to pass parameters to a SYS command. This isn’t good, but not as bad as certain people listing a graphics program without any way to save your creations. In the next instalment, I’ll be trying to draw some lines across a C64 graphics screen in 6502 Assembly Language, based on an example in the book. I may even try to animate these lines, but that won’t be according to any mathematical formula, because don’t forget I’m useless at maths!

Finally, here’s some artwork I did in the C64 lores screen mode. No programming was required at all, I just used some software called Multipaint, which runs on Linux, Windows, and Mac OSX. I didn’t spend all that long working on it. It gives you a rough impression of the slum I grew up in, which was in stark contrast to the semi detached house next door. I found I couldn’t convert the original graphics file from .bin or .ocp (Advanced Art Studio) to GIF, JPG, or even BMP, so in the end I had to take a pic of it with my Android phone. I hope you enjoy it! 

C64Slum

Posted June 18, 2017 by C64hater in Uncategorized