wallaby

LDA #0 LDY #<my_sprite JSR SetValue2 LDA #1 LDY #((>my_sprite) & $0f) | (((>my_sprite) / 2) & $70) JSR SetValue2 LDA #128 LDY #<my_sprite_color JSR SetValue2 LDA #129 LDY #((>my_sprite_color) & $0f) | (((>my_sprite_color) / 2) & $70) JSR SetValue2 This set of ASM functions are costing me a fair amount of space. Is there any way to pre-calculate the addresses in constants so I can set them in bB without having to calculate them on the Atari?

Not sure how much yet. Since this is my first Atari program I don't really know how much any feature costs in ROM size yet. I'm trying to fit the entire engine in 32k, and I think I'll be able to. It just won't leave any space for making the game any fun. Definitely no real CPU cycles to spare. I'm already alternating code per frame. I'll start by finishing the whole game engine. I'll only have a few hundred bytes left over assuming I'm successful. Thanks for the offer. The program is over 5,000 lines at the moment. I'm already putting just about any re-used code in sub-programs, but even calling them is expensive size-wise. I've replaced a few bB lines of code with slightly smaller ASM ones, but they're only saving a few bytes here and there. bB is a pretty decent pre-compiler! You mean there is some special processing in bB that reads notes in that mode? Or that is just a good starting sound for music? What I ended up writing was code that reads a 5-byte line describing a sound. The coolest (in my opinion) feature is it can chain data together to make complex sounds - it just treats them like a new sound. So simple sounds might have one single data entry. Complex sounds might have 3 or more all chained together like a linked-list but played back as if they're a single sound. The issue is I have to bank switch to set the initial sound. That costs ~20 bytes just to call a sub program. Instead, I'm planning on altering it so it just caches the index of the sound and only bank switches once per frame to set the sound. Instead of setting it right away. 20 bytes per sound is costing me a few hundred bytes even though the playback engine I wrote is small.

That is a ton of power for only 4k games. Will it eventually support larger sizes? Couldn't the FPGA alone clone just about any kind of 8-bit / 16-bit computer? It's like a Ferrari engine in a shopping cart.

You can only have one title screen, but you can animate the graphics. The only drawback to the title screen is how much ROM space it needs. You can easily fill a 4k bank. If you've budgeted that space in (I didn't, hah) then you're good to go. As for instructions - the title screen download in the first message in this thread has instructions in the .pdf. They're written well and easy to follow. Good luck!

I fell over the edge, so to speak, when I realized I needed to write an audio driver. Leaving sounds to the end is normal for me, but I didn't anticipate how much space I would use calling the sound sub program for each sound. I still have plenty of graphics bank space, but I tried running code from there and it doesn't work. I don't suppose there is a 64k DPC+ option? I might have to cull some features.

I messed around with adding it to the titlescreen kernel just as a test. It did not go well.

Are you sure this idea has merit? I mean, consider all the ideas you have. Maybe things no one has ever tried before. Clones of other games are a great starting point, but with a universe of possibility and artistic talent you could probably do better. No one even likes Hydlide. So you'd be parodying a game no one even cares about. If you consider a limited amount of time to create things like this, there are so many better ideas you could slot in there that would make a bigger impact. (In my opinion.)

Anyone looking for this in the future: it's not supported in batari basic. To use the extra sound capabilities of DPC+, you need to write your game entirely in ASM. This is because the DPC+ kernel in bB doesn't execute the required sound updates once per scanline. However, there is some sound support included in the kernel but it's not usable. I bet you could re-claim some space by commenting it out. If I was more experienced I might try to add it in. Maybe one day.

Okay, I understand. I'm using 50% bB and %50 ASM for my game and I incorrectly assumed it was supported in the bB DPC+ kernel. I think I'll have to pass on it for now. There isn't enough space to add it to bB's DPC+ bank. It's strange though, the waveforms are in the kernel. If I were to add LDA AMPLITUDE and STA AUDV0 to each blank, I think it would throw the timing off.

lda #44 STA NOTE0 STA NOTE1 STA NOTE2 lda #SINE_WAVE sta WAVEFORM0 sta WAVEFORM1 sta WAVEFORM2 lda AMPLITUDE sta AUDV0 All this does is generate a crackling sound. #44 is the value of the note C4. This is running once per drawscreen. Anything obvious I'm doing wrong?

Yes! That was it. Thank you for that. So now it compiles, but it crashes Stella. I'm guessing because DPC+ has changed since it was written? I wonder if those other errors were the result of copying Linux LFs into my code. Back to try again.

