HBL, Timer B, Rasters color and jitter

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Cyprian
Atari God
Atari God
Posts: 1464
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

HBL, Timer B, Rasters color and jitter

Postby Cyprian » Mon May 14, 2012 7:41 pm

It seems that there is simple answer why rasters on Timer B or HBL are not stable.
In various documents over the net 68000 Interrupt takes always 44 cycles. But according to that forum, Interrupt doesn't takes constant number of cycles but is between 26 and 44.

http://forums.freescale.com/t5/68K-Cold ... td-p/19079
In a 68000 system the E clock (originally the cycle clock for the 6800 CPU) is generated by dividing the system clock by 10 - the E clock was low for six clocks and high for four clocks. At the original 68K speed of 10 MHz this gave a suitable 1 MHz clock for 6800 peripheral devices.

When the VPA signal is activaated in response to a external cycle, the CPU will synchronize to the E clock and terminate the cycle after the next active E clock.

Since your interrupt is not synchronized to the E clock, there is a random delay based on the state of the E clock when the interrupt acknowledge occures.



and there:
http://furrtek.free.fr/noclass/neogeo/mvstech.txt

Note that while Motorola's documentation lists the interrupt acknowledge
cycle as taking 44 mclks, it varies from minimum of 26 to a maximum of 44
(typically 32 is the other length that happens most often). The cause of
the variable timing isn't known. This has implications when using the
display position IRQ to change screen attributes mid-scanline, as it
results in jitter because the ISR does not start at an absolute position
relative to when the interrupt was requested. (*1)

However, apart from very precise changes such as modifying the palette
or setting the screen brightness latch mid-scanline, this generally is not
a problem as long as the interrupt is generated with some extra time in
advance to compensate for worst-case jitter.

1. The variable length is caused by the 68000 which negates /AS based on
some internal decision. It has nothing to do with the E clock phase
relation, nor the video hardware releasing /VPA at the wrong time
(/VPA is negated after /AS is). It also does not depend on the code
being executed before the interrupt; NOP gives the fastest response
time on average (26 at best), STOP is a middle case for reference
despite putting the system in a wait-for-interrupt condition.


here viewtopic.php?f=68&t=13264 is another explanation of Raster jitter
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

ijor
Hardware Guru
Hardware Guru
Posts: 3270
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby ijor » Mon May 21, 2012 12:25 am

I'm afraid I can't elaborate too much right now, and probably I won't be able for a couple of weeks (yeah, that's becoming the norm lately, sorry about that). So just a couple of short comments.

HBL and Timer-B interrupts are two very different beasts. Their origin, behaviour, type of jitter, etc, they are all completely different between both types of interrupts.

HBL interrupt is generated by GLUE. There is jitter at the number of cycles that this interrupt produces. This jitter is caused by the CPU itself and related, indeed, to the internally generated clock E (the actual technical reason is that GLUE interrupts are autovector). The jitter however is not random. It is a fully predictable pattern (based on the phasing of the E clock). Paulo and me prooved how to sync to HBL a few years ago.

Timer B interrupts, on the other hand, are generated by the MFP. They are not autovector interrupts and hence they don't depend on the phase of the E clock. This interrupt has a different class of jitter. This interrupt has a starting time jitter generated by the MFP. The interrupt isn't generated always exactly at the same cycle (in relation to the horizontal beam). Contrast this to the HBL interrupts, which always start exactly at the same cycle.

Two additional issues affect both type (actually almost all the exceptions) of interrupts. There is a software jitter. Interrupts happen at instructions borders, so they might be delayed more or less if they are triggered during, say a long division instruction. Lastly, exceptions on the ST never take the "by the book" number of cycles. The reason is our famous round up to four (each bus cycle, not just each instruction) and pairing rules.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4982
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby simonsunnyboy » Mon May 21, 2012 3:39 pm

I was told in the past not to use HBL and use Timer B instead. Is the HBL even more unstable in comparison, e.q. even less cycles to use? (See the other thread)
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: HBL, Timer B, Rasters color and jitter

Postby mc6809e » Sat May 26, 2012 5:19 pm

ijor wrote:HBL interrupt is generated by GLUE. There is jitter at the number of cycles that this interrupt produces. This jitter is caused by the CPU itself and related, indeed, to the internally generated clock E (the actual technical reason is that GLUE interrupts are autovector). The jitter however is not random. It is a fully predictable pattern (based on the phasing of the E clock). Paulo and me prooved how to sync to HBL a few years ago.


