12/23/2024: Localization News - Team Innocent

PC-FX Localization for Team Innocent is released, a pre-Christmas gift!! In a twist, it feels like the NEC PC-FX got more attention in 2024 than any other time I can remember! Caveat: The localizers consider the "v0.9" patch a BETA as it still faces technical hurdles to eventually subtitle the FMV scenes, but they consider it very much playable.
github.com/TeamInnocent-EnglishPatchPCFX
x.com/DerekPascarella/PCFXNews
Main Menu
Menu

Show posts

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

Show posts Menu

Messages - OldMan

#201
QuoteNo idea if this helps.
Some. At least we know the cart is getting power (pin 38 == 5V), and that /CART is right (0V).
The fluctuations on the address lines probably mean they are changing (if you used a meter, those are average voltages)

It's the block of 5V in the middle that bothers me; Pins 15-23 (excluding pin 18, which is GND == 0V)
should be changing as well. Yet it appears they are stuck at 5V, which is a 1.

Looks like a dead card to me. Or possibly the data lines are shorted together somewhere...
#202
QuoteAnyone got an idea in regards to "set pin 1 to high"?
What would be the point of this? Pin 1 is Cart detect...and I don't -think- the pce actually uses that. In any case, setting it to 1 (ie, putting + voltage on it) would indicate no card connected, I think.

If you think its a problem with the cart slot, check for +5V on pin 38. That will tell you if the card is getting power.

...and you are not doing something silly, like using a US card in a JP machine and/or have a region mod set to the wrong region, are you?
#203
Thank you for the chuckles.

I'll have to go play 'stider' now :)
#204
QuoteAre there any know problems with using SOX to convert audio data to/from the PCE's ADPCM format for CD games?
Not problems, but....

Quotehey're sounding a bit more "noisy" than I'd expect
Yes. CD audio is 44KHz, adpcm is 8Khz (ok, 16Khz if you push it). So you lose a lot of samples to start with.  Then there's the fact that adpcm is a predictive algorithm, so you don't get -exactly- the samples you would expect.

Adpcm was developed for speech, and it doesn't do a good job on high quality audio.
#205
QuoteIn Ohio, Eagle Scouts get MAD pussy.
Absolutely. They draw out all the crazy ladies.... :)
#206
"...and over here we see a typical pcenginefx newbie waiting patiently to snipe the only copy of Magical Chase on E-Bay, hoping he can flip it."
#207
Quote...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.

QuoteI 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.
#208
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.
#209
Quoteconst char drop_pattern_data[] =  {17, 0, 21, 17, 19, 38, 24, 57, 22, 81, 37, 103};
Split that into 2 arrays; one for offset, one for length. Not a big deal, really...

