Help with mystery blit

[stereoman]

Hi! I'm trying to figure out why this demo (adf: http://lerppu.net/hackers-juttuja/demo2024test.adf) doesn't want to boot from WB 1.3.

From CLI it boots to a red copper screen, which indicates that a certain routine succeeded. But if you launch it from WB by clicking the icon, it eventually ends up to this weird brown-ish glitch screen after a long wait.

The routine that is in the demopack.exe searches for some words in a small buffer defined in data-section of the executable. By setting some watchpoints, I can see the proper data getting written into memory, probably the operating system exe loader (LoadSeg?). After that, but before my main() function, there's a weird blit, that seems to be originating from somewhere in kickstart rom. That blit then trashes the memory, by setting it zeroes.

> Blitter registers at start:
> PT A=00FCA0C0 B=00001004 C=0000FD78 D=0000FD78
> CON0=030A CON1=0000 DAT A=FFFF B=0000 C=0000
> AFWM=FFFF ALWM=FFFF MOD A=0000 B=FFF8 C=0050 D=0050
> COP=0 PC=00FCB39A

I wonder if someone more prolific with 1.3 internals might know what's happening here? I'm really stumped!

Extra lead: I tested this with a modified WB1.3 disk, that runs the demopack.exe with wbrun in startup-sequence, and I noticed that the test passes. But if I move the cli window, then the blit trashes the memory.

[a/b]

! Deleted
The transfer you requested has been deleted.

[stereoman]

Originally Posted by a/b

! DeletedThe transfer you requested has been deleted.

Goddamn :-) Fixed the link

[a/b]

Not sure why yet, but a WB's blit that does something at the top of the screen (maybe free memory update) gets its blit size changed to 0 in some gfx/OS struct for some reason so it ends up doing a 1024x1024 blit, which is wrong (trashes ~128kb). Code that calcs the blit size is also in rom, so... (I'll check tomorrow). Maybe you overwrite something or maybe the problem is in active view.
For starters, I'd suggest you switch to an empty view at the start of your exe (before killing dma/interrupts):
1. remember old_view = gfxbase->gb_ActiView
2. load an empty view via gfxlib with LoadView(0) and 2x WaitTOF()
3. at the end before exiting, restore the old view with LoadView(old_view)

[a/b]

OK, what I mentioned above didn't help (I've added a wrapper with LoadView() and it still crashed). However, I'd still suggest you add that to your code to ensure it works OK when started from non-PAL screens.

The problem is in calling DOS I/O functions with system being disabled (DMA/interrupts off, vectors changed, ....). I noticed that after your process has started running, there's also a CON process present, so it looked like you're doing console I/O via DOS library. I checked for Input(), Output(), and Write() calls in your exe and patched them out, and now it works fine (the same black/red pattern as when started from shell).
Internally, it looks like the problem is that CON process wants to do some blitting to unexisting console window or something to that tune, and either a Layer or ClipRect struct is fubar, and consequently the blit trashes a good chunk of chip memory (as explained above).
So maybe print something beforehand (e.g. call Input(), Output(), Write("whatever"), and Flush() to ensure a console window is created and rendered), before you kill the system.
And maybe avoid doing I/O unless the system has been restored.

[stereoman]

Thanks a ton for debugging a/b!

This is very surprising to me, since I don't do any kind of DOS I/O in my main() function. I just call Disable(); set DMACON, INTENA and INTREQ and then call the routine that fails.

It must come from the bebbo-gcc's libc which I believe is libnix.(https://github.com/bebbo/libnix) - There seems to be call to atleast Disable() in stackswap.c and also some dos function calls in other init routines, but nothing that would disable the interrupts indefinitely, or call the dos functions with system disabled. Strange..

[a/b]

Initially, I only patched Output() and Write(), and it still crashed. Only after patching Input() as well, it started working. So it looks like obtaining the input handle is part of the libc's init (and the rest could be on demand, Output() and Write() calls are paired for the most part). However, that still suffices to activate the console process (+console window) and causes problems.