PTPlayer / Vertical Blank Interrupt / 060

[a/b]

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.

[DanielAllsopp]

Originally Posted by a/b

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.

This confuses me then, the font and its mask data are the only pieces of data are INCBIN'd instead of allocated and loaded, but it is in a SECTION which is marked like:

SECTION ChipData,DATA_C

mainFont:
  INCBIN "data/bob.font.main.8x8.bin"

mainFontMask:
  INCBIN "data/mask.font.main.8x8.bin"

This is then loaded like this:

  lea.l mainFont,a1
  lea.l mainFontMask,a2

which corresponds to $dff04c and $dff050.

Originally Posted by a/b

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.

Thanks, I'll take a look at fixing that

[roondar]

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.

[roondar]

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.

[DanielAllsopp]

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?

  CNOP 0,8
Screen:
  ds.b Buffer_Height*BytesAllBitplaneLines

Regarding the fast memory, I'm at a loss as to why it's not working correctly as the data is in a DATA_C section. I've tried referencing the labels directly, and using pointers but neither work.

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!

[roondar]

Originally Posted by DanielAllsopp

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.

It actually doesn't work on a chipmemory only A1200 either (I've attached a screenshot of what happens when you start scrolling in WinUAE using Cycle Exact mode, this happens on a real A1200 as well for me). The bitplane pointers must always be at multiples of 8 when using 4x fetch mode. Even when scrolling . So you can't simply add 2 to them after every 16 pixels. Instead, you scroll for 64 pixels and then add 8.

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'.

The screen buffers are allowed like this, which I assumed was allocating the memory on a boundary of 8?

  CNOP 0,8
Screen:
  ds.b Buffer_Height*BytesAllBitplaneLines

Yes, they absolutely are, but when you update the pointers during scrolling they must also be at multiples of 8, so you have to increase the value by 8 every time and not 2

[DanielAllsopp]

Aye aye aye... there's a can of worms opened here!

Thanks roondar! I'm on it. Fecking FS-UAE!

[StingRay]

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.

[Galahad/FLT]

Is your emulated system using 2meg chip ram or larger?

[roondar]

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.

[DanielAllsopp]

Originally Posted by StingRay

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.

Thanks! I'll take a look at this. I actually knew about the copper list, but haven't done anything about it yet

Originally Posted by Galahad/FLT

Is your emulated system using 2meg chip ram or larger?

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.

Originally Posted by roondar

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.

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.

[phx]

Originally Posted by DanielAllsopp

Regarding the fast memory, I'm at a loss as to why it's not working correctly as the data is in a DATA_C section.

Maybe the section's Chip-attribute is lost while linking? How do you generate or link the executable? I would use a debugger to determine the address of

mainFont

for 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:

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..|

I've tried referencing the labels directly, and using pointers but neither work.

You should set a breakpoint before writing to the BLTxPT registers and inspect the data. Or even earlier, to find out what happens to them.

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,a7

and shouldn't appear anywhere else. Use it as a breakpoint and debug your code.

[phx]

Originally Posted by StingRay

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.

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?

[DanielAllsopp]

Originally Posted by phx

Maybe the section's Chip-attribute is lost while linking? How do you generate or link the executable? I would use a debugger to determine the address of

mainFont

for 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:

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..|

You should set a breakpoint before writing to the BLTxPT registers and inspect the data. Or even earlier, to find out what happens to them.

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 a6,a6

and shouldn't appear anywhere else. Use it as a breakpoint and debug your code.

Yeah, I can set breakpoints, probably not as easily as you can in WinUAE but I'll give it a go.

I'm building the project with a makefile with the following:

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)

[phx]

Originally Posted by DanielAllsopp

I'm building the project with a makefile with the following:

Looks good. So debugging your blitter setup is the way to go.

[DanielAllsopp]

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!

[a/b]

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?

[DanielAllsopp]

Originally Posted by a/b

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).

Amazing! What a spot, it works as expected now! Thank you so much!

Originally Posted by a/b

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?

Again, thank you for your insight. I'm interested in learning a bit more about how these misaligned accesses work so I can avoid them in the future. The exg a2,a3 code came from one of Photon's tutorials so not sure how that's supposed to work.

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

[a/b]

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.

[mcgeezer]

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

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