Author Topic: Question about rasters and emu's  (Read 5341 times)

0 Members and 1 Guest are viewing this topic.

Offline Devilmarkus

  • Vivid source of indefiniteness
  • 6128 Plus
  • ******
  • Posts: 4.035
  • Country: de
  • WebCPC / JavaCPC developer
    • index.php?action=treasury
    • CPC-Live website
  • Liked: 1014
  • Likes Given: 926
Question about rasters and emu's
« on: 21:05, 08 March 09 »
Hi together,
as I downloaded the new "Star Sabre 128k", I noticed, that the rasters in MODE 2 menu have been in-correct.

So I looked at JavaCPC's Z80 emulation, especially for the extra CPC-timings.

I changed a byte there from 1 to 0, and the rasters are shown correctly now.

I also made an own raster-image in MODE 1 which uses about 8 Colours.

The result is shown perfectly on a real CPC 6128 and in JavaCPC.

ALL (ALL!!!) other emulators like WinAPE, WinCPC, Caprice, CPCE95, Arnold, PCCPC etc.... cannot show this image properly.

Now my suggestion:
I think, some docs for the Z80 are not 100% exactly.

So for all Emu-coders:
Please check Z80 emulation.


This is the perfect result of my screen. 1-1 like on a real CPC.
Other emus have colour-distortions or disturbing stripes in the screen!

http://cpc-live.com/raster.dsk please check this DSK I made.
RUN"DISC" and you will see the screen.

I hope this helps to make other emulators more accurate.

If Richard reads this:
I changed in 'byte[] CPC_EXTRA_TIME' the last byte from 1 to 0.
Code: [Select]
  protected static final byte[] CPC_TIME_EXTRA = {
      1, 1, 2, 5, 1, 2, 1, 1, 2, 2, 2, 0, 0, 5, 0
  }
jemu.system.cpc.z80.java

Cheers,
Markus
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 391
  • Likes Given: 60
Re: Question about rasters and emu's
« Reply #1 on: 05:16, 09 March 09 »
If Richard reads this:
I changed in 'byte[] CPC_EXTRA_TIME' the last byte from 1 to 0.
Code: [Select]
  protected static final byte[] CPC_TIME_EXTRA = {
      1, 1, 2, 5, 1, 2, 1, 1, 2, 2, 2, 0, 0, 5, 0
  }

The value you changed is the Z80 interrupt acknowledge time which is added to the interrupt time on most instructions. Without this, the interrupt timing is wrong. The DSK image works on WinAPE with CRTC Type 3 (ASIC). What type of real CPC did you test it on?

Offline Devilmarkus

  • Vivid source of indefiniteness
  • 6128 Plus
  • ******
  • Posts: 4.035
  • Country: de
  • WebCPC / JavaCPC developer
    • index.php?action=treasury
    • CPC-Live website
  • Liked: 1014
  • Likes Given: 926
Re: Question about rasters and emu's
« Reply #2 on: 10:14, 09 March 09 »
I tested it on my CPC 6128 (CRTC 1)

BTW.: With this change, also other programs work better now.
For example: the 'Camembert meeting' demo works not perfect, but is visible and playing.

'Star Sabre 128k' also has correct colour rasters now.
« Last Edit: 10:20, 09 March 09 by CPC-Live »
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Offline Devilmarkus

  • Vivid source of indefiniteness
  • 6128 Plus
  • ******
  • Posts: 4.035
  • Country: de
  • WebCPC / JavaCPC developer
    • index.php?action=treasury
    • CPC-Live website
  • Liked: 1014
  • Likes Given: 926
Re: Question about rasters and emu's
« Reply #3 on: 11:12, 09 March 09 »
Here's a screenshot of my CTM-644 with my CPC 6128 running:

Click the picture to enlarge
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 15.568
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 3136
  • Likes Given: 5784
Re: Question about rasters and emu's
« Reply #4 on: 15:01, 09 March 09 »
Rather impressive :)

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 391
  • Likes Given: 60
Re: Question about rasters and emu's
« Reply #5 on: 04:28, 12 March 09 »
Here's a screenshot of my CTM-644 with my CPC 6128 running

