Messages

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards & Cases Now for Sale!!!!]

Hopefully it will also glow in the dark.

Depends on if we can find a reliable supplier of quality glow-in-the-dark plastic :/

[Off-Topic / Re: What are you currently listening to?]

Songs for long car rides should be longer than average pop song. At least, that's what I say now.

How long should they be?

("This is the song that never ends....")

[PCE/TG-16|CD/SGX Discussion / Re: Mad Stalker - Arcade or Super System game?]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

As opposed to the time to load things from CD?

[Localizations, Games, Apps, Docs / Re: ipl.bin questions]

Aplogies in advance for the wall of text.

I tried to read cdrom.asm for that cd_execoverlay function and I ended up being more confused.

Welcome to my world, 2 years ago. There are still parts of the startup I don't understand...

Why "JMP $C000" after loading an overlay?

See startup.asm around line 263.

Overlays have a different execution address, presumably so they can check for problems.
Fwiw, I -think- that's also why the ipl execute address is $4070  (startup.asm, line 230)

I get that ovlarray is the table, but where is this defined in the dozen inc/asm files
in HuC's include folder?

Again, it's in startup.asm, line 168. First thing in DATA_BANK (which is bank 3 for cds, I think).
It's also not something I want to fill out by hand.

Besides, it feels like a good portion of the code inside the library is just
a thin wrapper into the BIOS routines anyway.

