WDC offers free C Compiler/Optimizer and more

Realizing this may not be generally known and that it shouldn't be hidden on the 3rd page of the 2nd "nesdev designs" thread:

Western Design Center offers a C compiler/optimizer and ASM assembler/linker, among other tools, for free (except for commercial use on non- WDC/WDC licensed processors). I should probably also repeat their statement that the toolchain isn't for reverse-engineering their products even though that kind of goes without saying, since that's their subsistence.

http://www.westerndesigncenter.com/wdc/tools.cfm

You need to register as a user in order to download the full version, but that's it. Should be neat for anything (w)65C02 / 65C816 related.

Link to "that thread": viewtopic.php?p=199814#p199814.

Does Ricoh 5A22 use WDC IP? I wonder if it qualifies for commercial development.

Great stuff, thanks for sharing!

Looking forward to reports on how well it performs.

EDIT: Am I dense, or how are the tools actually downloaded..?

The link from the OP goes to a page with two links under WDC tools.

The first "You can register and download at WDC65xx.com." http://65xx.com/65xxcelr8r-overview/download/ gives a 404.

And the button "register and download today" is a good link http://wdc65xx.com/wdctools-download-2/ but only gives the warning about downloading the tools, and then a link to a contact form if seeking commercial license.

No where on any of these sites could I find a place to register.. Maybe it's just down temporarily? Tried a couple different browsers with same results..

EDIT 2: Went ahead and filled out the contact us form explaining my confusion for lack of better options. Promptly contacted by support team and provided link to actual registration page: http://wdc65xx.com/WDCTools Which once filed out sends you an email back to the "download-2" page which ends up getting properly populated with a "click for free download" button which worked no problem.

The NES's cpu is not WDC licensed I believe, and most people here are doing commercial development anyhow. Plus those are Windows-only.

Compiling lists of "Notable Applications" from wiki:

65C02
Home computers

-Apple IIc portable by Apple Computer (NCR 1.023 MHz)
-Apple IIe by Apple Computer (1.023 MHz)
-BBC Master home/educational computer, by Acorn Computers Ltd (2 MHz 65SC12 plus optional 4 MHz 65C102 second processor)
-Replica 1 by Briel Computers, a replica of the Apple I hobbyist computer (1 MHz)
-Laser 128 series clones of Apple II
-KIM-1 Modern Replica of the MOS/CBM KIM-1 by Briel Computing

Video game consoles

-Atari Lynx handheld (65SC02 @ ~4 MHz)
-NEC PC Engine aka TurboGrafx-16 (HuC6280 @ 7.16 MHz)
-GameKing handhelds (6 MHz) by Timetop
-Watara Supervision handhelds (65SC02 @ 4 MHz)

Other products

-TurboMaster accelerator cartridge for the Commodore 64 home computer (65C02 @ 4.09 MHz)
-Many dedicated chess computers i.e.: Mephisto MMV, Novag Super Constellation, Fidelity Elite and many more (4–20 MHz)

65C816

