05 April 2022, 06:30 | #21 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,053
|
The problem is data you blit is in fast memory ($dff04c and $dff050 contain fast memory ptrs), that's for the corrupt font/text on top of the red robocop image.
Also, DisableSystem is not 100% safe. Code between WaitEOF and AllOff is not atomic (what if interrupt or task switch happens between those two calls and int/dma/vectors are changed, and then later on you restore wrong data?). I'd do $4000 to INTENA right after the call to WaitEOF to ensure the next 6 reads are safe. Last edited by a/b; 05 April 2022 at 06:33. Reason: typo |
05 April 2022, 11:58 | #22 | ||
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Quote:
Code:
SECTION ChipData,DATA_C mainFont: INCBIN "data/bob.font.main.8x8.bin" mainFontMask: INCBIN "data/mask.font.main.8x8.bin" Code:
lea.l mainFont,a1 lea.l mainFontMask,a2 Quote:
|
||
05 April 2022, 12:58 | #23 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
I've checked in the WinUAE debugger and like A/B, I've also noted that you seem to be blitting your text blits from a fast memory source during the intro. See attached picture.
Note that this happens on any system config with fastmemory, it doesn't need to be a 68060. Don't know why it's happening, but I'd look into the text blitting routines for the values you use. |
05 April 2022, 13:46 | #24 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Another thing I've spotted that is likely causing display glitches is that you're using an FMODE value for 4x fetch, but your bitplane pointers are not always multiples of 8. This will cause all sorts of display glitches, including the weird 'double/quadruple' strips on the screen you can see here.
Remember that 4x fetch mode (whether for Sprites or bitplanes) requires the Sprite & Bitplane pointers to be multiples of 8, even when scrolling. This also means your scrolling code needs to use all 64 pixels to scroll, rather than the 16 you seem to use now. Last edited by roondar; 05 April 2022 at 14:00. |
05 April 2022, 14:06 | #25 |
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Thanks for your input roondar; what I don't get though is that this all works fine on a plain old A1200 with no fast ram. Scrolling is fine, fetch mode seems to work fine when scrolling with 16 pixels too. I thought the finer AGA scroll modes for quarter pixels etc were optional and you could indeed still scroll using 16 pixels.
The screen buffers are allowed like this, which I assumed was allocating the memory on a boundary of 8? Code:
CNOP 0,8 Screen: ds.b Buffer_Height*BytesAllBitplaneLines I'm amazed I've even got this far at all without something blowing up as it seems I'm doing a lot of things wrong here! |
05 April 2022, 14:12 | #26 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Quote:
The scroll registers on AGA support 64 pixels of scrolling, plus the extra 2 bits for 1/2 and 1/4 pixels. Edit: For more info, see here: https://github.com/rkrajnc/minimig-m...a/RandyAGA.txt and search for $102 The reason you're seeing a correct screen in FS-UAE might be that the settings of the emulator aren't correct (no cycle accurate), or that it might have a bug in it's emulation of this 'feature'. Quote:
Last edited by roondar; 05 April 2022 at 14:16. Reason: Added a link to the AGA docs |
||
05 April 2022, 14:26 | #27 |
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Aye aye aye... there's a can of worms opened here!
Thanks roondar! I'm on it. Fecking FS-UAE! |
05 April 2022, 14:42 | #28 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
I had a quick look and found 2 problems in your code:
1. your blitter wait is wrong, it reads from $dff000 which it shouldn't do. change tst.w (a6) to tst.b 2(a6) to access DMACONR instead, which is fine. 2. you enable copper DMA without setting the copperlist pointer before which in turn means any random copperlist that was set before will run. I doubt that you want this. |
05 April 2022, 14:54 | #29 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,016
|
Is your emulated system using 2meg chip ram or larger?
|
05 April 2022, 14:57 | #30 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
I've done another test. This time the level itself with an A1200/68020 & 8MB fastram using cycle exact mode. I'm seeing very similar distortions as you've seen with the 68060 in the video. It seems the problem is related to Fast RAM more than processor type.
|
05 April 2022, 15:01 | #31 | |
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Quote:
The A1200 I'm emulating is 2Mb only, the A4000 is a clone as close as I can get it to my real A4000: 060, 128Mb Fast RAM, 2Mb Chip. That's pretty much it, but whatever I do with the FS-UAE configuration, I can't get the same results as Roondar. It's supposedly cycle accurate but I dunno, it's not the same. Yeah, the fact I mentioned the 060 is probably a bit of a mistake; I only mentioned it as that's the only other CPU I have to test with. I didn't think of the Fast RAM, so sorry about that. Last edited by DanielAllsopp; 05 April 2022 at 15:07. |
|
05 April 2022, 15:02 | #32 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,537
|
Quote:
mainFontfor example. I just had a look on the header of the executable, and the last two sections have the Chip-attribute ($40000000), so this seems fine: Code:
00000000 00 00 03 f3 00 00 00 00 00 00 00 04 00 00 00 00 |................| 00000010 00 00 00 03 00 00 1f 90 00 00 10 50 40 00 2e 99 |...........P@...| 00000020 40 00 b4 b4 00 00 03 e9 00 00 1f 90 2c 78 00 04 |@...........,x..| Quote:
I don't know FS-USE very good, but in WinUAE and E-UAE you can break into the internal debugger and break at a specific instruction opcode with "fi". I am using fi cf4f, which is a No-Op exg a7,a7and shouldn't appear anywhere else. Use it as a breakpoint and debug your code. Last edited by phx; 05 April 2022 at 15:11. |
||
05 April 2022, 15:09 | #33 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,537
|
That's new to me. Is there any reason you shouldn't read a normal read-only register, which fulfills the same purpose as another read-only register, just for the delay?
|
05 April 2022, 15:13 | #34 | |
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Quote:
I'm building the project with a makefile with the following: Code:
ASSEMBLER = vasmm68k_mot LINKER = vlink INCDIRS = -Iinclude -Iinclude/ndk -Iinclude/ptplayer BFLAGS = -m68020 -Fhunk -quiet $(INCDIRS) LFLAGS = -bamigahunk # build $(OBJDIR)/%.o: %.s @echo Assembling... $< @$(ASSEMBLER) $(BFLAGS) -o $@ $< # link $(BINDIR)/$(TARGET): $(OBJS) @echo Linking... @$(LINKER) $(LFLAGS) -o $@.debug $(OBJS) @$(LINKER) $(LFLAGS) -o $@ -s $(OBJS) |
|
05 April 2022, 15:29 | #35 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,537
|
|
05 April 2022, 17:43 | #36 |
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Adding Fast RAM to my plain A1200 setup, and everything works as expected, i.e I can't replicate any of the issues Roondar is seeing. Adding a Blizzard 1230 IV to my emulated A1200 with Fast RAM and everything works as expected there too.
I suspect FS-UAE isn't on par with WinUAE... to the real hardware I go! |
05 April 2022, 18:00 | #37 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,053
|
There is a bug, you read a word from the font offset table into d3, and then add d3 as a longword to a1/a2. And d3 has old data in the upper word pointing to some fastmem location.
Either add d3 as a word or clear it beforehand (moveq #0,d3). Also, I've noticed that you do numerous misaligned word/longword accesses. Sure, 020+ can handle that but it's not optimal. E.g. your double buffering code (exg a2,a3, set bitplanes in copper list) reads a bitmap pointer from base+5. Maybe align your data structs if it's not too late/complicated? |
05 April 2022, 18:21 | #38 | ||
Registered User
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 272
|
Quote:
Quote:
Can you point me to to some more examples, and why they're wrong and maybe I can figure out how I avoid them. Also, why are they handled in 020+? It's never too late to change anything, this is after all a learning exercise for me |
||
05 April 2022, 19:21 | #39 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,053
|
OK, to make it simple to understand... If data bus is e.g. 32-bit then the cpu always reads in 32-bit chunks and from 32-bit aligned addresses (0, 4, 8, 12, ...).
If you read a byte from address 5 (data at 5), it will read 32-bits from 4-7 and discard unwanted bits. If you read a word from address 5 (data at 5-6), it will read 32-bits from 4-7 and discard unwanted bits. If you read a longword from address 5 (data at 5-8), it will read 32-bits from 4-7, 32-bits from 8-11, combine those two and discard unwanted bits. And that takes extra time. Additionally, older 68000/010 can't handle combining, and since they have a 16-bit bus a (long)word access to any odd memory address will cause an exception. So at the very least you want (long)word data to be 16-bit aligned (at even addresses). And if you aim at 68020 as minumum, you ideally want longwords to be 32-bit aligned. |
05 April 2022, 19:58 | #40 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Problem here is blitter waits. Set Wait for blitter on in Winuae and the problem goes away with fast ram enabled.
Make sure you load your blitter regs after your blit waits. Tip:- Check your modulos for all blitter pointers Code:
4013ac7c 4a56 tst.w (a6) 4013ac7e 082e 0006 0002 btst.b #$0006,(a6,$0002) == $00dff002 4013ac84 66f8 bne.b #$f8 == $4013ac7e (T) 4013ac86 2d7c 09f0 0000 0040 move.l #$09f00000,(a6,$0040) == $00dff040 4013ac8e 2d7c ffff ffff 0044 move.l #$ffffffff,(a6,$0044) == $00dff044 4013ac96 3d6a 0026 0064 move.w (a2,$0026) == $40142cfe [0022],(a6,$0064) == $00dff064 4013ac9c 3d6a 0026 0066 move.w (a2,$0026) == $40142cfe [0022],(a6,$0066) == $00dff066 4013aca2 2d48 0050 move.l a0,(a6,$0050) == $00dff050 4013aca6 2d49 0054 move.l a1,(a6,$0054) == $00dff054 4013acaa 3d6a 002c 005c move.w (a2,$002c) == $40142d04 [0150],(a6,$005c) == $00dff05c 4013acb0 3d6a 002a 005e move.w (a2,$002a) == $40142d02 [0003],(a6,$005e) == $00dff05e 4013acb6 4cdf 0701 movem.l (a7)+,d0/a0-a2 4013acba 4e75 rts == $00000000 |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Amiblitz 3 and PtPlayer | Nightshft | Coders. Blitz Basic | 4 | 14 November 2021 00:28 |
CIA or vertical blank/copper interrupt for playing music in an intro? | pushead | Coders. Asm / Hardware | 25 | 24 April 2021 11:40 |
Extended Vertical Blank | sandruzzo | Coders. Asm / Hardware | 9 | 23 October 2019 15:17 |
Vertical blank and Bobs | geldo79 | Coders. Asm / Hardware | 4 | 21 October 2019 10:04 |
ASM: Wait for Vertical Blank | Asman | Coders. Tutorials | 75 | 01 October 2019 12:11 |
|
|