News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_freemac

Raster offset of one char in overscan

Started by freemac, 13:11, 07 January 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

freemac

Hi


I'm currently working around CRTC/GateArray.


In certain demos, I've got a strange offset of exactly one char up for colors. Specialy in large resolution screens.


What is this original defect ? How can I detect it ?




arnoldemu

Quote from: freemac on 13:11, 07 January 16
Hi


I'm currently working around CRTC/GateArray.


In certain demos, I've got a strange offset of exactly one char up for colors. Specialy in large resolution screens.


What is this original defect ? How can I detect it ?
Please attach a screenshot (or two if you are comparing difference in large screens and normal screens). This will help us to understand the problem you describe.



My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

freemac

#2


Hop
*green is added manually using gimp 
First demo has a strange offset of one char up, so Raster lines (background of scroll text) is not vertically centered with scroll text BIG CHARACTERS.
Second demo (Little one), normaly the orange background shall be aligned with purple motif.
Third one, Prince of Percia (no overscan) is running fine, this game is well know as using Raster lines for change mode, in order to display a complete sentence at bottom of game.
Fourth one, Buggy boy (no overscan) is running fine : this game does use same pen for sky (blue) and and grass (green)
Last one, Trail Blazer, is using overscan, and then has a big bug : ball does leave ground too quiclky (one char up before it shall do)


arnoldemu

Quote from: freemac on 16:57, 11 January 16
Hop[attachimg=6][attachimg=7][attachimg=8][attachimg=9][attachimg=10]
I am not sure what is the problem in the images.

is it the green rectangle you talk about or is that debugging in your "emulator"?

Is it the crtc cursor the green blob? it is not used on cpc...

if it is colours, I see some bugs, how do you emulate vsync and hsync to monitor?

hsync and vsync to monitor are not the same as hsync/vsync from crtc.

hsync to monitor has a delay of 2 chars, then max 4 chars (cut if the hsync from crtc is shorter).
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

freemac


Quote from: arnoldemu on 20:11, 11 January 16
then max 4 chars (cut if the hsync from crtc is shorter).
What ?


Actually I just do a fix offset on end of VSYNC signal, and another fix offset on end of HSYNC signal...

arnoldemu

gate-array processes vsync and hsync before sent to monitor.

The vsync sent to the monitor is different to the vsync programmed into the crtc.
The hsync sent to the monitor is different to the hsync programmed into the crtc.

hsync:
1. hsync to monitor starts 2 us after the hsync from crtc.
2. hsync to monitor is max 4us
3. if hsync programmed into crtc is less than 6, hsync to monitor is shorter. (e.g. if you write 4 into hsync length in crtc, hsync to monitor is 2us long).

vsync (gerald confirmed this to me):
1. vsync to monitor is 2 HSYNC after the start of vsync from crtc. (2 scanlines delay)
2. vsync to monitor is max 4 lines
3. vsync to monitor is cut if crtc vsync length is less than 6.

The hsync and vsync to monitor will control the horizontal and vertical position in the monitor.

The hsync length and position defines when raster int is triggered.

I have some tests that show these things. When I release arnold I will release my tests.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

freemac



--vsync (gerald confirmed this to me):
--1. vsync to monitor is 2 HSYNC after the start of vsync from crtc. (2 scanlines delay)
--   => interrupt wait et wait_wait.
--2. vsync to monitor is max 4 lines
--3. vsync to monitor is cut if crtc vsync length is less than 6.
--   => vSyncCount = 25; 24|0 donc 4*6
--
--   So VSYNC (@raster-line) :
--   * CRTC 1000000 1100000 1110000 1111000 1111100 1111110 1111111
--   * TV   0000000 0000000 0010000 0011000 0011100 0011110 0011110



--hsync:
--1. hsync to monitor starts 2 us after the hsync from crtc.
--2. hsync to monitor is max 4us
--3. if hsync programmed into crtc is less than 6, hsync to monitor is shorter. (e.g. if you write 4 into hsync length in crtc, hsync to monitor is 2us long).
--   So HSYNC (@1MHz)
--   * CRTC 1000000 1100000 1110000 1111000 1111100 1111110 1111111
--   * TV   0000000 0000000 0010000 0011000 0011100 0011110 0011110


I implemented it, but as you said, no border effect in color raster.

[attachimg=1]
My version using larger screen.

[attachimg=2]
JEmu (JavaCPC) version I shall reach...


