English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 05 September 2020, 14:33   #241
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
HAM + Dual playfield

New undocumented feature:

If both HAM and DPF bits are set (OCS/ECS): HAM logic gets strangely mixed with dual playfield.

- if HAM selection bits are zero: color selection uses dual playfield color selection logic.
- if HAM selection bits are non-zero: selected R/G/B component value is palette _index_ number of current pixel. In other words HAM planes 0 to 3 raw value is not used like normally but they are processed using dpf logic which returns palette index.


I am not sure why no one else has found (or reported) this. I also missed it when I tested weird combinations long, long time ago. Originally found by vAmiga author.
Toni Wilen is offline  
Old 05 September 2020, 15:40   #242
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 326
Quote:
Originally Posted by Toni Wilen View Post
New undocumented feature:

If both HAM and DPF bits are set (OCS/ECS): HAM logic gets strangely mixed with dual playfield.

- if HAM selection bits are zero: color selection uses dual playfield color selection logic.
- if HAM selection bits are non-zero: selected R/G/B component value is palette _index_ number of current pixel. In other words HAM planes 0 to 3 raw value is not used like normally but they are processed using dpf logic which returns palette index.
That's interesting! Just to make sure I understand that correctly:

a) Direct colors will be picked from a 3+4 (08 is transparent) color palette like on a 2+2 plane DPF? Also using only palette colors 0-3 and 9-11 like DPF?

b) If "foreground" planes are non-zero, "background" planes are ignored? So "11" (fg) + "00" (bg) gives the same value as "11" (fg) + "11" (bg)? And the modified R/G/B component can also only be in the range 1-7 0-3 and 9-11?

And I guess changing playfield priorities will also work exactly like in DPF mode?

EDIT: corrected color ranges
chb is offline  
Old 05 September 2020, 16:28   #243
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
Quote:
Originally Posted by chb View Post
That's interesting! Just to make sure I understand that correctly:

a) Direct colors will be picked from a 3+4 (08 is transparent) color palette like on a 2+2 plane DPF? Also using only palette colors 0-3 and 9-11 like DPF?

b) If "foreground" planes are non-zero, "background" planes are ignored? So "11" (fg) + "00" (bg) gives the same value as "11" (fg) + "11" (bg)? And the modified R/G/B component can also only be in the range 1-7 0-3 and 9-11?

And I guess changing playfield priorities will also work exactly like in DPF mode?
Yes.

HAM selection bits (planes 5 and 6) are not affected by DPF.

Everything else uses DPF logic. Note that planes 5 and 6 are not filtered when selecting R/G/B replacement palette index, they are included in DPF color selection, just like in normal 6 plane DPF mode.
Toni Wilen is offline  
Old 11 October 2020, 03:57   #244
Jobbo
Registered User

Jobbo's Avatar
 
Join Date: Jun 2020
Location: Lexington, MA
Posts: 195
BLTAPTH ignored in line mode

In line mode the HRM asks you to fill in BLTAPT (high and low) with dy4-dx2 as a long word.

However, I've seen demos that don't set BLTAPTH and in my own code I can set it to anything and things still work fine.

So, it seems safe to assume the blitter ignores the high word.

Might be common knowledge, but I didn't see it in this thread and it was news to me.
Jobbo is offline  
Old 08 March 2021, 21:09   #245
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,030
Quote:
Originally Posted by Toni Wilen View Post
Even "simple" CIA chips can have secrets.
On the subject of CIA secrets, can anyone confirm this oddity?

The HRM's description of the CIA TOD counters reads as though the read latch is engaged by reading the high byte and remains high until the low byte is read - but having seen an access pattern today that trips up Minimig but which I believe works on real hardware, I believe that that the read latch is also cleared by writing to the low byte.
Can anyone confirm?

I also noticed that the Minimig CIA implementation doesn't engage the read latch at all if the ALARM bit is set. Is this correct?
robinsonb5 is offline  
Old 09 March 2021, 08:31   #246
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
I remember testing these long time ago, current UAE behavior:

Read TOD LO: latch cleared. Return latched LO if latch was enabled.
Read TOD MID: nothing interesting happens. Return latched MID if latch was enabled.
Read TOD HI: current TOD value gets latched but only if not already latched.

Write TOD LO: enable TOD. Read latch not affected.
Write TOD MID: nothing interesting happens.
Write TOD HI: disable TOD. Read latch not affected.

ALARM shouldn't affect reads, only writes.
Toni Wilen is offline  
Old 11 March 2021, 00:21   #247
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,030
Quote:
Originally Posted by Toni Wilen View Post
I remember testing these long time ago, current UAE behavior:

Read TOD LO: latch cleared. Return latched LO if latch was enabled.
Read TOD MID: nothing interesting happens. Return latched MID if latch was enabled.
Read TOD HI: current TOD value gets latched but only if not already latched.

Write TOD LO: enable TOD. Read latch not affected.
Write TOD MID: nothing interesting happens.
Write TOD HI: disable TOD. Read latch not affected.

ALARM shouldn't affect reads, only writes.

OK thanks - this matches the HRM's description.


The oddity I was seeing had two causes: firstly in my test program the assembler had replaced a move with a clr, which of course on 68000 causes a read before the write. This was unlatching the read counter on write.