A lot of it is, when building cd's. Many of the bios routines are duplicated
specifically so they can be used for HuCards.
[Though I'd like to shoot whoever thought using ifdefs was a good way to do that...
 I'd prefer startup.asm just have the ifdefs and include cd-specific/HuCard-specific versions.
 But I'm like that.]
 

I'm ditching the default ISOLINK too, while I don't want any table'ing messing
with my code nor default IPL stuff, I do want sector padding for non-overlay files
(like ADPCM samples) and 8-second track compliance. Perhaps I'll mod it or create
a new program for this, but for now I'll just stick with MSDOS "copy /b" to
join overlays and a hex editor to pad .bin files into 2048 byte sectors,
which is working OK in emus for now. What about IPL? Well I clipped off half of
the IPL.bin file and did this:

What I ended up doing was splitting the HuC ipl.bin in two, like you did, and renaming the
credits/boot code to ipl1.bin
Then I created an ipl2.asm which held the ipl table (and some extra code),
assembled it, and copy /b ipl1.bin+ipl2.bin ipl.bin. That put the ipl.bin file back.
(I may have chopped ipl2.bin up to get just the 2K I wanted. Don't remember)

I'd have to check bios for the exact address, but part of the first ipl sector
(which is checked for changes, unfortunately) is the 'real' boot code. It executes from
RAM (which makes more sense to me). It can do some neat things, like auto-loading adpcm
data and/or graphics and/or a splash screen. It's worth looking at a disassembly to see
how it operates.

Ahh much better. Sorry for the huge rant, I hope no one interprets this as a
"I'm too good for what everyone else uses" thing, that wasn't the intention.
I just want to do this in a way that my dumb brain doesn't get too confused.
For now I simply cannot work with the default libraries because it's too much
effort to figure out what goes where

Understood. And seconded. It's a pain, even in HuC, to get things 'just right'.

[Localizations, Games, Apps, Docs / Re: ipl.bin questions]

I can't figure out if overwriting the second byte of my overlay with '1' has any meaning whatsoever ...
It's just a overlay "index", ie if the overlay is the third parameter for ISOLINK it gets a 3 inserted into it ...
I hope that's the only change it does to the compiled overlays,...

Nope. ISOLINK also updates the overlay table with the location/size of the overlay(s).

If you are using ISOLINK, it shouldn't be a problem to run an overlay. Just use cd_exec_overlay with the overlay number.

If you are trying to do it by hand, you will need to fill in the overlay table, as well as setting the overlay number for each overlay. Then you  can call cd_exec_overlay.

(see cdrom.asm for cd_exec_overlay function)

[Localizations, Games, Apps, Docs / Re: Changing music files in a game]

So is there any way of getting around this when it wants the tracks to have a certain length?

There are always ways around those things. The question is, is it worth the time and effort.
No.
...
There are 2 paths someone could take to fix it.
The first would be to change the calls to use track number. Of course, that requires hunting down all the audio triggers, and changing the calls. Then making sure the area for reading the TOC is available. Etc.
The second would be to build an iso image with the audio in place, and using the offsets in the new image for the calls. Of course, you would have to do that every time you changed the track lengths.

Can it be done? Yes. Would it be easy? Not unless you know a -lot- about both the game and the cd layout.

[Localizations, Games, Apps, Docs / Re: How to fix the HuC/PCEAS 384KB ROM size problem?]

But to Mednafen, and presumably a Turbo Everdrive, 384KB ROMs were actually manufactured back-in-the-day using 2 separate ROM chips,

Correct, got that.

1 256KB ROM chip mirrored at banks $00-1F, and then 1 128KB ROM chip at bank $40-$4F.

Okay, so there's a hole in the address space.

So when Mednafen loads a 384KB ROM, it puts things into different banks than HuC/PCEAS expected

And mednafen is mapping the upper ROM chip where? Does it duplicate it (so its mirrored) or what? Any more info?
.........................................................................................

Now, to me, the simplest "fix" for this would be to add an optional flag to PCEAS to make it automatically pad HuCard ROMs to the nearest power-of-2, i.e. 64KB/128KB/256KB/512KB/1024KB.

Lol. <snort>. Changing HuC/PCEAS is probably going to be a pain. There's a better way, actually.

First, is your ROM actually 384K, or is it 384K+header (512 bytes)? That's important; I seem to remember mednafen use the header bytes if they were there.
So, try building your rom without the header if its present. (-h, iirc). If that works, let us know.
If it doesn't, PM Arkhan and get his permission. We have things to fix that

[Localizations, Games, Apps, Docs / Re: Changing music files in a game]

Nice. I don't understand why some games need you to do this and others don't. For example, I took tracks from Lords of Thunder and replaced every song in Sapphire. I also took tracks from Gate of Thunder and replaced every song in Sapphire with those too. Never had to worry about this shit.

The CD_BIOS has a few ways of playing audio tracks.
The first involves playing by a track number (0-99). To do that, the track number has to be converted to an absolute disc adddress.
The second is actually by absolute disc address (since the routine is already available, see above).

Some games use method one; other games use method two. It depends on what the programmers decided when laying out the cd image.

[Localizations, Games, Apps, Docs / Re: (work in progress) Barbarian on PCE]

great news today for the game : the music theme is integrated !

+1 !

[Localizations, Games, Apps, Docs / Re: (work in progress) Barbarian on PCE]

Congrats on the release.
I assume you got the tempo problem fixed? (Yeah, using only vsync can cause things to play slowly, since there's no tempo control there.)

Does this mean we can look forward to a smple/mml player some day?

[PCE/TG-16|CD/SGX Discussion / Re: Burning TG Game CDs]

No need to try and hunt down an old burner that will burn slower.

Agreed. Newer electronics have faster switching speeds. I assume that the laser can switch on/off fast enough that the slower rated speeds have no problem creating short enough transition areas. Its the faster speeds that have problems; even if the drive can do it, the transition area may not be within tolerences. Which may be why slower speeds work.

[PCE/TG-16|CD/SGX Discussion / Re: Burning TG Game CDs]

Sure but why would that have anything to do with how fast the burner does the job?

The faster the drive (read or write), the faster the disc spins.
The faster the disc spins, the more distance that goes by the laser.
CD Burners use the laser to create lands and pits on a CD-R disc. The faster the writing speed,
the faster the laser has to cycle on-off.
Those are all facts.

The theory is:
The faster the burn speed, and hence the laser cycle time, the less defined the change from a land to a pit and vice-versa. (It takes time for the laser to shut off/turn on).
Since a cd-player recognizes only the change from a land-to-pit (and vice versa), slower drives may mistake a transition area for actual data (since it is longer than expected, due to the write speed).
Slower write speeds lead to better defined land and pit areas, and better recognition.
....................................
BTW, this isn't a new problem. BITD, I had one of the first cd (audio) players available. I shortly thereafter purchased a 1x burner setup. Everything worked fine.
Then, due to an unfortunate accident, I had to replace the burner; I purchased a 4x model -
and found out that discs burned at 4x would not play in the cd player. I chalked it up to the player not liking writeable discs.

When a friend suggested lowering the burning speed, I couldn't understand why it would make any difference. But it did. Discs burned at 1x ( and even 2x with quality discs) were fine.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

I sure hope they are printing those singly.

(Bonk 3, line 7, prehistoric her?)

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

emailed it to you.

Got it. Thx.

Well, the last "bank" not "page", but yes, that's what it appears (to me) to be doing, and then it maps it into MPR4 ($8000-$9FFF).

Right, bank. (That's the 24-bit address in the card. I still get them confused.)
I assume its not going to be a problem with the MML being mapped into pages 4 and 5, then.

...if you wish to keep on accessing the internet with an out-of-date version of Firefox on an unsupported version of Windows. 

Hey, if it isn't broke, don't fix it

Thanks for adding that, and for finally making it available to me, yesterday, for testing.

It's been done for a couple of weeks. Was just waiting until I got the rest to be compatible.
I figured you'd get tired of fixing snginit(), though.

Now I see why Catastrophy is sitting there with banks 5,6,7 and 8 completely empty, and with bank 4 just containing a totally-unused 200-byte table for program overlays.

Feel free to move the mml into bank 5. It's simple enough to re-build the snginit() with a different page.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.

Yes, but it was built for an SCD. You need to re-build it for a CD, which involves specifying a cd-useable bank number.

And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.

Already in there, with the -p flag.

So ... with your new version of mml2pce, I've built a working CD of squirrel.c, and I can see that "yes", there's a problem when you try to put the sound data in bank 6 ... but everything is happy if you change it to put the sound data in bank 5.

Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.

So, if I understand this right....
It uses the entire last page for the trampoline code?

The big question is why-on-earth put the sound data into bank 6???

Because it was the highest unused bank. That way, we didn't have to keep going back and moving it
everytime we added something.

You should be putting the sound data into bank 4.

And have it over-written when we added new graphics and stuff?
(which is why we picked bank 6, after about the third time it happened...)

By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.

Understood. But there's no reliable way to know the last-used bank ahead of time, that we have found. Of course, its been a few years since I looked at, and I've learned some things since then, so maybe I'll find a better way.
Keep in mind, this is a test program. Good tests highlight the problem only.

Dropbox doesn't use Java (the programming language), it uses Javascript (aka ECMAscript), which is built into all web browsers. They are totally different technologies.
Now, if you choose to avoid all websites which use Javascript, then good-for-you ... but it would be helpful to know that.

Same basic technology - the website wants to run a program on my computer. Sorry you didn't know.
Yes, I'm paranoid like that.

BTW ... you can just install noscript or something like that to gain control over the execution of Javascript in your web browser.

So i should install and run someone elses (possibly buggy, possibly invasive) program when I can just turn Java and it's variants off? And lose the added bonus of no more forced ads and tons of spam? <sarc>

Also, keep in mind I'm on XP. Does firefox 34 even support plug-ins?

Anyway, I've emailed you the fully-working version of Squirrel (for both the old and new HuC).

I'll pick it up tomorrow. E-mail me the latest compiler, too, when you get a chance, so I can check to see if I've broken anything else.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I *really* need a copy of your test setup in order to replicate whatever you're seeing.

I'll be mailing it in a few minutes. It's a .zip, you have to re-name it. Google won't mail zips.

I can't find "test1.c" in the Aetherbutt_Squirrel3.zip that I just downloaded (again) from Aetherbutt.

My bad. I re-named it in the test directory. It's squirrel.c

And I'm having trouble replicating the problem that you're seeing. 

I didn't see you trying to build a cd version, with the mml in the right place. Bank 9 doesn't exist on a 2.0 card, and you don't appear to be re-building the mml....

Just for reference, I'm using the latest version of HuC, and the same version of Squirrel that I sent you guys back on November 21st (the download link is still the same).

Nobody sent me anything. And I don't run Java unless absolutely required, so sropbox is out.
Luckily I have friends who send me things - that's how I grabbed the compiler. But it took a couple of weeks.

.............................
FYI. This includes the new version of the mml compiler. Not for public consumption, yet.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Okay, I looked over the psg-player code.
There are 2 routines (psg_bios and psg_driver) that *must* be in an always-mapped page.
I -believe- they were originally in START_PAGE.

psg_bios maps in the bios functions, does an indirect call, and then restores the original mapping.
psg_driver maps in the player code and music, steps the player along, and then restores things.

The actual bios functions and the player code can reside in any page that is available. Together,
they do a good job of filling a page, though. It would probably be possible to split them (since they have seperate map-in functions), but I wouldn't recommend it.

Next step is to get psg_bios and psg_driver seperated out into start.asm, and to make sure they load into the correct bank. After that, it should be easy to set the psg_xxx functions and the psg_driver into SOUND_BANK. Then, I have to setup the macros for the interrputs.

That should create a setup that is compatible across the board for the bios MML player. Cards should use the compiled-in code, and cds should use the bios code.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I was trying to engineer a solution where any new sound driver could say that it needed it's own bank, even *if* you were building for CD.

Discovery of the problem was entirely due to regression testing the compiler before I started bringing in Huc. I wanted to know it was going to work for cds before I started on the card stuff.
That's on the agenda for the rest of the week.

...easiest solution (to one of the problems) is to rename that equate to SCP_BANK or SOUND_BANK, and for me to rearrange the new startup.asm to make sure that it is always in bank 2, if it is invoked.

Got it. I can change it to SOUND_BANK here.
I believe the player part is moveable to any bank. It's the psg_bios stuff I have to check on.
Even if it currently has to reside in a specific bank, that can easily be fixed, provided we know where
it is.

I, too would like to have the player/interface moveable to any bank. Not only for cards, but for cds as well; it's the only way we are going to be able to extend the player.

Then I guess that we need some way to decide where the music data actually goes.
...
In Catastrophy, it doesn't *seem* to start putting data in until it reaches bank 8.

We left that open to the user.
The MML compiler defaults to bank 9, I believe. There is a switch to move things to a user-selectable bank(s) however. Assuming Catastrophy is using the generated snginit.c, you can look at the very end of the file to determine where the song data is placed.

Be aware that there are problems with how we do it, however. AFAIK there is no way to preserve the current bank number (in either Huc or pceasm), or even find out what it is. Thus, there is no way to return to the last bank in use. Thats a big problem, since once the song data is processed, anything after it will be in the next bank(s). That's why we say put the snginit() include at the end of the file.
The problem is compounded by the fact that HuC doesn't fill pages; things either fit or they don't, and it moves to a new page. So a small re-arrangement of code (or adding something to the program) can cause things to shrink (leaving a gap) or expand (potentially being overwritten). Bank 9 seemed to be generally available, and we had to pick some default

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

And the PSG_BANK problem?

The original HuC only defined PSG_BANK as START_BANK+2 if you were not compiling for a CD
(startup.asm, line 34.)
It was defined as 3 (in system.inc), which is included only if you are building a CD.
(startup.asm, line 65)

I understand why there was no conflict now.
I do think it's misleading to re-use the name that way, though.

The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined.  If you are not building a cd, (ie, you're building a card), then
there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.

Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.

Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

The bank overflow problem for cds I *think* I got figured out.
..................................................................................................
I've been using bank 6 to hold the MML song codes.
Apparently, that kicks the heap to page 7. That means
there isn't enough space for the interface functions.

So: How do I disable the heap?
And any other code that got added?

I'm putting in my feature request now...Can we get an equ/define for the last page used by the system? So i don't have to go hunt for a place to put music

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

If you look at the original startup.asm for the old huc,
you will find (line 33) that -we- did not define PSG_BANK.
The original HuC had the problem.

We used (and defined) the PSGF_ versions because of it.
I didn't want to break anything else that may have used them
(like the included psg player), so I left them alone. I tried to
isolate the PSGF_versions, so they were only used by
the card bios setup; I may have failed there, but it didn't
hurt anything.

I still don't understand *why* the original bank setup works...but it
does, so I left it alone.

And no, I don't think the PSGF_ equates got changed. No real
reason to do so. I think the PSG_ function equates should be
removed myself (they are only applicable for the bios player),
but I can also see where it might cause other problems.

So, unless I'm having a terrible senior-moment,....

You too? I have them all the time...

You are setting your new PSGF_* equates in squirrel.s

??  afaik there is no squirrel.c to generate a .s file.
And .s is a generated file, so it has to be somewhere else.
(psgdefs.h)

Okay, I'm gonna start looking now....
We -will- get this sorted out

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there!
You'd have to tell me what it is that you guys are using it for.

Nope. I renamed the bios function numbers to PSGF_xxx.

It's used to make calls to the bios, for things like setting up wave table, envelopes, etc. And for starting playback
Look at the actual bios stuff; there's a table of functions, and those are the indexes.

And in any case, it's set to 3 explicitly in the old Huc...both places, iirc.
Which should kick up a "redefinition" warning, but since the values are the same, not an error.

...I'm not really sure under *what* circumstances LIB3_BANK is used

Yeah, I figure thats what the problem with bank overflow is.
I *think* they may be included by default.
I'll sit down tonight and figure out how the banks are being used.
But overall, I'm probably gonna have to change more than sound.inc/sound.asm to get it straightened out.

The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte. It uses the HuC bios
interface (a bunch of simple asm routines to call the bios functions). Most programs I've seen don't use it, other than possibly the play function.

[Fighting Street / Re: Do we need a Turbob Call to Arms]

Remember Turbolist? Back in like 1993-1996 or some shit? It was great. Fuck, everything else. Black Tiger? Set it back up please. 
Were you on that ARK?

No, but I was.

My point being, one could make a similar argument comparing turbolist to the PCE forums. (could but would be totally wrong) Guess what though? I do recall some dumb ass on there too.

Agreed. I wonder how many of them moved here, later.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Elmer, I gots a question....

First, I haven't grabbed the latest version of Huc. I'm still working with the last one.
In startup.asm. line 139 (by my editor), you have a check for NEED_SOUND_BANK.
If that's true, you set PSG_BANK. (presumably to 4, but I could be wrong there)
Is that supposed to be the bank for the psg player?

If so, there's a problem.  system.inc uses PSG_BANK for the bios function number.
And if you are using HuC, won't that overlap with either CONST_BANK or  DATA_BANK?

Also, is LIB3_BANK used by default? My first test program compiles/runs fine as a cd with the old Huc, but complains about the banks being full when I compile as cd with the new Huc. Any ideas there?

[Off-Topic / Re: What do you depise AT THIS MOMENT, literally....]

FUCK ME, there was a tiny hole in the garbage bag and a trail of soiled cat

BTDT. No fun at all.
At least it was a small hole, I had a clump fall out and splatter once. Talk about a stinky mess...

[Localizations, Games, Apps, Docs / Re: PC Engine/TG-16 Music (MIDI to MML to SQUIRREL)]

Just out of curiosity, windcharger...

Are you using the new HuC?. The old Huc? Building for CD, or building for card?
Is this actually intended for a game, or just for learning how to do it?

I can't speak to Psycho Arkhan Asylum's intent...but I do know he prefers to create the songs via midi (he can actually play a keyboard fairly well); the rest of it it is just his workflow to get it into an acceptable pce format.
Does anybody know it 3mle (or whatever it is) can output the midi as text? If so, it would be fairly easy to write a filter that converts it to pce format.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

So, I didn't really follow along of what you're trying to solve.

Not a timing issue, yet. I'm trying to get a feel for how quick and hsync routine would have to be to avoid the active display area.

So, if I'm understanding it correctly, I have about 5us after hsync before color burst and active display....That's gonna be tight.
......................................
Edit:  My bad. I misunderstood. I had to go read it about 3 more times before what was where on the diagram clicked.

Hsync is gonna be triggered after the color burst, and very shortly before active display starts.
That actually explains some of the color tearing i've seen.

Thx.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Elmer:
 Got it. I'm not sure if the mml compiler supports "Time base" mode or not (that's the packed format, iirc). In any case, you would need as assembler call (and knowledge of where the variable is at) to do tempo changes that way from HuC. Something the psg bios doesn't (natively) have, afaik.

So, here's what I think I'm gonna do:
I already have the patch in to add the underscore to the register name. I haven't exhaustively checked it yet, but I'm fairly confident it works.
I'll 'extend' the MML parser, so that upper-case notes will be direct mode, while lower case notes will be time-base mode (which will have the happy side-effect of allowing for shrinking the output).
I'll probably add a simple psg-bios call to change the time base.
Then we can start discussing in detail how to alter the timer/hsync irq to get things working right for samples.

One question for you and tom, though. How much worse will mapping alternate pages make the timer stuff?  IF we add sample support, I believe it's going to need extra space for the samples; some of them are going to be quite long, and the mml player is currently limited to 2 pages. Sort of. (That's a whole different discussion.)

..........................
Tom:
 You're the only leftover hardware guru afaik. Do you know when the hsync irq actually occurs? Is it at the end of the active scan-line display (ie, start of the back porch), in the middle of the hblank area, or at the beginning of active display?
More specifically for what I'm thinking: How long do I have between an hsync irq triggering and the actual start of active display? The entire hb;ank period, or 0 cycles?

...........................
Everyone else:
 Stay tuned. This could get interesting, and we may actually hash out how to add samples to the psg player.....

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

*** WARNING: Wall of text below. If you're not interested in technical arguements, or have not been avidly following ths thread, you may ignore this post ***

Quote from: TheOldMan on Today at 12:38:03 AM

    If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.

If someone were to implement that kind of scheme, then you'd get as many calls as you like ... it's just a case of defining your tempo as something that's an integer multiple of 1/6991 seconds.

I can't define the tempo. Tempo is how fast the song plays (not how fast the irq tick is). If a song is at 120 BPM ( a popular tempo),
that means it plays 120 whole notes in 1 minute. Or 20 in 1 second.

I -can- define how  many down counts are used before the psg player is called. So yes, in 1 second I can get as many calls as
needed. But I still only get 1 call per group of counts.
In order to change the *tempo*, I have to change the counter limit, which the psg player does, by changing the timer interval. I understand
it *can* be done, but it's a bit more complicated than just "do this".
How would you deal with interrupts in such a situation? (Remember we are getting 6991 of them every second) There's no guarantee that
an irq won't occur while the player is updating. Do those interrupts count towards the next psg call?
And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?

Those are the things I don't understand about how this would work. (And keep in mind, irq problems are a real thing, as rovers problem shows)

But while you can say that you *need* fine tempo adjustment for some reason ... most of the old games were done without it.

You never played a game where the boss attacked faster as you did damage?
Listen closely; the music usually speeds up, too.

And ... what's the fuss with 1/32 notes (a demi-semi-quaver)?
Doesn't the System Card Player already limit you to 1/16 notes (a semi-quaver)?

I'm not sure if the system card limits you or not, but that wasn't the point of the 1/32 note question.
*IF* you are limited to -only- vsync, 1/32nd notes are impossible. They require a fraction of a frame.
But, if you use the timer irq, you can update at  less than 1 frame. That was the point.
So the timer -is- needed. And without using the timer, There's no way to get 1/32 notes.

(And. as an aside, 1/32 notes are possible to play in the player. They just take 1 tick, instead of the 1.5 they should be,
causing them to de-sync. Which is probably why they aren't supported. And how we found the trick below, thanks to
a bug in squirrel during development.)

However, with the timer, we can use the following trick: Write the 32nd notes as 16th notes. Double all the other
note times. And run the song at double the tempo. Sounds exactly the same.
And you can do 64th notes by doubling again. Makes for some smoother arepeggios, and doesn't do too bad
as a slide. (something the psg player is lacking in)

And before anyone asks, you can change the tempo before a measure, double the note length for just that measure,
and then re-set the tempo. Provided you have a fixed tempo (ie, you don't call the psg setTempo() function to speed
the whole song up)

It's certainly possible, but it seems like a very high cost to allow both samples and a finely-adjustable tempo, and I really don't see the point....

This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much

Which is part of the reason I was asking about running it from HSync.
*IF* it can run off of hsync...
1) you could do a quick sample update  (lda  [samples],x / sta )
2) it would be at a decent rate (15 Khz, right?)
3) It could be hooked in via the user hsync hook.

