03 June 2024, 23:01 | #1 |
Registered User
Join Date: May 2024
Location: finland
Posts: 3
|
Help with mystery blit
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. Code:
> 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. Last edited by stereoman; 03 June 2024 at 23:33. Reason: fixed link |
03 June 2024, 23:18 | #2 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,091
|
! Deleted
The transfer you requested has been deleted. |
03 June 2024, 23:33 | #3 |
Registered User
Join Date: May 2024
Location: finland
Posts: 3
|
|
04 June 2024, 01:09 | #4 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,091
|
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) |
04 June 2024, 20:34 | #5 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,091
|
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. |
05 June 2024, 11:07 | #6 |
Registered User
Join Date: May 2024
Location: finland
Posts: 3
|
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.. Last edited by stereoman; 05 June 2024 at 11:28. |
05 June 2024, 11:27 | #7 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,091
|
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.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
V-Flip Blit question | Brick Nash | Coders. Asm / Hardware | 6 | 13 March 2023 13:41 |
How to calculate possible blit times? | Tigerskunk | Coders. Asm / Hardware | 32 | 11 January 2022 08:24 |
Blitz- cannot blit a shape | peceha | Coders. Blitz Basic | 8 | 10 April 2021 23:56 |
Calculations for a simple blit? | deimos | Coders. Asm / Hardware | 19 | 24 December 2019 14:28 |
[BlitzBasic] blit outside bitmap error | Raislin77it | Coders. Blitz Basic | 8 | 08 February 2014 11:42 |
|
|