Pong with segments

[+karri]

From the docs of the cc65

 

Special locations:

0000 - 00FF Zero page

0100 - 01FF Machine stack

 

A058 - C037 Collision buffer

C038 - E017 Screen buffer 1

E018 - FFF7 Screen buffer 0

FFF8 - FFFF Hardware vectors

 

At the end of RAM we have a C-stack 0800 just under collision buffer

[Shawn Jefferson]

It was simply a case of little mistakes here and there on my part. For anyone else trying to work out how to reference the bitmaps, you do it the same way as normal. eg. bitmap1.bmp (and ultimately bitmap1.o), you normally just have extern char bitmap1[]; and that's exactly the same even though the .o file isn't firmly linked to the executable part of the directory. I think that directory 0 = the executable btw?

 

For the compiler, the label "extern chat bitmap1[]", has an address of $200, since that's where you had defined it to be with your linker config and your segment. The compiler doesn't know or care that this may not be in memory (since it's on the cartridge). It's your job to be sure the right data is in memory when you reference it from your program.

 

directory = 0 is your executable, yes. The first directory entry is read by the lynx startup code (crt0.s in the library source.) (actually the bootloader that is loaded into high memory on the lynx from the startup code).

 

I would also like to clarify my question about the RAM start address, originally 0 I changed it to 1200 to accommodate the 1000 size bitmaps starting at 200, is that right or am I missing something?

 

You definitely want to set the start of the RAM memory area to $1200, otherwise, when your bitmap is loaded in, it will overwrite your code probably leading to a crash of your program. If your directory is not quite right, it may overwrite your code as well (lynx_load looks at the directory entry to see how many bytes it should load.)

 

Would be useful to understand typical memory map - how much RAM for code and data typically, with collision buffers used and where are the 2 / 3 screen sized buffers located - is that handled by the compiler or is it a fixed address?

 

Karri posted the memory map for you. Only the zeropage, hardware stack, and ROM are "fixed". The rest is setup by the cc65 lynx runtime library. The collision buffer, screen buffers are set by the startup code (or maybe tgi_init? I haven't looked at the lynx runtime source lately). The lynx linker config takes this into account by setting the RAM memory area size appropriately, so that your code won't accidently overwrite the collision buffer and screen buffers.

 

Although, you have an error in your linker config, since you didn't adjust the size when you added $1000 to the start of the RAM memory area:

 

RAM: file = %O, define = yes, start = $1200, size = $9E58 - __STACKSIZE__;

 

This puts the "top" of your RAM memory area at ($B058 - __STACKSIZE__). This is right in the collision buffer area. And also, since the C stack is setup to be directly at the end of the RAM memory area (as shown by this code from crt0.s):

 

setup the stack

lda #<(__RAM_START__ + __RAM_SIZE__ + __STACKSIZE__)

sta sp

lda #>(__RAM_START__ + __RAM_SIZE__ + __STACKSIZE__)

sta sp+1

 

What that also means is that your C stack is right in your collision buffer. Your program, if it uses the collision buffer, will be overwriting the C stack, causing your program to behave erratically and probably crash.

 

You should change it to:

 

RAM: file = %O, define = yes, start = $1200, size = $8E58 - __STACKSIZE__;

 

I hope that all made sense. Understanding these linker configs is key to getting benefit from the cc65 toolchain! And it does take awhile to figure them out if you haven't used them before.

[GadgetUK]

Excellent, it all makes sense now!!! Thanks ever so much for both of your help and patience!

[obschan]

Was there any recent change in cc65 which may requires us to rework the previous working code ?

I have updated to the latest svn version yesterday and since then I can't have anything working, keeps crashing.

I gave a try to your samples, pong.zip and pong2.zip, I get the same behavior, crashing before showing anything.

I must have missed something ...

Thanks in advance.

Edited March 24, 2013 by obschan

[LX.NET]

Do you by any chance get illegal opcode at $10000 ($FFFF + 1)?

[obschan]

Yep !

[sage]

optimizer bug?

[LX.NET]

I am not sure what it is, but I did get this error on one machine, not the other. I can look into the versions on each of them and report back. Hold on.

[obschan]

Arghhh I thought you knew what was going on ! ...

I get the illegal opcode at $10000 on my own programs but different illegal opcode locations on pong and pong2.

[LX.NET]

Arghhh I thought you knew what was going on ! ...

I get the illegal opcode at $10000 on my own programs but different illegal opcode locations on pong and pong2.

Sorry, obschan. I don't. I thought I was having this problem because I was working on segments and shoving memory and directory entries around. I had a different version of my source code on one machine (with CC65 version 5989) that was giving me the problems and headaches. On my other machine I had a other set of source code and CC65 version 5944. That was still OK. So, my guess is that it must be the compiler latest version.

The snapshot directory at CC65.org seems to be offline atm.

Edited March 25, 2013 by LX.NET

[Shawn Jefferson]

There is not likely to be any further snapshots, as Uz has given up the cc65 compiler. The only hope is that one of the other guys from the community takes it over and runs with it.

[obschan]

@karri which SVN version were you using to dev. pong2.zip ?

[+karri]

The version on my laptop is r5973 from 2013-01-27.

 

Or perhaps earlier. I am currently in Japan for 2 weeks so it will take a while to get back home to check this.

[obschan]

Thank you karri, everything is back to normal with the 5973.

And enjoy the sakura season !

Edited March 27, 2013 by obschan

[+karri]

Thank you obschan. Actually I got invited by some colleagues to join in a company Hanami party on the 5th. Today the weather was sunny and nice in Tokyo and tomorrow we will check out some sights here.

[sage]

The version on my laptop is r5973 from 2013-01-27.

 

Or perhaps earlier. I am currently in Japan for 2 weeks so it will take a while to get back home to check this.

 

Thats funny, all the flashcart designers in Japan the same time... what a pity that i have been three weeks too eraly :-(

Edited April 1, 2013 by sage

[Lynxman]

Thats funny, all the flashcart designers in Japan the same time... what a pity that i have been three weeks too eraly :-(

 

I stay in Japan until 10th.

[+karri]

Perhaps we should have a Lynx Hanami party

 

Lynxman, where in Japan are you?

 

I came to Kobe tonight and I will stay here for a while.

[GadgetUK]

Hi,

 

I am trying to get output from Chipper working with CC65 but getting errors on compile of the .asm file:-

 

music.s(33): Error: `.B' is not a recognized control command

1>music.s(33): Error: `:' expected

1>music.s(33): Error: Unexpected trailing garbage characters

1>music.s(36): Error: `.B' is not a recognized control command

1>music.s(36): Error: Symbol `dc' is already defined

1>music.s(36): Error: `:' expected

1>music.s(36): Error: Symbol `.size' is already defined

1>music.s(36): Error: Unexpected trailing garbage characters

1>music.s(41): Error: `:' expected

1>music.s(41): Error: Unexpected trailing garbage characters

1>music.s(103): Error: `:' expected

1>soundbs.mac(12): Note: Macro was defined here

1>music.s(103): Note: Macro parameter came from here

 

I've tried 3 different format of exports from chipper and I don't get where the problem is?

 

I can compiled the popcorn example you provided which came from chipper originally. but the format of the .asm is different than what chipper produces??

[+karri]

You should choose cc65 remake as the format. Right now you are using the BLL format.

 

It should have keywords like .byte mod dc.b

 

--

Karri

[sage]

I've tried 3 different format of exports from chipper and I don't get where the problem is?

 

I can compiled the popcorn example you provided which came from chipper originally. but the format of the .asm is different than what chipper produces??

 

you use the cc65 remake or newcc65 compiler?

 

Just as a remark: the example uses a mix of lyxass and cc65 code.

I was to lazy to add another example code...

Edited April 19, 2013 by sage

[GadgetUK]

Thanks, I will have another go when I feel better later.

[GadgetUK]

I think Der Luchs sent me the wrong formatted file previously because it was labelled BLL CC65 New and yet it looked like another format. I've tried exporting 5 sample songs out of Chipper as BLL.NewCC65 and they all work fine!

Edited April 21, 2013 by GadgetUK

[Der Luchs]

Jep, that can be possible!

All these different Exports

[GadgetUK]

Jep, that can be possible!

All these different Exports

 

Don't worry, these things happen! It took me a while to work it out because its still not perfect syntax wise and you could assume it just isn't going to be right. eg. Theres a 'set' directive at the top and it misses the dot out, it shoud be .set. Once you've fixed that, altered the .export stuff and segment it all works fine. I swear I tried before on all 3 formats and it didn't work, I must have been having a bad day...

 

I am thinking about implementing sound effects in the same manner - just use Chipper tracks for each sound. Not sure how large they will end up being for simple sounds... Before I do that I am going to have to re-factor my code again and create a sound 'space' in RAM. If you could send me a couple of tiny sounds, anything at all, then I can see what sort of size I am going to need to accommodate. I guess after we've done that i've got a fully working engine that could accomodate most game types provided segmenting is used from the start.

 

The way its stuctured at the moment, I have 4Kb bitmap buffer for background images - so I can effectively have no limits on the number of backgrounds etc, then I have another 9Kb segment which currently hosts either 2 different code blocks, or the music segment.

 

Main logic is in the remaining RAM, so on startup I don't load 'game play code' or 'pre init game play code', I just load the code for title screen, options, and segment into the 9Kb window the music. Then when starting the game I stop the music, swap the 9Kb music segment for the 'init code' segment. Initialise the game, then swap the 9Kb init code seg for the 'game play' code seg. Problem is I pretty much keep expanding the 9Kb segment size, which steals from the main segment size. Anyway, if you could send me a couple of example sounds - simple ones, say like 1 second each or something, just so I can see what I am looking at - because if they are small I might just be able to squeeze say 0.5Kb or 1Kb as another segment out of the main chunk or something.