More 315-5313 unknown stuff (speculation)

Talk about anything else you want

Moderator: BigEvilCorporation

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Fri Jan 04, 2008 12:05 am

Bump.

Hooked pins 120-127 and C-sync into an homemade DAC (R ladder), connected the analog output into Video-in of the TV, started S&K (demo mode, infinite running) in NTSC then switched to PAL after a while (to see those «bottom dots» on-screen)...

Results:
- Picture like $hit (LOL) shakes slightly both Horz and Vert, bah (bad sync insertion possibility);
- During active display I can't see anything useful but its full of alternating white-grey-black, like when you are tunning the TV: that static noise...
- In the place of those color dots there are bright dots, and in the rest of the black border there are some different greyscale patterns (rectangular), but I can't see in much detail because the picture isn't steady...

Those pins individualy connected to Video they show different "noise" in active... but those pixels in inactive are always there when they are visible.


Then tested pins 18-25 individualy (I hadn't soldered wires to these yet):

Active display was black/dark grey and in the inactive period there was some white pixel groups (2 or more).

Pin 9: -> nothing
Pin 14: seems nothing

I need to sync those pixels with c-sync to take conclusions...

[dream mode]
Ahhhh the VDP's datasheet was so great...
[/dream mode]

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Fri Jan 04, 2008 6:23 am

It may help:
To study signals VDP I did this: did connect on RGB, blue and red left in their seats and green connected through buffer to the signals. For example, thats "bottom dots" goes strictly by signal CLK of VDP memory. Try yourself.
Very interesting happens, when try "to watch" VDP memory signals. You can see them with the referenced raster and to see how the image is formed. Sprites are always on HBlank. Maybe, thats is why it have an restrictions "Sprites per line"?

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Fri Jan 04, 2008 10:07 am

Any idea of what I should do?

Apply some logic, move to a different set of pins...

Yeah RGB mode seems better because of the independent sync, I just didn't think of it, and used video as luminance+sync

Did you test any of the unconnected pins?

pin9, 14, [18-25], SPA/B, [120-127]

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Fri Jan 04, 2008 11:52 am

Jorge Nuno wrote:Did you test any of the unconnected pins?
pin9, 14, [18-25], SPA/B, [120-127]
Not yet.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Fri Jan 04, 2008 3:36 pm

Can you run homebrew on your console?

Probably the digital pixel data in the first post could be taken from Vram data bus but I need to diferenciate scan reads from DMA/68K reads/writes

How can I spy the Vram data bus without addresses since it's a multiplexed AD bus? What about the serial port? (crappy memories why didn't Sega used SRAM like everyone would... bah!)

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Fri Jan 04, 2008 4:39 pm

Jorge Nuno wrote:Can you run homebrew on your console?
Yes I can. I must check my PD-ROMs on real hardware.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Fri Jan 04, 2008 4:48 pm

Any means of testing SPA/B activity? like a osciloscope or a tv/some wires?

I would like to ask you if you can run any assembly source with sprites, with some additions...

In the VDP regs setup in the source, you would set every unknown bit to 1, then spy that SPA/B

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Fri Jan 04, 2008 6:15 pm

Give me compiled PD-ROM with test and I will do some research.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Fri Jan 04, 2008 6:19 pm

Will do, thanks :)

I'm now connecting Vram data bus to the TV, I'm separating addresses from data with a 74HC244 with enable connected to /OE1.

Edit: Vram data bus seems to output the tilemaps to the TV (it only shows vertical bars), the actual pixels probably are in the serial access port...

Edit2: Vram serial port looks better on the TV, but not that good yet (I can see something like the Sega logo in the S&K startup :lol: ).
Applying some logic atm...

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sat Jan 05, 2008 3:37 am

I have noticed that for every 32 raster pixels happening consistent with the reading of each Plan A/B and Sprites on 4x speed. Then, its shift inside VDP at normal pixel speed.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Jan 05, 2008 2:02 pm

HardWareMan wrote:I have noticed that for every 32 raster pixels happening consistent with the reading of each Plan A/B and Sprites on 4x speed. Then, its shift inside VDP at normal pixel speed.
Sorry but i don't understand what you are trying to say... :cry: :(
______

