PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: elmer on January 26, 2015, 07:40:55 AM
-
I've done enough research now to have a good idea of what the PC-FX is capable of ... and it does have it's interesting aspects.
But looking around ... as far as I can see, nobody has really attempted to do any PC-FX development since the early 2000's.
Even Mednafen's 2007 spurt of interest is still based on the Japanese GCC work done in 2000/2001.
Is this machine totally dead?
If I spend the time trying to get a C compiler working for the PC-FX ... does anyone even care anymore?
-
I've done enough research now to have a good idea of what the PC-FX is capable of ... and it does have it's interesting aspects.
But looking around ... as far as I can see, nobody has really attempted to do any PC-FX development since the early 2000's.
Even Mednafen's 2007 spurt of interest is still based on the Japanese GCC work done in 2000/2001.
Is this machine totally dead?
If I spend the time trying to get a C compiler working for the PC-FX ... does anyone even care anymore?
It would be interesting to see if it is feasible to port over PCE games on it and possibly give them a graphical overhaul.. But I'm not sure how alike both platforms are and if it is too complicated might as well do pc ports.
-
I'd be all over some sexy PC-FX homebrew!!! :mrgreen:
But there's only a couple hundred thousand of these things in existence, compared to millions of PCE (or even more FEKA and SNERD shat), so your potential audience is definitely smaller. If excitement for PC-FX translations is any indication, you'd certainly garner some healthy interest; and if you made something gaijin friendly and fun, I bet you'd even convice a few guys that they need to buy a PC-FX.
-
Something neutopia like would be interesting. With some snazzy spell effects.
-
I don't know the state of PC-FX emulation... But if it is robust, that certainly helps the potential audience your work will reach.
I personally would love stuff for PC-FX, but I don't own one (yet!).
I do enjoy the soundtrack for Miraculum, though.
-
It would be interesting to see if it is feasible to port over PCE games on it and possibly give them a graphical overhaul.. But I'm not sure how alike both platforms are and if it is too complicated might as well do pc ports.
Well ... you've got the same HuC6270 video chip that the PCE uses in there ... but with double the memory (128KB instead of 64KB).
Then you've got a 2nd HuC6270 video chip in there, so it's like a SuperGrafx ... but with a total of 256KB instead of 128KB.
Then you've got the same sound chip in there (with a couple of enhancements).
And you've got 2MB of main memory, so it's like having an Arcade Card build in.
On top of that you've got the "KING" chip with another 4 background layers (including 1 with rotation/scaling) and it's own 1MB of memory.
Then, lastly, you've got the MPEG video-playback layer ... phew!
So PCE ports would mainly be case of recoding the logic from 6502 assembler into V810 assembler or C ... you could actually keep the basic graphics/flow nearly identical to the PCE, and then make whatever enhancements you want at you leisure.
The big question is ... who has the passion to do that, and with which games?
-
I'd be all over some sexy PC-FX homebrew!!! :mrgreen:
But would you, and the active developers here, really want to write some? :-k
It should be possible to create a USB-based Develo-like system that talks to a retail PC-FX through the 2nd joypad port.
The Saturn guys apparently have a GDB debugger running over the Action Replay Pro's PC comms port ... so the same thing should be possible with the PC-FX through the joypad port.
It should be much easier than the PCE's Develo-board since the PC-FX hardware natively supports output through the joypad port.
That would work on a modern PC and avoid the need for an expensive-and-rare PC-FX GA board.
The GCC work that the Japanese fans did in 2000/2001 was to re-implement V810 support in GCC based upon the existing V850 support.
The main CPU in the PC-FX is the NEC V810, and the V850 is it's big brother that was developed at approximately the same time ... they are about 90% similar (from a compiler's point of view).
The V850 is still sold for the embedded market and is currently supported by GCC ... although I'm not sure that there's much reason to go more recent than GCC 3.4.6 in order to get a solid C99 implementation.
But it's all a significant amount of work to develop and put together ... for a machine that sold less than 200,000 units and had so few games that people care about.
If excitement for PC-FX translations is any indication, you'd certainly garner some healthy interest; and if you made something gaijin friendly and fun, I bet you'd even convice a few guys that they need to buy a PC-FX.
I can certainly see the value in translations that run on the original platform hardware ... that's a work of love and honor for the original creations.
But do enough people really care about new stuff for the PC-FX that they want to drag developer's attention away from PCE homebrew or (sorry to offend you :wink:) Saturn homebrew?
-
Personally, I can't get super excited about PC-FX homebrew. If we had a lot more going on(& released) for the PCE, I'd feel more interested in it.
-
The dev tools and library are sort of non-existantish, for starts.
I would love to do PC-FX development.
I had a few ideas for games, but without a competent library to work with, it'd be a giant pain in the penis parts.'
I should really finish the PCFX Tome of Obey. Atlantean and making games kinda sucked up all my time.
-
On a console called the PC-FX, with a design that's intended to look just like a PC tower and everything, it would be neat to get a little collection of classic DOS games. I don't know how practical it would really be, but I would love to play a little Gorillas or Aldo's Adventure on PC-FX.
-
King's Quest.
-
But would you, and the active developers here, really want to write some? :-k
I have no coding or pixel art abilities, so my involvement is limited to beta testing and buying the game when it's done, and I'd be just as happy to do that for either PCE or PC-FX.
But do enough people really care about new stuff for the PC-FX that they want to drag developer's attention away from PCE homebrew or (sorry to offend you :wink:) Saturn homebrew?
I give zero f*cks about anything on the Saturn, but I wouldn't want anyone to abandon a PCE project just to do something else (anything else really, be it PC-FX, some other PCE game, etc.). If they're starting out and looking to do a project on either the PCE or the PC-FX, I'm behind either platform; the dev should pick the platform that interests them most, as game making on either is a work of passion and will never be a money maker.
-
On a console called the PC-FX, with a design that's intended to look just like a PC tower and everything, it would be neat to get a little collection of classic DOS games. I don't know how practical it would really be, but I would love to play a little Gorillas or Aldo's Adventure on PC-FX.
Sorry, but I have trouble understanding where you're coming from with this. I may be missing something ...
Why not just buy a RaspberryPI and run DOSBOX on it? You could even put it in a PC-FX case if you like.
I believe that WindyCity is considering importing some PC-FXs in his next batch, and I'd suspect that he could get you a junker-machine's case pretty cheap.
What is there about running those games on 1994 console that's appealing? Seriously, I'm not trying to dis you ... just to understand.
-
I'm having a hard time understanding your point. With your logic, nobody should make anything for the PCE either, as there are other platforms with better technical specs and larger audiences.
-
The dev tools and library are sort of non-existantish, for starts.
I would love to do PC-FX development.
I had a few ideas for games, but without a competent library to work with, it'd be a giant pain in the penis parts.'
I only just saw your old post on AtariAge ...
http://atariage.com/forums/topic/200921-pc-fx-homebrew/
Arkhan OFFLINE
Posted Wed Aug 1, 2012 9:14 AM
No. There's not much of anything.
None of the PCE developers are actively doing any PCFX development, and we're probably the best people for the job, all things considered.
I've got the official dev kit, and the unofficial library that sort-of works.
It's not worth the time investment and effort, so I passed on it to continue doing PCE instead.
As you're one of the most committed current PCE developers ... I guess that I'll probably just follow your lead and let the PC-FX rest in peace.
-
I give zero f*cks about anything on the Saturn, but I wouldn't want anyone to abandon a PCE project just to do something else (anything else really, be it PC-FX, some other PCE game, etc.). If they're starting out and looking to do a project on either the PCE or the PC-FX, I'm behind either platform; the dev should pick the platform that interests them most, as game making on either is a work of passion and will never be a money maker.
I think that's the wisest comment that I've heard in a while ... developing on these old consoles today is all about interest and passion ... and it looks like there's very little passion for the PC-FX.
Basically, I have both interest and passion for the PCE.
I played a friend's PCE-CD back in the day when it blew away everything else on the market, and I pre-ordered a SuperGrafx as soon as I heard that it was going to be released (I've still got both it and the receipt!).
The PC-FX has been a distraction because I love to learn how things work and what they're capable of ... but I don't have that personal connection to it that rises to that level of passion that you so wisely define as needed to sustain development through the boring/frustrating parts of a project.
I watched a complete Zeroigar playthrough on YouTube last night ... it looks like even Hudson didn't have much passion for the PC-FX.
The game looks like a cancelled SuperGrafx SCD project that was resurrected for the PC-FX and then had the level 1 boss recoded to use the PC-FX's transparency and scaling. Everything else is basically done within the SGX's limits and doesn't seem to use the PC-FX's extra capabilities.
Comparing it to Sapphire on the PCE ... well that was a game whose developers showed interest, passion and extreme capability!
-
I'm having a hard time understanding your point. With your logic, nobody should make anything for the PCE either, as there are other platforms with better technical specs and larger audiences.
I think that you are spot-on with your earlier comment ... it's all about having a passion for the subject.
That passion is a very, very personal thing.
If SamIAm wants to play DOS games on a PC-FX ... then he has every right to have that desire. I'm not dissing it ... I just don't share it.
What I do have is a passion for the PCE ... and although the PC-FX has been an interesting distraction, the PCE is the real reason that I'm here.
-
It's not that there is no passion, it's that there's no tool set for us to do anything, and making those is a royal punch in the dicktip.
-
He's confused his lack of passion for everyone else not giving a f*ck.
-
It's not that there is no passion, it's that there's no tool set for us to do anything, and making those is a royal punch in the dicktip.
May I ask exactly which parts of a toolchain you'd need?
Trying to get the Japanese GCC built is so annoying that it has become a bit of a personal challenge ... so I'm willing to give it another couple of days if that would make a difference (I hate the GNU build process!).
-
He's confused his lack of passion for everyone else not giving a f*ck.
Quite possibly.
My personal passion is for shmups ... and I just gave my impression of Zeroigar earlier.
If there are games on the PC-FX that you love ... then I'm sure that you'd be happy to see some new development for it.
-
It's not that there is no passion, it's that there's no tool set for us to do anything, and making those is a royal punch in the dicktip.
May I ask exactly which parts of a toolchain you'd need?
Trying to get the Japanese GCC built is so annoying that it has become a bit of a personal challenge ... so I'm willing to give it another couple of days if that would make a difference (I hate the GNU build process!).
A meaningful library to communicate with the hardware, in C, would be good. I think there was some stuff floating around awhile back but it was not anything horribly amazing and useful.
a compiler that can compile C code into runnable PCFX code is also important.
-
The mednafen author and trap15 had been working on a PC-FX toolchain but I don't know what happened to it. I had started to document it on the original obeybrew.com but that was one section I didn't rewrite when I put it back up after it was hacked. They had developed a library called liberis. I added a high-level abstraction layer to make it work more like HuC for those who were already familiar with PCE coding. This was all some time ago though. trap15 had multiple examples of simple applications running on the PC-FX, including an input test and some picture display code.
-
The mednafen author and trap15 had been working on a PC-FX toolchain but I don't know what happened to it. I had started to document it on the original obeybrew.com but that was one section I didn't rewrite when I put it back up after it was hacked. They had developed a library called liberis. I added a high-level abstraction layer to make it work more like HuC for those who were already familiar with PCE coding. This was all some time ago though. trap15 had multiple examples of simple applications running on the PC-FX, including an input test and some picture display code.
Thanks for the pointer. Looks like Alex is still doing some work on it ... the last commit was only a few months ago.
https://bitbucket.org/trap15/liberis
https://www.youtube.com/watch?v=Dw7-al4kz-I
Now I need to look at his docs and see what compiler he's using.
-
Could the PC-FX handle a game like Marvel Vs. Streetfighter and the like?
-
Yeah if that stuff gets somewhere more usable, I'd be interested.
-
If a home brew scene developed and started spitting out games for the PC-FX it would give me a reason to buy one. I want one just because it's a funky and cool looking system but then I look at the library and say WTF? I can't read Japanese and I don't like dating sims.
-
iirc, it is based on gcc 2.9.5.
-
Now I need to look at his docs and see what compiler he's using.
Well, the indications are that he's using GCC, so I'm guessing that it would be Mednafen's 2007 build based on the Japanese GCC 2.95.2 mods but with newlib added.
I wonder if they ever moved up to a more modern version of GCC?
Hahaha ... I just saw that OldRover already answered the question while I was writing this message! :D
GCC 2.95.x is a total swine to compile on modern machines ... it uses illegal language features that were removed from modern GCC 4.x compilers. :(
-
afaik, moving to a more modern version wasn't possible due to a lack of V810 support or summat.
-
afaik, moving to a more modern version wasn't possible due to a lack of V810 support or summat.
Neither GCC 2.95 nor any of the more modern versions actually natively support the NEC V810 ... but even the latest GCC versions support the NEC V850.
From what I can see the Japanese guys that hacked the V810 support into GCC 2.95 just based it on the existing V850 support. Remember ... when they did it, GCC 2.95 was the latest version of GCC.
It *may* be relatively straightforward to use the same methodology to add V810 support in a more-modern version of GCC.
I have now managed to build a V850 GCC 3.4.6 cross-compiler that seems to compile some test V850 code correctly.
The next step is to see if I can patch it to add the support for the V810.
It may not work, but it seems to be worth an attempt in order to get a more-modern toolchain.
-
Just adding my 2 cents but I've always dreamed of a GOT II and a Nexzr II on the FX, with tons of sfx, parallaxes and crazy FMW backgrounds.
-
If I made a PC-FX game, it would involve tentacles and tits, as opposed to shooterings.
-
Why not all of the above, ark? Steam Hearts' FX.
-
Here's a little PC-FX love for Valentine's Day ...
The liberis examples are now compiling (and running on Mednafen) with my V810-patched GCC 3.4.6 and binutils 2.18.
That's 6-years of compiler changes/improvements over the previous GCC 2.95.2.
Next up ... moving the V810-support forward another 8-years to GCC 4.7.4, with fully standards-compliant C99 support! :wink:
-
Awesome possum. :D
-
EDIT: Sorry, wrong thread...
-
Next up ... moving the V810-support forward another 8-years to GCC 4.7.4, with fully standards-compliant C99 support! :wink:
Hmmmm ... small hiccup with GCC 4.7.4 ... the V850 guys changed the system ABI in 2010, and so liberis won't run without modification. I'm still trying to decide how to handle that, and if there's any advantage in using the new ABI on the PC-FX's V810.
In the meantime, I have binutils 2.22 and GCC 4.5.4 compiling V810 code, and have the liberis demo programs running on mednafen's PC-FX eumulation with that combo.
Since GCC 4.5.4 was released in 2012, I'm still going to claim 12 years of improvements over the old Japanese GCC 2.95.2.
Early days, though, and lots more testing to do ... but good progress.
-
If this ever gets to where something usable exists with some libraries, count me in.
I'm not the type to sit and write system libraries, because I have too many game ideas/things to be working on instead.
It's a good thing Elmer exists, lol.
-
I'm not the type to sit and write system libraries, because I have too many game ideas/things to be working on instead.
We all have our strengths and weaknesses, interests and things that bore us.
Yes, I'm one of those people that are happy to work on tools, but I'm afraid that libraries bore the heck out of me ... I rather just get on with writing a game.
If this ever gets to where something usable exists with some libraries, count me in.
There is a modern C99 compiler, a set of low-level hardware and CD access libraries, and the tools to make a bootable PC-FX .bin/.cue CD image.
That's all that I need to write a game.
I want a good debugger, so I'll try to do something about that, too ... but higher level libraries ... not my thing, I'm afraid.
I'm trying to help open things up a bit to make it easier for anyone that comes after me ... just like the Japanese PC-FX guys did in 2000, and Alex Marshall has been doing for the last few years ... but I have no interest in providing an entire game engine library.
I'll just develop a game instead, and then release the source. Anyone that's interested will be able to pick it apart to grab what they like from a working example.
I have no firm timescale for that.
If someone that does like writing libraries wants what I've done so far, then they just have to ask.
-
Yeah, because of my current PCE, MSX, and PC investments, I don't really have a strong urge to dive into the lowest level possibly library possible to start getting somewhere. Maybe when a lot of this stuff wraps up, I could put time into writing useful libraries.
but as it stands now, it'd just be taking away from me working on stuff people want to play already. Nope.
-
I can normally write libraries from working examples, so I might be able to throw my hat into the ring here. I would just need a solid base to work from. Injecting new life into the PC-FX has long been a dream of mine, and trap15's work was as close as I have gotten to realizing that dream. Thus, if you are able to get a more modern build of gcc working (doesn't have to be cutting edge... that 2012 build is just fine), I can probably run with it.
-
I can normally write libraries from working examples, so I might be able to throw my hat into the ring here. I would just need a solid base to work from. Injecting new life into the PC-FX has long been a dream of mine, and trap15's work was as close as I have gotten to realizing that dream. Thus, if you are able to get a more modern build of gcc working (doesn't have to be cutting edge... that 2012 build is just fine), I can probably run with it.
And then comes some sort of game for such a niche system.
My tentacle-rape-pirate-shooter-dating sim is likely the best fit for the system.
The thing has a very specific library, so it needs very specific titles.
-
I can normally write libraries from working examples, so I might be able to throw my hat into the ring here. I would just need a solid base to work from. Injecting new life into the PC-FX has long been a dream of mine, and trap15's work was as close as I have gotten to realizing that dream. Thus, if you are able to get a more modern build of gcc working (doesn't have to be cutting edge... that 2012 build is just fine), I can probably run with it.
Thank you ... I'm sure that everyone would appreciate the time and effort that you'd be putting in to it.
You are welcome to the compiler any time that you wish ... or you can wait a bit longer until I verify more of the nooks-and-crannies.
There really isn't much improvement between GCC 4.5.4 and 4.7.4 when it comes to plain-old-C ... I'm disabling the whole-program-optimization in GCC 4.7.4 anyway, because it's been reported to be a bit problematic until they fixed things in 4.8 and 4.9.
I can see about doing my "starter" project on the PC-FX as well as the PCE.
It's going to look a little underwhelming on the PC-FX ... but I should be able to at least try to use most of the PC-FX's systems, even if it could be done without them.
I wish that I could find an artist as good as Black Tiger to enhance the original Amiga/Arcade graphics for both the PCE and PC-FX, since I suspect that the original artist is too busy with paying work these days ... but the game did get an award at the time, so it's not like they're actually bad.
The whole thing would hopefully still be able to serve as a programming example that you could use to help kick start some higher level libraries to go on top of liberis.
I hope that you'd be willing to release any library work under the same MIT license that Alex (trap15) is using for liberis.
-
Licenses have never concerned me very much. I am even quite content to release things under the WTFPL. I'll wait until you have a stable system though. Hopefully, it'll work in Windows... I couldn't give a rat's hairy ass about Linux, and I know I'm not alone there.
-
I'll wait until you have a stable system though. Hopefully, it'll work in Windows... I couldn't give a rat's hairy ass about Linux, and I know I'm not alone there.
Makes sense to wait a bit ... there's no rush. Yes, Windows is the primary target ... I can work in Linux, and love some of the tools, but I prefer Windows.
It needs msys2 (sort-of-linux-on-windows) in order to compile things like GCC and Mednafen ... but I really don't want you to have to run that in order to develop for the PCE or PC-FX.
-
I am not sure what you intend to put on PC-FX elmer, but please don't let it be an Amiga game.
There a 5 extra buttons on the controller.
-
Some new toys finally arrived this morning :)
I'm seeing 2 controllers there that don't look like they have 5 extra buttons!
Not all games work best with a joypad ... even if a joypad is still a "supported" option. :wink:
-
Some new toys finally arrived this morning :)
I'm seeing 2 controllers there that don't look like they have 5 extra buttons!
Not all games work best with a joypad ... even if a joypad is still a "supported" option. :wink:
Yes, thank you for pointing out the obvious fact that a mouse isn't a controller and that they don't function like one, lol.
The PC-FX is sorely lacking in action games, so I would've hoped you'd carry that torch instead of making a clicky game that we have plenty of already.
I doubt you'll be able to top a game like Pia Carrot, especially if you're going to redo an Amiga game on PC-FX, lol. It'd be lacking two things: Quality, and Titties.
I myself am against putting most Amiga eurowank nonsense on my beloved PC-FX, though.
Just out of curiosity, how well versed are you in the PC-FX's library? I ask only because you may want to get on that before you try filling voids or putting similar stuff on the thing. It's basically a niche machine that lacks in quality Japanese action games, but to me has a certain flavor to it that needs to be upheld.
-
Yes, thank you for pointing out the obvious fact that a mouse isn't a controller and that they don't function like one, lol.
You're wrong there ... a mouse is a controller ... and so is a joypad ... there's a difference between the generic "controller" term and the specific case. If you ever develop a title on a platform that has strict manufacturer's standards (including terminology) ... then you'll learn to tell the difference.
Yes, I know what you meant ... but your language was imprecise, and that gave me a loophole ... so I took advantage of it. :wink:
The PC-FX is sorely lacking in action games, so I would've hoped you'd carry that torch instead of making a clicky game that we have plenty of already.
Since you obviously don't have a clue of what I'm thinking of doing ... is there some reason that you're being so negative?
-
You're wrong there ... a mouse is a controller ... and so is a joypad ... there's a difference between the generic "controller" term and the specific case. If you ever develop a title on a platform that has strict manufacturer's standards (including terminology) ... then you'll learn to tell the difference.
Yes, I know what you meant ... but your language was imprecise, and that gave me a loophole ... so I took advantage of it. :wink:
Yes, I know the difference. However, we're talking about consoles where the typical vernacular dictates that controller = standard thing that came with the machine, and mouse = thing you bought extra that isn't a controller because it doesn't work with majority of the library.
Your already typical semantics nonsense (in such a small post count), and bullshit penis waving aside, yes, you know what I meant, so, the entire thing was rather pointless.
I personally really wish you would cut with the borderline useless condescending, know-it-all crap and just get to the point (If you have one). ](*,) It's obvious you know stuff, but I'm not sure why you choose to deliver it in such a retarded manner.
Since you obviously don't have a clue of what I'm thinking of doing ... is there some reason that you're being so negative?
First, I'm not being negative. You're new here and don't really know the crowd too good yet. Try participating in threads besides rolling around in the technical ones, and you might realize this shit, instead of just being a bit of a knob and rubbing certain people the wrong way.
I am stating facts (PC-FX lacks action games, Amiga games are mostly beyond shit attempts at mimicking Japanese games), and speculating based off of your Amiga statement from before/your current mouse-jabbery, that you're probably not making an action game.
This was your cue to chime in a little and elaborate. You may have picked up on this if you dialed back the condescension-o-meter a bit and would stop being so quick to assert your prior experience that I really couldn't give two f*cks about at this point.
This is all curiosity because
1) I am interested.
2) The PC-FX is my second favorite machine, next to the PCE.
This is why I asked how well versed you are in the library. Are you aware of what voids need filled, and how they might be filled?
You don't really participate in the forum outside of technical crap, so I honestly have no clue what kind of experience you have with either NEC machine in terms of actual gameplay.
I come from the "try to put something on the machine that isn't there already" walk of life, instead of the "put some trite bullshit on the machine just because I felt like it" one.
My personal stance is: If you don't really have a strong passion for a platform and the current library, you really probably shouldn't be making a game for that platform until you fix this issue.
Anyway, I am Arkhan. I don't sugar coat anything. You've probably noticed this by now.
-
Arkhan and his acerbic words don't speak for me, and I've little doubt others here feel the same way.
Just do whatever you want or is is enjoyable, even if "enjoyable" turns out to be a simple Tyrian port. ;)
-
Make games you enjoy and want to work on. If it's fun, I'll gladly buy it and play it, giving zero f*cks that there's other similar games.
I come from the "try to put something on the machine that isn't there already" walk of life, instead of the "put some trite bullshit on the machine just because I felt like it" one.
Bitch, please. I enjoy Insanity, Pyramid Plunder, and Atlantean quite a bit, but you're batshit crazy if you think they're filling a void and unlike several other game in the PCE's library.
-
I would have no problem making action games for the PC-FX... platformers and shooters especially.
-
Even with only two players, Bomberman FX would be le tits. :mrgreen:
-
Bitch, please. I enjoy Insanity, Pyramid Plunder, and Atlantean quite a bit, but you're batshit crazy if you think they're filling a void and unlike several other game in the PCE's library.
The goal for them was "more pre-crash games besides Galaga and Space Invaders".
my main point is Amiga = probably not a good idea.
Especially if we're talking about like, Turrican FX.
Even with only two players, Bomberman FX would be le tits. :mrgreen:
Yeah. Anything y'know, NEC/Hudson-y
-
Arkhan and his acerbic words don't speak for me, and I've little doubt others here feel the same way.
Just do whatever you want or is is enjoyable, even if "enjoyable" turns out to be a simple Tyrian port. ;)
Thank you.
And "thank you", too for mentioning Tyrian ... I'm not sure if anyone has ever pointed that game out to me before.
I'm going to enjoy playing it, and the fact that it is open-source does make it a potential project, some day. :wink:
Make games you enjoy and want to work on. If it's fun, I'll gladly buy it and play it, giving zero f*cks that there's other similar games.
AFAIK there's nothing quite like it on the PC-FX.
The game's prequel was available on the PCE, but the 2nd game was never released on the PCE or PC-FX.
The problem is that unless I can get some art support ... it's not going to take advantage of the PCE's extra colors, and may look a bit bland.
When the game is actually running, and an artist can see that they wouldn't be wasting their time, then perhaps someone will be willing to give it a bit of "love".
I'm thinking that a PCE/PC-FX dual-boot CD would be nice ... either as a free downloadable, or as a pressed CD if the community shows enough interest in that.
The big caveat is ... it's not the world's deepest game. It was a bit of a gimmick, even at the time that it came out.
OTOH, it's simplicity is precisely what makes it a great 'starter' project.
I would have no problem making action games for the PC-FX... platformers and shooters especially.
I would love to do a good platformer or shooter on the PC-FX ... something to show that it could do more than was seen in it's game catalogue at the time.
There's a 1996 arcade game that comes to mind ... but it's a bit too complex to be a good 1st project.
Even with only two players, Bomberman FX would be le tits. :mrgreen:
Hudson have done such a great job with all the Bomberman games that there's absolutely nothing that I can think of to do to enhance one of their games for the PC-FX.
I learned a long time ago that I'm not a very good game designer ... programming is what I'm much better at.
-
I personally really wish you would cut with the borderline useless condescending, know-it-all crap and just get to the point (If you have one). ](*,) It's obvious you know stuff, but I'm not sure why you choose to deliver it in such a retarded manner.
I think that that could be one of the most open and honest posts that I've seen from you, so I'll respond in kind.
BTW ... we're very different people, and we communicate in different ways, and so, "yes", we've been banging heads.
Just think of it like you're talking to your granddad ... I use language in a different way from you, and if that causes you trouble, please just write it off as comments from an old fart that you can ignore.
If you look at my posts objectively, I hope that you'd find that I try to get to the point, and that I try to be encouraging and helpful ... that's my intent. I'd be sorry if I'm failing at that.
Your sig line says ...
If you're not ready to defend your claims, don't post em
I am prepared to defend anything that I've said. And I hope that I've been quick to apologize and retract when I've been shown to be wrong.
From my POV ... if you think that I've been a dickhead to you, it's precisely been because I've been challenging you to defend your claims, and perhaps to distinguish "fact" from "personal opinion".
This was your cue to chime in a little and elaborate. You may have picked up on this if you dialed back the condescension-o-meter a bit and would stop being so quick to assert your prior experience that I really couldn't give two f*cks about at this point.
Of course I knew it. I deliberately chose not to elaborate ... primarily because of your negativity.
I only keep on asserting my "prior experience" ... because you keep on calling things facts that my "prior experience" tells me are really opinions.
I am stating facts (PC-FX lacks action games, Amiga games are mostly beyond shit attempts at mimicking Japanese games), and speculating based off of your Amiga statement from before/your current mouse-jabbery, that you're probably not making an action game.
Actually, it's a Japanese arcade game (an action one).
Not a stunningly great game from the POV of history ... but popular enough in it's day.
Since it didn't get a SNES port until 1994 ... I feel that it's fair to take advantage of the Arcade Card if I want to, and perhaps do both a PCE and a PC-FX version with the same graphics.
But it won't be a good example of what the PC-FX can do ... it's way too simple.
As I stated ... it's a "starter" project to get some code written on both machines, and to provide some working code that can be ripped-apart to help produce libraries ... so that when someone has written them for you, you can do whatever game you like that you think fits the platform better.
This is all curiosity because
1) I am interested.
2) The PC-FX is my second favorite machine, next to the PCE.
This is why I asked how well versed you are in the library. Are you aware of what voids need filled, and how they might be filled?
You don't really participate in the forum outside of technical crap, so I honestly have no clue what kind of experience you have with either NEC machine in terms of actual gameplay.
I come from the "try to put something on the machine that isn't there already" walk of life, instead of the "put some trite bullshit on the machine just because I felt like it" one.
My personal stance is: If you don't really have a strong passion for a platform and the current library, you really probably shouldn't be making a game for that platform until you fix this issue.
And this is something that I totally respect ... but that I don't necessarily agree with.
I think that the PC-FX got a crappy deal in it's lifetime. I've become interested enough in it that I'd like to work to help open it up a bit more so that people like you can create what you feel is right for the platform.
I'd personally like to put something on it that stretches it a bit more than the dating sims that were done during it's lifetime.
Unfortunately, the "starter" project won't be it ... that particular goal will have to wait until later. But I have to start somewhere, or nothing will get done.
Do I care for it's legacy catalogue? ... nope, not at all ... and judging by it's original sales and current popularity ... I'm not the only one with that opinion.
I believe that it was caught in a crappy business situation at the time of it's release ... leading to very few "good" games, and I think that Hudson's poor little PC-FX deserved better.
-
BTW ... we're very different people, ..etc.etc.
Your tone sometimes comes off as condescending and "quick to assert knowledge", to me at least, and tends to be a bit dismissive of others statements/experiences.
If you're openly admitting you're a goony old fart that talks funny, this makes it different. You'll have to understand, in "old computer/console land", a lot of people doing that sort of tone aren't doing it because they're old/goony and just trying to be involved and helpful. They're doing it because they're literally full of shit, and trying to deflect/cover up/annoy/put everyone around them down
From my POV ... if you think that I've been a dickhead to you, it's precisely been because I've been challenging you to defend your claims, and perhaps to distinguish "fact" from "personal opinion".
You haven't really been challenging, though. lol. Mostly just agitating because you see opportunity to.
I only keep on asserting my "prior experience" ... because you keep on calling things facts that my "prior experience" tells me are really opinions.
I don't think I've called anything a fact other than Amiga having shit wannabe Japanese arcade games. I don't think anyone is really going to refute that, though. And the thing about controller vernacular, which are semantics not worth getting overly technical about because you've already admitted you know exactly what I meant.
The rest (here and in SoundLand) was obviously opinion and I don't think was ever stated as anything different...I think maybe you took them as fact-statements because you're approaching things from the "I'm seasoned and know more stuff" avenue, and want to assert your stuff.
Like that attempt to engage in "battle story penis waving" where you finally discovered I'm *not* an old fogey and couldn't care less about that crap. ;)
Anyway:
As I stated ... it's a "starter" project to get some code written on both machines, and to provide some working code that can be ripped-apart to help produce libraries ... so that when someone has written them for you, you can do whatever game you like that you think fits the platform better.
What is it? Aerofighters? King of Monsters 2?
King of Monsters 2 would be the coolest option and would make the most use of the buttons. I can't think of any other SNES arcade ports right now.
I'd personally like to put something on it that stretches it a bit more than the dating sims that were done during it's lifetime.
Unfortunately, the "starter" project won't be it ... that particular goal will have to wait until later. But I have to start somewhere, or nothing will get done.
Do I care for it's legacy catalogue? ... nope, not at all ... and judging by it's original sales and current popularity ... I'm not the only one with that opinion.
I believe that it was caught in a crappy business situation at the time of it's release ... leading to very few "good" games, and I think that Hudson's poor little PC-FX deserved better.
The library got hosed. There's a ton of voids to fill in the flavor of the original library. (Whereas the PCE library is basically a powerhouse and has a complete library, minus beat em ups but nobody feels like drawing all that art).
My serious, actual gripe is mostly stemming from your mention of Amiga. You made a comment that hinted at putting an Amiga game on the thing. When you've got the keys to the kingdom, and the obvious knowledge to do something, I can't imagine why *anyone* would settle on an Amiga game.
But it sounds like you AREN'T making an Amiga game on PC-FX (thank f*ck for that), so, whatever. You could make a tic-tac-toe/checkers combo game, and it'd probably be better than an Amiga port.
but, didn't you just get into PC-FX like 2 months ago, though? I don't think this is enough time to really settle on an opinion on the library. What all have you played. There *are* more than just dating sims. The non dating sim games are all actually pretty damn good. Minus Ruruli Ra Rura, which is pretty autistic. It's cute and almost works. It just kinda forgot to finish itself.
-
I think a decent magical chaise / Ys crossover is in order. You would have to fly around the field poking enemies in the arsehole with your broom. Also a decent Amiga port would go down well.
-
Also a decent Amiga port would go down well.
A decent Amiga port of what? one of the good adventure/RPGs? I mean we got Return to Zork going on it. There are some other point/clicks that would be fun, but, that's not what we need on the thing since the stuff is *already playable* somewhere.
The action stuff mostly has some severe cases of the 'tisms. Leander was the one that was almost a success. and Lionheart.
but, they still lack in the "this is awesome" department.
Valis 5? That could be a thing.
-
I meant porting super magical ys chaise FX to Amiga!
Also you are I fear correct in your assertion that the Amiga lacks awesomeness.
Also sorry didn't mean to derail the thread too much!
-
I'm thinking that a PCE/PC-FX dual-boot CD would be nice ... either as a free downloadable, or as a pressed CD if the community shows enough interest in that.
I'm sure a pressed disc would be doable. If you don't care about getting paid at all, it doesn't take many sales to cover pressing costs.
Valis 5? That could be a thing.
Valis X? f*ck yeah!
-
I'm thinking that a PCE/PC-FX dual-boot CD would be nice ... either as a free downloadable, or as a pressed CD if the community shows enough interest in that.
I'm sure a pressed disc would be doable. If you don't care about getting paid at all, it doesn't take many sales to cover pressing costs.
Valis 5? That could be a thing.
Valis X? f*ck yeah!
Valis EX
With an appropriate logo for, yknow,
sex
-
I'm sure a pressed disc would be doable. If you don't care about getting paid at all, it doesn't take many sales to cover pressing costs.
No, I absolutely do NOT want any money coming anywhere near me on this! It wouldn't be fair to the other guys that worked on the project.
The original artist was a huge PCE fan ... so I choose to believe that he'd have no problem with me using his stuff for this, but having any money involved makes it all ... ugly.
What is it? Aerofighters? King of Monsters 2?
Nope, neither of those.
But I'll give you all a clue, and see if you can recognize it ...
-
Operation Thunderbolt
https://www.youtube.com/watch?v=tC48sweGNv8
-
Thank balls. When I hear Amiga + mouse use, my mind goes to depressing places. I forgot they even *put* that game on there. I know Operation Wolf and Cabal were.
5$ says the PC-FX can make a better version than the Amiga one.
Any plans to give the game music during the levels? That kind of always sucked that it didn't have any.
what made you settle on this game?
EDIT:
Also, it costs about 1000 bucks to get a game pressed in the US, with a color manual of some variety.
You *might* run into some dicey situations with it though, as they'll have you sign forms stating that you are authorized to make use of the IP on the disc (sound, art, code).
Taito is still around. They might pee themselves. It's not likely they give any flying f*cks about PC-FX, but who knows.
So... you might want to avoid hassle and call the game like, Thunder Mission or something, and change the art even slightly.
as for "money floating around", you can most likely sell the thing to the first 1000$/30$ people (assuming 1000 bucks, and 30$ a pop), to cover the pressing costs, and then just give them out for free + shipping costs.
Though, we are talking PC-FX here, so you might only sell 30 of the damn things.
In all honesty, since this is the case, and the PC-FX is better at CD-Rs, you might have better luck just making them yourself so you aren't sitting on 470ish copies of a PC-FX game.
-
Operation Thunderbolt
Haha ... you've got a good eye. The SNES version uses a totally different intro to the arcade, so you've got a good memory.
Any plans to give the game music during the levels? That kind of always sucked that it didn't have any.
No idea. From what I remember, there was only one tune ... so it'd get boring really quickly.
what made you settle on this game?
Errr ... I wrote it ... and it's a simple game.
But still, the 3D sections are going to be ... "interesting" ... to try to do on sprite-based machine. :-k
You *might* run into some dicey situations with it though, as they'll have you sign forms stating that you are authorized to make use of the IP on the disc (sound, art, code).
"Operation Thunderbolt" was the military codename for the Israeli raid on the Entebbe airport. I'm not sure if Taito ever managed to get a trademark on it. But still ... that's easy to change.
None of the code, art or sound comes from Taito. Back then, all you got was an arcade cabinet that was set on freeplay, and the rights to use Taito's name/logo.
However ... changing the art would certainly help prevent any possible issues ... but would require an artist.
Though, we are talking PC-FX here, so you might only sell 30 of the damn things.
Remember ... I'm talking PCE/PC-FX dual-boot. Larger audience.
-
Ah, right. Dual boot.
Well, still, 30ish people will cover pressing fees. (I think it took 36 to break even for us).
and then you can just cut loose and hand them out for shipping if it makes you feel dirty making money.
as for tunes, if you're going CD, there's always just putting in 80s action movie themes (Rambo, Commando, etc.), or some sort of almost, but not quite renditions of them.
Anyway, I'm glad you finally came out with "stuff you worked on". Which machine were you on for this game? I played the Amiga one maybe a few times (I grew up with an Amiga and thought most of the games were pretty shit compared to the SNES/Genesis/TG/NES that were 30 feet away), and a lot on the SNES.
I don't think the 3D sections will really be too difficult to do on the PC-FX, considering the horsepower and hardware capabilities.
That sort of effect was done on 8-bit machines (SMS, MSX, NES) in a pretty acceptable manner, using sprite/tile based hardware.
IIRC, alot of the 3D effect is optical illusions, isn't it? static BG/ground (The SNES ground has some animation), animated scaling trees/etc a'la Outrun/Space Harrier, and then a bunch of idiot terrorists with weaponry bouncing around like jackasses?
-
Well, still, 30ish people will cover pressing fees. (I think it took 36 to break even for us).
Thanks for all the info about the costings ... that's very good stuff to know.
and then you can just cut loose and hand them out for shipping if it makes you feel dirty making money.
I've got no problem at all with money ... just not in this particular case.
Which machine were you on for this game?
Errr ... the machine that you hate! :wink:
I don't think the 3D sections will really be too difficult to do on the PC-FX, considering the horsepower and hardware capabilities.
I hope not ... it's just a question of sprites-per-line with the overlapping 3D objects ... or coming up with a work-around that actually still looks good.
If you look at the SNES video, they put all their background 3D scaling-objects into characters, and everything moves on character boundaries. It looks pretty crappy, to my eye, when compared to the Amiga's pixel-boundary blitting.
-
Yeah. You can get a smoother visual on the PC-FX than on the SNES.
See: Nirgends
you're not dealing with 360ish degree movement, so you should be all set.
-
I don't think I've called anything a fact other than Amiga having shit wannabe Japanese arcade games. I don't think anyone is really going to refute that, though.
Well ... back in the late 80's and early 90's ... every computer/console was judged by the quality of it's arcade ports.
It really didn't matter whether they were Japanese or American arcade games, just that they were arcade games. Gamers wanted to have the "arcade experience" at home ... and that was why the Neo Geo AES was released.
Now it was definitely harder to find good games from the American arcade companies ... so I can understand why you think that everyone wanted to do Japanese games, but it really wasn't about them being Japanese, or even about the quality of the original games ... it was the "arcade" part of it.
As an example ... here are a couple of comparison shots from the arcade and home versions of Op Thunderbolt. Can anyone honestly say that the home version looks like a "shit wannabe" compared to the arcade?
I think that Black Tiger's stunning work on Golden Axe shows that it's the quality of the artist and their team that makes the difference ... not whether it was a Japanese game, or even a Japanese arcade game.
-
I was commenting more on the gameplay itself than the visuals. The games might look nice, but often play pretty crappy. Especially when it's a multibutton game and you're stuck with a one button joystick or some meth-induced control scheme.
Japan just happened to be the ones with all of the powerhouse games that played very well, which is why I mentioned Japanese arcade games specifically.
So often, instead of the western world doing something they were good at, they kind of just tried to (poorly) mimic the Japanese stuff. Most memorable games on Amiga are originals, or games that originated here.
You'll find exceptions to the rule, but they're generally buried in piles of turds in the form of horrible ports, or crappy games done in the style of Japanese game.
Off the top of my head, on Amiga specifically, I can think of...
Rodland, Op Thunderbolt, Rainbow Islands, and maybe R-Type as being alright on the Amiga.
but then you've got messes like Street Fighter 2, Sidearms, Super C, and they also somehow ballsed up the port of Bonk (not an arcade game, but still another example of Japanese mimickry).
I'll never understand how they pulled that one off.
Like I said, I grew up with the Amiga, and was rarely impressed by the games when compared to SNES/TG/Genesis that I had sitting right nearby.
I never understood why some of the games turned out so bad. Maybe the teams porting it sucked at the games and couldn't recreate the gameplay?
It's an interesting thing really. You have all the audio/visuals (sometimes the audio goes a little too eurowank for me), but then the gameplay caves in on itself.
Another hilarious example, non-Amiga, is Green Beret on MSX. Everyone responsible for that one needs to never touch a computer, ever again.
-
Half the ports I've seen on Amiga make me wonder if the devs had actually ever even seen or played the source material. Most of the stuff just comes across as crap.
-
I was commenting more on the gameplay itself than the visuals. The games might look nice, but often play pretty crappy. Especially when it's a multibutton game and you're stuck with a one button joystick or some meth-induced control scheme.
Japan just happened to be the ones with all of the powerhouse games that played very well, which is why I mentioned Japanese arcade games specifically.
So often, instead of the western world doing something they were good at, they kind of just tried to (poorly) mimic the Japanese stuff. Most memorable games on Amiga are originals, or games that originated here.
You'll find exceptions to the rule, but they're generally buried in piles of turds in the form of horrible ports, or crappy games done in the style of Japanese game.
I can only agree with you ... taking arcade games with their powerful hardware, multiple buttons, and whatever other gimmicks that they could entice people with ... and then porting them to the very-limited home computers of the day ... was something that was never going to end up well.
But people seemed to want them, and they certainly bought them ... and so companies kept on making them.
I totally agree that the best games of the time were the originals that were specifically designed for the machines that they were released on.
Off the top of my head, on Amiga specifically, I can think of...
Rodland, Op Thunderbolt, Rainbow Islands, and maybe R-Type as being alright on the Amiga.
but then you've got messes like Street Fighter 2, Sidearms, Super C, and they also somehow ballsed up the port of Bonk (not an arcade game, but still another example of Japanese mimickry).
I'll never understand how they pulled that one off.
There were plenty of low-quality bucket-shop development companies.
And you don't need to be polite about Thunderbolt ... even though Robert did a great job on the graphics ... it was still a simple whack-a-mole gimmick game with little depth.
Like I said, I grew up with the Amiga, and was rarely impressed by the games when compared to SNES/TG/Genesis that I had sitting right nearby.
I never understood why some of the games turned out so bad. Maybe the teams porting it sucked at the games and couldn't recreate the gameplay?
It's an interesting thing really. You have all the audio/visuals (sometimes the audio goes a little too eurowank for me), but then the gameplay caves in on itself.
It's always been tough to find good programmers.
But also ... don't forget that the Amiga came out in 1985, 2 years before the PCE, and 4 years before the Genesis.
Hardware changed a lot during those years, and so did the amount of consumers/money in the business ... which lead to longer development schedules and sometimes larger teams ... which in turn allowed for the possibility of better games overall.
Another hilarious example, non-Amiga, is Green Beret on MSX. Everyone responsible for that one needs to never touch a computer, ever again.
Hahaha ... I just looked at that one on YouTube ... what a disaster.
I thought that you were going to criticise the other home computer versions, which I have little love for, but the MSX one took "awful" to a whole new level.
Stuff like that was one of the reasons that MSX totally failed in the West.
I remember MSX1 machines being clearanced for about $50 ... and they still didn't seem worth it.
I liked the following quote ...
From an interview at MSX Games Box, Konami UK's old PR-manager Dennis Henings:
Q: What did Konami Japan say when they saw the MSX version of Green Beret developed by Konami UK?
A: $%£&**(())++~~ ( or their equivalent) This was much the same as I did!
Half the ports I've seen on Amiga make me wonder if the devs had actually ever even seen or played the source material. Most of the stuff just comes across as crap.
You got no design docs, no source code, no graphics, and no sound.
You were lucky if you got an arcade cabinet set on "freeplay".
Some of the cheaper developers would just video someone playing the game, and "maybe" rent one for a few weeks.
Then 2 guys would get 4 months to recreate it ... from scratch. Let's be generous and say 6 months if you did 2 versions (like the ST and Amiga).
Not a recipe for doing brilliant work ... particularly if the job had been farmed out to one of the porting shops that would hire a couple of teenagers fresh out of school to do the work for cheap.
-
well that explains a lot. So you had people who were either not skilled at games, or simply barely experienced in the game at all, trying to recreate the whole thing. That's a bit mental.
At least with things like the MSX in Japan, you had Konami cranking out home versions of games. I guess that's what really separates the quality of games from here and there back then.
The Amiga for one, should have been able to produce very tightly put together arcade games. For some reason, it did not have many. Many of them looked great but played like balls.
Even some of the classics, like Shadow of the Beast, are admittedly a bit retarded. I prefer the PCE version of that game, because simple mechanical errors are fixed.
And, Operation Thunderbolt on Amiga is fine. It's as good as any other home version of the game, and plays as good as you'd really expect from a version that lacks the cool, gun controller.
We used to play that, Operation Wolf, and Revolution X (lol) without the cool guns, and they were all fun anyway.
-
well that explains a lot. So you had people who were either not skilled at games, or simply barely experienced in the game at all, trying to recreate the whole thing. That's a bit mental.
At least with things like the MSX in Japan, you had Konami cranking out home versions of games. I guess that's what really separates the quality of games from here and there back then.
There is a really wonderful short book written by a developer:
http://bizzley.com (http://bizzley.com/)
It's Behind You — Bob Pape — R-Type (ZX Spectrum)
It is such a great read...it really captures so many different aspects of the UK computer scene that I was curious about.
The entire account strikes me as genuine and sincere...no sensationalism, no exaggerated drama, no manufactured dilemmas.
Anyway, it corroborates everything elmer said. :)
-
Lol, I know some of the music in games was just written for whatever reason without the musician knowing what the game was or what was going on.
So, stuff like LED storm? Dude was just jamming out and went oh here, I guess you can put this in the game now. What is it!
I notice a lot of game shops back in the 80s and even early 90s were basically just kind of winging it.
That's what separates stuff like Valis from Commander Keen.
Whole company of people vs. Dudes Who stole their work computers to work on the weekends.
I'll have to check that book out. I like hearing about how stupid things were.
-
There is a really wonderful short book written by a developer:
http://bizzley.com (http://bizzley.com/)
It's Behind You — Bob Pape — R-Type (ZX Spectrum)
Thank you ... I hadn't seen that before. What a fun read! :)
At least with things like the MSX in Japan, you had Konami cranking out home versions of games. I guess that's what really separates the quality of games from here and there back then.
The Japanese arcade companies had a huge incentive for producing decent ports in their own home-market ... producing crap versions would have led to a terrible loss of face ... and no Japanese exec would have tolerated that.
For territories outside Japan, where nobody at home would hear about it ... AFAIK, they couldn't care less. They got their licensing fees, and didn't seem to be interested in trying to impose any quality-control.
-
There is a really wonderful short book written by a developer:
http://bizzley.com (http://bizzley.com/)
It's Behind You — Bob Pape — R-Type (ZX Spectrum)
It is such a great read...it really captures so many different aspects of the UK computer scene that I was curious about.
If anyone is interested in the history of those times, then Chris Wilkins' "History of Ocean" tells the tale of one particular company ... but since it's more of a history-through-interviews, it's not as good of a story-read as Bob's book.
http://www.fusionretrobooks.com/The-History-of-Ocean-Software-p/ocean.htm
There used to be a cheap PDF version, but I can't find it anymore.
-
From what I remember reading, that Green Beret debacle was the last time Konami let round eye touch their software for awhile.
-
From what I remember reading, that Green Beret debacle was the last time Konami let round eye touch their software for awhile.
Hahahaha ... I can totally believe it after that seeing that mess!
The "History of Ocean" mentions that the C64 version Thunderbolt was another disastrous outside-job, and that they canned the developer and had to rewrite it from scratch internally in 3 1/2 weeks.
In the early days, that kind of screw-up was unfortunately not as uncommon as it should have been.
-
I'd like to meet the crew responsible for Double Dragon on C64. I waited about 10 minutes for that trainwreck to load.
Only to go "....." *click* and walk back over to play Sega.
-
I'd like to meet the crew responsible for Double Dragon on C64. I waited about 10 minutes for that trainwreck to load.
I just looked on wikipedia ... Binary Designs Ltd ... hahahaha ... yep, they didn't have a great reputation.
-
I'd probably be able to take C64/Amiga game libraries more seriously if there weren't so many shitty ports floating around.
I don't know how Sidearms made it out the door on *either* machine.
-
I'd probably be able to take C64/Amiga game libraries more seriously if there weren't so many shitty ports floating around.
I don't know how Sidearms made it out the door on *either* machine.
Hahaha ... now you're talking about Probe Software (Fergus McGovern) ... another errrr ... not-very-good developer ... but somehow they kept on getting work, and then ...
http://www.theguardian.com/technology/2008/jun/24/fergus.mcgovern
OK, I'm calling "uncle" ... you beat me! Mercy, please! Yes, there were a LOT of really bad ports done in those days. :wink:
-
at least now I know who to punch in the eye, if I ever see the guy
-
I would be interested to port some of my games on PC-FX, the problem is, how many people actually have a PC-FX and are willing to buy new games ?
The PC-FX is quite expensive, and because most of the games are unplayable, and the playable ones are expensive too, I guess not much people possess this console. (that the reasons I hesitate to buy one)
If there is at least 100~150 people interested, I might consider working on this machine.
Can the current liberis library play audio cd ? Movie ?
-
Welcome!
I think that you'd find it a fun machine to program for, with a very developer-friendly architecture.
More interesting than the PlayStation 1, and much less crazy than the Saturn.
I would be interested to port some of my games on PC-FX, the problem is, how many people actually have a PC-FX and are willing to buy new games ?
You'd probably be better off asking that in the main "PC-FX Discussion" section, because not all PC-FX players/collectors are interested in the "Development" section.
I suspect that a lot of PC-FX owners would be open to new games ... the problem is that even here, there really aren't that many active PC-FX owners.
The PC-FX is quite expensive, and because most of the games are unplayable, and the playable ones are expensive too, I guess not much people possess this console. (that the reasons I hesitate to buy one)
If you get a used one without-box from sellers in Japan, I don't personally think that the PC-FX itself is that expensive, and surface shipping isn't that bad (but slow).
If you want a boxed one in perfect condition, and you want it fast, then it'll cost one heck of a lot more!
It's cute to have a PC-FX GA, but it isn't actually needed for development unless you want to write code for the 3D chip ... and so limit yourself to the dozen or less people on the planet with a working PC-FX GA setup.
You can develop quite happily in Mednafen while waiting for real hardware to arrive ... Ryphecha's emulation accuracy is excellent, and it's a nicer development environment than the PC-FX GA anyway.
And since the machine has absolutely no copy-protection, you can burn a CD and run anything that you like and try it before deciding whether you want to buy it.
If there is at least 100~150 people interested, I might consider working on this machine.
That's your decision to make.
If you're interested in being an early developer of Western PC-FX homebrew, and you're not afraid of the challenge of working on a machine that is still fairly unknown, and you're willing to try to puzzle your way through Japanese hardware manuals, then you're in the right place at the right time.
If you're looking for major recognition and some financial reward for your efforts ... then this might not be the best machine for you.
Can the current liberis library play audio cd ? Movie ?
No, I'm afraid not.
You can see Alex's liberis documentation, and his English copy of the documentation that the Japanese homebrew guys put together in 2000/2001 at http://daifukkat.su/pcfx/
If you really want to develop on the PC-FX right now, Hudson's old PC-FX GA libraries are supposed to work with the old Japanese GCC 2.95 toolchain.
I believe that they were supposed to be limited to only run on the PC-FX GA, but that's probably just in the C startup code, which you could replace.
I'm specifically avoiding the use of those old libraries moving forward, because I want to have a 100% legal toolchain that can be used for homebrew.
AFAIK, that would make it the only 5th-gen machine with a completely legal toolchain ... but I could easily be wrong on that, and would be happy to be corrected.
-
The PC-FX is quite expensive....
I recently sold my extra boxed system and a half dozen common games for $200 shipped, so it's not that expensive.
-
The PC-FX is quite expensive....
I recently sold my extra boxed system and a half dozen common games for $200 shipped, so it's not that expensive.
That's because you're a kind and generous soul, and not a seller in Japan working hard and trying to make a living off of eBay. :wink:
-
They weren't from Japan, but I did buy 'em on ebay and I didn't lose money reselling them.
-
Hmmmm ... small hiccup with GCC 4.7.4 ... the V850 guys changed the system ABI in 2010, and so liberis won't run without modification. I'm still trying to decide how to handle that, and if there's any advantage in using the new ABI on the PC-FX's V810.
In the meantime, I have binutils 2.22 and GCC 4.5.4 compiling V810 code, and have the liberis demo programs running on mednafen's PC-FX eumulation with that combo.
Since GCC 4.5.4 was released in 2012, I'm still going to claim 12 years of improvements over the old Japanese GCC 2.95.2.
Early days, though, and lots more testing to do ... but good progress.
Jeez ... I posted that almost a year ago ... where has the time gone! :shock:
I thought that I'd take a short break from the Xanadu translations and take a look at this again.
Binutils 2.23 and GCC 4.7.4 are now compiling the "liberis" demo programs correctly, using the old V810 ABI that dates back to the ancient Japanese GCC 2.95 (and even earlier).
I'm definitely going to need to do some more testing, but moving up to the GCC 4.7 compiler gives us nearly full compliance with the latest "C11" standard.
There are still a couple of things from C11 that didn't get to be standards-compliant until GCC 4.9 (like atomics) ... but nothing that anyone is likely to need on an old single-core system like the PC-FX.
The nice thing (for me), is that I've now got binutils 2.23 and GCC 4.7.4 on both the PC-FX and the X68000, so I can mess-about in C with both of Hudson's old GCC-capable machines. :wink:
-
Sounds like a major improvement over the old system, and sufficient for those ambitious enough to do some serious dev. I am considering buying a PC-FX for this purpose.
-
Sounds like a major improvement over the old system, and sufficient for those ambitious enough to do some serious dev. I am considering buying a PC-FX for this purpose.
I was going to recommend a PC-FXGA, mostly in order to use a nice-and-fast PC CDROM drive that can read anything. But you've already pulled-the-plug, so I'm a bit late.
As long as you're willing to put up with the tools in their slowly-evolving state, then I think that you'll find it a nice machine to work on. :)
-
As long as you're willing to put up with the tools in their slowly-evolving state, then I think that you'll find it a nice machine to work on. :)
I was willing to work with trap15 while developing liberis, using Linux inside of a virtual machine and even ironing out a method of making the system work under cygwin... so yeah, I'm up for it. :D
-
As long as you're willing to put up with the tools in their slowly-evolving state, then I think that you'll find it a nice machine to work on. :)
I was willing to work with trap15 while developing liberis, using Linux inside of a virtual machine and even ironing out a method of making the system work under cygwin... so yeah, I'm up for it. :D
You helped Alex with creating "liberis"? That's so cool! :D
That's also how this kind of stuff is "supposed" to work in these "internet-connected" days.
Someone may leave ... someone may appear. As long as there's decent documentation for everyone's efforts, then we can all build on each-other's hard work and create something wonderful.
I've been adding my work to this endeavor ... but I wouldn't have even started without seeing that Alex "trap15" Marshall had trailblazed the whole library issue, and that's without considering Rypheca's incredible contribution in creating Mednafen in the first place.
Piece-by-piece ... that's how we'll open up the PC-FX for "modern" homebrew development.
-
My contributions were minimal but yeah, I was there... by the time I got involved though, liberis was already pretty far along. Mainly what I did was testing new stuff he was adding, but I also wrote a high-level sprite library extension so that HuC users wouldn't have much of a learning curve. I think it was Ryphecha who got the old gcc working in the first place. We would all jaw for hours on IRC while it was being developed.
-
Talk about a labor of love, doing any kind of dev for the PC-FX. There's underdog and then there's underdog.
While you're at it, develop for the Bandai Pippin (but deliberately make sure it won't work on a Mac). ; )
-
Bandai Pippin
(http://cdn.smosh.com/sites/default/files/bloguploads/simpsons-fire.gif)
-
Documentation for this crap is pretty much the most important part.
Even more important than getting it working, probably.
One day, when PCE/MSX stuff I am doing has died down, PC-FX is where my tentacle rape space pirate RPG Mahjong dating sim is going to be.
-
Documentation for this crap is pretty much the most important part.
Absolutely. Poorly-documented toolchains go nowhere fast. Imagine if WinterMute had taken the time to properly document *anything* he worked on... way more people would be using devkitpro... but since he never felt it necessary, only those with free time on their hands had the patience to figure everything out on their own. Just one example. HuC did not have the greatest documentation at first either, but several people stepped up to help. Your Squirrel library is probably the best-documented dev tool there is in the PCE scene.
-
Documentation for this crap is pretty much the most important part.
Well, I'd say that we're lucky to actually have the full system documentation, even if it is in Japanese.
I've got all the docs readable by Microsoft Word ... and we can convert them into any modern format for translation/editing.
All the work that Alex Marshall did in converting the old http://hp.vector.co.jp/authors/VA007898/pcfxga/ website into English is still available for updates & edits.
(His site "daifukkat.su" website died last year, but I've got a backup of it.)
He was very good about including doxygen tags in his source, so there's some semi-decent documentation for how to use the code that he's written.
I'm cleaning up my "build" scripts so that they're a bit-more sensibly organized.
I've got Mednafen building a 64-bit Windows version now, and I'll try to get the tools 64-bit-clean over the next week or so.
I'll also try to put a hack into Mednafen so that we've got 8MB on the PC-FX instead of 2MB.
It's so much easier to have extra memory available in "debug" builds to compensate for the larger size of the compiled code, and to also provide extra space for in-game logging/debugging info.
-
This reminds me, I need to work on PCFXTOO.com again... lol
I hate websites.
-
My PC-FX came in today, so it's on like popcorn.
-
Congratulations, that was quick!
Now, I've still got some important stuff left to do on the toolchain (like getting newlib compiling again), so I'm going to have to slow you down somehow ... :-k
Errrrmmm ... you do realize that I can only pass on the new toolchain to folks who have completed the Zeroigar translation's "Sakuraigar Mode"? (That should keep him busy for a while!) :wink:
-
Congratulations, that was quick!
Now, I've still got some important stuff left to do on the toolchain (like getting newlib compiling again), so I'm going to have to slow you down somehow ... :-k
Errrrmmm ... you do realize that I can only pass on the new toolchain to folks who have completed the Zeroigar translation's "Sakuraigar Mode"? (That should keep him busy for a while!) :wink:
I'll never work with these tools, drat!
-
OK I beat your game... any idea on when this might be ready for testing? :)
-
OK I beat your game... any idea on when this might be ready for testing? :)
Oh, cr*p that was quick! :shock:
I hope that you didn't actually take me seriously and really play the game ... unless you actually wanted to! #-o
-
After being a royal pain in elmer's ass (sorry bro hehe), I got the toolchain working here... so now comes the fun part. :D
(http://scontent-iad3-1.xx.fbcdn.net/hphotos-xtl1/v/t1.0-9/12804751_10208018991819913_948209440238472748_n1c16.html?oh=14164e8aaa7e208dcb93b884d2866ac8&oe=578E3377)
-
After being a royal pain in elmer's ass (sorry bro hehe), I got the toolchain working here... so now comes the fun part. :D
Woohoo!
Well ... there's the V810 VWF-code that I wrote for Zeroigar and posted in one of the other threads when you're ready to tackle that nasty ROM font in Alex's example code! :wink:
-
Ran it on my PC-FX... works beautifully. :)
(http://scontent-iad3-1.xx.fbcdn.net/hphotos-xpf1/v/t1.0-9/12794456_10208019177784562_7616281069850897323_nbc53.jpg?oh=25db7107ae25bece57998e48657ef4bb&oe=5757A5C8)
Woohoo!
Well ... there's the V810 VWF-code that I wrote for Zeroigar and posted in one of the other threads when you're ready to tackle that nasty ROM font in Alex's example code! :wink:
Oh yeah, definitely... and I'm gonna test the hell out of this thing and annoy you further ;) haha :lol:
-
Naturally, one of the first things I looked for was library code to play CD audio tracks... looks like there are none, but there's low-level SCSI command access, so I can just write some code to do all the drive stabbies and wrap it up in a neat high-level implementation. :)
EDIT: OK, this part would be easier if I knew what the LUN was of the drive... :lol:
-
According to Ryphecha, the LUN should be 0. So, I attempted to edit the hello.c example program to play a CD track. I'm getting no audio, and it must be because I am missing some important step.
eris_low_psg_set_main_volume(15,15);
eris_low_cdda_set_volume(63,63);
scsicmd10[0] = 0x48;
scsicmd10[1] = 0;
scsicmd10[4] = 2;
scsicmd10[5] = 1;
scsicmd10[7] = 3;
scsicmd10[8] = 1;
scsicmd10[9] = 0;
eris_low_scsi_command(scsicmd10,10);
-
I still can't get CD audio to work and I am not sure why... in the meantime, I've added some more high-level functionality to mimic HuC's behavior, as I did with the high-level sprite library. While it's pretty basic for now, it's a good proof of concept.
First up is put_string() as per HuC's implementation, with the addition of the Tall font.
void put_string(char* str, int x, int y, int tall)
{
u32 o[256];
int i;
int len = strlen8(str);
if (len > 255) len = 255;
for(i = 0; i < len; i++)
o[i] = str[i];
o[i] = 0;
u32 kram = x + (y << 5);
len = strlen32(o);
for(i = 0; i < len; i++) {
printch(o[i], kram + i, tall);
}
}
Then there's put_number() which requires itoa... looks like this is in stdlib but the default makefile explicitly prevents stdlib from linking so I just added K&R's implementation of itoa, slightly modified to work with this toolchain.
void put_number(int thenumber, int length, int x, int y, int tall)
{
char onum[33];
if (length > 32) length = 32;
if (length < 1) length = 1;
itoa(thenumber,onum);
onum[length] = 0;
put_string(onum, x, y, tall);
}
/* itoa: convert n to characters in s */
void itoa(int n, char s[])
{
int i, sign;
if ((sign = n) < 0) /* record sign */
n = -n; /* make n positive */
i = 0;
do { /* generate digits in reverse order */
s[i++] = n % 10 + '0'; /* get next digit */
} while ((n /= 10) > 0); /* delete it */
if (sign < 0)
s[i++] = '-';
s[i] = '\0';
reverse(s);
}
/* reverse: reverse string s in place */
void reverse(char s[])
{
int i, j;
char c;
for (i = 0, j = strlen8(s)-1; i<j; i++, j--) {
c = s[i];
s[i] = s[j];
s[j] = c;
}
}
And yeah, this is based on chartou32() and printstr() in hello.c... they work well, so why reinvent the wheel... I just merged them into a single function and added a safeguard.
-
Here's a put_hex() based on Robert Jan Schaper's itoa() that hardcodes in a base value of 16:
void put_hex(int thenumber, int x, int y, int tall)
{
static char buf[32] = {0};
int i = 30;
if (thenumber < 1)
{
put_string("0",x,y,tall);
return;
}
for(; thenumber && i ; --i, thenumber /= 16)
buf[i] = "0123456789ABCDEF"[thenumber % 16];
put_string(&buf[i+1],x,y,tall);
}
-
Then there's put_number() which requires itoa... looks like this is in stdlib but the default makefile explicitly prevents stdlib from linking so I just added K&R's implementation of itoa, slightly modified to work with this toolchain.
Yes, I've got to figure out what the command-line-magic is that's needed to get stdlib actually linked into the build again.
I've got newlib is compiled for the V810, and it provides all the usual goodies, but I guess that Alex wasn't using it when he did his work on liberis.
Good work on the investigations ... I'll be interested to see what kind of code the compiler comes up with for some of the C code that you've done.
-
Okay so I had the code working fine for CD audio playback all along... there was actually a bug in liberis that prevented it from outputting sound.
In src/low/soundbox.S:
.global _eris_low_cdda_set_volume
_eris_low_cdda_set_volume:
out.b r6, 0x12A[r6]
out.b r7, 0x12C[r6]
jmp [lp]
change it to this:
.global _eris_low_cdda_set_volume
_eris_low_cdda_set_volume:
out.b r6, 0x12A[r0]
out.b r7, 0x12C[r0]
jmp [lp]
though you can get the same effect in regular C code with the following:
out8(0x12A, leftvol);
out8(0x12C, rightvol);
so that's one mystery solved! :)
-
So... we got some basic CD audio functionality now as well... here we go:
void cd_set_volume(u8 leftvol, u8 rightvol)
{
if (leftvol > 63) leftvol = 63;
if (rightvol > 63) rightvol = 63;
out8(0x12A, leftvol);
out8(0x12C, rightvol);
}
This does not exist in HuC because there's apparently no way to adjust the volume outside of using the hardware faders.
void cd_playtrk(u8 start, u8 end, u8 mode)
{
u8 scsicmd10[10];
scsicmd10[0] = 0x48;
scsicmd10[1] = 0;
scsicmd10[2] = 0; /* reserved */
scsicmd10[3] = 0; /* reserved */
scsicmd10[4] = start;
scsicmd10[5] = 1;
scsicmd10[6] = 0; /* reserved */
scsicmd10[7] = end;
scsicmd10[8] = 1;
scsicmd10[9] = 0;
eris_low_scsi_command(scsicmd10,10);
}
I made the prototype identical to the HuC one, although this is incomplete. There's probably a way to set the track(s) to loop, but I don't know what it is yet... made sense to prepare for it though. :) If there's no way to do it in hardware (what a step back that would be), then it could probably be emulated by polling the drive status at regular intervals.
Anyway, this is all tested working... I will try to add the rest of the CD audio functionality from here. MSF playback is supported, as well as pause/resume, so these won't be too difficult to add in. I just wanted to get a working base to start... now that it's working fine, it can be expanded.
-
More CD functionality based on direct SCSI commands.
void cd_pause()
{
u8 scsicmd10[10];
scsicmd10[0] = 0x47; // operation code PAUSE RESUME
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = 0; // reserved
scsicmd10[4] = 0; // reserved
scsicmd10[5] = 0; // reserved
scsicmd10[6] = 0; // reserved
scsicmd10[7] = 0; // reserved
scsicmd10[8] = 0; // Resume bit
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}
void cd_unpause()
{
u8 scsicmd10[10];
scsicmd10[0] = 0x47; // operation code PAUSE RESUME
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = 0; // reserved
scsicmd10[4] = 0; // reserved
scsicmd10[5] = 0; // reserved
scsicmd10[6] = 0; // reserved
scsicmd10[7] = 0; // reserved
scsicmd10[8] = 1; // Resume bit
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}
void cd_playmsf(u8 strt_m, u8 strt_s, u8 strt_f, u8 end_m, u8 end_s, u8 end_f, u8 mode)
{
u8 scsicmd10[10];
scsicmd10[0] = 0x47; // operation code PLAY AUDIO MSF
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = strt_m; // starting M
scsicmd10[4] = strt_s; // starting S
scsicmd10[5] = strt_f; // starting F
scsicmd10[6] = end_m; // ending M
scsicmd10[7] = end_s; // ending S
scsicmd10[8] = end_f; // ending F
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}
Again, using HuC's convention. The pause/unpause functions could easily be put into a single function with a parameter... would save some code space...
void cd_pausectrl(u8 resume)
{
u8 scsicmd10[10];
if (resume > 1) resume = 1; // single bit; top 7 bits reserved
scsicmd10[0] = 0x47; // operation code PAUSE RESUME
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = 0; // reserved
scsicmd10[4] = 0; // reserved
scsicmd10[5] = 0; // reserved
scsicmd10[6] = 0; // reserved
scsicmd10[7] = 0; // reserved
scsicmd10[8] = resume; // Resume bit
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}
Some #defines would make that clearer...
#define CD_PAUSE 0
#define CD_UNPAUSE 1
#define CD_RESUME 1three #defines, because reasons. :lol:
-
May I ask why you do
"if (leftvol > 63) leftvol = 63;
if (rightvol > 63) rightvol = 63;"
rather than
"
leftvol &= 63;
rightvol &= 63;
" ?
And does it work right if leftvol = -1? I believe HuC has some problems with mixed mode compares.
(ie, 63 is an int (presumably signed) and leftvol is unsigned char; Huc doesn't sign extend afaik, so
it's possible to get things that seem to work in most cases...but not in all)
I know its not HuC, that's why I'm asking.
-
I wondered about that. It all depends on what causes less cycles. If it's generally false 90% of the time, maybe quick value tests and a jump are faster than always AND'ing and assigning/writing to a memory location. You guys would know, maybe Rover cycle tested his code. I wanna agree it could be faster your way, but I'd wanna test it, dunno.
-
May I ask why you do
"if (leftvol > 63) leftvol = 63;
if (rightvol > 63) rightvol = 63;"
rather than
"
leftvol &= 63;
rightvol &= 63;
" ?
Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts. :lol:
-
May I ask why you do
"if (leftvol > 63) leftvol = 63;
if (rightvol > 63) rightvol = 63;"
rather than
"
leftvol &= 63;
rightvol &= 63;
" ?
Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts. :lol:
That's not exactly "clever" C code ... "+=", "-=", "*=", "/=", etc are pretty standard stuff.
OTOH ...
if (leftvol > 63) leftvol = 63;
is actually very different to ...
leftvol &= 63;
Your version clamps an over-the-limit value of 64 to the maximum of 63.
NightWolve's version wraps 64 back to 0 (which is pretty-much-never what you want in practice).
Given that neither are particularly good end-results, and that you're programming for a fairly-slow videogame console and not a medical life-saving device ... IMHO it's best not to waste the CPU cycles by even trying to clamp/wrap it, and just leave it up to the programmer to feed it legal values.
-
I've always said that we should just remove the safeguards and let the problems solve themselves... but I was just being cautious, as I tend to do. I'll remove all safeguard code from my work and also not add any in the future.
-
Okay so I guess one thing we're going to need is some utility tools to convert graphics and other such things.. if stuff like this does not already exist, I can spend this weekend working on such things.
-
NightWolve's version wraps 64 back to 0 (which is pretty-much-never what you want in practice).
Uh, you mean OldMan? I only wondered which version uses less CPU cycles factoring in the % rate that over 63 is possible. If it's 9X% false in general use, then I'm guessing reading those variables and always writing back to them with an AND operation will take more CPU cycles versus a cmp to 63 and jumping over the assignment/writing of 63 to the variable. I'm not sure either way, but I think a test is worth it to know what's fastest to keep the library code fast if such safeguards are really needed (sounds like they might not be).
But anyway, good point if his AND'ing with 63 would cause a wrap back to 0 with 64 which rules out considering it at all... I thought it was legit code to accomplish the same result at first glance and simply compact but doubted the CPU cycle gains in switching.
-
I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4. I'm going to assume that Y is the upper 8 bits, U is the high nybble of the lower 8 bits and V is the lowest nybble... someone please correct me if I'm wrong. I am going to be using this formula:
Y = (0.299*R) + (0.587*G) + (0.114*B)
U = ((B-Y)*0.565) / 4
V = ((R-Y)*0.713) / 4
YUV = (Y << 8) + (U << 4) + V
If any of this is wrong, I'd like to know... :)
EDIT: Fixed mah formula!
-
Uh, you mean OldMan? I only wondered which version uses less CPU cycles ...
Sorry, I got confused! :oops:
I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4. I'm going to assume that Y is the upper 8 bits, U is the high nybble of the lower 8 bits and V is the lowest nybble... someone please correct me if I'm wrong. I am going to be using this formula:
Y = (0.299*R) + (0.587*G) + (0.114*B)
U = ((B-Y)*0.565) / 2
V = ((R-Y)*0.713) / 2
YUV = (Y << 8) + (U << 4) + V
If any of this is wrong, I'd like to know... :)
I'm afraid that my graphics toolchain still needs a lot of cleanup before it's shareable.
I've got 131 undocumented options in there now from 25+ years of "just-get-it-done" ... it badly needs some TLC before anyone else would find it useful.
But here's the palette code that I added to it for converting graphics for Zeroigar.
It's not pretty, but it worked.
float fl___R = (float) pcl__P->m_uRgbR; // 8-bit (0-255)
float fl___G = (float) pcl__P->m_uRgbG; // 8-bit (0-255)
float fl___B = (float) pcl__P->m_uRgbB; // 8-bit (0-255)
float fl___Y =
( 0.2990f * fl___R) + (0.5870f * fl___G) + (0.1140f * fl___B);
float fl___U =
(-0.1686f * fl___R) - (0.3311f * fl___G) + (0.4997f * fl___B) + 128.0f;
float fl___V =
( 0.4998f * fl___R) - (0.4185f * fl___G) - (0.0813f * fl___B) + 128.0f;
if (fl___Y < 0.0f) fl___Y = 0.0f;
if (fl___Y > 255.0f) fl___Y = 255.0f;
if (fl___U < 0.0f) fl___U = 0.0f;
if (fl___U > 255.0f) fl___U = 255.0f;
if (fl___V < 0.0f) fl___V = 0.0f;
if (fl___V > 255.0f) fl___V = 255.0f;
unsigned ui___Y = (unsigned) fl___Y;
unsigned ui___U = (unsigned) fl___U;
unsigned ui___V = (unsigned) fl___V;
ui___U = (ui___U + 8 ) >> 4;
ui___V = (ui___V + 8 ) >> 4;
ui___P = (ui___Y << 8 ) + (ui___U << 4) + ui___V;
*puw__Q++ = (uint16_t) ui___P;
-
I was actually wrong on the / 2... it should be / 4 (or >> 4, both work)... realized that when I was taking a shower... why is it that all this stuff comes to me when I'm all wet? :lol: Anyway, I recognize that algorithm as well, and I am not sure which one would produce more accurate results... maybe neither, heh. :)
-
Anyway, I recognize that algorithm as well, and I am not sure which one would produce more accurate results... maybe neither, heh. :)
Well ... mine comes directly from the PC-FX SDK documentation, but I'm not sure where yours comes from (especially since you're missing the center-bias on the U & V). :wink:
-
Mine comes from here:
http://www.fourcc.org/fccyvrgb.php
because I don't have access to such fancypants thingos. :lol:
-
Okay so I implemented the algorithm you have up there... here's the results I get parsing a simple 16 color palette:
255 0 255 -> 0x69DF
0 0 0 -> 0x88
36 0 0 -> 0xB89
0 36 72 -> 0x1DA7
72 0 0 -> 0x167A
36 72 144 -> 0x45B7
36 108 180 -> 0x5FB5
144 36 36 -> 0x447B
180 36 36 -> 0x4F7D
144 72 36 -> 0x596A
180 108 36 -> 0x795B
216 72 72 -> 0x737D
216 144 72 -> 0x9D5B
255 144 72 -> 0xA95C
255 216 72 -> 0xD33A
255 180 144 -> 0xC66B
As long as I didn't mess anything up, I assume your implementation should get the same results.
-
...Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.
Ok. I do that too.
Asking because I often see the & route used, suposedly being 'faster'.
And because I've had trouble with mixed-type compares...Maybe 0x3f would be 'better' than 63?
personally, I'm not sure though that clamping it is 'better'. I like to know when there are problems with input variables, and no sound would be a sure indication of that :)
Since I'm not familiar with the machine, or the compiler generated code, I'll leave it to the experts.
As for the input checks...we do it all the time. It's easy enough to use a #ifdef/#endif to turn them
on/off.
I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4.
Ouch.Good luck.
-
Okay so now this subforum needs to be changed to Turbo/PCE/PC-FX Game/Tool Development... :lol:
-
I made an RGB to YUV conversion utility that takes a JASC-PAL 16 or 256 color palette and spits out a header file with the palette encased in an array. Hopefully I got everything right... I have not actually used it in a source file yet because I don't yet have anything to convert actual graphics with, but this is a start.
http://www.frozenutopia.com/pal2yuv.7z
Source code is included; built using fbc 1.05, not gcc, so it's probably out of some people's comfort zone, but it's right at home for me. :lol:
-
Since I'm not familiar with the machine, or the compiler generated code, I'll leave it to the experts.
With these old CPUs, it's definitely a good exercise to take a look at what the compiler generates to see how good a job it's doing.
One of the big things to note about the V810 is that all loads from memory-to-registers are automatically sign-extended to 32-bit, and that all internal arithmetic is done as signed 32-bit.
So any "unsigned" C variables are likely to need another instruction to zero-extend them (usually an "and"), and that you don't get much (if any) benefit from using 8-bit or 16-bit ("char" or "short") variables.
As for the input checks...we do it all the time. It's easy enough to use a #ifdef/#endif to turn them
on/off.
Having extra checks that are only compiled in "debug" mode is definitely good practice.
But "clamping" or "wrapping" is IMHO almost never a good idea in game development.
An "assert" is a good way to cause an instant blow-up, and so to cause a programmer to see and fix a problem.
"Warning" messages just tend to be ignored until they become a more-serious problem.
Okay so now this subforum needs to be changed to Turbo/PCE/PC-FX Game/Tool Development... :lol:
:wink:
Source code is included; built using fbc 1.05, not gcc, so it's probably out of some people's comfort zone, but it's right at home for me. :lol:
FreeBASIC? Wow! Well, each of us has our own comfort-zone.
I'm investigating "Go" to see if it's good replacement for "C" for tool/systems programming.
It's the first "modern" langauge that I've ever seen that actually seems well-designed and aimed at the solving the kind of problems that I've seen in my years of software development.
-
An "assert" is a good way to cause an instant blow-up, and so to cause a programmer to see and fix a problem.
"Warning" messages just tend to be ignored until they become a more-serious problem.
From a content creation viewpoint I would certainly agree. The warnings become neglected and not addressed unless noticed during gameplay, and are almost always ignored and often referred to as red spew.
Asserrts are unavoidably required to be corrected, submitting files that are causing asserts hardly happens because during the testing phase before submission it's blatent that your changes broke the build.
-
From a content creation viewpoint I would certainly agree. The warnings become neglected and not addressed unless noticed during gameplay, and are almost always ignored and often referred to as red spew.
Hahaha! :wink:
Color-coding the insane volume of messages that most games spit out is one of the first attempts to try to stop the "important" stuff from getting lost in all the "noise".
It never works.
There's never enough free time to fix the "small" stuff ... so it just gets sidelined with a "we'll fix it later".
That's why I like "asserts" for things like bad parameters to functions ... it causes the problem to be dealt with at a time when somebody still probably remembers why that change was made that broke things.
Asserts are unavoidably required to be corrected, submitting files that are causing asserts hardly happens because during the testing phase before submission it's blatent that your changes broke the build.
Yeah, someone repeatedly "breaking the build" is a self-correcting problem ... either the peer-pressure will cause the offender to learn better habits, or if they're too stupid to do so, they'll get fired, and the average I.Q. of the team will raise by a couple of points.
Either circumstance is a "win" for the team.
*************
Anyway ... back to the PC-FX.
On the "plus" side ... the toolchain now goes through the magical "2nd-GCC-build" stage that's needed to get newlib working properly, and I've got newlib actually linked into a test program.
That means that we've now got "stdlib", and "sprintf", and "malloc", and all those other goodies.
On the "negative" side ... calling "sprintf" crashes.
2 steps forward, 1 step back ... as usual. ](*,)
-
All the apps in the PC-FXGA download are incompatible with Windows 7... guess I better install a VM. :)
-
Ah, yeah, Windows 7 broke my TurboRip app also because Microsoft tightened security and no longer allowed you to build a SCSI command packet for reads and pass it directly to the CD/DVD drive, you must instead use their SPTI methods for reading data/audio sectors, otherwise the packet is rejected...
All other command packets to read the CD's TOC, set the drive speed, etc. are allowed, just command packets for reads are policed. You also cannot read a MODE1 sector in raw 2352 form, only in 2048 cooked... MODE2 sectors have multiple forms, and they couldn't police raw reads there as then you couldn't detect Form 1 or 2, so they left that alone...
I suspect they pissed off a lot of developers/customers by breaking many apps having done this though which might explain why such SCSI policing was removed for Windows 8/8.1/10 and CD/DVD apps started working again, TurboRip included. But anyway, I researched the changes needed and actually got it working on Windows 7 after johnnykonami/SamIAm reported the problem to me.
-
(http://www.frozenutopia.com/mpconv2.html)
After a hard-fought battle, I finally got Windows 95 installed into a VM and the PC-FXGA toolset installed... this looks like the only thing really worth using in the whole bloody package though... aside from the docs that are all in Japanese... :lol:
-
Ah, good old MPCONV2. How many times did it get used to encode yet another test video for Zeroigar subtitles? It must have been hundreds.
-
Hm, so https://www.virtualbox.org/ ?
I use Microsoft's Virtual PC 2007, but I don't recall it allowing Windows 95, lowest selection was 98 I think. I resurrected a real Windows 95 PC I bought in 1996 however, my first computer which I still have. It would be useful to get a Win95 install set up in my main workstation though for rare testing when needed assuming it works reasonably well in an emulated setting. Will check out VM Box some time.
-
I use Microsoft's Virtual PC 2007, but I don't recall it allowing Windows 95, lowest selection was 98 I think. I resurrected a real Windows 95 PC I bought in 1996 however, my first computer which I still have. It would be useful to get a Win95 install set up in my main workstation though for rare testing when needed assuming it works reasonably well in an emulated setting. Will check out VM Box some time.
IMHO Virtual PC 2007 is better than VirtualBox for a DOS/Win3/Win95 virtual machine, mostly because it emulates an older set of hardware, and it comes with "shared folder" additions for those old OS versions that IIRC VirtualBox doesn't.
If you want to run Win95 or earlier on Virtual PC 2007, just set the OS to "Other" and use the "additions" from Virtual PC 2004 (they work fine).
After a hard-fought battle, I finally got Windows 95 installed into a VM and the PC-FXGA toolset installed... this looks like the only thing really worth using in the whole bloody package though... aside from the docs that are all in Japanese... :lol:
Hahaha ... you wimped-out and didn't install the Japanese version of Windows! :wink:
I ended-up buying a copy of Win95 OSR2.5 from Japan just so that I could run all the PC-FXGA utilities on my old PC that has the PC-FXGA card installed.
-
Hahaha ... you wimped-out and didn't install the Japanese version of Windows! :wink:
Nah dude, just didn't get that far... wanted to know I could even get it to work before going through such trouble.
EDIT: The program runs in Windows XP but I don't know yet how well it actually functions:
(http://www.frozenutopia.com/mpconv2xp.html)
-
EDIT: The program runs in Windows XP but I don't know yet how well it actually functions:
IIRC, WinXP is the last version that included a compatibility-layer for 16-bit Windows programs.
Good to know that MpConv2 runs on it.
If it runs at all, then I'd be a bit surprised if it didn't run correctly ... it's just doing graphics/sound processing, and I don't remember it having a direct connection to the PC-FXGA hardware.
EDIT:
I just checked again ... it's been a while since I looked.
MpConv2 has both Japanese and English resources (as so looks fine on an English version of Windows), but its .hlp file is all in Japanese, and looks like garbage on English Windows).
Hudson's AGE graphics editor only contains Japanese resources, and a Japanese .hlp file.
It's possible to extract/translate/reinsert both the resources and the .hlp file contents ... but it's one heck of a lot of work.
I can just-about see it being worthwhile for MpConv2, because the PC-FX video is unique, and there is no other tool available to do the conversion.
AGE, OTOH, is a pretty crappy graphics editor whose only real use is in converting BMP images into the PC-FX's bitmap and tile formats ... and these tasks are usually better performed with modern tools and modern formats (like PNG).
I did use it to convert Zeroigar's English title-screen, because it saved a bunch of time in writing an alternative ... but it's not really a good long-term solution.
-
I have AGE (Awful Graphics Editor) almost figured out. Yeah, in the long run, it's a rather poor program, and forget about using it as a graphics editor... I think MS Paint is more useful... but as a conversion tool, it does the trick for now. I'm using Borland Resource Workshop 4.5 to edit it.
(http://www.frozenutopia.com/vbageedit.html)
-
Just in case anyone out there that understands Japanese is looking at this and thinking "This is all very cool, I wish that I could help!" ... then here's your opportunity! :wink:
SamIAm is rather snowed-under with everything that he's doing on the Xanadu games, so I'd really rather not pester him for help on this.
Here is the documentation for mpconv2 in .rtf and .doc format.
https://www.dropbox.com/s/9pia84lwn3einla/mpconv2e.zip?dl=0
It would be really great if someone could translate the Japanese text into English (preferably without destroying the actual formatting so that it can be recompiled into a .hlp file).
There are a bunch of embedded pictures in there, but I'm not expecting anyone to get out a paint program and try to edit those (although it would be wonderful if someone did).
Is anyone willing to help?
-
I can do replacement graphics for AGE's help file once it's translated, if that helps.
-
I can do replacement graphics for AGE's help file once it's translated, if that helps.
That would be nice!
-
Well, here's the MpConv2 GUI pics in English at least...
(http://www.frozenutopia.com/pcfx/pic1.html)
(http://www.frozenutopia.com/pcfx/pic2.html)
(http://www.frozenutopia.com/pcfx/pic3.html)
(http://www.frozenutopia.com/pcfx/pic4.html)
(http://www.frozenutopia.com/pcfx/pic5.html)
(http://www.frozenutopia.com/pcfx/pic6.html)
(http://www.frozenutopia.com/pcfx/pic7.html)
-
For what it's worth, I am almost done translating the AGE application. The menus are done, but the thing has a large string table, primarily for the status bar, which I am handling now.
(http://www.frozenutopia.com/pcfx/age.html)
-
I accidentally broke one of the dialogs while editing... might take some time to fix, even though it's just the New Image one that I doubt anyone will use... still, can't leave it broken.
-
What is your resource editor of preference here BTW ? Too bad nobody found a stash of old tools like this for PC Engine... Kinda neat for anybody that would get serious with the PC-FX. I honestly don't care much for this platform, but have at it if you do!
-
I am using Borland Resource Workshop 4.5 to do the resource editing... it's the only one I could find that actually works with 16 bit programs... pretty much everything else is for win32.
I've completed all of the strings I can actually see... it is not completely translated, and there is some text in the EXE itself that will also need translation at some point (xvi32 can handle this), but it's done enough to be useful. Of course, me being me, I decided to demo it with fine art... aka painted boobs. :P
(http://www.frozenutopia.com/pcfx/age_e.html)
Configured as a 256 color 7up tilemap. One thing that's rather cool about this program is that you can clone a window and then zoom the clone and apply a grid to it... any work you do on either the original or the clone (or many clones, for that matter) is applied to every window of that image. That's actually really friggin cool. Too bad this thing is seriously suckage for actual editing though.
So I put together the edited binary and uploaded it with a simple readme file. I's nearly 1AM and I'm tired but wanted to get this out tonight. Have at it. :)
http://www.frozenutopia.com/pcfx/age_e.7z
-
Too bad nobody found a stash of old tools like this for PC Engine.
I take it that you're overlooking that the PC-FX contains 2 of the PC Engine's VDC chips, and so has an identical sprite and tile format for the sprites and those background layers.
So, the AGE editor applies directly to the PC Engine, it just also handles the PC-FX's extra formats, too.
So I put together the edited binary and uploaded it with a simple readme file. I's nearly 1AM and I'm tired but wanted to get this out tonight. Have at it. :)
Thanks! It's really nice having someone else interested in trying to open-up the PC-FX for development!
-
Too bad nobody found a stash of old tools like this for PC Engine.
I take it that you're overlooking that the PC-FX contains 2 of the PC Engine's VDC chips, and so has an identical sprite and tile format for the sprites and those background layers.
So, the AGE editor applies directly to the PC Engine, it just also handles the PC-FX's extra formats, too.
So I put together the edited binary and uploaded it with a simple readme file. I's nearly 1AM and I'm tired but wanted to get this out tonight. Have at it. :)
Thanks! It's really nice having someone else interested in trying to open-up the PC-FX for development!
Thanks for explaining this - I was completely unaware! If you guys want a artist guinea pig I'd be down to look into getting a machine setup to try this out. :)
-
Thanks for explaining this - I was completely unaware! If you guys want a artist guinea pig I'd be down to look into getting a machine setup to try this out. :)
Excellent, thanks!
Really, you can do everything in Mednafen for the most part, there's little need to buy a real PC-FX until you're actually "hooked". :wink:
-
Holy crap, I really was tired that night... I totally missed the "I's"... soooooooooo uncharacteristic of me to miss a typo so glaring.
-
OK... from what I can tell... vsync should be "easy"... it looks like this is something on the 6261. Port 300h is the status port, and bit 15 indicates whether or not the screen is drawing. So, from this, I guess a "wait for vblank" routine would simply be a polling loop that buggers 300h until bit 15 is 0.
-
So it appears liberis already does this, with the function eris_tetsu_is_displaying(). However, it seems rather useless. I check its value... if it's 1, I wait until it's 0, and if it's 0, I wait until it becomes 1 and then wait for it to become 0 again. Naturally, this doesn't work for shit, even though this is how this should actually work.
-
So it appears liberis already does this, with the function eris_tetsu_is_displaying(). However, it seems rather useless. I check its value... if it's 1, I wait until it's 0, and if it's 0, I wait until it becomes 1 and then wait for it to become 0 again. Naturally, this doesn't work for shit, even though this is how this should actually work.
It's working perfectly ... just as long as you understand that "disp" also goes to "0" during hblank as well as during vblank! :wink:
If you want to do a wait loop like that, then you should probably be looking at the "raster count" instead.
The "proper" way to do it would be to look at a frame counter that gets incremented by the vblank-interrupt ... but I have no idea if liberis even hooks the interrupts.
****************
I've found out why newlib isn't working ... it's actually something to do with the code that's generated by the compiler's optimize-for-space settings.
For some reason it's generating an extra bogus stack-fixup instruction that's throwing off the stack alignment, and causing the code to get the wrong return address.
This isn't going to be a lot of fun to track down! #-o
-
Too bad nobody found a stash of old tools like this for PC Engine.
I take it that you're overlooking that the PC-FX contains 2 of the PC Engine's VDC chips, and so has an identical sprite and tile format for the sprites and those background layers.
So, the AGE editor applies directly to the PC Engine, it just also handles the PC-FX's extra formats, too.
Cool, that's great to know, it should be noted in the ReadMe as it could be useful for PCE hacking.
-
OK so what I have done then is created two functions... one pauses the program until the raster line is below 1, and another that pauses the program until the raster line is above 0. Is there enough time in between these two points to do drawing and such, or am I better off just checking for 0 and skipping the second one?
-
OK so what I have done then is created two functions... one pauses the program until the raster line is below 1, and another that pauses the program until the raster line is above 0. Is there enough time in between these two points to do drawing and such, or am I better off just checking for 0 and skipping the second one?
Well ... I'd read the docs, which Google Translate butchers as ...
b. RASTER COUNT (bit5 ~ 13)
I shows the raster number currently being displayed on the CRT. Display period is up to 22-261.
It should be noted, does not match the scanning line number that is defined in the NTSC signal.
During external synchronization, I will be 1FFH if the external sync signal is disturbed.
Note) of raster number value, you need to be sure you read more than once since become undefined by the timing to be read is constantly updated.
So you've got a range of values for the 239 lines of the actual display, with no extra values during the vblank period.
It depends upon what you're trying to do.
If you know for sure that your code is running at 60Hz, you could always wait for raster count 261, and then wait again for "disp" to go to zero (which is probably the vertical-blank).
That's horrible, but it might work.
If it were me doing this, then I'd just figure out how to hook the vblank-interrupt with a small assembly-language function, and implement a counter.
-
I hate counters, hooking interrupts, and RISC assembly. :lol:
I did a test where I measured the high and low with eris_tetsu_get_raster()... the range was 0 to 261 (makes sense, since I'm telling tetsu to use 262 lines). Also, I tested getting rid of the second pause, and things worked the same as using it, so it looks like there's no point in using that second pause.
...and yeah... that's some severely butchered language there... :lol:
-
eris_tetsu_get_raster() may occasionally return a garbage value on real hardware as it doesn't appear to follow the hardware programming manual's advice. You can call the function multiple times to work around it, but that's not as efficient as having the workaround for the hardware bug in the function itself...
-
I hate counters, hooking interrupts, and RISC assembly. :lol:
Well, I guess that's pretty-much-why I'm spending my time banging my head against the brick-wall of GCC! ](*,)
To be honest ... I personally believe that the V810 is the best designed and most-programmer-friendly of all the 5th-Generation CPUs (including the 3DO's ARM!).
You don't have to actually think about any of the "nasty" gotchas from those 1st-generation RISC architectures ... it has hardware-interlocks so that you can just code as you see fit (you just lose a few percentage-points of performance).
IMHO, the PlayStation's and N64's MIPS CPUs are ugly-but-bearable. The Saturn's SH-2 is an abomination, and just shows Sega's continued inability to design elegant hardware. The 3DO's ARM chip is really nice ... but a classic CISC architecture.
But the V810 is actually the first well-designed, programmer-friendly RISC chip that I've ever seen.
I guess that we've all got our own comfort-zones.
eris_tetsu_get_raster() may occasionally return a garbage value on real hardware as it doesn't appear to follow the hardware programming manual's advice. You can call the function multiple times to work around it, but that's not as efficient as having the workaround for the hardware bug in the function itself...
Thanks! I wasn't sure if that was a "real" warning in the docs, or just a bad artefact of Google Translate.
I'll fix the liberis function to actually read the value a couple of times and make sure that it's stable.
I just "fixed" Alex's startup code to do a faster job of clearing "C"'s BSS segments on startup ... partially for the performance improvement, but mostly to avoid having to dig much deeper into whatever-it-is that I broke in GCC's stack code (I think that I know, I'm just not enjoying the thought of fixing it).
While you're "on-the-line" ... can I ask if you've seen anything in the PC-FX BIOS or libraries that uses the R2 and R5 registers?
AFAIK, they're not used except temporarily-during-startup, and I'd like to use them for the Frame Pointer and the Thread Local variables pointer.
-
To be honest ... I personally believe that the V810 is the best designed and most-programmer-friendly of all the 5th-Generation CPUs (including the 3DO's ARM!).
You don't have to actually think about any of the "nasty" gotchas from those 1st-generation RISC architectures ... it has hardware-interlocks so that you can just code as you see fit (you just lose a few percentage-points of performance).
IMHO, the PlayStation's and N64's MIPS CPUs are ugly-but-bearable. The Saturn's SH-2 is an abomination, and just shows Sega's continued inability to design elegant hardware. The 3DO's ARM chip is really nice ... but a classic CISC architecture.
Interesting. It makes me wish I understood more about processors and programming.
When it comes to Sega, in addition to whatever poor choices the engineers were making, it seems to me that the executive side may have been steering them into bad ideas as well. Sega had a relationship with Hitachi - I think they were manufacturing the 68000s and other components in the Mega Drive, and there are even rumors that Hitachi execs and Sega execs were golfing buddies. Not to mention, I wouldn't be surprised if there was also a reluctance to use non-Japanese parts.
Don't let me derail the thread, though. :wink:
EDIT: Here's a Japanese article I just found that tells at least some of the story of how Sega chose the SH-2, from the perspective of a Hitachi engineer, published in an industry magazine in September 1997.
http://japan.renesas.com/products/mpumcu/superh/related_sh/theme/story/06.jsp
Some interesting points:
- The SH-1 was completed by 1992, but nobody was buying it.
- Hitachi approached Sega about using it in summer 1992. Interestingly, their first meeting wound up taking place in the Sega cafeteria.
- Sega rejected the SH-1 as it was. They told them to come back with 1) improved multiplier performance, 2) synchronous DRAM interface circuits installed, 3) the ability to meet certain game-oriented benchmarks.
- Hitachi started mass producing the SH-1 before they had any buyers for it. The lead engineer was frustrated with this and with the general work environment, and was about to take a job at another company. He submitted his intention to resign and everything.
- The vice president of the Hitachi's semiconductor subsidiary called him, buttered him up, and asked him to stick around a while longer.
- Rather suddenly, Sega accepted the SH chip for its next game system in autumn 1992. Hitachi started working an an improved SH-2 soon after.
- In summer 1993, Sega complained to Hitachi that the SH-2 wasn't powerful enough. In September, there was a big meeting of top people from both companies, and Hitachi apparently revealed a "secret strategy" - put two of them together.
- By March 1997, Hitachi had sold 15 million SH-2s through Sega. However, the profits weren't good because Sega was so desperate to keep costs down.
-
If you know for sure that your code is running at 60Hz, you could always wait for raster count 261, and then wait again for "disp" to go to zero (which is probably the vertical-blank).
That's horrible, but it might work.
If it were me doing this, then I'd just figure out how to hook the vblank-interrupt with a small assembly-language function, and implement a counter.
I don't think we're going to find a PAL PC-FX in some NEC dumpster any time soon.
In the long run the hook is required if you start doing complex raster effects. May as well get it out of the way and then not think about it.
To be honest ... I personally believe that the V810 is the best designed and most-programmer-friendly of all the 5th-Generation CPUs (including the 3DO's ARM!).
You don't have to actually think about any of the "nasty" gotchas from those 1st-generation RISC architectures ... it has hardware-interlocks so that you can just code as you see fit (you just lose a few percentage-points of performance).
IMHO, the PlayStation's and N64's MIPS CPUs are ugly-but-bearable. The Saturn's SH-2 is an abomination, and just shows Sega's continued inability to design elegant hardware. The 3DO's ARM chip is really nice ... but a classic CISC architecture.
But the V810 is actually the first well-designed, programmer-friendly RISC chip that I've ever seen.
Which is such a shame, since the rest of the PC-FX doesn't really live up to the CPU.
MIPS is fantastic if you're a compiler.
I have to wonder if most of Sega's odd console hardware choices are from taking their arcade designs (which are very reasonable) and trying to rip features out until it reaches a consumer price point (which is never reasonable). The company as a whole is such a great case study.
I guess that we've all got our own comfort-zones.
This is definitely a factor.
The nice thing about console hardware (especially old hardware) is that every single platform has something "wrong" with it. We get to pick the "least bad" option.
-
Don't let me derail the thread, though. :wink:
Hahaha ... I like tangents! :wink:
EDIT: Here's a Japanese article I just found that tells at least some of the story of how Sega chose the SH-2, from the perspective of a Hitachi engineer, published in an industry magazine in September 1997.
Thanks, that's very interesting. :-k
Here's a Hitachi marketing-brief about the SH-2 from back around that time-period ...
http://www.hotchips.org/wp-content/uploads/hc_archives/hc06/2_Mon/HC6.S4/HC6.4.2.pdf
When it comes to Sega, in addition to whatever poor choices the engineers were making, it seems to me that the executive side may have been steering them into bad ideas as well. Sega had a relationship with Hitachi - I think they were manufacturing the 68000s and other components in the Mega Drive, and there are even rumors that Hitachi execs and Sega execs were golfing buddies. Not to mention, I wouldn't be surprised if there was also a reluctance to use non-Japanese parts.
That sounds like your typical "business" scenario.
Hitachi's early CPU successes were in being a licensed second-source for American CPUs, and often improving them ... such as their HD64180 (improved Zilog Z80) and their HD6309 (improved Motorola 6809). Hitachi's relationship with Motorola gave them first the 6809, and then the 68000 (which they sold to Sega for the MegaDrive, and then also the Saturn).
AFAIK, the SuperH series (SH1, SH2, SH3) was one of their first home-grown designs ... and they made a bit of a mess of it.
It's still the only CPU that I know of that has 2 different instructions, with different names, and different binary codes, that do exactly the same thing.
It also misses out a bunch of useful things, which means that you end up needing to use multiple instructions to accomplish what other RISC architectures can do with a single instruction.
Their "secret strategy" of throwing 2 SH-2 CPUs together in the Saturn and the 32X was an absolute joke, and just a marketing gimmick to claim double the processing power. In reality, the each CPU could pretty-much completely use the entire memory bandwidth by itself, and so pairing the 2 of them on a single bus just lead to massive bus-contention and starvation for each processor.
They tried to mitigate this by re-purposing the 4KB of write-through-cache into internal memory in order to reduce the bus-contention, but that was a joke because the 5th-generation machines were all supposed to be programmed in "C", and neither the language, nor any of Sega's libraries could actually take advantage of that little 4KB of uncontested memory.
Which is why nearly-all early Saturn games just disabled the 2nd CPU and ran entirely on the 1st CPU ... throwing away 50% of Sega's marketing-hype performance.
The PC-FX's V810 (and the PlayStation's MIPS R3000) don't have the raw fake-benchmark performance numbers of the SH-2, but they easily make up for it in practice by providing "usable" performance.
IMHO, the PlayStation is the 5th-generation equivalent of the PC Engine. It's an elegantly-designed machine that does exactly what it's designed to do, and does it very, very well. But since it's basically a super-Amiga, with a fast blitter for 2D games, and good-for-its-time-but-poor-in-hindsight 3D performance, it's just a little bit "boring" to program.
The PC-FX is like a C-programmable SuperGrafx, with some extra SNES-like background layers and video too. It's just a more-interesting 2D machine, especially if you contemplate using the HuC6273 chip that's on the PC-FXGA to give you Saturn-like 3D capabilities (or just lots of sprites).
-
In the long run the hook is required if you start doing complex raster effects. May as well get it out of the way and then not think about it.
I agree ... but as-for-myself, I'm too busy at the moment working on other things (like the Xanadus and trying to get GCC "fixed").
Well ... that and pontificating in interesting threads! :roll:
MIPS is fantastic if you're a compiler.
Which is OK in 2016 ... but the quality of the compilers back in 1995 was pretty bad. You pretty-much-had-to drop down into assembly for any speed-critical routines.
But "yeah", MIPS's delay-slots aren't that nasty to program-around. IIRC, my distaste at the time was more to do with my lack of a decent assembler.
By the time that the N64 came around, that had been fixed by the guys at Cross-Products and PsyQ ... but the N64 had it's own "mysteries" with the RSP.
Which is such a shame, since the rest of the PC-FX doesn't really live up to the CPU.
The choice to ship with 2 PCE VDP chips is definitely bizarre.
The choice to ship with the PCE sound-chip is a bit regretable, but just follows-on from NEC's years of promoting CD-audio and premixed-ADPCM in games.
The PC-FX's own custom chips, the HuC6271 for video, the HuC6272 for backgrounds and SCSI, and the HuC6273 for "3D" sprites, seem to be pretty-nice, and very much remind my of a Saturn-done-right-but-a-bit-less-powerful-and-a-lot-more-usable.
I have to wonder if most of Sega's odd console hardware choices are from taking their arcade designs (which are very reasonable) and trying to rip features out until it reaches a consumer price point (which is never reasonable). The company as a whole is such a great case study.
There's definitely a huge difference in practical design-philosophy between the throw-everything-at-it-and-damn-the-cost arcade boards where you're charging thousands of dollars each to a select-few customers in order for them do suck the quarters out of people's pockets, and the let's-sell-millions-cheaply console market.
Sony's PlayStation is a perfect example of that. It's a very "minimal" hardware design, with the costly chips put exactly where they're needed.
The Saturn, OTOH, is an absolute joke of a design, with expensive bits-and-bobs thrown everywhere and lots of stuff just sitting there idle because it's got nothing to do most-of-the-time.
The nice thing about console hardware (especially old hardware) is that every single platform has something "wrong" with it. We get to pick the "least bad" option.
Hahaha ... "yep"! :wink:
-
While you're "on-the-line" ... can I ask if you've seen anything in the PC-FX BIOS or libraries that uses the R2 and R5 registers?
AFAIK, they're not used except temporarily-during-startup, and I'd like to use them for the Frame Pointer and the Thread Local variables pointer.
No, but I haven't really dug into the BIOS and official dev libraries that much.
-
OK so on another subject... I am now starting to delve into the tools we have at our disposal, now that AGE is translated. I took a 32x32 BMP image and converted it to a 6270 sprite. AGE expanded it to 128x128. Dafuq?
-
It's still the only CPU that I know of that has 2 different instructions, with different names, and different binary codes, that do exactly the same thing.
CLA when you have LDA #0 when you also have XOR A,A
SHL A when you have ADD A,A...
(Well, I guess with completely orthogonal instruction sets, such things are inevitable.)
The Saturn, OTOH, is an absolute joke of a design, with expensive bits-and-bobs thrown everywhere and lots of stuff just sitting there idle because it's got nothing to do most-of-the-time.
Your description there completely reminded me of how local municipalities (and their workers) operate over here in Japan... :-|
-
I modified trap15's sprite example to fill VRAM with an array rather than noise.
(http://www.frozenutopia.com/pcfx/spr7up_cd-0000.html)
But this is as far as I got. If I try changing the size of the sprite (using either eris_sup_spr_create or eris_sup_spr_ctrl), it vanishes. There is also no update code in the example program so it makes me wonder how the sprite's position is ever updated at all... unless liberis is automatically updating the SATB any time a change is made...
EDIT: Wait a minute... am I right in reading that the FX's 6270s can only make 16x16 sprites, completely f*cking over one of the best features of the same chip on the PCE?
-
CLA when you have LDA #0 when you also have XOR A,A
Ooooh ... I'm definitely curious which CPU has both "CLA" and "XOR A,A". I wouldn't count "LDA #0" because that would probably have an extra byte in the encoding, or an extra cycle in execution, and possible even different flag settings.
SHL A when you have ADD A,A...
(Well, I guess with completely orthogonal instruction sets, such things are inevitable.)
Yep, with those instructions it would depend upon the allowed addressing modes for each instruction.
*************
But the SH-2 has ...
Format: SHAL Rn
Abstract: T ← Rn ← 0
OpCode: 0100nnnn00100000
Description:
Arithmetically shifts the contents of general register Rn to the left by one bit, and
stores the result in Rn. The bit that is shifted out of the operand is transferred to the T bit.
Format: SHLL Rn
Abstract: T ← Rn ← 0
OpCode: 0100nnnn00000000
Description:
Logically shifts the contents of general register Rn to the left by one bit, and stores
the result in Rn. The bit that is shifted out of the operand is transferred to the T bit.
2 instructions that do exactly the same thing.
They're complemented by ...
Format: SHLL2 Rn
Abstract: Rn << 2 → Rn
Format: SHLL8 Rn
Abstract: Rn << 8 → Rn
Format: SHLL16 Rn
Abstract: Rn << 16 → Rn
Format: SHAR Rn
Abstract: MSB → Rn → T
Format: SHLR Rn
Abstract: 0 → Rn → T
Format: SHLR2 Rn
Abstract: Rn >> 2 → Rn
Format: SHLR8 Rn
Abstract: Rn >> 8 → Rn
Format: SHLR16 Rn
Abstract: Rn >> 16 → Rn
Errrmmmm ... WTF happened to "SHAR2", "SHAR8" and "SHAR16"??? They'd actually be useful, but they're nowhere to be found.
Definitely a CPU designed by a hardware engineer that never had to actually program a line of code in his life.
Of course, any self-respecting CPU designer from the time would just have put in a barrel-shifter, and provided "SHLL/SHLR/SHAR Rn,Rn" instead of that rat's-nest of stupid instructions.
Your description there completely reminded me of how local municipalities (and their workers) operate over here in Japan... :-|
Hahaha, so true everywhere! :wink:
-
(http://www.frozenutopia.com/pcfx/spr7up_cd-0003.html)
Getting somewhere... but this is rather convoluted and quite different than working with the same chip on the PCE.
-
Wait a minute... am I right in reading that the FX's 6270s can only make 16x16 sprites, completely f*cking over one of the best features of the same chip on the PCE?
Nope, you're missing something in the docs, or Google Translate is messing things up for you.
It's exactly-the-same VDC chip that's in the PCE, and it has the same 32x64 maximum sprites with the size-bits in the same place.
I think that you may be expecting a little-too-much from the current-state of liberis.
Alex has provided all the critical background stuff in there ... but the higher-level "engine" stuff (like SATB updates) is completely-missing AFAIK.
That's where you get to read the SDK docs, and perhaps get-your-feet-wet with some V810 assembly language ... or not.
Getting somewhere... but this is rather convoluted and quite different than working with the same chip on the PCE.
I'm glad that you're making progress!
It's exactly-the-same chip, with exactly-the-same data formats, how is it different to work with?
-
In order to get this sprite to display on the PCE, I would normally give it pattern values in offsets of 0x40. Here, it's a pattern value offset of 2. That does not make a whole lot of sense to me.
eris_sup_spr_set(0);
eris_sup_spr_create(0, 0, 0, 0);
eris_sup_spr_set(1);
eris_sup_spr_create(16,0,2,0);
eris_sup_spr_set(2);
eris_sup_spr_create(0,16,4,0);
eris_sup_spr_set(3);
eris_sup_spr_create(16,16,6,0);
but anyway...
_eris_sup_spr_ctrl:
mov lp, r17
setup_addr r20, r19, r18, 3
mov r6, r16
mov r7, r15
mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_write
mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_read
mov r19, r6
jal _eris_low_sup_vram_read
mov r10, r7
and r16, r7
or r15, r7
mov r19, r6
jal _eris_low_sup_vram_write
mov r17, lp
jmp [lp]
I am not sure how similar this is to the original C code I wrote, as this is nineteen flavors of Greek to me, but in theory, the only purpose of the function is to modify the high byte of the fourth word of the SATB entry.
-
OK so I did some more testing... it seems that the fourth argument of eris_sup_spr_create() affects the entire fourth word. So, I set it to 0x1180 to set a size of 32x32 with a priority of 1 and a palette of 0, then got rid of the code for the other three sprites. It worked. So, I changed it to 0x1080 to reduce it to 16x32. It worked. So, it looks like it's affecting the entire word. I can work with that for now. :) I can only surmise from this that eris_sup_spr_ctrl() is doing the same thing.
-
In order to get this sprite to display on the PCE, I would normally give it pattern values in offsets of 0x40. Here, it's a pattern value offset of 2. That does not make a whole lot of sense to me.
I've not looked at the documentation ... is he perhaps using an "index" instead of an "byte-offset"?
_eris_sup_spr_ctrl:
mov lp, r17
setup_addr r20, r19, r18, 3
mov r6, r16
mov r7, r15
mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_write
mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_read
mov r19, r6
jal _eris_low_sup_vram_read
mov r10, r7
and r16, r7
or r15, r7
mov r19, r6
jal _eris_low_sup_vram_write
mov r17, lp
jmp [lp]
It makes sense when you know that the 1st 4 parameters to a C function are passed in registers r6,r7,r8,r9, and that the return value is passed back in r10.
"lp" is just the function's return-address (unlike the 6502, it doesn't go on the stack). So he's saving it temporarily in r17 so that it doesn't get trashed by the subroutine calls (the "jal" jump-and-link instructions).
He's using r15-r20 as temporary registers (there are 32 registers).
So, that code ...
[ul][li]calculates a VRAM address[/li][li]sets that address in the VDC's MARR (READ) and MAWR (WRITE) registers[/li][li]reads the 16-bit word at that VRAM address[/li][li]ANDs it with the the contents of r6 (the original 1st parameter)[/li][li]ORs it with the the contents of r7 (the original 2nd parameter)[/li][li]writes the 16-bit word back into the VRAM address[/li][/ul]
Basically, simple stuff, but done in a really slow-and-horrible way.
BTW ... Alex's function has a bug in it. He shouldn't be using r20 without saving it on the stack.
The ABI defines it as a "callee-saved" function-preserved register, and not a "caller-saved" function-workspace register.
P.S. I'm going to "guess" that this is the kind of technical stuff that makes most people's head ache! :wink:
-
Aye... the way spr_ctrl normally works is you set a mask and then set new parameters. For example:
spr_ctrl(SIZE_MAS|FLIP_MAS, SZ_32x32|NO_FLIP);
or
spr_ctrl(FLIP_MAS, FLIP_X);
so only the bits you want to change are affected.
-
Okay so this is all starting to come together... all the differences in paradigms are starting to lose relevance. Practice always makes perfect, I guess. :)
(http://www.frozenutopia.com/pcfx/asteroid-0000.html)
Two 32x64 sprites glued together on the first 6270. What I did was write a test program in assembly that does nothing more than import a sprite file, then wrote a utility that will extract the converted data from it and put it into a neat little text file. I can then copy the text out of the text file and paste it into my program, where I have a large array that holds all the sprite data. It's not the most elegant solution but for now it works. :)
-
That's great to see on the screen! :)
-
(http://www.frozenutopia.com/pcfx/asteroid-0003.html)
I could not find a random number generator in liberis and since stdlib is disabled, I figured I would just add one manually. I implemented the basic xorshift RNG, and gave it static seeds (until I implement a "Push Run Button" part to seed it). The stars fly by from right to left and respawn at random X and Y values when they reach the left side of the screen. The right half of the asteroid on the screen is white because I was testing the eris_sup_spr_pal() function... it works. :)
What I am doing here is porting my old Asteroid Challenge demo to the PC-FX. A great deal of the code is directly portable, though any code that references graphics needs to be updated. The core logic and collision routines are 100% portable without changes from its PCE original. This is why I like C so much. ;)
EDIT: Moved further along... have added the asteroid generator.
(http://www.frozenutopia.com/pcfx/asteroid-0007.html)
-
Awesome. :)
-
As was with the PCE version, the sprites of the high score and the player shots create massive amounts of flicker due to the very large asteroids... but now I can move both of those to the second 6270 to eliminate the flicker. Woohoo :lol:
-
The game works.
(http://www.frozenutopia.com/pcfx/asteroid-0010.html)
It currently lacks asteroid-to-player collision because it runs too fast, and I have not yet added any sound aside from the CD audio music... but it's working and playable.
-
The pad code does not work on real hardware. I don't know why. It will register a value and then immediately go back to 0... and will toggle just like that as you hold down *anything*.
EDIT: I came up with a hack that works... I read the pad more than once and use the highest value as the result. That gets the job done. I have no idea what's wrong but hey, at least I figured out a workaround.
-
The game works.
Excellent! :)
But OTOH, that means that you're going to beat me to having a working PC-FX game. :cry:
The pad code does not work on real hardware. I don't know why. It will register a value and then immediately go back to 0... and will toggle just like that as you hold down *anything*.
That's another one of those things to look for in the SDK docs.
The PC-FX's joypads are hardware-serial-read rather than parallel-read, and IIRC the hardware allows for a multi-tap.
So the liberis function that you're calling may not be resetting the "read" back to the "initial" state for the pad ... or something ... or I may be totally wrong.
While you're "on-the-line" ... can I ask if you've seen anything in the PC-FX BIOS or libraries that uses the R2 and R5 registers?
AFAIK, they're not used except temporarily-during-startup, and I'd like to use them for the Frame Pointer and the Thread Local variables pointer.
No, but I haven't really dug into the BIOS and official dev libraries that much.
It doesn't look like anything in Hudson's compiler or BIOS is using R2 or R5, much to my surprise and happiness.
It does look like the BIOS "fsys" library is using $54 (or maybe $58) bytes of GP-relative storage from -32768[GP] to -32684[GP], but I think that I can take care of that in GCC's linker script so that we can still use those library functions.
My "stack-handling" problem is about 90% fixed ... it's something that I broke when doing the incredibly-ugly update from GCC 4.5.4 to GCC 4.7.4. #-o
-
Excellent! :)
But OTOH, that means that you're going to beat me to having a working PC-FX game. :cry:
Sowwie... :cry: but on the plus side... that means that we're really super close to having a completely useful toolchain, right? :D
That's another one of those things to look for in the SDK docs.
The PC-FX's joypads are hardware-serial-read rather than parallel-read, and IIRC the hardware allows for a multi-tap.
So the liberis function that you're calling may not be resetting the "read" back to the "initial" state for the pad ... or something ... or I may be totally wrong.
I am not sure what the problem is myself and I have not tried doing it through just regular port reads (I assume liberis already does this though), but I worked around it by reading the port multiple times and using the highest value.
In other fun stuff, I tried implementing a track loop function... but it froze up the system. The SCSI-2 docs are HORRIBLE to comprehend... I was barely able to get CD audio playing at all, and even then, I can only send a single play command because successive commands lock the whole machine up. I am assuming it has something to do with the flag that tells the device to return a result immediately when a command is sent, but I have NO idea how to even get return values from the drive, nor am I able to figure out how to set ANY of the code pages to configure ANYTHING. I realize I'm not a coder but ffs, this shit's written for robots hocked up on Chesto berries.
-
More fun trial-and-error... I used AGE to convert a 256 color BMP to a 256 color KING bitmap, then wrote a custom utility to strip off the 256 byte header, and used yet another tool I have that converts any file into a word array, plus my palette conversion utility that converts a JASC-PAL to a YUV palette array... bottom line, through a lot of experimentation and a lack of proper documentation, I got a nifty 256 color image to display on KING BG0.
(http://www.frozenutopia.com/pcfx/bgking_cd-0004.html)
Here's the code for it... this requires no external resources, as it's entirely array-based. I used bg7up.c as the initial template for this program, and made changes where needed.
http://www.frozenutopia.com/pcfx/bgking.c
I tried to paste the code into this msg but it exceeded the character limit for a post, so I just uploaded the source instead.
-
Sowwie... :cry: but on the plus side... that means that we're really super close to having a completely useful toolchain, right? :D
I am not sure what the problem is myself and I have not tried doing it through just regular port reads (I assume liberis already does this though), but I worked around it by reading the port multiple times and using the highest value.
I think that your 2nd comment answers your 1st question.
We're definitely on the "path" to having a completely useful toolchain, and it's nice that you're getting some pretty stuff on the screen, but ...
From my POV, we've got a "broken" compiler, and a "broken" library, with minimal functionality.
It's a good, maybe-even-a-great, start ... but it's just a "start". There's one heck of a long way to go to have a "completely useful toolchain".
Now, I've got the patience to keep-on-plugging-away it, but progress with GCC is slow-and-very-very-painful.
-
Now, I've got the patience to keep-on-plugging-away it, but progress with GCC is slow-and-very-very-painful.
And this is why you're so awesome. :D
EDIT: I erased the rest of this post because I'm retarded.
-
Now, I've got the patience to keep-on-plugging-away it, but progress with GCC is slow-and-very-very-painful.
And this is why you're so awesome. :D
Hahaha ... perhaps "stupid" is a better word! ](*,)
Anyway, I think that I got the "stack-problem" in GCC 4.7.4 fixed late last-night. Now it needs some more testing to make sure that I wasn't hallucinating.
Then I still want to "break" it again and implement a different ABI, if I can. :-s
The current ABI probably seemed-like-a-good-idea-at-the-time, but it breaks the possibility of in-game stack backtraces which are incredibly-helpful to decent debugging.
Luckily, NEC's idea of reserving the R2 and R5 registers for things that nobody-ever-used-in-practice gives us 2 free registers to use in a new ABI (if I can wrestle GCC into compliance).
Again ... very low-level technical stuff, but it's part of making the toolchain "usable" for any of the poor-suckers that decide to give-it-a-try. :wink:
-
I'll leave the low-end stuff to you, heh. :lol: I'm more of the end-user type... and I can assure you that us poor suckers are going to be numerous once this is more refined. ;)
I did finally get ADPCM playback working, and how. It's not trivial to explain how it works, but I will probably write up a quick tutorial on it at some point, as well as other things I've managed to get working on the end-user side of the struggle. Not having access to a whole lot of proper, readable documentation has proven to be the largest hurdle, and trying to find any kind of example source code with google usually returns snippets that use existing libraries rather than going straight to the metal. My experiences with SCSI have been the worst offender on both counts.
-
Anyway, I think that I got the "stack-problem" in GCC 4.7.4 fixed late last-night. Now it needs some more testing to make sure that I wasn't hallucinating.
The good news ... "yes", that "stack problem" seems to be fixed! :D
And with-a-few-more-changes, newlib is now actually linking into a test-app, and newlib's "strlen" is working.
With yet-more-changes, "sprintf" is actually compiled and linked into the test-app.
The bad news ... that's shown-up the next bug in the compiler, "varargs" are not working. #-o
Oh well ... onto the next piece of nasty debugging. ](*,)
I did finally get ADPCM playback working, and how. It's not trivial to explain how it works, but I will probably write up a quick tutorial on it at some point, as well as other things I've managed to get working on the end-user side of the struggle.
Great! Any documentation that you can do would be extremely helpful.
-
OK sooooo.... ADPCM. This turned out easier than I thought... I was just doing a few things wrong, which can happen when you code for so long without resting.
eris_king_set_kram_pages(0, 0, 0, 0);The last value is the ADPCM KRAM page. I leave it at 0. You can put it at 1, which means you have to set bit 31 when you load a sample into KRAM.
out8(0x120,1);Bits 0 and 1 set the sample rate. I set this to 1 for 16kHz. 0 is 32kHz, 2 is 8kHz and 3 is 4kHz. Bits 2 and 3 set linear interpolation for channels 0 and 1, respectively. Bits 4 and 5 reset channels 0 and 1 respectively. I left them all alone for now. Experiment at your own leisure.
out8(0x122,0x3F);
out8(0x124,0x3F);
out8(0x126,0x3F);
out8(0x128,0x3F);Set the left/right volumes of channel 0 and 1 to max (range is 0x0 - 0x3F). liberis has a function for this but as you've noticed, I'm avoiding liberis functions for now and just using the ports directly... I know the ports work, not so much the functions. :)
out16(0x600,0x51);
out16(0x604,0);
out16(0x600,0x52);
out16(0x604,0);Port 0x600, when written, is Register Select on the KING. For this, I'm first telling KING to select register 0x51, which is the channel control for ADPCM channel 0. Bit 0 is the buffer select (0 for sequential and 1 for ring), bit 1 enables end interrupt and bit 2 enables intermediate interrupt. I'm not 100% sure exactly how the interrupts work just yet so I leave them alone for now. Anyway, writing to 0x604 after selecting a register configures that register with the data you send it. Register 0x52 will configure ADPCM channel 1.
That's pretty much it for getting ADPCM set up. To actually play a sample, you have to do a few things.
out16(0x600,0x58);0x58 is the ADPCM channel 1 start address. This is going to tell KING where to get the ADPCM data from. ADPCM data is kept in normal KRAM. Using 0x5C instead of 0x58 does the same for channel 1.
out16(0x604,(0x2000/256));The KRAM address has to be divided by 256. I wrote this out longhand to demonstrate.
out16(0x600,0x59);Now I'm telling KING to set the end address. This is 0x59 for channel 0 and 0x5D for channel 1.
out16(0x604,(0x2000+10417));The end address is an absolute address, not a divided one. My ADPCM sample is 20834 bytes long, but since addressing is in words, I cut this value in half. I do believe that if your samples' addresses are outside of the range of 16 bits that you will also need to send the upper bits of the address to 0x606... I've never tested this but this seems logical.
Now that you've told KING the range of the sample, it's time to actually play it.
out16(0x600,0x50);0x50 is the register that controls playback for both channels. That also means that you will need to be mindful of samples already playing.
out16(0x604,5);Finally, play the sample. Bit 0 plays the sample configured for channel 0 and bit 1 plays the sample configured for channel 1. Bits 2 and 3 control the sampling rate and use the same scheme as earlier. Since I want 16kHz, I set bit 2 on and bit 3 off. So... bit 0 on, bit 1 off, bit 2 on, bit 3 off... value is 5. This plays the ADPCM sample in channel 0 at 16kHz.
If you need to stop a sample while it's playing, select register 0x50 and send a 0 to the bit of the channel you wish to stop. Writing just 0 to 0x604 will stop both channels. You can read 0x604 to see which channels are currently in use, and then just stop either of them if you want to. If you set the buffer type to Ring, the sample will playback infinitely until you tell it to stop in this manner... or so the docs state.
So that pretty much sums up how to use ADPCM on the PC-FX.
-
To continue on the ADPCM kick, I figure I should add in some more details.
So in my example, I give it a starting address of 0x2000. That's because I've loaded my ADPCM array data into KRAM at that point. Loading data into KRAM is easy...
eris_king_set_kram_write(0x2000, 1);
for(i = 0; i < sizeof(voxarray)-1; i++)
eris_king_kram_write(voxarray[i]);
I have a u16 array called voxarray that has all the ADPCM data in it. The two parameters of the first function call are the address and the auto-increment amount (1 word, in this case). Each time you write a word to KRAM, the pointer moves up 1 word, so you don't have to keep setting the address. Nifty and convenient methinks.
So... getting the ADPCM data into your source code... well, this is where having some coding knowledge worked out well for me. I coded a simple utility called any2arr which takes any file you give it and creates a header with the data of that file as a u16 array.
http://www.frozenutopia.com/pcfx/any2arr.7z
Making ADPCM files is also easy... just snag a copy of sox. To make the samples for Asteroid Challenge FX, I used sox like so:
sox -r 16000 boom.wav boom.vox
The -r 16000 tells it to use 16kHz, the .wav is obviously my source audio, and the .vox is the output file. sox knows to make an ADPCM file based on the .vox extension. So, just convert your file to a .vox with sox, run the .vox file through any2arr, and you've got your ADPCM data, ready to include into your program.
EDIT: Forgot to mention... since we're using words here, take the filesize of your .vox file and divide it in half to get the length. Take that divided value and add it to your starting address to get the ending address that you need. I think I did mention this briefly in the first post about this but it bears mentioning again, because reasons.
-
So... getting the ADPCM data into your source code... well, this is where having some coding knowledge worked out well for me. I coded a simple utility called any2arr which takes any file you give it and creates a header with the data of that file as a u16 array.
Good stuff! :)
But you're really going-out-of-your-way to avoid using "objcopy" or an assembly file with an "incbin", aren't you! :wink:
http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967
************
On my side of things ... GCC is now correctly passing the varargs to "sprintf" ... where it all just dies. ](*,)
-
But you're really going-out-of-your-way to avoid using "objcopy" or an assembly file with an "incbin", aren't you! :wink:
Honestly... I had no idea about that... heh :D I just go with what I know... remember, I'm not a hardcore coder like you are, I'm just a game developer who can code a little. :)
-
Honestly... I had no idea about that... heh :D I just go with what I know... remember, I'm not a hardcore coder like you are, I'm just a game developer who can code a little. :)
The point is ... you're finding problems, and you're solving them. That's brilliant! 8)
It's just that sometimes you're hitting problems that have already been solved, and this is one of those cases. :wink:
objcopy -I binary -O elf32-v810 -B v810 filename.bin filename.o
-
Well, the one problem I still can't figure out is the SCSI bit. I'm experimenting with KING's SCSI ports now. I read 0x600 and 0x602 for now... 0x602 *should* contain the SCSI status, if I'm reading the daifukkat docs correctly. It's returning 1101100, which indicates Busy, Request, C/D, and I/O are all set to 1. I figured maybe I could use this to determine if the system knew when the audio track had finished playing. However, the status never changes. So I guess this is out.
-
It's returning 1101100, which indicates Busy, Request, C/D, and I/O are all set to 1. I figured maybe I could use this to determine if the system knew when the audio track had finished playing. However, the status never changes. So I guess this is out.
That sounds very-much-like what I was seeing in the Xanadu 2's custom CD-reading code.
I think that those bits are all just to do with controlling communication over the SCSI bus itself.
If you want to find out if the CD has finished playing a track, I suspect that you'll have to send it some kind of a "status query" command.
-
Here's what the SCSI-2 docs say, but I am not able to make heads or tails of this, honestly...
PLAY AUDIO commands with the immediate bit set in the audio control
mode return status as soon as the command has been validated (which may
involve a seek to the starting address). The playback operation
continues and may complete without notification to the initiator.
Error termination of audio operations shall be reported to the
initiator by returning immediate CHECK CONDITION status to the next
command (except for REQUEST SENSE and INQUIRY.) The deferred error
sense data (see 8.2.14.2.) is used to indicate that the error is not
due to the current command.
The status of the play operation may be determined by issuing a REQUEST
SENSE command. The sense key is set to NO SENSE and the audio status
(see 14.2.10) is reported in the additional sense code qualifier field.
1, I have no idea how to set the audio control mode. The docs are very, very dry and hard to follow. 2, I have no idea how to receive the results from an SCSI command.
-
Here's what the SCSI-2 docs say, but I am not able to make heads or tails of this, honestly...
Hahaha ... welcome to my world! :wink:
PLAY AUDIO commands with the immediate bit set in the audio control...
Basically, the return-code from "PLAY AUDIO" just says whether the CD drive has validated and accepted the "PLAY AUDIO" command.
You've got to send the drive a "REQUEST SENSE" command and look at the return code to see if it is still playing.
I have no idea how to receive the results from an SCSI command.
That's going to be a problem.
You should see an example of reading the result of a "REQUEST SENSE" command somewhere in Alex's examples ... I can't imagine how he could have managed to read data from the CD without using it.
-
Unfortunately, I see no mention of it in his examples, and of course, his source is next to impossible for someone like me to read... but I tried at least. :)
http://www.staff.uni-mainz.de/tacke/scsi/SCSI2-08.html
^^^ has the "details" of REQUEST SENSE. This is where getting a response becomes dim... I have no idea what to read to get this response. It says it returns 18 bytes... where?
Okay so one other thing is that eris_low_scsi_command() returns an int... but does not actually say what the return value might actually be. From what limited amount I understand of our lovely assembler here, I assume that this is the entirety of the function:
_eris_low_scsi_command:
mov lp, r15
mov 0, r14
mov 1, r13
movea 0x84, r0, r12
mov 3, r11
mov r0, r10
out.h r11, 0x600[r0]
out.h r0, 0x604[r0]
out.h r0, 0x600[r0]
add 2, r11
out.h r12, 0x604[r0]
scsi_delay
out.h r13, 0x600[r0]
out.h r13, 0x604[r0]
scsi_delay
out.h r13, 0x600[r0]
out.h r11, 0x604[r0]
scsi_delay
1: jal _eris_low_scsi_get_phase
be 1b
scsi_delay
out.h r13, 0x600[r0]
out.h r0, 0x604[r0]
scsi_delay
1: jal _eris_low_scsi_get_phase
cmp 4, r10 # command
bne 1b
mov 3, r11
mov 2, r10
out.h r11, 0x600[r0]
out.h r10, 0x604[r0]
1: in.h 0x602[r0], r11
andi 0x20, r11, r11
be 1b
br 2f
1:
mov 1, r10
mov r0, r11
cmp r14, r7
bnh 3f
ld.b 0[r6], r11
add 1, r6
3:
add 1, r14
movea 0x11, r0, r12
out.h r0, 0x600[r0]
out.h r11, 0x604[r0]
out.h r10, 0x600[r0]
out.h r10, 0x604[r0]
out.h r10, 0x600[r0]
out.h r12, 0x604[r0]
3: in.h 0x602[r0], r11
andi 0x20, r11, r11
bne 3b
out.h r10, 0x600[r0]
out.h r10, 0x604[r0]
3: in.h 0x602[r0], r11
andi 0x20, r11, r11
be 3b
2: jal _eris_low_scsi_get_phase
cmp 4, r10 # command
be 1b
mov 1, r11
mov 3, r10
out.h r11, 0x600[r0]
out.h r0, 0x604[r0]
out.h r10, 0x600[r0]
out.h r0, 0x604[r0]
mov r14, r10
mov r15, lp
jmp [lp]
-
Using eris_low_scsi_status() freezes the system. Every. Single. Time. No matter what's going on... even if nothing's going on.
Sending another SCSI command freezes the system... even if I've also used eris_low_scsi_abort(). eris_low_scsi_abort() itself does not lock up the system, but using eris_low_scsi_command() a second time does.
At this point, my only guess is that something in the SCSI setup is misconfigured.
EDIT: Using eris_low_scsi_reset() allows me to use eris_low_scsi_command() a second time... but this is more than likely not the way it's supposed to work...
-
Using eris_low_scsi_status() freezes the system. Every. Single. Time. No matter what's going on... even if nothing's going on.
All that I can say is that Alex's SCSI and SCSI_DMA examples seem to work ... well, they do in Mednafen, I've not tried them on my PC-FXGA.
That suggests that he's got the basics right ... but he may not have provided all the functions that you need (i.e. a REQUEST SENSE function).
On my side of things ... GCC is now correctly passing the varargs to "sprintf" ... where it all just dies. ](*,)
So, it turns out that I'd fixed the varargs stack allocation, but I still had an error in the code-generation that actually saved the varargs themselves to the stack. #-o
With that fixed, then modifying Alex's "hello" example's printing code to ...
printstr("Hello World!", 10, 0x20, 1);
printstr("Love, NEC", 11, 0x38, 0);
i = sprintf(str, "Eat %X!", 0xdeadbeef);
printstr(str, ((32 - i) / 2), 0x48, 0);
... gives ...
(http://farm2.staticflickr.com/1666/25997926105_0a7c6729f9_o.png)
That's using "strlen" and "sprintf" ... and "sprintf" requires a "malloc", so we've got functional memory-allocations, too! :D
It's "Miller Time" ... but with something that actually has some flavor, instead. :wink:
-
Yes, they work... but unfortunately, they explain nada. He never once uses eris_low_scsi_status() in his examples, although I am seeing that the function is being called in the assembly source in several other functions.
I am not sure what eris_low_scsi_data_in() does. Perhaps this is how to get the return values from things like REQUEST SENSE. Of course, the docs offer absolutely no context... as usual. Oh well... only one way to find out, I guess.
That's using "strlen" and "sprintf" ... and "sprintf" requires a "malloc", so we've got functional memory-allocations, too! :D
It's "Miller Time" ... but with something that actually has some flavor, instead. :wink:
Haha :D well that's awesome... good string functions are always nice to have. Hopefully this doesn't introduce too much overhead. And root beer, please... :lol:
EDIT: Because REQUEST_SENSE requires me to use eris_low_scsi_command(), of course actually using it crashes the machine after I've already sent 0x48. Something is clearly jamming up SCSI when I tell it to play an audio track.
EDIT2: ...and if I sent a REQUEST_SENSE before I send the audio play command, it *also* jams up the system. What. The. f*ck.
EDIT3: I commented out the eris_low_scsi_data_in() line... which was returning 0 anyway so I am pretty sure that this is *not* how to get return results. The system crashes when I send a second SCSI command. I'm no expert here but I am positive at this point that this is exactly where the flaw is. Something to do with using eris_low_scsi_command() from within the C code is the culprit. Using eris_low_scsi_reset() does, of course, reset the SCSI subsystem so additional commands can be sent... but I am 99.9999% positive that this is not the way you're supposed to have to do things. The only other thing I can think of is something to do with the SCSI phase... although it appears that eris_low_scsi_command() is already waiting for the correct phase... AAAAAAAAAAAAAA
-
Yes, they work... but unfortunately, they explain nada. He never once uses eris_low_scsi_status() in his examples, although I am seeing that the function is being called in the assembly source in several other functions.
I just had a quick look, and the impression that I'm getting is that the "eris_low_*" functions really aren't supposed to be called by themselves from C.
It's hard to tell because the assembly code is very hard-to-read because he hasn't bothered to use constants, or sensible labels, or to actually add comments to explain what's going on.
I can see that there's going to have to be some major re-writing going on.
-
This reminds me, that I really need to make some sort of effort to setup that PCFXGA crap.
lol.
-
I can see that there's going to have to be some major re-writing going on.
I'll take the plunge and attempt to learn V810 assembly better then... looks like we've got a massive project on our hands here and it's gonna take some combined brainpower.
-
This reminds me, that I really need to make some sort of effort to setup that PCFXGA crap.
Bueller? Bueller? Bueller?
I'll take the plunge and attempt to learn V810 assembly better then... looks like we've got a massive project on our hands here and it's gonna take some combined brainpower.
To be fair to Alex ... I suspect that at-least-some of the reason for his sparse assembly-code was just working with the old GAS assembler from binutils-2.10.
The GNU folks put a lot of work into making GAS more "programmer-friendly" over the last 15 years.
If you've programmed any CPU in assembler before, then I think that you'll find it really pleasant, especially if you've tried to read other early-RISC assembly, like MIPS or SH2.
The big thing that initially seems "weird" to folks that are used to 6502/Z80/68000/x86 is that there are no addressing-modes in the instructions. Everything is just register-to-register, and you have to load/save registers to memory explicitly.
It makes-up for that by having lots of registers, so that you really don't need to load/save "temporary" stuff inside a function very often. And the "big-win" is that most instructions run in 1-cycle (effective throughput, with a 5-cycle pipeline) .
With the CPU running at 21Mhz, with mostly-single-cycle instructions, it's one-heck-of-a-lot faster than the 7MHz HuC6280 with it's 2-to-7-cycle instructions.
Well ... until you hit a pipeline-stall, anyway. The docs from the Nintendo Seminar that I sent you do a good job of explaining the basic theory, and the (few) pipeline-stall conditions.
I already posted an example of what my V810 assembly-code looks like, taking advantage of running the source-code through the C-preprocessor to provide "macro" capability to the GNU assembler ...
http://www.pcenginefx.com/forums/index.php?topic=19619.msg421022#msg421022
-
FWIW, I'd forgotten what it was like to program in C on some of these old architectures.
GCC on the PC-FX really, really, really doesn't like working with 8-bit or 16-bit local/global/struct variables.
You're much, much, much better off declaring everything as an "int" or "unsigned", or "int32_t" and "uint32_t" if you care about the sizes.
This is one of those cases where "portable" C code ... isn't. It'll cripple your performance. #-o
-
In cycle-critical applications, such as a really busy action game, a good coder knows that to get top performance, you use the most CPU-efficient variable type and you give not one shit about how much space it takes up in memory. If using ints is the fastest, then you use ints... bottom line. :)
-
I took a quick look at the VirtualBoy's "libgccvb" source code, and was surprised to see so many uses of "u8" and "u16" in the code.
The V810 CPU was designed to handle 32-bit variables ... and it doesn't do any arithmetic operations on 16-bit or 8-bit values.
That means that the compiler needs to do a lot of masking/sign-extending when it's asked to deal with 16-bit or 8-bit variables, just so that it keeps the results correct within the limits of 16-bit or 8-bit rounding.
You really should be using "int" and "unsigned" as much as possible, and avoid "short" and "char" variables.
I thought that it would be interesting to see how the different GCC compiler versions compile a couple of simple C functions.
In each case, the original libgccvb version is first, and then 1 or 2 versions replacing the "u16" and "u8" variables with "unsigned" instead.
It seems strange to me that GCC 4.4.2 is doing such a relatively-poor job compared to GCC 2.9.5 or GCC 4.7.4, I wonder what went wrong?
All examples are compiled with "-O2 -fomit-frame-pointer".
****************************************************************************************
****************************************************************************************
void copymem (u8* dest, const u8* src, u16 num)
{
u16 i;
for (i = 0; i < num; i++) {
*dest++ = *src++;
}
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_copymem: andi 65535,r8,r8 _copymem: andi 65535,r8,r8 _copymem: andi 65535,r8,r8
be .L1 mov 0,r10 be .L4
addi -1,r8,r11 cmp r8,r10 mov 0,r10
andi 65535,r11,r11 bnl .L4 .L3: mov r7,r11
add 1,r11 .L6: add 1,r10 add r10,r11
add r6,r11 ld.b 0[r7],r11 ld.b 0[r11],r12
.L3: ld.b 0[r7],r10 andi 65535,r10,r10 mov r6,r11
add 1,r7 add 1,r7 add r10,r11
st.b r10,0[r6] st.b r11,0[r6] add 1,r10
add 1,r6 add 1,r6 st.b r12,0[r11]
cmp r11,r6 cmp r8,r10 andi 65535,r10,r11
bne .L3 bl .L6 cmp r11,r8
.L1: jmp [r31] .L4: jmp [r31] bh .L3
.L4: jmp [r31]
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
****************************************************************************************
****************************************************************************************
void copymem2 (u8* dest, const u8* src, unsigned num)
{
unsigned i;
for (i = 0; i < num; i++) {
*dest++ = *src++;
}
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_copymem2:mov r6,r11 _copymem2:mov 0,r11 _copymem2:cmp r0,r8
add r8,r11 cmp r8,r11 be .L10
cmp 0,r8 bnl .L10 mov 0,r10
be .L7 .L12: ld.b 0[r7],r10 .L9: mov r7,r11
.L11: ld.b 0[r7],r10 add 1,r11 add r10,r11
add 1,r7 add 1,r7 ld.b 0[r11],r12
st.b r10,0[r6] st.b r10,0[r6] mov r6,r11
add 1,r6 add 1,r6 add r10,r11
cmp r11,r6 cmp r8,r11 st.b r12,0[r11]
bne .L11 bl .L12 add 1,r10
.L7: jmp [r31] .L10: jmp [r31] cmp r10,r8
bh .L9
.L10: jmp [r31]
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
****************************************************************************************
****************************************************************************************
void addmem (u8* dest, const u8* src, u16 num, u8 offset)
{
u16 i;
for (i = 0; i < num; i++) {
*dest++ = (*src++ + offset);
}
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_addmem: andi 65535,r8,r8 _addmem: andi 65535,r8,r8 _addmem: andi 65535,r8,r8
andi 255,r9,r9 mov 0,r11 andi 255,r9,r9
cmp 0,r8 andi 255,r9,r9 cmp r0,r8
be .L13 cmp r8,r11 be .L20
addi -1,r8,r11 bnl .L22 mov 0,r10
andi 65535,r11,r11 .L24: mov r9,r10 .L19: mov r7,r11
add 1,r11 add 1,r11 add r10,r11
add r6,r11 ld.b 0[r7],r12 ld.b 0[r11],r12
.L15: ld.b 0[r7],r10 andi 65535,r11,r11 mov r6,r11
add 1,r7 add r12,r10 add r10,r11
add r9,r10 add 1,r7 add r9,r12
st.b r10,0[r6] st.b r10,0[r6] add 1,r10
add 1,r6 add 1,r6 st.b r12,0[r11]
cmp r11,r6 cmp r8,r11 andi 65535,r10,r11
bne .L15 bl .L24 cmp r11,r8
.L13: jmp [r31] .L22: jmp [r31] bh .L19
.L20: jmp [r31]
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
****************************************************************************************
****************************************************************************************
void addmem2 (u8* dest, const u8* src, unsigned num, u8 offset)
{
unsigned i;
for (i = 0; i < num; i++) {
*dest++ = (*src++ + offset);
}
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_addmem2: mov r6,r11 _addmem2: mov 0,r12 _addmem2: andi 255,r9,r9
andi 255,r9,r9 andi 255,r9,r9 cmp r0,r8
add r8,r11 cmp r8,r12 be .L20
cmp 0,r8 bnl .L22 mov 0,r10
be .L18 .L24: mov r9,r10 .L19: mov r7,r11
.L22: ld.b 0[r7],r10 ld.b 0[r7],r11 add r10,r11
add 1,r7 add 1,r12 ld.b 0[r11],r12
add r9,r10 add r11,r10 mov r6,r11
st.b r10,0[r6] add 1,r7 add r10,r11
add 1,r6 st.b r10,0[r6] add r9,r12
cmp r11,r6 add 1,r6 st.b r12,0[r11]
bne .L22 cmp r8,r12 add 1,r10
.L18: jmp [r31] bl .L24 cmp r10,r8
.L22: jmp [r31] bh .L19
.L20: jmp [r31]
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
****************************************************************************************
****************************************************************************************
void addmem3 (u8* dest, const u8* src, unsigned num, unsigned offset)
{
unsigned i;
for (i = 0; i < num; i++) {
*dest++ = (*src++ + offset);
}
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_addmem3: cmp 0,r8 _addmem3: mov 0,r12 _addmem3: cmp r0,r8
be .L24 cmp r8,r12 be .L25
andi 255,r9,r9 bnl .L28 andi 255,r9,r9
add r6,r8 .L30: mov r9,r10 mov 0,r10
.L26: ld.b 0[r7],r10 ld.b 0[r7],r11 .L24: mov r7,r11
add 1,r7 add 1,r12 add r10,r11
add r9,r10 add r11,r10 ld.b 0[r11],r12
st.b r10,0[r6] add 1,r7 mov r6,r11
add 1,r6 st.b r10,0[r6] add r10,r11
cmp r8,r6 add 1,r6 add r9,r12
bne .L26 cmp r8,r12 st.b r12,0[r11]
.L24: jmp [r31] bl .L30 add 1,r10
.L28: jmp [r31] cmp r10,r8
bh .L24
.L25: jmp [r31]
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
****************************************************************************************
****************************************************************************************
-
I think that I have figured-out how to let GCC know that "ld" instruction sign-extends variables into an int.
Here are a coupe of examples of how it effects the code with newlib's "strlen" function, and then some variations on it.
The variations show how the generated code changes when things get a little bit more complex when modifying "strlen" to change the comparison so that the compiler can't just short-cut the check for zero.
The thing to pay particular attention to is the number of instructions in the inner loop.
It shows, again, that if you choose to use C on a processor like the V810, then there are definitely tricks to know that will improve the code-generation.
****************************************************************************************
****************************************************************************************
ORIGINAL FUNCTION FROM NEWLIB 2.2.0
size_t strlen (const char *str)
{
const char *start = str;
while (*str)
str++;
return str - start;
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_strlen: ld.b 0[r6],r10 _strlen: ld.b 0[r6],r10 _strlen: ld.b 0[r6],r10
cmp 0,r10 mov r6,r11 shl 24,r10
be .L42 cmp r0,r10 sar 24,r10
mov r6,r10 be .L46 be .L39
.L41: add 1,r10 .L47: add 1,r6 mov r6,r10
ld.b 0[r10],r11 ld.b 0[r6],r10 .L40: add 1,r10
cmp 0,r11 cmp r0,r10 ld.b 0[r10],r11
bne .L41 bne .L47 shl 24,r11
sub r6,r10 .L46: mov r6,r10 bne .L40
jmp [r31] sub r11,r10 sub r6,r10
.L42: mov 0,r10 jmp [r31] .L39: jmp [r31]
jmp [r31]
****************************************************************************************
****************************************************************************************
MARK THE END-OF-STRING WITH A NON-ZERO CONSTANT
size_t strlen2 (const char *str)
{
const char *start = str;
while (*str != 1)
str++;
return str - start;
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_strlen2: ld.b 0[r6],r10 _strlen2: ld.b 0[r6],r10 _strlen2: ld.b 0[r6],r11
cmp 1,r10 mov r6,r11 shl 24,r11
be .L47 cmp 1,r10 sar 24,r11
mov r6,r10 be .L51 cmp 1,r11
.L46: add 1,r10 .L52: add 1,r6 be .L49
ld.b 0[r10],r11 ld.b 0[r6],r10 mov r6,r10
cmp 1,r11 cmp 1,r10 .L46: add 1,r10
bne .L46 bne .L52 ld.b 0[r10],r11
sub r6,r10 .L51: mov r6,r10 shl 24,r11
jmp [r31] sub r11,r10 sar 24,r11
.L47: mov 0,r10 jmp [r31] cmp 1,r11
jmp [r31] bne .L46
sub r6,r10
jmp [r31]
.L49: mov 0,r10
jmp [r31]
****************************************************************************************
****************************************************************************************
PASS THE END-OF-STRING MARKER IN AS A "char" PARAMETER
int strlen3 (const char *str, char eos)
{
const char *start = str;
while (*str != eos)
str++;
return str - start;
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_strlen3: shl 24,r7 _strlen3: shl 24,r7 _strlen3: ld.b 0[r6],r10
sar 24,r7 sar 24,r7 shl 24,r7
ld.b 0[r6],r10 ld.b 0[r6],r10 mov r7,r12
cmp r7,r10 mov r6,r11 shl 24,r10
be .L52 cmp r7,r10 sar 24,r12
mov r6,r10 be .L56 cmp r7,r10
.L51: add 1,r10 .L57: add 1,r6 be .L56
ld.b 0[r10],r11 ld.b 0[r6],r10 mov r6,r10
cmp r7,r11 cmp r7,r10 .L53: add 1,r10
bne .L51 bne .L57 ld.b 0[r10],r11
sub r6,r10 .L56: mov r6,r10 shl 24,r11
jmp [r31] sub r11,r10 sar 24,r11
.L52: mov 0,r10 jmp [r31] cmp r12,r11
jmp [r31] bne .L53
sub r6,r10
jmp [r31]
.L56: mov 0,r10
jmp [r31]
****************************************************************************************
****************************************************************************************
PASS THE END-OF-STRING MARKER IN AS AN "int" PARAMETER
int strlen4 (const char *str, int eos)
{
const char *start = str;
while (*str != eos)
str++;
return str - start;
}
********* GCC 4.7.4 ******************* GCC 2.9.5 ******************* GCC 4.4.2 ********
_strlen4: ld.b 0[r6],r10 _strlen4: ld.b 0[r6],r10 _strlen4: ld.b 0[r6],r10
cmp r7,r10 mov r6,r12 shl 24,r10
be .L57 cmp r7,r10 sar 24,r10
mov r6,r10 be .L61 cmp r7,r10
.L56: add 1,r10 .L62: add 1,r6 be .L63
ld.b 0[r10],r11 ld.b 0[r6],r10 mov r6,r10
cmp r7,r11 mov r10,r11 .L60: add 1,r10
bne .L56 cmp r7,r11 ld.b 0[r10],r11
sub r6,r10 bne .L62 shl 24,r11
jmp [r31] .L61: mov r6,r10 sar 24,r11
.L57: mov 0,r10 sub r12,r10 cmp r7,r11
jmp [r31] jmp [r31] bne .L60
sub r6,r10
jmp [r31]
.L63: mov 0,r10
jmp [r31]
****************************************************************************************
****************************************************************************************
-
Just a quick (technical) update on the PC-FX toolchain ...
The Good:
A new stack-frame layout is implemented, and R2 is now the permanent-frame-pointer instead of the compiler just using R29 whenever a frame-pointer is needed.
*****************************
GCC 1999-ABI V850 STACK FRAME (old PC-FX GCC 2.9.5 compiler)
CALLER
incoming-arg4
ap-> 16-bytes-reserved
CALLEE
saved-lp
saved-??
fp-> saved-fp
local-variables
outgoing-arg?
outgoing-arg4
sp-> 16-bytes-reserved
*****************************
GCC 2016-ABI V810 STACK FRAME (new PC-FX GCC 4.7.4 compiler)
CALLER
fp-> ap-> incoming-arg4
CALLEE
saved-fp
saved-lp
saved-??
local-variables
outgoing-arg?
sp-> outgoing-arg4
*****************************
"-mprolog-function" is working, but I've stopped it from being automatically-enabled whenever any optimization is requested.
The new stack frame layout reduces the code-size of the prolog functions so that there's a good chance that they'll stay in the V810's instruction cache more often. Note: the new prolog functions always save the FP and the LP when they're used.
A stack backtrace is now possible when either "-fno-omit-frame-pointer" or "-mprolog-function" is used.
Any C "leaf" functions (i.e. functions that don't call other functions) will omit the prolog function if they don't destroy any callee-saved register, and so small-fast-utility-code will still run as-fast-as-possible.
The NEC-standard register conventions are still the same, except for R2 now being the FP.
Any assembly langauge code that reads arguments off the stack will need to subtract 16 from their offset.
The Bad:
Any C "interrupt-handler" functions are probably broken at the moment, until I get around to fixing them.
Does anyone actually write interrupt-handlers in C???
The compiler generates some pretty slow register-saving code for them, so I sort-of assume that folks just write then in assembly. Am I wrong?
The Future: (long term - i.e. not until Xanadu is finished)
I'd like to add a few compiler intrinsics for some of the V810 opcodes, particularly the string opcodes and the in/out opcodes. That would allow the compiler to easily in-line some stuff that people have to drop into assembly to do.
It would also be a thought to contemplate changing the standard register usage so that R26-R29 are not callee-saved registers, and so avoid the compiler from having to save them on the stack whenever someone wants to use a string opcode. But doing so would break all current assembly-language code, and I suspect that people wouldn't want that. "Yes", the change in stack-offset in the new ABI also breaks things ... but that's an easy thing to find/fix. Changing ALL the registers would be a much more complicated thing to fix.
-
I fixed the "interrupt_handler" to where it's working again, although I'm not using the helper-functions anymore, because I really can't see the point.
I could make the code a tiny bit smarter ... but IMHO it's already a little bit better than GCC's V850 code, so any further work on it can wait.
Now ... this is it for me for a while on the PC-FX, or else I'll be in trouble! :wink:
************************************
volatile int __attribute__ ((zda)) zda_frame_count = 0;
__attribute__ ((interrupt_handler)) void my_irq1 (void)
{
for (int i = 0; i < 100; i++)
zda_frame_count++;
}
_my_irq1: add -4,sp
st.w r1,0[sp]
add -8,sp
st.w r10,0[sp]
movea 100,r0,r10
st.w r11,4[sp]
.L7: ld.w zdaoff(_zda_frame_count)[r0],r11
add -1,r10
add 1,r11
st.w r11,zdaoff(_zda_frame_count)[r0]
cmp 0,r10
bne .L7
ld.w 0[sp],r10
ld.w 4[sp],r11
add 8,sp
ld.w 0[sp],r1
add 4,sp
reti
************************************
volatile int sda_frame_count = 0;
__attribute__ ((noinline)) void increment_sda_frame_count (void)
{
sda_frame_count++;
}
__attribute__ ((interrupt_handler)) void my_irq2 (void)
{
for (int i = 0; i < 100; i++)
increment_sda_frame_count();
}
_increment_sda_frame_count:
ld.w sdaoff(_sda_frame_count)[gp],r10
add 1,r10
st.w r10,sdaoff(_sda_frame_count)[gp]
jmp [r31]
_my_irq2: add -4,sp
st.w r1,0[sp]
mov sp,r1
addi -72,sp,sp
st.w r29,-12[r1]
st.w fp,-4[r1]
movea 100,r0,r29
mov r1,fp
st.w r6,-72[r1]
st.w r7,-68[r1]
st.w r8,-64[r1]
st.w r9,-60[r1]
st.w r10,-56[r1]
st.w r11,-52[r1]
st.w r12,-48[r1]
st.w r13,-44[r1]
st.w r14,-40[r1]
st.w r15,-36[r1]
st.w r16,-32[r1]
st.w r17,-28[r1]
st.w r18,-24[r1]
st.w r19,-20[r1]
st.w r30,-16[r1]
st.w lp,-8[r1]
.L3: add -1,r29
jal _increment_sda_frame_count
cmp 0,r29
bne .L3
ld.w -4[fp],r1
ld.w -72[fp],r6
ld.w -68[fp],r7
ld.w -64[fp],r8
ld.w -60[fp],r9
ld.w -56[fp],r10
ld.w -52[fp],r11
ld.w -48[fp],r12
ld.w -44[fp],r13
ld.w -40[fp],r14
ld.w -36[fp],r15
ld.w -32[fp],r16
ld.w -28[fp],r17
ld.w -24[fp],r18
ld.w -20[fp],r19
ld.w -16[fp],r30
ld.w -12[fp],r29
ld.w -8[fp],lp
mov fp,sp
mov r1,fp
ld.w 0[sp],r1
add 4,sp
reti
************************************
-
To continue on the ADPCM kick, I figure I should add in some more details.
...
So... getting the ADPCM data into your source code... well, this is where having some coding knowledge worked out well for me. I coded a simple utility called any2arr which takes any file you give it and creates a header with the data of that file as a u16 array.
http://www.frozenutopia.com/pcfx/any2arr.7z
Making ADPCM files is also easy... just snag a copy of sox. To make the samples for Asteroid Challenge FX, I used sox like so:
sox -r 16000 boom.wav boom.vox
The -r 16000 tells it to use 16kHz, the .wav is obviously my source audio, and the .vox is the output file. sox knows to make an ADPCM file based on the .vox extension. So, just convert your file to a .vox with sox, run the .vox file through any2arr, and you've got your ADPCM data, ready to include into your program.
EDIT: Forgot to mention... since we're using words here, take the filesize of your .vox file and divide it in half to get the length. Take that divided value and add it to your starting address to get the ending address that you need. I think I did mention this briefly in the first post about this but it bears mentioning again, because reasons.
I gained some experience when I switched to SOX (http://sox.sourceforge.net/) for the Ys IV dub work, so wanted to contribute some more to your tangent should it be useful.
We found that extracting ADPCM and converting to wave sometimes introduces a crazy DC offset to the wave which looks like this when you open it with Audacity:
(http://www.ysutopia.net/special/YS4_099_2728000_Waveform.jpg)
It *should* instead look like this, properly centered:
(http://www.ysutopia.net/special/YS4_099_2728000_DCNormalWave.png)
To fix it, you could 1) open a wave every time in Audacity, select it all (CTRL+A) and use the Normalize effect's "Remove DC offset" without the Amplitude gain option, or 2) add a switch with SOX to handle it/prevent its introduction right on the spot.
The Ys IV Dub kit which I made available way back demos SOX usage in the universal batch files.
http://www.ysutopia.net/downloads/ys4/YS4_DUB_KITv2.zip
Of all the batch files, the YS4_CONVERT_VOX_TO_WAVE.bat has the proper command line to eliminate the DC offset should you notice its appearance in the tracks of whatever game you're extracting.
@ECHO This Ys IV batch file needs 2000/XP/Vista/7++ to work.
@ECHO Won't work on old non-NT platforms: Win98/ME, etc.
FOR %%I IN (*.vox) DO sox.exe -r 16000 -e oki-adpcm "%%I" "%%~nI.wav"
REM Append below to the above commandline to eliminate dcshift
REM highpass 10
REM E.g. : sox.exe -r 16000 -e oki-adpcm "%%I" "%%~nI.wav" highpass 10
It's not used by default, and I recommend only use that highpass switch when you check the waves in Audacity and witness a crazy DC shift as shown. So, the trick is you'd simply append "highpass 10" to the command:
FOR %%I IN (*.vox) DO sox.exe -r 16000 -e oki-adpcm "%%I" "%%~nI.wav" highpass 10
That above assumes you neatly extracted all the Japanese APDCM clips to .VOX files.
For completion, a universal command to convert new English wave files to VOX would look like this (the counterpart batch command):
@ECHO This Ys IV batch file needs 2000/XP/Vista/7++ to work.
@ECHO Won't work on old non-NT platforms: Win98/ME, etc.
FOR %%I IN (*.wav) DO sox.exe -G "%%I" -r 16000 -e oki-adpcm "%%~nI.vox"
Well, that's what I wanted to share.
I also wanted to look into your problem with SCSI issues, but that might get me more involved than I want. I could help given my experience building up TurboRip, but the lack of experience in low level assembly for consoles is the issue.
I'll try though. You were asking about a struct member where status info from the CD drive is returned to determine success/failure. That's the SENSE_DATA structure you want to look at.
struct SRB_ExecSCSICmd // Offset
{ // HX/DEC
BYTE SRB_Cmd; // 00/000 ASPI command code = SC_EXEC_SCSI_CMD
BYTE SRB_Status; // 01/001 ASPI command status byte
BYTE SRB_HaId; // 02/002 ASPI host adapter number
BYTE SRB_Flags; // 03/003 ASPI request flags
DWORD SRB_Hdr_Rsvd; // 04/004 Reserved
BYTE SRB_Target; // 08/008 Target's SCSI ID
BYTE SRB_Lun; // 09/009 Target's LUN number
WORD SRB_Rsvd1; // 0A/010 Reserved for Alignment
DWORD SRB_BufLen; // 0C/012 Data Allocation Length
LPBYTE SRB_BufPointer; // 10/016 Data Buffer Pointer
BYTE SRB_SenseLen; // 14/020 Sense Allocation Length
BYTE SRB_CDBLen; // 15/021 CDB Length
BYTE SRB_HaStat; // 16/022 Host Adapter Status
BYTE SRB_TargStat; // 17/023 Target Status
VOID FAR *SRB_PostProc; // 18/024 Post routine
BYTE SRB_Rsvd2[20]; // 1C/028 Reserved, MUST = 0
BYTE CDBByte[16]; // 30/048 SCSI CDB
SENSE_DATA_FMT SenseArea; // 50/064 Request Sense buffer
};
I don't know how it's defined in your PCFX situation, can't help you there, but it's normally defined as "SenseArea" after the CDB and here are its members:
typedef struct _SENSE_DATA_FMT {
BYTE ErrorCode; // Error Code (70H or 71H)
BYTE SegmentNum; // Number of current segment descriptor
BYTE SenseKey; // Sense Key(See bit definitions too)
BYTE InfoByte0; // Information MSB
BYTE InfoByte1; // Information MID
BYTE InfoByte2; // Information MID
BYTE InfoByte3; // Information LSB
BYTE AddSenLen; // Additional Sense Length
BYTE ComSpecInf0; // Command Specific Information MSB
BYTE ComSpecInf1; // Command Specific Information MID
BYTE ComSpecInf2; // Command Specific Information MID
BYTE ComSpecInf3; // Command Specific Information LSB
BYTE AddSenseCode; // Additional Sense Code
BYTE AddSenQual; // Additional Sense Code Qualifier
BYTE FieldRepUCode; // Field Replaceable Unit Code
BYTE SenKeySpec15; // Sense Key Specific 15th byte
BYTE SenKeySpec16; // Sense Key Specific 16th byte
BYTE SenKeySpec17; // Sense Key Specific 17th byte
BYTE AddSenseBytes; // Additional Sense Bytes
BYTE PaddByte; // Make it an even DWORD-padded 20-byte structure
} SENSE_DATA_FMT;
For getting errors out of this thing, well, my post would get much longer... I'll wait for more input if you really need help and haven't made further progress on this since your last post. I built a function to convert all SCSI error/status codes to readable strings from the MMC/SCSI-3 docs, and I don't want to paste that in here, but perhaps that's something you'd want/could be used.
-
I gained some experience when I switched to SOX (http://sox.sourceforge.net/) for the Ys IV dub work, so wanted to contribute some more to your tangent should it be useful.
We found that extracting ADPCM and converting to wave sometimes introduces a crazy DC offset to the wave which looks like this when you open it with Audacity:
(http://www.ysutopia.net/special/YS4_099_2728000_Waveform.jpg)
Thanks! :D
As pointed-out in the other thread, this is exactly the problem that I'm having with the Xanadu tracks.
My creaky old brain has finally figured out what's going on, and I don't believe that we should have the same problem on the PC-FX.
That's because the PC-FX is using a later generation of ADPCM chip that supports sample clipping/saturation.
The very-old OKI MSM5205 that the PCE uses didn't support that, and its math ends up wrapping around and causing nasty audio glitches ... there are warnings about it in the OKI manual where they recommend that you only use 80% of the dynamic range in order to avoid problems (i.e. +/-29191 instead of +/-32767).
AFAIK, that's almost-certainly the problem that you're hearing when you're using Dave's tools to convert your stuff to the PCE.
I expect that his stuff is working 100% correctly.
But SOX is written for newer OKI ADPCM chips which do support sample clipping/saturation (like the PC-FX), and so it gets the decoding/encoding math wrong when you're trying to convert sounds for the OKI MSM5205 in the PCE ... and those errors would look exactly like what we're seeing.
I've just checked the SOX source code ... it definitely shouldn't be used to encode/decode a .VOX file for the PCE.
I also wanted to look into your problem with SCSI issues, but that might get me more involved than I want. I could help given my experience building up TurboRip, but the lack of experience in low level assembly for consoles is the issue.
You're absolutely right about the SCSI SENSE command ... the problem that we're having on the PC-FX is that the SCSI interface is extremely low-level ... it actually looks a lot like Hudson's "fast" CD routines that I've been disassembling and trying to understand.
We're not getting any data back from the SENSE command at all ... which I believe is a liberis problem that's just because Alex never handled anything other than DATA read commands.
It's just another thing to add to the huge list of things to fix.
-
PC-FX uses a slight modification of the OKI ADPCM algorithm, so if you were to encode audio as OKI ADPCM, it'll sound noisy and have weird clipping when played back on the PC-FX. And IIRC, the ADPCM encoder in MPCONV2 is buggy and uses a slightly different encoding algorithm(including a typo'd LUT value) than the PC-FX, so even it will tend to produce noisy ADPCM, particularly on source audio that uses full dynamic range.
-
Quick and dirty code that proooobably(:p) works right(just pack nybbles low to high, little-endian):
static const int step_sizes[49] =
{
16, 17, 19, 21, 23, 25, 28, 31, 34, 37, 41, 45, 50,
55, 60, 66, 73, 80, 88, 97, 107, 118, 130, 143, 157,
173, 190, 209, 230, 253, 279, 307, 337, 371, 408, 449,
494, 544, 598, 658, 724, 796, 876, 963, 1060, 1166, 1282, 1411, 1552
};
static const int step_index_deltas[16] =
{
-1, -1, -1, -1, 2, 4, 6, 8,
-1, -1, -1, -1, 2, 4, 6, 8
};
typedef struct
{
int predictor;
int step_size_index;
int delta_mask;
long long error_sum;
} encoder_ctx_t;
void encoder_reset(encoder_ctx_t* ctx)
{
ctx->predictor = 0;
ctx->step_size_index = 0;
}
void encoder_init(encoder_ctx_t* ctx, int linear_ip, unsigned char raw_rate)
{
if(linear_ip)
ctx->delta_mask = ~((1 << raw_rate) - 1);
else
ctx->delta_mask = ~0;
ctx->error_sum = 0;
encoder_reset(ctx);
}
unsigned char encoder_encode(encoder_ctx_t* ctx, int16_t samp)
{
const int32_t delta = (samp >> 1) - ctx->predictor;
const int32_t abs_delta = abs(delta);
const int32_t cur_ss = step_sizes[ctx->step_size_index];
int32_t m;
uint8_t nyb;
m = (abs_delta / cur_ss) - 1;
if(m < 0)
m = 0;
if(m > 7)
m = 7;
nyb = m | ((delta < 0) ? 8 : 0);
//
//
//
ctx->predictor += ((step_sizes[ctx->step_size_index] * ((nyb & 7) + 1)) & ctx->delta_mask) * ((nyb & 8) ? -1 : 1);
if(ctx->predictor < -16384)
ctx->predictor = -16384;
if(ctx->predictor > 16383)
ctx->predictor = 16383;
ctx->step_size_index += step_index_deltas[nyb];
if(ctx->step_size_index < 0)
ctx->step_size_index = 0;
if(ctx->step_size_index > 48)
ctx->step_size_index = 48;
ctx->error_sum += abs(samp - (int32_t)((uint32_t)ctx->predictor << 1));
#if 0
{
int16_t tmp = ctx->predictor << 1;
fwrite(&tmp, 2, 1, stderr);
}
#endif
return nyb;
}
-
Quick and dirty code that proooobably(:p) works right(just pack nybbles low to high, little-endian):
Thanks! :D
That's going to need a bit of studying ... but I was already taking a look at your code in Mednafen's soundbox.cpp.
Errrmmm ... that's definitely a bit different the standard OKI 12-bit codec implementation.
I'm going to need a little bit of time to delve into the details to understand the implications of the differences.
I guess that the 1st thing that I'm noticing is that it's dealing in 14-bit samples, and that the multiplier for the code bits is definitely different ... (n&7) + 1 instead of the (2*(n&7) + 1) / 2 that I'd expect.
But it is saturating, so I guess that I wasn't wrong on that aspect.
Well ... it's something to look at more-deeply once I've dealt with the PCE codec.
-
Should probably mention these libraries in case anyone wants to make an all-in-one encoder and isn't already familiar with them:
https://uazu.net/fidlib/
http://www.mega-nerd.com/libsndfile/
http://www.mega-nerd.com/SRC/
-
That's going to need a bit of studying ... but I was already taking a look at your code in Mednafen's soundbox.cpp.
Errrmmm ... that's definitely a bit different the standard OKI 12-bit codec implementation.
I'm going to need a little bit of time to delve into the details to understand the implications of the differences.
OK, I finally understand what's going on. :)
I checked the PC-FX manual for the HuC6230 sound chip and here's what I found ...
ADPCM Sample Rates:
31.47KHz / 15.73KHz / 7.87KHz / 3.93KHz
The 15.73KHz / 7.87KHz / 3.93KHz rates support optional LERP.
ADPCM Sample Range:
0..4095.875 (12-bit output, 15-bit internal)
ADPCM Initialization:
Sample(N) = 2048.000
Step(N) = 16
Sample clamps to 0 min or 4095.875 max.
On Decompression:
SampleDelta(N) = ((Code(N) + 1) * Step(N-1)) / 8
(Is this integer rounded, or stored as 15-bit???)
On Compression:
Code(N) = ((8 * SampleDelta(N)) / Step(N-1)) - 1
(Code(N) = Min 0, Max 7)
Now Mednafen's code makes sense ... thanks!
Yes, that's an interesting twist on the standard OKI algorithm. :-k
I'm a bit disappointed that the PC-FX is only outputing 12-bit samples ... but at-least it's raised the sample rate to nearly 32KHz.
It looks like an easy algorithm to add into my converter ... I think that the code that Rypheca posted should work nicely!
Should probably mention these libraries in case anyone wants to make an all-in-one encoder and isn't already familiar with them:
https://uazu.net/fidlib/
http://www.mega-nerd.com/libsndfile/
http://www.mega-nerd.com/SRC/
Thanks, those are definitely some interesting libraries. 8)
But personally, I'm really, really, really, trying to avoid doing anything too comprehensive, because I don't see the point in attempting to compete with SOX or Audacity for the majority of the audio processing.
I just want to make sure that the final 16KHz 16-bit .wav -> 16KHz ADPCM .voc stage is actually correct for the chips that we're using.
-
2, I have no idea how to receive the results from an SCSI command.
Err, that's what I was trying to address, using the ModeSense10 SCSI command is something trickier (and I wouldn't wanna go into that myself here).
But my best guess for status results of a SCSI command would be to look at the 17th byte passed the CDBByte[16] array (the SCSI command packet array). In both ASPI and SPTI programming styles, to communicate with SCSI devices, the SENSE_DATA structure has always been placed right after CDBByte[16]. So the 17th byte would be the ErrorCode, the 19th byte would be the SenseKey, etc.
If ErrorCode is 0x00, the command is pending, the drive still working. If it's 0x01, you got success, and if it's 0x04, you got an error which is when you then need to check 3 variables, SenseKey, AddSenQual, and AddSenseCode to convert the error to a human readable string.
Here's a short sample on that:
switch (bySenseKey) {
// MEDIUM ERROR: Indicates that the command terminated with a non-recovered error condition
// that may have been caused by a flaw in the medium or an error in the recorded data.
// This sense key may also be returned if the device server is unable to distinguish
// between a flaw in the medium and a specific hardware failure (i.e., sense key 4h).
case KEY_MEDIUMERR:
switch (gAddSenseCode) {
case 0x02:
switch (gAddSenQual) {
case 0x00:
return "No seek complete (Unreadable sector: unburned/gap/bad disc or lens)";
}
break;
case 0x06:
switch (gAddSenQual) {
case 0x00:
return "No reference position found";
}
break;
case 0x11:
switch (gAddSenQual) {
case 0x00:
return "Unrecovered read error";
case 0x01:
return "Read retries exhausted";
case 0x05:
return "Layered-Error Correction uncorrectable error";
case 0x06:
return "CIRC unrecovered error";
case 0x0F:
return "Error reading UPC/EAN number";
case 0x10:
return "Error reading ISRC number";
}
break;
}
I should think at least for PC-FX, a 1994 console, that the CD component is a fully compliant SCSI device, so it should behave similarly and that info should be available right after CDBByte[16]. Dunno about the PCE though, David Shadoff described it as a "hacked audio CD player" so it'd be a bit more primitive I gather.
-
2, I have no idea how to receive the results from an SCSI command.
Err, that's what I was trying to address, using the ModeSense10 SCSI command is something trickier (and I wouldn't wanna go into that myself).
Ahhh ... what you're missing is that we're not getting anything sensible back from the SCSI device. :wink:
The PC-FX SCSI interface is done at a very, very low level ... and the library routines that Alex wrote for reading data from the CD just don't actually handle reading back the results of the "SENSE" command, or any results, really (unless I'm missing something).
The routines are very, very "fragile", they're not like Microsoft's SCSI commands, and they "break" and crash the PC-FX when they're not used 100% as-expected.
That's not surprising (to me), it just means that we need to wrap some error-handling code around them to make them "friendly".
The point (to me) is that Alex created a wonderful set of "groundwork" that can be expanded to build a robust and full-featured library for PC-FX development.
But it's not "friendly" yet ... and The Old Rover is doing a great job in pointing out areas that need to be improved.
-
The routines are very, very "fragile", they're not like Microsoft's SCSI commands, and they "break" and crash the PC-FX when they're not used 100% as-expected.
Right, but I think it's a SCSI thing/standard, not a Microsoft or Adaptec thing in what I was pointing out. Somewhere, you have the CDBByte[16] array in the PC-FX code which is the SCSI command packet array, and if you have that, the 17th byte would be the SCSI return ErrorCode, and the 19th byte would be SenseKey, etc. It's a hunch. So, that's where I would look.
He also wanted to know how to use the ModeSense10 command, which is how you detect the drive's speed setting, return the information on its abilities, stuff like that, but I don't wanna get into that one, it's tricky and it along with ModeSelect10 lock up the drive easy when used improperly. ;)
I locked up my drives plenty of times when developing TurboRip. It's sending a bad SCSI command to the drive that did the trick. One of the safeguards though that I learned from looking at Adaptec's code was to loop through all detected CD drives, and set their timeouts to 15 seconds. By default, some manufacturers in the past set insane timeouts to like 15 minutes or so which is why you'd get stuck seemingly for good with a bad command or issue, etc...
-
Here's a bit of good news ... a developer on one of the VirtualBoy forums is giving my V810 GCC compiler a test drive.
Here's the better news ... his C code showed-up a huge mistake/bug that I'd made in the compiler!
Hopefully I've fixed that particular bug now, but this all goes to show how important it is to test the compiler with lots of different code so that these sort of problems show up.
It'll be interesting to see if he unearths any more problems. 8-[
-
Nice. Tis good to see that there's still progress on this. :D
-
Nice. Tis good to see that there's still progress on this. :D
Yep ... slowly, it's mainly a question of priorities, and that the toolchain needs more testing.
I've fixed an 2nd bug, this time in the GNU assembler that was causing it to assert() and crash when it automatically replaced out-of-range short branches with long jumps (nice feature).
I don't know if you found that one in testing, but it does explain some weird stuff that I was seeing while doing the Zeroigar translation. Turned out to be a stupid 1-character cut-n-paste typo! :oops:
-
Yep ... slowly, it's mainly a question of priorities, and that the toolchain needs more testing.
Well, the VirtualBoy guy (jorgeche) has got his engine/game-demo running with my patched GCC now, and I guess that means that it's pretty much got as thorough a testing as it's going to for a while.
I'll try and clean up the patches for a "release" sometime in the next few weeks/months (there's no rush, right?).
One thing that was particularly interesting about jorgeche's engine code is that he's basically implemented a lot of C++ object-oriented features in C as macros.
It made me curious enough that I tried building the GCC C++ compiler for the V810/PC-FX, and it actually compiled!
Anyone interested in C++, or rather "Embedded C++" (the saner subset for small machines) programming for the PC-FX?
FYI ... most of my game development work over the years on lots of platforms was done in C++, but basically following the same restrictions as Embedded C++.
Console manufacturers don't allow you to use exceptions, and C++'s horrible and slow RTTI is trivially-replacable with much faster type-safe dynamic casting using functions/macros if you don't use multiple-inheritance. OTOH any kind of dynamic casting would be slow on the PC-FX.
-
Not a fan of C++ myself but there are plenty of others who are so it'd be wise to keep support for it, imo.
-
Serious respect Elmer, enjoyed reading this thread , you too the old rover!
Just a question where do i start if i want to contribute,
My coding abilities are limited but i am willing to learn . Anywhere i should start?
I have two working PC FX's
Also i have read that code can be executed from the memory card slot is this true?
If so can a hacked memory card with an sd slot be used similar to what the gamecube can do?
Looking forward to hearing from you.
-
jorgeche managed to trigger another "hidden" bug in the compiler. #-o
This time it was only with large C functions and when the frame-pointer was enabled in the compiler.
Turns out that GCC was "helpfully" rearranging the order of CPU instructions so that things were put on the stack before the stack was actually adjusted ... causing havoc if an interrupt happened.
That may be a bit too technical for most folks ... but any programmer here that's had to track down a bug like that knows what an absolute swine it is to track down the cause when the CPU just starts randomly jumping into strange locations because the stack has been corrupted! Without Mednafen, it would have been almost impossible to find.
Anyway ... I finally figured out how to convince GCC not to be so stupid, and everything seems good now.
Simple C++ test code seems to work fine with "new" and "delete" using the regular C malloc() and free() from newlib.
Those probably shouldn't be used in practice in a game-engine on the PC-FX, but replacing them with something more sophisticated can wait until work on liberis resumes.
The VirtualBoy guys are wanting to release a new version of their IDE/engine/game with the latest compiler, so I'm cleaning it all up for the first official release of the new compiler patches.
*****************************
Also i have read that code can be executed from the memory card slot is this true?
If so can a hacked memory card with an sd slot be used similar to what the gamecube can do?
I've heard that the PC-FX will load/run code off of the BMP memory card, but I've not tried it, and I have little idea of how you'd sensibly get any code on there in the first place.
I suppose that you'd have to burn a program on a PC-FX CD that would then write the 2nd program onto the BMP itself.
Sounds like a PITA, and I'm not sure what the gain would be ... unless someone either hacked a BMP to add circuitry to communicate to a PC, or someone designed a PC-to-PCFX joypad communication cable.
At the moment, it's just easier to develop in Mednafen and then burn a CD to test stuff on a real console.
It's even easier if you have a PC-FXGA card that already has all the PC communications side built into it.
Unless you're an electronics engineer and want to design a BMP-to-sdcard modification, then it's never going to work that simply.
Just a question where do i start if i want to contribute,
My coding abilities are limited but i am willing to learn . Anywhere i should start?
I'm not sure that we're at the point where there's much that anyone can contribute unless they have skills/experience in specific areas.
If someone is an electronics engineer, then it would be nice to have that PC-to-PCFX cable or BMP hack designed.
If someone is an expert in Japanese, then it would be nice to have more of the PC-FX hardware documentation translated.
If someone has a lot of experience at designing/creating assembly libraries for low-level hardware access, then liberis still needs a lot of work.
If someone has a lot of experience at designing/creating graphics tools or modern IDEs, then the new compiler and Mednafen could be wrapped-up in an easy-to-use package for newcomers to start with (like the VirtualBoy guys have done with VBDE).
If someone is a graphic artist, then there will eventually need to be some artwork done for a demos to show off the machine, but it's still too early for that.
If you don't have any of those skills, then I'm not sure what help you can provide at this time that's going to help out.
Helping others get interested in the platform is one way ... for instance, letting people know about the Zeroigar translation so that they can see one of the more-interesting games on the machine, that was pretty impressive in its story-telling.
Learning to program is always good, and you may want to get started with HuC on the PC Engine since the PC-FX uses 2 of the same VDC chips inside it, so anything that you learn should transfer over fairly easily later on.
-
If you don't have any of those skills, then I'm not sure what help you can provide at this time that's going to help out.
I will cheer from the sidelines and offer free corn if you ever find yourself in Nebraska.
-
Knowledge of HuC might be useful for the functionality of liberis that trap15 and I wrote that mimics HuC's standard library, but HuC itself is painfully limited compared to your gcc build. A great deal of pure HuC code (no inline assembly) will port over with minimal changes (which I demonstrated with Asteroid Challenge FX), but it seems a better idea to just write from the ground up if you've written HuC code that has to specifically work around HuC's limitations (which Asteroid Challenge did, and with a vengeance).
-
Thanks Elmer,
I'm afraid I don't meet the selection criteria for what needs doing at the moment but i will continue to follow this thread for any advancements and have a go at HuC,
As for translating Japanese have you tried contacting Nana from
https://www.patreon.com/nana_vs_nana
He is currently in the process of translating many PC98 games to english , he may be of help to you.
Thanks
-
Well, the VirtualBoy guy (jorgeche) has got his engine/game-demo running with my patched GCC now, and I guess that means that it's pretty much got as thorough a testing as it's going to for a while.
I'll try and clean up the patches for a "release" sometime in the next few weeks/months (there's no rush, right?).
Wow ... has that much time passed??? :shock:
The VirtualBoy developers finally released the new version of their engine/toolchain/ide last week, including my V810-patched GCC compiler and tools ...
http://www.planetvb.com/modules/news/article.php?storyid=426
I haven't received any bug reports from them in the last 9 months, so I'm going to assume that I can say that the compiler is pretty solid and has passed all of their testing. 8)
-
I haven't received any bug reports from them in the last 9 months, so I'm going to assume that I can say that the compiler is pretty solid and has passed all of their testing. 8)
This is not a bad thing. :D Does that mean that your toolchain is end-user-ready? Or at least close to it? :D
-
Thanks Elmer,
I'm afraid I don't meet the selection criteria for what needs doing at the moment but i will continue to follow this thread for any advancements and have a go at HuC,
As for translating Japanese have you tried contacting Nana from
https://www.patreon.com/nana_vs_nana
He is currently in the process of translating many PC98 games to english , he may be of help to you.
Thanks
Woah that's pretty cool, and I bet that the Screamer PC98 translation came out from there (can't find a list of games). Finally someone is tackling that problem consistently and I'll probablydo my first patreon donation soon :)
I'm also glad he (she?) is also translating adult games without any kind of prejudice whatsoever. I'm not interested in them (and some are frankly repulsive lol) but they are also cultural tokens of 80/90's Japan so they have their importance too. I'd trade those for early PC88 adventure games anyday but beggars can't be choosers and anything translated at all is already excellent.
Yet another Off-Topic post by Punch! :lol:
-
Does that mean that your toolchain is end-user-ready? Or at least close to it? :D
I guess that it means that I should finally release the patches, and stop worrying about how ugly the build process is for the toolchain. :roll:
I checked-in the changes to Alex's liberis and pcfxtools into github a few months ago.
But as far as the end-user goes, liberis is still fundamentally broken in a number of places, and we still don't have access to the CD.
So, I'd say that it's ready for folks to start working on fixing liberis ... but I'm going to be busy for a while yet, so I won't have time to help until later on this year.
Does anyone actually want to start working on fixing liberis? :-k
-
What needs to be fixed on the CD part?
-
What needs to be fixed on the CD part?
I don't know, I haven't looked at it. The bug-report was from you ...
Using eris_low_scsi_status() freezes the system. Every. Single. Time. No matter what's going on... even if nothing's going on.
Sending another SCSI command freezes the system... even if I've also used eris_low_scsi_abort(). eris_low_scsi_abort() itself does not lock up the system, but using eris_low_scsi_command() a second time does.
-
Hi everyone,
sorry for replying to this old thread but it had _exactly_ the topic I am looking for.
I am curious about the best/current status in terms of homebrew.
A few words on me:
I always code in Assembler for anything older than the GBA. This makes things super-exciting for me - albeit possibly slower in development ;-)
I feel home with the 65(C)02 CPU (lots of C64 stuff, Atari 2600, Lynx).
More recently I coded for Virtual Boy (same CPU as PC-FX) and since I like the RISC approach (I also learned RiscV assembly at the time), I
purchased a PC-FX (yes, the more niche the better).
I realise that I totally skipped the PC-Engine (though I have it, and adore it) as dev-machine. It felt 'too big' at the time for my simple-team approach.
But it seems like the PC-FX would really be fun to code some more v810.
I develop games as a hobby for some years now.
Now about this new world to me ;-)
I found these:
https://github.com/jbrandwood/pcfxtools
and of course the v810 GCC patch/port that I never used for VirtualBoy though.
THERE I use the official ISAS assembler, for example here:
https://github.com/enthusi/VBeat
I am all for linux, while I don't mind running WINE if that does the job.
So I guess to code in assembly for the PC-FX I would have to go for the GCC-suite AS?
I did reverse engineer some of the PC-ENG routines in Beyond Shadowgate to extract all bitmaps and learn some things about the system, but in the end, I never actively used its GPU/AUDIO before.
My guess from reading so far is that I should take a close look at the liberis sources.
But is there anything for the PC-FX like the TechScrolls?
Like this?
http://perfectkiosk.net/stsvb.html
Is this the latest, most complete?
http://daifukkat.su/pcfx/
And if not here, any forums/threads or people to suggest to contact? ;-)
For example at first glance there doesn't seem to be a linear bitmap mode, right?
But what mode are those few 3d example modes using? Real-time algo to place pixels into time maps?
Sorry for all these questions and I am sure quite some of them are based on my total lack of knowledge and may not even make sense to more HUC-experienced folks.
Would be ace to get SOMEthing (nice) running on the PC-FX.
All the best and thank you
Martin aka enthusi / PriorArt
-
I don't know if there's any pc-fx dev smart peeps here any more, sadly. I believe Elmer (perhaps others too) is on Paul's forum, so maybe try there if you don't have any replies here.
Myself, I know nothing about pc-fx dev (or for anything else) but I'd love to see some cool homebrew for the lil box. :pcgs:
-
Thanks!
I did indeed got some hint and reply on the 'proboards'.
Enough to get me started hopefully :)