I'm not at all sure it would work, and would require a channle just for samples. But it's interesting to think about....
I'll give you one more thing to think about, too. The psg player keeps a bit-mapped byte to indicate which channels are in use.
It should be possible (though not necessarily quick) to check the byte and find an available channel

The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???

For the player, it is. Once the player starts processing, it locks itself out from further calls until it is done.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

So if you wanted 108hz tempo, set the TIMER to 6991 khz, set the software down counter to 108 (instead of writing it to the TIMER counter port), and on each TIRQ call decrement it. When it reaches 00, pass control to the PSG player. Otherwise, on each call you can now write a sample to any channel you like.

I understand the theory (sort of). Here's the problem I have....

I assume setting the TIMER to 6991Khz is meant to lock in a particular clock for the timer.
If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.

Now, assume it works (and I think it can, by appropriate choices for the parameters). How do I speed it up? Change the value for the down counter? So i would need a table for the different  tempo/downcounts? Okay, and doable. So it should work.

But now I'm effectively duplicating what the hardware does in software.
And I would still have to send out a sample, regardless of whether the psg driver runs or not, wouldn't I? Otherwise, I'd end up missing samples.

I can see that it should work, but it's not obvious (to me, anyway) how it would be implemented.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Yeah, good point. If your code that's making these changes to the scroll are at the very edge of vblank's end, then it's possible something in vblank code is pushing it over.