Acorn Communicator
Apple IIGS (edit: platinum edition only)
C-One Reconfigurable Computer (standard CPU/RAM card)
Super Nintendo Entertainment System (the console's Ricoh 5A22 CPU is based on the 65C816)
Nintendo SA-1 (a co-processor chip used in several SNES game cartridges; based on the 65C816)

Beside those, they're still used in industrial and medical applications. There's also a handful of obscure "build your own computer" kits and pcb designs.

Of course, this doesn't answer if Ricoh (or Hudson) had a license. Would they get away with doing the modification trick more than once (the 6502)?

Hmmm. Isn't only the Enhanced IIe (the one that could display those funny mousetext characters and I think it existed as an upgrade kit and also released alone) using 65C02? The non-enhanced IIe clones I had been using (which were supposed to be 100% identical to the real ones) only used the original 6502.

The Apple IIc, enhanced Apple IIe, and platinum Apple IIe use the 65C02.

The Super NES was manufactured at the start of the era of exclusive rights in "mask works," so I consider it far more likely to have been duly licensed.

Hm. In that case, wikipedia must be slightly wrong (or at least not very precise), as is often the case. I guess that'd make it fall into the same category as the listed BBC computer.

While I had the attention of the WDC rep I decided to ask if the 6502 in the NES/famicom was considered a WDC core and they said yes. So if there's a reasonable way to get around the fact the tools to don't support the 6502, WDC doesn't see the NES/famicom as requiring license for commercial projects.

Nice! I happened to send a question on the Hudson and SNES derivates earlier, so they might be wondering what the commotion is right now

Yeah, that's a tough one. Even if one'd manage to disable the compiler/optimizer using non-present opcodes, addressing modes and decimal mode, it probably wouldn't be too optimal anymore.

The 6502 pre-dates WDC and hence is a MOS/CSG design.

The 2A03 is a pirate illegal chip but based on the MOS/CSG design.

There is a
WDC 65C02
Ricoh 65C02
which have different instructions

CSG 65CE02
CSG 8502
CSG 4502

HuC6280 seems to be Ricoh 65C02 based

Sounds like useful for the SNES, but for the NES not so much as it doesn't seem the tools supports the NMOS 6502.

At least the assembler can still be used for NES, it has a 6502 argument for the CHIP directive. No HuC6280 support though, not that I expected it...

There's a brief mention of Nintendo development, the Intelligent Systems ISX format and SNES mapping modes in the assembler manual.

I guess now we finally have a 65x assembler that can do proper zero/direct page stuff, like moving the runtime direct page location and force absolute or long addressing in page 0.

well this is the 2.0 version of wdc tools:
http://www.mediafire.com/file/pqvz1i9t8 ... ls+2.0.zip
and an example someone had made a long time ago, this example can be compiled and linked with wdc tools, it's a SNES game:
http://www.mediafire.com/file/9bf0nt91m ... ngfu_1.zip
I do not know how to use the simulator that comes with the tools, I do not understand much the programming of the snes, but there are a couple of manuals out there

Not a game, it just displays a static image. But still, it's nice to see a "hello world" example for the WDC compiler.

Yes, you're right, it's an image, just load the pixels in the vram, I'd like to be able to implement multithreading, if I do not have the libraries for the snes hardware, maybe I can make calls to the OS kernel from the emulator, another possibility is to program the libraries in assembler, knowing what parts of the snes hardware do everything, just like knowing 65816 opcodes,something else, maybe reverse engineering to know which opcodes deal with the joystick interrupts in an emulator, they should be called from i / o to the OS kernel, for example: windows (being simulated) made by the emulator

There are no threads. There is no OS. There is no kernel. There is no "joystick interrupt". Welcome to working on actual bare metal. From this paragraph, it's fairly obvious you need to start by learning about general CPU architecture and assembly language (65xxx is fine, but the concept applies universally to any CISC-based CPU).

charly400: filling in what koitsu said - It's not too bad (actually rather half the charm) to be working with no layers of abstraction. Everything is under your direct control. Also, the lack of an OS is actually part of what made consoles have a bit of an edge over personal computers once. Access to the zero page is all yours and there's no background process. At some point access to the zero page (which takes less time to access than the rest of ram) stopped being interesting for application developers since computing got fast enough. I’m trailing off here...

You're right, I have to learn assembly language first, work directly on the hardware is a bit away from my current knowledge, as for WDC tools, I can not link the wdc libraries to any source code in c, although I have the environment variables of the LIB and BIN directories, when I try to link all files I have a lot of undefined references to functions, for example stdio.h is included in a .c file, then I link the file c with all the libraries because I do not know where it is defined printf, and in spite of everything I still get a link error, it seems as if there is no support for the 65816, I know that there is no support for the processor of snes, but there is no support for the WDC, you have to define all the symbols in assembly so that functions can be called




Certainly that there is no kernel in the SNES, it is like programming in real mode flat model, but accessing 16 mb of memory, maybe doing reverse engineering on an emulator, on the accesses to the smc image and see what it would be a way of seeing On the screen that each subroutine does, it is certainly a bit of processor programming, but I am surprised by the lack of WDC support for its own processor

CPU is one thing, but you have all the non CPU bits like the sound and video side and compiler is completely oblivious to those. You'd have to write your own stdio and other libraries to get going (which is essentially what everyone has to do to anyway when they start doing retro game dev).

What character driver back end does WDC's printf expect? Perhaps I might be able to spin up a terminal emulator in 65816 assembly language to whatever spec it needs, much as I did a few years ago for NES and devkitPro did for libgba, libnds, etc.

That is why it is not easy to compile the codes, the cpu carries a code, the code communicates with the memory, and with i / o, there must be libraries to operate the devices, recently I was using gcc with environment variables and links without problems, I had never used gcc with the command line, always from an IDE, but code and libraries in an intel 386, not 65816, I do not understand what happens with wdc and the libraries, it would seem that the symbols were not recognized, the fact that is an un-customized snes processor and this gives it a confidentiality value, I honestly do not understand it



You can`t use an emulator if the code does not link, the symbol that represents printf is not found by the linker, you would have to write in assembler the stdout calls of 65816, I do not know much about the processor, but the programming books says it clearly, surely you have to check what routines are associated with the pixelation of the Vram, you also have to see with some debugger if the emulator interprets the drivers of the 65816, maybe it ignores them, and fills the screen with pixels directly, because they are virtual drivers, but real driver routines in ROMs
Tepples, you say what character the driver returns, as a punctual read / write value?

The way it's supposed to happen, as I understand it, is that a hosted implementation of the C language comes with a C standard library implementation whose printf calls fputc(codeunit, stdout); or fputs(stdout, codeunits); or fwrite(codeunits, 1, num_codeunits, stdout);. It expects the underlying operating system to provide fputc and fputs, or fwrite. If you're at that stage, then sprintf will work as advertised, and printf and fprintf will link, but you get a linker error at fputs, fputc, or fwrite. I'd write the fputc, fputs, or fwrite.

If printf itself fails to link, then you probably have only a freestanding implementation of the C language, and you'll need to provide the vast majority of the C library, including printf. For this you can adapt Newlib or cc65 libc or whatever.

@charly400
Are you using machine translation? Is your native language something other than English?

Yes, I am using the Google translator, I am Spanish, I speak only a little bit of English realy, and the translator helps me, that is why some sentences seem to be tarzan, with respect to what you say, I understand how the functions invoke others, a part of your link says: Note that gcc for instance will, if compiled for a hosted environment (-fhosted), assume functions used in the standard library have the corresponding meaning and might apply very aggressive optimizations (it has many of those built-in functions). For freestanding, it actually does not, so you can use a function strcmp for instance with completely different semantics. However, it assumes the mem ...- functions to exist, as these are used for normal code, e.g. struct assignment. that is not happening with WDC, I think you are right in what you say because the same linker is able to add libraries with their parameters, in WdC it is possible that the command line are missing link parameters, don`t know what link parameters are the libraries with the command line, in DEV C says linker - parameters, for example, when you install winbgim, a windows style graphical interface, it happens that the linker uses special parameters to access library functions that have nothing to do with the linker or the compiler that I use, Maybe it's something like that
Maybe buying WDC tools,
the complete package is purchased

Tepples, what you told me about the invocations of functions, has to do with that, when I received the indefinite references to functions, they were indefinite references within libraries, not inside headers, for example "undefined symbol _printf" as an error message, where _printf is invoked in the library, the problem is that _printf calls write, but write is not defined in the machine code of 65816, when libraries call kernel functions, those definitions reside in the kernel, but there is no kernel

In that case, I would write write() in 65816, just as I have done in 6502.

totally agree, that way it is possible to make programs in c, the ORCA / C compiler for apple 2 allows to make programs that fit apple memory system and it/s peripherals, the way to compile for the snes memory system is not equal but similar, plus other devices

I don't know about the possibility of using ORCA/C to compile games for the SNES. ORCA/C is heavily reliant upon many aspects of the Apple IIGS and/or GS/OS or the built-in ROM (for bare-bones things); GS/OS actually provides you an entire OS and API for such things, including memory management; there is no malloc on the SNES! For ANY this to work on the SNES -- and I think someone else already covered this -- you would have to write your own crt library that did equivalent things on the SNES to what was done on the IIGS. Any common libc functions you're used to? Throw them out -- they probably won't be very helpful on the SNES, and you'd have to dedicate a portion of CHR to a font. Possible? Yes. Useful? Maybe? Sort of? Probably not given that today we have tolerable emulators with debuggers. But that's just my view.

The IIGS and the SNES are MASSIVELY different in every single way except the CPU (I'm an old Apple IIGS programmer, and I do/did SNES stuff as well, so I'm not out of my element talking about this -- in fact, the reason I got into doing SNES programming and doing my documentation was because I found out the SNES had a 65816 in it). For one, the SNES is a tile-based system, not pixel-based like the IIGS. Also unlike the IIGS there is no "text mode" or direct/native way to get text onto the screen (IIGS, much like the II/II+/IIC/IIE, has a stock ROM that provides a lot of this). These are one of many reasons why you didn't see games being ported from the IIGS to the SNES or vice-versa -- the systems are just way too different, especially graphically. And FYI: graphically, hands down the SNES is the more powerful of the two -- IIGS graphics are clever/neat but very limited (single background, limited palette, limited memory and access model, and things like having a 16-colour-per-horizontal-line limitation that cannot be overcome in any fashion (the "3200 colour" mode people talk about on the IIGS takes up something like 90% CPU time and involves very quickly swapping palette contents while the screen is drawn, i.e. during HBlank)), because they were designed by Woz with very real limitations of system resources (memory and budget); SNES, PC, and Amiga are all graphically superior in every way. In my youth I wanted to port so many SNES games to the IIGS and learned sadly most could not be done -- the other way around was more likely.

That said: people DID use ORCA/M (the 65816 assembler on the IIGS) to write some SNES games. There are better people than me to talk about this subject -- people who did commercial games -- but many of the folks at Tiburon Entertainment were Apple IIGS assembly programmers (guys like Ian Schmidt, Rich Wifall, James Brookes, Jason Andersen, and Steven Chiang). But honestly, most companies ended up writing their own sets of tools (including assemblers, and sometimes C compilers) -- guys like Toshi Morita did exactly this at several companies (LucasArts, Sega). Rebecca/Becky Heineman (then Bill Heineman) may also have done this, but you'd have to ask her. BTW, I'm dropping names because these are people I knew in my IIGS/SNES heyday/youth, many of whom I met, so I'm familiar with their skill.

There are some commercial SNES games that are strongly suspected to have used C (several are RPGs or involve complex text engines). I can't remember names off the top of my head right now, but disassembly and analysis turned up some signs that parts of some games may have involved code generated by a C compiler, mixed with very heavy amounts of native assembly for the SNES specifically. There were also games that had what were suspected to have a kind of "home-grown intermediary language" used to create portions of 65816 code -- disassembly turned up stuff that looked very "C-like" except not quite. So like I said, many companies just wrote their own tools.

People also often forget: unlike homebrew, these were companies with many paid employees, not just a single person trying to wrangle together something. You had pairs of people doing graphics, another guy working exclusively on a sound engine (and/or working with a musician -- sometimes the same person), others working on core game mechanics code, another working on menu/UI, blah blah. With homebrew, it's often one or two people. This is why incredible games like Axiom Verge take nearly 6 YEARS -- done entirely by one guy on weekends and weeknights, while working a full-time job (reference). With both the NES and the SNES, almost everyone involved with writing code had assembly experience (or had to learn it).

So we're back to what I said in my previous post: you're talking a lot about something you have little-to-no familiarity with. Start by learning assembly language. You're going to be fighting an uphill battle using C for the SNES, and you LITERALLY will have no way to debug things in real-time with C code (because all debuggers for SNES emulators are assembly-based). You need to get familiar with bare-metal and console development. Throw away everything you've learned that "holds your hand" (libc functions, kernel functions, etc.) and ask yourself: 'if all I had was a CPU, no libraries, nothing but an assembler and documentation, and told "here's the instruction set, here's RESET and NMI vector locations", how would I start?' Because that's exactly what you'll have to start with. You want to code on a video game system (essentially embedded) released in 1990? You're going to have to think like in 1990.

Many things are the ones that I have to study in order to program a snes game, I know I do not know the native language aka 65816 assembly as to communicate directly with the devices, with respect to the memory system, I understand that apple 2 GS provides APIs for communicate and read / write in memory and peripherals, the peripherals are not equal to those of SNES, the only thing that is equal is the addressable memory = 16 mb RAM, I know that the console prints text by means of some function of an interrupt provided by the firmware, and use another function to write pixels in apple 2 I do not know if it would serve in SNES, they are functions = several instructions in assembly, but without considering the control routines of the monitor, the driver, I have been programming for many years in C / C ++ and BASIC, but programming the Snes is different because of the hardware units it has and the absence of libraries, maybe to do malloc in SNES it is necessary to manually relocate the physical memory, this include control the instruction pointer, and the registers, doing that would not happen a code break somewhere ... a real job, you know much more than i in computer architecture and assembly, it is true that to read hexadecimal code i have to know assembly, I have a basic assembly notion for risc processors, I still do not understand more than arithmetic instructions in assembly, I recently started with the book of Henessy organization and design, a great great book

If you're displaying dialogue between characters or anything like the "speaker boxes" in Super Mario World, you're already dedicating some video memory to either a font or a VWF canvas. And hopefully, you're using BG3 for this so that you can keep the font 2bpp. I imagine the following overall VRAM layout would be practical:

$0000-$3FFF: BG1-2 CHR, 1024 tiles at 4bpp
$4000-$5FFF: OBJ CHR, 512 tiles at 4bpp
$6000-$6BFF: Font or VWF canvas for fix layer, 384 tiles at 2bpp
$6C00-$6FFF: Fix layer (BG3) tilemap, 32x32 words
$7000-$77FF: Parallax layer (BG2) tilemap, 64x32 words
$7800-$7FFF: Playfield (BG1) tilemap, 64x32 words


And even some on the NES, such as Koei's turn-based war sims. It started with NovaSquirrel finding printf format strings in a ROM and ended with AWJ discovering an entire bytecode VM.

So that leaves two steps:

1. Someone writes a character output driver that displays on the S-PPU.
2. Someone integrates it with WDC's tool to provide a working Hello World program, or at least provides details about the calling convention it expects for write().

I can do 1. Who can do 2?

I have not been able to do it yet, I'm working from laevateinn, to see how every part of the snes hardware works as a whole,
there must be a way to imitate printf

Trivia: Subsequently, Brevik of condor/blizzard north fame has repeatedly stated he did his work on Diablo for pc in assembly because he came from a SNES dev background and didn’t yet know how to write C at the time. It may be a simplification, but i found it a bit insightful the approximate mindset of early 90s game developers.

You'd have to establish the context first. Since the SNES has no text mode, you'd need to supply typeface graphics as part of your program, load them into VRAM, and set up the display to use them. Once you've done that, it's possible to write text to a tilemap in order to display it.

...

Apparently Google Translate doesn't do well with terms like "font" and "tilemap" when targeting Spanish...

Right 93143, the pixels have to be loaded, generate a function in assembly that loads each pixel of the letter in Vram, google traslate its under construction

Not exactly. The SNES uses a tiled graphics system, which means that the graphics are composed of 8x8-pixel tiles. And there's no framebuffer; VRAM is solely for holding raw data for the video chip to use when rendering. If you want to output text, the simplest way is not to render the text in software. It's to load a set of tiles, one for each possible letter, number, and so on, into VRAM, and then to write the text string into the tilemap (also in VRAM) that specifies which tile to use for each location on the screen. Writing to VRAM is best accomplished with DMA, since VRAM is locked during active display; this means that the tilemap containing the text should be held in WRAM so it can be transferred to VRAM during VBlank.

Also, the data format of tiled graphics on the SNES is rather strange - it's an interleaved bitplane format where the data for each pixel is spread across multiple bytes, and it's very difficult to render into. (Except for Mode 7, which uses a completely different and much more easily understood format.) This is why graphics are usually not drawn in software on the SNES.

There are of course other ways to do text, including drawing in software, but they are more complicated and slower.

I would like to understand what you say, but it is too sophisticated for me, I know that vblank is part of the kernels in other consoles, I think I understand that you would use dma to transfer a tile, dma uses block transfers, I think that's why you say it is not convenient to write only one pixel at a time, because it would be slower than dma, I also understand that using dma while it is impossible to write in vram allows the letter to be sampled in tv faster than by processing it with cpu, because it is available for the vram faster than processing it with the cpu when the vram is unlocked, but really this is far from my current knowledge, for the moment I do not know the architecture of the snes, I only have a couple of examples, one that is called wdctest that is in assemblergames and the one that i uploaded the forum in this topic on page 1, I have to study snes programming, and snes architecture, to be able to understand the architecture, I have a couple of books, book 1 and book 2, book 1 lacks CPU snes data chapter

It's not just DMA. The way the PPU of machines like the SNES and the NES work, indexing into graphics as counted per tile (usually 8x8 pixels) is hardware supported, whereas reading/writing individual pixels must be done in software by the CPU (and as such, manipulation of graphics on a sub-tile/per-pixel level is rare on slow processors like these. You can sometimes see it used in some games as a way to destructively mask, skew or rotate graphics in RAM, but that's the practical extent of it).

