68000 clock cycles table

[MetalGuru]

Hello !

Thanks for your test.
This means that at least these switches do not work with all STEs with the time spots used for my STF.
But may be it can your with slightly different time spots.

Anyone with a STF can test this ?

Any more STEs around (as it seems that there also are diffrent generations of STEs) ?

I tried HARD162E.PRG on a my 1040ST and i see the bee and a white border.

/MetalGuru

[ljbk]

Hello !

Thanks for your test.
This means that at least these switches do not work with all STEs with the time spots used for my STF.
But may be it can your with slightly different time spots.

Anyone with a STF can test this ?

Any more STEs around (as it seems that there also are diffrent generations of STEs) ?

I tried HARD162E.PRG on a my 1040ST and i see the bee and a white border.

/MetalGuru

Many thanks !!!

When you say 1040ST, you mean STF right ?

Can you also test ijor's program to check your clock here:

http://www.atari-forum.com/viewtopic.ph ... 7bb6e871f6


Anyway, this means that the thing does not only work on my machine.
Nice !
So it worth to proceed !

[MetalGuru]

Many thanks !!!

When you say 1040ST, you mean STF right ?

Can you also test ijor's program to check your clock here:

http://www.atari-forum.com/viewtopic.ph ... 7bb6e871f6


Anyway, this means that the thing does not only work on my machine.
Nice !
So it worth to proceed !

Well actually it's a 1040STFM..


/MetalGuru

[leonard]

My GFA program uses 12 line sizes:
0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206 and 230 bytes.

I confirm with my own small C syncscroller finder that you can acheived a 5 lines hardscroller with these lines (instead of 6). The funny trick is that you use the 1+4 mode, and even better, you don't have to do anything in the first line (160 bytes). For anyone loving strange beauty of numbers, here are the lines combine. Please note the first line could be 160 each time.

