coding tutorial lessons wanted?

[Heaven/TQA]

are you interested in small coding examples for atari 8bit computers?

 

i haven't much freetime right now to go with my projects timepilot and senso7800dx but i want to code something smaller... like examples how to scroll, bitmap stuff, PM stuff, etc... just for the newbies who want to code games in assembler... what do you think?

 

tools:

 

atari800win 3.0+

XASM

turbo basic

Code Genie PC Editor

 

hve

[Wrathchild]

I might join in on this....

 

I'm putting together a 101 for developing

cartridge (XEGS) images to run on A800Win

 

I'm using the CC65 suite and so this will

include a mixture of ASM and C.

 

Mark.

[Jetboot Jack]

Mark/Hve,

 

Sounds very cool guys!

 

I'd certianly be intrerested in a "C" tutorial - I'm using XASM right now, and whilst I've gotten all my basics working (which took far too long - since my memory failed me in SO many areas) - scrolling, DL & DLI's, redefined chars, PMG, some raster kernals etc - it is really very difficult to get the motivation to do much proper game logic in ASM, its so much easier to work in a more structured language that allows more natural language concepts to be created...

 

A high level alternative in a standard language like C (as opposed to falling back on compiled Basic or Action) would be AWESOME!

 

Added to which my drive to learn C/C++ has put my 8bit work on hold (well that and getting a new job!) and a chance to combine the two would be a real treat!

 

sTeVE

[calamari]

Jetboot,

 

I checked into cc65 (the 6502 C compiler). Unfortunately, it doesn't seem to produce very optimized code (in fact it says in the docs that it doesn't try to optimize at all). Which is too bad, because C should be a good language for optimizations. I decided to do some tests to see how it treated a straightforward program. Here was my code:

 

void main() {

 //docs say unsigned char is best

 unsigned char z=0x10; 

 //docs say use predec over post dec

 ++z;

}

 

Here was what I was expecting it to look something like:

 

lda     #$10

sta     Z

inc     Z

 

Here is what I got instead:

lda     #$10

jsr     pusha  

ldy     #$00

ldx     #$00

clc

lda     #$01 

adc     (sp),y 

sta     (sp),y

ldy     #$01

 

My poor, poor program. Z was promoted to a 16-bit value (why? My variable type was unsigned char), Z was accessed indirectly like an array (adds 1 cycle, plus cycles for having to zero out Y), and ADC was used to do the increment, completely destroying any savings I might have seen.

 

If someone knows how to produce tight code with this thing, PLEASE let me know. I think it would be very cool to have a C compiler for 5200. It shouldn't be too hard to make a 5200 target for cc65 (there is an Atari 800 target). But, with this kind of code output it would be impossible to use it for anything but the simplest programs.

 

calamari

 