ShowAmplitude0: .byte zz________ .byte zzX_______ .byte zzXX______ .byte zzXXX_____ .byte zzXXXX____ .byte zzXXXXX___ .byte zzXXXXXX__ .byte zzXXXXXXX_ .byte zzXXXXXXXX ds 8, zzXXXXXXXX ShowAmplitude1: ds 8, zz________ .byte zz________ .byte zzX_______ .byte zzXX______ .byte zzXXX_____ .byte zzXXXX____ .byte zzXXXXX___ .byte zzXXXXXX__ .byte zzXXXXXXX_ .byte zzXXXXXXXX ALIGN 256 MusicData0: ; Bar 0 DC.B C4 DC.B 0 DC.B 0 DC.B 0 DC.B E4 DC.B 0 DC.B 0 DC.B 0 DC.B G4 DC.B 0 DC.B 0 DC.B 0 The showamplitude data won't compile. (A different type of byte definition syntax?) The music data compiles but crashes the game. Even if I just put DC.B C4 on a line on its own, the game crashes. What is DC.B? A special kind of datatype? It looks like C4, G4, E4 are types of notes and not hex? I can get sound coming out, but it doesn't sound nice and it's only possible if I set NOTE0 to #3. But it just sounds like the normal Atari TIA.

sta AUDV0 lda (MPTR2),Y Gets the error "Value in 'lda (MPTR2),Y' must be <$100." Same error for all of the MPTRx loads. I guess it's saying the value is too high. If I comment it out, it compiles. But there is no sound or anything.

I agree what you're saying, but I found it difficult to isolate just the music code. When I attempt to compile the .asm with DASM, the errors I get are: C:\Atari\DPCPlus>c:\atari\dasm dpcplus.asm dpcplus.asm (6547): error: Unknown Mnemonic '35,'. dpcplus.asm (6550): error: Unknown Mnemonic '$CA,'. dpcplus.asm (6550): error: Unknown Mnemonic '$CA,'. dpcplus.asm (6550): error: Unknown Mnemonic '$CA,'. dpcplus.asm (6550): error: Unknown Mnemonic '$CA,'. dpcplus.asm (6550): error: Unknown Mnemonic '$CA,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6554): error: Unknown Mnemonic '$F8,'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6558): error: Unknown Mnemonic '$C4'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6563): error: Unknown Mnemonic '$80,'. dpcplus.asm (6568): error: Unknown Mnemonic '$8A,'. dpcplus.asm (6568): error: Unknown Mnemonic '$8A,'. dpcplus.asm (6568): error: Unknown Mnemonic '$8A,'. dpcplus.asm (6568): error: Unknown Mnemonic '$8A,'. dpcplus.asm (6568): error: Unknown Mnemonic '$8A,'. Unrecoverable error(s) in pass, aborting assembly! Complete. But that's just the tip of the iceberg. So what I thought the best thing to do was isolate the code and slowly copy-paste it into a known working compile until it stops working. But there are some syntax that seem incompatible. I'll try to remove just the sound making part of this again to find out exactly what, if you like. That's the main reason I asked for the most atomic example. Like the "hello world" of DPC+ sound. I'll give it another shot.

Yes, this demonstrates the sound, and is a great resource, but it is extremely difficult excise from the demo code. I don't have an ARM development environment so I can't compile the source and tinker with it there. Plus, some ASM commands seem incompatible with my version DASM and/or I lack the understanding on how to port it to an empty DPC+ project. All I need is a demo of playing a single sound that I can duplicate for the other voices. This has a visualizer, and what looks like a tracker (which is cool, but beyond my current ability to re-use), and important data that is spread around the source. The variables at the top and wave data at the bottom (also very cool). It's very tantalizing, but I can't get past weird compiler errors I'm getting and at a fundamental level I don't know what it is doing most of the time. Assuming I already have a graphics loop, what is the smallest loop I can use to just play sounds? (No visualization)

Getting direct access to the memory location for the playfield would be a big boon for me too. I use horizontal scrolling in DPC+ but it's a hack by animating the playfield. If I could procedurally generate my playfield it would save a few thousand bytes too.

Interesting. Bank 7 works okay for me. I wonder if I have a newer or older version of DASM? I didn't expect it to work in Bank 7, but when I tried, it runs fine. As for ROM locations - it would be fine if you could calculate the address before it's compiled. I don't know how to do that. Plus, I think the address would change anytime you added anything and you'd have to re-do it. I tried experimenting with setting the address in a constant but it sometimes didn't work.

Are there any examples of driving the DPC+ sound chip from ASM? I think the TIA was designed for sound effects mainly and its dashing my dreams of nice chiptunes for my game. I've been searching around for a bit, but I haven't found any sound examples at all. Another 3 voices would be a lot of fun to utilize.

