Debuging NallePuh...

@kas1eQuote:

Since I like to test things, I could help with testing. I'm just not sure where to start.

HippoPlayer I have already tested under NallePuh and yes it works fine after installing all the dependent library.

@Maijestro

Quote:

No one knows, but its easier if know some program you think might work, with CIAA/CIAB emulation and Paula, but does have intuition gui, and not a custom / copper gui.

I guess this tool can be most useful if you have some source code, you want trying to get working, by emulating some of the chips, you can focus on other things.

Blitz Basic 2 compiled binaries can be a candidate,
Amiga Mode, was not 100% OS clean, but some work can be needed to emulate mouse button and joystick pressing.

Programs that need IO, direct keyboard reading or joystick, is not supported yet. (not sure I want to do any hack.), I can see what I can do within my own ecosystem of tools.

@LiveForIT
Tested new version : installation script fixed, good.
Also, “test” button now surely work and produce sound!

Have question through : previous version of blittler.library was 72.247 of size. The new one in latest version are just 9.197. That expected or something wrong ?

And another question about “CIA” tab : it does have JOY1 and JO2 / Mouse with "Button1/Button2", pressing on which change nothing. Is it expected to be like this for now ?

Related to the tests :

I find out my old "Tales_From_Heaven" game, which have CGX version, and the whole game is a set of executables (intro, end of game, etc, etc), all of which use : audio.device + ciab.resource with P61 mod player. They all fail without NallePuh, and fail the same with NallePuh.

Will you be in interest if I will create bug report about and send you test binaries from ?

I also tried to use some test case using 68k version of ptreplay.library (the ones used for mod playing and use CIA/Paula as well) – and have crashes with NallePuh. Want a bug report about as well ?

There are source code of how usually this P61 replayer assembler functions are used, maybe it will be of any help to understand what missing in NallePuh about: http://aminet.net/package/mus/misc/P6112

@kas1e

It’s strange, I have not made any changes to the test button.

The JOY1/JOY2 will only work while Nalle Puh is active.

It writes to internal variables, that you can read by peeking the hardware registers.
or just take peek in the code and see what it does. I had a idea disable the buttons when Nalle Puh is not active, but on the other hand they do no harm, if you press it.

please write example hardware banging codes, if there are something you know is not working.
(Hardware banging code does not need to be 680x0 assembler.)

It can also be something is mixed up, it was written pretty-quickly, and not tested a lot, like everything else, (Mouse is normally plugged into Port1, Joy1 is plugged into Port2, if I’m not mistaken. That’s how it should be).

CIAA chip emulation works independently from Paula emulation, I’m not sure that’s correct, I believe CIAA should be able to trigger Paula IRQ, but I’m not sure. also, I’m not sure I’m passing the correct inputs to interrupt routines, it just assumed they are similar to Paula interrupt calling.

Interrupt routines are not located/inserted into execbase, you can only be obtain by using ciaa.resource and ciab.resource, program that do odd things, probably will fail.

Programs go into forbid states, are not supported, emulation can not keep time, while OS is locked up.

@LiveForIt
Quote:

I mean GUI of NallePUH have "CIA" tab, in which there are buttons JOY1/JOY2 pressing on which do nothing, even if nallepuh active.

@kas1e

Pretty sure it did something in Deluxe Galaga AGA
(The game is not playable),
so perhaps what your doing is different.

@LiveForIt
What you mean ? I am about nallepuh's preferences. This one have tab cia, in which buttons "joy" pressing on which do nothing. Why ? What their purposes ? Why i can press on them ?

@kas1e

“WMHI_GADGETDOWN” is not working so I had to emulate button up/down by timer. this why perhaps your confused.
Simple thing to do in Gadtools become becomes quite complicated in Reaction, because of that.

I severe I never use reaction again, for anything tiny bit complicated.



IO_BUTTONS_UP is handled by timer because I had to workaround for Reaction (so you find it timer.c)

This perhaps why you think the function is not used?




potgor is one of the hardware registers is DFF016.