I was investigating this while looking for a discrepancy between Minimig and real hardware. I think the crucial piece of information I was missing is that after a reset the TOD counter doesn't count at all until it (or CRB) is written to for the first time. Since Kickstart has always done this by the time user code gets a chance to run, this isn't usually noticeable - but from looking at the source, WinUAE appears to behave this way so I guess it's a known characteristic.
robinsonb5 is offline  
Old 12 March 2021, 19:53   #248
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
TODs are cleared at reset. I used "Double Dragon II" RESET Action Replay protection hack to confirm it. This hack allows to execute RESET from chip RAM and continue code execution normally when using 68000.

Test program executed RESET, then it copied CIA registers to RAM.
Waited few scanlines, copied CIA registers again
Waited 1000 scanlines, copied CIA registers again.

Result was always:

00000000 FF000000 FFFFFFFF 0003FFFC (CIA-A in reversed order)
00000000 FF000000 FFFFFFFF 0000FFFF (CIA-B in reversed order)

1000 scanline wait had 76 keycode in CIASDR and SP flag set in interrupt register. All other register contents were identical.

CIA-A 03/FC is due to need to switch off overlay after reset. Normally it would have been 00/FF too.

CIA register copy was done in reversed order to prevent latch related side-effects. I also did it in non-reserved and results were same.

I didn't test ALARM, perhaps later but I assume it is cleared too.

btw, I forgot that ALARM does affect reads, if ALARM is set, TOD LO read does not enable latch.
Toni Wilen is offline  
Old 12 March 2021, 21:37   #249
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,876
Quote:
Originally Posted by Toni Wilen View Post
New undocumented feature:

If both HAM and DPF bits are set (OCS/ECS): HAM logic gets strangely mixed with dual playfield.

- if HAM selection bits are zero: color selection uses dual playfield color selection logic.
- if HAM selection bits are non-zero: selected R/G/B component value is palette _index_ number of current pixel. In other words HAM planes 0 to 3 raw value is not used like normally but they are processed using dpf logic which returns palette index.


I am not sure why no one else has found (or reported) this. I also missed it when I tested weird combinations long, long time ago. Originally found by vAmiga author.
sorry bit over my head, how many colours can you have on each playfield?
Retro1234 is offline  
Old 12 March 2021, 23:21   #250
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,030
Quote:
Originally Posted by Toni Wilen View Post
TODs are cleared at reset. I used "Double Dragon II" RESET Action Replay protection hack to confirm it. This hack allows to execute RESET from chip RAM and continue code execution normally when using 68000.

Neat trick! Thanks for sharing the results - very useful and much appreciated.
robinsonb5 is offline  
Old 14 March 2021, 00:04   #251
lmimmfn
Registered User

 
Join Date: May 2018
Location: Ireland
Posts: 257
Quote:
Originally Posted by robinsonb5 View Post
Neat trick! Thanks for sharing the results - very useful and much appreciated.
Curious , do you see any use for this?
lmimmfn is offline  
Old 14 March 2021, 00:23   #252
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,030
Quote:
Originally Posted by lmimmfn View Post
Curious , do you see any use for this?

Only in making the Minimig FPGA core better match real hardware, and thus avoid an obscure combination of circumstances which was resulting in its system clock running too fast.
The chances of this particular discrepancy causing a problem were incredibly tiny - but as the late, treat Terry Pratchett taught us, million to one chances crop up nine times out of ten.
robinsonb5 is offline  
Old 14 March 2021, 00:52   #253
lmimmfn
Registered User

 
Join Date: May 2018
Location: Ireland
Posts: 257
Quote:
Originally Posted by robinsonb5 View Post
Only in making the Minimig FPGA core better match real hardware, and thus avoid an obscure combination of circumstances which was resulting in its system clock running too fast.
The chances of this particular discrepancy causing a problem were incredibly tiny - but as the late, treat Terry Pratchett taught us, million to one chances crop up nine times out of ten.
Lol, makes sense, im still curious if this is useful in any way, like dual plane with 1 plane using HAM and the other using only colour registers, it would be interesting if thats possible.
lmimmfn is offline  
Old 17 May 2021, 19:36   #254
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
Blitter linedraw with DMA loaded pattern (sort of)

Flexible Zoom / Upfront enables B channel in linedraw mode to load new line pattern words. (normal documented method only allows 16-bit static pattern)

Unfortunately it isn't as useful as it looks. When B channel is enabled, line draw cycle sequence becomes (was known long time ago but I didn't know it actually was useful, sort of):

-BC-BD-BC-BD (normal is -C-D-C-D).

B is loaded twice/pixel which wastes lots of DMA time. Linedraw disables normal +-2 adders, B is loaded twice from same address, then modulo is added, repeat.

Weird undocumented feature anyway
Toni Wilen is offline  
Old 21 May 2021, 21:21   #255
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
Copper blitter wait bug details

Details here:

http://eab.abime.net/showpost.php?p=...6&postcount=35

Basically it is blitter bug, it finishes too early and if CPU steals final D write cycle, in worst case there is no free blitter cycles for final D write until after new blit has already been started.
Toni Wilen is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
who can provide hardware to create ADFs of some old rare stuff like Nautilus...? Bernd support.Other 3 19 August 2011 23:41
Stuff for sale amiga a1200 plus more retro stuff blast MarketPlace 23 22 June 2010 19:05
Action Replay Undocumented Features deicidal support.Hardware 0 01 March 2010 17:15
I've got some Amiga stuff...I want your SNES stuff! Fingerlickin_B MarketPlace 14 20 February 2009 01:33
Amiga stuff for trade for Atari Stuff 8bitguy1 MarketPlace 0 12 February 2009 05:36

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.11011 seconds with 16 queries