Hi all, im new to the fun 6502 community, and glad to be apart of it. I am making a nes emulator, but came across a problem. I was wondering how exaclty do i read the assembled file produced by the nes assembler. I opened the assembled file in notepad and got this:

NES


Colour bars display program v1.1 14-Nov-97 © 1997 by Mark Knibbs <mark_k@iname.com>Øx­ û¢ Ž Ž
Êš „
„ © ‘ ˆÐûÆ
÷ ŒÀ ÒÀ©€

Did you try the email address?

Bit OT: I read that the Gameboy had a Z80 clone on board. I also know there is a cartridge that enable you to play Gameboy games on a NES. Thus IMHO the NES has this Z80 clone as well.
In fact I just found this: http://hitmen.c02.at/files/releases/gbc ... 0_6502.txt

The SNES has a 65816 on board, I'm sure of that.

_________________

Continuing the OT: I think it was the SNES that had the gameboy cartridge adapter not the original NES. The GB processor was inside the cartridge and communicated with the SNES through its video signals.

The Gameboy Advance also contains a Gameboy Color processor in addition to it ARM7TMDI. Theres a tiny little switch in the cartridge slot that decides which processor is enabled. The Game Cube has a plug in module that goes underneath it that also contains its own ARM processor.

The GB/GBC processor is closer to an 8080 than a Z80. It only has one set of registers (AF,BC,DE,HL) no shadow registers or index registers. Each cartiridge contains a memory controller which maps addresses to banked ROM/RAM chips.

Its fun to program but very underpowered. All the critical screen update code must be run during a very small refresh period or it corrupts the display signals.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'm not familiar with the NES assembler, but I would not expect actual code (as opposed to the display strings) in a .obj file to show as text that you could read with a text editor. For example, the LDA# op code, $A9, is not a text character. Even in ANSI characters, it looks like the top-left corner of a box. If you have a programmer's text editor like MultiEdit, there should be a hex mode though, which, on the left side of the screen, shows the pairs of hex digits to interpret even the unreadable characters, and on the right side of the screen, lines of what you showed, which won't be readable except when there's a string in the code like your first line has.

There should also be a .lst file output which is basically your source text file with the macros expanded out, and to the left of each line, the addresses and exact bytes (in readable hex-digits, 0-F) that the assembler lays down for that line of source code.

If you make the assembler produce something like an Intel hex or Motorola S19 file which an EPROM programmer would use, that is all readable text of the assembled code (with no source code showing), although lacking spaces between pairs of digits, and having the housekeeping bytes at the beginning and ends of the lines for telling the EPROM programmer what the beginning address of each line is and for error-checking. Intel Hex looks like:

The colon signals the beginning of a new line, the 10 means there are ten data bytes in the line, the 8000 (8010 in the second line) is the line's starting address in the target computer's memory (in this case, our ROM started at $8000), then 00 means it's actual data to put in the ROM, and then you'll recognize LDA#$60, STA$4000, LDA#$FF etc.. The E8 at the end of the first line and 6E at the end of the second are checksum bytes.

Hey thnkx for you tips garth, but my nes assembler does not produce any listing files. And correct me if im wrong, but isn't the emulator suppose to read in the binaries directly, it seems i am a bit confused when it comes to understanding binary files.

I'm sure it is; but that won't be human-readable-- at least not with a plain text editor. Assemblers usually give you more than one kind of file when they're done running. The .lst text file is the best for seeing what the assembler did with your source code, especially if you want to look at areas of conditional assembly or seeing the final addresses assigned to variables and labels for example.

Gameboy is a Z80 type CPU with every last remnant of extended addressing removed.

_________________
"My biggest dream in life? Building black plywood Habitrails"