Topic: How did you learn ML?

[istvan]

mystikshadows asked about learning 6502 in a different thread, and that brings to mind a question I've often wondered about...  How did other people take the plunge into ML?

I had a C64, a copy of Supermon, the C64 Reference Guide, and the local library's "ML for Beginners" by Richard Mansfield.  I probably checked that book out a dozen times before it started to make an ounce of sense to me.  Finally, one day everything sort of "clicked" and I suddenly grasped everything I'd read (or at least enough to be dangerous).  After I realized what ML was all about, I went running back to BASIC like a freightened child to his mother.

I was initially overwhelmed with the difficulty of debugging (a good ole' syntax error sticks out like a sore thumb, a complicated subroutine that pushes a byte on the stack, sometimes branches around the PLA, and then crashes your computer when it tries to return is a little tougher to see).  I was also horrified at the amount of development time, even when things were going well.  Two hours spent at the keyboard can get you a very nice BASIC program.  Two hours spent wrestling with your assembler won't give you as much to show (although what you have can probably finish executing before the Return key is all the way back up).

A few years later I got my 128, along with a copy of the Compute! 128 Programmer's Reference Guide.  The built-in ML monitor was a godsend, as well as the detailed memory maps I was able to find online.  I tried several assemblers, both for 64 and 128 mode, until I helped myself to a copy of Merlin-128 that I found on one of the mega-piracy sites that had just gone online (I am not a crook.)  After that, there was no looking back.

I've got a three-ring binder with all the things I now find indispensable for programming.  Here's what's in it:

     1) a grid showing all of the 6502 instructions - I've got the instruction set memorized, of
     course, but every once in a while I still need to look up how flags are affected or the
     number of clock cycles an instruction takes

     2) a table showing what each bit of the MMU config register does

     3) a copy of page 20 from the 1750 REU manual, showing what the REC registers do

     4) descriptions of the kernal/editor routines

     5) the 128 memory map, heavily molested by margin notes

     6) a chart of ascii/screen codes

     7) Craig Taylor's "In Depth Look at the 8563" from one of the early issues of C= Hacking

I've never seen Commodore's 128 reference guide, but either that or Compute's is essential for fully understanding how the 128 is laid out.  I've been at this for a while, now, and I still grab for my Compute! book every now and then.

For a rookie, the only thing really missing from the list is a book on learning ML.  Mansfield's ended up doing the trick for me, but there weren't many practical code examples and I still had to figure a lot out by trial and error.  There's got to be something better.  Didn't Jim Butterfield write an ML book?

Sorry for the long screed.  I'm interested to hear about how other people got started with the 6502 - maybe our tales of hardship and success can save mystikshadows some strife.

[Stephane Richard]

I have the machine language routines for the commodore 64/128 book/code (or what seems to be book and code ;-)....in a zip file.

I also have   MACHINE LANGUAGE FOR THE COMMODORE 64and Other CommodoreComputers
                              by Jim Butterfield in text format ...

Maybe that's the one i should start my learning with :-)

[nikoniko]

Yeah, Jim Butterfield wrote a few books, the best known of which was Machine Language for the Commodore 64 (later revised to add the 128). A while ago he got back the rights from the publisher and kindly set about having his book scanned and OCR'ed so that it would available for anyone who wants it. There are PDF and text versions over at Project 64. I wonder if Mansfield's book is online somewhere too?

I think either one would probably be a good place to start. By the time I got a copy of Butterfield's ML book, I was already pretty comfortable with the 6502 instruction set from his earlier KIM book, but I didn't know anything about Commodore 64s or 128s. The book had a rudimentary memory map, so until I found the 128 Programmer's Reference Guide that was all I had to go on. I only saw the Mansfield book briefly at the bookstore, but my impression was that they both had about the same scope.

It's been years since I've done any 6502 development, so I've been spending a lot of time reviewing materials available on the net. I still pretty much remember the instruction set, but a lot of the specifics of 64/128 programming have disappeared from my memory.

[6502Dude]

...snip...I wonder if Mansfield's book is online somewhere too?

Yes, it may be found at http://www.atariarchives.org/mlb/


Mansfield's 2nd book of Machine Langauge is here - http://www.atariarchives.org/2bml/

I see Jim Butterfield each year two or three times at computer meetings.

I ought to bring my copy of ML for Commodore 64 to get his autograph :-)

I bought this book new back in mid 1980s and it is pretty well worn.

I learned 6800 ML before 6502.

[nikoniko]

Thanks for the link! Funny, although I knew that Atari Archives had some books on ML, I didn't notice they were the ones by Mansfield.

I once spent some time learning 6809 assembly to work on a homebrew Vectrex game. Didn't quite finish the game, but I enjoyed the learning experience.

[Stephane Richard]

Yeah those two Mansfield book look very well written too.  I started reading my Jim Butterfield books, and well I like the way they are written too so far.  Pretty clear stuff.

[xlar54]

All those books are really good.  Of course the programmers ref books are required reading also. Probably the best advice I would give anyone, is first learn the opcodes in something like a 6502 simulator app. (Theres a couple of really good ones).  Once you have dedicated yourself to learning the opcodes, thinking in ML is much easier.  Ive noticed in the past that I would try and mentally "convert" what I was trying to accomplish from BASIC to ML.  This strategy slowed me down. Much like learning a real language, its better to learn in thought than doing mental conversions.  Instead of converting PRINT "HELLO" to the screen, you begin to think "I need to index this register and send these bytes to $FFD2".