I found one bug in my code : I use offset to place my screen, and they are too small, then they are "negative" while overscan. If I grow my offset in order to get a screen displayed I have a black screen : in fact my HSYNC(/same with VSYNC) begin does reset this offset counter, never reaching then the display area.
And worse, I implemented a small screen display using its own offset added. Making then 3 offset counter to cascade :
- CRTC offset
- GateArray small offset
- VRAM offset (640x480 pixels centered Vidéo RAM)


I'll try to implement offset counter and cascade, and come back here  :-X

freemac

Solved in r005.5
r005.5 - Yamaha SOUND_CLK now mapped from GateArray...

Z80 instruction are slow down to do 4T in order to synchronize with pixels at screen (RAM access/VRAM access)
Yamaha is synchronized with instruction... in a certain way, that "-circles" demo (accessible via CPCRulez) does not... freeze...  in JUST ONE of this 4T * 2 combination (* 2 is about trying a 0.5 offset of clock)

TrailBlazer is corrected in r005.5
Sim City is starting always OK in r005.5
-littleOne demo is OK in r005.5
(and more...)

freemac

#8
Miraculously solved in r005.5

...

I don't know why this version does run fine... but as it is electronics, adding a line of code does destroy everything... except if I succeed in refactoring my code (normal in electronic languages : compiling is a heuristic (space vs temperature vs wire map length))

I have two candidates versions of refactored code (so stable-compiling code) that seems interesting to compare, r005.5.1c6 is running fine with SimCity (key in menu ok) but badly with TrailBlazer (raster 1 char offset) and r005.5.1c7 is running fine with TrailBlazer (raster fine) but not with SimCity (no key in menu)

I'm working with Yamaha, this chip does use 2 entries BDIR and BC1 to fire an action between : selecting an reg address, selecting write mode, selecting read mode.
The problem is that the datasheet is not enough explicit in the way CPC coders does use/feed them  ;)

My Yamaha-1MHz is synchronized via gate-array with Z80-4MHz (gatearray does insert WAIT_n to mod 4 time of each instruction, synchronizing this way with read/write of memory for video), I did this synchronization in an experimental way : 8 possibilities, only 1 run fine.
But it is not really normal that I need to synchronize my Yamaha here in order to "have nice graphic", and "have nice joystick". So I have inserted a "mock" variable to turn off all the part of Yamaha except "read/write reg" and "read keyboard/joystick port".

Now the two experimental results :
In r005.5.1c6 :
if falling_edge(clk) then
compute busctrl_we, busctrl_re,busctrl_addr
if busctrl_we='1' then
  -- do write reg from portA
if busctrl_re='1' then
  -- do read reg to portA (+joystick)
if busctrl_addr='1' then
  -- do memorize current addr from portA
if rising_edge(clk) then
-- music

In r005.5.1c7 :
busctrl_addr<= --directly computed from wires (directly == no clock)
addr<=I_DA when falling_edge(busctrl_addr); -- do memorize current addr directly in a falling_edge of previous built wire
if falling_edge(clk) then
compute busctrl_we, busctrl_re
  if busctrl_we='1' then
   -- do write reg from portA
  if busctrl_re='1' then
   -- do read reg to portA (+joystick)
if rising_edge(clk) then
  -- music

I did some others experiments adding another clock to Yamaha component (CLK_CPU) -as the heuristic compiler loves clocks and dislikes states cascades- (see "vhdl good practices") but without success (only SimCity does run this way)

I read also the datasheet pulse length, and they are really border line (7.2 periods at 4MHz for writing, 1.4 for reading...) and shifted (specially read and address operations)

So now the question  :D

When you feed an Yamaha, when read/write/address are really taken into account ? (MAXAM source code are welcome !)

arnoldemu

#9
Did you see my post?

amstrad cpc "acid" test

in cpctests directory there are 3 dsks. On the discs are many tests for plus and cpc and for some devices.

Try these for cpc. They are tested on real CPC.

Run ppi.bin
run psg.bin
run cpctest.bin

And run tests in z80tests folder.

See the readme.txt for more information.

Tests will tell you success or failure with expected values.

In PPI test I test a lot of 8255 functionality.

In PSG test, this is a lot of tests about register functionality, register access and values read and written.

If you want an audio test try psgexer.asm.

This does volumes, envelopes, tones (checking A,B,C channels) and noise.

You need to download this file:

Unofficial Amstrad WWW Resource
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

freemac

Hi,

