The new fork of HuC

[elmer]

I see this too, same source code:

Code: [Select]

.code
.data
.dw $0800
_font:
.incchr "tiles/gamefont.pcx",0,0,32,3

 That looks like the size (in words) of the graphic data.

Isn't 32x3 (i.e. the standard 96 character ASCII font) times 32-byte characters = $0C00 bytes, $0600 words?


<EDIT>

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?

Hahaha ... you beat me to it! 

[TheOldMan]

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,

[Bonknuts]

I see this too, same source code:

Code: [Select]

.code
.data
.dw $0800
_font:
.incchr "tiles/gamefont.pcx",0,0,32,3

 That looks like the size (in words) of the graphic data.

Isn't 32x3 (i.e. the standard 96 character ASCII font) times 32-byte characters = $0C00 bytes, $0600 words?

I was thinking 0 to 3 as four rows, but then 0 to 32 still didn't make sense. I dunno. It's the closest number I could think in relation to it. Maybe vram address?

[nodtveidt]

It probably is size. HuC is probably setting aside 0x800 because 32x3 isn't a multiple of 16 but 32x4 would be. I've noticed that the compiler crashes if I use an image with a width that isn't a multiple of 16 but is still otherwise technically valid (like 31 8x8 tiles wide).

[DarkKobold]

So, its inserting a random zero into the rom, in between incspr? That seems lame.

Also, a faster load_vram would be amazing. wink wink nudge nudge say no more.

[nodtveidt]

A less-glitchy scroll() would be amaze. But I understand how difficult this is to do.

[elmer]

It probably is size. HuC is probably setting aside 0x800 because 32x3 isn't a multiple of 16 but 32x4 would be.

I've found it in the HuC source, and it does sort-of look like something to do with size.

It's set to $0000 for .incpal, .incbat and .incspr, $0800 for .incchr and $1000 for .inctile.

It's used by the set_tile_data() function when used with 3 parameters.

If you use the set_tile_data() function with 1 parameter, then the the tile size is read from the data itself.

You can always override the tile size with set_map_tile_type().

Basically ... it's an ill-concveived way to tag the format of the data.

It will be removed.

So, its inserting a random zero into the rom, in between incspr? That seems lame.

Very lame.

A less-glitchy scroll() would be amaze. But I understand how difficult this is to do.

What's wrong with scroll()?

Remember ... I don't use this stuff, I'd need a good explanation of the problem before it could be looked at.

[Arkhan]

What's wrong with scroll()?

Remember ... I don't use this stuff, I'd need a good explanation of the problem before it could be looked at.

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


It also only lets you have 4 regions by default.

[TheOldMan]

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.

[Bonknuts]

If the problem is because Squirrel is running on the TIRQ instead of V-INT, then just simply add two small bits of logic at the very start of the TIRQ routine; check flag if TIRQ already in progress; if so skip it (return out). There's no need to buffer anything. If the next TIRQ call is "open", it'll get handled there (and so on). Secondly, if the check flag is clear - set it and immediately re-enable interrupts. Just make sure to clear it on TIRQ exit. This logic should be fast/tight at the beginning of the TIRQ; stz $1403, don't even bother pushing Acc on the stack - use a BBRx opcode to check flag and branch out (to an RTI).

If you're already doing this AND it's still delaying H-int routine - then you need to seriously look at both to find out what's going on. Because you have 455cycles to set X/Y regs - they're buffered. I.e. If the H-int routine got delayed and ends up setting X/Y 3/4 way into the routine, it should still work.

[elmer]

It also only lets you have 4 regions by default.

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

I was thinking about reducing it to 3 regions in order to speed-up the sorting time!

A 3-region sort can be done in 3 compares.
A 4-region sort can be done in 5 compares (HuC uses a bubble-sort with up to 6 compares).
A 5-region sort can be done in 9 compares (the bubble-sort would take up to 10 compares).

I can see the *potential* use for 4 regions in a split-screen game with status bars at the top and bottom ... but who-on-earth would write that in HuC, and if they did, why wouldn't they just use sprites for the top and bottom status bars???

If the problem is because Squirrel is running on the TIRQ instead of V-INT, then just simply add two small bits of logic at the very start of the TIRQ routine
...
If you're already doing this AND it's still delaying H-int routine - then you need to seriously look at both to find out what's going on.

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.

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

The stuff that's done in the hsync interrupt isn't particularly slow.

As Bonkuts said, this sounds more like an interrupt-handling issue, or someone is using Txx instructions with larger than 32-byte transfers which are delaying the interrupt.

And for gawd's sake ... why run Squirrel in a timer-interrupt anyway???

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.

IMHO, part of the "sound" of these old consoles is that the music drivers ran at 60Hz.

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.

Is there a list anywhere of HuCard games that ran music drivers at 120Hz with a timer interrupt???

[touko]

IMHO, part of the "sound" of these old consoles is that the music drivers ran at 60Hz.

i agree and it's difficult with that to play PCM with timer interrupt .

[nodtveidt]

I very frequently use all four scroll regions.... both Henshin Engine and Lucretia do this. Henshin Engine's stage 00 actually needed five, but I found a way to work around that with dynamic tiles and sprite tricky-trickies.

[TheOldMan]

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.

[ccovell]

Is there a list anywhere of HuCard games that ran music drivers at 120Hz with a timer interrupt???

Not that I know of, but anecdotally, Keith Courage & Neutopia (though the former only needs it for sound effects).  Out Live runs its music routine at around 108Hz.