Assuming WinAPE still passes all the tests on PlusTest: there is a small problem with the exact timing of interrupts in some rare circumstances. I had a short discussion with someone on CPC Zone about it on a protection code they were writing. I don't actually have any idea how to determine what's causing it at the moment.

Offline Devilmarkus

  • Vivid source of indefiniteness
  • 6128 Plus
  • ******
  • Posts: 4.035
  • Country: de
  • WebCPC / JavaCPC developer
    • index.php?action=treasury
    • CPC-Live website
  • Liked: 1014
  • Likes Given: 926
Re: Question about rasters and emu's
« Reply #6 on: 14:23, 12 March 09 »
WinAPE also seems to have some more problems.

The "Hi-Tech" demo causes WinAPE to crash ?!??!?

When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 391
  • Likes Given: 60
Re: Question about rasters and emu's
« Reply #7 on: 04:21, 13 March 09 »
The "Hi-Tech" demo causes WinAPE to crash ?!??!?

I can't get 2.0a17 to crash with my copy. Can you send my the DSK you're using?

Offline Devilmarkus

  • Vivid source of indefiniteness
  • 6128 Plus
  • ******
  • Posts: 4.035
  • Country: de
  • WebCPC / JavaCPC developer
    • index.php?action=treasury
    • CPC-Live website
  • Liked: 1014
  • Likes Given: 926
Re: Question about rasters and emu's
« Reply #8 on: 11:22, 13 March 09 »

I can't get 2.0a17 to crash with my copy. Can you send my the DSK you're using?

Downloadlink

