Video Timing

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
jms2
Posts: 2001
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: Video Timing

Post by jms2 » Sat May 19, 2018 7:22 pm

The Sony TV also has another problem with BBC machines, which is unrelated to Frogger. It sometimes can't do the sub-pixel antialiasing in Mode 7, displaying a sort of checkerboard effect instead. This tends to go away if you blank the screen (eg by changing mode).

VectorEyes
Posts: 113
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Re: Video Timing

Post by VectorEyes » Sat May 19, 2018 9:34 pm

jms2 wrote:The Sony TV also has another problem with BBC machines, which is unrelated to Frogger. It sometimes can't do the sub-pixel antialiasing in Mode 7, displaying a sort of checkerboard effect instead. This tends to go away if you blank the screen (eg by changing mode).
Some TVs have all sorts of signal-processing designed to improve the signals coming out of Set Top Boxes, DVD players etc. My old Philips TV has a mode where it'll detect and correct for MPEG compression artefacts. Is there any chance the TV in question is detecting something in the Mode 7 signal that it thinks is something it should correct for? (Unlikely I know, but just thought I'd mention it.)

User avatar
kieranhj
Posts: 701
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Video Timing

Post by kieranhj » Mon Jun 04, 2018 5:19 pm

Rich Talbot-Watkins wrote:
Mon May 14, 2018 8:33 pm
I feel like this can also be explained by the same issue as tricky's problem, here.

Have I understood right that you have a bunch of single line, single row CRTC frames (R4=0, R9=0), and then a block of rows to make the PAL frame up to 312? In the other thread, we have the observation that R4 needs to be changed before the final scanline; but if each CRTC frame *is* only one scanline, that doesn't give you any place to do it. So you'll get an extra row of R4=0 with the new R12/R13 (at the bottom), and then you'll get the big block of R4 as intended.

Or maybe your issue was just about setting R6 to 0 too late in order to start the bottom border (remembering that it needs to be set to 0 before the new frame starts in order to show nothing). If it were set too late, that'd show exactly one extra single line row, and then correctly disable display for the remaining rows of the PAL frame.

Does that kinda make some sense?
Just to pick this thread up again. There's definitely divergence that happens with my R4=0,R9=0 CRTC setup in emulation vs hardware. I was chasing a bug with one of the effects that only occurs on real HW - eventually I realised the symptoms were the same as the timer slipping by a scanline (I could "repro" under emulation by artificially adding a 128 cycle delay in the draw fn.)

When I deinit an effect I put back the CRTC to standard MODE 2 configuration (8 scanlines/row, 32 visible rows, 39 total rows.) This always takes place at the top of the screen, at the start of scanline 0, so I can maintain a stable PAL signal without triggering a resync between effects. What I *think* was happening is because we're in R4=0,R9=0 the new R4=38,R9=7 values aren't latched until the current scanline has been emitted, so I end up with my standard 312 scanline screen PLUS an extra one from scanline 0 before the registers took effect.

My fix is to set 32 visible rows, 39 total rows but start with R9=6 (7 scanlines/row), wait for 8 scanlines then set R9=7 (8 scanlines/row) so I end up with 38*8 + 1*7 + 1 = 312 scanlines. This works on real hardware but results in the effect being "broken" on b-em and jsbeeb.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
tricky
Posts: 2640
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Video Timing

Post by tricky » Mon Jun 04, 2018 11:13 pm

Would it be "safer" to add a total adjust (R5) of 8 scan lines and then change your mode in that section, with 38 rows and vsync one row earlier?
If I understand what you are doing, and I might have missed it, this would make everything match as well as supporting any 6845s that don't add the extra line (inc maybe beeb FPGA?).
You could leave it in all effects, giving you a safe place to do "stuff".

User avatar
kieranhj
Posts: 701
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Video Timing

Post by kieranhj » Tue Jun 05, 2018 10:15 am

tricky wrote:
Mon Jun 04, 2018 11:13 pm
Would it be "safer" to add a total adjust (R5) of 8 scan lines and then change your mode in that section, with 38 rows and vsync one row earlier?
If I understand what you are doing, and I might have missed it, this would make everything match as well as supporting any 6845s that don't add the extra line (inc maybe beeb FPGA?).
You could leave it in all effects, giving you a safe place to do "stuff".
That's an interesting idea, thank you! The vertical total adjust might well be considered "no man's land" by the CRTC, so not considering the other registers. I'll have to ponder the implementation, and might mean I have to re-time some of the effects, but it would be great not to have to have a manual prompt at the beginning asking "is this real hardware y/n?"

