TylerBarnes

Yeah, it is better to use the correct capacity PROM for the mapper you're using. However, it should also be noted that you can still use larger capacity chips in place of a smaller one, but you generally have to copy your data to fill out the whole chip. Generally you just do this in your batch file when compiling with the copy command and the /b argument to designate you are concatenating a binary file. You can do this like this directly in the command prompt, but in a build .bat is better. C:\folder>copy /b input_file.chr+input_file.chr output_file.chr

Did you checkout and learn from Vegaplay? If you haven't it is very useful to learn from on how to get some simple NSF's playing in assembly. I used it as my first introduction to the process, and since then it has been a solid foundation for music carts. Getting songs to play mostly boils down to bank switching (NFS without bank switching ar prefered), size, and dealing with sprite conflicts. If you need any advice or assistance let me know!

Thank you so much!!! I haven't been around much but I still love this place and all you folks!!

I wish I had more cross platform experience to lend a helping hand. I have no idea how PC engine works. A common method of changing text would be to look at a hex dump and see if any of their tiles were assigned to ascii values. You should be able to see plain text in the text interpreted side of a hex editor if that is the case.

Decided to completely fix the pumpkin one. Not sure why I though the dull flat look was ok before, lol. And slight contrast and color improvements to the wild west one.

Finished this one last night. Moonlit Sheep 34x34px

That looks really awesome! I really love the little canyon scene on the label. Only 4px wide!

I'm not as experience in px stuff as I would like. At least in the open ended sense that is very common these day (i.e not being limited by a given consoles capabilities). My background is from ad design, photo retouching/compositing, and things of that nature. You are a very equipped artist, so all the fundamentals you are already familiar with in your art experience will remain the same regardless of the resolution. So, no pillow shading and obvious stuff like that. there are some pixel specific things to think about though. There are multiple ways to shade or make gradients. Sometimes dithering is the answer, or sometimes a stepwise color/shade change is appropriate. So you would want to think about the texture you are trying to portray and make a determination on how to proceed shading. Also, it's easy to make things look too busy when the resolution is very low. I tend to try and think about what a given pixel is doing, what it's role is and if it is strictly required. This is a loose and fast rule however, Some of my examples above just have some smeary shading compared to a lot of pixel art I've seen, so again, it comes down to what you think is best. After doing the above pico resolution images, I have noticed that it certainly helps me actively think more about what particular pixels are most important and what is actually contributing to the image. So based on that I would definitely recommend getting your feet wet with some pico res images. They are quick to sketch up too, so getting to that rewarding feeling when the image comes together tends to come a lot quicker than if it was like a 250px or 500px piece. Try 32px on for size and see what comes of it. (or do what you like ) At any rate thank you so much for the feedback, I would love to see what you come up with, man. Always admired your work here. -Tyler TrebleWing

I noticed not much (or any) entries in the Pixel Art sub-thread. However, I feel it certainly has some potential to be a fun spot. Pixel art is rad, yo! I guess I'll share some of my entries in a series I'm working on in which I'm limiting myself to very very very low resolutions only. Like, 32x32px and below for the most part! City Skyline is 24x24px Sunset Trees is 25x25px Snow Scene is 32x32px Beach is 25x25px Pumpkins are 28x28px and Desert is 28x28px I hope you enjoy, and I hope y'all make threads and make this a great spot to admire each other's '8-bit artography'! I will be putting all the images that I make in this style on this instagram: https://www.instagram.com/picoartography/

I absolutely love Ben Eater. This means a lot to me, thank you!

I have recently issued myself a challenge to code a piece of software for the NES only using hardware that would have been available at the time. I have chosen the trusty Apple //e for this task. It will be my main dev machine, coding everything in Merlin, burning eproms straight out of the Apple with the Southern California Research Group PROmGRAMER card, and a bit of extra help from the STAG pp42 EPROM duplicator. I hope you enjoy watching the process from start to a finished 'Hello World' on the NES!

Looks like state abbreviations for Brazil.

Should there be the extra OR pipes at the end?

Did everyone with at least one bauble just receive a 'merch wearer' bauble that they did not earn? I sure did. lol. While the shirts look dope, I don't have one/