It's not even that. Consider the following:
You have 2 scroll regions, each taking half the screen.
You also have the player playing, on the timer. It just so happens that when you start the music, the timer irq kicks off it's countdown at just before that same spot, due to initialization operations.

Now, during active display, you update the scroll areas, and they get re-sorted. The player doesn't have much to do, so its okay.
Until you hit a point in the music where a lot has to happen (for example, we need to change waves). Now the player will update. It takes longer than 'normal' because of the extra things it has to do. So your game code is delayed a little bit more than normal. And you end up (eventually) changing the parameters for the bottom scroll region. Unfortunately, because of the sorting that happens, the scroll update is delayed.

By one friggin scanline. Which means the bottom region bounces up and down.
Yes, it really does happen.
In fact, it can happen with small scroll regions near the top, and the player on vsync also.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

....what is the sort all about?

My understanding is that the scroll regions are sorted by display lines. Then, when an hsync occurs, you don't have to look for the region to see if things need changed. Because they are sorted, you can check the current region, and if its the correct line, update the scroll registers and move to the next region.

Sorting is needed because the scroll regions aren't fixed in place. You can move region 1 to any (valid) spot on the screen; you can also expand/contract them, from frame to frame. So the  regions need to be sorted before being used. IIRC, something like this happens in some example code on how to use them.