All tests are failing except cpctest  :-[

Here the results : CoreAmstrad r005.5 – arnoldemu testbench | MameVHDL

[attachimg=1]

I'll try to validate PPI first, it shall be easy.

arnoldemu

Quote from: freemac on 14:24, 14 August 16
Hi,

All tests are failing except cpctest  :-[
Don't worry. I know you will fix it :)

Quote from: freemac on 14:24, 14 August 16
I'll try to validate PPI first, it shall be easy.
Yes that is a good idea.

If there is something you are making and these tests do not test it, please tell me and I will try and think if there is a way to make a test for that.

I have tried to test as much as I can think.

Some of these tests rely on "high impedance" state and some rely on which has more power to drive the bus (ppi or ay).

I can't test mode 1 and mode 2 of the PPI properly because CPC can't drive the strobe inputs in these modes so I don't know exactly what cpc does here but I tested what I can.

I need to merge the CRTC tests together and tidy up the code. So for the moment ignore these.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Arnaud

Quote from: freemac on 14:24, 14 August 16
Hi,
All tests are failing except cpctest  :-[

It's great that means when the tests will be ok the emulation will be automaticaly greatly improved.  ;)

arnoldemu

BTW, I just realised that Mode 1 and Mode 2 8255 tests assume a CPC6128, "Amstrad" startup name, no cassette connected and no printer connected.

I will update them and try and do more testing with other computer names WITH and WITHOUT cassette and printer.

NOTE: "mode 0: port b read" test sometimes fails because of vsync. I will modify the test to make it more reliable. :)


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

GOB

I'm glad to see that we always look at my old ODE demo :)

freemac

[attachimg=1]
bit set/reset algorithm ok.

The mode 1, using table "Port C Status Read" is still in progress (I'm using bad default values, I'll retry with more 0)

[attachimg=2]
PSG seems happy (I put btw "high impedance" in ports in READ mode, as explain at top of 8255 PPI)

freemac

#16
Here the final results for my light PPI component...
mode 2: port A mode 2, port B mode 0, port C bits output-SUCCEEDED
mode 2: port A mode 2, port B mode 0, port C bits input-SUCCEEDED
mode 1: port A mode 1 (input), port B mode 0, port C bits output-SUCCEEDED
mode 1: port A mode 1 (output), port B mode 0, port C bits output-SUCCEEDED
mode 1: port A mode 1 (input), port B mode 0, port C bits input-SUCCEEDED
mode 1: port A mode 1 (output), port B mode 0, port C bits input-FAILED
got 07 expected 27 - FAIL
got 00 expected 20 - FAIL
got 10 expected 20 - FAIL
got 30 expected 20 - FAIL
mode 0: bit set-SUCCEEDED
mode 0: bit clear-SUCCEEDED
mode 0: psg control with bit set/reset-SUCCEEDED
mode 0: port a output latch r/w-SUCCEEDED
mode 0: port b output latch r/w-SUCCEEDED
mode 0: port c output latch r/w-SUCCEEDED
mode 0: port a control write reset test-SUCCEEDED
mode 0: port b control write reset test-SUCCEEDED
mode 0: port c control write reset test-SUCCEEDED
mode 0: port a read-SUCCEEDED
mode 0: port c read-SUCCEEDED
mode 0: port a read-SUCCEEDED
mode 0: port b read-SUCCEEDED
mode 0: port c read-SUCCEEDED
mode 0: port c mixed input/output-SUCCEEDED
mode 0: ppi port a output-SUCCEEDED
ppi control read-SUCCEEDED
ppi port reset from control-SUCCEEDED

I'll start now with the interrupt signal calibration, I think I know why it is influenced by clock of Yamaha feed by Gatearray : in VHDL, data signal loves having a clock along it. Perhaps wiring them together shall result in a better determinist compilation.
[attachimg=1]

[attachimg=2]
It's progressing good... refactoring GateArray, it's cleaner. wip...

freemac

#17
Solved using arnoldemu testbench cpctest.bin (and others)

[attachimg=1]

Thanks a lot arnoldemu  8)

I succeeded in refactoring r005.5 (I'll call this refactor r005.5.1), so I can continue my project - I can now add lines of code without breaking everything.

Now TrailBlazer and SimCity are both running fine !

Result of refactor (for this one) :

       
  • Yamaha does write data or address under clock. Read is anarchic (during state '1' of read signal)
  • Yamaha clock is synchronized with GateArray (my GateArray is 4MHz, my Yamaha 1MHz, my PPI 4MHz, my Z80 4MHz)
  • M1 offset (synchronize of Z80 by GateArray using WAIT_n for modulo 4 size instruction) is now a parameter of GateArray (2/2 int HSYNC width OK)
  • GateArray reaction is improved (int HSYNC pos OK)
  • signal coming from GateArray are fire under the same clock (interrupt and crtc_VSYNC for PPI) - same clock == same delta time in vhdl. (1/2 int HSYNC width OK)

arnoldemu

Fantastic news! :)

BTW, You can test hblank and vblank (remember gerald described how it worked?). The hblank and vblank tests show this.

hblank test:

- black for hsync duration
- 2us delay before hsync sent to monitor
- 4us cut-off for hsync if >=6us.

This programs hsync width 4-16. blanking appears in centre of screen, hsync to monitor shows in middle. blanking appears brighter than hsync when monitor brightness increased.

vblank test:
- black for 26 lines (26 hsync)
- 2 line delay before vsync sent to monitor
- vsync cut at 4lines if >6 lines.

Please also try:
- colours (shows all 32 possible colour values, 27 with repeats)
- cpcborder (sets cpcborder with bit5=1 and bit5=0).
- cpcpen (sets cpc pen with bit5=1 and bit5=0)

These will help you to confirm these parts too.

I found hblank and vblank are important. On KC Compact it is not correct and on a cpc monitor the screen is distorted for some values. On CPC it works correct and the screen is more stable. :)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: freemac on 09:33, 19 January 16