Offset required (from 2 to 254) | lines
002:160,230,186,186,184, 80, Ok
004:160,230,230,230,230,204, Ok
006:160,230,230,230,230,206, Ok
008:160,230,230,206,206, 0, Ok
010:160,230,230,230,184, 0, Ok
012:160,230,230,230,186, 0, Ok
014:160,230,230,206,158, 54, Ok
016:160,230,230,206,160, 54, Ok
018:160,230,230,206,162, 54, Ok
020:160,230,230,206,162, 56, Ok
022:160,230,230,186,186, 54, Ok
024:160,230,230,186,186, 56, Ok
026:160,230,186,162, 56, 0, Ok
028:160,230,186,160,158,158, Ok
030:160,230,230,230,230,230, Ok
032:160,230,230,230,206, 0, Ok
034:160,230,206,206, 0, 0, Ok
036:160,230,230,184, 0, 0, Ok
038:160,230,230,230,158, 54, Ok
040:160,230,230,230,160, 54, Ok
042:160,230,230,230,162, 54, Ok
044:160,230,230,230,162, 56, Ok
046:160,230,230,186,184, 80, Ok
048:160,230,230,186,186, 80, Ok
050:160,230,206,162,158,158, Ok
052:160,230,206,162,160,158, Ok
054:160,230,206,162,162,158, Ok
056:160,230,230,230,230, 0, Ok
058:160,230,230,206, 0, 0, Ok
060:160,230,230,206,204, 54, Ok
062:160,230,230,206,206, 54, Ok
064:160,230,230,230,184, 54, Ok
066:160,230,230,230,186, 54, Ok
068:160,230,230,230,186, 56, Ok
070:160,230,230,162, 56, 0, Ok
072:160,230,230,160,158,158, Ok
074:160,230,230,162,158,158, Ok
076:160,230,230,162,160,158, Ok
078:160,230,230,162,162,158, Ok
080:160,230,230,162,162,160, Ok
082:160,230,230,230, 0, 0, Ok
084:160,230,230,230,204, 54, Ok
086:160,230,230,230,206, 54, Ok
088:160,230,230,230,206, 56, Ok
090:160,230,230,230,184, 80, Ok
092:160,230,230,230,186, 80, Ok
094:160,230,230,186, 56, 0, Ok
096:160,230,230,184,158,158, Ok
098:160,230,230,186,158,158, Ok
100:160,230,230,186,160,158, Ok
102:160,230,230,186,162,158, Ok
104:160,230,230,186,162,160, Ok
106:160,230,230,186,162,162, Ok
108:160,230,230, 0, 0, 0, Ok
110:160,230,230,230,230, 54, Ok
112:160,230,230,230,230, 56, Ok
114:160,230,230,206, 56, 0, Ok
116:160,230,230,204,158,158, Ok
118:160,230,230,206,158,158, Ok
120:160,230,230,206,160,158, Ok
122:160,230,230,206,162,158, Ok
124:160,230,230,206,162,160, Ok
126:160,230,230,206,162,162, Ok
128:160,230,230,186,186,160, Ok
130:160,230,230,186,186,162, Ok
132:160,230,186,162,162, 0, Ok
134:160,230, 0, 0, 0, 0, Ok
136:160,230,230,230,230, 80, Ok
138:160,230,230,230, 56, 0, Ok
140:160,230,206,206,204,158, Ok
142:160,230,230,230,158,158, Ok
144:160,230,230,230,160,158, Ok
146:160,230,230,230,162,158, Ok
148:160,230,230,230,162,160, Ok
150:160,230,230,230,162,162, Ok
152:160,230,230,186,186,184, Ok
154:160,230,230,186,186,186, Ok
156:160,230,186,186,162, 0, Ok
158:160,230,162,162,158, 54, Ok
160:160,230,162,162,160, 54, Ok
162:160,230,230,230, 80, 0, Ok
164:160,230,230,206,204,158, Ok
166:160,230,230,206,206,158, Ok
168:160,230,230,230,184,158, Ok
170:160,230,230,230,186,158, Ok
172:160,230,230,230,186,160, Ok
174:160,230,230,230,186,162, Ok
176:160,230,230,162,162, 0, Ok
178:160,230,186,186,184, 0, Ok
180:160,230,186,186,186, 0, Ok
182:160,230,204,204,204,204, Ok
184:160,230,206,204,204,204, Ok
186:160,230,206,206,204,204, Ok
188:160,230,230,230,204,158, Ok
190:160,230,230,230,206,158, Ok
192:160,230,230,230,206,160, Ok
194:160,230,230,230,206,162, Ok
196:160,230,230,230,186,184, Ok
198:160,230,230,230,186,186, Ok
200:160,230,230,186,162, 0, Ok
202:160,230,206,162,158, 54, Ok
204:160,230,206,162,160, 54, Ok
206:160,230,206,162,162, 54, Ok
208:160,230,230,204,204,204, Ok
210:160,230,230,206,204,204, Ok
212:160,230,230,206,206,204, Ok
214:160,230,230,230,230,158, Ok
216:160,230,230,230,230,160, Ok
218:160,230,230,230,230,162, Ok
220:160,230,230,206,162, 0, Ok
222:160,230,230,186,184, 0, Ok
224:160,230,230,186,186, 0, Ok
226:160,230,230,162,158, 54, Ok
228:160,230,230,162,160, 54, Ok
230:160,230,230,162,162, 54, Ok
232:160,230,230,162,162, 56, Ok
234:160,230,230,230,204,204, Ok
236:160,230,230,230,206,204, Ok
238:160,230,230,230,206,206, Ok
240:160,230,230,230,230,184, Ok
242:160,230,230,230,230,186, Ok
244:160,230,230,230,162, 0, Ok
246:160,230,206,206,158, 54, Ok
248:160,230,230,184,158, 54, Ok
250:160,230,230,186,158, 54, Ok
252:160,230,230,186,160, 54, Ok
254:160,230,230,186,162, 54, Ok

[ijor]

What i mean is the visual result: an unstable picture.
It happens that a line combination leading to a stable fullscreen pic can lead to an unstable 320 pixels wide pic and vice versa.
For example, if i rember rigth, if the last line of the sync-scroll lines is a 186 bytes one (only left border) it is likely that the pic will be unstable.

If you ever find in your notes some reference, so that I could try to reproduce the problem, please let me know. I would be very interested to study this.

This means that at least these switches do not work with all STEs with the time spots used for my STF. But may be it can your with slightly different time spots.

