|
Post by elmer on Feb 9, 2019 6:04:28 GMT
Lemmings does a similar (slightly faster) check for a mouse, but it came out before 6-button pads existed, and it can't tell the difference. One thing that I should note is that both Lemmings and Princess Maker 2 ONLY check for a mouse in port #1, and not in any of the other ports.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 9, 2019 7:54:49 GMT
So... I managed to write code for the controller on mednafen (that build of yours with the large font, elmer) but I have no idea how to compile it back, running make doesn't include my .cpps in the compiler/linker and there's a large amount of files in there. Yep, that's the joy of makefiles for you, you can't just add new files and have them automatically built and linked in. You'll need to either add your code into an existing file, or add an include for your file within an existing file, or edit the makefiles. If you're really getting that deep into modifying mednafen, then Dave may be able to help you get in touch with mednafen's authors. Or you can post on the mednafen forum.
I did create a xe1analog.cpp and xe1analog.h and included them in input.cpp, and xe1analog.cpp got included in Makefile.am.in. I think I get the gist of the input code and it's quite simple really, but I can't compile the damn thing unless I'm using your script, which downloads a tar from the mednafen site and ignores what I wrote, and I also can't modify your script to NOT download from the site and still work. I'm not too big into the way the compiling process works here...
|
|
|
Post by dshadoff on Feb 9, 2019 8:27:17 GMT
So... I managed to write code for the controller on mednafen (that build of yours with the large font, elmer) but I have no idea how to compile it back, running make doesn't include my .cpps in the compiler/linker and there's a large amount of files in there. Yep, that's the joy of makefiles for you, you can't just add new files and have them automatically built and linked in. You'll need to either add your code into an existing file, or add an include for your file within an existing file, or edit the makefiles. If you're really getting that deep into modifying mednafen, then Dave may be able to help you get in touch with mednafen's authors. Or you can post on the mednafen forum. Well... maybe it's not so difficult. I'm not sure how much code you added that you felt a new file was required (since other files referencing it would still need to be modified for references), and you haven't mentioned which directory the file is located in, but I'll give you a top-down view of the build process: If you are using elmer's "build_mednafen" script, then it basically does a full rebuild every time, as it removes the build directory and runs a full configure. I find this build to be rather slow, since I would prefer not to force a rebuild of everything each time I want to compile/link a minimal set. Makefiles were created for exactly this situation - only the required files need to be built and linked (although once in a while, you still want that "full build" cleanliness). But you need to state the whole dependency chain in order to achieve this. One dependency chain is: "executable requires xxx object files and libraries". Another dependency chains is "object file requires source and headers". And so on. The make system realizes when one of the dependencies has been updated, and forces a recompile of the object; which in turn forces a relink of the executable. Many targets can make for a complex dependency tree. Mednafen does a 2-step build process, using an "automake" system, where a program helps build the complex tree of make dependencies, so the makefile is less complex to maintain. "configure" builds a bunch of "Makefile.in" files from "Makefile.am" sources. So, rather than adding the file to the "Makefile.in" files as both a compile dependency/target, and also as a link dependency, you simply add it to the relevant "Makefile.am" file, then run the configure process (which elmer's build does for you anyway). If you take a look at <some directory>/mednafen/src/Makfile.am, you'll see that all that's listed are the cpp files and the external libraries. The cpp files are organized according to category, and it sources "Makefile.am.inc" files from subordinate directories such as "pce". If your file is in one of these subordinate directories, put it in the relevant "Makefile.am.inc" file instead of the top-level one. It should basically be just that simple (but I can't make promises). Having said that, I have added a bunch of code for my own version, but I always added it to existing files. In the event that you leave your code in a separate file, successfully add this file to the Makefile system, and still have problems after rerunning configure and make, there's always mednafen people as elmer mentioned. I've had better success in the #mednafen channel (#mednafen on irc.freenode.net) than the forums. I just noticed that you said elmer's script re-downloads the tarball each time... it shouldn't be doing that unless you are running it with either "build_mednafen clean". Lemmings does a similar (slightly faster) check for a mouse, but it came out before 6-button pads existed, and it can't tell the difference. One thing that I should note is that both Lemmings and Princess Maker 2 ONLY check for a mouse in port #1, and not in any of the other ports. Interesting. I believe that all the mouse-using games are single-player, and I never thought about whether it was even possible to address 2 mice... it sounds like you'r saying it's possible, but simply that nobody does it. I guess that somebody can program 2-player "Missile Command" on the machine then. Dave
|
|
|
Post by elmer on Feb 9, 2019 8:28:03 GMT
I think I get the gist of the input code and it's quite simple really, but I can't compile the damn thing unless I'm using your script, which downloads a tar from the mednafen site and ignores what I wrote, and I also can't modify your script to NOT download from the site and still work. Really??? If the build script has already downloaded the source, it shouldn't download it again. Just let it download the file. If the "mednafen" source directory already exists, then the build script shouldn't try to unpack the source archive and so overwrite your changes (unless you pass it the "clean" parameter). I use that script all the time as I make my changes, even though it always does a full compile, and not an incremental compile. Now ... I'm less certain of what mednafen's build scripts will do if you make changes to Makefile.am ... that's up to you at that point.
|
|
|
Post by dshadoff on Feb 9, 2019 18:33:26 GMT
I was just looking at all the electrical signals for the joystick port - they're separately mapped directly on the Hu6280 - and something jumped out at me. The bits for this port are separately mapped out on the Hu6280 directly; the bottom 4 bits are controller values, bits 4 and 5 appear to be unused, and bit 6 is the bit that defines whether the machine is Japanese or American. ...But bit 7 mysteriously maps to a pin on the external connector. (Why ) Does anybody know what this bit represents (either from a code point of view, or any hardware that uses it) ? Here are the Hu6280 pins: D0 - pin 22 (controller) D1 - pin 24 (controller) D2 - pin 25 (controller) D3 - pin 26 (controller) D4 - pin 27 (NC) D5 - pin 28 (NC) D6 - pin 29 (0 = US; 1 = JPN) D7 - pin 30 (apparently pin B02 on external bus connector) See page 27 of the repair manual here: gamesx.com/wiki/lib/exe/fetch.php?media=schematics:turbografx-16_unit_service_manual_-_smtg16.pdf
|
|
|
Post by elmer on Feb 9, 2019 19:03:35 GMT
...But bit 7 mysteriously maps to a pin on the external connector. (Why ) Does anybody know what this bit represents (either from a code point of view, or any hardware that uses it) ? It's used to detect whether the IFU-30 Briefcase, SuperCD-ROM, etc is attached. Since the actual CD-ROM drive is separate from the IFU-30, you still don't know if you have the drive itself, but at-least you'll have the SCSI interface hardware to query if the drive is actually attached.
|
|
|
Post by dshadoff on Feb 9, 2019 23:29:06 GMT
Great, thanks ! It's a real disappointment that there are so many unconnected electrical lines on the $1000 port though.
6 outbound from CPU 2 inbound to CPU (plus 1 utterly wasted for region check, and 1 for CDROM check which probably could have been done more elegantly). Seems like a real lost opportunity.
Dave
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 10, 2019 5:43:27 GMT
Well... maybe it's not so difficult. I'm not sure how much code you added that you felt a new file was required (since other files referencing it would still need to be modified for references), and you haven't mentioned which directory the file is located in, but I'll give you a top-down view of the build process: If you are using elmer's "build_mednafen" script, then it basically does a full rebuild every time, as it removes the build directory and runs a full configure. I find this build to be rather slow, since I would prefer not to force a rebuild of everything each time I want to compile/link a minimal set. Makefiles were created for exactly this situation - only the required files need to be built and linked (although once in a while, you still want that "full build" cleanliness). But you need to state the whole dependency chain in order to achieve this. One dependency chain is: "executable requires xxx object files and libraries". Another dependency chains is "object file requires source and headers". And so on. The make system realizes when one of the dependencies has been updated, and forces a recompile of the object; which in turn forces a relink of the executable. Many targets can make for a complex dependency tree. Mednafen does a 2-step build process, using an "automake" system, where a program helps build the complex tree of make dependencies, so the makefile is less complex to maintain. "configure" builds a bunch of "Makefile.in" files from "Makefile.am" sources. So, rather than adding the file to the "Makefile.in" files as both a compile dependency/target, and also as a link dependency, you simply add it to the relevant "Makefile.am" file, then run the configure process (which elmer's build does for you anyway). If you take a look at <some directory>/mednafen/src/Makfile.am, you'll see that all that's listed are the cpp files and the external libraries. The cpp files are organized according to category, and it sources "Makefile.am.inc" files from subordinate directories such as "pce". If your file is in one of these subordinate directories, put it in the relevant "Makefile.am.inc" file instead of the top-level one. It should basically be just that simple (but I can't make promises). Having said that, I have added a bunch of code for my own version, but I always added it to existing files. In the event that you leave your code in a separate file, successfully add this file to the Makefile system, and still have problems after rerunning configure and make, there's always mednafen people as elmer mentioned. I've had better success in the #mednafen channel (#mednafen on irc.freenode.net) than the forums. I just noticed that you said elmer's script re-downloads the tarball each time... it shouldn't be doing that unless you are running it with either "build_mednafen clean". Almost there, thanks a lot for your help!
|
|
|
Post by elmer on Feb 10, 2019 23:30:01 GMT
Almost there, thanks a lot for your help! Cool stuff!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 11, 2019 20:30:47 GMT
OK the basic "protocol" is done but I'm having serious trouble figuring out how to format the emulator's 16-bit analog data since I have no idea if the XE-1A sends signed or unsigned stick axes, and some button presses end up in odd places (like pressing 'C' on the controller gets treated by the emulated machine as pressing 'A'), which suggests the 4 bit output of PCE_Input_Device::Read() is not a straightforward, linear bit by port map. I'm going to leave this aside for a bit and ask around IRC later.
Oh yeah and I forgot to put in the guide that the buttons are all pulled low just like a real PCE pad so '0' means "pressed" and vice versa.
|
|
|
Post by elmer on Feb 11, 2019 21:04:46 GMT
OK the basic "protocol" is done but I'm having serious trouble figuring out how to format the emulator's 16-bit analog data since I have no idea if the XE-1A sends signed or unsigned stick axes, and some button presses end up in odd places (like pressing 'C' on the controller gets treated by the emulated machine as pressing 'A'), which suggests the 4 bit output of PCE_Input_Device::Read() is not a straightforward, linear bit by port map. The information that you are looking for is all in the Forgotten Worlds disassembly that I posted on the previous page, if you take the time to understand what it is doing.
|
|
|
Post by dshadoff on Feb 11, 2019 21:20:00 GMT
You can also understand the format of the analog values range by writing a quick program to display the analog values on screen, ans manipulate the controls (assuming that you have one). If you don't have this joystick, I'd be happy to run tests using my own.
...Which reminds me, elmer you were going to send me a test to run against the 6-button Hori ?
Dave
|
|
|
Post by dshadoff on Feb 12, 2019 3:47:02 GMT
Elmer, if yo didn't start making the test program for the 6-button, maybe it isn't necessary. I just opened the Hori for a *completely* different reason, and while I was in there, I did some trace checks. Sure enough, one of the 74HC157's has 4 of the inputs (on the same gang-side) tied to ground.
So that should answer the question - it will appear the same as the Avenue 6 pad.
But I'd still be happy to test out analogue stuff.
|
|
|
Post by elmer on Feb 12, 2019 5:14:56 GMT
Elmer, if yo didn't start making the test program for the 6-button, maybe it isn't necessary. I just opened the Hori for a *completely* different reason, and while I was in there, I did some trace checks. Sure enough, one of the 74HC157's has 4 of the inputs (on the same gang-side) tied to ground. So that should answer the question - it will appear the same as the Avenue 6 pad. Thanks, that's really good to know! Sorry, I got distracted with this whole TED2 SDcard access sidetrack that we've started now. I found Emanuele Bettidi's Avenue Pad 6 schematic a few days ago, and that pretty-much confirmed that all 4 direction bits were going to be tied to zero in a 6-button pad. More importantly, I finally figured out how Princess Maker 2 is successfully distinguishing between a mouse and a 6-button joypad, and it has nothing at all to do with some difference between UP-n-DOWN being pressed instead of LEFT-n-RIGHT being pressed ... which is the little fantasy that my mind had taken me on. What it (and Lemmings) is doing is to poll the mouse super-fast (approx 20 times-per-frame), and then count just how many times the joypad/mouse returns a direction value with the top-nibble set to zero. As you reported in your mouse code, the maximum mouse movement delta that you're getting in 1/60s is a value of about $2D. By doing the mouse-polling 20 times as fast, when the mouse itself is idle as the game starts up, then the value of the top nibble is mostly going to be zero. So Princess Maker 2 just polls the mouse for a while, and counts how many times it see a zero value. If it sees 80% or more zeroes, then it knows that it is looking at a mouse instead of a 6-button joypad. I believe that I can think of a better test along the same lines ... but I'll leave that as an exercise for the reader until I've written the code and tested it out in practice.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 12, 2019 20:11:06 GMT
You can also understand the format of the analog values range by writing a quick program to display the analog values on screen, ans manipulate the controls (assuming that you have one). If you don't have this joystick, I'd be happy to run tests using my own. I might take on your offer later as for me, I have yet to find one for a good price. But I'm still looking for it (and mouse).
|
|