WinApe.ini:
Code: [Select]
[ROMS]
Cartridge=CPC_PLUS.CPR
Lower=OS6128
Upper(0)=BASIC1-1
Upper(1)=
Upper(2)=
Upper(3)=
Upper(4)=
Upper(5)=
Upper(6)=
Upper(7)=PARADOS
Upper(=
Upper(9)=
Upper(10)=
Upper(11)=
Upper(12)=
Upper(13)=
Upper(14)=
Upper(15)=
Multiface=
Cartridge Enabled=false
Multiface Enabled=false
Disable All=false
Enable L07=false

[Configuration]
Refresh Rate=10
Display Mode=1
Sound Mode=3
Sound Volume=15
Full Screen=false
Direct Video=false
Sound Bits=16
Sound Stereo=true
Sound Frame Delay=0,0
Show ASIC=FALSE
Keyboard File=
CRTC Type=0
Auto Run=false
Disable Update=false
Turbo Mode=false
Joystick Enabled=true
AMX Mouse Enabled=false
Emulation Speed=100
Frame Skip=false
VHOLD Position=0
Full Screen 16=true
Hide Mouse=true
Hide Menus=false
No Right Click=false
Enable IDE=true
Master IDE Type=0
Master IDE Path=
Slave IDE Type=0
Slave IDE Path=
Enable Clock=true
Enable Mouse=true
Adjust Mouse=true
Monitor Type=0
Monitor Brightness=0
Linear Palette=true
Hide Panel=false
On Screen Drive LED=true
Show Track=true
Enable Plus=false
Plus PPI=true
Extended RAM=1
Silicon Disc=false
Position=481,166
Half Size=false
Stretch Size=768,540
Render Both=true
DirectX Stretch=false
PAL Emulation=false
Disc Sound=false
Tape Sound=true
Maximised=false

[Drives]
Drive(0)=
Drive(1)=
Drive(2)=
Drive(3)=
Drive(4)=
Drive(5)=
Drive(6)=
Drive(7)=
Single Sided A=false
Single Sided B=false
Single Sided C=false
Single Sided D=false
Last Drive=1
Fast Disc=true

[Debug Windows]
Debug=false
Dump=FALSE
Stack=FALSE
Disassemble=FALSE
Registers=false
Break Instructions=false
Hide On Run=true
Position=63,755
Size=632,374
BreakPos=100,400
BreakSize=308,95
Breaks=false
RegsPos=235,766
Graphics=false
GraphicsPos=100,300
GraphicsSize=360,200
DataAreaPos=100,300
DataAreaSize=308,97
Data Areas=false
Show ASIC=true
Row Highlight=false
Follow PC=false

[CPCDOS]
Path=G:WinApe


[Snapshot]
Last Opened=
Last SNR=

[Screenshots]
Save On Flyback=true
Filter=1
Half Size=false
Half Height=false
Last Path=
[Pokes]
Position=100,100
Size=420,400
[Tape]
Position=899,490
Size=245,112
Visible=false
File Name=
[Printer]
Type=3
Name=Microsoft XPS Document Writer
File Name=
Tab=Asm1
[Assembler]
Position=407,131
Size=707,547
Visible=true
Library Path=
SymbolPos=500,100
SymbolSize=340,120
Selected=6
[Formats]
PARADOS 80=10,91,5,80,1
PARADOS 41=10,81,5,41,1
PARADOS 40D=10,A1,5,40,2
ROMDOS D1=9,01,5,80,2
ROMDOS D2=9,21,5,80,2
ROMDOS D10=10,11,5,80,2
ROMDOS D20=10,31,5,80,2
ROMDOS D40=10,51,5,80,2
S-DOS (ROMDOS D80)=10,71,5,80,2
DATA (SS 40)=9,C1,5,40,1
DATA (DS 40)=9,C1,5,40,2
DATA (SS 80)=9,C1,5,80,1
DATA (DS 80)=9,C1,5,80,2
SYSTEM (SS 40)=9,41,5,40,1
SYSTEM (DS 40)=9,41,5,40,2
SYSTEM (SS 80)=9,41,5,80,1
SYSTEM (DS 80)=9,41,5,80,2
IBM (SS 40)=8,01,1,40,1
IBM (DS 40)=8,01,1,40,2
IBM (SS 80)=8,01,1,80,1
IBM (DS 80)=8,01,1,80,2
ULTRAFORM=10,10,5,41,1
« Last Edit: 11:27, 13 March 09 by CPC-Live »
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Offline Axelay

  • 6128 Plus
  • ******
  • Posts: 559
  • Country: au
  • Liked: 359
  • Likes Given: 85
Re: Question about rasters and emu's
« Reply #9 on: 10:56, 23 March 09 »
I've been doing some tests on my CPC464 as a result comments about the raster timing on the plus in Star Sabre. Using the following test code I've found on my 464 that it performs the colour change half a character later than it occurs on Winape, WinCPC & Arnold.  It occurs at the beginning of the equals signs in the emulators, and in the middle of the equals signs on my 464.  Assuming the test code isnt doing anything "bad", seems like there is a small timing issue in the emulators?

Code: [Select]
;;write direct "a:testspl.bin"
org &8000
run &8000
nolist
; init text firmware
    call &bb4e
; set mode 1
    ld a,1
    call &bc0e
; set border black
    ld bc,0
    call &bc38
; set loader colours
    ld hl,LoaderCols
    ld a,3
    call SetColours
; set text position
    ld a,1
    call &bb6f
    ld a,1
    call &bb72
; set pen
    ld a,1
    call &bb90
; print text
    ld c,25
.MsgLpO
    ld b,40
    ld a,51
.MsgLpI
    call &bb5a
    inc a
    djnz MsgLpI
    dec c
    jr nz,MsgLpO
di      ;; disable interrupts
im 1     ;; interrupt mode 1 (CPU will jump to &0038 when a interrupt occrs)
ld hl,&c9fb    ;; C9 FB are the bytes for the Z80 opcodes EI:RET
ld (&0038),hl   ;; setup interrupt handler
ei      ;; re-enable interrupts
    ld de,&5554
.main_loop
    call FrameFly
    ld bc,&7F00
    out (c),c
    halt
    defs 3
    out (c),e
    halt
    defs 3
    out (c),d
    halt
    defs 3
    out (c),e
    halt
    defs 3
    out (c),d
    halt
    defs 3
    out (c),e
    halt
    defs 3
    out (c),d
jr main_loop
.FrameFly
ld b,&f5    ;; B = I/O address of PPI port B
.vsync
in a,(c)    ;; read PPI port B input
rra      ;; transfer bit 0 into carry
jr nc,vsync    ;; if carry=0 then vsync= 0 (inactive),      ;; if carry=1 then vsync=1 (active).
ret
.SetColours
; HL points to list, A holds 15 or 3
    ld b,(hl)
    ld c,b
    push af
    push hl
    call &bc32
    pop hl
    pop af
    inc hl
    cp a,0
    ret z
    dec a
    jr SetColours
.LoaderCols
    defb 0,0,26,0
 

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.335
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2264
  • Likes Given: 3478
Re: Question about rasters and emu's
« Reply #10 on: 11:33, 23 March 09 »
I've been doing some tests on my CPC464 as a result comments about the raster timing on the plus in Star Sabre. Using the following test code I've found on my 464 that it performs the colour change half a character later than it occurs on Winape, WinCPC & Arnold.  It occurs at the beginning of the equals signs in the emulators, and in the middle of the equals signs on my 464.  Assuming the test code isnt doing anything "bad", seems like there is a small timing issue in the emulators?

Code: [Select]
;;write direct "a:testspl.bin"
org &8000
run &8000
nolist
; init text firmware
    call &bb4e
; set mode 1
    ld a,1
    call &bc0e
; set border black
    ld bc,0
    call &bc38
; set loader colours
    ld hl,LoaderCols
    ld a,3
    call SetColours
; set text position
    ld a,1
    call &bb6f
    ld a,1
    call &bb72
; set pen
    ld a,1
    call &bb90
; print text
    ld c,25
.MsgLpO
    ld b,40
    ld a,51
.MsgLpI
    call &bb5a
    inc a
    djnz MsgLpI
    dec c
    jr nz,MsgLpO
di      ;; disable interrupts
im 1     ;; interrupt mode 1 (CPU will jump to &0038 when a interrupt occrs)
ld hl,&c9fb    ;; C9 FB are the bytes for the Z80 opcodes EI:RET
ld (&0038),hl   ;; setup interrupt handler
ei      ;; re-enable interrupts
    ld de,&5554
.main_loop
    call FrameFly
    ld bc,&7F00
    out (c),c
    halt
    defs 3
    out (c),e
    halt
    defs 3
    out (c),d
    halt
    defs 3
    out (c),e
    halt
    defs 3
    out (c),d
    halt
    defs 3
    out (c),e
    halt
    defs 3
    out (c),d
jr main_loop
.FrameFly
ld b,&f5    ;; B = I/O address of PPI port B
.vsync
in a,(c)    ;; read PPI port B input
rra      ;; transfer bit 0 into carry
jr nc,vsync    ;; if carry=0 then vsync= 0 (inactive),      ;; if carry=1 then vsync=1 (active).
ret
.SetColours
; HL points to list, A holds 15 or 3
    ld b,(hl)
    ld c,b
    push af
    push hl
    call &bc32
    pop hl
    pop af
    inc hl
    cp a,0
    ret z
    dec a
    jr SetColours
.LoaderCols
    defb 0,0,26,0


I know of these issues and expected them.
They are down to 1: inaccurate OUT instruction emulation 2) CRTC type.
hmmmm...
Can you try this:
OUT &BC00,1:OUT &BD00,65
and tell me if the first char line is different from the rest of the lines?
I think this will be different on type 1.
 
 
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline Axelay

  • 6128 Plus
  • ******
  • Posts: 559
  • Country: au
  • Liked: 359
  • Likes Given: 85