I had forgotten about the E clock. CPUclk/10, right? I'm guessing to get pixel accurate timing you had to use a STOP instruction and an HBL interrupt handler padded with instructions based on the current scanline making for a fixed 48 cycles from interrupt to first CPU write instruction.

Very nice.

ijor
Hardware Guru
Hardware Guru
Posts: 3270
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby ijor » Mon Jun 18, 2012 3:46 am

simonsunnyboy wrote:I was told in the past not to use HBL and use Timer B instead. Is the HBL even more unstable in comparison, e.q. even less cycles to use? (See the other thread)


Again, they are quite different. Which one is better? Well, as always, the correct answer is ... it depends. In most cases Timer B is probably better though. HBL is better when you need it outside the vertical borders (Timer B ticks at displayed lines only, because it is triggered by the edge of the DE signal).

mc6809e wrote:I'm guessing to get pixel accurate timing you had to use a STOP instruction and an HBL interrupt handler padded with instructions based on the current scanline ...


Yep, that's about the general idea. HBL has a jitter pattern that is predictable. You need to establish the initial current position on the pattern only once (the phase of the E clock). Then, for any future scanline at any future frame, you can easily compute what would be the jitter pattern (the phase of the E clock at HBL time at that particular scan/frame), and then the exact number of cycles of that particular HBL.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Mon Jun 18, 2012 6:50 am

Thanks for sharing this ijor.

I'd managed to determine that the HBL input to the 68000 goes low on the same cycle on every line with the logic analyser; I'd also determined that the reason the 68000 starts later on some lines /frames than others is a difference in the number of wait states applied to the interrupt (because the time difference from screencurrent to HBL is a constant), and that the 5 was important as a factor of the timing constant, but I hadn't determined the exact mechanism. Excellent analysis.

So the E sync still applies if the reason for asserting VPA is for autovector... that's a properly badly documented feature of the 68000.

ijor
Hardware Guru
Hardware Guru
Posts: 3270
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby ijor » Tue Jun 19, 2012 9:36 pm

Dio wrote:So the E sync still applies if the reason for asserting VPA is for autovector... that's a properly badly documented feature of the 68000.


VPA on interrupts, of course, makes the CPU to wait until E sync. It is explicitely documented. I don't know why you think it is badly documented. You might have been looking at the wrong manual(s).

Btw, the E sync mechanism is also the reason for the wait states jitter when accessing any of the ST's ACIAs. As with HBL (or VBL, for that matter), ACIAs access timing has a non-random, predictable, jitter.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Wed Jun 20, 2012 9:17 am

ijor wrote:It is explicitely documented. I don't know why you think it is badly documented. You might have been looking at the wrong manual(s).

I'd never spotted it because I'd never felt the need to read up on the fine details of the M6800 cycles, since they aren't particularly timing critical in ST emulation (I knew the general principles of the synchronous bus, but hadn't read the spec in detail).

So after searching, I found it in B.2 of the 9th edition User Manual, where it says "During an interrupt acknowledge cycle while the processor is fetching the vector, VPA is asserted and the processor (or external circuitry) asserts VMA and completes a normal M6800 read cycle as shown in figure B-6. For the interrupt vector, the processor uses an internally generated vector number called an autovector."

While it does say 'a normal M6800 read cycle' it doesn't actually mention that the E-clock wait states are involved, and it has no mention of the different behaviour in the documentation on interrupts, and it's equally poor to omit to mention it in the section on interrupt timing. It's hardly a huge omission, and sure, by the standards of technical documentation it's a rounding error, but it's still an omission. If you had a system that never used VPA anywhere but for autovectors, you might feel with some reason quite cheesed off that a timing feature like this wasn't called out elsewhere.

ijor
Hardware Guru
Hardware Guru
Posts: 3270
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby ijor » Mon Jul 02, 2012 1:20 am

Dio wrote:While it does say 'a normal M6800 read cycle' it doesn't actually mention that the E-clock wait states are involved, and it has no mention of the different behaviour in the documentation on interrupts, and it's equally poor to omit to mention it in the section on interrupt timing. It's hardly a huge omission, and sure, by the standards of technical documentation it's a rounding error, but it's still an omission. If you had a system that never used VPA anywhere but for autovectors, you might feel with some reason quite cheesed off that a timing feature like this wasn't called out elsewhere.