http://amigadev.elowar.com/read/ADCD_ ... anual_guide/node018B.html

the custom register is in PUH.c

that you find in

https://github.com/khval/NallePuh/blob ... 3253ce91bae421/PUH.c#L774

@Kas1e

Now that I have established that it is doing something, perhaps its doing something wrong, but at least look at code, before you say it’s doing nothing.

Perhaps the question is why is it in preferences, and answer is simple I had no where else to put it.
as you can see some buttons are not gray, while Nalle Puh is active, this means you can change the settings while Puh is running, and you should be able to emulate joystick / mouse presses in hardware registers by pressing the buttons.

Amiga hardware is messy some buttons are in DFF016 and others are in CIAA / PRA register.

So, what are you having problems with CIAA / PRA or do you have problems with DFF016, or is there something else your having problems with? Perhaps some misunderstanding.

@LiveForIT
Quote:
I am not programmer, I am user, and report all from the user POV.

Quote:

I have concerns with preference GUI and the user based feeling that something is wrong : because when you hit CIA tab, you do have buttons JOY1 / JOY2, etc.: they look like they can be pressed. So I pressed them, and have no visual feedback that anything happens at all, so i am, as user, do not know what happens and what should happen when i press on them. Any pressed button, should cause some visual action : at least that how any GUI works.

But that not really important for now, just point out on obvious from user's POV thing which make me curious right after i hit CIA tab.

@kas1e

its a avtive low signal on DFF016, i will swap the bit states.

and also it looks like AmigaOS4.1 is emulates left mouse press just fine.. (but it should be a option to take over I think)

Its Port2 / Joystick port, AmigaOS does not emulate.

WMHI_GADGETDOWN is pretty pointless. The user must be able to cancel mouse click by moving pointer away from the gadget before releasing the mouse button. Software reacting to gadget down would break that.

I found some instructions which tells to use WINDOW_IDCMPHook and WINDOW_IDCMPHookBits to handle IDCMP_GADGETDOWN messages. Also you need to set GA_Immediate,TRUE on the gadgets in question.

Sometimes moving from the classics to the present day is different regarding the old habits. But one have to always learn.

@TSK

I my case, I need to know how long button was pressed,
if user needs a long press or a short press, using a timer means button press time is fixed.

Also I can't use Delay() as it blocks the event loop,
as I need to keep track of the timer signals.

This why my code got lot more complicated, when I can’t have event down, and event up.

so the code, remember when the button was presses, then continues checking time passed, until x amount time has gone by, then it simulate button released. and does that for etch button. So code changed from being event driven, to become a pull driven. Not as bad as busy loop, buts not ideal.

As you point out there is logical error that BUTTON_UP is the same as BUTTON_PRESSED_CONFIRMED, as you pointed out, BUTTON_PRESSED_CONFIRMED should happen when mouse inside button and there is a BUTTON_UP event, what I want is unconditional BUTTON_UP event, as Reaction does not use same event handling code and is black box, from my point of view, this kind of things can be problematic.

@LiveForIt

Maybe adding to the button object creating "GA_Immediate, TRUE," makes WMHI_GADGETDOWN work.

GA_Immediate (BOOL)
When set indicates that the gadget is to notify the application when it becomes active. This attribute corresponds to the GACT_IMMEDIATE activation flag.

Defaults to FALSE.

Applicability is (OM_NEW, OM_SET, OM_GET, OM_UPDATE)


...
LAYOUT_AddChild, ButtonObj = ButtonObject,
GA_ID, GAD_BUTTON,
GA_Immediate, TRUE,
//GA_RelVerify, TRUE,
GA_Text, "A button!",
GA_HintInfo, "The default hint info is this",
ButtonEnd,
CHILD_WeightedHeight, 0,
...

@TSK and@jabirulo

thanks for help, I have look at it, when get the time.

@kas1e

P6112

So, from what I can see P6112 has issues, first of all the example try mess with view and take over the screen, and setup copper lists. I removed that.. I added the executable file to Compatibility prefs, to disable JIT, and this what I find in DumpDebugBuffer:

a0 = 0x78

Disassembly of 68k crash site:
67B1943C: 2750 04B6 move.l (a0),0x4b6(a3)
67B19440: 43FA 0F7E lea 0x67b1a3c0(pc),a1
67B19444: 2089 move.l a1,(a0)
67B19446: 700F moveq #0xf,d0
67B19448: 4DF9 00DF F000 lea 0xdff000.l,a6
67B1944E: 7200 moveq #0,d1
67B19450: 3D41 00A8 move.w d1,0xa8(a6)
67B19454: 3D41 00B8 move.w d1,0xb8(a6)
67B19458: 3D41 00C8 move.w d1,0xc8(a6)
67B1945C: 3D41 00D8 move.w d1,0xd8(a6)

Clearly its reading from somewhere outside of chipset, so there must be some other problem that’s not related to chipset emulation probably.

anyhow by searching for move.l (A0) and looking for one with (A3) as dest, I find line 813 in P96112-play.i

there some lines before that...

move.l P61_VBR_-P61_cn(a3),a0
move.l $78(a0),a0

So something strange is happeing here...

the content if A0+0x78 should be what A0 has, but I guess, there is exception that cause the move.l to be ignored, and end up with some junk in A0.

if content of A0+0x78 is 0x78 then that is too big convenience.
If emulation is buggy, I think that’s unlikely lots of 68K programs work on AmigaOS4.

Unless I don’t know 680x0 that well, can be the case as well.

A3 is 0x67B1A556 so its not a NULL pointer.

@kas1e

lea p61coppoke+3,a4 ; only used in P61mode >=3

Well thats not true, if I set A4 to 0xDEAD0000 and it started crashing somewhere else.

The P6112 example is really full of issues, it seems, its not good test subject to find out if there is anything not working in NallePuh.

Because first we need to disable cooper code,
and then find the bugs in P6112,
and fix the lack of conditional checks,

That seams be a issue with code, Proton / Scoopex is a guy who does not like to use LVO’s, it’s not particularly friendly code to read, (unless you remeber offset numbers) it’s not a type of code that I will call self-explanatory,
you need to take the code apart and put it back together to see what it does. If he had used more sub routines it be easier to see what code is doing, not sure if it ever was written to explained to someone. He does have some comments in there at least. Perhaps code was never reviewed, or as often is, developer works alone with little or no feedback.

I really not sure its time well spent trying to understand this code or not, we know ProTracker works in HippoPlayer with ProTracker , the trackers we have problems with is with OctaMedPlayer it might be using different playback routine for ProTracker in OctaMedPlayer. so if we do get it working, it might not explain anything.

Perhaps my time is better spent on improving blitter emulation or joystick support. Or perhaps fix the minor issues with reaction.

I tried this with hippoplayer under QEmu/AmigaOS4-Peg2.
It took me a while before i understood that i had to deactivate it to be able to select mode to be fair.

Hippoplayer now plays a future composer tune via paula, but the timing is all over the place, sometimes too slow, sometimes too fast, can something be done about that? A setting or so I mean or is this just the way it is?

@spotUP

The timing will always be effected by overhead of exception handler, some timing methods are there for better then others.

I guess it uses V/H Scanline positions not CIAA/B timing, there is option in Hippo maybe makes a difference, Hippo Source code is open source. I suck at assembler, so their somethings I probably won’t touch. The only reason I work on this, is because no one else did.

The scanline horizontal position is tricky, because of the busy loops. Perhaps there should be different settings, estimated and or loop until match. I guess there is also possible that vertical scanline position, can miss a scanline position, because it’s always estimated.

You can always have a look at the Nalle Puh code, and see if there is something you think you can improve. I think come down to different modes of operations, more compatible or more precise.

We can make sure ticks threw all the values and be where unprecise. Or we can always estimate the position, in that case a busy loop looks for value 6 or something, can miss multiple times. Or in the worst case never get value 6. a busy loop that does look for exact match greater than 6 or less than 6 should work with an estimate.

@spotUP

Välkommen tillbaka till AmigaOS4! :)