On a related note, I always wondered how the Beeb changed mode smoothly without disrupting the vsync in the middle of a refresh but I guess it just doesn't so you get one frame that's screwy before the monitor resyncs to a clean signal.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Tue Jun 05, 2018 11:24 am

With the diversion on restoring 'normal' CRTC conditions, I think I've lost the discussion here! Kieran, can you explain again what problems you're seeing now on real hardware, compared to emulation? During the demo (and also during the transition)?

Just to make sure I understand your code well enough, can you confirm that call_update is called at some imprecise moment during vertical flyback, and call_draw gets called just after the topmost visible scanline has started to be rasterised (i.e. after the left border, within the first few characters of the horizontal displayed region)? I think the timing of this is the most crucial, e.g. if it were to happen fractionally before the first visible scanline starts (e.g. in the left border) it could change the behaviour entirely!

User avatar
tricky
Posts: 2640
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Video Timing

Post by tricky » Tue Jun 05, 2018 2:41 pm

Sorry, I was half asleep when I wrote that, assuming you have many "screens" per field, you would get many blank bits, not what you want.
Unless you are going in and out of mode 7, the vertical timing doesn't change, so apart from one long/short row, the timing shouldn't be too far off.

User avatar
kieranhj
Posts: 701
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Video Timing

Post by kieranhj » Tue Jun 05, 2018 9:48 pm

Rich Talbot-Watkins wrote:
Tue Jun 05, 2018 11:24 am
With the diversion on restoring 'normal' CRTC conditions, I think I've lost the discussion here! Kieran, can you explain again what problems you're seeing now on real hardware, compared to emulation? During the demo (and also during the transition)?

Just to make sure I understand your code well enough, can you confirm that call_update is called at some imprecise moment during vertical flyback, and call_draw gets called just after the topmost visible scanline has started to be rasterised (i.e. after the left border, within the first few characters of the horizontal displayed region)? I think the timing of this is the most crucial, e.g. if it were to happen fractionally before the first visible scanline starts (e.g. in the left border) it could change the behaviour entirely!
Sorry, I'm trying to get a better repro that is separated from all of my demo nonsense.

I've hacked together something that sets the colour palette 0 on the first and last rasterlines of the frame (0 and 255) to check that's actually what's happening. For a standard 8 scanlines / row, 39 rows / frame screen I get this on b-em, jsbeeb and real HW:
standard crtc.PNG
Blue on rasterline 0, red on rasterline 255
For the same test with my screen made up of 256x CRTC cycles each one row of one scanline (then 56 rows of one scanline = 312) I would expect this, seen in b-em and jsbeeb:
256 single scanlines.PNG
Green on rasterline 0, red on rasterline 255
Instead what I'm getting is this:
real master.jpeg
No colour rasterline 0, red on rasterline 254!
So nothing visible on the top rasterline 0 and then the red palette change happening on rasterline 254 continuing through rasterline 255. This would be consistent with the timer triggering effectively at rasterline -1 (so turning the red palette off during vblank still.) But because the image is stable I must be producing a 312 rasterline display (otherwise the 312*64us timer would get earlier and earlier and the red bar at the bottom would get larger.)

This would be consistent with the CRTC generating a single frame of 313 rasterlines whilst switching from the standard 8 scanlines/row to my 1 scanline/row arrangement. I'm setting the CRTC register values at the very start of rasterline 0 (the red bit in the middle picture before the palette is changed to green.) Does this still make sense? What do we think the CRTC is doing here?

When I have more time I can strip the code code and upload it if useful.

EDIT: This would also be consistent with my previous "fix" which was generating a single frame of 311 lines which put the timing back as expected for those subsequent effects which are absolutely rasterline sensitive.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
hoglet
Posts: 7364
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Video Timing

Post by hoglet » Wed Jun 06, 2018 6:41 am

It would be very handy to have a minimal test case for this, then I'll try and fix it in BeebFPGA (which I think probably also has the issue).

Is there are conclusion as to what "additional" behaviour actually needs to be implemented to match the real 6845?

