On Sat, 6 Jan 2007 03:01:51 +0000 (UTC), John Reimer
<terminal.node@gmail.com> wrote:

>I moved to 6510 assembler eventually and started having fun with raster interrupts, setting the vic II to operate in different modes on different scan lines. Those days were so fun! I never got extremely far into such low-level things, but even the beginnings were full of wonder. :)

For me it was the SID chip and music stuff. At that time I was really ignorant of synthesizer principles, but it was a good way to learn a few basic principles.

For my money, the best thing about C64 Basic was that it was so limited. If you wanted to do anything worthwhile, at least if you wanted it to run at a sensible speed, you had to learn assembler. I remember writing my first Brezenhams-algorithm line drawing routine in Commodore Basic and watching the pixels appear pretty much one-by-one!

Since I couldn't afford a decent assembler, in my case I ended up with a freebie typed in from a book listing - which turned out to be a good thing, since I could update it myself.

-- 
Remove 'wants' and 'nospam' from e-mail.

Walter Bright wrote:
I just want to know the primary one.

Mostly C now, at work.

Past experiences also included C++, x86 assembly, VB, Java and Python.

Luís

On Mon, 08 Jan 2007 00:05:14 +0000, Steve Horne wrote:

> On Sat, 6 Jan 2007 03:01:51 +0000 (UTC), John Reimer
> <terminal.node@gmail.com> wrote:
> 
>>I moved to 6510 assembler eventually and started having fun with raster interrupts, setting the vic II to operate in different modes on different scan lines. Those days were so fun! I never got extremely far into such low-level things, but even the beginnings were full of wonder. :)
> 
> For me it was the SID chip and music stuff. At that time I was really ignorant of synthesizer principles, but it was a good way to learn a few basic principles.
> 


I played with the SID chip a bit, but not very much.  I remember a very little about fiddling with attack/decay/sustain/release values.


> For my money, the best thing about C64 Basic was that it was so limited. If you wanted to do anything worthwhile, at least if you wanted it to run at a sensible speed, you had to learn assembler. I remember writing my first Brezenhams-algorithm line drawing routine in Commodore Basic and watching the pixels appear pretty much one-by-one!


Yes, the C64 BASIC was quite limited.  One had to resort to so many peeks and pokes to do anything substantial that one might as well have learned assembler.  I thought I was such a wiz at 15 when I started learning it, although in retrospect I realize I wasn't even close :P.

Bresenham in BASIC :), that must have been slow.  The
bitmapped video had especially wierd memory layout, each location
mapped to an 8 byte vertical zone much like a single character map, if I
recall correctly.  This may not have been so unusual at the time, but I
considered it weird... that is, until I learned about the VGA 16 colour
modes of the PC :P.


> Since I couldn't afford a decent assembler, in my case I ended up with a freebie typed in from a book listing - which turned out to be a good thing, since I could update it myself.
>

I had purchased the two Compute's Gazette books on assembler.  The first merely taught it, and the second guided you through implementing a complete assembler and editor (the red and blue books, I can't remember the names). I never understood the second book at the time, but I think I made use of the assembler/editor from it.

Later I purchased the Super C system for C64.  That was my first introduction to C programming, about 15 years ago now.

-JJR

Pragma wrote:
> Don Clugston wrote:
>> Sean Kelly wrote:
>>> Pragma wrote:
>>>>
>>>> I cut my teeth on C64 Basic*
>>> ...
>>>> (*I see that I'm not alone here - it's like those things were built to train new coders)
>>>
>>> I remember being so excited when the C64 magazines arrived in the mail--a friend and I would spend all day entering the printed code to play the new game they contained.  It wasn't my first experience with programming, but it was certainly one of the most significant.
>>>
>>>
>>> Sean
>>
>> POKE 53280,0: POKE 53281,0
>> Those were the days.
>> A lot of my early programming was refactoring the code while typing it in because I was such a slow typist.
>>
>> I never used C64 BASIC much -- I switched to asm very quickly because it was higher level (!) I wrote my own editor/assembler, which let me have labels and variable names more than 2 characters long. It booted off a cassette drive in 15 seconds using a turboload routine (I was too poor to own a disk drive). It's still one of the programs I'm proudest of.
>>
> 
> 15 seconds?  Now *that's* impressive.  I recall waiting for some games to load via tape that took 2-3 *minutes*.

I had a special 'leaderless' cassette, which didn't have the clear bit at the start. When saving it, I tricked the C64 into beginning to save immediately. To get the 15 seconds timing, you had to press shift-run/stop and PLAY on tape as soon as you flicked the power-on switch; you never saw the power-on screen. The turbo loader was saved inside the filename (filenames could be up to 500 bytes long). The editor/assembler itself was about 3K long, and it used primitive compression.