Sure, no problem. This community has helped me numerous times and it would be great to be able to contribute for once! But this isn't very elegant as can be complicated. First, you need to define your graphics data as a data statement: data my_sprite: {sprite data here} end You'll also want the color information. You can use that as a data statement too. data my_sprite_color: {colors} end You can put this anywhere, but I put it in bank 7 (which is reserved for graphics data anyway.) Now you need to store the lo and hi bytes of the sprite and colors. I had a lot of trouble getting batari basic to work with it, so I resorted to ASM. LDA #0 LDY #<my_sprite JSR SetValue2 LDA #1 LDY #((>my_sprite) & $0f) | (((>my_sprite) / 2) & $70) JSR SetValue2 LDA #128 LDY #<my_sprite_color JSR SetValue2 LDA #129 LDY #((>my_sprite_color) & $0f) | (((>my_sprite_color) / 2) & $70) JSR SetValue2 What I'm doing is getting the address bytes and storing them in an unused portion of the cartridge. The SetValue2 sub routine I got directly from this forum where we were asking for ways to use the stack as a variables (can't remember the title of the thread.) You'll need that routine. It's only a few lines and indispensable. I store the sprite starting at 0 and the colors starting at 128. You don't have to do it this way. I have no idea why I didn't just put all 4 bytes consecutively, but whatever. At this point you have saved 4 bytes for your sprite. 2 for the graphics and 2 for the colors. To actually change our sprite, we need to get them back out and write them. sprite_lo = GetValue2(0) sprite_hi = GetValue2(1) sprite_color_lo = GetValue2(128) sprite_color_hi = GetValue2(129) LDX sprite_lo STX player0pointerlo LDA sprite_hi STA player0pointerhi LDX sprite_color_lo STX player0color LDA sprite_color_hi STA player0color+1 And that will set our player0 sprite to whatever we defined as our data. To change the sprite to something else, all you need to do is get the 4 bytes from whereever you put them, and write them again. Once you get one sprite working it's trivial to use others. What it isn't is fast.

Sorry, I meant 261 for the title screen and 262 for my game loop. Even stripping all my game code except the title screen loop still has it synced to 261. A completely blank project using unaltered titlescreen asm files syncs at 261 according to Stella. Here is the code I'm using (and using the download from the first post in this thread version 1.5) Pardon my comments. They're so I can easily see where a bank is on Sublime Text's preview pane. I stripped all my code except what is used to run the title screen. set kernel DPC+ set tv ntsc set smartbranching on set dpcspritemax 8 goto __Bank_2 bank2 bank 2 temp1=temp1 __Bank_2 __Reset titlepage gosub titledrawscreen bank6 goto titlepage GameStart ;BANK 3 ***************************************************************************************************************************************************** bank 3 temp1=temp1 ; BANK 4 ************************************************************************************************************************************************* bank 4 temp1=temp1 ;555 BANK5 55555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555 bank 5 temp1=temp1 ;6666 BANK 6 6666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666 bank 6 temp1=temp1 asm include "titlescreen/asm/titlescreen.asm" end

The title kernel is syncing at 241 scanlines. When I switch from the displaying the title screen, to the normal game routine, the game syncs at 242 (normal for DPC+, I think?) The change from 241 to 242 causes the screen to roll for a moment at the switch. Is there anything I can change to make the title kernel sync at 242 also? This will also help with PAL compatibility as it can't properly display an image with an odd number of scanlines.

How do I access the DPC+ voices from bB? I assume I can do it from inline assembly if nothing else. Do the DPC+ sounds greatly improve the sound possibilities?

That only changes the player0 sprite though. Consider an 8x8 sprite that is a skeleton. Now an 8x8 sprite that is a troll. Now let's say you want that to player1 to be a skeleton. Very straight forward. But now you want player1 to be a troll. You need to change the sprite data for player 1. You could stack the sprites, like you did in your example and that works. But wait... Now you need player2 to be a skeleton and player3 to be a skeleton. You need to re-use your skeleton data for multiple DPC+ players without duplicating it. The system I have set up defines the sprite once. Then it writes the data to whatever DPC+ player sprite that needs it. This allows me much more flexibility

Yes, that's what I was doing. I have a number of sprites. Each of them can be a monster character, but I didn't want player1 to always be the same monster. I wanted to be able to use one sprite in ROM for more than one player, but also change them. I ended up with a non-trivial way of doing this by calculating the addresses of the sprite data and storing them in the stack. When the game decided it wanted a particular monster, it would retrieve the LO and HI addresses from the stack and write the data. It works, but it's slow. I change monster sprites during screen transitions, so the slowness isn't a problem.

Okay, changed the window and size to the same value (instead of doubling the height). That keeps the image correct, but when I change the index, the colors look like random data. EDIT: Got it! Changed the window to half the size of the height. Changed the last lines in the kernel (the sprite data) to use half the height and comment out the lines you mentioned. Thanks!