Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Coding for beginners
2008-01-06 12:45
Darkus

Registered: Apr 2007
Posts: 8
Coding for beginners

I`ve been searching the net for assembler guides and applications but I hoping someone can recommend the best guides and programs I should use for starting out - plus are there any issues with using emulators only ? Anyone who may answer these questions, please bare in mind I know very little about the C64 platform at this stage :)
2008-01-06 13:24
A3

Registered: Dec 2005
Posts: 362
This topic has been up before some of the earlier ones are:

Learning machine code language

machine code / assembler

Code, how to get started?
2008-01-06 13:25
6R6

Registered: Feb 2002
Posts: 245
http://codebase64.org/doku.php

Is useful as it has source-codes.

But you will want to get aay64.txt ( http://www.the-dreams.de/aay.html ) and perhaps the Commodore 64
Programmer's Reference Guide ( its on this page somewhere http://project64.c64.org/index.htm )

If you decide to code on PC - then use
64tass v1.45 ( 64TASS V1.45 ) - If you want to use a more advanced compiler, then try http://www.cc65.org/

2008-01-22 22:59
The Shadow

Registered: Oct 2007
Posts: 304
Darkus,

I have used mostly Turbo Assembler which is great. If you are starting out though it is best to choose your favorite cartridge; Action Replay, Super Snapshot, etc and practice with a plain ML monitor. This method is the hardest and will give you a more thorough understanding of your 64. There are new assemblers released too which are said to be good like the kick assembler.

TS
2008-01-23 09:27
WVL

Registered: Mar 2002
Posts: 902
About recommending assemblers : I always use 64tass, simply because it is (IMO) the simplest that is available.

About coding on emulators : There are some 'quirks' that emulators sometimes do not emulate correctly, however : you will be hard pressed to notice any if you're starting with coding.

I recommend the latest VICE to test your codes, and the latest HoXS for inbetween tests. Hoxs is definately the better emulator, but is a lot less 'usable' (at least to me).

Hoxs is much slower (the price you pay for better emulation) but it will emulate almost anything you throw at it. A big disadvantage of Hoxs (IMO) is the missing cartridge emulation, which simply makes it a lot harder to debug things and I also miss the fastloader.. (I have my own version of Jiffydos as the roms in Hoxs to make up for it a bit..). In the end : use hoxs to test milestones in your code, but not for every test.

Also, I'd recommend to write your first program directly in the Monitor of a cartridge like Action Replay, you will be much closer to the machine and it's simply nice ;)

When you manage to get your first programs to run and work, you can switch to assemblers. (the reason to write directly in monitor is that you are very close to the memory, and you kind-of distance yourself from what-byte-is-where when using assemblers (at least for the code itself))

Good luck!
2008-01-23 12:28
Radiant

Registered: Sep 2004
Posts: 639
Quoting WVL
A big disadvantage of Hoxs (IMO) is the missing cartridge emulation, which simply makes it a lot harder to debug things and I also miss the fastloader..

Don't forget the excellent built-in monitor VICE provides, as well. Makes development a breeze.
2008-01-23 14:40
enthusi

Registered: May 2004
Posts: 677
I agree with WVL on using a monitor first.
But it really wont matter if you use vice or hoxs or whatever emu (if any).
The only things not emulated well is behavior that is non-intuitive anyway.
A rule of thumb: dont assume pre-settings of emulators to be valid on real thing (like memory beeing preset as 00 or FF etc).
That's all.
I use acme. Its plain, direct and mostly TASS compatible.
Also available for many platforms.
Dont even try to code in vice-Monitor. It may be nice (as in better than nothing) to debug but not to code in.

Forgive the command-style tone of mine, all this is just my idea/exp of it.

Code on,
enthusi
2008-01-23 17:02
Mace

Registered: May 2002
Posts: 1799
Radiantx wrote:
Quote:
the excellent built-in monitor VICE provides
I know where the normal VICE monitor is... but where's the 'excellent' one? ;-)
2008-01-23 19:04
WVL

Registered: Mar 2002
Posts: 902
vice monitor is ok for debugging, but for coding? nah.. Maybe TMR would like it :)
2008-01-23 19:28
TDJ

Registered: Dec 2001
Posts: 1879
Quote: Radiantx wrote:
Quote:
the excellent built-in monitor VICE provides
I know where the normal VICE monitor is... but where's the 'excellent' one? ;-)


Let me guess: you probably don't use the professional Vice version?

Anywhoo, I guess starting in monitor is the right way to go, I myself did all my parts pre-Focus in it.
2008-01-23 19:51
null
Account closed

Registered: Jun 2006
Posts: 645
Quote: Let me guess: you probably don't use the professional Vice version?

Anywhoo, I guess starting in monitor is the right way to go, I myself did all my parts pre-Focus in it.


surely a monitor is a good way to start, but Vicemon is a bit masochistic imho.

FCIII monitor ftw.

------------------------------------
http://zomgwtfbbq.info
2008-01-24 11:43
Martin Piper

Registered: Nov 2007
Posts: 722
I find ACME suits my needs, especially after a couple of tweaks to allow it to output warnings in Microsoft Visual Studio format. This lets me build in the IDE and press F4 to jump to reported warnings/errors. I've found using a nice modern IDE with source control really helps improve the C64 coding experience. :)

I also quite like debugging in VICE and altered ACME to output labels in VICE debugger format. When the PRG loads just load the labels in the debugger and then the disassembly is much easier to read. I did think about tweaking VICE to automatically load labels if it detected the file existed when loading a PRG with the same file name, but never got around to it. An alternative would be to write a debugger hook back to Visual Studio to enable me to do breakpoints and source single stepping, but that is also a much larger project. ;)

I've uploaded the tweaked ACME sources and a build here. http://codebase64.org/doku.php?id=base:tool_sources#sources_for..
2008-01-24 13:32
Cruzer

Registered: Dec 2001
Posts: 1048
These advices are all very good, but don't forget the most important thing - eat/drink lots of caffeinated stuff, otherwise you'll never have the drive you need to try, try and try again thousands of times over until you figure out how to do something decent.
2008-01-24 13:43
HCL

Registered: Feb 2003
Posts: 728
Fir5t you n33d 7o 134rn t0 5pe4k 1ike teh 1337 ha**0r5, otherwise you'll never be able to learn coding, no chance. Practice here in teh shit ph0rumz a few light-years, and then come back and learn coding.

And then when you become famous, remember who gave you all this good advice!!
2008-01-24 13:57
Burglar

Registered: Dec 2004
Posts: 1101
Quote: These advices are all very good, but don't forget the most important thing - eat/drink lots of caffeinated stuff, otherwise you'll never have the drive you need to try, try and try again thousands of times over until you figure out how to do something decent.


dont forget weed! it'll give you really creative coding solutions that miraculously stop working the next day ;)
2008-01-24 14:18
Cruzer

Registered: Dec 2001
Posts: 1048
Quote:
dont forget weed!

I wouldn't know about that, but alcohol in the right dose can be a help too...


2008-01-25 07:26
plagueis
Account closed

Registered: Dec 2007
Posts: 48
Hello all beginning 6510/6502 coders.

I had a c64 in the 80's and now recently purchased one again off of ebay. I always wanted to learn to code, back then, but I was younger and my attention span was never really there, plus, living in a small town I didn't have any local machine code mentors.

Now, after reading Puterman's excellent tutorial and many disk mags (such as Coder's World 1,2 and 3...and all the Attitudes), I have mastered quite a bit of the basics, and even have managed to create a one screen intro. I started about 3-4 months ago, using primarily the CCS64 emulator, and also Vice. I've mostly been using Turbo Illasm off of the "Coder's Orgasm V3" disk. I've also written quite a few routines (timed and $d011 raster bars, etc) using the monitor in Final Cartridge III, and Action Replay VI. I have those ROMs, plus I also have the hardware for Final Cartridge III. The only problem is, I haven't had the chance to test any of my code on the real hardware due to lack of a monitor (screen). I hope to remedy that soon.

So mainly I just made this post to share my experiences with other beginners. Cruser was absolutely correct about needing Caffeine to stay focused on figuring out new routines and effects, and stay on it until you get them working the way you want. I have made a lot of progress in only a few months after starting from scratch, but I have a long way to go.

So, Turbo Assembler for sure, only after a decent knowledge of coding in the monitor.

Action Replay VI or Final Cart. III

Read anything by Puterman (great tutorials...plus he doesn't always give you *all* the answers)

Read all 3 issues of Coder's World, then read them again.

Read Attitude 4,5,etc...
2008-01-25 09:48
Radiant

Registered: Sep 2004
Posts: 639
Quote: vice monitor is ok for debugging, but for coding? nah.. Maybe TMR would like it :)

Coding in any monitor these days is masochism. The VICE monitor is excellent because it's such a fantastic gateway between the emulated C64 and the host machine.
2008-01-25 13:26
assiduous
Account closed

Registered: Jun 2007
Posts: 343
Quote:
Hoxs is much slower (the price you pay for better emulation) but it will emulate almost anything you throw at it.

And if it won't,report it to the author, he fixes anything you throw at him within a few days.

although hoxs64 is deadly accurate (ccs64 and vice are nothing close) i wouldn't trust it in all circumstances. if vice, ccs and hoxs display differently it's always a good idea to check on a real C64. In the great majority of cases Hoxs64 will prove to be accurate but not always. A few days ago I found a minor VIC bug affecting Hoxs64 and CCS64 and not present in VICE and it is now being fixed for the next release of Hoxs64.
2008-01-25 14:14
HCL

Registered: Feb 2003
Posts: 728
You read Puterman's tutorial!? Oups, we're about to see some rather weird stuff here soon ;).
2008-01-25 20:12
The Shadow

Registered: Oct 2007
Posts: 304
Recently I bought a 64 from eBay myself. Doodling around on an emulator is fine. When it concerns the hardcore details, an actual 64 is a must.
2008-01-25 21:07
plagueis
Account closed

Registered: Dec 2007
Posts: 48
Quote: You read Puterman's tutorial!? Oups, we're about to see some rather weird stuff here soon ;).

HCL,

Well, yeah...he certainly has some unique design elements in his demos...but his beginning coding tutorials are some of the best in my opinion. Lately I've kind of been obsessed with reading all the tutorials I can find and trying out as many of the routines as I can. Puterman's stuff is very well written, and has a great coverage of loops and the very basic essentials that you learn in the beginning. I also forgot to mention that I've learned a lot from Richard Bayliss' Assemble It tutorial.

Of course, I have been a C programmer (mostly in the UNIX environment) since the Mid '90s, so I was already familiar with hex, pointers, etc...and I've done a little Intel asm as well.

One thing that I would recommend is to download many old and new c64 demos and watch them. I do that a lot and try to figure out in my mind how the effects were accomplished and where the screen cuts are and everything. Think about the approximate raster time for each thing that is happening on the screen. I do that very often for inspiration. Of course, you can use your monitor (on the cart or emulator or whatever) to disassemble the routines and figure them out also.

/\/ecromancer
2008-01-26 23:53
Martin Piper

Registered: Nov 2007
Posts: 722
Then once you figure out this assembler programming lark the next logical step is to go one step lower level and design your own TTL hardware and opcodes. :)
2008-01-27 10:14
Mace

Registered: May 2002
Posts: 1799
Quote: Then once you figure out this assembler programming lark the next logical step is to go one step lower level and design your own TTL hardware and opcodes. :)


I think you skipped a few steps, then :-)
2008-01-27 23:17
plagueis
Account closed

Registered: Dec 2007
Posts: 48
I have changed my handle (at least on here) since there were two other Necromancers.

Anyway, my area of coding will probably center around old school (and new) demo effects, so for those interested in these areas of c64 coding, the tutorials I mentioned above are excellent.

2008-01-28 07:07
JackAsser

Registered: Jun 2002
Posts:
My road to C64 coding was getting some initial help from my brother, read the VIC article, download CC65 and start bugging Krill, WVL and Graham on #c-64 as much as possible. ;D If you're committed it really doesn't take that long to learn how to code the standard effects, they're really quite simple most of them. The hard part was figure them out initially back in the 80'ies.

And also I second RadiantX about the claim that the VICE monitor is excellent (although there are room for tons of improvement). Also I don't agree that coding in a monitor gives you better understanding that coding in assembly. It's just tedious imo. Monitors should be used for debugging, not coding.

To get a good understanding and really learn how to code on the C-64 the most important thing is to be committed to it. And this is general for all new areas of knowledge you wish to pursue, be it coding or playing the guitar.

2008-03-03 22:33
Martin Piper

Registered: Nov 2007
Posts: 722
Quote: I think you skipped a few steps, then :-)

I typed up a few of my thoughts on the subject. ;)
http://www.wellytop.com/Fnagaton/DIYComputer.html
2008-05-20 21:47
omega120
Account closed

Registered: Sep 2005
Posts: 204
Quote: I`ve been searching the net for assembler guides and applications but I hoping someone can recommend the best guides and programs I should use for starting out - plus are there any issues with using emulators only ? Anyone who may answer these questions, please bare in mind I know very little about the C64 platform at this stage :)