The problem comes in because of that; iirc, when you update a scroll region, it re-sorts them (at least in the code I was looking at). Which causes problems.
(ie, what if they are being sorted and an hysnc occurs, for a matching line? for one example)

....................

...damn ass musicians always wanting the world lol.

+1. Though in fairness, Arkhan does manage some really nice sounding stuff in a small space...

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

All channels, or any specific channel and any number of them, can be set to DDA mode. Or do you mean from the BIOS psg player?

Yeah, i went and looked it up. All 6 channels can do DDA. Would probably be easiest to hack in on channels 5-6, since there's already support in the player to switch modes (ie, noise mode)

...To hack in sample support, it seems that simply setting the PSG player tick to 1 and have the hook do the down counting and call the PSG player when that expires, for tempo control.

I can sort of see how that might work.
The psg player doesn't really have a 'tick'; each call, from vsync/timer is used to count down values. That's easier to explain (to musicians used to midi) as 'ticks'. Wouldn't you have to run the timer at a high rate (ie, low count) to do that though?

I'm not sure how much space the ripped player takes up in squirrel package,

~8k for the player. Some more in the library page for the actual driver call. (ie. mapping things in, etc)
Same as bios. And yes, iirc, building a cd project changes how the psg setup stuff/driver is done; in a non-cd project, that code is in the library pages, while building a cd project substitutes the appropriate bios calls. Unless you removed it, the player code would still be compiled in, just never used. (My bad).

