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!  

On 11/3/2021 at 10:04 AM, drxandy said:

@TylerBarnes @Gamegearguyhappy birthday you two!! (Belated)

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 
 

2 hours ago, nesmaster14 said:

Cool stuff! Those landscapes are impressive and I really like the gradient on the desert one.

I don't consider myself a graphic artist, but I've always been drawn to pixel art, specifically making the most within limited resolution/palette/hardware. I remember now one of my blogs needed a favicon and had a limit of like 16x16. This is what I came up with like 6 years ago:

16x16 by nesmaster14 

 

It's not palette/hardware restricted pixel art of course, but I think even making pixel art in the modern sense (limiting resolution with more palette) has plenty of merit and craft to it. I enjoyed making it and feel inspired now to try it again.  Cheers!  

 

 

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

On 3/22/2021 at 5:04 PM, CasualCart said:

This is gorgeous, dude! Any pointers for someone who's interested in learning proper pixel-art someday?

-CasualCart

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/ 

2 hours ago, Khromak said:

 Reminds me of Ben Eater, whose videos I love.

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!
 

23 minutes ago, Gloves said:

Why are you guys speaking in code?

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 

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. 

34 minutes ago, Dr. Morbis said:

But some of those games have 4 channel sound and some are 8 channel.  Does that matter?

They only use those channels. the chip itself is capable of more. 

34 minutes ago, Dr. Morbis said:

does that mean I need two chips that will hold 128k each? 

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. 

 

34 minutes ago, Dr. Morbis said:

Or is Pac-Man CE one of those rare NES games that has different size chips for the prg and chr (unlikely)

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. 

; In bit pattern below, Bits we care for are shown with capital letters; lowercase we are trying to get rid of
; Known zeros will be written

CheckCollide:  ; when entering routine, X and Y pre loaded with xPos and yPos of checked point 
	TXA        ; %XXxxxxxx ; X/64
	LSR        ; %0XXxxxxx
	LSR        ; %00XXxxxx
	LSR        ; %000XXxxx
	LSR        ; %0000XXxx
	LSR        ; %00000XXx
	LSR        ; %000000XX
	STA tmp    ; %000000XX
	TYA        ; %YYYYYyyy ;(Y/8)
	LSR        ; %0YYYYYyy
	LSR        ; %00YYYYYy
	LSR        ; %000YYYYY
	ASL        ; %00YYYYY0 ;*4
	ASL        ; %0YYYYY00
	ADC tmp    ; %0YYYYYXX add both to complete X/64+(Y/8)*4
	TAY        ; Y is now Byte index into main 4x30 map
	
	TXA        ; %xxXXXxxx ;X/8
	LSR        ; %0xxXXXxx
	LSR        ; %00xxXXXx
	LSR        ; %000xxXXX
	AND #%0111 ; %00000XXX
	TAX        ; X is index into BitMask for bit pos within the byte 
	
	LDA CollisionRAM, y  ; Load the byte player is in from 4x30 map
	AND BitMask, x       ; compare the exact bit position with lookup table 
	RTS                  ; Zero is clear if collistion is true for later branch

BitMask: 
	.db %10000000
	.db %01000000
	.db %00100000
	.db %00010000
	.db %00001000
	.db %00000100
	.db %00000010
	.db %00000001

;In bit pattern below, Bits we care for are shown with capital letters; lowercase we are trying to get rid of
; Known zeros will be written

CheckCollide:        ; when entering routine, X and Y pre loaded with xPos and yPos of checked point
	TXA              ;%XXxxxxxx C=0 ;   
	ROL              ;%Xxxxxxx0 C=X
	ROL              ;%xxxxxx0X C=X
	ROL              ;%xxxxx0XX C=x
	AND #%00000011   ;%000000XX C=x
	STA tmp 

	TYA              ;%YYYYYyyy  ; (Y/8)*4
	ASR %11111000    ;%0YYYYY00  ;illegal opcode $4B (&& with byte and LSR) N,Z,C
	ADC tmp          ;%0YYYYYXX  add both to complete X/64+(Y/8)*4
	TAY              ; Y is now Byte index into main 4x30 map

	TXA              ;%xxXXXxxx  ; X/8 (Capital X are bits we care about) 
	LSR              ;%0xxXXXxx
	LSR              ;%00xxXXXx
	ASR %1110        ;%00000XXX
	TAX              ; X is index into BitMask for bit pos within the byte 
	
	LDA CollisionRAM, y  ; Load the byte player is in from 4x30 map
	AND BitMask, x       ; compare the exact bit position with lookup table 
	RTS                  ; Zero Flag is clear if collistion is true for later branch