Re: Question about rasters and emu's
« Reply #11 on: 12:50, 23 March 09 »
 
I know of these issues and expected them.
They are down to 1: inaccurate OUT instruction emulation 2) CRTC type.
hmmmm...
Can you try this:
OUT &BC00,1:OUT &BD00,65
and tell me if the first char line is different from the rest of the lines?
I think this will be different on type 1.

Hmmm.  Are you saying the variation would differ between the CRTC types? Do you know by how much?

Trying that, all the lines look the same, just a couple of characters visible on the sides of the screen.

Offline Devilmarkus

  • Vivid source of indefiniteness
  • 6128 Plus
  • ******
  • Posts: 4.035
  • Country: de
  • WebCPC / JavaCPC developer
    • index.php?action=treasury
    • CPC-Live website
  • Liked: 1014
  • Likes Given: 926
Re: Question about rasters and emu's
« Reply #12 on: 12:56, 23 March 09 »
I've been doing some tests on my CPC464 as a result comments about the raster timing on the plus in Star Sabre. Using the following test code I've found on my 464 that it performs the colour change half a character later than it occurs on Winape, WinCPC & Arnold.  It occurs at the beginning of the equals signs in the emulators, and in the middle of the equals signs on my 464.  Assuming the test code isnt doing anything "bad", seems like there is a small timing issue in the emulators?