And even if you read/write individual pixels, you still do it to the interim storage of CHR RAM, which is still organized as tiles. You cannot (on the SNES) write individual pixels directly to screen. Where a 'normal' computer has one or several pixel-by-pixel drawn frame buffers, a SNES (and many other retro consoles) have "name tables" which are simple arrays of indexes on what tile to "clone stamp" where, from the graphics RAM/ROM to the screen.

This info video helps explain it, using Commodore 64 and the NES as examples:
https://www.youtube.com/watch?v=Tfh0ytz8S0k

He calls a "tile" a "colour cell", but they're the same. The idea is that you have data about the graphical raster pattern stored in a tile/cell of a fixed size (again, usually 8x8 px), and then assign what collor corresponds to what bit in the pattern. It means you can reuse the same pattern with different colours on different parts of the screen by assigning different palettes to the pattern. This is akin to the indexed graphics mode you have in GIF:s, except you have several palettes applied to different areas, and not just one.

Programming the 65816 (including the 6502, 65C02, and 65802) by WDC, but originally by David Eyes and Ron Lichty, will be sufficient for learning the CPU. You can find copies here: http://wiki.nesdev.com/w/index.php/Prog ... ide#Online

I was about to complain about the link being down, until I noticed the note about "in case the link is down, use this version provided by Koitsu" -- thanks for hosting that!

So, I have seen that a DMA transfer happens between the CHR ram of the cartridge and the memory of the PPU or the central memory WRAM, I understand that tiles are sent or palete information, DMA is how it works in the pcs however it is the rom programmer who fills the controller registers, as in the example kungfu1, instead of from the kernel as it is done in a pc, in both cases it is the CPU that fills those registers, but also the ppu can do it, I think I understood that point reading from nesdev.com, that DMA occurs between both memories,cpu's memory and chr and ppu's memory and chr, while the current processor that requested dma is in HALT state when DMA start.
What i dont know if tiles are hardware circuitry oriented like registers to be filled


Great that book, I already had it, thanks for the complete nesdev guide to learn how to program the SNES, as a fan of SNES I have dedicated to archive as many books as I could, I also have the WDC programmanual in assembly, snes is one of the few modern consoles that have no virtual memory or kernel , playstation 1 has a RISC architecture but it has a kernel, however it resides in an IOPRP image along with the drivers that manages the bios, the only way to know what are the driver routines for the snes, such as DMA controller and joysticks and more things is seeing that it is repeated among the roms in some emulator, it seems to me, but from the N64 onwards the consoles are more like the pcs, the routines of the kernel are hidden from the user

Neither does the Genesis or the Game Boy Advance.

The N64 cartridge's parallel interface (PI) behaves as an SSD, and I'm told its CPU has enough of an MMU to make virtual memory possible. But to make mmap() practical, you'd need to write some sort of cooperative multithreading kernel so that one thread can execute while another thread is blocked on a page fault waiting for a DMA from PI to finish. Such a kernel isn't included in any BIOS in the console itself; it has to be linked into each game. I don't know whether commercial N64 games actually use page faults, or whether they just treat the N64 cart as a file system.

There was no 100% standard way to operate the DMA unit or the joypad ports in software. All of that was up to the developer. You could learn by identifying code in commercial games that touches the relevant registers, or you could just study how the registers work and write your own.

(Actually, if you were using normal joypads, you could take advantage of an auto-read function in hardware that did the serial port communications in the background and loaded some registers with the results. But if you were using a weird device you had to do the serial polling yourself - there were standard BIOSes for things like the multitap, SNES Mouse and Super Scope, but at least in the case of the SNES Mouse a number of developers modified the BIOS.)

I learned partly by using Neviksti's SNES Starter Kit, which contains a number of basic routines. Once I figured out what they did, I became capable of writing my own, so I don't use the Starter Kit routines any more. The SNES is far simpler than a modern computer, so it's actually quite reasonable to write hardware interface code in assembly.

...

As I understand it, the only official, non-developer-defined code used by every SNES game is the code used by the audio CPU to receive data from the main CPU during boot. It resides in the only storage memory in the entire SNES: the audio module's 64-byte IPL ROM. You see, the audio module is almost totally isolated from the rest of the system; its only window to the outside world is a set of four 8-bit I/O ports through which the main CPU can communicate with the audio CPU. And since everything written to the ports from outside has to be read by the audio CPU on the inside, you can't just DMA things into audio RAM; you need the audio CPU's cooperation to pick up the data and put it where it's supposed to go.

The audio module's IPL ROM defines a simple communications protocol, so that when the system boots, the audio CPU starts up running a data reception loop rather than random garbage. The interface code on the main CPU side is not defined by Nintendo; the developer can do anything that properly respects the protocol implicitly defined by the IPL ROM code.

Strictly speaking, the IPL ROM is only necessary for boot. You can write your own audio-side communications driver and use the IPL ROM to load it, and once you've got that in the audio RAM, along with a way to get the audio CPU to jump to it, you never need to touch the IPL ROM again.

First time I hear someone call the SNES a modern console. It has more things in common with the NES than the Playstation so I like to draw the line of "modern consoles" at the 32-bit era and onward.

I assume you mean the release PlayStation, not the early PlayStation that plays Magic Floor and little else.

sure, dma registers can be filled in many ways, depends on the origin and destination, great the snes starter kit !, has a game, the walker example, very good game, I really appreciate the material that you have given me, regarding the programming of the joystick, sure there are ways to read / write the registers, they are waiting for the joystick signal, the registers are automatically read by the program, it should be like a while that repeats until there is a certain value in those registers, with respect to what you say about the sound routine is unique, I'll keep it in mind, I also have something to share, but I'm pretty sure you have it, this does not have to do with the topic, it's for playstation 2
code warrior: http://assemblergames.com/threads/reque ... ps2.63328/
SDK: https://archive.org/details/PlayStation ... rsion3.0.3

repport me if the links are down


is an old console but newer than the commodore 64 or apple 2 gs, it is true that it is not like the generation of 32-bit processors


I used mmap to sample files in memory, I know people who while debugging an application dump the trace in memory reserved by mmap, it is faster than generating a file, it is possible to generate a DMA in N64 from a device like a disk, a page fault occurs when the page is not in memory, but on the disk

mmap is literally just a software interface to an MMU and disk cache. There's no way it's substantively faster than explicitly using PI load commands.

What I've read about the N64 implies that using the MMU apparently causes a dramatic performance hit: page faults are incredibly expensive due to the N64's memory bandwidth; it's best to explicitly move things in or out of memory predictively instead of rely on a fault.

I made a mistake, since the debugging process control the registers so control the program flow, I was writing about that when I wrote about mmap
I believed that N64 only handled virtual memory, you say that is it possible to access the RAM directly?, can you access all the registers of the processor directly or does it have something like protected mode?

The N64 has an MMU with TLB, yes, but it also has an MMU bypass. Reportedly most games use the bypass, because there's not much advantage when it's a single-user single-process system that's usually cooperatively threaded.

More detail

I have read that the only addresses that the cpu handles are virtual, you say that disabling MMU translation allows direct access to physical addresses?, that's great, i have read in n64 wiki, that in kseg1 and kseg0 virtual addresses = physical addresses, that is, direct mapping by the MMU but without translation, and it is possible with pointers to see the content of the TLB, but from ksseg and kseg3 modes

Technically correct.
No, you cannot disable the MMU translation.
Part of the memory map is a direct fixed mapping from virtual addresses to physical addresses, with granularity of 512 MiB. (The entire virtual memory range from 0x8000_0000 through 0x9FFF_FFFF, as it says on the wiki, directly addresses physical memory from 0x0000_0000 through 0x1FFF_FFFF.

Physical addresses from 0x0000_0000 through 0x04FF_FFFF, and 0x1FC0_0000 through 0x1FCF_FFFF correspond to devices internal to the RCP; the rest is access to the Parallel Interface. Given how tricky direct PI interface is, I have a hunch that this direct map was only made available so that the PIF's initial program loader didn't have to use the DMA hardware.)

Physical addresses above 0x2000_0000 are technically possible, but apparently unseen.

I understand, it means that this virtual memory, is never located in another place in ram but always in the addresses from 0x0000_0000 through 0x1FFF_FFFF, in ram


ok, so, knowing where the program can be located you do not need the DMA system with the MMU to do it, and it is also faster to access the RAM directly.
So the initial position of the program using the MMU is not fixed in RAM = another translation for the program segments, which is what happens when loading a rom through the MMU

Yes I mean the release PS. I know it is the Super Famicom's illegitimate child (it even inherited the controller) and the story about the Nintendo PlayStation prototype that was found and repaired.
The biggest reason I've always seen the 32-/64-bit era as a "modern" era in my mind is probably because it's the era when 3D games became standard, that's a huge change in most genres of games that has changed little since. The next biggest reason is that the 32-/64-bit era was designed to use high level programming languages while the 16-bit era was still mostly into assembly.

It doesn't send any email when it is registered