News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Revenant

Pages: 1 2 [3] 4 5 6 7 8 ... 10
Personal Projects / Re: SNES-CD / Playstation BIOS
« on: March 30, 2016, 02:11:24 am »
It probably resembles the Turbo-Duo BIOS. Like the Turbo Duo and Sega CD, the SNES-CD loads tracks to RAM 2KB at a time. Major hassle... that's why CD file systems were invented.

Where do you get 2kb from? According to fullsnes, the BIOS can read up to 32kb from disc in a single transfer (which is also the maximum size of a single file on the SNES CD cartridge's SRAM).

(Bear in mind that there's nothing requiring the BIOS to only be able to transfer a single disc sector into RAM at a time.)

ROM Hacking Discussion / Re: Ever notice weird things in a ROM?
« on: March 29, 2016, 06:51:32 pm »
[edit: misread post, whoops]

ROM Hacking Discussion / Re: Ever notice weird things in a ROM?
« on: March 29, 2016, 01:08:37 pm »
There's no verification either. Almost everything on TCRF about the unused Industrial Area stage in SNES Final Fight is incorrect.

Speaking as one of the site's admins, there's plenty of verification. But you can't really expect the relatively small staff to be able to verify every detail of the nearly 8,000 games currently represented on the site. This is the whole purpose of allowing other users to edit articles (or, at the very least, make issues known on an article's talk page instead of just making an offhanded mention somewhere where there's no guarantee that anyone who cares will actually see it).

Newcomer's Board / Re: Transposing music of Kirby's Adventure
« on: March 22, 2016, 09:43:56 am »
My notes linked above have a complete list of effect commands, though I'm not able to add them to the Data Crystal article at the moment.

ROM Hacking Discussion / Re: How to increase interest in hacking?
« on: March 10, 2016, 08:27:22 pm »
Some people have alleged that Visual BASIC is inferior to Visual C because it's buggier.

I think far more often the issues is not that it's buggier, but that it's specifically designed for simplicity at the expense of flexibility (and performance). There are good reasons why literally no systems code in existence is written in any BASIC dialect.

(Also, "Visual C" is not a thing that exists. I assume you meant Visual C++, which is a development environment, not a language.)

Personally I find BASIC, visual or not, many times easier to deal with than C. For one thing, object overloading becomes confusing, makes many C++ programs languages unto themselves.

C and C++ are two different languages.

For another: MAKE. Don't get me started there. I think MAKE turns people off from C++ more than anything else... many people refuse to try to learn it because they know that they have to deal with MAKE.

Using make is by no means mandatory for C/C++ programming. And if you're using Visual C++ or another similar toolchain as mentioned above, it's probably not even going to be part of the equation. The whole reason IDEs exist is to simplify the development process.

Finally, the interpretation burden. I have no difficulty making sense of well-written BASIC. C/++/# on the other hand, even when well written, requires deep concentration to make sense of.

I think this depends primarily on how familiar you are with C and its descendants. While C certainly does have more of a learning curve than any given BASIC dialect, there are so many languages that inherit its syntax that a basic understanding is considered a pretty fundamental skill for most programmers to have.

C also seems to promote shorthand variable names which make code less self-documenting.

No more than any other language does. What's stopping anybody from writing "let a = 5" in BASIC?

That attitude is incomprehensible to me, for several reasons. While it may be true that people who prefer BASIC have less talent as programmers than people who prefer C, there is nonetheless a much larger pool of them, and they tend to be more enthusiastic.

There is basically no correlation whatsoever between enthusiasm and ability. A reasonably skilled programmer (i.e. a non-beginner) can usually pick up the fundamentals of a new programming language more or less over a weekend.

While modern BASIC dialects may be good for a first language, I would absolutely not recommend it to anyone for any kind of long-term production purposes. It's specifically designed to be a simple language for simple tasks; trying to write something as complex as an emulator or debugger in any flavor of BASIC is going to get hairy and cumbersome fast.

Additionally, BASIC, with its GOSUBs and GOTOs, is actually more like ASM than C is (at least on the surface), so it's not a huge learning curve for someone who is familiar with QB64 to start working in Z80 or 6502. In summary: the community is likely to grow if we push BASIC as the language for developing debugging tools.

GOSUB is functionally equivalent to a simple function call in nearly any other language, and GOTO is something that also exists in C, with identical functionality (and is also a really bad thing to encourage people to use except when they absolutely know what they're doing).

Aside from those two things, there is basically no meaningful resemblance between any BASIC dialect and any assembly language - and if there was, why would you encourage people to use it as their primary language? The whole reason people use high(er) level languages is because they are ideally as far from assembly programming as possible.

(Meanwhile, C is basically as low-level as it gets when it comes to non-assembly programming languages, to the point where most compilers support inserting assembly code directly into C programs.)

ROM Hacking Discussion / Re: How to increase interest in hacking?
« on: March 09, 2016, 03:55:49 am »
Improving machine translation is something people have been trying continuously to do at least since the 1950s, if not earlier. The fact that (e.g.) Google Translate ignores sentence structure in favor of pattern recognition is arguably one of the reasons it even manages to sometimes produce something vaguely comprehensible; otherwise, as furrykef points out, you could turn one perfectly structured sentence into another and end up with something that is technically sound, but so disconnected from the source material in actual meaning that an actual human translator would consider it unusable, if not completely meaningless.

To wit, and to look in the opposite direction for a minute, how would you machine-translate "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" into Japanese?

ROM Hacking Discussion / Re: How to increase interest in hacking?
« on: February 27, 2016, 09:23:45 pm »
Using the command prompt really isn't that difficult to learn, and most programmer-y types will tell you that it's more or less a fundamental part of doing anything above a certain level of technical depth (and I think a lot of ROM hacking tasks fall into that category).

Speaking as someone who develops GUI software professionally, I'd much rather use a simple but useful command line tool that I can invoke as quickly and repeatedly as necessary as opposed to an equivalent GUI-based program where it looks like someone just dropped two or three buttons into the Visual Basic form designer and called it a day. There are a lot of programs where GUIs just feel completely unnecessary and counterproductive in comparison. Being able to use (and design) both GUI and command-line programs effectively can definitely pay off.

Newcomer's Board / Re: Transposing music of Kirby's Adventure
« on: February 23, 2016, 07:10:09 pm »

Here are my old semi-sparse notes on Kirby's Adventure's music. It has the locations of the song pointer tables as CPU addresses but I don't remember where in the actual ROM the individual tracks are located (or which ROM I was even working with, probably either US PRG0 or JP).

The nesdev forum thread "Why no SNES homebrew scene?" comes to my mind as well.

Well, I think part of it is because the NES (as well as the SNES and Genesis) are what the majority of people in the hacking and homebrew communities grew up with, so naturally they're a popular target for that reason.

As for NES homebrew and hacking specifically, I think there's another specific reason: because it's easier. (Usually.)

- BOTH inexplicably cut song #02.  I'm not sure how the order of the music is effected, but I believe it's different.  (There was actually a patch from 2011 on this site that corrected the music -- can be found at: ... FYI!)

It occurred to me some time after making that patch that the removed song is like 80% lifted from "Fine Time" by New Order. Presumably someone noticed and had it removed to avoid copyright infringement.

As for the BS version differences, the cartridge header is literally the only thing that was changed from the retail version:

Code: [Select]
1:10:52.01 D:\games\roms\snesroms
>fc/b "Super Aleste (Japan).sfc" "Super Aleste (Japan) (BS).sfc"
Comparing files Super Aleste (Japan).sfc and SUPER ALESTE (JAPAN) (BS).SFC
00007FD0: 20 FF
00007FD1: 20 00
00007FD2: 20 00
00007FD3: 20 00
00007FD4: 20 00
00007FD5: 20 9C
00007FD6: 00 A0
00007FD7: 0A 30
00007FD8: 00 20
00007FD9: 00 10
00007FDA: AD 33
00007FDB: 00 01
00007FDC: 09 13
00007FDD: F7 08
00007FDE: F6 EC

So the patch can (presumably) also be safely applied to the original Japanese version as well.

Anyway, nice work! It's good to see what is probably my favorite SNES/SFC shmup get some more love.

Programming / Re: Algorithm for best optimizing string compression?
« on: February 04, 2016, 12:00:35 am »
I definitely knew it as DTE originally, when used non-recursively.

I'm surprised Wikipedia claims byte-pair/digram encoding wasn't publicly described until 1994, given how simple it is. In fact, I've personally found one obscure example that is dated 1993 (and I decompressed all of it by hand, which was rather interesting to slowly watch, given the text). I'm curious as to what the real earliest example of it in the wild is.

Programming / Re: Algorithm for best optimizing string compression?
« on: February 03, 2016, 07:07:51 pm »
Yes, "recursive DTE" is the same as dictionary compression with the following differences:
  • Dictionary entries can reference other dictionary entries
  • The length is always 2, so the length of each word do not have to be stored

Is this functionally different from what's usually known as byte-pair encoding?

ROM Hacking Discussion / Re: Maldita Castilla
« on: January 31, 2016, 10:47:43 pm »
"" is the usual archive name used by Game Maker (Studio?) games.

There's a QuickBMS script for them available here:

Newcomer's Board / Re: Satellaview Games Hacking/Translation
« on: January 31, 2016, 12:06:26 am »
Sorry to necropost but did you finish the translation of bs kaizou? Or are you still working on it? no english rom exist on the internet and that game is pretty good and prety underrated.

Not yet. I'd been working with a second translator after DS became preoccupied with stuff but then both of us more or less became too busy with things as well. I'd like to have it finished sometime this year though.

64-bit builds (including accuracy) are now available in the OP.

Going forward I'll probably keep publishing both 64 and 32-bit builds (but most likely only 64-bit for accuracy).

November 17, 2015, 06:21:01 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I've uploaded newer 64-bit builds which should be a fair bit faster than the previous ones (blame me not bothering to switch away from outdated sjlj-based tools until now...)

If you were experiencing slower emulation with the x64 builds (especially with coprocessor-based games) that shouldn't be an issue anymore.

It's been a while. Here's version 073+2. I didn't do everything with it that I actually wanted but I think it merits a new release at this point, and maybe this'll spur me to work on it more often. Download(s) in the original post.

Changelog [mostly scraped from commit messages in no particular order]:
Code: [Select]
Replaced original memory editor with a new, faster and better one [Revenant]
Added hotkeys for breaking and stepping in the debugger (F5 through F8) [Revenant]
Added new "Sound Viewer" window to tools menu [Revenant]
Removed "enable" checkbox from breakpoints, now enabled by R/W/X setting [Revenant]
Re-enabled quickload/save menus [Revenant]
Frame count added to CPU/SA1 traces [Revenant]
Fixed cycle timing issue introduced by debugger in previous release [Revenant]
Slightly improved SPC700, SA1 and SuperFX disassembly [Revenant]
Fixed MMIO mapping on SA1 bus (fixes crash with Marvelous and possibly others) [AWJ]
Various emulation, build, and other improvements [AWJ]
Backported various OpenGL, Direct3D, and rawinput fixes from bsnes 081+ [mziab]
Fixed potential GUI deadlock when Windows system menu is opened [Revenant]
Improved BPS/UPS/IPS soft patching support [mziab, Revenant]
snesreader no longer advertises RAR support that it doesn't actually have [mziab]
Backport newer File Extractor from VBA-M. LZMA2-compressed 7zip archives work now [mziab]
Various build fixes, mostly for clang / Mac OS [Optiroc, AWJ]
Nicer OSX app bundle (custom icon and retina support enabled) [Optiroc]

If there's something I was going to add / should have added but didn't, feel free to poke me about it anyway.

64-bit accuracy builds are still coming eventually.

Newcomer's Board / Re: Having some trouble applying an IPS patch
« on: August 08, 2015, 08:28:12 pm »
Probably, since Lunar Magic still expects ROMs to be headered (and will apparently will now add a header automatically to ROMs that don't have one).

I have no idea why it still does, since SNES copier headers haven't actually had any useful purpose (other than making distributing patches a hassle) for more than 15 years at this point, but that's probably a discussion for somewhere else.

Pages: 1 2 [3] 4 5 6 7 8 ... 10