Are people really ignorant of PCE audio stuffs??? Nobody reads the PCM threads I post either?

Yes.
I read them. Sometimes I even sort of understand them. Once in a while, I even catch a glimpse of how they work. Not all of us are that into the actual audio processing/hardware operations. Or have studied it in that much detail.

Unless Old Man and team get this figured out in time when you need it, hit me up when you guys want to do sample streaming support.

Go for it. I have enough other things to do. (Like getting the player to work with the new Huc. Including timer irq support)
If you get it working, pick an unused bytecode to indicate sample playback, and I'll see about putting it in the mml compiler.
..........................
I figure if you pump out the sample values on hsync (assuming 262 hsync/frame) you could handle 12KHz at 5-bit resolution. Not exactly cd quality, but probably good enough for recognisable speech/sfx.
Also, when you re-sample for pce, are you scaling down and interpolating over time, or what?
I've read  some about it, but mostly have been using sox to do it...

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

It'd be nice to have realistic sound effects, rather than trying to reproduce a cat meow or screech using musical notes.

If you can settle for low quality.....
Convert the effect down to 5 bits, split it into 32-byte chunks, assign a wave number to each, and cycle through them. (load wave n, play note, load wave n+1, etc) It's not gonna be high-quality, but someone else was trying to do this a few years ago.  I remember fixing squirrel to get it work.