p.s. does anyone know the algorithm to systematically produce combinations like this: ABC ACB BAC BCA CAB CBA (and also for ABCD or ABCDE, etc, or for combinations like AB-ABC, where it would be AB-ABC, BA-ABC, AB-ACB, BA-ACB, etc? I am experimenting with the idea of an optimizing expression parser, but I want it to make sure it uses the best form of the expression that will lead to the fewest cpu cycles, and that means rearranging the expression in all possible ways.

[Thomas Jentzsch]

Here is what I got instead:

lda     #$10

jsr     pusha  

ldy     #$00

ldx     #$00

clc

lda     #$01 

adc     (sp),y 

sta     (sp),y

ldy     #$01

 

My poor, poor program.  Z was promoted to a 16-bit value (why? My variable type was unsigned char), Z was accessed indirectly like an array (adds 1 cycle, plus cycles for having to zero out Y), and ADC was used to do the increment, completely destroying any savings I might have seen.

It looks to me like the compiler stored the variable on a stack. That would make perfect sense for local variables.

 

So, try making Z a global variable!

 

BTW: I don't see that Z is now a 16-bit value. It's a 16bit pointer to a 8 bit value.

 

BTW2: PreInc vs. PostInc: Yes, PreInc is usally faster, especially when you get a return value (e.g. a = ++b). If you use PostInc, the compiler has to load/store the old value for return first and then increase.

For simple variables (like your 8 bit example), that shouldn't make big difference (except for an unoptimizing compiler ), but if you are working on larger values or structures it sure does.

[twh/f2]

are you interested in small coding examples for atari 8bit computers?

 

i haven't much freetime right now to go with my projects timepilot and senso7800dx but i want to code something smaller... like examples how to scroll, bitmap stuff, PM stuff, etc... just for the newbies who want to code games in assembler... what do you think?

hve

 

this is a great idea! Especially in creating little snippets, which can be used for the game/demo main body. This is a general problem for newbies (me for example) ...

 

what about: scrolling, loading graphics, setup a dli, insert music via vbi or a simple "hello asm.world"

[Osmeroid]

I'd be very interested in this - getting started is always the hardest part

[Heaven/TQA]

ok... tomorrow is a bank holiday here in germany so i can start small bits and pieces...

 

but a 1st frame work is

 

http://www.s-direktnet.de/homepages/k_nadj...j/senso256.html

 

a small approx. 480 bytes "big" game... should be understandable for

newbies as hard optimisation was not started yet...

 

hve

[Jetboot Jack]

Calamari,

 

Thanks for the info - I was thinking of writing all the basic screen handling and PMG code in ASM but use C for the logic part...

 

I have been working on an 8bit (and 5200) version of Pepper II - and was struggling slightly with a good way to both lock the main character to the zippers and also make the zippers zip up, undo and lock zipped up.

 

I had considered using a check for which character the PMG is over and using that to determine the direction the player could move and whether it needs to change to a zipped up or unzipped graphic - I am using Antic 4...

 

Whilst I've had no problem creating the flow of the code and a rough version in basic, its a bit hideous in ASM (but then again I may be just a bit thick) so was thinking that C would be a good choice to handle such work...

 

I guess speed would be important for the use I am thinking in this project, since I would want to run the game either in one or two frames...

 

sTeVE

[calamari]

Thomas suggested using a global variable. Here is my new test code:

 

unsigned char z=10; //global variable

void main() {

 ++z;

}

 

Here is the compiled result:

.segment        "DATA"



_z:

       .byte   $0A


; --------------------
; void main ()
; --------------------



.segment        "CODE"



.proc   _main



       jsr     enter

       ldx     #$00

       inc     _z

       lda     _z

       jsr     leave

       rts



.endproc

 

This code is looking a lot better with the global variable. ldx #$00 and lda _z seem to be unused in this case. I did some other experiments, and declaring all variables as global is clearly the way to go, but you still have to be very careful with your code. z+=w; is good, but z=z+w; involves a subroutine call to do the addition. z+=1; compiles the same as ++z;, good. z*=2; and z<<=2; both call a subroutine instead of shifting left. ++w[1]; worked well. Loops seem to produce decent code. Nothing is optimized though. With a do...while loop and a --z; inside the loop there are duplicate lda _z's next to each other. You'd definitely want to clean up the source after compiling to remove the extraneous code.

 

Jetboot:

Now, obviously I'm biased in this area, but... as far as converting goes, translating from Atari Basic to 5200BAS shouldn't be a big deal. You'll have access to Quickbasic style program control statements: multiple line/nested IF/ELSE/END IF, AND and OR in IF are accepted, you can test for ZFLAG, CFLAG, etc (to save cycles), DO...LOOP (WHILE/UNTIL), FOR...NEXT, SELECT CASE. Unlike C, you would have to break down any algebraic expressions into pieces. For example, you might rewrite Q=W+2 as A=W:A=A+2:Q=A. This should not be too big a deal for most expressions and gives you full control. Once you get the basic program translated, compile it. Then copy & paste the relevant asm code into your main program.

 

calamari

[Thomas Jentzsch]

You'd definitely want to clean up the source after compiling to remove the extraneous code.

While the new code looks much better, IMO it would be much better to include some simple peephole optimizations to the compiler (or write a post-compiler for that) instead of having to rework your code over and over.

[Heaven/TQA]

i finally made a nice antic 4 distortion demo for use in atari800win.

 

all sources, readme, xasm, etc... included.

 

tell me what do you think. i will involve this basic demo to far more interesting stuff... sty tuned

 

http://www.s-direktnet.de/homepages/k_nadj...prog/intro1.zip

 

hve

[mos6507]

I was wondering if there were any 8-bit cartridge disassemblies available anywhere?

 

I'd like to know what the differences are in assembling a game meant to run as a ROM cartridge vs. an executable that runs out of RAM.

 

It would be nice if there were a simple "HELLO WORLD" type program available with conditional assembly that could build itself into a cart-ready ROM image or executable, like the equivalent of "How to Draw a Playfield" for the 2600.

[Thelen]

That example is super !!! I missed it on 22th...

 

@ Cybpunks, I have included a example for a HELLO WORLD program. It assembles with XASM like the example from Heaven.

 

Thelen

hello.zip