You can learn C64 machine code for making games by making a visit at:-
http://peterscommodore64.synthasite.com
2008-05-29 13:42
chatGPZ

Registered: Dec 2001
Posts: 11386
unrelated babble related to Manky +2 removed on popular demand :)
2008-05-29 13:47
omega120
Account closed

Registered: Sep 2005
Posts: 204
Whats wrong with a monitor to write code its what I have always used and always will because it is a challenge, not going for some kind o assembler which I think is the easy way out for some people to writer there so called creation. swtich to the `machine code monitor` you will get better satisfaction! I will take note of your comments and see what I can ajust or alter in my coding.
2008-05-29 13:52
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Quote: Whats wrong with a monitor to write code its what I have always used and always will because it is a challenge, not going for some kind o assembler which I think is the easy way out for some people to writer there so called creation. swtich to the `machine code monitor` you will get better satisfaction! I will take note of your comments and see what I can ajust or alter in my coding.

Beginners already have a challenge called "learning 6502 machine code", they don't need a second challenge of working in a harsh environment to go with that.
2008-05-29 14:01
omega120
Account closed

Registered: Sep 2005
Posts: 204
You think its harsh to code using a monitor I dont think so Ive been coding for years using a monitor you should test your strength on it!
2008-05-29 14:48
Hein

