News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Recent posts

#1
avatar_Shaun M. Neary
Games / Re: Mighty Street fighter - CP...
Last post by Shaun M. Neary - Today at 12:22
Hahaha
Is Toki actually a playable character now?!  :laugh:

That amount of comedy is worth the five euro alone!
#3
Overall, GA went crazy. Something got unsoldered inside.
#4
Quote from: McArti0 on Today at 10:49@eto it's not like that.

Mode 1 work like that Lp0,Lp1,Lp2,Lp3,Hp0,Hp1,Hp2,Hp3.

First line R pen 1 : 11110000
First line R pen 2 : 00001111
First line R pen 3 : 11111111

You probably saw my first version of the post which was incorrect. It's now

Quotewith PEN 1 byte 1 would be 11110000 (4 pixels PEN 1)
with PEN 2 byte 1 would be 00001111 (4 pixels PEN 2)
with PEN 3 byte 1 would be 11111111 (4 pixels PEN 3)
and that seems to be the same values.

#5
@eto it's not like that.

Mode 1 work like that Lp0,Lp1,Lp2,Lp3,Hp0,Hp1,Hp2,Hp3.

First line R pen 1 : 11110000

First line R pen 2 : 00001111

First line R pen 3 : 11111111
#6
Quote from: dr_slump on 17:10, 15 July 25With pen 2/pen 3, now the left part of the characters repeats in yellow. In mode 2, every other character is missing.
could you try again in mode 0?

I would expect that the normal output is striped with two pixels being visible, then two pixels being invisible. 
The same should happen for PEN 1-7

But with PEN 8-15 the blank areas should repeat the previous two pixels just in another colour. 

#7
I forgot to add the video shift register schematics in the previous post

Please be aware that the bits in this schematics are 0...7 and not 7...0.

(I didn't recognize that in the first place why I went back and forth on the original post with what is shifted where. )
#8
Quote from: Bread80 on Yesterday at 22:45That could mean A0 hasn't fully settled by the time ~CAS transitions low and the DRAM's address decoders start working. The late transitioning signal could, perhaps, mean that different DRAM's are working off of different values for A0. So, maybe, some of the chips are return a value for A0=1 and some are returning a value for A0=0. Possibly the address decoding is incomplete and they may be returning data for a completely different address.

Exactly... what could happen is that the address bit of A0 is one or the other - or maybe something completely different is happening. If there would be rubbish on screen or always everything empty or an exact replica of the left side, I would totally agree.

But we see a very special behaviour that can't be explained by an address error. It's the data bits that get transformed in a predictable way. And I don't see how the multiplexer for the address bus can transform data bits in a predictable and consistent way.

Look at the screenshot where he sets PEN 2 and PEN 3. I attached the relevant part here again. The right half of each character is a repetition of the left half - just in PEN 1.

Let's have a look at the first line of pixels of the character R.

with PEN 1 byte 1 would be 11110000 (4 pixels PEN 1)
with PEN 2 byte 1 would be 00001111 (4 pixels PEN 2)
with PEN 3 byte 1 would be 11111111 (4 pixels PEN 3)

If it would working correctly byte 2 would then be right half of R, if it would just be an address glitch it would be a repetition of the first byte or some other content from somewhere in RAM but what we actually get is for every single byte something that could be a shift (4 left) operation.

In the end we get something that would be the equivalent of byte 2 =

PEN 1: 00000000 (empty)
PEN 2: 11110000 (4 pixels but now PEN 1)
PEN 2: 11110000 (4 pixels but now PEN 1)

And this behaviour is consistent for every single character.

The only thing I am aware of that can shift bits (except for the CPU) is the Gate Array.

And there it could be explained, if I understand the schematics correctly. This to me looks like the data of the first byte is loaded into the video shift register in the GateArray. Then it's shifted 4 bits while outputting the first 4 pixels. After that the next byte should be loaded into the video shift register. If  this does not happen  the GateArray continues with the 4 bits that are still there - which is basically the content of the first byte shifted 4 bits to the right.

This would also explain Mode 2 behaviour as in Mode 2 the shift video register will shift by 8 bits thus being empty.
#9
Quote from: Bread80 on Yesterday at 22:59
Quote from: Rabs on Yesterday at 22:32How does the CRTC come into play with addressing lines, could it be that if one of the  tracks between the CRTC and multiplexers was broken that the same adress lines would be repeated when addressing the memory for the screen display and hence repeat? See Noel's video, mentioned above.
Yup. That's pretty much the issue here. But the repeat in this instance is every successive byte. So we're talking about address line A0. A0 is driven directly by the GA, it's the signal whose full name is MA0_CCLK - "address line zero, CRTC clock".

I've no idea why they didn't just clock the CRTC at twice the frequency though. I believe it's capable. Maybe there's a limitation on how it can be programmed? Maybe it would have required an extra signal from the GA? Maybe the CRTC is too slow to update between the two video bytes?
Yup, so I would check the traces first. You can create all sorts of odd repeating patterns.

This is IC113 PIN 3 on my test board.

You cannot view this attachment.

I will try IC105 PIN 4 tomorrow and see if I get the same pattern.
#10
Quote from: Rabs on Yesterday at 22:32How does the CRTC come into play with addressing lines, could it be that if one of the  tracks between the CRTC and multiplexers was broken that the same adress lines would be repeated when addressing the memory for the screen display and hence repeat? See Noel's video, mentioned above.
Yup. That's pretty much the issue here. But the repeat in this instance is every successive byte. So we're talking about address line A0. A0 is driven directly by the GA, it's the signal whose full name is MA0_CCLK - "address line zero, CRTC clock".

I've no idea why they didn't just clock the CRTC at twice the frequency though. I believe it's capable. Maybe there's a limitation on how it can be programmed? Maybe it would have required an extra signal from the GA? Maybe the CRTC is too slow to update between the two video bytes?
Powered by SMFPacks Menu Editor Mod