Points of Required Attention™
Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,492,162
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 04-27-24 11:32 AM
Guest: Register | Login

Main - Posts by Parasyte

Pages: 1 2 3

Parasyte
Posted on 12-29-09 04:19 AM, in [SMD]How to hack Gens to use 2megabytes as RAM?? (or: how NOT to hack) Link | Quote | ID: 124434


Red Goomba
Level: 18

Posts: 41/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
ROM hacking is quite a bit more difficult. For the very reason you've added more RAM and a higher clock rate to an emulator.

Parasyte
Posted on 12-31-09 07:08 AM, in asm programming = slave labor Link | Quote | ID: 124614


Red Goomba
Level: 18

Posts: 42/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
Posted by Aaendi
Posted by DahrkDaiz

Of course, that's because the carry bit is needed to do math beyond native cpu word sizes, otherwise you have no way of knowing when the value exceeds the storage unit. It's a feature and much needed.



Most cpu's have both an add with carry, and an add without carry opcode.

Behold, CISC architectures! (65c816 is technically a CISC architecture, but it's very simple compared to x86-like architectures. Zilog z80 comes to mind...

This is why RISC instruction sets were invented; If you have only a single instruction that performs a specialized operation, and apply that same methodology across all instructions, you're left with a very well-tuned architecture that can be learned in mere hours. Who needs two add instructions (much less five or six) when one will do?

Posted by Aaendi
Posted by DahrkDaiz

That's because they're "index registers" used for "indexing". It's a slight nuisance anyway and you can still do major math operations without indexer registers.



When your in a tight loop it becomes very useful.

Tight loops are bad for many reasons. Mostly where efficiency is a concern; CPUs with branch prediction can help reduce branch overhead inside tight loops, but on SNES, you're SOL; unroll those loops if you want to write fast[er] code!

Parasyte
Posted on 01-05-10 03:58 AM, in asm programming = slave labor Link | Quote | ID: 125058


Red Goomba
Level: 18

Posts: 43/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
If you don't want to be a programmer, you shouldn't become a programmer. This ideal applies everywhere equally; I do not want to be an artist, so I never became an artist.

Parasyte
Posted on 01-10-10 02:08 AM, in Debugging needs a face-lift. (rev. 2 of 01-10-10 02:16 AM) Link | Quote | ID: 125339


Red Goomba
Level: 18

Posts: 44/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
Some of you are familiar with this, but for the majority of you, this will be your first introduction to a new debugger technology I am developing. The idea is a remote debugging protocol, applicable to emulators and video game hardware, among other uses.

I've written so much about this, I don't even know where to begin. And even then, it is still difficult to explain its uses concisely. The name of the protocol is "Scalable Remote Debugger Protocol". And I usually try to define it with the following rhetorical question:

"What if you could use FCEUX's debugger on Nestopia? Or on Nintendulator? What if you could use it on a real NES?"

That's the driving force behind SRDP. My goal is the separation of the debugger UI from the emulator. This separation means it can even be used for debugging on the actual hardware.


How does it work?

SRDP is not a magic potion. It is a protocol. Basically, a kind of "common language" that emulators need to speak. This common language allows communication with a debugger user interface; a program that the user interacts with to get into the low-level functionality of the target game.

What the crap does that mean? It means the emulator will *not* have a debugger UI built-in. But it will have debugger functionality built-in. To access that debugger functionality, you connect to the emulator through a debugger interface. That's right; two different programs, with SRDP allowing them to share information.


But why this separation?

The separation of the debugger UI from the low-level debugger functionality allows for a lot of really great features. And I've written a lot about the advantages of the separation. But for one, it will allow the same debugger user interfaces to be used on any emulator of your choosing, or even on the real deal.

Of course, using a debugger interface on the hardware means the hardware needs a way to speak SRDP, as well. It will require a hardware module of some form that can provide a communications link with a PC. It will also require software running on that hardware which implements the low-level debugging functionality.


What about SNES? What about PSOne? What about...

Yes, they will all be supported! Yes, all of them. The design of SRDP (and even its name confirms this) is to be scalable. That means it can scale up to arbitrarily complex machines. In theory, as complex as supercomputers with thousands of CPUs. This also means it can scale down to arbitrarily small machines with few resources. Even as low as those silly Tiger LCD games we used to have in the early '90s! (Do those still exist?)


So what do you [Parasyte] want from me [the reader]?

Well, mostly what I'm looking for here is just support. In the form of PR, for example; spreading the word, and generating "hype" and excitement will be the greatest spark of motivation for myself.

If you are a coder interested in writing debuggers, augmenting emulators, designing user interfaces, or just using debuggers (for hacking, or fixing bugs in your own code, for instance) then we could use your input as well! We have a protocol specification to finish specifying, an API that needs more thought, loads of documentation that needs to be written, debugger interfaces that need to be created, emulators that need to be modified... The list is nearly endless.


I want to help! What do you want me to do?

There's plenty of reading available:

* The post that started it all
* The debugger UI that I intend to create to support any game console over SRDP
* About the protocol
* A recent post to HCS's forums attempting to generate interest and help from the N64 community
* My blog, and a central location for SRDP development info
* Follow our progress on Twitter
* Another post, this one regarding the application of SRDP to PS2

And finally, there's also the IRC channel, where I will be randomly making assertions on the design and development of SRDP, the reference implementation "libsrdp", my test suite and test client/server included with libsrdp, and general problems associated with modern debugging. I implore you to join the channel, even if to idle: irc.freenode.org #srdp

If you have any questions, join IRC and ask away!

Parasyte
Posted on 01-10-10 02:25 AM, in asm programming = slave labor Link | Quote | ID: 125340


Red Goomba
Level: 18

Posts: 45/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
Do you want to be a developer, or a designer?

There are advantages to having knowledge of both. But to create a "killer app" you really need a dedicated team. Sure, some people can create a complete game alone (*cough* Sivak *cough*) but that doesn't mean his games are killer apps. (No offense, Siv! Battle Kid is a fine example of what a single person can do.)

All I am saying is, you might want to focus on just one thing. Design? Direction? Art? Music? Programming? Story? Writing?

Trust me, programming is not the most important out of that list.

Parasyte
Posted on 01-11-10 05:09 AM, in asm programming = slave labor Link | Quote | ID: 125432


Red Goomba
Level: 18

Posts: 46/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
Using hardware rotation will produce less "choppy" results than having sprites drawn at different angles.

Would I rather have 360 steps of rotation, or 16? Hmmm, that's a tough decision...

Parasyte
Posted on 01-18-10 03:58 AM, in Debugging needs a face-lift. Link | Quote | ID: 125683


Red Goomba
Level: 18

Posts: 47/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
Feel free to join IRC. There are other people getting involved that don't know where to begin, either. Sometimes I don't even know where I should start. But come on in, the water is nice!

There is some potential for this project to help bring powerful debugging tools to OS X. My primary workstation is OS X, in fact. So if there is any possible chance for this project to succeed, OS X will definitely be considered one of the top priority operating systems to support. We just need more open source emulators for the platform. But many of them are already portable enough as it is. Here is some of my work in this particular area: http://www.kodewerx.org/forum/viewtopic.php?f=11&t=7125

Parasyte
Posted on 01-19-10 08:18 PM, in asm programming = slave labor Link | Quote | ID: 125733


Red Goomba
Level: 18

Posts: 48/48
EXP: 24789
Next: 5108

Since: 02-09-09
From: Flagstaff, AZ

Last post: 5211 days
Last view: 5189 days
I'm not sure. That's a good question.
Pages: 1 2 3


Main - Posts by Parasyte

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.230 seconds. (336KB of memory used)
MySQL - queries: 68, rows: 88/88, time: 0.224 seconds.