Registered: Apr 2004
Posts: 954
Monitor programming doesn't seem practical for coding games, assembler will give you more freedom to experiment with the game, instead of the code.
2008-05-29 15:04
omega120
Account closed

Registered: Sep 2005
Posts: 204
I looked at assembler and thought the idea was crap and went immediately back to my ACTION REPLAY monitor. that was years ago and I am still using the A.R. monitor for coding.
2008-05-29 15:53
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Quote: You think its harsh to code using a monitor I dont think so Ive been coding for years using a monitor you should test your strength on it!

i've written projects in a monitor, my strength isn't in question here; it's beginners trying to make head or tail of 6502 machine code whilst being thrown in at the deep end. A monitor is a hostile environment for a new programmer, an assembler at least lets people forget about learning hex to begin with, they all support decimal.
2008-05-29 16:16
omega120
Account closed

Registered: Sep 2005
Posts: 204
Hostile enviroment I dont think so I self taught my self reading hex monitor code and I found the language dead simple once I got the hang of it as with assembler I could not get a hold of it either here nor there I found the system very hard to grip on yes I would opt for the learner on c64 machine code to go for the monitor action any day.
2008-05-29 16:35
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
So that's you in the monitor camp and almost everyone else in the assembler camp...
2008-05-29 16:40
omega120
Account closed