BUT...

What you're referring to is just simple sample playback.

...a sample would have to disrupt the music to play.

Not necessarily. We haven't figured it out yet, but there are 2 channels on the psg that can be set to "direct-dda" mode. In theory, you could use those for sample playback. Would require a streamlined irq routine, I think.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

What-on-earth do you want more than 4 regions for??? 

(faked) multi-layer parallax. Say, 3 sky sections and 3 ground sections.

why wouldn't they just use sprites for the top and bottom status bars???

Because they're in use for enemies/shots/etc. Not to mention, it's easier to update the BAT than it is to re-load the sprite data (especially for scoring).

From what I've seen, the scroll() does it's sorting and preparation during the vblank interrupt.

What version of scroll are you looking at?
I don't see how this would be possible (ie, only sort/prepare during v-blank) without some kind of buffer....

why run Squirrel in a timer-interrupt anyway???

Because we would like to speed the sound up during boss battles. And tempo adjustments are only available using the timer irq.

I find it highly-unlikely that anyone is currently creating music complicated-enough that a 120Hz or 240Hz timer-interrupt would make an substantial quality-difference to the stepping in the envelopes/sweeps.

Take it up with Arkhan. He had a 135 BPM song with 32'nd notes for an arpeggio using faked adsr envelopes.  It made a difference to him.

And if anyone is using Squirrel on a 60Hz timer interrupt instead of the vsync interrupt, then they need to be slapped around the face with a wet kipper

...where's that wet kipper. I owe him a few, I guess....

.........................................

As Bonkuts said, this sounds more like an interrupt-handling issue

I agree. I just don't know which irq is actually causing the problem, or why.

The bios guys were pretty good, imo.  Vsync/HSync/Timer already have lockouts to prevent multiple nested calls (ie, if you get a hsync and are already servicing one, it will return right away). The bios player also has a sound lockout (ie, if it's in use, and an irq occurs, the sound part of the irq returns immediately).

It's been a while since I looked at all this, though. And I never was good with irq code.

I very frequently use all four scroll regions.

Rover: We did 5 or 6 on the pp title screen. You just have to adjust some sizes for the scroll list.
Not something I'd want to do in a high-speed game (unless scroll became way faster), but definately fixable. Without sprite/tile trickery.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

IIRC, Rover had this issue where it's slow, so doing other things (like using Squirrel) can cause flicker/line spazzery.

scroll() is hooked into the hsync irq. It has to monitor the raster-hit irq bit.
One problem with that is, I think, that it re-sorts it's list (at least thats what I think it's doing) during this process.
Which leads to the problem; if something is already in an irq (be it vsync or timer), the hsync routine can get delayed, causing the scroll area adjustment to be delayed a line.

I'm not entirely sure why/when it happens, but it does happen. Especially is squirrel is running at a high timer rate, or if lots of small regions are being constantly scrolled.
I think this could be solved if the code maintained a dual-buffer setup; the current list could be used for the irq (and it could be really fast) and the 'new' list could be updated/sorted as needed, and moved to the current list during vsync.

But thats all only a wild guess, and I'm not sure it would actually fix the problem.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Hrm... I am not sure, as 32x3 8x8 tiles comes out to 0x600 words, not 0x800 words... unless the compiler is assuming 32x4 for some odd reason?

IIRC, the pcx->pce conversion routine works in 16x16 pixel blocks. (ie, sprite-sized).
I prefer to use an external converter and a #incbin() nowadays, due to stuff likethis,

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Does anyone know why there's special-handling for bank $FE in this HuC code?

Not certain about this, by any means, but...
Huc generates a 'hidden' bank for subroutine calls, so that they can be mapped in if required.
I think that may be why HuC subroutines have to be 'call' ed, so they can be mapped in.

I've run into situations where HuC/Pceas will place subroutines from the same file into
different banks. If those routines happen to be all assembler (Yes, I do that), you can't do
a jsr to call the routines. You need to use the HuC call.