(I've slightly lost the plot)

Dave

User avatar
kieranhj
Posts: 701
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Video Timing

Post by kieranhj » Wed Jun 06, 2018 6:48 am

Rich Talbot-Watkins wrote:
Mon May 14, 2018 8:33 pm
I feel like this can also be explained by the same issue as tricky's problem, here.

Have I understood right that you have a bunch of single line, single row CRTC frames (R4=0, R9=0), and then a block of rows to make the PAL frame up to 312? In the other thread, we have the observation that R4 needs to be changed before the final scanline; but if each CRTC frame *is* only one scanline, that doesn't give you any place to do it. So you'll get an extra row of R4=0 with the new R12/R13 (at the bottom), and then you'll get the big block of R4 as intended.
OK, so I think I've answered my own question here and you were right all along - this can be explained by the same issue as Tricky's problem - i.e. setting the vertical total R4 doesn't have any effect during the final scanline of a CRTC cycle (value latched earlier than expected as per reenigne's observation on CGA in that thread.)

For my special screen, on rasterline 255 I'm attempting to set up a final block of 57 scanlines = 312 total but as we're already on the final scanline of this CRTC cycle that gets ignored until the next cycle starts so I end up with 256 + 57 = 313 scanlines. Because the timer now triggers effectively at rasterline -1 (the final scanline of the vsync cycle) the CRTC registers I'm setting are effectively ignored and the cycle completes. I'm cycle counting 255 scanlines to my big vsync block which will now be on rasterline 254, taking effect on 255 + 57 = 312 scanlines. So all the frames onwards are 312 scanlines (by accident rather than design) - this means the timer is now 128us out going forward.

This also explains what I was seeing previously (and reported on jsbeeb github) with the graphics appearing at the bottom rather than the top of the screen on real hardware - it was actually my timing that was out by one scanline so the screen address was being set before the end of the frame rather than during vblank as I had thought.

I'm still not clear as to exactly when the CRTC is comparing the Vertical Character Count against Vertical Total (R4) which I think is at the root of my issue. Is this only when VCC is incremented or cleared?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
tricky
Posts: 2640
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Video Timing

Post by tricky » Wed Jun 06, 2018 7:42 am

Perhaps it might be worth adding a line of total adjust before and after the main 256 lines to allow the vertical total to be set in the adjust line in case we come across a 6845 that doesn't add the extra line (may also make HW match SW).

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 8:39 am

That all sounds very plausible, Kieran! It makes sense once you realise that the timer itself will trigger a scanline early; it also helps to explain why the first scanline was apparently displaying OK when, by the same account, you'd expect setting R4=0 during the first visible scanline to be ignored if it had already "taken the decision" not to finish the frame yet. Of course, since it gets triggered in the last scanline of the previous CRTC frame (in the top border), it ends up being picked up fine at the start of the new CRTC frame.
kieranhj wrote:
Wed Jun 06, 2018 6:48 am
I'm still not clear as to exactly when the CRTC is comparing the Vertical Character Count against Vertical Total (R4) which I think is at the root of my issue. Is this only when VCC is incremented or cleared?
My take on it is that the comparison is probably performed at the beginning of the last scanline (when VerticalCharacterCount==R4 and ScanlineCount==R9). Instinct tells me that it has to be like this; you can't have some registers which are compared after the internal counter has been incremented, and others which are compared before.

I'm fairly clueless with low-level hardware/electronics but I was trying to read up on counter circuits to see how they're constructed. The 6845 block diagram shows counters with a C input ("clock"?), an MC input ("modulus control"?) and CO blocks ("comparator"?). I presume there'll be some kind of propagation delay between the comparator firing and the MC signal resetting the counter (and who knows what the big box marked 'vertical control' is really doing?), but we can assume that VCC will either be incremented or reset to 0 by the next clock (which of course only fires on each scanline). One question is whether the comparators are triggered only when the counters get a clock pulse, or if it happens every cycle?

Hopefully one of the hardware guys (EdS or Mark) can lend their expertise to deciphering the block diagram, and speculate on how it might all work. It really is quite instructive in hinting at the inner workings of the chip:

Image

Edit: This is actually more like the type of CRTC the Beeb uses (with Skew control and a programmable VSync width), but the other block diagram is a bit simpler and clearer.

User avatar
BigEd
Posts: 1985
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Video Timing

Post by BigEd » Wed Jun 06, 2018 8:52 am

That diagram is just a bit too big for my brain, but I'm sure the chip designers will have been concerned with making something fairly simple and regular, fitting the requirements.

One thought: the diagram shows many registers and many comparators. The chip might be like that. Or, it might be that the registers sit on a bus, and there's one comparator which round-robins comparisons between registers and timers. So it can't compare everything at once, it just has to keep up with the usual timings of the usual displays. It could however set one of many 'equals' flops at the time of the comparison, so the control machinery can read those (several) flops whenever it needs to. It's just that the 'equality' might be a little stale by the time it's read.