Is this the correct result?
Like on your 464?
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.335
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2264
  • Likes Given: 3478
Re: Question about rasters and emu's
« Reply #13 on: 13:18, 23 March 09 »
Hmmm.  Are you saying the variation would differ between the CRTC types? Do you know by how much?

Trying that, all the lines look the same, just a couple of characters visible on the sides of the screen.
Yes it is possible the variation would vary depending on crtc type.
One of the diagrams in the datasheet for the CRTC type 1 (UM6845R) seems to indicate that the CRTC is clocked half a char later than the other crtcs.
So, this would produce the effect you see.
On a CRTC type 0, you may get different results. This is something I was going to test on my various cpcs when I had finished a test program.
 
But also, it depends on the accuracy of the emulation.
Why?
Take OUTI for example.
This effectively reads a byte from (HL) and outputs it, then it changes HL and BC.
So the breakdown may be something like this:
 
1 NOP cycle to fetch ED
1 NOP cycle to fetch A1 (Not sure exact opcode for OUTI).
1 NOP cycle to OUT value to hardware
1 NOP cycle to INC HL and dec B
 
it all depends on the order the z80 performs commands like this.
Some emulators update the OUT instruction at the end of the command, some may do it a bit earlier.
So both are important.
 
I was going to finish some tests and run them on the cpc's I have (type 0, type 1, type 2 and type 3).
Then I was going to see the differences and document them here.
 
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 391
  • Likes Given: 60
Re: Question about rasters and emu's
« Reply #14 on: 02:06, 24 March 09 »
They are down to 1: inaccurate OUT instruction emulation 2) CRTC type.

All the emulation in ALL the emulators is inaccurate as far as exact palette changes go. There are a number of contributing factors:
 
1. The Z80 OUT instruction places the data on the data bus and sends the /WR and /IORQ lines low a number of nanoseconds into the instruction, determined by the clock speed (4 MHz, not 1MHz), the exact point in the internal fetch-decode-execute cycle of the Z80 and the delays of the gates themselves.
 
2. The Video Gate Array (or in the case of the Plus, the ASIC) modifies it's own internal palette registers a number of nanoseconds after sensing and decoding the signals on the data bus.
 
3. The signals coming from the CRTC may vary from one CRTC to another, and each of these signals is actually offset from the CPU and VGA signals. One way to see the offset clearly is to do:
 
out &bc00,2:out &bd00,20:out &bc00,1:out &bd00,20:out &bc00,0:out &bd00,31
 
This makes the HSYNC from the CRTC clearly visible in the middle of the screen and you can see the offset of the black HSYNC in pixels by looking at the characters on the right.
 
The only way to get these more accurate is to test exactly where the palette changes occur on each CRTC type and do either a) 16 MHZ accurate emulation (ie. 1 MODE 2 pixel clock) or b) Fudge it and have smart rendering routines which can change the palette part way through the NOP.
 
There are two separate timings for the HSYNC black switch and actual VGA palette changes.
 
On the Plus this is further complicated by different timings again for ASIC palette changes and accurate soft-scroll changes, which also occur part way through a NOP.

Offline Axelay

  • 6128 Plus
  • ******
  • Posts: 559
  • Country: au
  • Liked: 359
  • Likes Given: 85
Re: Question about rasters and emu's
« Reply #15 on: 14:33, 24 March 09 »
Thank you both for the explanations.  It sounds like the chances of emulation getting more accurate are pretty slim then, but some documentation on exactly how much they differ by is in the works, and whenever that happens to become available will be great.

Trying that string of outs, I'm not sure what I'm looking for with respect to the characters on the right?  Do you mean the way the first character of the screen is 'missing', so instead of 'ready' I see 'eady'?

Is this the correct result?
Like on your 464?

No, the image here shows the colour changing on the right side of the equals character, whereas my 464 is changing the colour right in the middle of the equals character.  Or if you like, it's 1 byte width or half a nop earlier than in this image.