I wonder if someone can help me, as my code isn't working how I expect.
I'm trying to do a mode switch every line... now it's my understanding that each line of the screen takes 64 NOPs to draw, and each NOP is 4 ticks = 256 ticks
So this code skips a single line (it works correctly as expected)
;ds 64 ;[256]
BUT here is the code I'm using to do the mode switches... and the code for each line if I'm calculating it right is just 250 ticks... not the expected 256... if I make it 256, the effect is unstable...
Again:
;ds 64 ;[256]
ld bc,&7F00+128+4+8+0 ;[10] - ScreenMode change
out (c),c ;[12]Change screen mode
inc c ;[4]
ds 56 ;[224]
;Total...250 - Why not 256?
;ds 64 ;[256]
out (c),c ;[12]Change screen mode
dec c ;[4]
ds 54 ;[216]
dec iyl ;[8]
jp nz,Again ;[10]
;Total...250
I've got the tick counts from my usual z80 documentation - Is there something wrong in my z80 timing calculations, or is there something else I'm missing?
Any advice would be appreciated
You need to take into account contention - this is most easily done on the CPC by using the "NOP timings" because the CPC stretches parts of instructions so they always take multiples of 4 t-states.
See http://cpctech.cpc-live.com/docs/instrtim.html (http://cpctech.cpc-live.com/docs/instrtim.html) for timing details
The error is the JP timing and the OUT timing. Do not use ticks because CPC is not ZX :)
Thanks, that makes sense... I knew I must be doing something wrong!
Quote from: keith56 on 23:59, 21 May 19
Thanks, that makes sense... I knew I must be doing something wrong!
And BTW, take a look at imperial mahjong about mode changing, there is a funny trick used to manage something like your code
QuoteAnd BTW, take a look at imperial mahjong about mode changing, there is a funny trick used to manage something like your code
... I don't remember it :).
@keith56 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1886) Trying to do some EGX graphics? If yes, SuperSylvestre will be proud!
Quote from: roudoudou on 06:33, 22 May 19
And BTW, take a look at imperial mahjong about mode changing, there is a funny trick used to manage something like your code
I've had a look at the source, I'm not great at disassembling code...
I assume You mean switching to mode 1, and immediately back to 0?... taking advantage of the fact that the mode can only change once per line, and timing things so it happens immediately at the end of a line... effectively doing a pair of switches at the same time?
Quote from: Targhan on 10:30, 22 May 19
Trying to do some EGX graphics? If yes, SuperSylvestre will be proud!
sort of... I'm hoping to cover it in my tutorials as a 'warm up' to some Rupture tricks... I've also added support for EGX screens to my Akusprite Editor.
I'm not planning on using it in any games though at this time
Quote from: keith56 on 11:24, 22 May 19
I assume You mean switching to mode 1, and immediately back to 0?... taking advantage of the fact that the mode can only change once per line, and timing things so it happens immediately at the end of a line... effectively doing a pair of switches at the same time?
Exact!
Quote from: keith56 on 11:24, 22 May 19
sort of... I'm hoping to cover it in my tutorials as a 'warm up' to some Rupture tricks... I've also added support for EGX screens to my Akusprite Editor.
I'm looking forward to those tutorials.
Timings are very important to Rupture tricks. With simple ruptures you can be pretty lose with them. I've been playing around with setting CRTC register 4 to zero and playing around with that. In the emulator I had CRTC type 1 set because setting the address can happen early on that. I had everything working great and I even switched to type 0 and it all seemed to work. Then I reset the emulator I ran the code and everything went tits up - I was still on CRTC type 0. Atfer hours wondering what the heck was happening I discovered that on CRTC type 0 I was setting register 4 with a value too late. I made it 1 scanline earlier and it all started to work on CRTC type 0.
Is the winape emulator accurrate with the CRTC types? I'm wondering why when it was working for type 1 and I switched to type 0 it still worked. Then it failed after a reset of the emulator running type 0 - this is really puzzling me? Or do I just take it with a pinch of salt because it's an emulator?
Because I only have one real machine it's pretty hard to get this stuff right for all CRTC types and for that I need to rely on the emulator.
Quote from: AHack on 18:26, 22 May 19
Is the winape emulator accurrate with the CRTC types?
Not at all ;D
Quote from: AHack on 18:26, 22 May 19
I had everything working great and I even switched to type 0 and it all seemed to work. Then I reset the emulator I ran the code and everything went tits up - I was still on CRTC type 0. Atfer hours wondering what the heck was happening I discovered that on CRTC type 0 I was setting register 4 with a value too late. I made it 1 scanline earlier and it all started to work on CRTC type 0.
Yes, I've had the same problem, I've tested the code I'll be covering on all CRTC types after a reset on the WinApe emulator, but I've not tested on 'real hardware' - I don't even have a CRT any more
I'll be putting a disclaimer on the tutorials warning people that I cannot be sure the code will work in production... I believe there's also the risk that crazy CRTC settings can physically damage a monitor... does anyone have any info on that? - I was wondering, can too short Hsyncs , or crazy Hsync positions cause damage?
There is a legend about a tiny screen burning the middle of the monitor (i don't believe it)Some Chany's demos use 65 NOPS lines or more which made the monitor doing some noise (some people are scared of this)