User avatar
1024MAK
Posts: 7650
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Video Timing

Post by 1024MAK » Wed Jun 06, 2018 9:13 am

Timer, counter, flip-flop and register/latch typical abbreviations:-

CLK - input clock pulses
C - input clock pulses
CK - clock
R - reset input
S - set input
MC - master clear (resets and clears counter/flip-flop/register/latch to zero immediately without waiting for a clock cycle)
MR - master reset, same as master clear
CE - chip enable
Q - output

Where you see the divide sign (➗), it denotes the number the input clock is divided by (and hence the number of flip-flops in the counter).

CO is likely to mean comparator, that is logic that compares each pair of inputs and which has an output that goes to an active state when they are equal.

Not sure what is meant by the box marked 'CC'.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
1024MAK
Posts: 7650
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Video Timing

Post by 1024MAK » Wed Jun 06, 2018 9:35 am

Here is a diagram of a 74LS688 comparator from a TI datasheet:
IMG_7218.JPG
74LS688 comparator internal logic
Inside a more complex chip, you would not need the Schmitt trigger inverters on the inputs.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
1024MAK
Posts: 7650
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Video Timing

Post by 1024MAK » Wed Jun 06, 2018 9:38 am

The box marked 'vertical control' must have both counters and various logic gates, as RA0 to RA4 are generated from it.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 9:48 am

Edit: Mark just posted a load of great stuff, but going to post what I had here anyway, in reply to Ed!

That sounds more complicated Ed! I assume a comparator is no more than a bunch of ANDed XNORs which surely can't have a prohibitively high transistor count.

My mental model for this is as follows:
  • The counter increments on a clock active edge, unless MC is asserted, in which case it's reset. Meanwhile, the comparator will continually fire for as long as the counter value is equal.
  • In the case of the vertical character counter, its clock comes directly from the Scanline==R9 comparator. So this actually implies that VCC is incremented at the beginning of the last scanline.
  • The MC for the VCC is more nuanced: unlike the HCC, whose MC comes straight from its comparator with R0, the VCC's comes from the Vertical Control block. The are loads of inputs to Vertical Control:
    • VCC equal to R4
    • VCC equal to R6 (for controlling VDisplay)
    • VCC equal to R7 (for controlling VSync)
    • Horizontal total (when HCC equal to R0)
    • Horizontal half total (when HCC equal to R0/2, for controlling odd/even fields)
    • Scanline counter
    • R5
    So it seems likely that all this logic is cooked in some way so that VCC gets its reset delayed until the following character row. Among many other things, it must also be used to control the vertical total adjust and the interlace field logic.
There are some curious things I haven't yet figured. For example, the Scanline Counter has as its MC input: SLC==R9 OR (something from the Linear Address Generator). What can that be doing?

Also interesting to note that the Linear Address Generator gets Hend as an input - this is so that it can cache the MA when the right border starts, and use it as the MA for the next character row. But I don't understand why it apparently doesn't have an input from Vertical Control. How else can it know when MA needs to be reloaded from R12/R13?

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 9:52 am

Looks like my interpretation of MC is wrong - thanks Mark. So MC will perform an immediate reset then.