Hello all, Working on some demo coding ideas. Naturally some pseudo 3d was something I wanted to do. This was my inspiration for making this: https://www.youtube.com/watch?v=p4Iz0XJY-Qk This rom is early days but I'm happy to have gotten it this far. I'm doing some matrix rotation using signed sine tables and also utilizing the MMC5's multiplication registers. I'm still trying to figure out where I need to refactor to remove the jitter. This is either from rounding to early, or just the limitations from a 256 byte signed sin table. These are the transformations I am doing: My sin table uses $00 to represent 0, $FF to represent +1, and $80 for -1. If you are not familiar with matrix math this is a basic illustration of what is involved: http://matrixmultiplication.xyz/ In my code I basically do it in a very unrolled manner to help with execution speed. For an example of the method, lets take the first cos(theta) in the Z rotation. I need to perform x * cos(theta). I would do the following. LDX Theta ; load current angle (0-255) LDA cos, x ; Load precalculated cos value for that given angle BPL + ; check the sign JSR TwosComp ; convert negative to positive to get magnitude of number + STA $5205 ; store in MMC5 multiplication register LDA X ; Load starting X coordinate BPL + ; check sign JSR TwosComp ; convert from negative to get magnitude + STA $5206 ; Store in other MMC5 multiplication register LDA $5206 ; Take high byte of 16-bit multiplication result STA alpha ; save it in var for later addition LDA cos, x ; check if was negative BPL + LDA alpha JSR TwosComp ; Convert back if it was previously negative. STA alpha + LDA X ; same check as above BPL + ; if X started negative, LDA alpha JSR TwosComp ; we convert back to negative STA alpha + Then I do the same for Y * -sin(theta) , store that result in a var called 'beta' and at the end I add alpha + beta to complete the first row of the matrix and get the final X value. The process is repeated for the second row of the matrix to get the final Y value for that specific rotation.

Anyone thinking of buying in Unity? They just became publicly available. They look like they will be a good buy to get in early.

No idea which will actually be relevant or useful, but I'll list all the ones I can think of that could potentially be referring to video games related things. RNG - Random Number Generation (Equivalent to 'luck' in speedrunning) PPU - Picture Processing Unit (Nintendo Entertainment System) CPU - Central Processing Unit SID - Sound Interface Device (Commodore) VIC - Video Interface Chip (Commodore) C64 - Commodore 64 C128 - Commodore 128 TIA - Television Interface Adapter (Atari 2600) ROM - Read Only Memory RAM - Random Access Memory SRAM - Static Random Access Memory VRAM - Video Random Access Memory RGB - Red Green Blue KHz - Kilohertz MHz - Megahertz GHz - Gigahertz HEX - Hexadecimal NWC - Nintendo World Championships CRT - Cathode Ray Tube VGA - Video Graphics Array CGA - Color Graphics Adapter EGA - Enhanced Graphics Adapter BPP - Bits Per Pixel DIP - Dual In-line Package SMD - Surface Mount Device DIY - Do It Yourself IC - Integrated Circuit

View Advert NES Laser Invasion (any condition) Looking to get as many Laser Invasion carts as I can. Condition is not a huge issue to me. I'll still take dirty shells, torn labels, stickers, marker, etc. Let me know. Thanks Advertiser TylerBarnes Date 09/04/2020 Price Category WTB  

View Listing NES Laser Invasion (any condition) I am looking for as many Laser Invasion carts that I can get. Condition does not matter to me. While clean carts are still useful to me, I'm also more than fine with torn labels, marker, store stickers, etc. Please let me know if you have one or multiple you want to get rid of. Lister TylerBarnes Date 09/02/2020 Price Category Wanted

Neat bit of kit. I have never seen one of those before.

I prefer forums that do not allow deleting. Even people without ill intent can screw things up with continuity issues. the Chipmusic forums just use a graveyard section for spam, hateful threads, etc.

Ah very cool. Looks like a cool board you put together. I have not done a namco before; didn't know the intricacies between boards. Thanks for the info provided.

