More 315-5313 unknown stuff (speculation)
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
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]
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]
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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"?
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"?
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
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!)
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!)
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
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 ).
Applying some logic atm...
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 ).
Applying some logic atm...
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Sorry but i don't understand what you are trying to say...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.
______
Now...
THE STUFF:
(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
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
OK. I will record live video to show you how it does. When you see it - you will get it.Jorge Nuno wrote:Sorry but i don't understand what you are trying to say...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.
I already have it. And I know, how this kind of memory works.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
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
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
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
^^LOL am I drunk !? Obviously it's missing the Serial Clock to validade the output OMG
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
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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.
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.
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.
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.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
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
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