Registered: Sep 2005
Posts: 204
People can go what ever they want to go.
2008-05-30 19:51
Richard

Registered: Dec 2001
Posts: 621
I used to program in Turbo Assembler all the time, but now I use the ACME cross assembler, because the limitations are stronger. Turbo Assembler used to be good, but now we program C64 stuff on a PC, so I recommend anyone else to try this.

Someone pointed this type of advice to me. I cannot remember who introduced me to the ACME cross assembler environment but I think it is great and feel very comfortable with it. Easy to handle as well. :)
2008-05-31 15:32
Danzig

Registered: Jun 2002
Posts: 440
speaking of 8bit-machine code especially 6502 you can easily reach simple goals with a monitor. the crest-demomaker is s-mon ;)

but take into consideration: development speed... using a crossdev-toolchain is the way to go nowadays. i recomment kickassembler by any means, roxxor!

people still inserting commands in a 4k codeblock by transfering the code and then relocating the beast from the necessary position forward deserve empathy :D

also turboassembler (the c64-version ;) ) was a powerful companion in the 80/90s but fucked up sourcecode can nowadays easily be avoided ;) and using it in an emulator is just pain in teh 4rs3.

tons of different files on one disk each loaded separatly to test or just using ".incbin"s and get ONE resulting file... hm... your choice *G*

and, speaking about tool-chains in general, I just start the "making" and the result is a fully linked, crunched and .d64ed file... autostarting in an emulator (f.e. x64)...

pardon, but this discussion is useless in 2008...
2008-05-31 16:34
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
When writing tutorials for beginners there really shouldn't be any question; assemblers and particularly cross assemblers make it possible to worry about learning code without having to learn everything at once; working in a monitor requires learning hex, understanding how bits in a byte represent numbers and a number (s'cuse the pun) at the same time as learning 6502 itself.
2008-05-31 16:43
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:

working in a monitor requires learning hex, understanding how bits in a byte represent numbers and a number (s'cuse the pun) at the same time as learning 6502 itself.


uhm pardon but, if you cant take the hour to learn hex and bits and bytes (numbersystems such as sedecimal are primary school stuff btw) - forget about programming alltogether.

i would actually recommend playing around in a monitor aswell, atleast for a start, and especially to get familiar with the bits and bytes and all that junk.

ofcourse, once you have made a few trivial programs, you should move on to an assembler.
2008-05-31 17:16
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
It's almost like a game, if you don't keep someone's attention at the start they don't get over the first level; that's why my preference is to get people playing with opcodes and actually moving something onscreen (even inc $0400 or inc $d020 for an absolute starting point) and then introduce hex and how bits represent numbers. Actually getting a result onscreen for their effort more often than not hooks people in when just talking about different number bases for "chapter 1" doesn't.

Essentially that's how i learnt too, using an assembler that accepted decimal numbers and not dealing with hex straight away; i've still got mot of the source for my first real game and that's nearly all in decimal.
2008-05-31 17:36
chatGPZ

Registered: Dec 2001
Posts: 11386
again: numbersystems are primary school material. i learned about binary and hex (and octal =P) in 4th grade primary school atleast, and so should have most other people.

and seeing sources with 53280 instead of $d020 make me shudder really.

no really. learn the basics first, not somewhere along the way. if thats too much for your attention span...oh well. forget programming. you'll give up at the next roadblock anyway =P
2008-05-31 18:10
Oswald

Registered: Apr 2002
Posts: 5094
I have vague memories about "learning" number systems in primary school. I also remember not understanding it at all, just memorizing some processes.

I dont think majority learned hex 2's and stuff before anything else, rather the other way around. Its not crucial for anything anyway.
2008-05-31 19:59
Danzig

Registered: Jun 2002
Posts: 440
I remember my computer & math teacher claiming its impossible to convert hex to dec, bin, oct and via verca without writing the "way" down!!!
it was an exam, i just had the answers but had not written the solution on the paper.
he claimed i peeked my classmates. i said: ok, that guy was on the seat infront of mine and that guy behind me. check their answers, they are all WRONG. Finally he told me nobody except of me had the right answers but still claimed I peeked.
so i offered him to test me on the board. he shall write random numbers from the "numbersystems" and i will solve the corresponding systems. ofcourse he said: we have no time for this. and my points were still STOLEN!

this is now 18 years ago... but i still spray hex/bin/oct-numbers on the walls of his house each sylvester night ever since... ok, just joking *G*
2008-06-01 07:30
chatGPZ

Registered: Dec 2001
Posts: 11386
haha lol, i remember similar things :) teacher couldnt believe that i knew 2^16=65536 =)
2008-06-01 10:38
Conjuror

Registered: Aug 2004
Posts: 168
My lecturer at college was getting the students to do the 2^x, I took over after 2^8 and went to 2^16. They all looked at me like I was a freak. All from memory of course.

Steve
Conjuror/TF
2008-06-01 11:31
Martin Piper

Registered: Nov 2007
Posts: 722
Being able to mentally convert bases, especially decimal to binary or hex, is very useful while coding low level languages. I've been disappointed by the number of times I've interviewed job applicants for programming positions and found they couldn't convert the hex numbers in programming tests or understand the concept of bit masks.
2008-06-01 11:40
Conjuror

Registered: Aug 2004
Posts: 168
Quote: Being able to mentally convert bases, especially decimal to binary or hex, is very useful while coding low level languages. I've been disappointed by the number of times I've interviewed job applicants for programming positions and found they couldn't convert the hex numbers in programming tests or understand the concept of bit masks.

I think thats a bit harsh. Ok I can do it (sometimes), but don't need it in my every day job. (Java Developer.)

Maybe it shows a mind set or an extra interest in how computers work, so is a bonus.

My maths generally is not that good, but rarely do I need it at work. Recently I had to do coding to calculate the decay of radionuclides which wasn't too bad but calculating expiry dates was tricker. I had to reverse calculations which were exponential using logarithms. Didn't have a clue, but have friends with the knowledge so still managed to give the client what they needed.

Steve
Conjuror/TF
2008-06-01 11:44
Sander

Registered: Jan 2002
Posts: 496
Hehe, though i'm not a coder... i had a similar experience.
In primairy school, the teacher and the kids were in awe when i had to double the numbers and said these numbers in a row without a second of thought: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048. (ok, mine ended just there.. soz i became pikseler)
2008-06-02 19:16
Archmage

Registered: Aug 2006
Posts: 185
I'm with Sander on this one. Still I am convinced that it is possible to do some ok coding without being able to do decimal to binary to hex conversion standing on one foot. It's not all about the records either. A screens with some graphics displayed and a tasteful simple effect plus a scroller can be nice too.
2008-06-02 21:10
Burglar

Registered: Dec 2004
Posts: 1101
Quote: I'm with Sander on this one. Still I am convinced that it is possible to do some ok coding without being able to do decimal to binary to hex conversion standing on one foot. It's not all about the records either. A screens with some graphics displayed and a tasteful simple effect plus a scroller can be nice too.

that maybe true, but even for a simple scroller you need to know hex or binary. you need to understand how $d016 (smooth scroll register) works and what to store in it... doing that in decimal is more difficult ;)
2008-06-02 21:48
Oswald

Registered: Apr 2002
Posts: 5094
I have made a "smooth" upscroll in basic I knew how to use d011 (trial and error) and print statements to scroll up a charline when needed.

I have made my own charset in basic including data lines, poking them to mem, switching it on, etc. without a char editor, by drawing the chars on paper and calculating them by hand.

