Large Screen BOB problem

BooBoo · 02 May, 2011, 02:51 PM

With a Large Screen Screen 1008x1023 positioning a BOB around Y521 and beyond the BOB becomes distorted
The two images below -The First image shows the BOB at Y520 and the Second at 521

Sprites seem ok - What causes this and is there anyway around it?

BooBoo · 05 May, 2011, 04:37 PM

PowerBobs seems to fix this - But I dont realy like using the PowerBobs version of AMAL as it seems very bugged.

Anyone know of a contact for Manuel Andre?

Hungry Horace · 07 May, 2011, 07:13 PM

Are you using PowerBobs with the reg screen, out of interest?

BooBoo · 08 May, 2011, 10:08 AM

Yep just the Demo version with nag screen

Lonewolf10 · 05 Aug, 2011, 07:13 PM

That's a strange one. I have never seen that before, but I haven't worked with extra large screens in AMOS.

Did you get it fixed in the end?

Regards,
Lonewolf10

judeEZT · 13 Jan, 2015, 09:10 PM

Damn! I'm having the exact same problem.

I'm coding a 8-way scroller and need a large screen, but bitplanes seems get disjointed.

Anyone nows the best way to solve this?

bruceuncle · 16 Jan, 2015, 09:55 PM

If it's working okay in the PowerBobs extension then it looks like an AMOS bug. So I've added it to the bugs register.
Anyone know of a likely cause?

Sent from my Lumia 800 using Tapatalk

SamuraiCrow · 20 Jan, 2015, 07:15 AM

Hmmm... Maybe it's a hardware glitch. Sometimes there would be a problem with flaws in the design of the chipset and it would get worked around in the Kickstart routines but not in the hardware-banging code of the day. That's one reason that using the Kickstart versions of the routines might be preferred.

bruceuncle · 24 Jan, 2015, 02:30 PM

Thanks SamuraiCrow, but I think this one's more likely an AMOS bug as BooBoo mentions that PowerBobs appears to fix it. For now, it's just added to the bugs list. I haven't given it a high priority so I'll find out when I get there, so to speak...

SamuraiCrow · 24 Jan, 2015, 03:12 PM

I'm not sure. Remember that PowerBobs uses the CPU to blit instead of the blitter.

bruceuncle · 25 Jan, 2015, 05:43 AM

Quote from: SamuraiCrow on 24 Jan, 2015, 03:12 PM
I'm not sure. Remember that PowerBobs uses the CPU to blit instead of the blitter.

Ah, now I see what you're getting at SamuraiCrow. Sorry for being a bit dense sometimes

.

Do you think an emulator (I use WINUAE) would be accurate enough to test that sort of problem?

SamuraiCrow · 25 Jan, 2015, 03:42 PM

If you use cycle exact timing for an A500 it should be accurate enough. Also disable the JIT on the CPU for the most accurate tests.

SamuraiCrow · 29 Jan, 2015, 03:43 PM

Sorry, no. But I have been commissioned by the Apollo team to write software blitter routines for an FPGA accelerator so using the Kickstart routines would be wiser.

Lonewolf10 · 14 Feb, 2015, 07:54 PM

I haven't tried doing anything like that with any extensions.

I haven't used it for ages, but at a guess the 'nag screen' will likely be part of the Cold start "C_Lib -> L0" routine. A well placed jmp instruction should enable it to be skipped without causing the rest of it to fall over.
Which version of Powerbobs are you using? If I have it I can give it a try, but no promises...

bruceuncle · 15 Feb, 2015, 02:44 AM

Quote from: Lonewolf10 on 14 Feb, 2015, 07:54 PM
I haven't tried doing anything like that with any extensions.

I haven't used it for ages, but at a guess the 'nag screen' will likely be part of the Cold start "C_Lib -> L0" routine. A well placed jmp instruction should enable it to be skipped without causing the rest of it to fall over.
Which version of Powerbobs are you using? If I have it I can give it a try, but no promises...

Don't do anything just yet. As I'd mentioned elsewhere, I got fed up with not being able to unleash the true power of Resource (its macros) due to all the good info being locked up in a user-unfriendly help system. I'd databased the Resource help data a while back and done nothing with it. So I did a quick and dirty Access report a couple of weeks ago so I could get a preview and read it at last!. (I've attached a PDF of it for anyone interested - I'll be dragging a cross-referenced and much tidied up version out of the database when I get the time.) Fantastic what Resource can really do.

So, I'm in the middle of writing the Resource macros to disassemble ANY AMOS library (both old and new versions). As PowerBobs was topical, that's been the guinea pig for testing. This is not just getting at the code - these macros add in the AMOS labels and equates to make reassembly for the AMOS Pro environment a piece of cake. You get all the Rxxx library macros inserted with the original dc.w lines commented out; plus all the +LEqu.s amos.library calls and the +Equ.s A5 offsets resolved to symbols. I'd created (and posted here a long time ago) the Resource symbol libraries for AMOS Pro. I've modified them a little since then so I'll have to get them together for release too - the macros rely heavily on them.

I always suspected Resource was more powerful that it looks. The version I'm using is V6.06. Does anyone know the legal position with a program like that? I haven't seen that version around in 'the usual places'. Mine came from an image of an Amiga HDD I came across a while back. These macros will only work in V6.06.

The manual attached here was very much created just for me. So there's no contents, index, etc. The first few pages contain the 'general' topics, then it's sequenced in the same order as the menus followed by the order in which the pop-up button windows appear in V6.06. I cut the built-in symbol libraries out as they blew the page count up to 636! They'd perhaps be better published separately as a reference. But all that will be after AMOS Pro V2.10...