Quoteconst char drop_pattern_x[] =  {20,.....
This one is a 'problem'. One nice thing to know is that HuC create initialized data in order. So, if you
start with d_p_d[], then define d_p_d1[], they should be consecutive in memory. So, if you go past the end of the first array, you should get values from the second....
The catch there is making sure the data doesn't cross a page boundary :(

personally, i'd make a c function that returned the value you need (or sets a global variable) based on an index. Then you can use #asm/#endasm in the function to do it in assembler. A bit slower than direct access via an index register, but able to handle more than 256 bytes via a simple addition

Or you could try something like

char *p;
p=d_p_d+ix;
var = *p;
#210
QuoteHow do you guys feel about it?
Personally....I'll adapt. Either '[' or '(' is fine

Can I macro (something like) MPR6 = $40?
#211
QuoteAnd I guess really, the real dilemma for me is the whole Squirrel thing.
Don't worry about it. From what I've seen, we can put the player in whatever page we want, and fix the startup/irq code to handle it. It shouldn't be any worse than the Huc modifications.

My worry is getting the Huc functions to work. Guess I'll install this, and see what I can do..
#212
QuoteI was going to sell this but my days are numbered.
?? Something wrong sparky?
#213
Off-Topic / Re: Random Pictures Thread
02/10/2016, 01:12 AM
QuoteBest way to watch Jaws
You guys can see better than I can....Are there any ladies there?
#214
Off-Topic / Re: Random Pictures Thread
02/07/2016, 04:55 PM
QuoteNow, I did not expect to find one of our fine members being mentioned in MA3:
It's even funnier if you read that whole story arc and know more about Senna :)
#215
QuoteMakes me appreciate the AbCard release even more, that's a lot of time invested in just a case, let alone the rest of the game.
Yes, a -ton- of time. That's a big part of why orders were so late.
#216
Quote...somebody design a tray that could slide into a standard jewel case that would hold a HU card in place. That way we can put an insert in the back and they should be fairly cheap...
Like atlantean?
Fwiw, it's ~ 5Hrs printing time. And things that big (~6"x6") tend to lift near the end.
Yeah, It's only $1 in plastic....but $35 at minimum wage to have someone monitor the printer.... :(

(And if someone isn't watching the printer, that's when it will curl at the corners, catch the print head, and you end up with a mess....and 4+ hours wasted, usually)
#217
QuoteNo. Maude.  1972. First appearance of Florida and James Evans.
You sure about that? Wasn't their son Lionel a friend of the meathead/Gloria on Archie Bunker?  I could swear Archie went to meet Lionels parents one time, looking for Gloria....
Coulda been post-72 though.

Wow, that makes me old.

(For you Young-uns: IIRC, Maude's hubby Phillip was originally a drinking buddy/ co-worker of Archies. Maude and Edith became friends...Which led to the Maude spin-off. Don't remember how Florida and Maude met (probably at a women's lib meeting), which led to the "good times" spinoff.  Then, iirc, Maude moved into an apartment building, where she met Sherman Hemsley (don't remember the characters name) and the maid (don't remember her name either), who eventually ended up with their own series.... Yeah Normal Lear ruled the 70's sitcoms :)
#218
Congratulations.

Now the boring stuff starts :)
#219
Quotewell yes, but that could be a flash chip in itself
simply having the unlock address programmed into a rom
Didn't think of that. So you could use a chip to detect the $7f (io page) part of the address, and use that output to turn the chip on so the programmed data would appear on the data lines?
Maybe. The BRAM unlock is different register on a read, though, iirc.

I think you could do it, just don't think it would be as simple as it appears.
Just to satisy my curiosity, could you put an 8 bit A-B switch in a small programmable device? If so, it might make things easier...(Switch between BRAM and regular memory based via the switch)
#220
Quotethe data lines can go directly to the RAM as CE can put the RAM into tri-state
Wouldn't you need all the address lines to catch the unlock address?
#221
IF I remember right (and I may not...)

Quoteok i suspect im looking at an address range decoder
You need to watch $1803 in the I/O area (bank $7f?). One of the bits 'unlocks' the BRAM.
I think it then appears at $8000. I don't -think- you need to map it in.

Best bet is to ask bonknuts or elmer. They seem to really know the hardware from a programming pov.

EDIT:
Just checked the bios code. It maps the I/O page to $8000-$9fff,  before unlocking BRAM. Not sure how that works, but it then checks for the format string at $8000...
Unlock bit is 7 ($80).
#222
Quotemy brain is already filled with nonsense and tripe. Not much free space.
Mine too. I'm waiting on a brain defrag routine, to squeeze out those last bits... :)
#223
QuoteThat must be an huc thing
Could be. I didn't hunt it down :)
I suspect part of the HuC startup code does things like disable the user irqs, resets the display size, and turns the display off.
Which is why I wish I could replace the HuC startup sequence.

(Yes, I know it's possible. But I haven't gone through it enough to actually do it :)
#224
QuoteAhh, so this is what you guys were talking about. I've used IPL to load a few graphic (and I think ADPCM) things like a splash screen, but I mostly just use it for the CD version detection routine; basically just a boot loader for the SCD or ACD program. I just jump into system ram and load all SCD/ACD banks and then jump to my exec address.
Yeah, that's pretty much what we are talking about.
And debating (he from an asm, me from a Huc point of view) whether it's "better" to use the ipl empty space or load part of the program into Ram and execute it there.

We agree we disagree, mostly. Though I do have to say I could see loading initialized data and possibly kernel/irq functions into ram as a good thing. Can't do that with Huc (well, I could, but it's a lot of work)

And a note for anyone else playing with this: IIRC, it's not a background kind of operation.  (At least on the HuC side). Your graphics load, and display. Then (I think) the screen blanks while the program is loading. So, alas, no loading progress screen :(
#225
More fun with the IPL...

Set the GRPBLK_  stuff and load your graphics and a palette before anything actually runs...
Set the ADPBLK_ stuff and OpenMode, and play an adpcm tune (or whatever) before loading....

Both of those also require adjusting the IPLBLK_ record number so the program will load (set it to start record of games actual code)

Stash your actual exec address (original IMLJMP,  default = $4070) at the start of the free area and jump to it from the custom code area. Game should run like normal :)

Or for even more fun, use the custom code area to do a cd_read via mpr....and load as much as needed from the cd....(you still have to specify length, etc for cd_read)

The only big problem with this kind of stuff is HuC keeps a list of offsets for overlays. Those have to be patched if you use the graphics/sound stuff, since the game won't start at sector 2 on disc, and HuC assumes that it will. Somewhere I have a tool that patches all that stuff, if I can ever find it again. (And someone wants to host it)

....And the final piece of the puzzle, elmer.  Use the last 3 sectors of the program code (or add 3 sectors to it) and load those in the custom code. (Or,  if you prefer,  set the size in bytes and call cd_read with _dh = 0: that forces a byte->sector conversion) Then you can jump to a small routine that will load those last sectors into $2800.....

I *think* that will let you load 6K into the ram bank, and all of the cd card memory. Well, except for the load routine extension....which is < 64 bytes, iirc.
#226
QuoteI was a GameStop store manager for about 3 yrs.....
When shitty after market controllers are returned they are always field destroy.
My nephew was an assistant manager for about a year. He had to 'field destroy' a nice 17" LCD from one of the promo setups.

Manger insisted he use a hammer.
That really hurt :(
#227
QuoteI see that there's a lot to learn so I might not do a CD version as I was planning for my homebrew in development
You're going to laugh, but here's my suggestion. And I'm serious.

Write a HuCard game (assembler is fine, HuC not required). Get it to work. Try to keep it under 128K.
Then, assemble it with the -cd or -scd option. Check the size, and figure out what is not getting loaded. (If anything) Then it's pretty simple to change the memory map and load more code, up to the card limit.  And you have a cd/scd game iso.
It only gets complicated when you're using overlays and/or trying to load things from cd in the game. And even that isn't too bad; you can duplicate the overlay array approach HuC uses.
#228
QuoteOK, I just looked at the loading process in Mednafen.
So the 2 IPL sectors are loaded into RAM $2800-$37FF.
Right. Keep in mind that there is a split in the ipl though; part of it is data, part of it is boot code....

QuoteThe contents of $2800-$2D1F are verified as a valid IPL (the signature).
Right. That's the first half of the ipl.

QuoteThen the code jumps to $2B26 to actually run some code before loading/running the game program/data that is specified in the IPL.
Not sure about the addresses, but ok. The code that gets run has been verified as the NEC boot code. That part loads the graphics, etc. Can't change it, or the boot fails.

QuoteSo you've actually got 736 bytes of space for your own code in there if you don't overwrite that area with boot code.
Again, not sure about the size, but ok.

Now, in those 736 bytes, you can do what you want, pretty much. Soooo, let's say you load another couple of sectors at $3000, and jump to it. Those sectors could be your menu program.... :) Or other code....
All in all, I think it shows a lot of thought.  And I can see where it could do a lot of the things a HuC program does when it starts up....

QuoteI was thinking for a second that your code inside the IPL would run while loading the main program code .
Unfortunately not; I think the main program gets loaded last (maybe first), iirc. That is, assuming its not running from the ipl area, though maybe the main code gets loaded anyway. Don't quote me on that, though; it's been a long time since I did that stuff....

What I do remember is splitting the ipl into 2 parts; one part contained stuff that got verified - it had to match what was in bios for the cd to work.  The other part contained the data described in the ipl doc. I then disassembled the actual startup code to see how it worked...and that's when I found a check for the execution address being in the RAM page, which allowed me to run the bouncing logo routine. Except for the size constraint, I realized I could probably use any bios calls I wanted - including loading more code into ram.

fwiw, I actually had a test ipl that would check the cd card, and boot different programs for the 2.0 and 3.0 cards. Kind of gave up on that, since I would have to keep 2 different versions of things in sync, but the idea was to run a low-quality version and a higher-quality version of the same program, depending on which card it was running on....
#229
QuoteDo you mean actually putting your code in the IPL sector itself???
Yes. As long as you don't change the signature (which is actually a routine that does the gfx/pallete/sound loading and playing), you can set the execution address to run code in RAM. Unfortunately, there's only about 1K left at the end of the ipl stuff.

Fwiw, that's how the 'aetherbyte' logo bounces in pp. The gfx and sound are loaded in the ipl, and then the logo is bouced by a custom routine. In the ipl.
#230
QuoteI'm not even sure if the IPL loader even allows you to load up more that 64KB in the boot process.
The ipl by itself can load all of vram, and up to 5 pages of code. But if you set the execution address (to the last part of the ipl, iirc) it can call your ipl code. At that point, you can do pretty much what you want, if you can fit it into ~1K. You have to direct execute your main program, though....
#231
QuoteI thought the IPL file that HuC had was just like a static signature thing the CD bios checked for copyright and disc validation
The first part of it is that. But part of it is a small program that gets loaded into RAM (yes, ram) and executed to load various things. Like the actual program itself, from cd.

Quote(which MPR banks can I use? interrupt vectors are ok to be assigned on the last bank? any special function to load before doing regular game stuff?)
MPR 0 is I/O. MPR 1 is RAM. Mpr 7 is (usually) the bios code.  That leaves you MPR 2-6 to map for your program.  You -can- use MPR 7 for your irqs, but it's a pita; better to place them in either MPR 2 or MPR 6,  and leave them alone. IIRC, nothing 'special' is required to run the program, but you may have to do some setup at the start. (ie, set screen size, load palettes, turn display on, etc).

QuoteI could also use HuC to do all that hard work for me...
Its worth learning to write at least a working "Hello World" program in HuC, just so you know what you have to do. Once it works, you can look through the generated asm and see what is going on and then get rid of some of the HuC cruft.

QuoteI still don't get how stuff is supposed to be referenced on disc ("record no."), is it a "CD frame" index or something? Do I have to generate all that stuff by hand?
Rec H/ Rec M/ Rec L  is a 3 byte LBA address. That's generally the best way to handle most cd stuff.
The ctime stuff is a 3-byte timestamp. Its a little trickier to use. IIRC, there's a function to convert between them.
Yes, you have to know where things are ahead of time. It's not as bad as you think, though.  Most things won't move around in the iso.

#232
QuoteJust compiling a hucard project as-is makes no positive effect -- I have bank 0 with startup code plus 4 more banks I pull graphics from and map during startup. I imagine that there's some preparation to be done but I can't find any documentation. What's the minimum setup for an ASM CD project?
I'm not sure I understand what you are saying/what your question is.?.

Are you actually displaying anything yet? That's probably the first thing you need to work out. Without loading anything other than a font, can you print a test message? If not, you need to figure out how to set the display up, and get a test message displaying.

Btw, you don't need to compile the gfx into the program. If you understand the ipl, it can load vram + pallettes for you.

#233
Quotebut what happens when initiating a reset with the SELECT+RUN keys?
During the pad read, there is a check for [SELECT]+{RUN]. If the key combination is pressed, the code jumps to the reset vector.  I don't believe the "soft reset" has anything to do with the hardware signals.
#234
QuoteMine's still in the paper sleeves.
How many cases do you need? We were buying them in 50 packs for around $15.
Or try the grocery store (believe it or not).
#235
Off-Topic / Re: Random Pictures Thread
01/02/2016, 04:23 PM
Quotedouble take at that name wondering if that was really there at the time of print...
Yes it was. It was a not-so-subtle dig at the Ayatolla Khomani (sic).
#236
Off-Topic / Re: Game Sack
01/01/2016, 09:07 PM
QuoteNot even Mickey?

I thought he likes everything.  :lol:
Actually, the quote is "Let's give it to Mikey....He won't like it. He hates everything"

(It's from a Life cereal commercial)
#237
8160 yen???
Wow. just .........wow.
#238
QuoteI've owned a Coleco but I've never even played Intellivision, and I always wanted to... know anything about that one?
Got the intellivison one for my nephew. I never had an intellivision, but his comment was it was "meh". Not as laggy as the coleco one, and actually had a lot of the 'real' intellivision games. Iirc, he was a bit disappointed the talking games he liked weren't on there. Not sure if it was just favorite games missing, or if the speech module didn't work.

Fwiw: I think the intellivision one was $30 after xmas, so wait and look for it then :)
#239
QuoteMakes less sense than the Coleco Flashback they've already released! (Which despite still having my actual Coleco, I considered,
Don't bother with the coleco flashback, unless you get it really cheap (ie, < $20).
It feels like an emulator, the controllers are the wrong size (and you can't use real coleco controllers), and there are only 2-3 decent games on it.

Yeah, I'm a geek. I have the flashbacks sitting by their respective machines. Haven't played any of them in months. (Though comix zone on the sega one was good.)
#240
QuoteCOLECO Chameleon is a versatile new video-game system that serves as a modern day take on the classic game console and will accurately play classic games from the past.
But can I play my old colecovision games?
I don't see any number keys on the controllers, guys.....
#241
QuoteStill good enough to learn on I hope
If you're still learning, stay under $500. You can get a pretty nice machine for that price to learn on and see if it's for you. Believe me, no matter what they say it is -not- "hook it up and print" :)

#242
QuoteGot any tables for NEC uPD7759C ADPCM formats?  :-D  Seems nobody has those.
A quick look says the tables diff table at least is calculated on they fly, apparently.

See if this helps: https://github.com/xobs/chumby-mame/blob/master/src/sndhrdw/upd7759.cpp
#243
QuoteAhh man, now you're just teasing - lol.
Yeah, sort of. If you think about what Aetherbutt is doing, and recent messages from me, you can make a pretty good guess as to what I'm doing. Remember, I'm the tool guy here.

Quote...runs game logic every other frame....
I'm hoping it doesn't come to that.

QuoteIs there some reason that you don't want to just store the pre-converted ADPCM in the data track, load it directly from CD into the ADPCM buffer, and then play it from there?  :-k
It's a matter of quality. I have to be able to say to the boss "This is why we can't do it that way" and then convince him that What I'm doing 1) Will work, and  2) Will work good enough.

There's also some technical stuff that prevents using sox.

QuoteIt's a pretty-simple basic algorithm, isn't it?
Laughably so. When I saw it, it took less than an hour to get it working. Biggest problem was I had the wrong (intel/dvi) table. Once I figured that out....it works.
I just thought it noteable that the only real change to the algorithm (for different formats) was the tables used. Maybe I should compile a set of tables to output different formats... :)
#244
QuoteWhat were you trying to do?
Not at liberty to discuss details.

Suffice it to say, -if- I could read pcm from the cd (which can be done), buffer it, and then play it via the adpcm chip (which we can't :), we would have much higher quality audio in....something.
As it is, I have the conversion routines (No, sox is not an option for....reasons) and am currently testing that part.  I'm just not sure 8/16 K will satisfy Arkhan.....

Fwiw: Did you know that the only -major- differences between ADPCM types is the step tables they use? Google-chasing things from archaic pixels led to the dialogix specs, which had the encoder algorithm and tables.....
Which made for an easy conversion of the generic adpcm routine I was using.
#245
Thx elmer.
So the adpcm is seperate from the cd stuff. I kinda thought so, but it's nice to have confirmation.
Guess I can't just read the incoming cd audio, save it, and pump it back out via adpcm <sigh>
(Oh, all right. I -can- do it, but it would require conversion in the pce. Not worth it)
#246
From the docs I have, F = 32/(16-DH), which would lead one to believe if DH = 15 ($0f), F=32 KHz.
But the docs also say max for dh = $0E (14) which is 16KHz.

Fwiw, I haven't tried DH= 15 to see if it works.
In any case, it's not 44KHz cd quality, and its looking like I'm going to have to re-sample the audio.
#247
Is it possible to play 44KHz audio samples from the adpcm buffer?
I know I can play a cd track directly, and I -believe- the adpcm functions have a max frequency
of 16KHz. Does that mean I *have* to convert a 44KHz sound track to 16KHz/mono/4bit in order to play it????
#248
QuoteI know that "(NULL == pValue)" is supposed to be "good" practice, but I just don't like the look.

I get bitten by the "(pValue = NULL)" bug once or twice a year, but it doesn't take long to find, and is a price that I'm personally willing to pay to not have to mentally deal with reading "reverse-polish" in my C source.
Yeah, I don't like the 'reverse polish' notation either. To my mind, I'm comparing a variable to a value - not the other way around.
And just by habit from long ago, my code is littered with  if( cptr == (char *) NULL)... I know it's not needed (but I have a few funny stories about people who thought that and took it out, only to find out it really was needed sometimes), but it helps get around some type-checking warnings.

QuoteThese days, since you guys at AetherByte now have your own source for both the "compiler" and the "playback" side of things, I hope that you guys would want to push things forwards a bit and make some improvements.
The compiler code, yes.
AFAIK, the player code is still copyright NEC. That's why we aren't changing it, and why we can't license it like people keep asking. As for the licensing terms, that all because Arkhan wants to know who's actually using it - I don't think he's ever told anyone they can't, or had to pay royalties.

QuotePerhaps Bonknuts' core sound driver matched with your higher-level compiled-MML will be a way to do that. 
I would love that. But I'm not sure a compiler-type program would do it. I'd have to see what the driver supports/does. It is a good idea, if it will work...

(I'd like to have a choice of drivers built into a bios image even better. :) )
#249
Quote... to force myself to start writing (NULL == pValue) instead of (pValue == NULL)
Won't they let you do just (pvalue) for checks?????
wow....
#250
Quote
QuoteThat said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.
Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.
Why? I don't understand......?
You can use the 5-bit stuff (re-loading the waveforms) to do some neat things. If you play with it a bit...
I just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible. You can swap your program  to cd, and have it play the same. So you can develop your music (or whatever) on a card image (in an emulator) and drop it into a cd-image.

If I have to use system card memory to hold a player -that's already in the bios-, I'd use a custom engine, too.
So when will it be available for general use, bonknuts? And what kind of resources does it us? (we already know about the cpu time.) How is it on memory? especially the zp space?
[ Don't take that the wrong way. It's -not- a dig; it's a serious question. I'd like to see what it can do, especially the adpcm stuff....]