I have made a sprite editor in basic, which even saved the sprites as seq.

I have made a little animated (different phases for directions, animated turns) airplane sprite flying around the screen, being able to takeoff/touchdown to a runway, dropping bombs, etc in basic.

all this without knowing shit about hex or binary.
2008-06-02 21:53
chatGPZ

Registered: Dec 2001
Posts: 11386
you have created a sprite bitmap and calculated the right numbers to poke in memory without knowing binary? somehow that seems unlikely =P you might have not known that you did indeed know about it at this point =P
2008-06-02 22:11
Oswald

Registered: Apr 2002
Posts: 5094
there was a book explaining the process(edit: chapter 6.2 in the user manual, it explains it without introducing binary or bytes). I had another book explaining all the "pokes" of the sid/vic/cia with examples. fex.: poke 53265,(peek(53265) and 248)+yscroll
2008-06-02 22:19
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:

there was a book explaining the process.


it had a table with all possible combinations of the sprite bitmap and the corrosponding bitmap?

or did it explain the process of converting a row of pixels (== a binary number) to decimal?

i dont know, but somehow one of these seems unlikely =)
2008-06-02 22:30
Oswald

Registered: Apr 2002
Posts: 5094
 
  Say you want to create a balloon and have it float around the sky.  The
balloon could be designed as in the 24 by 21 grid:


                          SERIES |SERIES |SERIES
                             1   |   2   |   3
                                 |       |
                          1       1       1
                          2631    2631    2631
                          842684218426842184268421
                         +------------------------+
                       1 |.........#######........|
                       2 |.......###########......|
                       3 |......#############.....|
                       4 |......#####...#####.....|
                       5 |.....#####.###..####....|
                       6 |.....#####.###.#####....|
                       7 |.....#####.###..####....|
                       8 |......#####...#####.....|
                       9 |......#############.....|
                   R  10 |......#############.....|
                   O  11 |......#.#########.#.....|
                   W  12 |.......#.#######.#......|
                      13 |.......#..#####..#......|
                      14 |........#..###..#.......|
                      15 |........#..###..#.......|
                      16 |.........#..#..#........|
                      17 |.........#..#..#........|
                      18 |..........#####.........|
                      19 |..........#####.........|
                      20 |..........#####.........|
                      21 |...........###..........|
                         +------------------------+
                                   1    1    2   2
                          1   5    0    5    0   4

                                   COLUMN

  The  next  step is to convert the graphic design into data the computer
can use.  Get a piece of notebook or graph paper and set up a sample grid
that  is  21 spaces down and 24 spaces across.  Across the top write 128,
64,  32,  16,  8,  4,  2,  1,  three  times (as shown) for each of the 24
squares.  Number down the left side of the grid 1-21 for each row.  Write
the  word  DATA  at  the  end  of each row. Now fill in the grid with any
design or use the balloon that we have. It's easiest to outline the shape
first and then go back and fill in the grid.
  Now  if  you  think  of  all  the  squares  you  filled in as "ON" then
substitute  a 1 for each filled square.  For the one's that aren't filled
in, they're "OFF" so put a zero.
  Starting  on  the  first  row,  you need to convert the dots into three
separate  pieces of data the computer can read.  Each set of 8 squares is
equal to one piece of data called a byte in our balloon. Working from the
left,  the first 8 squares are blank, or 0,  so the value for that series
of numbers is 0.
  The  middle series looks like this  (again a 1 indicates a dot,  0 is a
space):

              128    64    32    16    8     4     2     1
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |  0  |  1  |  1  |  1  |  1  |  1  |  1  |  1  |
            +-----+-----+-----+-----+-----+-----+-----+-----+
               ^     ^     ^     ^     ^     ^     ^     ^
               |     |     |     |     |     |     |     |
               0  +  64 +  32 +  16 +  8  +  4  +  2  +  1  =  127


  The  third  series  on  the first row also contains blanks, so it, too,
equals zero. Thus, the data for the first line is:

                             DATA 0, 127, 0

  The series that make up row two are calculated like this:

            +-----+-----+-----+-----+-----+-----+-----+-----+
  Series 1: |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  1  |
            +-----+-----+-----+-----+-----+-----+-----+-----+
                                                         1  =  1

            +-----+-----+-----+-----+-----+-----+-----+-----+
  Series 2: |  1  |  1  |  1  |  1  |  1  |  1  |  1  |  1  |
            +-----+-----+-----+-----+-----+-----+-----+-----+
               ^     ^     ^     ^     ^     ^     ^     ^
               |     |     |     |     |     |     |     |
              128 +  64 +  32 +  16 +  8  +  4  +  2  +  1  =  255

            +-----+-----+-----+-----+-----+-----+-----+-----+
  Series 3: |  1  |  1  |  0  |  0  |  0  |  0  |  0  |  0  |
            +-----+-----+-----+-----+-----+-----+-----+-----+
               ^     ^
               |     |
              128 +  64                                     =  192

  For row 2, the data would be:

                            DATA 1, 255, 192

  In the same way, the three series that make up each remaining row would