I don't want to make a huge debate about this, it is not the main point and I'm not here to defend Motorola. But sorry, I think you are completely wrong.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Mon Jul 02, 2012 11:48 am

OK, put it this way - if something that's intrigued dozens of people and led to some quite substantial amounts of research turns out to be in the docs after all, but nobody except yourself ever found it, it's poorly documented :) .

ijor
Hardware Guru
Hardware Guru
Posts: 3270
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby ijor » Tue Jul 03, 2012 4:30 am

Dio wrote:... but nobody except yourself ever found it ...


Not sure this is a fair, accurate description. I'm pretty sure it was known before, only that you never heard it from that people.

I mentioned the same (or a very similar one) issue some years ago when we developed the newer sync scroll techniques. I described then (in that long thread) that the CPU can perform "misaligned" access to GLUE. So was I the first that ever found out that accessing devices such as GLUE doesn't have to be aligned? No, I don't think so, and I said so then.

I'm pretty sure that "hardware" guys, were very well aware about these facts. It is obvious for a hardware designer that the MMU wouldn't force an alignment on the "other side" of the bus. In the same way, it is obvious for a hardware designer (even if it were completely undocumented) that autovector interrupts are aligned to the E clock.

But for some reason, there wasn't too much communication between hardware and software guys (especially not with demo coders) in the ST scene.

If you had a system that never used VPA anywhere but for autovectors, you might feel with some reason quite cheesed off that a timing feature like this wasn't called out elsewhere.


I am going back to this for a good example of what I am trying to say. You are looking at this, from a software guy (non hardware designer) point of view. For a hardware designer it would be obvious, because it would see it from an almost opposite approach. VPA is raised anytime a legacy (6800 compatible) peripheral is accessed, disregarding which kind of bus cycle is being performed. Otherwise hardware decoding implementation would have been much more complicated. VPA prevents DTACK, and then the CPU must decide internally when to complete the cycle (again, disregarding which kind of cycle) using the E clock. Otherwise how would the CPU know when to complete the interrupt cycle? In other words, and hardware wise, autovector interrupts are just a consequence and a secondary effect of legacy interrupts.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Tue Jul 03, 2012 6:57 am

Yeah, absolutely. I think the ST wasn't an enormously attractive machine to hardware hackers, probably due to the lack of a proper expansion bus; conversely, it was extremely popular with software hackers, since it's almost all about the software.

Now I think about it, I observe the AVEC pin added on the later 68000s, presumably in order to do autovectored interrupts without the delay incurred via VPA...

User avatar
troed
Atari God
Atari God
Posts: 1341
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: HBL, Timer B, Rasters color and jitter

Postby troed » Tue Jul 03, 2012 7:43 am

ijor wrote:reason, there wasn't too much communication between hardware and software guys (especially not with demo coders) in the ST scene.


I can not recall anyone in the demo scene I came into contact with knew that you could predict HBL interrupt jitter, at least. I do know that it was understood to be "different" from the other interrupts though, maybe someone played around with it but never dared to assume it would be the same on all machines.

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: HBL, Timer B, Rasters color and jitter

Postby mc6809e » Tue Jul 03, 2012 9:04 pm

Dio wrote:Yeah, absolutely. I think the ST wasn't an enormously attractive machine to hardware hackers, probably due to the lack of a proper expansion bus; conversely, it was extremely popular with software hackers, since it's almost all about the software.


I don't think it was the lack of an expansion bus. Before the arrival of the 16/32-bit machines in the 80's, most computers had a decent built-in basic interpreter and some way to transfer control to a machine language program. It was possible to go from power up to executing simple machine code in minutes. So much was documented. I remember being able to call Motorola on the phone to get free technical manuals on their parts.

In the mid-80s a wall started to go up. Operating systems became more complicated. Atari ST basic was so full of bugs -- it seemed like writing the interpreter had been an afterthought. Without a C compiler, it was difficult to really program the Atari ST or Amiga. Computers soon stopped being for hobbyists and started being mere tools.

