TylerBarnes

Relevant to the discussion. While possible quite a bit would have to be added into the original source code to get the games looking like native GBC games.

Now that looks sweet as hell. Had no idea this was a thing.

While going through and deleting unused and unlisted videos on my channel, came across a fun YM2413 psytrance track I never finished for Sega Master System. Not cool enough to go back to, but cool enough to share, haha. XPMCK used to create.

I wrote my own encoder in 6502 assembly. It is an NES rom that take a single screen .nam file and stores the encoded hex in RAM. I unfortunately don't know any other programming languages.

You are 100% right. UserTable EQU $00 Gloves = $00 TylerBarnes = $01 Vectrex28 = $02 applyBauble: LDX #$01 LDA Bauble STA UserTable, x INX STA UserTable, x RTS

This was on purpose. Gloves is not a home brewer but a recognizable user to fill the table.

There was a homebrewer award? I want a piece of that cake! applyBauble: LDX #$01 LDA Bauble STA Users, x INX STA Users, x RTS Users: .db Gloves,TylerBarnes,Vectrex28

This is a very real bug, but only applies in games where the player is hitting buttons constantly and their inputs need to be honored 100% of the time. For a simple NSF player and song selector it is no trouble at all. DCPM samples are welcome.

While looking at Mario's source code. Loos like this BIT skip is used throughout to hop over various sections when you only want to load a different value in A but the rest of the subroutine is all the same.

The above mentioned and also GameHut, Retro Game Mechanics Explained, 8-Bit Show and Tell, The 8-Bit guy, etc

GTROM is pretty much the decided mapper. Cost and space make it a no brainer. Samples are now allowed, and file sizes can be up to 24KB. Not sure if I can allow more. We will have to see how much the player code ends up taking. Also. as long as your NSF format does not do crazy things to RAM, we can make songs work that were made on other platforms (ppMCK, FamiStudio, etc) Ultimately, it is VERY early on to really say for sure.

This is very true. Also many people may not want to muck around with opening up the chassis and installing internal parts (a very easy installation in this case).

I bought a refurb Lenovo T440 with i7 for about $250-$300. This was my choice since it has dual battery. Refurbed units will obviously have a shit battery so you just buy the Lenovo 6cell 68+ for the external battery and buy the 45N1109 as the optional internal. I get about 14 hours of coding on it. Even with just the 68+ its about 9 hours. EDIT: Just reread and saw the stress on NEW. Sorry.

This depends on your platform. Atari carts average 4KB-8KB for ROM. Every byte can matter.

So in the spirit of learning new things, what is your favorite 6502 trick? My question stems from very recently coming across a simple, albeit limited, trick that just seemed to strike a chord with me and made me go 'wow'. The trick I am talking about is using the BIT opcode in place of a JMP $xxxx that only skips 2 bytes. Consider the following code in which I want to check a state, and conditionally jump to one of two choices, and store it in a destination. LDA State CMP #$01 BEQ LabelTwo LabelOne: LDA ChoiceA JMP Jump LabelTwo: LDA ChoiceB Jump: STA Destination The 'JMP Jump' part of the code will occupy 3 bytes total. 1 for the opcode, and 2 for the address. We can instead replace these three bytes with the single byte of the BIT opcode ($2C) and this effectively skips the 'LDA ChoiceB' altogether while keeping the accumulator and carry flag preserved. LDA State CMP #$01 BEQ LabelTwo LabelOne: LDA ChoiceA .db $2C LabelTwo: LDA ChoiceB ; If ChoiceA, These are read as an address to BIT Jump: STA Destination What happens is when the CPU reads the BIT opcode, the next two bytes it is expecting are the lo byte of an address, and then the high byte of an address. So it reads $A9 from the LDA opcode as the low byte. Then the value byte that is assigned to ChoiceB as the high byte. It then does the rest of the stuff associated with the BIT instruction (non-destructively compares the accumulator to set flags). By the time it has finished the BIT it is ready to 'STA Destination' the value in the accumulator. This is not faster mind you. It is 1 cycle slower. But saves two bytes. Not very broad in application, but very cool imo. The machine code for those interested. ; Lets assume the assembler assigned 'Jump' the address of $1234 ; Also assume 'Destination' is RAM location $00 on zero page ; Lastly assume we have loaded LDA ChoiceA and we are performing the JMP Jump / Bit trick ;___Disassembly____ ; Version 1 $A9,$00 ; LDA #$00 ; LDA ChoiceA $4C,$34,$12 ; JMP $1234 ; JMP Jump $A9,$01 ; LDA #$01 ; LDA ChoiceB $85,$00 ; STA $00 ; STA Destination ;Version 2: $A9,$00 ; LDA #$00 ; LDA ChoiceA $2C,$A9,$01 ; BIT $01A9 ; BIT $01A9 $85,$00 ; STA $00 ; STA Destination

Added Episodes 18 and 19 Player graphics and walking cycle

Coming in late to this thread haven't really read from the start. My thoughts on the main topic. I definitely see both sides. If I could briefly compare it to modern game dev on PC, there are some pretty amazing tools that make things easy and give you an engine to actually play with straight away. I will say, Unity for example, since it is very popular. Many individuals, and teams have used this tool to great effect and produced some great games. The player of these games does not necessarily care whether the dev used advanced tools that gave them more premade code/structure in comparison to another dev that built their own framework and engine. The gamer, for the most part, wants to play a great game. I think it's the same on NES. The feeling of accomplishment and pride the dev should be feeling first and foremost is seeing there game idea/story/implementation/character/etc be well received by people that have played it. This is the usually a pretty universal goal of making any interactive piece of software like a game. However, this is not said to equate the two accomplishments (using tools vs from scratch). They are in different leagues for sure, and it takes a great deal more effort/talent/patience/dedication/time/etc to do it all from the ground up, but if your game is great, I think you should feel proud regardless of the tools you used. I'm not sure if I have made up my mind if I feel one should be forced to put an asterisk on their project and declare it as tool assisted. Right now I'm inclined to say it ultimately doesn't matter. I feel that the more people are interested in seeing the NES as a viable console to make/play new games on, it will create a bigger market for sharing your own custom creations with a wider audience. An audience that is also trying to participate.

Not sure if really the same but putting this here regardless. Scrobins came through in the clutch with an assist on informing me when a limited cart I was after became available. We briefly discussed the cart in another thread and I expressed I really wanted to find one. Then today, BAM, I get a DM with a link to an auction/buy now. Thank you for the bro assist! This is why this community is awesome.

Yeah no prob!

I get them printed. CustomStickerMakers is decent and fast. about $0.70 a label.

Also side note, I am recruiting a solid chip artist I feel would be perfect to join the squad. Cris AKA 'Viridian クリス' I have invited them to join the forum/discussion

Yes please do. I guess step one is just get famitone playing one song. Having a song will help with that.

This exact thing happened to me. I was so annoyed.

Episodes 16 and 17 added ^_^