When saving a file, the code for saving was stored on the screen, which meant you could save from any part of RAM; but if you accidentally pressed {CLR/HOME} the C64 would crash once you hit RETURN, because you'd wiped out the code it was executing.

John Reimer wrote:
> On Mon, 08 Jan 2007 00:05:14 +0000, Steve Horne wrote:
> 
>> On Sat, 6 Jan 2007 03:01:51 +0000 (UTC), John Reimer
>> <terminal.node@gmail.com> wrote:
>>
>>> I moved to 6510 assembler eventually and started having fun with raster
>>> interrupts, setting the vic II to operate in different modes on different
>>> scan lines. Those days were so fun! I never got extremely far into such
>>> low-level things, but even the beginnings were full of wonder. :)

Oh yeah! The coolest thing was asking it to shrink the screen at the exact moment when it was drawing that part of the screen. The VIC-II would get confused, and keep displaying the contents of memory location $3FFF, and  would let you display sprites in the border. If you did this in the middle of the screen, it used to display character $FF at the end of the line, but I never worked out exactly what was happenning.

The unidentified opcodes were great too, trying to work out what was going on inside the CPU. A couple were actually useful.

>> For me it was the SID chip and music stuff. At that time I was really
>> ignorant of synthesizer principles, but it was a good way to learn a
>> few basic principles.
> 
> I played with the SID chip a bit, but not very much.  I remember a very
> little about fiddling with attack/decay/sustain/release values.
> 
> 
>> For my money, the best thing about C64 Basic was that it was so
>> limited. If you wanted to do anything worthwhile, at least if you
>> wanted it to run at a sensible speed, you had to learn assembler. I
>> remember writing my first Brezenhams-algorithm line drawing routine in
>> Commodore Basic and watching the pixels appear pretty much one-by-one!
> 
> 
> Yes, the C64 BASIC was quite limited.  One had to resort to so many peeks
> and pokes to do anything substantial that one might as well have learned
> assembler.  I thought I was such a wiz at 15 when I started learning it,
> although in retrospect I realize I wasn't even close :P.

The C64 BASIC manual explained that the command to do graphics was POKE. Must be one of the worst languages ever made.

> Bresenham in BASIC :), that must have been slow.  The
> bitmapped video had especially wierd memory layout, each location
> mapped to an 8 byte vertical zone much like a single character map, if I
> recall correctly.  This may not have been so unusual at the time, but I
> considered it weird... that is, until I learned about the VGA 16 colour
> modes of the PC :P.

The multicolour mode was definitely weird, though. The meaning of colour #1 depended on the settings in colour RAM.

>> Since I couldn't afford a decent assembler, in my case I ended up with a
>> freebie typed in from a book listing - which turned out to be a good
>> thing, since I could update it myself.
> 
> I had purchased the two Compute's Gazette books on assembler.  The first
> merely taught it, and the second guided you through implementing a
> complete assembler and editor (the red and blue books, I can't remember
> the names). I never understood the second book at the time, but I think I
> made use of the assembler/editor from it.

COMPUTE!'s First Book of Machine Code.
COMPUTE!'s Second Book of Machine Code.

Knew them well :-).

> Later I purchased the Super C system for C64.  That was my first
> introduction to C programming, about 15 years ago now.
> 
> -JJR

Don Clugston wrote:
> Pragma wrote:
> 
>> Don Clugston wrote:
>>
>>> Sean Kelly wrote:
>>>
>>>> Pragma wrote:
>>>>
>>>>>
>>>>> I cut my teeth on C64 Basic*
>>>>
>>>> ...
>>>>
>>>>> (*I see that I'm not alone here - it's like those things were built to train new coders)
>>>>
>>>>
>>>> I remember being so excited when the C64 magazines arrived in the mail--a friend and I would spend all day entering the printed code to play the new game they contained.  It wasn't my first experience with programming, but it was certainly one of the most significant.
>>>>
>>>>
>>>> Sean
>>>
>>>
>>> POKE 53280,0: POKE 53281,0
>>> Those were the days.
>>> A lot of my early programming was refactoring the code while typing it in because I was such a slow typist.
>>>
>>> I never used C64 BASIC much -- I switched to asm very quickly because it was higher level (!) I wrote my own editor/assembler, which let me have labels and variable names more than 2 characters long. It booted off a cassette drive in 15 seconds using a turboload routine (I was too poor to own a disk drive). It's still one of the programs I'm proudest of.
>>>
>>
>> 15 seconds?  Now *that's* impressive.  I recall waiting for some games to load via tape that took 2-3 *minutes*.
> 
> 
> I had a special 'leaderless' cassette, which didn't have the clear bit at the start. When saving it, I tricked the C64 into beginning to save immediately. To get the 15 seconds timing, you had to press shift-run/stop and PLAY on tape as soon as you flicked the power-on switch; you never saw the power-on screen. The turbo loader was saved inside the filename (filenames could be up to 500 bytes long). The editor/assembler itself was about 3K long, and it used primitive compression.
> 
> When saving a file, the code for saving was stored on the screen, which meant you could save from any part of RAM; but if you accidentally pressed {CLR/HOME} the C64 would crash once you hit RETURN, because you'd wiped out the code it was executing.