--vsync (gerald confirmed this to me):
--1. vsync to monitor is 2 HSYNC after the start of vsync from crtc. (2 scanlines delay)
--   => interrupt wait et wait_wait.
--2. vsync to monitor is max 4 lines
--3. vsync to monitor is cut if crtc vsync length is less than 6.
--   => vSyncCount = 25; 24|0 donc 4*6
--
--   So VSYNC (@raster-line) :
--   * CRTC 1000000 1100000 1110000 1111000 1111100 1111110 1111111
--   * TV   0000000 0000000 0010000 0011000 0011100 0011110 0011110



--hsync:
--1. hsync to monitor starts 2 us after the hsync from crtc.
--2. hsync to monitor is max 4us
--3. if hsync programmed into crtc is less than 6, hsync to monitor is shorter. (e.g. if you write 4 into hsync length in crtc, hsync to monitor is 2us long).
--   So HSYNC (@1MHz)
--   * CRTC 1000000 1100000 1110000 1111000 1111100 1111110 1111111
--   * TV   0000000 0000000 0010000 0011000 0011100 0011110 0011110


I implemented it, but as you said, no border effect in color raster.

hblank and vblank tests test this. :)

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Executioner

Quote from: freemac on 18:36, 18 August 16

       
  • M1 offset (synchronize of Z80 by GateArray using WAIT_n for modulo 4 size instruction) is now a parameter of GateArray (2/2 int HSYNC width OK)

You may wish to run the Plustest Z80 timing tests (and interrupt wait-state tests), and have a look at the JEMU CPC implementation (on which JavaCPC was originally based but has been somewhat modified). The /WAIT signal is held low for 3 of every 4 cycles for accurate timing in JEMU.

Executioner

PM me if you'd like the latest version of Plustest (which has many tests for standard CPC also), the instruction timing stuff is in the version on winape.net. JEMU source is available at jemu.sourceforge.net.

freemac

#22

=arnoldemu==========================================
gate-array processes vsync and hsync before sent to monitor.


The vsync sent to the monitor is different to the vsync programmed into the crtc.
The hsync sent to the monitor is different to the hsync programmed into the crtc.


hsync:
1. hsync to monitor starts 2 us after the hsync from crtc.
2. hsync to monitor is max 4us
3. if hsync programmed into crtc is less than 6, hsync to monitor is shorter. (e.g. if you write 4 into hsync length in crtc, hsync to monitor is 2us long).


vsync (gerald confirmed this to me):
1. vsync to monitor is 2 HSYNC after the start of vsync from crtc. (2 scanlines delay)
2. vsync to monitor is max 4 lines
3. vsync to monitor is cut if crtc vsync length is less than 6.


The hsync and vsync to monitor will control the horizontal and vertical position in the monitor.


The hsync length and position defines when raster int is triggered.


I have some tests that show these things. When I release arnold I will release my tests.
===========================================
From DrOG (atari forum), TV 15kHz mode original Amstrad output : "Perfect and well-centered!"[attach=2]

amstrad_170328_r005.8.15c16e.rbf (FDC candidate 16, e experimental "Another TV mode experimental : applying Gerald HSYNC/VSYNC width formula.")

Powered by SMFPacks Menu Editor Mod