The Southsider

Congratulations on reaching Beta, Chris! Regrettably I haven't had much time for testing lately. I haven't even downloaded Cabbage Patch Kids yet!

Congratulations on reaching Beta, Chris! Regrettably I haven't had much time for testing lately. I haven't even downloaded Cabbage Patch Kids yet!

 

Thanks for the message. I was like that last year, which is why Juno First took so long to complete. I hope you get a break soon as I'm really looking forward to seeing Chetiry completed.

 

Chris

Thanks for the encouragement, Chris. Oh yes, I'll get a break this summer. That's the nice thing about working in education. The thing is I'll be busy catching up on all the things I haven't done since September. So the question is, will there be enough time to finish a homebrew along the way?

Doesn't assemble for me.

d:\_privat\Atari\dev\dasm\Projects\JunoFirst>dasm juno1.asm -f3 -ojuno1.bin
---- $0 bytes left (RAM)
---- $31a bytes left (BANK 1 - MAIN GAME)
---- $116 bytes left (BANK 2 - KERNEL A)
---- $116 bytes left (BANK 3 - KERNEL B)
juno1.asm (2521): error: Unknown Mnemonic '256'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
---- $1f6 bytes left (BANK 4 - GAME LOGIC)
---- $30 bytes left (BANK 5 - WAVE DATA)
---- $a bytes left (BANK 6 - SAVEKEY)
---- $606 bytes left (BANK 7 - MUSIC)
---- $119 bytes left (BANK 8 - TITLES)
Unrecoverable error(s) in pass, aborting assembly!

I am using the latest vcs.h, macro.h and DASM files.

 

BTW: If you need help optimizing for some extra space, please let me know.

And with z26, your binary finds(!) a SaveKey.

And with z26, your binary finds(!) a SaveKey.

 

I know about this one - it appears to be a bug in z26.

 

Chris

Doesn't assemble for me.

 

Not sure why you are having this problem - I am using DASM 2.20.11 and unmodified standard include files. The only difference is that I am using Linux. Perhaps there are some special characters in the source code, or it is getting confused by the carriage returns. I have attached an archive (Juno_First_BETA2.zip) to the top level containing the latest version. This archive contains the .h files that I am using and a version of the source (juno1.asm.dos) that has been run through unix2dos - can you see if this works for you?

 

BTW: If you need help optimizing for some extra space, please let me know.

 

I'm OK for space at the moment thanks to a huge 32K ROM size, but I am desperately short of RAM if you can spot any obvious optimisations?

 

Thanks,

Chris

I have attached an archive (Juno_First_BETA2.zip) to the top level containing the latest version. This archive contains the .h files that I am using and a version of the source (juno1.asm.dos) that has been run through unix2dos - can you see if this works for you?

Works!

 

I'm OK for space at the moment thanks to a huge 32K ROM size, but I am desperately short of RAM if you can spot any obvious optimisations?

Finding RAM is tougher. I will have a look.

Finding RAM is tougher. I will have a look.

 

I'm glad it assembles for you now. Don't spend too long looking as the game is essentially finished - just if you spot any obvious optimisations. One thing that could use some optimisation is the music player and data. It is currently occupying its own bank (bank 7), but if it could be squeezed in with the title-screen data (in bank 8 ) then I would have space for another colour scheme.

 

Thanks,

Chris

I am far from understanding your code, but I noticed some things. Generally your code looks very good organized (better than a lot of my own code ). But some things could be improved:

1. You are mixing temporary, local variables with permanent, global variables (e.g. INVS). This makes it hard to keep track of RAM usage.

IMO you should define are rather large, global space for temporary variables. Then you can optimize this space for size and get rid of blocking RAM space permanently.

2. While you are at it, I would use the SUBROUTINE keyword of DASM and define local variables locally by preceding them with a '.' (this is possible for lables too).

That brings your code closer to high-level languages and makes it IMO better maintainable.

 

Some subjective, random code style tips:

I am using mixed case for variables and labels, and upper case for constants only. IMO makes the code more readable.

I use the SUBROUTINE keyword wherever I can and define my local variables right at the start of a subroutine.

Local lables and variables allow you to be lazy and reuse names.

 

Last not least, for a vertically oriented game, I would try to use more than 192 scanlines for the kernel (NTSC TVs can easily display 200 and more lines). Even if that means using more than 262 scanlines in total.

One thing that could use some optimisation is the music player and data. It is currently occupying its own bank (bank 7), but if it could be squeezed in with the title-screen data (in bank 8 ) then I would have space for another colour scheme.

Music player and data require about 2.5k. But there is just maybe 1k free in bank 8.

 

Hmm...

Music player and data require about 2.5k. But there is just maybe 1k free in bank 8.

Hmm...

 

Yes, it's probably not possible, unless some clever encoding of the music data can be found.

 

Chris

Hi Chris

What should i say,really great work...........

greetings Walter

Yes, it's probably not possible, unless some clever encoding of the music data can be found.

 

The smallest blocks of the music data are 9 bytes and it's broken down in three levels. That would usually provide a good compression already, compared with totally raw data.

 

Does the music kit allow tweaking of the size of the smallest blocks? Maybe 3 or 6 would produce a better result. I kept that value totally variable in SID2TIA, since you can often gain another 10-15% by finding the "best" granularity. The smaller the blocks get the bigger the overhead in the next level gets, so at a certain point you're losing more than you gain when going to an even smaller block size.

 

I only do 2 levels though, since that makes more sense for smaller songs with few repeating parts. For a larger song with more repeating parts three levels are better.

 

It can also make sense to use different granularities for both voices for optimum ROM usage, unfortunately at the cost of extra position counters in RAM though.

 

So far for the theory. As for getting "real", it'd be best to have the raw data in hands, then you can go and try some things. I wouldn't expect to gain more than 20% during such a process (since it already _is_ patternized), so personally I wouldn't even try to get it from 2.5K down to 1.0K if that is the only goal.

 

BTW: AFAIR did supercat write some pack/unpack code for music somewhere during the creation of Toyshop Trouble. Would be interesting to see wether packing is better than patternizing. I'm pretty certain though that proper patternizing will win in most cases

Thomas,

 

Thanks for the suggestions. The variables are certainly in a mess at the moment. This happened when I integrated together all of the different parts (high score table, title screen, music, main game). I managed to find a couple of spare bytes to improve the high score table by organising things better. I haven't used the SUBROUTINE keyword before - it sounds very useful - it's probably too late for this project but I'll definitely use it next time.

 

Chris

I am desperately short of RAM if you can spot any obvious optimisations?

I haven't checked whether you've done this already, but you can squeeze a few bits of RAM out of the PC. In fact, supercat described a lot of clever ideas for milking extra RAM out of the Atari during our chess discussion.

I haven't checked whether you've done this already, but you can squeeze a few bits of RAM out of the PC. In fact, supercat described a lot of clever ideas for milking extra RAM out of the Atari during our chess discussion.

 

Thanks for the pointer - there are some good ideas in there that I would never have thought about!

 

Chris