Now...
THE STUFF:

Image

Image

(S&K) Sandopolis Zone sand currents, SEGA logo, Special stage
2 frames/pic because the TV can take snapshots :)

Vram Serial port, AND 4 bits of it, combined /CSYNC, combined /SOE }-> Video-in of the TV, I'm not using any of the analog video/rgb outputs!

If you want to help me cleaning the picture see the vram datasheet:
http://www.alldatasheet.com/datasheet-p ... ZP-10.html

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sat Jan 05, 2008 5:00 pm

Jorge Nuno wrote:
HardWareMan wrote:I have noticed that for every 32 raster pixels happening consistent with the reading of each Plan A/B and Sprites on 4x speed. Then, its shift inside VDP at normal pixel speed.
Sorry but i don't understand what you are trying to say... :cry: :(
OK. I will record live video to show you how it does. When you see it - you will get it.
Jorge Nuno wrote:If you want to help me cleaning the picture see the vram datasheet:
http://www.alldatasheet.com/datasheet-p ... ZP-10.html
I already have it. And I know, how this kind of memory works.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Jan 05, 2008 5:30 pm

Ok, I think I know how it works too, but in the pictures there are some white/black bars, which shouldn't be there and I have no clue how to get rid of them...

^^LOL am I drunk !? Obviously it's missing the Serial Clock to validade the output OMG :P


I think the VDP gets the plane data from vram trough the parallel data port and then sets the pointer address of the serial port and the pixels come out in the serial data bus, then palletizes them, applies sh/hl, then dac them.

MegaDrive with HDMI, LOL

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Wed Jan 09, 2008 8:14 am

To understand how the VDP works, it is necessary to see how works the main component video system - VRAM. This Dual channel DRAM, incorporating feature is that the buses of address and data has been combined. The second port of serial access is connected separately. In order to obtain meaningful data needs to become attached to something. I used an active raster, which shows on TV. I took one of the colors (green), and instead VDAC connected to a digital output AD4. And got this picture:
Video 17 MBytes
As can be seen in video, the image is divided into 6 equal parts (I think in the 32-tiles mode they will be 5). First 5 (Section 1 - Section 5) are used for rendering plans A and B. Last one, 6 section is used for rendering sprites. You can see that the sections shifted to left (relative to the active raster), which is logical - picture needs a little advance preparation, to compensate for the delay in the schemes. In each section takes place 4 times read from VRAM to SO. Meanwhile, the rest of the time likely to be used by the processor. If you calculate that 40-tiles mode (320 pixels), it will mean that at one section accounts for 40 / 5 = 8 tiles (or 64 pixels), and one subsection 8 / 4 = 2 tiles (16 pixels). Section 6 seems totally preoccupied sprites reading, and shows that sprites coordinate Y is match, and the coordinates of X formed during basic raster drawing. But VRAM speed is limited. And size of sprite buffer inside VDP is unknown. So, maybe this is why we've got that limitation of srites per line?
Next, I switched green color on the serial exit SO4.
Video 14 Mbytes
It has become clear that all information service appeals to VRAM gone and emerged clean image data. However, they are highly compressed horizontally, just do not forget - is only 1 bit of the 8, and the pixel is 4 bits.
Image
On the field VBlank under raster we see processor accessing to memory during treatment interruptions - the same mysterious dots, which sometimes appear there.
So what everyone thinks about this?
PS Sorry for my terrible english. :oops:

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Wed Jan 09, 2008 11:22 am

Ok so you used the video-out of the MD and connected a Vram pin to the green line?

I think this is not what i'm looking for... I'm trying to get a digital video out of the VDP, just like the system C2 does (I has the same VDP as the megadrive but it uses no RGB, but has pins 120-127 conected to a 8bit D latch, which don't connect to anything on a standart MD... (But connected to a TV I could only get diagonal lines with random pixels :( )

I'm sure it's possible to compute pixel data spying the VDP memory accesses but it's too complicated... The solution are pins 120-127, I'm almost sure, I just need to discover how...


Thanks for the effort :D

Post Reply