(Edit: although here's an example of the sort of circuit I was imagining: a synchronous counter with a synchronous reset.)

By the way, I think CC on the diagram is just another CO that's scanned badly!

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 10:00 am

Rich Talbot-Watkins wrote:
Wed Jun 06, 2018 9:48 am
There are some curious things I haven't yet figured. For example, the Scanline Counter has as its MC input: SLC==R9 OR (something from the Linear Address Generator). What can that be doing?

Also interesting to note that the Linear Address Generator gets Hend as an input - this is so that it can cache the MA on that active edge, and use it as the MA for the next character row. But I don't understand why it apparently doesn't have an input from Vertical Control. How else can it know when MA needs to be reloaded from R12/R13?
These seem to be errors: in the other block diagram I posted, I think it makes a bit more sense.

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 10:13 am

1024MAK wrote:
Wed Jun 06, 2018 9:35 am
Here is a diagram of a 74LS688 comparator from a TI datasheet:
Happy I guessed that right, at least :lol: Even if I didn't realise it would invert the inputs (or indeed the output!).

User avatar
1024MAK
Posts: 7650
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Video Timing

Post by 1024MAK » Wed Jun 06, 2018 10:29 am

A couple of things to keep in mind when looking at counters.
Depending on the design of the counter, it can be clocked by a logic level (high, or low), or better, clocked on an edge (rising from logic low to logic high, or falling from high to low).

The easiest (and hence cheapest) counters have unsynchronised outputs. That is, propagation delay of the logic circuits causes the count to ripple through each stage, with the output of each stage changing one after another. This results in the output having invalid data for brief time periods.
The more complex synchronised counter design has an output that only changes state once per clock cycle, so it has no output glitches.

Generally speaking, the more complex the circuit, the higher the propagation delay. But if the outputs are synchronised to a central ('master') clock, as long as the period of the clock speed is greater than the propagation delay, you remove a lot of the problems caused by variable propagation delay.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
kieranhj
Posts: 701
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Video Timing

Post by kieranhj » Wed Jun 06, 2018 10:51 am

Rich Talbot-Watkins wrote:
Wed Jun 06, 2018 8:39 am
kieranhj wrote:
Wed Jun 06, 2018 6:48 am
I'm still not clear as to exactly when the CRTC is comparing the Vertical Character Count against Vertical Total (R4) which I think is at the root of my issue. Is this only when VCC is incremented or cleared?
My take on it is that the comparison is probably performed at the beginning of the last scanline (when VerticalCharacterCount==R4 and ScanlineCount==R9). Instinct tells me that it has to be like this; you can't have some registers which are compared after the internal counter has been incremented, and others which are compared before.
And from the other thread:
reenigne wrote:
Sun Jun 03, 2018 9:47 pm
Rich Talbot-Watkins wrote:
Mon May 14, 2018 7:51 pm
So far the observed behaviour seems to be: "Set R4 before the final scanline of the frame for its new value to be noticed".
That seems right to me, given the results of my own experiment with the Motorola 6845 ("type 2" in the CPC parlance) on my CGA card. I can't find the exact details of what I'm thinking of right now, but I noticed that certain register values take effect at points in the line/frame earlier than you might expect (at the end of the visible area, or at the start or end of the sync pulse). I think the reason for this is to avoid "too much happening at once" in what would otherwise be the obvious place for things to happen (row 0, scanline 0 within the row, or character 0) which could cause flip-flops to be set and reset in the same cycle and could lead to unpredictable behaviour.
This does make sense. Looking at the b-em source code it's doing approximately the following:

IF HorizontalCharacterCount==R0 AND ScanlineCount==R9 AND VerticalCharacterCount==R4 THEN VerticalCharacterCount=0; FrameCount++

Presumably jsbeeb similar? What do we think that logic should look like?

I have a simpler test case that I can upload but I haven't had chance to try it on real hardware, so don't want to confuse matters if it is not working correctly (it should be as I just hacked out all the unused code from the above.)


Actually if anyone wants a punt it's in GitHub here: https://github.com/bitshifters/just-ras ... st-rasters.

First screen is standard 8 scanlines/row * 39 rows/cycle setup - rasterline 0 should be set green when the timer arrives (with some jitter) then rasterline 255 should be set red after cycle couting 255 rasterlines. The left half of the top row of pixels is set to &AA so should see dashes.

Press N to move to 1 scanline/row * 1 row/cycle * 255 cycles + 57 rows/cycle screen - rasterline 0 should be set green when the timer arrives and rasterline 255 should be set red after cycle counting 255 rasterlines. The right half of the top row of pixels is set to &AA so should see stripes down the right side of the screen as the same memory address is repeated on all 256 rasterlines.

Note this only works on a Master as I'm using 65C02 instructions. On real hardware I'm expecting the first screen to be the same as the emulator but on the second screen the top line of green should be missing and the bottom two rows will be red.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 10:54 am

1024MAK wrote:
Wed Jun 06, 2018 10:29 am
The easiest (and hence cheapest) counters have unsynchronised outputs. That is, propagation delay of the logic circuits causes the count to ripple through each stage, with the output of each stage changing one after another. This results in the output having invalid data for brief time periods.
The more complex synchronised counter design has an output that only changes state once per clock cycle, so it has no output glitches.
The kind of circuit in the link I posted in my edit above seems fairly straightforward, and strikes me as the sort of thing that would fit the 6845's operation. The key to all this lies in the big "Vertical Control" black box!
1024MAK wrote:
Wed Jun 06, 2018 9:38 am
The box marked 'vertical control' must have both counters and various logic gates, as RA0 to RA4 are generated from it.
I think this is fairly straightforward, as RA0-RA4 either correspond exactly to the scanline counter (SC), or to SC*2+<field number> in the case of interlaced sync+video. But there certainly must be a fair bit of logic in there, as it needs to perform special handling for things like the vertical total adjust section, interlace, etc.

It'd be interesting to know whether R9 is affected in the same way as R4, i.e. if R9 is reset to a new value in the last scanline, does it get ignored due to "having already decided" to finish the character row?

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Wed Jun 06, 2018 10:58 am

kieranhj wrote:
Wed Jun 06, 2018 10:51 am
This does make sense. Looking at the b-em source code it's doing approximately the following:

IF HorizontalCharacterCount==R0 AND ScanlineCount==R9 AND VerticalCharacterCount==R4 THEN VerticalCharacterCount=0; FrameCount++

Presumably jsbeeb similar? What do we think that logic should look like?
Both B-Em and jsbeeb perform comparisons before and after the counter is incremented, so in this sense it's not really working the same as the CRTC I don't think. I don't think it'd be a really straightforward change, to be honest. It think it needs to increment the counter first (or reset it), and then perform all the comparisons, setting some bools to simulate latched state to be handled later. If I can find some time, I'll try and sketch out the logic which I think works, and see if I can make changes to jsbeeb.

User avatar
BigEd
Posts: 1985
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Video Timing

Post by BigEd » Wed Jun 06, 2018 11:03 am

Rich Talbot-Watkins wrote:
Wed Jun 06, 2018 9:48 am
That sounds more complicated Ed! I assume a comparator is no more than a bunch of ANDed XNORs which surely can't have a prohibitively high transistor count.
Could be - it was only a thought. (With a regular datapath layout, a bus is almost free. A comparator in static logic is at least 5 transistors per comparator per bit, which is about 5 * 14 * 10, coming out at 700. That's not trivial, in the chips of the day. Alternative circuits exist, but XOR is not nearly as cheap as NOR. A counter which is preloaded and counts down to zero is very much preferable - but the block diagram doesn't indicate that.)

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Thu Jun 07, 2018 7:03 am

Just pondering this again this morning. I think, in terms of simplicity, everything makes sense apart from one thing. Are we sure that R12/13 take effect when set in the final scanline of the previous frame? Kieran, do you have concrete evidence of this working OK in your demo, or is there a chance you're getting a lag in the address setting?

User avatar
Rich Talbot-Watkins
Posts: 1299
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Video Timing

Post by Rich Talbot-Watkins » Thu Jun 07, 2018 7:10 am

BigEd wrote:
Wed Jun 06, 2018 11:03 am
A counter which is preloaded and counts down to zero is very much preferable - but the block diagram doesn't indicate that.)
And indeed we know it not to be the case, as it's possible to change registers during the CRTC frame, and their new value will be correctly used as the upper bound.

Are there die shots of the 6845 that would give an immediate impression of its complexity?

User avatar
BigEd
Posts: 1985
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Video Timing

Post by BigEd » Thu Jun 07, 2018 7:14 am

> any die shots?
I don't think there are - I don't know of any and can't find any - but that would really help! As you say, even the organisation of the thing.

User avatar
tricky
Posts: 2640
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Video Timing

Post by tricky » Thu Jun 07, 2018 11:49 am

Rich Talbot-Watkins wrote:
Thu Jun 07, 2018 7:03 am
...Are we sure that R12/13 take effect when set in the final scanline of the previous frame?...
Scramble sets one address (for then next 8 scan lines) and then immediately sets the the one for the following frame (8 scan lines).

Code: Select all

lda #CrtcR13Screen1stCharLo : sta CrtcReg : lda crtc_r13 : clc : adc #64 : sta CrtcVal

lda #CrtcR13Screen1stCharLo : sta CrtcReg : lda crtc_r13 :       adc #128 : sta crtc_r13 : sta CrtcVal
lda #CrtcR12Screen1stCharHi : sta CrtcReg : lda crtc_r12 :       adc #0   : sta crtc_r12 : sta CrtcVal
Without a NOP ladder, this has 10 cycles of slack, but as b-em seems to be about two cycles out, only eight of them are available.
So it certainly looks like setting it at the end of a frame works and that the beginning of the next is latched until the following frame.
I know it is on the correct line and somewhere off screen, so I assume that it is at the end, it certainly seems so from palette changing N cycles before setting R12/13.

Post Reply