It is currently Wed Aug 15, 2018 3:34 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sun Apr 22, 2018 2:42 pm 
Offline

Joined: Thu Apr 19, 2018 12:19 am
Posts: 16
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


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 2:47 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1694
Location: Gothenburg, Sweden
Quote:
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.


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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 4:36 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 957
charly400 wrote:
there must be a way to imitate printf

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...


Top
 Profile  
 
PostPosted: Mon Apr 23, 2018 2:18 am 
Offline

Joined: Thu Apr 19, 2018 12:19 am
Posts: 16
93143 wrote:
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.



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 :)


Top
 Profile  
 
PostPosted: Mon Apr 23, 2018 2:51 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 957
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.


Top
 Profile  
 
PostPosted: Tue Apr 24, 2018 2:44 am 
Offline

Joined: Thu Apr 19, 2018 12:19 am
Posts: 16
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


Top
 Profile  
 
PostPosted: Tue Apr 24, 2018 3:03 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1694
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Apr 24, 2018 9:56 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3474
Location: Mountain View, CA
charly400 wrote:
... 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

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


Top
 Profile  
 
PostPosted: Tue Apr 24, 2018 10:38 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 445
Location: Central Illinois, USA
koitsu wrote:
charly400 wrote:
... 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

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!

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 11:28 am 
Offline

Joined: Thu Apr 19, 2018 12:19 am
Posts: 16
FrankenGraphics wrote:
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.

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

koitsu wrote:
Programming the 65816 (including the 6502, 65C02, and 65802)[/i] 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

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


Last edited by charly400 on Wed Apr 25, 2018 4:03 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 11:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20403
Location: NE Indiana, USA (NTSC)
charly400 wrote:
snes is one of the few modern consoles that have no virtual memory or kernel

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.


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 3:23 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 957
charly400 wrote:
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

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.


Top
 Profile  
 
PostPosted: Fri Apr 27, 2018 5:10 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 996
Location: Sweden
charly400 wrote:
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,
...
but from the N64 onwards the consoles are more like the pcs, the routines of the kernel are hidden from the user
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.


Top
 Profile  
 
PostPosted: Fri Apr 27, 2018 6:54 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20403
Location: NE Indiana, USA (NTSC)
Pokun wrote:
First time I hear someone call the SNES a modern console. It has more things in common with the NES than the Playstation

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


Top
 Profile  
 
PostPosted: Sat Apr 28, 2018 1:14 pm 
Offline

Joined: Thu Apr 19, 2018 12:19 am
Posts: 16
93143 wrote:
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.

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

Pokun wrote:
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.

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

tepples wrote:
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.

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


Last edited by charly400 on Sat Apr 28, 2018 10:27 pm, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group