be converted into their decimal value.  Take the time to do the remainder
of the conversion in this example.
  Now  that you have the data for your object,  how can it be put to use?
Type in the following program and see what happens.


unlikely? lol :) you havent seen the user manual so far? you can pretty much do anything without knowing hex or binary as the above and my own example shows.
2008-06-02 22:51
chatGPZ

Registered: Dec 2001
Posts: 11386
yeah sure. that example clearly doesnt explain how to convert a binary number to decimal. ofcourse.

you really love to argue, even if there is no point AND beyond =)
2008-06-02 23:08
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Quote: yeah sure. that example clearly doesnt explain how to convert a binary number to decimal. ofcourse.

you really love to argue, even if there is no point AND beyond =)


It does illustrate my point though, it introduces only enough[/b] knowledge to get the job of putting a sprite, something visual, on the screen done, nothing more and it doesn't even say that it's converting binary to decimal even if that's what is actually going on.

i've always felt that the best educational texts introduce just about everything in a way that the reader can get something happening on the screen so that they get a sense of progress; the balloon example in the manual does that, the majority of readers will think "i got a sprite on the screen" rather than "i can convert binary to decimal" even if they learnt both at the same time.
2008-06-02 23:28
chatGPZ

Registered: Dec 2001
Posts: 11386
yes ofcourse, but that wasnt my point. the point is that there is NO way to convert a sprite to the data you have to poke in memory other than either looking up the numbers in a huge table - or learning to convert binary to decimal. wether you call it so, now thats a completely different question and it doesnt really matter at all.
2008-06-03 00:24
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
i know it wasn't your point and never said that... just that your previous point about people learning hex and so forth is at odds to what i believe makes a good tutorial and the C64 manual, weak as it is generally, goes in the same direction.
2008-06-03 07:13
Oswald

Registered: Apr 2002
Posts: 5094
Quote: yeah sure. that example clearly doesnt explain how to convert a binary number to decimal. ofcourse.

you really love to argue, even if there is no point AND beyond =)



thats exactly what YOU did in this case. after implicitly calling me a liar, instead of simply admitting you were wrong, you couldnt resist kicking into me a last one. well done. how your friends used to say? "groepaz is a good and friendly scener" yeah my ass =)
2008-06-03 07:22
Archmage

Registered: Aug 2006
Posts: 185
@Burglar: yes, of course. But understanding the concept of hex and binary, which of course is mandatory when coding on the C64, differs from being able to do instant conversions off the top of your head. So my post was mainly directed at Martin Piper. Basically I just want to say that it is possible to do at least _some_ coding without being very good at maths - as in calculation - because a lot of it is conceptual. Like for instance _how_ $d016 works.

And spinning on from this with regards to the topic of this thread being "coding for beginners", how interested is the scene in seeing simple stuff like demos/intros without any fancy stuff at all? Just displaying a logo, playing music, a scroller and perhaps some sprites? After all, this is where coders begin I would think. I for one think that anything goes as long as there is serious effort behind it, but you veterans might have another view?
2008-06-03 07:34
Frantic

Registered: Mar 2003
Posts: 1648
I give a shit what people do, as long as they have some kind of fun when doing it AND as long as there is at least some kind of effort put into it.
2008-06-03 07:37
Oswald

Registered: Apr 2002
Posts: 5094
Quote: yes ofcourse, but that wasnt my point. the point is that there is NO way to convert a sprite to the data you have to poke in memory other than either looking up the numbers in a huge table - or learning to convert binary to decimal. wether you call it so, now thats a completely different question and it doesnt really matter at all.

nopes. _I_ made a point that one can make sprites and stuff without KNOWING binary or hex, which you attacked.

"you have created a sprite bitmap and calculated the right numbers to poke in memory without knowing binary?"

yes I did.

the proof is above the text from the user manual. anyone following that process will not understand or know binary numbers. (if he didnt knew them before..) he will just see a weird process with numbers, but that doesnt mean he has the slightest idea of binary numbers.
2008-06-03 07:56
Frantic

Registered: Mar 2003
Posts: 1648
Now, let's see... yes! LET'S SPEND THE DAY ARGUING!!! :)

2008-06-03 09:11
omega120
Account closed

Registered: Sep 2005
Posts: 204
As I see in the previous posts someone seems to say that you must use binary numbers to enter a sprite data, I can tell you I have never learned how to handle binary numbers as I have never used it, I always use hex numbers to enter sprite data.
2008-06-03 09:56
chatGPZ