They only use those channels. the chip itself is capable of more. That depends entirely on how the rom uses PRG and CHR rom space. the mapper is capable of using 512K PRG and 256K CHR. The rom does not necessarily have to only allocate half/half to each. So when you split the rom with something like TNINES is should hopefully give you the two files separately to read their size and choose the right chips. Even if you choose a chip that is double the size, you can simply duplicate the data to fill the entire EPROM. a binary add in DOS will append the files together: COPY /B CHR.bin+CHR.bin Output_CHR.bin So if the CHR rom was 64K, but you only have 128K chips, you could do the above. A large amount of titles use different sized chips. NROM is a prime example, only having 32K PRG and 8K CHR.

Any cart that uses the Namco 163 audio features will, by default, use the same NES mapper. This means finding donors will be the easy part. Lookup the cartridge list of that audio expansion chip here: https://wiki.nesdev.com/w/index.php/List_of_games_with_expansion_audio#Namco_163 Then buy the cheapest release on the list. ------------------------- Whether you want to choose EEPROM chips or UV EPROM chips is up to you, but just know that their pinouts are not the same and this will dictate how you rewire. I personally prefer EPROMS since I'm more used to their pinouts compared to NES Mask Rom pinouts. ------------------------- Rewiring will likely be the hardest part. You want to use a multimeter with a continuity mode to test whether two points are connected (emitting a beep when they are). Use the pinout of your PROM and the pinout of the Namco chip as your map. Match all the address pins (A0, A1, A2, A3....) and the data pins (D0, D1, D2, D3....). Namco Pinout here: https://wiki.nesdev.com/w/index.php/Namcot_163_family_pinout If you don't see some of them on the namco pinout, it is because they connect directly to the NES via the cart edge connector. Pinout here: https://wiki.nesdev.com/w/index.php/Cartridge_connector ------------------------- For the large majority of NES games, the maskrom chips use a common pinout: https://wiki.nesdev.com/w/index.php/Mask_ROM_pinout They are very close to comercial EPROM pinouts but not 100% the same. Many times it is just a matter of rewring the few pins that differ between the maskrom vs the EPROM I personally have no idea if Namco games follow those maskrom pinouts. If you beep out a couple of the pins with the namco chip to compare, you could likely narrow it down.

Found a cool optimization today. My first venture in successfully exploiting an illegal opcode. Used ASR ($4B). I know it's not too terribly exotic, but fun nonetheless. It uses the immediate addressing mode, ASR #imm The instruction will AND the immediate byte with A, and then shifts A one bit over. It affects N, Z, and C but they are not relevant in the way I used it. To start it would help to know what code I started with and what it was doing. It is a part of my collision detection routine for a 4x30 bytemap. (1 bit per tile). To index into this and compare the bit position, you would use X/64+(Y/8)*4 to grab the relevant byte from the 1D array, and then use X/8 AND %0111 as an index into a table checking for the exact bit position of the selected byte. There is a section in this calculation that is dealing with the (Y/8)*4 that works out particularly well with the ASR opcode to optimize. ; Lets assume we have calcluated X/64, and already put it in a variable called 'tmp'. ; Also, I am showing bits I care about in green, to follow their movement ; Known zeros are written ;-------------------------------------------- [X/64 calculation here] STA tmp ; X/64 in tmp TYA ; %yyyyyyyy ; (Y/8) LSR ; %0yyyyyyy LSR ; %00yyyyyy LSR ; %000yyyyy ASL ; %00yyyyy0 ; *4 ASL ; %0yyyyy00 ADC tmp ; add both to complete X/64+(Y/8)*4 TAY ; Y is now Byte index into main 4x30 map ;-------------------------------------------- In effect, I noticed that what we are ultimately left with is the 5 bits we care about having been shifted to the right once, and afterwards, bits 0 and 1 need to be ignored. Turning this %yyyyyyyy into this %0yyyyy00. So a quicker way to do this would be: TYA ; %yyyyyyyy ; (Y/8)*4 AND %11111000 ; %yyyyy000 LSR ; %0yyyyy00 However, ASR happened to conveniently do both of these for me at once. It ANDs A with the immediate byte and then shifts right once. TYA ; %yyyyyyyy ; (Y/8)*4 ASR %1111100 ; %0yyyyy00 ;---------------------------------------------- For those interested I'm including the full routine here for context.