Another thing that helped was actually understanding what the CPU is *doing* in each opcode. The source code to VICE and other simulators out there show you exactly whats happening when LDA is called. By looking at these, you start to understand things like when and why the Z flag gets set, etc.

Lastly, the bane of many asm programmers is the indexing modes. Again, I have to push the simulators here.  Play play play.  Learn the difference between indexed indirect and indirect indexed.  And more than just what they do, spend some time learning why they do it.

The short of it is, you're not learning a computer programming *language*, when you learn ASM. You are _really_ learning the CPU itself. So you have to start to think in those terms. The CPU couldnt give a flip about PRINT, INPUT, A$, any of that. It cares what byte the PC is pointing to, what it needs to do in regards to that op, etc.

This is why I had so much trouble early on.  Most books teach opcodes, basics of bits and bytes, some hex, skim over addressing modes, and then try to help you mentally convert from BASIC to ML.  But something very frustrating occurs when you are taught this way.....

PRINT 20 * 543

Well, now we're really stuck.  I can send chars to $FFd2, but how the heck do I do the math?  You have to learn the CPU first, IMHO.

[Stephane Richard]

That sounds like very wise advice xlar.  I think I'm gonna do exactly that :-).

[Hydrophilic]

Like others, I too learned 6502 programming from Jim Butterfield.  I also bought the assembler package from Commodore.  It ran in 64 mode and since it was disk based without a fast loader, it was very slow... so most programs I wrote using the built-in C128 Monitor.

Then I got curious about the Z80 and got a book.  Sorry I can't remember the exact name, something generic like 'Z80 Programming'.  It's somewhere out in my garage missing the cover...  Anyway, my point is I didn't have a Z80 assembler so this is where it gets interesting.

Using the tables in the Z80 book, I wrote, in 6502 ML, an assembler for the Z80.  It ran and compiled to memory so was very fast.  Also, unlike other assemblers that have trouble with forward references, this was a multi-pass assembler.  This allowed things like forward references to forward references to forward references... something that chokes many assemblers even today (CC65 for example).

I was so happy with it, I used it to write, in Z80 assembly of course, an assembler for 6502 ML.  Is that crazy or what?

[gklinger]

...so most programs I wrote using the built-in C128 Monitor.

That's determination. Using a monitor to program can cause brain damage and brain damage is the only explanation for someone doing what you did.

Seriously though, I think what you did was great. You took what you had at hand and created the tools you needed.

I have a similar story about when I got my first modem. I got the hardware without software so I did the only logical thing I could do; I wrote a simple terminal program. Then I connected to a bulletin board and learned about a terminal program that a lot of other people were using. I wanted to download it but I couldn't because my software didn't support file transfers so I spent a weekend figuring out how Xmodem worked and then added the functionality to my software. I was finally able to download the software only to realize that it wasn't much better than what I had written. The only logical thing to do was copy the features I liked and add them to my program until I had a terminal that worked exactly the way I wanted it to. I found out later that quite a few people had done much the same thing.

It's impossible to explain the do-it-yourself philosophy to people who came to computers in the modern era.

[nikoniko]

That sure brings back memories. I ended up implementing a simple term program with Xmodem on three or four different computers. Some company would have done well to publish a decent terminal program in book form with translations to many different platforms, much as Compute! did with its SpeedScript word processor.

Besides calling BBSes, I found other other fun uses for my Commodore modem as well. Since its tone dialing system relied on output from the SID chip, it was listening for sound any time one had the modem off hook. I ended up writing several programs which took advantage of this. One would auto-answer any call and play a series of my favorite SID songs until the caller hung up. Another utilized the SAM voice synthesizer to create a time service; one could call in and have the current time read aloud, followed by a random quote. (And on Independence Day, SAM would even sing the national anthem for you!) Unfortunately, however, one of my friends leaked my number to somebody with a really big mouth, and we soon had strangers calling at all hours day and night. My mother was none too happy about that, especially considering we had only the one phone line. :/

By the way, I loved the 128's ML monitor. Much as I always enjoyed the immediacy of BASIC, a monitor brought a similar feeling to machine language programming. Even when I finally had a good assembler, I often preferred the monitor for shorter programs. The Commodore 128 would have been an absolutely perfect machine if it had also included Python! (Nevermind that it hadn't been created back then.

[Hydrophilic]

I ended up writing several programs which took advantage of this. One would auto-answer any call and play a series of my favorite SID songs until the caller hung up.

:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:

Another utilized the SAM voice synthesizer to create a time service...

That's pretty cool!  Have we all realised that Microsoft ripped (bought?) SAM?!  It's built into Windows 2000 and Windows XP as the default text-to-speach engine.  If you haven't experienced this yet, just press [Windows]+ to bring up the 'Accessiblity Manager' (or whatever they call it) and this activates SAM automatically (by default, it may have been turned off).

Um... sorry to go off topic like that, SAM deserves his (her?) own thread.

[Black Death]

Funny thing I played with ML about 5 yrs after starting with the vic-20 and on 2 the 64,  Never had alot of success i used the "Kernal Jump Routines" that came in the original book,   Funny thing is about 15 yrs l8r I aqcuired a c64 and 1541 and some games and i wanted to play "Pool Of Radience"  So I had to make a "Disk Di-Sector" Program to search for the "Keywords" to allow game play,  well basic was taking WAY to long to search the Entire Floppy so I wrote a Machine Language Routine that Searched out the Key word I entered and Logged it so I could go in and change them,  and that was the first real successful ML routine I ever wrote!!!!  LOL,   what a flashback,   Ack I'm old!