Lillapojkenpåön

The hacks were extremely hard to vote on as I had not played the original games and had no Idea what was added, In the end I voted for the prettiest graphics, even tho that might have been the original graphics and something else was added? I would like to add that the fact that packaging had more votes than the other categories was brought up when you could still vote and could easily correct it by casting votes from the fake accounts to the other categories to, that should have been kept secret until voting was closed as you could just switch to voting from different devices or change your IP after that, the fact that only one AA member has come forward and said they voted on it in all these threads about it doesn't seem right.

To me there's no difference in creating a bunch of accounts and vote for yourself, or ask friends to do it for you, both require you to not care at all about the community or want to reward those that deserve it, I didn't even vote for my own game when it was nominated, I can prove it by the fact that it got zero votes 😄 as it should.

I hadn't even seen that thread and was starting to doubt my judgement, but I was right. wizard of wor, galagon and aardvark was the ones I had trouble choosing between as they are clean, beautiful, awesome, fresh and original yet fits perfectly to a 2600 game. I will give it clean just to be nice, but the other descriptions don't match.

I think something should be done when the result of the voting is blatantly ludicrous, like instant disqualification.

I can't wait for SpiceC!!!!!!!!!🤤 An improved kernel for bB could just be a hack of the DPC+ kernel, 9 virtual player0 sprites for example, using the exact same code as for the nine player1's, if there isn't something keeping the kernel to only be in one bank? and maybe one could change the six playfield reads and playfield color to some other updates more like the slick kernel? here's some more source material

They are still as much in the mainloop as Darrell's example, you're just visually jumping to somewhere else which doesn't optimize but rather adds unnecessary jumps, if you mean the sprite that you moved to the init, it does nothing in your code other than set the playerheight to eight, it points to a sprite and color but is immediately overridden on the first frame when the pointers are set to something else in NOTFIRE. Darrell had it in the mainloop because it was the stand still sprite, so just a easy way to reset to that one when no joystick direction is pressed. You can set the high pointers in the init tho if you merge the graphics and colors You were never pointing to RAM only ROM, and you're not bankswitching when seting the pointers in one bank to a table in another, you're just storing a number to a variable so the speed is the same. You also weren't using the last code Darrell posted, that let's you put the graphics in any bank without changing any numbers. graphics_data_test2.bas

I tried to point the colors to RAM awhile ago like this asm lda #<STACKbegin sta player0color lda #(>STACKbegin) & $0F sta player0color+1 end so I could just push colors to the stack but in main the flashdata adress I guess keeps you from pointing anywhere else, do you know if it would be possible to change that line to allow or just exclusively be able to point to first of all RIOT RAM since it's fast to read and write to, or the stack or worst case copy from the not visable part of the color queue up to the visable part? flashdata+(RIOT[player0color+1]<<8)+RIOT[player0color], //source queue+(fetcheraddr[46]<<8)+fetcheraddr[38], //destination

Or does it just get the first four bits (page?) of the adress and then add bank number?

I was just scanning the entire site looking for what the usual ((>WALK) & $0f) | (((>WALK) / 2) & $70) does, I guess it just points to the graphics bank? does dasm allways assume it's in the first bank or why do you have to add this manually? Could you walk me through what the & $0f does so I can learn something today? 🙂 Does it just turn of half the byte to make sure it's 0000 before adding the bank number????

Nope, I tried to do it like it's done in the standard kernel, but with reveng's latest bugfixed dpc+ distribution, if I would need to do it now I would try to put a gosub to another bank in bB vblank gosub _vblank bank5 and comment the vblank assembly in the kernel and put it in bank5 as inline assembly to get all the letters to fit in bank 1, but maybe there's more that needs to be done?

I just remembered that I tried to add the extra letters in a dpc+ project a couple years ago, but the score graphics ends up in bank 1, that only has a couple bytes free, so I could only fit one letter 😁 maybe it has shrunk by now but I don't think so.

I also had trouble with the score editor, so I just changed it in notepad.

Awesome! Nope The c code copies from flashdata to ram for player 0 colors it sends pointers to these adresses to my_memcpy flashdata+(RIOT[player0color+1]<<8)+RIOT[player0color], //source queue+(fetcheraddr[46]<<8)+fetcheraddr[38], //destination If I understood the adresses a little better and what the bit shifting does I could get it to copy from queue to queue if that's possibe, but I don't.

How does that work? are those times specific to that exact code, I mean is it adjusted for any c code or 6507 cycles? Or what exactly do I need to be aware of to not change to make sure It keeps working?

Sokoboo isn't in the best wip category? just checking if that's correct since I found it weird, and the rom is in the wip archive.

Now that I'm starting to get how DPC+ and CDFJ works I thought of a thing, if you have both player 0 and player 1 virtual sprites, and two player 1's get to close, couldn't you put one in player 0's buffer (if that position is free) and position in that stream? A fluid system where the buffers and GRP0 and GRP1 are used to draw as much as possible before flickering? That is probably what everybody is doing allready now that I think of it 😁

Wasn't there talk about implementing detection in Stella as well, by looking for strings in the filename like NTSC, SECAM, PAL60 etc. I hope that's still on some to do list somewhere because that was a great idea. I allways wondered how you did this, very cool! Why aren't we converting the players to?

If anybody else with windows has postponed trying this, I found a very simple way to compile download latest win32.exe from here https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads install download latest Compressed 32-bit executable for Windows https://dasm-assembler.github.io/ download one of the cdfj collect sources unzip and copy dasm.exe to that folder (to keep it simple) add an environment variable arm-none-eabi C:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin open the Makefile with notepad and change this part #TOOLCHAIN=arm-none-eabi TOOLCHAIN=arm-eabi to this TOOLCHAIN=arm-none-eabi #TOOLCHAIN=arm-eabi and save. that was it I think, I had to use mingw32 for the make command.

So if I understand correctly, somewhere in the C code all virtual sprites colors that will appear on the current frame gets copied and placed on this page according to the virtual sprites Y position <P1COLOR (>P1COLOR) & $0F and graphics merged to <P1GFX (>P1GFX) & $0F That makes sense. I understand that it's to late to change it by then, but before that we can obviously change it, we change graphics and colors all the time in bB, that's what I want to point to ram. Instead of changing colors by pointing to different tables like bB does it lda #<(playerpointers+18) sta DF0LOW lda #(>(playerpointers+18)) & $0F sta DF0HI LDX #<playercolorL0138_1 ;these colors will later be copied to the que STX DF0WRITE LDA #((>playercolorL0138_1) & $0f) | (((>playercolorL0138_1) / 2) & $70) STA DF0WRITE Have it point to dpc+ ram like the stack, since I don't think the arm can access the riot ram? Like this lda #<(playerpointers+18) sta DF0LOW lda #(>(playerpointers+18)) & $0F sta DF0HI LDX #<STACKbegin STX DF0WRITE LDA #(>STACKbegin) & $0F STA DF0WRITE then pushing colors to the stack would be easy.

Hmm, how are the pointers limited to only point to ROM? I guess that's the problem since the player allways has random colors or is completely yellow no matter where I point, I think any adress you put in turns into a rom adress somewhere in the kernel, otherwise it would have been all black at some point with all the adresses I've tried, I think. This defenitely pushes random numbers to the stack $0c when pushing fire but I can't get it to read from there, anyone is welcome to try ram_color2.bas EDIT: I looked in the kernel and color fetchers gets set to <P1COLOR (>P1COLOR) & $0F and graphics to <P1GFX (>P1GFX) & $0F Those adresses are defined in the DPCplusbB header, Isn't it RAM? C_function = FETCHER_BEGIN CcodeData = C_function + 4 playerpointers = CcodeData + RAMcopylength P1GFX = playerpointers + 38 P1COLOR = P1GFX + 256

Can someone explain why you can't change the player colors btw? Do they not get copied to the dpc+ ram? You seem to be able to read and write anywhere in the ram, I just don't know where the colors end up? And why is this needed when pointing to the color? what does it do? | (((>color) / 2) & $70)

DF0LOW = BKCOLSLOW + z DF0HI = BKCOLSHI variable = DF0DATA

Yes you can, this example reads when pushing left and writes when pushing right READ_PLAYFIELD_COLOR.bas

Can someone help me make an empty custom kernel template? something like this.. BAS includesfile custom_kernel.inc mainloop drawscreen goto mainloop INC custom_kernel.asm ASM https://atariage.com/forums/applications/core/interface/file/attachment.php?id=347153

That's perfect, even better without the gosubs, nice! 👍