Just awesome!

BCS wrote:

> Walter Bright wrote:
> > I know you all are early adopters of D, and that's a special breed different from the vast majority of programmers. But still, it would be   useful (in writing documentation) to know what language was your  primary tool before coming to D. I also know that many of you are handy  with multiple diverse languages, I just want to know the primary one.
> > 
> 
> basic / c / c++
> 
> I would have done ASM (and still want to) but I can't seem to find
> references.

I you mean X86 assembler, then "PC Assembly Language" @ http://www.drpaulcarter.com/pcasm/ is pretty good IMHO, and it's available to download for free.

Walter Bright wrote:

> I just want to know the primary one.

C++

Bruno Medeiros wrote:
> Kyle Furlong wrote:
>> Jeff M wrote:
>>> On 2007-01-02 15:29:03 -0800, Walter Bright <newshound@digitalmars.com> said:
>>>
>>>> I know you all are early adopters of D, and that's a special breed different from the vast majority of programmers. But still, it would be   useful (in writing documentation) to know what language was your primary tool before coming to D. I also know that many of you are handy with multiple diverse languages, I just want to know the primary one.
>>>>
>>>> Asm?
>>>> C++?
>>>> C?
>>>> None (D's your first language)?
>>>> Java?
>>>> C#?
>>>> Python?
>>>> Lisp?
>>>> Ruby?
>>>> Delphi?
>>>> Perl?
>>>> Cobol? <g>
>>>
>>> My primary language is PHP, but I have a good knowledge of the following languages:
>>>
>>> * PHP (including PHP Internals)
>>> * C
>>> * C++
>>> * C#
>>> * ECMAScript
>>> * SQL
>>>
>>> At one time I knew these languages:
>>>
>>> * Perl
>>> * Java
>>>
>>> I've been learning D for the past two weeks.  It's like C++ except that it doesn't make me want to shove knitting needles into my eyes.
>>>
>>> -- Jeff
>>>
>>
>> I love these newcomer anecdotes. :D
> 
> When commenting about C++ to coder friends I usually describe it as making me "want to dig inside my skull and scrape out the pain."
> (It's a phrase I took from an excellent noir story)

I feel that way about VBA's bug-oriented programming -- any old garbage will compile without complaint. The way that compiler bugs can corrupt your *source code* is just brilliant.

Walter Bright wrote:
> I know you all are early adopters of D, and that's a special breed
> different from the vast majority of programmers. But still, it would be
>  useful (in writing documentation) to know what language was your
> primary tool before coming to D. I also know that many of you are handy
> with multiple diverse languages, I just want to know the primary one.
> 
> Asm?
> C++?
> C?
> None (D's your first language)?
> Java?
> C#?
> Python?
> Lisp?
> Ruby?
> Delphi?
> Perl?
> Cobol? <g>

Hi,

I'd say I'm comming from Delphi, though that's not fully correct because there are lot's of languages I had a look at and with few of them I code different projects. So here are the languges I used to use in order of time spent on them:

Delphi     - due to my apprenticeship and because I somehow like it. And
             because the IDE is simply the best! (though D2005 was
             somewhat slow...)
PHP        - because I was (am) young and didn't know better. I decline
             writing PHP these days. PHP is just a big security hole
Python     - The one and only scripting language. Best documentation,
             very fast, extensible, very good for agile software dev
             (e.g. eXtreme Programming)
Java       - I have to learn at university at the moment. It's nice
             because of it's platform independence, but this seems to be
             everything that's good about it.
C          - To be able to translate .h files to delphi headers ;) or:
             To understand the linux kernel source and to be able to
             "talk" to all those others using it...
C++        - because I like it the object-oriented way
ASM        - for a project with some friends building a microkernel that
             based on asm+pascal


There are some more I had an eye on, but those are the ones I used to use and am still using (except PHP)