Registered: Dec 2001
Posts: 11386
next time please someone hold me back from participating in a thread with oswaldnonsense involved, please. thanks.

oswald: your excerpt from the manual did exactly prove what i said. it _IS_ explaining how to convert binary to decimal. no matter how much you think it isnt. go look up somewhere else how it is usually explained, and see how similar it is.

oh well *sigh*
2008-06-03 10:58
Oswald

Registered: Apr 2002
Posts: 5094
groepaz, the nonsense is that you put words in my mouth and thoughts in my head I dont have.

what I have said(already 2 times, but you keep ignoring it, and make up artifical arguments for me to fight those) is this: I could design sprites/chars without understanding/knowing binary. and I did. I have added 128 if there was a pixel or 16 if there, etc. that doesnt means I knew binary. fex. if one would tell me to set bit 4. in $d011, I wouldnt be able to do it. I would have first understand what a byte and a bit is. 0's and 1's and the whole concept of a different number system than decimal.
2008-06-03 11:10
chatGPZ

Registered: Dec 2001
Posts: 11386
yeah ofcourse, now go and resort to rambling about details which are pretty much irrelevant for the point (why does this remind me of the threading discussion?).

read my first post again. to convert a row of pixels into a decimal number you can do two things:

a) look them up in a table
b) convert them yourself from binary to decimal

there is no other way. and noone with his right mind would even consider the table solution. (no wait, i HAVE seen tables like this, even in books - exceptions that prove the rule, as always). and the c64 manual doesnt either - it very obviously explains a binary to decimal conversion (and wether it calls it like this is very irrelevant)

and wether you thought you didnt know binary, or wether you didnt even think this is a numbersystem conversion, or wether you didnt even think at all - doesnt matter. you still converted from binary to decimal, and you learned it from the manual without knowing it. (good manual if it can achive it like this i'd say). [the bad point beeing, like you said, is that it didnt atleast mention in one sentence that pixels refer to bits in a byte - so you can apply what you have learned to other situations too]

oh well. ofcourse this all isnt so. instead of replying, everyone just go back to post #112 and repeat. o_O
2008-06-03 11:14
enthusi

Registered: May 2004
Posts: 677
to settle this (haha), I see both points. To an extent that there is none :)
Anyway, Oswald DID a binary conversion back then but didnt understand it which in my opinion is perfectly possible.
You cant draw sprites without doing binary "math" but there is no real "need" to understand it.
I recall myself poking shit into memory instead of variables in basic and I was wondering why some pokes failed. I made heavy use of poke and peek without even getting the idea why I couldnt poke >255 or why it was limited to 65535. Of course that was in 1951.
And Im CERTAIN many people still do lda #$35 sta $01 without a fucking clue
2008-06-03 13:08
Martin Piper

Registered: Nov 2007
Posts: 722
Why does oswald keep on trolling the same thing even when he has lost the point?
2008-06-03 14:17
Oswald

Registered: Apr 2002
Posts: 5094
"and wether you thought you didnt know binary, or wether you didnt even think this is a numbersystem conversion, or wether you didnt even think at all - doesnt matter."

it does. because thats where it all started. I have claimed that I could design sprites (on paper) for basic data lines without knowing binary - and you attacked that argument.

I havent said its possible without bin-> dec conversion. this is your artifical fabricated argument you put in my mouth to 'win' this argument.

ofcourse groepaz always wins every argument - and the black knight never looses =)

2008-06-03 14:25
chatGPZ

Registered: Dec 2001
Posts: 11386
yeah lets resort to irrelevant details! oswald discussion tactics ftw! *yawn*
2008-06-03 14:56
Frantic

Registered: Mar 2003
Posts: 1648
Thread closed
2008-06-03 17:31
Hein

Registered: Apr 2004
Posts: 954
It's like teachers arguing about the best way of learning fun stuff in front of a class of beginners, if any beginners are still here.
2008-06-03 18:52
Burglar

Registered: Dec 2004
Posts: 1101
Quote: It's like teachers arguing about the best way of learning fun stuff in front of a class of beginners, if any beginners are still here.

hahahaha, so true :)

they already left the classroom app 30 posts ago, but none of the teachers noticed...
2008-06-03 22:16
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Who said this was a classroom, that's what tutorials are for innit. =-)
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
iAN CooG/HVSC
Jazzcat/Onslaught
E$G/HF ⭐ 7
XmikeX
Guests online: 344
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Diskmag Editors
1 Magic  (9.8)
2 hedning  (9.6)
3 Jazzcat  (9.5)
4 Elwix  (9.1)
5 Remix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.184 sec.