Hmm, I don't think so. If my theory is correct, then you have a single possible timing to make these switches. So unless you made a mistake, this might mean it won't work at all on STe.

Well, as I said above. I have some idea that I never tested. Assuming the idea works, it might give you a chance to adapt the timing here. But I am suspecting now that the switches are simply not possible (without a distorted picture) in STe machines.

Anyway, this means that the thing does not only work on my machine.

I can't assure you it works on all machines. But I can assure you it works at least in many. I did make some tests some time ago. The tests I did were different than yours. But they both depend on the same issue. If my tests worked, then yours should as well on the same machine.

The funny trick is that you use the 1+4 mode, and even better, you don't have to do anything in the first line (160 bytes).

Exactly. That's what I was saying all the time, that if you never loose sync you can sync-scroll with 4 scan lines only!

[leonard]

Exactly. That's what I was saying all the time, that if you never loose sync you can sync-scroll with 4 scan lines only!

Yes Well, keep "in sync" for the complete screen is quite a pain but few demos use that mode. (I remember a fullscreen demo by mcoder with a 2 bitplan text vertically waving)

4 lines scroller is cool !

btw Paulo, could you explain your trick to get two version of line working for each ST state ?

[MetalGuru]

I've tested ijor's program.
I get:

Computed clock: ~32.08 MHz
Machine: PAL

/MetalGuru

[ljbk]

I've tested ijor's program.
I get:

Computed clock: ~32.08 MHz
Machine: PAL

/MetalGuru

Many thanks !

This means that the 162 bytes line works on a standard PAL STFM machine as it does on a weird NTSC STF machine like mine with a different CPU and video clock.

[ijor]

btw Paulo, could you explain your trick to get two version of line working for each ST state ?

I would try to explain. Because I suspect Paulo doesn't know the full explanation. I mean, he obviously knows how to make it work. But he might not know from the theory, why it has to be done like this, and why exactly it works (it shouldn’t work according to what most people believes the ST works).

The full explanation is rather long. For quite some time I wanted to complete a couple of articles. But I never could find the time. It is likely that I won't be able anytime soon. So here is a short, concise one. Many people probably won't understand it. But other like Leonard and Paulo surely will, and then we'll all be able to answer possible questions.


Why these new switches don't work, or are not stable depending on the wake state?

All the other overscan switches require a precision of 4 machine cycles. That is, you have a window of 4 cycles to apply the switch to be effective. These two new cycles, however, require a precision of 2 cycles.

A precision of 4 cycles is not a problem. It is always possible to find a simple code and timing that would work on all machines and wakeups. But a precision of two cycles is problematic because of two reasons.

The two wakeups produces a shift of two machine cycles between the CPU and GLUE. So a given code that would work in one wakeup, would be 2 cycles earlier (or later) in the other and won't work. So these switches require the code to be adapted at runtime to the current wakeup.

The other problem is that 2 cycles is beyond the NOP resolution. You have to use pairing correctly to shift the code in 2 cycles unit. And put something like EXG D0,D0 (6 machine cycles) right before writing into GLUE.

Up to here I'm sure Paulo knows. But there are still two questions to answer:

1) Why these new switches require a 2 cycles precision? They shouldn't. After all it is a normal 50/60Hz switch. All the horizontal 50/60 switches are based on the 4 cycles distance between the 50/60Hz GLUE timing. This shouldn't be an exception. After all, we are just messing with the left border, the rising edge of DE. And this signal is raised 4 cycles later in 50Hz than in 60Hz. So it would be natural to assume it should require the same 4 cycles precision as say, removing the right border.

A hint: Near the top of the second part of the excellent Alien overscan articles, there is a key sentence. He says that something couldn't be exactly determined. If you can determine what he couldn't determine, then you have the answer to why we need a 2 cycles precision.

2) Pairing should not help according to the theory. The theory is that all CPU bus cycles are aligned on a four cycles boundary. So it doesn't matter what kind of pairing you use, you should never be able to make a bus access two cycles earlier (or later). But the theory is wrong, something that Paulo suspected long ago. I remember he mentioned something like “it seems the CPU can sometimes get two time slots in a row”.