Open source OS's like Linux have done a lot to make systems accessible again, but getting details about how hardware works can still be difficult. And which hardware? Modern OSes have abstracted away so much detail that hardware makers are free to come up with completely difference and often inferior designs that merely fit the abstraction. All this abstraction again puts up a wall and in some cases means common sense optimizations can't be taken advantage of until the OS catches up with new abstractions.

Consider how long it's taken to get a PC to run a CPU in parallel with hardware graphics acceleration. It took years for Windows to get to a point where a programmer could launch a hardware accelerated graphics function that wouldn't block on the call. The OS wasn't designed for that concurrency. And as a result, many graphics accelerators weren't built with a way to asynchronously inform the CPU that an operation had completed. Precious CPU cycles were wasted running a simple loop that checked to see if the hardware had finished. No OS support for asynchronous operation meant no hardware support. And no hardware support meant that there was no need to alter the software. A Catch-22. Just drawing boxes in a window on a single CPU machine running WinXP can make the machine unresponsive. I've done it. The only way out was to create a condition where the thread would yield after drawing a small number of boxes.

HTML/javascript has made things a bit easier for creating simple things. But again, layers of cruft and abstraction have made things opaque. Ever try to write a fast side-scroller using javascript? It's gotten easier with some of the kits out there, but the underlying code complicated and it takes at least a GHz machine with a somewhat modern graphics card.

And WebGL still can make a WinXP machine freeze because of a lack of appreciation for concurrency. Vista finally fixed that.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Tue Jul 03, 2012 10:07 pm

mc6809e wrote:Consider how long it's taken to get a PC to run a CPU in parallel with hardware graphics acceleration. It took years for Windows to get to a point where a programmer could launch a hardware accelerated graphics function that wouldn't block on the call. The OS wasn't designed for that concurrency. And as a result, many graphics accelerators weren't built with a way to asynchronously inform the CPU that an operation had completed. Precious CPU cycles were wasted running a simple loop that checked to see if the hardware had finished. No OS support for asynchronous operation meant no hardware support. And no hardware support meant that there was no need to alter the software. A Catch-22. Just drawing boxes in a window on a single CPU machine running WinXP can make the machine unresponsive. I've done it. The only way out was to create a condition where the thread would yield after drawing a small number of boxes.

And WebGL still can make a WinXP machine freeze because of a lack of appreciation for concurrency. Vista finally fixed that.

I write graphics drivers for a living, so I know a bit about this :) . I think you miss the target a bit looking at notifications and the OS; while the Vista driver model is mostly simpler for us to work within (no more kernel debuggers for most of the code, a lot fewer bluescreens and, as you say, a lot less time in kernel mode which generally makes the machine more responsive). But the philosophy before Vista was that the video driver was just Another Device Driver. Moving it up across the ring boundary hasn't all been gravy mind, it creates a different set of problems.

Now a rising fundamental problem is that you can't preempt the GPU very well. It's possible (indeed, trivial now with arbitrary sized programs) to run a single command on the hardware that can take a very long time to complete, but really it would be nice to be able to preempt it at about the ms level. New hardware is working towards that...

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: HBL, Timer B, Rasters color and jitter

Postby mc6809e » Wed Jul 04, 2012 12:58 am

Dio wrote:I write graphics drivers for a living, so I know a bit about this :) . I think you miss the target a bit looking at notifications and the OS; while the Vista driver model is mostly simpler for us to work within (no more kernel debuggers for most of the code, a lot fewer bluescreens and, as you say, a lot less time in kernel mode which generally makes the machine more responsive). But the philosophy before Vista was that the video driver was just Another Device Driver. Moving it up across the ring boundary hasn't all been gravy mind, it creates a different set of problems.


My point was that the OS's philosophy of CALL function, wait, CALL function, wait, to some extent dictated the hardware. How long did it take for graphics hardware to provide even an interrupt for something like VBlank? Polling 3DA wasted cycles. A work-around would be to use the timer but you had to poll a little bit anyway in case the frequency was a little off.


Dio wrote:Now a rising fundamental problem is that you can't preempt the GPU very well. It's possible (indeed, trivial now with arbitrary sized programs) to run a single command on the hardware that can take a very long time to complete, but really it would be nice to be able to preempt it at about the ms level. New hardware is working towards that...