Also, I use the vram[] syntax quite a bit for 'quick and dirty' access to sprite/bat information,
especially if I'm using vram as a map. Never used the vdc[] syntax, though.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

If I recall correctly, it's because the registers can't be read from the hardware.
Or at least not all of them can.

+1. I know the read data can't be (ie,vdc register 2.) Think about how it works.
And, if I remember correctly, most of the others are read only, accordingto the vdc doc in the docs/pce directory.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Think of how many PCE HuCard games were released after that, a lot (most?) using their company's own custom sound drivers.

I do not think many companies developed their own sound drivers; I suspect it is more likely they modified the 'stock' system card one. 

...do you believe that the System Card 1.0 Player can recreate ALL of those effects???

No, but I think a new modifed version could. Although I can't swear it would be compatible with all existing games.
I would especially like to incorporate the bonk trumpet sound. I think bonknauts Azazel (?) driver could do that.

And just out of curiosity, has any one put the plan all together, yet?
We can make a new bios card (right, desh?) with 512K ROM (lots of room for extra code), 512K RAM (for bigger games...or maybe streaming video buffers) that should be backwards compatible with bios 3.1.  Just saying.....

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?

My goal is to split things up, so you only include the stuff you actually use. If you don't need scrolling areas, you don't include that code; if you do need them, you include them. If you don't need the system font, don't include it. Things like that.

I'm finally getting comfortable with HuC, and the stuff it uses. I have no desire to learn a new compiler setup, unless its something I write and am initimately familiar with. I would also like to be able to move functions, etc between compilers/assemblers/etc. I understand there would have to be changes made to do that. The basic code, however, -should- be moveable.

In theory, this would allow groups to set up a project, using what they are comfortable with, and the code could be re-built using whatever compiler/assembler/etc.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Back on topic. Avoiding the arguement.

I'd prefer to avoid the overhead of a JSR if possible (especially in a TIMER interrupt)

I understand, but that's not -quite- what I was thinking...
My thoughts were more "We need to call the user routine from an irq...If we used a standard macro name....Wonder if that would work?"

If those were something like "sound/vsync.asm", "sound/timer/asm", and "sound/system.asm", then you'd just change your PCE_INCLUDE environment variable to include whichever driver you wanted.

I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one. Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically). And, if you didn't want sound at all, you could comment out/remove the #define from the main program.
When you wanted to choose a sound engine, you could see whats available by looking at sound.inc.

........................
Just an idle question: Is it possible to replace the 'new' system stuff with the 'old' Huc stuff, and still have the compiler generate a working executable? Or have enough things in the compiler changed that that's no longer feasable?

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I think by MOD, you're probably meaning "tracker" or tracked format?

To me, MOD means some program that looks sorta like a piano roll, and makes sound.
I don't really understand the difference between trackers and mods, and probably never will (I don't care that much how it makes sound. Just that it does)

Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

The next big question is going to be how to get a decent (and legal) sound driver.

I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]

Do you know of any other good, popular MOD players?

The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

It's not mod files....

Okay. You would know more about that than me; I only assumed mod files because of the naming.

My point is that he was trying to get a new sound engine in Huc. That's what caused the problems with using the (disassembled) bios code. I think that's a good idea, just a poor way to do it :/

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Yep, that's the one.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I'm particularly interested now in what changes were made to the irq handler.

From what I've looked at, at least the timer irq does nothing now (I think). It requires setting up a user irq handler to be useful. That's probably why the mml player doesn't work on the timer.

I'm not even sure there is a mod player, yet.

There is a pair of files (st.c/st.h) that appear to contain the code to play mods (?). Not sure if they get included in the system or not, but they are available for use.
Something called SimpleTracker? That's all I know about it.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

What mod player program???

I'm not sure; I haven't looked into it that much. I'm not even sure there is a mod player, yet.
However, the version I downloaded and set up has tools that work on mod files. Again, not sure
what they do, but they are there.

I assume (and could be wrong) that there is either a mod player in the code, or that one was planned; In either case, I also assume that's why the #defines are there, as support for that.

Note that, like for squirrel, I did a find-in-all-files for IRQ_TIMER and IRQ_VSYNC. The only place they occur are in HuC.h. In addition, I also did a find-in-all on the original HuC files; the defines do not occur there, so they are apparently new.

I'll keep you posted as I look through the code. I'm particularly interested now in what changes were made to the irq handler.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Finally got a chance to look at the code for the new HuC, specifically with respect to the IRQ_TIMER/IRQ_VSYNC stuff.

It's only #defined in HuC.h. As far as I can tell, it's not used anywhere.

Any idea why Uli did that? I assume it's for the mod player, but shouldn't that code be more library-like? Not everyone is gonna want the mod player code in every program.
There's also a handful of new #defines there that I'm semi-sure are also gonna cause problems, notably the ADPCM stuff he added...

Can he even access a #define value in assembler? I never could get that to work....

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

z = a[x+y]    into    a[0] = z[x+y]

Looks like somebody got the macro parameters backwards...