Previous | Next
| From: Crown (all posts)
Date: 1998-05-12
Subject: Re: TED timing, Interlace
|
Hi guys,
Levente:
>I mean, if you set a raster routine which generates a 'zebra' grid
>in the background color (every second line is black), you will see
>different color on the screen if the 'colorized' lines are even or odd.
Are you sure of this? Is it not possible that your TV has a bit too big mask sizes? (Try to enlarge the screen with the controls, and if it still does what you are saying then I didn't said a word :) )
>regarding the corrupted mail, and I also replied but this one seemed
>like not to reach your mailbox. Neither I have the message text yet,
Nope, haven't got that.
>World and also asked if you have a webpage or your programs are available
>somewhere on the Net. ...I liked your Iron Maiden demo :-), I guess once I guess you can find them at ftp://c64.rules.org/pub/plus4
or I can mail them to you.
>Some years ago I also made such a TED timing diag, all with the usual
>stuff of single and twiee clock, the proc's and the TED's cycles,
>memory refresh, transparent DMA, all how it's related to $ff1e and
>so on. Well, though, it wasn't really considered worthy by anybody. I wrote Actually this list was born, for sharing these infos with the emulator writers, so they could make better ones. :) If you have these docs and you can share with us that would be welcomed on this list!
>a bit smaller TED doc which was published in the Commodore Hacking mag Yes I've read that.
>BTW, regarding the $ff1e thing, I thought you wrote cycle exact timing
>much earlier. I saw one of your demos (hmmm, maybe even from '90)
>containing a splitted raster scroll which I guess just needed this
>exact timing.
You must be talking about Digital Dream. Well yes that used exact timing,
but that was running in slow mode with screen off, and that simplifies a lot. (I didn't knew much about the DMA mechanism at that time.)
And the startup was a simple waiting loop for a certain $ff1e $ff1d combination, and it doesn't mattered if it starts up 1 or 2 frame later.
It was so constructed that one loop took 1 cycle less than the whole screen takes, so this moved the output to the left, and every 4th loop it made a real scroll, and run this time 3 cycles more than a screen takes. For compensating the variyng cycle usage of the music player,
the timer was set up before the music player was called, and after finishing the music player the timer value was polled,
until it reached below a predefined value, then the value of the timer was used as index to jump into a sequence of nops.
>Yes, mentioning that not all of these phases can be detected because
>the proc can't always read the regs (ie. in single clock mode, or in
>refresh cycles the proc can't reach the bus in the first half clock
>phase).
I thought this is obvious :)
>seems to match my measurements. The only difference that I numbered the
>cycles from 0 to 56 and splitted them to two phases (but the result is Yes this describes better what is happening.
>the same). Also, maybe it was misspelled but there are 109 cycles on a
>border, 'fast mode' (= twiee clock enabled) line instead of 114 'cos Yes it is misspelled, I think Lion forgot to correct that one as I pointed this out to him before. :)
>Also, the cycles assigned ' - ' ( Empty ) contain TED reads from the
>address $FFFF (you can experiment with it by removing the vertical border
>by the C-64 like $ff06= 03, 0b trick and checking the resulting pattern on
>the screen). Well, it doesn't seem to be much serious anyway.
This fact is stated in that posting!
I did some experiments with the trick you mention here before, and indeed there are some use for this. I'm sure you know about the unconnected space feature. If the CPU or the TED reads from an unconnected address space
(for example from a non existent cartdrige, or the area at $fe00-$feff if there is no 1551 on a C16) then the read data will be the same which was read or written on the previous cycle.
The address $ffff can be turned into a non-connected address if one pages the Kernal out and pages a non-existent cartridge in. If you do this in slow mode, with the C64 method of opening the upper and lower border, then you will see the data read or written by the CPU.
This can be used to obtain information on each cycle of the CPU instuction set. You set $ffff to $0 in RAM, turn on RAM, and bank in the cartridge.
Now the opened upper and lower border is totally empty. You write an exact positioning code which finishes somewhere in the middle of one of the border lines, now turn on ROM (STA $FF3E it's good if the A is zero,
as its value will be displayed on the next cycle), then comes the instruction you wanna inspect, then turn on RAM (STA $FF3F).
The instruction STA$FF3F will have a fixed look, and before that you will see the bitmap representation of the bus content for each cycle.
All other cycle will display zero.
>From this, with some tweaking (setting registers to different value,
instruction parameters etc...) the acessed address could be found out.
I do know that this was already measured by the C64 guys, but this is a very cheap method to do that again, without the use of a scope.
>It would be sensible to measure which memory cells are addressed during
>memory refresh cycles (...maybe, Marko did some experiments on this
>recently, at least on the VIC-II).
I haven't checked this yet, but I think it's similar to the C64 way.
This can be checked also with the unconnected address space feature.
Interlace:
>No, the point is: to present a regular interlaced v-retrace signal. I've
>read some docs about this. Other words, you can remember: a real laced Yes, but what are the diffs between the two retrace signals? They must be different. If it is only in the length than this can be reproduced,
but for this we should know how much time it takes longer or shorter.
The original Commodore docs (at least it looks to be original) says the following:
Vertical Sync Start at line 254
Vertical Sync Stop at line 257
Vertical Blank Start at line 251
Vertical Blank Stop at line 269
Vertical Equalize Start at line 251
Vertical Equalize Stop at line 260
These are for PAL.
The NTSC values are:
Vertical Sync Start : 229
Vertical Sync Stop : 232
Vertical Blank Start : 226
Vertical Blank Stop : 244
Vertical Equalize Start : 226
Vertical Equalize Stop : 235
Do someone knows what is this Equalize thing?
I've checked some of these values, and it looks that they are not correct. The Vertical Blank start at 251 that is ok,
But it finishes in a little after the middle of line 275.
I have some partial informations from CCIR 470-1 and CCIR601.
It is about the blanking intervals. The V-blank time on PAL should be 25 times of the Horizontal line Period which is 64 usec
+ 1 times the Horizontal blanking time which is 12 +/- 0.3 usec.
If we compare this to the blanking interval of the Plus4 we can see that it is less at least with the time of a half line.
Maybe this + 1 Horizontal blank time is only for one half frame?
>But I guess, this effect can be made 100% correct only, if at all, using
>a scope and measuring the resulting V-retrace signal instead of playing
>with an appropriate TV (...else evil knows if the resulting laced signal
>will work well on another displays). You can also try it if you have a scope.
Sure but if you know the exact required time value for both types of retrace sygnals, then it can be tried blindly also :)
Do you know these time values?
Also, there are some tolerances, and if it is in then it's ok.
>(You (or anybody) can have them and some gfx if you'd like to. Just
>write; I can mail them, or put some of them up to the falcon.pmmf.hu
>ftp.)
Sure send it I'd like to experiment ... :)
Tibor Biczo / Crown of GOTU
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