It's been a problem for a long time. The 2d accelerators of old sometimes had similar problems, but it wasn't completely the GPU's fault. On some cards, higher resolutions would starve the GPU (in a way similar to what happens when an OCS Amiga is set for 16 color hires 736x566 display) which would then leave nothing for the CPU.

Why not allow a software fallback if the GPU is busy? That might allow at least the task manager to come up, allowing one to kill a misbehaved process. Of course the GPU has to at least yield to the CPU so it can access to memory. Again, some early accelerators would consume all available bandwidth and block the CPU. It didn't occur to the designers that the CPU might want to touch graphics memory at the same time a blit was occurring. And why? Because the OS didn't support the notion. Of course the Atari ST and Amiga both used a shared memory arrangement for CPU/graphics, so it was obvious that the CPU and GPU might both be fighting for memory access. As a result, both machines have graphics accelerators that have a limited kind of preemption built into the hardware.

Perhaps if BeOS has taken off we'd have seen these problems solved much earlier.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Wed Jul 04, 2012 8:13 am

mc6809e wrote:My point was that the OS's philosophy of CALL function, wait, CALL function, wait, to some extent dictated the hardware. How long did it take for graphics hardware to provide even an interrupt for something like VBlank? Polling 3DA wasted cycles. A work-around would be to use the timer but you had to poll a little bit anyway in case the frequency was a little off.

Certainly by 1997, although I suspect most chips had the capability a lot earlier. The big enabler of concurrency for 3D was off-chip FIFOs, quickly replaced by command buffer DMA - these developed in the 1996-99 timeframe.

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: HBL, Timer B, Rasters color and jitter

Postby mc6809e » Wed Jul 04, 2012 4:37 pm

Dio wrote:
mc6809e wrote:My point was that the OS's philosophy of CALL function, wait, CALL function, wait, to some extent dictated the hardware. How long did it take for graphics hardware to provide even an interrupt for something like VBlank? Polling 3DA wasted cycles. A work-around would be to use the timer but you had to poll a little bit anyway in case the frequency was a little off.

Certainly by 1997, although I suspect most chips had the capability a lot earlier. The big enabler of concurrency for 3D was off-chip FIFOs, quickly replaced by command buffer DMA - these developed in the 1996-99 timeframe.