I found the full answer on two completely unrelated topics. One is how the Discovery Cartridge works. As many people know, the DC is not exactly a ROM cartridge, it has a custom ASIC with a low level floppy controller. Back on the old days I found that the DC performs a small piece of code right from the cartridge. So it does have some code. It didn't make much sense to me at the time. The software is rather big, it couldn't be for saving code space. I thought it could be some kind of copy protection to avoid cloning or hacking. But then I didn't care too much and forgot about it for a long time.

Now I know why. So try to answer why the DC might need to run some code off the cartridge, that it couldn't, or would be much more complicated, when run as part of the normal program. Looking at the ST schematics could also give the answer

[leonard]

Hey Ijor you play with our nerves

I can follow a coding discussion, but if that problem require looking at ST shematics, then I'm afraid I'm out... (I don't know anything in electronics ! )

Someone else?

[ljbk]

btw Paulo, could you explain your trick to get two version of line working for each ST state ?

Hi Leonard !

I can not explain you fully the reasons why it works in this way with the electronic timings and so on.
What i can tell you is that for my ST, and it seems that for some more, the switch in both wake up states has to be done with a precision of 2 pixels/cycles as ijor said and as i knew already for a long time: you can check my emails from April 2005 about Nostalgic and some other test progs.
A sync switch is made of a switch to a certain frequency or resolution and then a switch back.
For these cases and for both wake up states, one of the 2 must be done precisely at a certain time with that precision of 2 pixels/cycles.
The provided program simply tries both combinations patching the code if the first one does not work and also reversing the background color.
That is why you can get a stable "bee" with black or white background depending on the wake up state or a flashing screen like in Steem if none of the two routs works.

Btw, your table shows combinations for a 5 lines sync scroll.
With the 12 possible line sizes, you can do it theorically with 1(sync)+4 where the sync line can be 158, 160 or 204.
But i can not say that all 128 offsets have a stable combination before testing it on the real hardware.
May be i will do it next weekend or the one after if i have some time as this really needs a lot of time.


Cheers,
Paulo.

[Cyprian]

I found the full answer on two completely unrelated topics. One is how the Discovery Cartridge works. As many people know, the DC is not exactly a ROM cartridge, it has a custom ASIC with a low level floppy controller. Back on the old days I found that the DC performs a small piece of code right from the cartridge. So it does have some code. It didn't make much sense to me at the time. The software is rather big, it couldn't be for saving code space. I thought it could be some kind of copy protection to avoid cloning or hacking. But then I didn't care too much and forgot about it for a long time.

Now I know why. So try to answer why the DC might need to run some code off the cartridge, that it couldn't, or would be much more complicated, when run as part of the normal program. Looking at the ST schematics could also give the answer

It means 4 clocks boundaries do not rule in cartridge area?

[Greenious]

It means 4 clocks boundaries do not rule in cartridge area?

Well, let me have a shot at this, I believe the answers are these:

1) HBL is not exact, meaning, it actually flickers a few clockcycles back & forth. For each individual horisontal line, the "window" to do the switch, actually is pretty big, but since the exact moment HBL is turned on, is impossible to predict, timing becomes more critical. When it also get shifted, relative the CPU, as in the 2 wakeup modes, the windows gets an additional cut.

2) every 2 clockcycles there is a readslot to the memory, they alternate between the shifter & the CPU. 68000 normally do only 1 read for every 4 clockcycles, so this is actually not slowing it down that much.

However...

The CPU also prefetch the next instruction. With instructions that has got very short runtime (ie 6 clockcycles) and/or do memory access, the CPU never manages to prefetch the next instruction in time, and has to wait for 2 clockcycles to get in "phase" with the readslots. But with instructions that take more time, and/or do no memory access, you could actually do 2 instructions in a row that use n*4+2 clockcycles, and when they finish, still be in phase with the 4 clock readcycle. (and thus "save" 4 clockcycles)

Not only that, but it is also entirely plausible that you in some cases can do a n*4+2 instruction + a n*4 instruction and finish with a n*4+2 instruction, and still have "saved" 4 clockcycles. It all depends on the number of memoryaccesses involved, and when they take place.

ROM access is not restricted by this, and the CPU can actually run "out of phase" with the memory slot as long as it is not accessing RAM. So the reason they put some code inside the discovery cartridge is likely due to some extreme timing requirements.

[DrCoolZic]

I have tested the Hard16e program on my 1040STF and I am getting a black border. Not sure if it has importance but it seems that the sweeping frequency received by the monitor (a multisynch monitor) is changed by the program resulting in an image slightly shifted and shrinked.

Also tried on a 1040 STE and I am getting complete flickering.


FYI my 1040STF is detected as NTSC @ 32.04. It has a non standard hardware in the Video:
The original Shifter circuit (C025914-38A), which is located in a shielded trap, has been removed and replaced by a small board containing 2 Shifter circuits (this provide a 4096 colors pallete to my Atari). This was done as part of the 4MB memory upgrade from John Russel innovations (called the JRI-RAM+). The TOS of the machine has been upgraded to 1.4

But this should not have an impact ?

[ijor]

Hey Ijor you play with our nerves

Sorry Leonard, that wasn't my intention

Well, Cyprian_K found the answer to the second question, and Greenious (as most hardware experts) knew it all the time.

Let me make an historical evolution of how I learned the CPU timing in the ST:

1) Instruction timing follows Motorola docs.
2) Not at all. They must be rounded up to a multiple four.
3) Wait, not always, there is a pairing mechanism. So the rule is actually that all bus cycles peformed by the CPU are aligned in a 4 cycles boundary.
...
4) Wrong, not always. Only when the bus cycle access an address in the private MMU/Shifter/RAM data-path.

In other words. If the CPU accesses an address that does NOT intefere with MMU timeslots, then it is not limited by that alignment.

In particular, accessing TOS in ROM, cartridge space, and most I/O locations, including the GLUE sync register can be done at anytime. RAM and Shifter registers follow rule 3 above. The resolution register is a special complex case because it is shared both by GLUE and Shifter.

So the whole damn thing works, because the bus cycle that performs 50/60 switch does NOT have to be aligned to a 4 cycles boundary.

Yet, nobody attempted to answer question number 1. Why do we need two cycles precision for these new switches at all? No Greenious, HBL has no flicker or jittering whatsoever. There is some jittering on the HBI (horizontal blank interrupt) which is a different thing and does not affect the issue.

So, what was that thing that Alien couldn't determine?

[ijor]

It is interesting to look at this from the non-technical point of view.

The Discovery Cartridge was developed around 1988. So Mr. Adams (Happy Computers man) knew something back then, that (almost) none of the sceners/coders/full-screen experts realized for a very long time. It is possible that Mr. Adams got help from some Atari engineer. But as Greenious can tell you, most hardware guys knew, or at least could easily realize that rule 3 should not apply to ROM and cartridge. They might perhaps, miss the exact effect on overscan switches.

So what I found interesting, is that it seems there was a big disconnection between Atari engineers, hardware guys, and software guys. Otherwise this could have been found and widely known long ago.

[ljbk]

I have tested the Hard16e program on my 1040STF and I am getting a black border. Not sure if it has importance but it seems that the sweeping frequency received by the monitor (a multisynch monitor) is changed by the program resulting in an image slightly shifted and shrinked.

Also tried on a 1040 STE and I am getting complete flickering.


FYI my 1040STF is detected as NTSC @ 32.04. It has a non standard hardware in the Video:
The original Shifter circuit (C025914-38A), which is located in a shielded trap, has been removed and replaced by a small board containing 2 Shifter circuits (this provide a 4096 colors pallete to my Atari). This was done as part of the 4MB memory upgrade from John Russel innovations (called the JRI-RAM+). The TOS of the machine has been upgraded to 1.4

But this should not have an impact ?

Hello !

Thanks for your tests.

The "bee" should be shifted by 4 pixels to the left as the screen starts a bit earlier as it would with and NTSC 60Hz display but the line and VBL frequencies are unchanged and correspond to a normal PAL frame.
The "shrinking" you refer should not happen.
Anyway with a sync-scroll, this kind of lines would be applied for 4 lines maximum and not for 199 like it is this test program.

Taking your results and the previous ones into account, it looks that these sync switches work on STF(with 32.02, 32.04 and 32.08 MHz video-clock) but not on STE.
But as STEs have a built in hardware scrolling, that is not too important.
Alien's 4-bit sync-scrolling also only works on STFs.

[DrCoolZic]

The "bee" should be shifted by 4 pixels to the left as the screen starts a bit earlier as it would with and NTSC 60Hz display but the line and VBL frequencies are unchanged and correspond to a normal PAL frame.
The "shrinking" you refer should not happen.

Actually your program changes both the Vsynch and Hsynch frequencies!

Before running your program: 15.8 KHz and 60Hz
After running your program: 15.6 KHz and 50 Hz

This explain why the image is shrinked. I guess you did not expect my machine to be running in 60 Hz ? More info on my configuration in http://www.atari-forum.com/viewtopic.php?p=75965#75965

BTW Sorry it took some time to reply but I had to carry an hyper heavy monitor close to my Atati to make the frequency measurement!!!

[ljbk]

The "bee" should be shifted by 4 pixels to the left as the screen starts a bit earlier as it would with and NTSC 60Hz display but the line and VBL frequencies are unchanged and correspond to a normal PAL frame.
The "shrinking" you refer should not happen.

Actually your program changes both the Vsynch and Hsynch frequencies!

Before running your program: 15.8 KHz and 60Hz
After running your program: 15.6 KHz and 50 Hz

This explain why the image is shrinked. I guess you did not expect my machine to be running in 60 Hz ?

Sorry it took me some time to carry an hyper heavy monitor close to my Atati to make the frequency measurement.

Yes, that's right the program sets the normal PAL frequencies.
I did not tought about the possibility of your ST running in default in NTSC/60 Hz especially considering your location in France.
Anyway, what i meant is that the program should not generate any abnormal frequencies.

[leonard]

Oh sorry Paulo, I copy/paste a 6 raster line scroll

Here is a 5 (1+4) line one, WITHOUT the 0 bytes lines (is that line working on all ST now?)

If you use the 0 bytes line, you get a (1+4) line syncscroller too, but, as Ijor mentioned, the first line could be always 160bytes, so you *can* to 4 lines syncscroller if you stay in sync during the complete VBL !

Here is 1+4 synctable, without use of 0 bytes line

000:160,230,162,162, 54, Ok
002:160,230,162,162, 56, Ok
004:160,230,230,204,204, Ok
006:160,230,230,206,204, Ok
008:160,230,230,206,206, Ok
010:160,230,230,230,184, Ok
012:160,230,230,230,186, Ok
014:160,206,204,158, 54, Ok
016:160,206,206,158, 54, Ok
018:160,230,184,158, 54, Ok
020:160,230,186,158, 54, Ok
022:160,230,186,160, 54, Ok
024:160,230,186,162, 54, Ok
026:160,230,186,162, 56, Ok
028:160,186,186,184, 80, Ok
030:160,230,230,230,204, Ok
032:160,230,230,230,206, Ok
034:160,162,162,160,158, Ok
036:160,162,162,162,158, Ok
038:160,230,204,158, 54, Ok
040:160,230,206,158, 54, Ok
042:160,230,206,160, 54, Ok
044:160,230,206,162, 54, Ok
046:160,230,206,162, 56, Ok
048:160,230,186,186, 54, Ok
050:160,230,186,186, 56, Ok
052:160,186,158,158,158, Ok
054:160,186,160,158,158, Ok
056:160,230,230,230,230, Ok
058:160,204,204,204, 54, Ok
060:160,206,204,204, 54, Ok
062:160,206,206,204, 54, Ok
064:160,230,230,158, 54, Ok
066:160,230,230,160, 54, Ok
068:160,230,230,162, 54, Ok
070:160,230,230,162, 56, Ok
072:160,230,186,184, 80, Ok
074:160,230,186,186, 80, Ok
076:160,206,162,158,158, Ok
078:160,206,162,160,158, Ok
080:160,206,162,162,158, Ok
082:160,206,162,162,160, Ok
084:160,230,204,204, 54, Ok
086:160,230,206,204, 54, Ok
088:160,230,206,206, 54, Ok
090:160,230,230,184, 54, Ok
092:160,230,230,186, 54, Ok
094:160,230,230,186, 56, Ok
096:160,230,158,158,158, Ok
098:160,230,160,158,158, Ok
100:160,230,162,158,158, Ok
102:160,230,162,160,158, Ok
104:160,230,162,162,158, Ok
106:160,230,162,162,160, Ok
108:160,230,162,162,162, Ok
110:160,230,230,204, 54, Ok
112:160,230,230,206, 54, Ok
114:160,230,230,206, 56, Ok
116:160,230,230,184, 80, Ok
118:160,230,230,186, 80, Ok
120:160,206,206,158,158, Ok
122:160,230,184,158,158, Ok
124:160,230,186,158,158, Ok
126:160,230,186,160,158, Ok
128:160,230,186,162,158, Ok
130:160,230,186,162,160, Ok
132:160,230,186,162,162, Ok
134:160,186,186,186,184, Ok
136:160,230,230,230, 54, Ok
138:160,230,230,230, 56, Ok
140:204,230,158,158,158, Ok
142:160,230,204,158,158, Ok
144:160,230,206,158,158, Ok
146:160,230,206,160,158, Ok
148:160,230,206,162,158, Ok
150:160,230,206,162,160, Ok
152:160,230,206,162,162, Ok
154:160,230,186,186,160, Ok
156:160,230,186,186,162, Ok
158:204,230,230,206, 56, Ok
160:204,230,230,184, 80, Ok
162:160,230,230,230, 80, Ok
164:160,206,204,204,158, Ok
166:160,206,206,204,158, Ok
168:160,230,230,158,158, Ok
170:160,230,230,160,158, Ok
172:160,230,230,162,158, Ok
174:160,230,230,162,160, Ok
176:160,230,230,162,162, Ok
178:160,230,186,186,184, Ok
180:160,230,186,186,186, Ok
182:160,162,160,158, 54, Ok
184:160,162,162,158, 54, Ok
186:160,162,162,160, 54, Ok
188:160,230,204,204,158, Ok
190:160,230,206,204,158, Ok
192:160,230,206,206,158, Ok
194:160,230,230,184,158, Ok
196:160,230,230,186,158, Ok
198:160,230,230,186,160, Ok
200:160,230,230,186,162, Ok
202:160,184,158,158, 54, Ok
204:160,186,158,158, 54, Ok
206:160,186,160,158, 54, Ok
208:160,204,204,204,204, Ok
210:160,206,204,204,204, Ok
212:160,206,206,204,204, Ok
214:160,230,230,204,158, Ok
216:160,230,230,206,158, Ok
218:160,230,230,206,160, Ok
220:160,230,230,206,162, Ok
222:160,230,230,186,184, Ok
224:160,230,230,186,186, Ok
226:160,206,160,158, 54, Ok
228:160,206,162,158, 54, Ok
230:160,206,162,160, 54, Ok
232:160,206,162,162, 54, Ok
234:160,230,204,204,204, Ok
236:160,230,206,204,204, Ok
238:160,230,206,206,204, Ok
240:160,230,230,230,158, Ok
242:160,230,230,230,160, Ok
244:160,230,230,230,162, Ok
246:204,184,158,158, 54, Ok
248:160,230,158,158, 54, Ok
250:160,230,160,158, 54, Ok
252:160,230,162,158, 54, Ok
254:160,230,162,160, 54, Ok

[ijor]

I have tested the Hard16e program on my 1040STF and I am getting a black border.

Great! Many thanks. This might confirm it works on all non STe computers. Because as I said on the other thread, it seems your ST belong to the latest generation, which we could assume it should be the closest to the STe.

Btw, this might confirm a theory I have for quite some time. It is that the whole theory that there are a dozen (or half a dozen) different GLUE/MMU/SHIFTER combinations, which different overscan behavior, is just a mhytos.

I believe there are only two (pre STe) GLUE generations as far as overscan concerns. The ones with the two different top border sizes. The rest is just ... wakeups.

There might be in addition, some differences in the stabilization. I'm not so familiar with the stabilization issue.

...WITHOUT the 0 bytes lines (is that line working on all ST now?)

If should work whenever the other new scan lengths work. They are both produced by the same mechanism. The time critical switch is almost the same, just in the opposite direction. And the stability of both depends on the same timing.

[Cyprian]

Sorry Leonard, that wasn't my intention

Well, Cyprian_K found the answer to the second question, and Greenious (as most hardware experts) knew it all the time.

thanks,
i have next question

is it possible to run parallel cpu and blitter in hog mode? (for xample, cpu in cartridge area and blitter in st-ram)

[Greenious]

Yet, nobody attempted to answer question number 1. Why do we need two cycles precision for these new switches at all? No Greenious, HBL has no flicker or jittering whatsoever. There is some jittering on the HBI (horizontal blank interrupt) which is a different thing and does not affect the issue.

So, what was that thing that Alien couldn't determine?

Alright, since I am curious, hate not understanding, got pride, and everything...

After having read through aliens overscan articles...

The answer lies in the right border removal method, since you have a 4 clockcycle window, to switch to 60hz to make the GLUE skip DE deactivation. But since the 2 wakeup periods differs with 2 clockcycles vs the internal clocks, they only have a 2 clockcycle window that is common to eachother, relative the CPU.

is it possible to run parallel cpu and blitter in hog mode? (for xample, cpu in cartridge area and blitter in st-ram)

No, blitter & the CPU share the same data & adressbus, so running them in parallell is impossible. (their memory accesses, even though they access different parts, would collide, since they use the same bus)

[ljbk]

If you use the 0 bytes line, you get a (1+4) line syncscroller too, but, as Ijor mentioned, the first line could be always 160bytes, so you *can* to 4 lines syncscroller if you stay in sync during the complete VBL !

With the 12 line sizes i refered, you can theorically:
- syncscroll a fullscreen in 1 sync + 4 lines like in your table
- syncscroll a 320 pixels wide screen in 1 sync + 3 lines
- syncscroll a fullscreen in 4 lines without synching at screen start
- syncscroll vertically a 320 pixels wide screen in 3 lines without synching at screen start

Without synching at screen start has of course quite a high price in case of fullscreen: complete precisely timed screen with keyboard and so on like one screen of ULM in Darke Side Of The Spoon or Ziggy interrupt method. In case of a 320 pixels wide screen, you only need to be synched during the low/top border and VBL.

But as i said, these theorical possibilities have to be checked for stability with the real hardware.
Just the 3 lines case gives you 12^3= 1728 combinations.
This is because in terms of image stability a [158 184 186] combination can have different results of a [184 186 158] combination.
For the 1+4 case, we have at least 62208 combinations ...

Cheers,
Paulo.

[ijor]

The answer lies in the right border removal method, since you have a 4 clockcycle window

No, your window/precision analysis is wrong.

The border in question is the left one, not the right one. But what is more important is that, even if your analysis would be correct, it wouldn't explain why the difference between the left and the right borders.

Note that "border removal" is not the best expression here. This might confuse some people because the left border is "removed" using a completely different mechanism, and we aren't removing the left border here. We are talking here about switches that can select the borders (actually, the DE edges) for being at the 50Hz position, at the 60Hz position, or at none. "None" has the opposite effect on each side. In the right side it removes the border, in the left side it removes the line.

This selection among 50/60/none should be equivalent for both borders/edges. Same distance betwen the 50Hz-60Hz positions. Same window. Same precision. But it is not.

Sorry Greenious, but I'm afraid you probably don't have much chances to find the answer for this one . It is a software issue, not a hardware one. Or more exactly, it requires a software analysis. Schematics, scopes, traces won't help you here (not without the right software).

Ok, seems that those that could answer without more clues are not very interested. So, second hint:

My bad, ugly, seudo-translation from portions of Alien article, second part:

Code: Select all

note that the determination of the exact moment of the HBL triggering was impossible...furthermore, the determination of Y is not interesting at all ...

SEUDO-CODE
...
IF Position ==  13   AND display_freq=60 THEN Activate signal H
IF Position ==  14   AND display_freq=50 THEN Activate signal H
IF Position ==  93   AND display_freq=60 THEN de-activate signal H
IF Position ==  94   AND display_freq=50 THEN de-activate signal H
IF Position ==   Y   AND display_freq=60 THEN Activate Hsync
IF Position == Y+1   AND display_freq=60 THEN de-activate Hsync, start new line
IF Position == Y+2   AND display_freq=50 THEN Activate Hsync
IF Position == Y+3   AND display_freq=50 THEN de-activate Hsync, start new line

So as I was saying all the time, determine what Alien couldn't determine. What is the value of Y?