It is currently Sun Nov 18, 2018 1:06 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Thu Apr 19, 2018 3:23 am 
Offline

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


Top
 Profile  
 
PostPosted: Thu Apr 19, 2018 11:35 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Thu Apr 19, 2018 2:01 pm 
Offline
Formerly WheelInventor

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

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


Top
 Profile  
 
PostPosted: Thu Apr 19, 2018 11:27 pm 
Offline

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


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

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



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


Top
 Profile  
 
PostPosted: Thu Apr 19, 2018 11:40 pm 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 664
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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).

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Fri Apr 20, 2018 8:05 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20777
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Apr 20, 2018 8:56 am 
Offline

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


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

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


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?


Top
 Profile  
 
PostPosted: Fri Apr 20, 2018 9:16 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20777
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Fri Apr 20, 2018 11:12 am 
Offline

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


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 6:43 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 7:18 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20777
Location: NE Indiana, USA (NTSC)
In that case, I would write write() in 65816, just as I have done in 6502.


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 8:52 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 12:09 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 2:46 am 
Offline

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


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 7:19 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20777
Location: NE Indiana, USA (NTSC)
koitsu wrote:
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.

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

koitsu wrote:
There are some commercial SNES games that are strongly suspected to have used C (several are RPGs or involve complex text engines).

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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 53 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 5 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