IO, a new MSX1 demo by Logon System

Page 8/17
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13

By Overflow

Resident (57)

Overflow's picture

18-03-2015, 13:40

Dedicated to izy: (youtube) IO live at the party.

Some of you guys might be interested by some simple tests I did back in December: COM and sources.
Assuming: 50Hz, [email protected] freq (including: z80 mode on turbo r, lower freq on Panasonic msx2+).
Don't mind displayed texts by the .COM: they are obsolete (I've learned since December).

---

TSTLIN0.COM

On MSX2 w/ 1 clock only: red column, vertical, does not move. Which means: exactly 228 cycles on a scanline.

On MSX turbo R: mess! cos' outing to vdp requires 1 additonnal cpu-cycle. So one loop takes more time. Exactly 4 cycles more, since there are 4 outs in one loop.

On MSX1 w/ 2 clocls: column is no straight vertical, light slope. It means: not exactly 228 cycles on a scanline. There's a difference which likely depends on the 2 quartz used as clocks.

---

TSTLIN2.COM
Run it on turbo R (or MSX2+ from Pana.): the loop from TSTLIN0.COM has been modified, it now has 4 cycles less, in order to counter the 4 cycles added by slowing down the outs to vdp.
Run it on openMSX: red column, vertical, does not move. Which means: exactly 228 cycles on a scanline. Logical: openMSX has one clock only for cpu & vdp.
Run it on real turbo R: column is not straight vertical, light slope. It means: not exactly 228 cycles on a scanline. There's a difference which likely depends on the 2 quartz used as clocks.

---

TSTFRM.COM

On MSX2 w/ 1 clock only: red line in the border does not move. Which means: exactly 71364 cycles on 1 frame.

On MSX1 w/ 2 clocks, I mean those I tested: the red line slowly move right or left. Which means: not 71364 cycles on 1 frame, but maybe a bit less or a bit more (I got up to -3 cycles). Not an integer by the way, since clocks/quartz are not synchronized.

On MSX1 w/ 2 clocks, I mean those from izy? well, my guess: the red line will move quickly up or down? Which would mean: not 71364 cycles on a frame but maybe (as an example) 71200. It would implie: clocks/quartz from cpu & vdp are VERY desynchronized. Would also mean (in my example) that a scanline is 71200/313=227.47 cycles long. Again: not an integer.

@izy: you want to know how many cycles to adjust on your machine ? you would have to modify TSTFRM.Z80 to remove/add some cycle from the 71364-cycles long loop, until getting a stable red-line. That's what I did for NMS8280 I had for tests. I'm afraid I don't have anymore the numbers for that test.

By ro

Guardian (4085)

ro's picture

18-03-2015, 14:25

As my fellow-coder Savage used to say: "If it looks good on MSX, it is a trick". And damned what good tricks you got up yer sleeve, Overflow!

"Impressed" might not even be the word I'm looking for, hell there are just no words Smile Congratulations, you just made my day. have fun coding tricks!

By Overflow

Resident (57)

Overflow's picture

18-03-2015, 15:40

Wow! thanks to all of you guys for your nice words. I appreciate.

Now maybe you guys should consider to thumb up and ask for more there and there and there. Let it be clear: I don't care about numbers, I do care about nice comments as you guys write down here. That said, do you guys want to promote MSX as a demo-plateform? then you guys could/should show your interest at the right place. Comments at the right place could motivate some other 8-bitters or z80-ers to code demo on MSX. Again: I do not need this, just see: I did it (i.e. IO) without this kind of of motivation. But: MSX (demo-)scene might need this.

Then? well, may some of you guys start to code demo-fx like I did?

By mau_rizio

Resident (48)

mau_rizio's picture

18-03-2015, 17:23

Wich assembler do you use?

PS: wonderfull demo Smile

By Overflow

Resident (57)

Overflow's picture

18-03-2015, 17:35

mau_rizio wrote:

Wich assembler do you use?

SJasm+

By yzi

Champion (441)

yzi's picture

19-03-2015, 20:44

I tried but I can't get a completely stable red line on the Toshiba HX-10. The closest I can get is this:
tstfrm l=18, a=92, 1 x nop, 3 x ret nz

At the end of the frame loop, there were 3 x ret nz in the original. I tried with 4 x ret nz, but it was too much. Then I changed two of them to NOPs, but that was too little. The video clip above is the best combination, and even it isn't completely stable.

I converted the program to SDCC / as-z80 format. Here it is
http://www.kameli.net/~yzi/tstfrm_sdcc.zip
I checked that my as-z80 version produces the same COM file as the original. Or at least it has the same md5 hash.

By yzi

Champion (441)

yzi's picture

19-03-2015, 21:59

Here's the closest combination I could get with my Canon V-20 tstfrm l=18, a=92, 4 x nop (Canon V-20)

Maybe I'm counting the cycles wrong. Nop is 1 cycle less than ret nz, right?
http://map.grauw.nl/resources/z80instr.php

My V-20's serial number is 707954, if someone can figure out something from that. Build a table of cycle amounts for every individual machine!? First you'd have to type in your MSX1 machine's model and serial number...

By Overflow

Resident (57)

Overflow's picture

19-03-2015, 22:47

Thanks yzi.
Unless there's one clock, you can't get a stable line.
This would mean that 2 quartz can be perfectly synchronized.
Don't mind the precise cycles thru NOP or RETZ, both your machines get roughly same result.
I am wondering if any other machine else than yours has same timing.

So instead of LD A,71: DEC A: JP NZ,$-1 you get LD A,92: DEC A: JP NZ,$-1
Which is 21 loops more. One loop is 5 (DEC r) + 11 (JP c) = 16 cycles.
So your frame is 21*16=336 cycles more than mine (336 to add to theorical(?) 71364 cycles) .

This might be good news:
336 cycles on a frame, divided by 313 scanlines, gives almost 1 cycle more on each scanline.
From line #1 to line #192, timing will change by 14 cycles = 192 * (336/313 -1)
14 cycles is not a big deal to cope with. I mean: I will try a patch to
- test your timing (around 71364+336 cycles expected on a frame)
- rise all single-scanline-loops from 228 cycles to 229 cycles
(on unlimited-sprites scene, on fake-3D scene, on plasma scene)
- change expected cycles-by-frame on last splitrasters scene (adding 336 cycles)

I believe we should go on thru private messages or mails
(maybe I should have decided this before that message btw).
This might requires quite a few remote tests by you.
I'll work on this starting from Sunday.

By yzi

Champion (441)

yzi's picture

19-03-2015, 23:07

Great. I hope the demo can be patched to work across a wide variety of MSX1 machines.
If someone else wants to try this out on their real MSX1 machines, here's a .dsk file with a set of COM files with various combinations
http://www.kameli.net/~yzi/tstfrm_com_set_dsk.zip

The longer file names are more fine-grained. The COM file names are of the form "tfXXYYZZ.com", where XX=l register initial value, YY=a register initial value, and ZZ=per-frame cycles to add on top of those, if they're different from the original, which should be tf1871.com. The original would be ZZ=18, but I only started adjusting the final per-frame instructions after I had found the coarse values.

By hit9918

Prophet (2853)

hit9918's picture

21-03-2015, 15:38

@grauw, about AY counting the pulse wave.

+     +z---------+     +--z-------+     +----Z-----+
|     |          |     |          |     |          |
+z----+          +--z--+          +----z+          +

at the "+", the AY flips the bit. and sets its counter register to 0.
at "z", z80 writes frequency register. which is the counter comparison register.

The flip happens upon the AY counter register = precise.
The z80 poke can be late up to an arm length late. I.e. it can jitter.

What if the z80 in jitter pokes too early. Then in a glitch the arm diagram is pushed to the left.
At least when poking the smaller value. The counter gets bigger than comparator and immedeately gets set to 0. The diagram gets pushed to "minus maximum" of z80 jitter.
Done that the z80 can jitter around in the arm while the wave keeps precise.
What do you think Smile

Page 8/17
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13