Didn't command buffers come in with directx 5? The first release that would run on a Win95 machine was in 1998. Command buffer DMA took much longer to arrive, I think. There are still cards today that use the CPU to maintain the queue of commands. That's better than polling to be sure, but the ability to have a separate graphics op sequencer has been around since at least 1985 (the Amiga's copper could run a sequence of blitter ops).

Even so, to what extent is this feature used by application programmers in general? Lot's of applications are still GDI, though I've seen efforts to mix directx and GDI calls. How long did it take Adobe to use graphics acceleration? 2009?

Oh, well. I know I sound like an old man telling the kids to get off my lawn. I suppose I'm just a little jaded when I see the mess that's Windows.

I think BeOS is good model. There was a nice separation in graphics handling between handing the Windows and contents of the windows. An app drawing into a window would always yield to the OS when a window had to be resized or moved. They were able to get very nice performance even on a dual 200Mhz pentium machine. That was purely a software based approach, thoiugh, so interrupting a blit was easy.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Wed Jul 04, 2012 7:47 pm

mc6809e wrote:Didn't command buffers come in with directx 5? The first release that would run on a Win95 machine was in 1998. Command buffer DMA took much longer to arrive, I think. There are still cards today that use the CPU to maintain the queue of commands. That's better than polling to be sure, but the ability to have a separate graphics op sequencer has been around since at least 1985 (the Amiga's copper could run a sequence of blitter ops).

You may be thinking of execute buffers, which were a very early DirectX feature and a dead end. DirectX 5 was the first that properly offered the DrawPrimitive model which is essentially the core of even the modern APIs.

I'm certain there is no graphics card today that does not use command buffer DMA. And all graphics cards have to have some CPU involvement in converting an API command stream into a command buffer for execution - most obviously, the GPU can't efficiently share address space with the CPU.

Oh, well. I know I sound like an old man telling the kids to get off my lawn. I suppose I'm just a little jaded when I see the mess that's Windows.

Trust me, DirectX is about ten times better than OpenGL. I started out as a GL driver man, but watched with increasing horror as it turned into a complicated mess of interacting extensions, and was extremely happy when they moved DirectX to real-mode so I could jump ship without having to work in kernel-mode all the time. It's not perfect - notably, it's very short on throughput - but the Windows driver stack is tolerably well designed.

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: HBL, Timer B, Rasters color and jitter

Postby mc6809e » Wed Jul 04, 2012 9:16 pm

Dio wrote:Trust me, DirectX is about ten times better than OpenGL. I started out as a GL driver man, but watched with increasing horror as it turned into a complicated mess of interacting extensions, and was extremely happy when they moved DirectX to real-mode so I could jump ship without having to work in kernel-mode all the time. It's not perfect - notably, it's very short on throughput - but the Windows driver stack is tolerably well designed.


Thanks for the info, Dio. I appreciate it. Would you say the same situation exists between opencl and directcompute?

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: HBL, Timer B, Rasters color and jitter

Postby Dio » Wed Jul 04, 2012 10:58 pm

I'm not an expert on either.

Instinctively I think OpenCL should be much better off - it can't have acquired the fragmentation that OpenGL has as of yet, and it has the advantage that the programming model for compute is an order of magnitude simpler than the programming model for the 3D pipeline. Very approximately, it's one shader pipe and a bunch of bits of typed or untyped memory it can read and write to; there's not the vast quantity of semantic complexity encoded in 2-5 different shader types and the fixed function blocks that connect them doing texture filtering and rasterisation and depth buffering.

What makes OpenGL so hairy is that to program any given component it has to go 'If this extension is in use, use this programming model; otherwise, if this other extension is in use, use this programming model, otherwise use this other one' and all the different extensions map onto slightly different bits of the GPU state, creating all sorts of horrible cross-connections between different logical groupings of state. So, for example, to set up the depth buffer you might find yourself having to examine dozens of different bits of state to map the full API state space to the hardware state space. I saw this coming as soon as extensions started to explode in complexity after the multitexture days...

mlynn1974
Captain Atari
Captain Atari
Posts: 164
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby mlynn1974 » Sat Dec 20, 2014 12:26 am

I know this is an old topic but this has intrigued me for a long time.

If we look at the 3D MegaBalls screen in MindBomb you can see how the rasters flicker in the left hand side border when the next sprite wave is being precalculated.
https://www.youtube.com/watch?v=tpR_CGsb1_U

I was told that, in simple terms, this is because the code is doing a lot of DIVS and MULS which take in the order of 160 clock cycles. The interrupt can't be triggered during the execution of the instruction (only at an instruction boundary) so it misses the start of the scanline a bit hence the jitter. I take it it would take a lot more effort to get the rasters really stable when the demo has been programmed like that?
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: HBL, Timer B, Rasters color and jitter

Postby mc6809e » Sat Dec 20, 2014 2:30 am

mlynn1974 wrote:I was told that, in simple terms, this is because the code is doing a lot of DIVS and MULS which take in the order of 160 clock cycles. The interrupt can't be triggered during the execution of the instruction (only at an instruction boundary) so it misses the start of the scanline a bit hence the jitter. I take it it would take a lot more effort to get the rasters really stable when the demo has been programmed like that?


It's worse than that, actually.

Worst case is well over 300 cycles with an interrupt happening near the beginning of a MOVM.L all registers instruction followed by a DIVS.

I'm not sure what the rule is. It could be that interrupt response is put off until the last instruction that has completely filled the prefetch queue has executed.

User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: HBL, Timer B, Rasters color and jitter

Postby leonard » Fri Jan 16, 2015 1:18 pm

mlynn1974 wrote:I take it it would take a lot more effort to get the rasters really stable when the demo has been programmed like that


Ziggy Stardust find a very elegant solution for doing DIV & MUL inside its awesome interrupt fullscreen routine ( begining of the OVR screen in "Froggies over the fence" demo). In that screen you have 3d compute during a fullscreen, running from timer A interrupt. The incredible "simple" trick is to execute a "stop" instruction just before each MULS or DIVS of the code. So the long instruction will start as soon the timer A interupt just finished. Manikin could have use that simple fix. It should have slow down the precompute a bit, but make rasters perfectly stable.

Ziggy's idea was just brilliant.
Leonard/OXYGENE.

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 959
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: HBL, Timer B, Rasters color and jitter

Postby Frank B » Fri Jan 16, 2015 3:58 pm

That is clever


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests