 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by neviksti |
| Pages: 1 2 |
| User | Post | ||
neviksti Goomba Level: 8 Posts: 1/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Hello, I was curious about the F-Zero data and people suggested I look here. I am by no means a rom hacker, more of a rom programmer I guess. So my main methods for trying to understand a rom are to look at the code. This is usually slow and inefficent, but eventually leads to a fairly complete understanding of what the game is doing during xyz. In short, I'd like to help... but be patient as my methods are slower. I figured out how the game keeps track of its state and goes through menus etc. So I tracked down this... Here is the "grand prix mode" track loading routine: 80/88FC: 20D589 JSR $89D5 Here is the "practice mode" (or title screen) track loading routine: 80/8ACD: 20D589 JSR $89D5 Hopefully this will quicken the search for others reading the code. I would love to see a fully functional track editor, so if you tell me what is most needed, I can try to focus my efforts on that. In the mean time, I'll continue reading through the code. |
|||
|
neviksti Goomba Level: 8 Posts: 2/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Hello, if I am blind and there is a big "search" button that I am overlooking, I appologize. There is a lot of great info on this board, and I was wondering if there is some way to search through all the posts/threads to see if a particular question/topic was already discussed without having to read every single one. Thanks. |
|||
|
neviksti Goomba Level: 8 Posts: 3/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| The MOVZ and INCZ aren't part of the "standard" spc700 opcode list that I am used to. What did you use to disassemble it? (Or where did you get the list of opcodes if you did it by hand?) Anyway, it appears they are using "Z" to denote "byte" (as opposed to the MOVW opcode, etc). Also, the ending of the boot rom isn't code, it's just the reset vector. So don't worry about trying to interpret that. Anyway, here is the code I commented up for myself:
Edit: grr... the board keeps clipping my post (the lines don't wrap around). Should I not be using "pre" tags? It seems to mess everything up after it, even though I've closed the tag. Oh well, for now I'll just manually enter the line breaks. Edit: The point of the "blah" section is to check if the bootstrap is being signalled to move onto the next block (this is done by changing the counter by more than 1, ie not just incrementing it). As I said, the above is just comments I wrote for myself ... so you may want to comment it up yourself for it to be more useful. Hope it helps though. (edited by neviksti on 06-10-05 10:07 PM) (edited by neviksti on 06-10-05 10:10 PM) (edited by neviksti on 06-10-05 10:11 PM) |
|||
|
neviksti Goomba Level: 8 Posts: 4/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| First of all, I suggest using a nice debugger, as these problems can be quickly figured out that way. Lately, I really like Super Sleuth, http://users.tpg.com.au/trauma/spx/ It has nice breakpoint features, and you can single step through your code. Rarely, I still use zsnes (dos with debugger), since it still has other helpful features. That being said, I can probably guess what the problem is here. Your code is basically: wait till auto-joyread has completed check button presses if anything pressed, start game else go back and wait again (Your original post was fine, I'm not sure where all the confusion is coming from.) Anyway, the problem is that auto-joyread isn't always enabled. You need to request the system to do this task (set bit0, reg $4200 ... you only need to do this once, unless other code clears it). This is because some games use the manual read method, and if the system was trying read the joypads at the same time ... well, obviously both reads would fail. Also, a long time ago, I remember some emulators having a problem with auto-joyread not working unless NMI was also enabled. I checked it out on the real system ... but my memory is really bad, and I can't remember the result. I think the real system didn't need the NMI enabled for auto-joyread. Regardless, I suggest testing your hack out on the real system before you get too much farther. (I or others can do that for you if you don't have the equipment.) (edited by neviksti on 06-12-05 10:21 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 5/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Hello, for those that don't know of me, I love playing with old hardware. Half the fun is learning how it works ... or in some cases, just getting it to work. I have considered this for quite some time now, and decided I want to work on the SNES X-Band. I am looking for people to help. For those that don't know, the X-Band was a device for the SNES that: - in essence was a massive "Game Genie", it is a hacker's dream come true, allowing fairly massive patching of almost any game - the "main program" on the device itself was updatable - it contained a modem - there used to be a service that you could call into and download updates, and hacks ... Which allowed many games to be turned into multi-player modem games! - the US user base was fairly large and enthralled with it, but when the company was bought out the service was shut down (I'm probably getting history a bit wrong here, but they were bought out ... eventually leading to Qualcomm as the owners I think) - From the sounds of it, the programmers were a close knit group of hard working youngsters just out of college. They disassembled and gutted many a game to hack it and over came the obstacles to make games 2-player modem games ... which they obviously weren't originally designed to be! - You could also send mail and read news "online". and finally - There is actually a secret built in memory viewer/hexeditor! (This means if we can get something working, by making just a couple changes, ie the dialup number in memory, anyone with an X-Band could try out what we create... they don't need a copier or any other special equipment.) This thing has plenty of potential. Who's interested in helping? What would really help: - If you own an X-Band, check if the memory (battery backed SRAM) is still good by starting it up. If so, I'd love to get a copy of some real patches (haven't found any X-Bands with good bateries yet). - Try checking local used game stores and seeing if they have some X-Bands that still have the saved memory. - If you have an X-Band and can't help, but would like to donate it ... well, it would be very much appreciated  Side oddities that would be fun to fiddle with: - If you own an X-Band keyboard (or know where to get one), I'd be interested seeing how it works. (This was added later in its life, and I'm not sure if it got beyond the proto-type phase.) For those interested in helping with the hacking, some skills that would be helpful (not required though): Code readers: - understand SNES asm - understand C at a low level (We will be looking at the code in asm, but it was originally written in C and then compiled ... so it looks kinda weird unless you understand C at a low level.) - goals are to figure out software protocals and hardware features so that we can make this puppy do whatever we want Code writers: - can write a modem program for a PC (I have done this in DOS in C with asm thrown in as well, but I used direct register writes and swapped interrupt vectors ... I'm not sure how to do it "the modern way" in Windows) - this is for eventually making a new "server" ... which will depend on info from the code readers above, but I'd like to have at least the fundemental communication routines setup so we can play with / test info as it comes in. - also plenty of test programs to figure out the hardware will be necessary (SNES programs) - ultimately, it would be fun to do a proof of concept with MarioWorld (It's two player, but you take turns ... so there are no synchronizing issues). Then try out MarioKart. - maybe someone that could write a crude "decompiler" to turn the X-Band code back into a crude form of C (would make reading it much quicker). Hardware skills: - even if you don't understand asm, you may be able to help interpret strange findings from the code ... a good understanding of the memory map and chips involved will help us figure out the hardware (I already have a rough sketch of the memory map, and have a datasheet explaining the modem chip used in this cartridge) - For testing purposes, it would be nice to connect the X-Band directly to the modem of a PC. There appears to be a mode of the modem chip on the X-Band that supports this ... however, I have no idea how to get the PC modem to do this. Help here will be nice as well. - help with understanding the theory behind how they overcame the lag in a phone line to make a synchonous multiplayer modem game Basically, there are plenty of fun things to work on. After this progresses a bit, I can supply the following to big helpers that need it: - a SF3 or SF7 (an SNES copier) which is versatile enough to use the XBand on pass through and still allow modifying the ROM - an X-Band for testing So who's up for the thrill of conquering this rom hacking challenge? People with all ranges and levels of interest are welcome! Thanks, -nevisti... P.S. If you guys know other places to pull in friends to work on this, feel free to ask them as well. (edited by neviksti on 06-16-05 04:41 AM) (edited by neviksti on 06-16-05 04:42 AM) (edited by neviksti on 06-16-05 04:45 AM) (edited by neviksti on 06-16-05 04:47 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 6/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
Originally posted by XcomGS No, broadband would require an entirely different chipset (and programming). So that is not within the scope of this project. Originally posted by XcomGS I will not be producing these. Once the service shut down people had no need for the device, so it is often easy to pick up (and cheap!). Just check around your local used game shops, or even better ... E-bay, Amazon, other auctions and used-goods places online, etc. ======== Okay, for those willing to help: I looked into this briefly several years ago, but not intensively. So please bear with me while I search through all my old stuff to revive this project. First thing, I had contact with one X-Band employee for awhile. He gave me some confidential files which I can share with other helpers. These are helpful, but aren't a "solve all". If you want to help and need the files, just PM me. Here is a comment he made though: We called an 800 number and we picked off caller ID to then This is the "SNES X-Band <--> Server" software protocal that I would like to understand. Do whatever you feel is best, but I suggest finding the data first, then worrying about the format of it (I'm not 100% sure the final implementation was as he remembers it above... this was not the part he worked on ... so keep this in mind). So please code readers, try attacking that first. ======= The ROM in question (that I've been working on) is: "XBand Modem BIOS (U)" Here's the memory map as I see it (the employee wasn't able to help me with this): The code expects 64kBytes (yes bytes) of SRAM in bank $E0. The "modem registers" or whatnot seem to be located in bank $FB, The BIOS is HiROM. Strangely, the bios runs its code from banks $Dx (instead of $Cx). So, if it doesn't already, any emulator you use has to correctly mirror the ROM (it repeats every $10 banks in this case). On a side note, the code is horribly written in many places (and I mean horribly), so I can only assume that they used a higher level language (to make coding easier), and that didn't optimize very well and converted the code a little strangely sometimes. This hunch was confirmed by the XBand employee.
======== I have the modem datasheet which I can send to anyone interested. But I found some old notes of mine and believe I just got it from here:
========= I don't remember the "button sequences" that allowed secret things like the hex-editor to appear. I remember finding the code that did this and all the sequences, so it must be in my notes here somewhere. I'll let you know when I find it. ========= For those playing with the ROM in an emulator to figure it out, I've really come to enjoy the debugging/browsing process in Super Sleuth. I you haven't tried it yet, I suggest giving it a chance. It has no sound currently, so I'd also suggest at least seeing it in another emulator though ... so you can enjoy the fun X-Band music .========= EDIT: I may have had to hack the ROM to get it to run on the emulators. (Yes, my memory really is that bad.) If you are having trouble, let me know. (edited by neviksti on 06-16-05 05:33 PM) |
|||
|
neviksti Goomba Level: 8 Posts: 7/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
Hmm... yes, you probably did use a hack to get it to run on emulator. At the least it won't run in snes9x debug. Shame too, since it would probably be rather easy to hack out those button codes again.Okay, I remember now. I used Super Sleuth since the author quickly added support for it when I posted the above info years ago. I thought (or at least hoped) that the other emulators followed suit (especially since I posted it on the ZSNES boards). Oh well, I guess we won't be able to listen to the songs on the emulators for now. But I really prefer Super Sleuth's debugger anyway. (The trace dump features aren't as nice as some, but the "in game" debugging is great!) ------- EDIT: Apparrently, an offshoot of the Snes9x sources (UOsnes) did incorporate the X-Band info I posted a couple years ago. I don't know if you can get a copy with debug support though. -------- I can try to add support to snes9x myself if you think it will really help. If someone more familiar with the Snes9x source can put in a "game specific hack" with the above memory map (all that really matters is the bank $E0 SRAM, I can fiddle with the ROM for the rest) please let us know. Oops forgot to lookup those button press sequences. I'll do that in the morning. Goodnight everyone! |
|||
|
neviksti Goomba Level: 8 Posts: 8/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Well, it looks like it gets the row data after at least two "unpackings". - somehow the rows for the "track panels" as you called them (32x32 tiles, or 16 rows) are put into ram - then the rom data holding all the track panels are unpacked (using the above ram table) into just row data in ram I have not found that first part yet (or more accurately, I may have found it, but have not made sense of it yet ... it jumps all over). Here is the routine for the second part: Notice there is no compression ... so this step is easy.
|
|||
|
neviksti Goomba Level: 8 Posts: 9/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
Originally posted by spoondiddlyI found more of my old notes -- I used the tracer and figured out some sections where it looked for button sequences. I only checked for sequences on the main screen, so these need to be entered there: Maze mini-game: down(2),left(2),right,B Snake mini-game: up(2),left,right,left,right, L font green cycle - up(2),right(2),down(2),left font clear cycle - down(2),left(2),up(2),right font rainbow cycle - left(2),up(2),right(2),down unknown - up,right,down,left,B normally pressing B selects the item you're on ... this sequence doesn't ... so it must be doing SOMETHING ... maybe it unlocks another secret? + four "impossible" sequences that I don't understand yet. (Impossible because they don't correspond to actual button values. I tried hacking the rom to make them valid sequences, and a couple appear to be a messed up font and others just didn't work. FAQs for the X-Band online appear to suggest that some sequences were removed/changed between the different versions (japanese version as well as the genesis version) ... so maybe this is just a remenant of that.) ============================= Originally found by searching the internet: Done from the options menu: debugger: up,right,down,left,up,up,left,right,left,right,down,L Just play with the buttons, and it isn't too hard to figure out. Except for maybe what commands can be entered on the "command line". I think I figured this out as well, by reading the disassembled code. I don't remember seeing anything that great in there, but I'll look again to refresh my memory. Here's a quick run down in case it helps: left,right - move cursor up,down - scroll memory address by "one line" of hex data A - change "view mode" between: hex + ASCII / hex only / ASCII only B - increase address digit that cursor is on X - decrease address digit that cursor is on Y - jump to address pointed to (by cursor, or top of data shown) when on memory viewer - executes command when on command line Start - leave debugger Select - change "input mode" between: hex part / ascii part / command part L/R - increase or decrease address by one when on memory viewer - increase or decrease letter by one when on command line EDIT: Okay, I looked up my old disassembly of the "command line" stuff. Here are valid commands: (a fairly large chunk of the code at bank $D7 is used for the command line stuff)
============================= I still don't have anything big (new anyways) to report yet. How is everyone else doing? (edited by neviksti on 06-19-05 05:31 AM) (edited by neviksti on 06-19-05 05:40 AM) (edited by neviksti on 06-19-05 05:55 AM) (edited by neviksti on 06-19-05 07:03 AM) (edited by neviksti on 06-19-05 07:05 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 10/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| > Did you use the service back when it was around? Sadly no. As for the "patching system", the "game patches" sound like they work like this: - there is hardware that can hold up to 16 addresses - if the game accessed any of these addresses, the memory map switched to something that put in code from the X-Band memory - there is some register that the X-Band patch writes to to say that it's done and return the memory map to normal I know that is fairly vague, but it is a start. The X-Band could also patch its "Operating System". This worked a different way. When they wrote the code, they made sure that many routines were called using a kind of jump table in SRAM. This way the service could download "updates" by just putting some data/code into specific spots in the SRAM. If you fiddle with the code for a bit, you'll see these routines real quick. They are all over. Most are "called" through $E00040. Here's my comments on the memory so far while reading through the code (so it might be wrong), but hopefully it is useful:
If you are interested in the info the X-Band employee shared with me, just let me know. Also, it looks like those links for the modem datasheet are down as well. I can send it all to you if you want, just let me know where an appropriate place to send several attachments is. (edited by neviksti on 06-21-05 01:03 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 11/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| HyperHacker wrote: > I know I'm interested even though I'll probably never see one of these devices.  > How big are the attatchments? Compressed, the data is about 5 MB. If this is a problem, I can host it temporarily and send you a link. X-bands are getting harder to find (probably more because people think no one will buy it ... not due to lack of them "laying around"). Just seeing this thing run on a real SNES makes one wish it worked again. Besides, it's a shame to work on hacking this thing unless you have one in hand. So, two options: Option one: - If you are willing to help, and find someone selling one (usually just posting on a gamer's board will bring a couple XBander's to the surface) I will buy it for you. I don't expect miracles from you, but please people ... don't rip me off. This really is for those interested in helping. Option two: - I have two X-Bands. I want this so I can do testing later. However, it may be best at this early stage to loan one out to another helper. I really hesitate on this, since I do need it back later. But I'll consider this if we can't find anyone selling X-Bands. spoondiddly wrote: > Hah! spent the time to hack that out and you already got it up - yesterday! Can we compare notes on this? I did more work trying to figure out the "button sequences", and there are still some things that are confusing me. Also, notice the: "Remote Diagnostic Screen" !! (I forgot about that in the previous posts) If we ever get an 'X-Band server' working, this may be an even better way for people to get their X-Band working again. (No need to fiddle with anything in the onboard hex-editor now, because (I believe at least) that the customer service could dial in and run any routine in the OS and/or modify the SRAM, etc.) Anyway, here is the raw info I have about the button sequences. I tried entering the "impossible" sequences on the second controller input hoping that's how it was encoded. No luck. Also tried on first controller just in case. No luck. (Also, don't bother disassembling/commenting the routine mentioned here ... I already have done that, so if you want that as well, just let me know.) Routine that checks key patterns: $D391A6 (edited by neviksti on 06-22-05 04:16 AM) (edited by neviksti on 06-22-05 04:18 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 12/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| HyperHacker wrote: > Why not just edit the button sequences and see what happens? If they are supposed to be there, then there should be a legitimate way to activate them. But, like you, I was curious what would happen if I just put in a different button sequence. So I actually did this a couple years ago when I first looked into it. Unfortunately, I don't remember anything interesting happening. But, just to be complete I decided to redo that test: I modified the "impossible" sequence to just be all right button presses (modifying only one at a time of course), and I saw the following: $D8:1B1A - garbled color font $D8:1BD6 - nothing happenned $D8:1BFA - nothing happenned $D8:1C5E - nothing happenned The code in this ROM is all over the place. Comments from X-Band employees themselves was that they tried to use the same C code between all the systems as much as possible. So, while in "normal" cases I'd feel like we're missing something big here ... I really think we are just seeing "defunct" junk that wasn't fully commented out. That being said, I'd love to be proven wrong if someone finds out how to correctly activate them. |
|||
|
neviksti Goomba Level: 8 Posts: 13/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
Originally posted by Overload Thank you for pointing that out. I got it just a couple hours before it expired... that was close. So now I have an extra X-Band to fiddle with. And yes, the SRAM is mirrored at Bank $60-$7D. Would you like the X-Band to work on? It goes without saying that you know how to reverse-engineer with the best of them. I'd definitely enjoy working on it with you. I have a rough idea of how the server works now. There's some "checksum" business that I'm not very sure about yet. I'm going to write a small server program to test out the ideas soon. Originally posted by Geiger The information necessary to get the X-Band rom to load and run has already been known for about two years. It involves the SRAM mapping already described here, and the modem regs set to always return some constants (I don't remember this, as Overload was the one that figured it out and posted it on the old Zsnes board). Anyway, Overload was the only one that incorporated the info into his emulator. (Well, and the UOsnes emulator which I've never used.) So support for loading the X-Band rom is not missing in Snes9x / Zsnes due to lack of information. I don't think it's reasonable to include all the features of the X-Band into an emulator (it would be neat, but way too much effort would be required). So the only purpose the emulators play in this is just to give us a quick way to see how the code fits together (and to see directly the code that is pertinent to a particular situation). Since I prefer Overload's emulator for debugging anyway... I'm already quite happy. However, if you want the X-Band ROM to load/run on Snes9x and/or ZSNES, feel free to remind them about it. (edited by neviksti on 06-28-05 09:04 PM) |
|||
|
neviksti Goomba Level: 8 Posts: 14/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Somethings I'd love to see in a disassembler: 1] For massive disassembly / reverse-engineering of the code, it would be nice if the disassembler could use the information the user has learned from the code to make sections more readible. For example, as I read through the code I could make a table of variable names, routine names, and even "macros" (some code was obviously generated with macros and it's annoying to see similar chunks again and again ... when the only info you'd really need is just the macro name). Then when dissassembling other sections of the ROM (or even re-disassembling the same sections to make it more readible), the code will be much much more readible. To some extent the variable and routine names thing can often be done manually by find/replace in a text editor. But this gets quite time consuming for each new disassembly as the list gets longer. I am particularly interested in the notice "macro" feature, as it would make code much much easier to read, and currently there is no easy way to do this. I have to do it entirely by hand. 2] If you are using tracing abilities ... I'd love something that notices DMA loads and marks that section of the rom as data (and maybe even mention where it is loaded to, so we have an idea of what the data is). ----------- Comments on previous posts: Branches to labels that are not internal to the routine I just write as follows "BRANCH_$XXXXX". Now I use Rom-addresses for those. But you're saying you would prefer snes memory mapped addresses? Yes, I would prefer snes memory addresses as well. These are the addresses in the actual opcode data (except for relative jumps), and for debugging purposes (putting in a breakpoint) this is the address needed. In short, the system address is usually the relavent address. > php/plp inside the current routine would be nice, yeah. Well the only reason I was considering it was to keep a more accurate eye on the A and X/Y register width. But I've never seen it used that way. Of course, I wouldn't rule out that someone might have used it for changing register widths. I have seen this used. Not often within a routine, but quite often between routines. In most coding styles that choses to change the register widths frequently, I see something like: routines will php, set to the widths they need for that routine, and then plp at the end of the routine ... for "linear" disassemblers this often messes up the widths for the code after that routine (since they don't do any tracing, or handle php/plp stuff). The worst rom I've ever looked through as far as trying to keep track of the reg widths was the SF7 Bios. The coding style used there had no "standard" width and the routines didn't even always return with the same widths as when they were called. I'm not sure how the programmer kept that all straight in his mind. It was a horror to disassemble. ------------- There are a couple projects I am working on now that require large disassembly of 65816 code. I can test your disassembler by using it, however I don't really have time to come up with extensive tests specifically to look for bugs. The code I'm working on understanding right now was actually written in C, so there are all the lovely stack frames, pushed parameters, standard regs to return stuff in, etc. It takes quite awhile to go through since the code is not nice compact asm ... but sprawling "translated to asm" C code. If you could write a crude "decompiler" instead of just a disassembler, that would be incredible. But that's pretty much a different project entirely. Anyway, good luck on your project. I look forward to seeing how it turns out, and if you want me to help test it, just let me know. (edited by neviksti on 07-05-05 03:28 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 15/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
Originally posted by MathOnNapkinsWell, you'd have to keep track of values stored to memory. For the regular DMA, you need to keep track of data written to the $43xx registers. Then when $420B is written, just grab the source/destination addresses as well as length info of the DMA from your saved $43xx registers. This information can be used to mark portions of the ROM as data, as well as allowing the user to know where the data is sent (what it is used for). I do a lot of testing myself. And when I think I've found a stable version I try it out on my own disassembly and I generally trust it. Okay. I was just offering to test it since you asked for beta testers and input. Sounds like you got it handled already. --------------- EDIT: HyperHacker: Wouldn't a game with an expansion chip actually use the COP instruction? That's not really how expansion chips are communicated with. The real point is, that some programs may use BRK, COP, or STP. But they should be used rarely. If programs use them regularly, then a feature to select which opcodes to consider "rare" would indeed be nice. (If I remember correctly, LordTech's SNES C compiler used the COP instruction a lot due to his implementation choices.) (edited by neviksti on 07-06-05 03:06 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 16/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| AN XBAND THAT STILL HAS A GOOD BATTERY / SRAM HAS BEEN FOUND!! I can't believe it. I'm almost scared to fiddle with it right now. I tried for hours to dump the SRAM and kept failing. Reading $E0:8000-FFFF on the cartridge from a SNES program was just returning the same data as from $E0:0000-7FFF. Eventually I figured out the following: Using the following sequence: lda $FBC0F8 would change the memory map so all the SRAM is accessible. I don't understand the purpose of this, and it drove me nuts to figure out ... but we now have a copy of the X-Band Sram that should still have patches and other goodies in it!! Anyone that wants the SRAM, just let me know. I'll try to figure out what patches are on it and let you guys know --------- EDIT: Here are all the games that there are "stats" for on this X-Band, so were probably played at least once. Mortal Kombat 3 Killer Instinct WeaponLord Super Mario Kart Super Street Fighter II Zelda (test) Mortal Kombat II I've been starting it up with a random game (you need to have a game inserted since the X-Band doesn't have a CIC of its own). It would tell me at the beginning that the game might not be supported and I'd have to connect to check for a patch. However, with Mario Kart inserted, it doesn't say this. Hopefully this means the patch is still there (but it may mean nothing more than that it knows a patch exists). Kind of off topic, but check out what I found when searching for X-Band stuff: http://www.aep-emu.de/index.php?name=PNphpBB2&file=viewtopic&t=1593&postdays=0&postorder=asc&start=19 Someone posted about this thread on a German emulation site ... and took the time to translate the first post! It's both odd and flattering. (edited by neviksti on 07-08-05 06:01 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 17/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Overload and d4s, the files have been sent. If patches are still present in this device, then I shouldn't have to figure out as much about the hardware to get the first "connected game" running. However, I still haven't decided on the appropriate "short cut" / path to take now. I still need to learn more about the communication protocal, but I know enough now that it may be advantageous to make a small server and start testing things. However, I have no place I can connect up the X-Band and PC server to phone lines in close vicinity to each other. Does anyone have some suggestions on how to proceed from here? (It will probably take a long time to get the first connect to work, so at this point, giving someone an X-Band and trying to connect to each other for testing would be way too slow for debugging purposes. I need a way to have quick / easy control over both sides.) Overload: > I had a feeling this was a good one. And, thank you very much for pointing out that auction > Try it with your other X-band and see what happens? Apparently, until you connect to the server the first time, it doesn't really check about the cartridge/patches. Even on your emulator, it comments on the cartridge with the good SRAM. If instead I delete the SRAM and have the x-band software notice it is "corrupt" and fill out a new one (with a new character, etc), then the programs doesn't comment about the cartridge (not even after resetting it). d4s: > oh, just found one on yj. > it comes with a small card, too. > i assume these cards contain credits to use the service, yes? Yes, that is what the cards are for. I have never seen one in person though. I have also heard vague references to that being used as a "debug" port as well (some device with a ribbon cable and card like end was attached to the X-Band during operation). I do not know how likely the truth of that is though. I took apart the X-Band and the card receptor ... the card slot is nothing but some metal contacts. So the card must have an IC chip on it, so the X-Band can communicate with it. I know which register the X-Band checks to see if a card is inserted, or at least here is what my old notes say: $FBC108 bit 0 ... appears to say whether a card is inserted or not So you probably can track down the card communication software if you are curious. (edited by neviksti on 07-08-05 06:30 PM) |
|||
|
neviksti Goomba Level: 8 Posts: 18/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
Originally posted by HyperHacker There may be (and I intend to do that at some point), but I hesitate to start with that method. That is because I need to hack around stuff in the ROM to not look for the dial-tone and enable the "straight-connect" mode (or whatever it is called) since the lines are now free-floating. (Also, unlike the X-Band, I'm not sure if my PC modem supports that type of connection.) So if there are any problems, I won't know if it is with the data, or my hack (the settings I choose, the code I skip, etc). I fully expect the initial steps of the server to be quite difficult to debug and reverse-engineer. Once we surmount that hill though, it should get easier. And then I'll feel much more comfortable adventuring out into more complicated methods (albeit, methods that will ultimately be easier on me). |
|||
|
neviksti Goomba Level: 8 Posts: 19/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| Okay, I sent the SRAM to you as well. As for help with the code... I'm really getting lost in it. However, I have learned a great deal in the last few days. Enough, that we may be able to just skip looking at much more of the code. Here's what a packet looks like: -------------- "IBM's BiSync" like framing special characters: STX = start of text / data = $02 ETX = end of text / data = $03 DLE = data link escape = $10 packet looks like: STX ...data... DLE ETX Any DLE characters in the data itself are "padded" with an extra DLE. The code seems to ignore the STX character (doesn't even check it), but it does expect a character there. --------------- The data in that last packet is actually a crude AppleTalk like packet. (I've been told they used a form of ADSP, and have also seen interviews where people have re-iterated this as well.) this "inner" packet looks like: ADSP header ...data... crc The crc is a checksum of all the packet data before it, INCLUDING the STX character, and the ADSP header, and BEFORE padding the data with any DLE characters. ADSP header, $0D bytes long how the code treats the data - (word), (two dword entries - treated as a pair?), (word), ?flags? (byte) header data is in network byte order (most significant byte first) -------------------------------- As for the actual data itself, I've only looked at the server mode (not game mode) stuff so far. It looks like the server controls everything. It basically sends a command and parameters which the X-Band then executes and responds. I found the crc algorithm in the ROM, and it is easy to follow. As for the ADSP header stuff, and actual data handling ... I know where the "main controlling routine" is for this. But it calls many routines and I'm getting lost trying to understand everything. Googling for a bit-level explanation of the ADSP header has not turned up anything useful. I obviously haven't hit upon the correct keywords to search for. Anyone that can help me understand this header by looking for info ... it would really be appreciated. We're getting closer! ================ EDIT: Okay, this seems to explain what is in the ADSP header: http://www.lex-con.com/protocols/apple.htm Source Connection ID, (Send Sequence Number, Receive Sequence Number), Receive Window, Descriptor Here's some other pages: http://www.networksorcery.com/enp/protocol/adsp.htm (has the RFC) http://www.protocols.com/pbook/appletalk.htm#ADSP (not much better info, but explains what the receive window means) Still nothing that explains the bits (not even the RFC? Am I missing something obvious?). EDIT(2): Okay, found more: http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/netat/adsp.h I don't really understand it right now. I think I'll get some sleep and read it again tomorrow. (edited by neviksti on 07-10-05 06:45 AM) (edited by neviksti on 07-10-05 06:57 AM) |
|||
|
neviksti Goomba Level: 8 Posts: 20/25 EXP: 1510 For next: 677 Since: 06-09-05 Since last post: 36 days Last activity: 30 days |
| ||
| I do not have the tools to dump the Genesis data. But if anyone here does, I agree ... it should be done as soon as possible. From what I've heard, the protocal was the same for both systems (well, at least nearly the same). Therefore if I get the server working for the SNES version, it probably will work (maybe with minor modifications) for the Genesis version as well! Also, I should point out that I would still like more dumps of the SNES XBand SRAMs as well. We should collect as many patches as possible before all the batteries die. (edited by neviksti on 07-11-05 11:20 PM) |
| Pages: 1 2 |
| Acmlm's Board - I2 Archive - - Posts by neviksti |
