Для форума zx.pk.ru . Перевод с японского ;)
V9938 VHDL Source Codes
от 2006-11-21 , автор Kunihiko Ohnaka обещает заняться V9958 !!!
( Русское описание чипа V9938 )
The below-mentioned source codeis protected by the use permission condition of the source codeof false VDP. When commercial utilization it is examined, that to "kuni @ communication ohnaka.jp", we ask.
The license of these source codes are here. Contact kuni @ ohnaka.jp if you will use these source code in a commercial product.
Explanation of file
|Vdp.vhd||Top entity. Mounting the VDP command is included||Top entity (including VDP-Command engine)|
|Text12.vhd||TEXT MODE mounting 1 and 2||An implementation of TEXT MODE1 and 2|
|Graphic123M.vhd||GRAPHIC MODE mounting 1, 2, 3 and MULTI COLOR MODE||An implementation of GRAPHIC MODE 1, 2 and 3 and MULTICOLOR MODE|
|Graphic4567.vhd||GRAPHIC MODE mounting 4, 5, 6, and 7||Implementation of GRAPHIC MODE 4, 5 and 6 and 7|
|Sprite.vhd||Mounting the sprite engine||An implementation of the SPRITE engine|
|Spinforam.vhd||1 line the table which houses the information which is necessary to draw sprite,||An information table for rendering sprite a line|
|Ntsc.vhd||The module which adds the horizontal equivalent pulse of NTSC timing||Add NTSC equivalent pulse|
|Pal.vhd||The module which adds the horizontal equivalent pulse of PAL timing||Add PAL equivalent pulse|
|Vga.vhd||The module which rise it scans converts the image signal, outputs with VGA timing||VGA up-scan converter module|
|Doublebuf.vhd||The double line buffer which is used because vga.vhd rise scans converts||Double buffer for vga.vhd|
|Linebuf.vhd||The line buffer which forms doublebuf.vhd||Linebuffer for doublebuf.vhd|
|Osd.vhd||The module which actualizes On-Screen-Display for added information indication||On-Screen-Display (for display additional information)|
|Osdnametable.vhd||The table which houses the information in printing which is indicated in OnScreen-Display||Pattern name table of OSD.|
|Font0406.vhd||The character font which is indicated with OnScreen-Display||The font of OSD|
|Memo.txt||Mounted memo||Implementation memo (wrote in Japanese)|
The function of V9958 is mounted.
Антикварные сырки с древнего помершего сайта Kunihiko Ohnaka .
data It is the timing chart in order to form the picture of NTSC. If it becomes
-> NTSC timing (переведено на английский с оригинального PDF)
-> vhdl source (sync formation and color signal formation for test) 2000/08/01
v9938_rireki.htm last update. 2001/9/18
little it tried making on the basis of the analytical result of V9938 compatible
chip past version
V9938 VRAM access
V9938. Still, partly there is also a strange place, but the picture is produced with VPOKE of MSX-BASIC, something the picture moves with put sprite.
-> Vhdl source (sync formation, VRAM access and sprite (provision mounting), SCREEN8 suitable 2000/08/11
SCREEN1,2,4. Unless the picture is changed to seeing the list indication of
mounting BASIC the pallet one by one not be able to go, because it was the
? inconvenient, you tried mounting SCREEN1 temporarily. SCREEN1 is indicated
properly in, unless it mounts either the pallet, because it is unpalatable,
it mounted that. When it is to obtain, at last writing compiles to the picture
of BASIC coming out in the one shot the surprise. When it moves in the one
shot, considerably impression. Speaking clearly, the genuine picture you distinguish
and are not attached. Almost because algorithm it does not change, next it
tried mounting SCREEN2 and SCREEN4. So the game the ? there will continue
to be labor assistant and not be able to check. When the small place was fumbled,
with SCREEN1 in the picture with the rubbish became the ? way. After the inside
? it is.. .
-> Vhdl source (sync formation, VRAM access and sprite (provision mounting), pallet and SCREEN1,2,4,8.2000/08/12 (отсутствует)
the bug taking trial of SCREEN2,4 demon castle legend (only this game it was
in labor assistant) it tries moving, the picture the ? the ? which is sown.
. When you saw carefully, the setting part of pattern generator table address
by mistake was. Sprite Mode you distinguish 2 and Mode1 clearly. After, SCREEN5
provisional support (there is a bug)
-> the vhdl source (sync formation, VRAM access and sprite (provision mounting), pallet and SCREEN1,2,4,5,8.2000/08/13
such as faithfulness reappearance of sprite is designated as 0xD0, sprite
after the that reproducing the specification which becomes non indication.
The game with strange sprite stopped coming out. After, mounting the sprite
non indicatory bit. When with Sprite Mode 2 side 8 you try to try to be able
to indicate properly, at all not entering. With 3 ten thousand gates TMS9918
limit?. . Unless just a little it compresses, whether useless.
-> Vhdl source (sync formation, VRAM access and sprite (with Mode2 up to side 4), pallet and SCREEN1,2,4,5,8.2000/08/13
sprite discovering the phenomenon where sprite of puzzle is indicated with
the condition for taking. Bug correction. After, being to have forgotten to
raise ram.vhd, it adds.
-> Vhdl source (sync formation, VRAM access and sprite (with Mode2 up to side 4), pallet and SCREEN1,2,4,5,8.2000/08/14
-> FPGA built-in RAM component
of the bug taking substance side which fails in the VRAM light/write and the
clock of VDP being same period not to have done, correcting the bug where
intrinsic hazard occurs.
-> Vhdl source Sprite (with Mode2 up to side 4), the pallet and the SCREEN1,2,4,5,8.2000/08/20
-> FPGA built-in RAM component (for Leonard)
-> the FPGA built-in RAM component (for FPGA Express) renaming in ram.vhd,
compile In order in order to make the built-in RAM component conversion circuit
of the pallet register small, the pallet register which it had with FF, to
use FPGA built-in RAM, it changed.
-> Vhdl source Sprite (with Mode2 up to side 4), the pallet and the SCREEN1,2,4,5,8.2000/08/23
-> FPGA built-in RAM component (for Leonard)
-> the FPGA built-in RAM component (for FPGA Express) renaming in ram.vhd, when please compile (note) you use FPGA Express, there is a possibility compiling not passing with MAX+Plus2.
midst of cause investigation It reached the point where compiling passes with
Xilinx WebPack ICE and FPGA Express.
sprite (with Mode2 up to side 4), pallet and SCREEN1,2,4,5,8
download.html last update. 2001/9/18
Download of data/source
Up-to-date VHDL source
VDP interchangeable version
|VHDL source (v9938.vhd)||In order to connect with other false PLD module, the output of DHCLK and DLCLK||2000/12/07|
|Built-in RAM component (ram.vhd)||It is for Leonard and for Xilinx WebPack ICE.||2000/12/05|
|Built-in RAM component (ram.vhd)||It is for FPGA Express.||2000/12/05|
|Pin defined file (v9938.acf)||For Okoshi electrical machinery and appliances edition false PLD baseplate||2000/??/??|
|Pin defined file (v9938.acf)||Pine electronic edition (tentative name) for MP3 player baseplate||2000/12/07|
Present as for the specification of V9938.VHD this (v9938.vhd_shiyou.html) (в процессе...)
Version as for past record this (v9938_rireki.htm) (в процессе...)
It leaves the version which can hit I/O from MSX. (For Okoshi electrical machinery and appliances edition false PLD baseplate ver0.2) (as for old version this)
|VHDL Source||nvtop_o.vhd Okoshi electrical machinery and appliances edition top entity||2001/9/18|
|nvtop_m.vhd Pine electrical machinery and appliances edition top entity||2001/9/18|
|nikuvdp.vhd MSX Mapping it does to I/O VHDL||2001/9/18|
|gpc.vhd Core of graphic engine||2001/6/12|
|Built-in RAM component||It is for Leonard. Please modify ram.vhd and name.||2001/6/12|
|Pin defined file (Max+PlusII)||Okoshi electrical machinery and appliances edition||2001/9/11|
|Pine electronic edition||2001/9/18|
|POF File||nvtop_o.pof Okoshi electrical machinery and appliances edition||2001/9/18|
|nvtop_m.pof Pine electronic edition||2001/9/18|
|Demonstration||Test of scroll and the like||2001/6/12|
|The test of the scroll and the like (the ‚Ч - it does, ‚Б corresponding edition)||2001/9/18|
last update. 2000/12/20
The details of V9938
* The merit of V9938
As for V9938 MSX1 (TMS9918) from comparing, like below the point is expanded.
dot, adding the bit map picture of 256 color simultaneous indications
Adding the Kousei small bit map picture of the 512x212 dot with simultaneous display color 16 color /512 color
It reached the point where sprite arranges up to side 8
It reached the point where sprite can acquire color at the line unit
Plural synthesizing sprite, it reached the point where it can do also 2 colors or more to use in 1 line,
Hardware vertical scroll function adds
The block transfer and the like of VRAM hardware by VDP command
So, those where most troublesomely so is are mounting the VDP command. But the beam beam being to use with the popularity game of the title picture and the Ys series etc. of MSX2, we would like to move, is, well.
* V9938VRAM access timing analytical data
Entirely being to be presumption from here, note. If it tries applying ѓЌѓWѓAѓi and the like, also, being more accurate thing to be recognized, it does, but still it has not been popular to there.
V9938 is driven with 21.48MHz. When that clock is designated as standard, when it includes also horizontal retrace line period, per side 1 line it becomes 1368clk. When we assume, that 4clk (with Kousei small mode 2clk) with 1 dot it indicates, it is the period when 1024clk is indicatory.
According to the specification, the lead/read from VRAM of V9938 in the page mode cycle of DRAM, per 1 byte has become 189nsec. As for this exactly being to be time of 4clk minute, as for presumption correctly so is.
But 2 dots you must indicate similarly SCREEN8 where 1 dot is suitable to 1 byte and, with 4clk, with SCREEN7, the access cycle of DRAM becomes all the way all the way to indicating. Then dot indicatory period becomes that time does not cut altogether in the VRAM read-write and the like.
But, it has become that in the specification of V9938 the VRAM read-write is possible at approximately 8 ѓК second period. Because there are also approximately 48 ѓК seconds at the indicatory period of 1024clk, it is not possible, this period all VRAM access failure. How it has become, it is probably will be?
With the buffer of several bytes, it is possible to make entry delay, but lead/read cannot do with the method. Perhaps, with the conception of the opposite, is not to have the FIFO buffer on indicatory side, probably will be? Having the indicatory dot buffer of several byte amounts, it is thought that from the dot of X=0 it starts reading the dot from point in time the left, opens the bus periodically and has spared time in the access of VRAM.
With V9938, it meaning that the fact that it has the necessity to appoint whether the occasion where VRAM access address is set to the register, or the light/write which is led/read it does is puzzle, it does, but when inside has become like this, you can understand. In other words, between 8 ѓК seconds to read-write, stochastically 1 time is the case that the bus of VRAM that tries is opened securely from address set. At that time, if it is to have been about to read reading, if to remember, it is entry, being if it should have executed previous entry, it does.
Because the quantity of the buffer the access of maximum of 6 times is expected between 48 ѓК seconds, if 6 bytes it has, it becomes good thing. Don't you think? it is realistic value.
* V9938 sprite algorithm analytical data
This analysis is simply presumption same as the VRAM access analysis above. But, VRAM access as description above when we assume, that it decided, also the time when it can cut in sprite indication naturally is decided. 1368clk of 1 line they are approximately 63.5 ѓК seconds with as a time. Because among 1024clk those (48 ѓК seconds) it is used for indicating, remaining time is 344clk. In addition to open VRAM at 8 ѓК second period, you must transfer, because, you must take 8 byte VRAM access amount. When with it does, the time when you can use in sprite is the 1368-1024-8x4=312clk=78 byte.
While indicating, because it is not possible, reads sprite pattern, you must prepare the information of priority indicatory pattern and color etc. of sprite during horizontal retrace line period.
First, the worst 32 bytes it is necessary to read in order to inspect whether or not it is on the line which it has been about that the Y-coordinate will indicate from now. X coordinate of the sprite which is judged that among those, the Y-coordinate is on the line, pattern number, pattern (the byte 16 dots =2), it is necessary of color to read 5 byte total. When we assume, that 8 lines it indicates, the 32+5x8=72 byte it is necessary to read. Don't you think? the ‚¤ - it is it is last. When it pulls from 78 bytes, it remains and there are only 6 bytes. It is necessary to execute VDP command at this period don't you think? it is. It does, it is little.. . Of course, also vertical retrace line period being left over, when now the sushi, perhaps there is no VRAM access, time is spared in VDP, don't you think? it is probably will be.
* V9938 sprite algorithm analytical data that 2
After that, while analyzing the internal operation of VDP command, a certain thing was found.
As for V9938 sprite when it TURNS OFF, it was written on also the manual, that VDP command accelerates, it was the fact which is known well. With what is said is among the periods when the sprite table is read, being the kind of mechanism which spares the time when it has been less crowded in VDP command.
As for story changing, you said that 72 bytes it is necessary to read to 8 indicating sprite, but that is the worst case. For example when the Y-coordinate of plainness 0 is 0xD0, because plainness the after the that is not indicated, it is not necessary to read above VRAM that.
As for me, ", the expectation perhaps the effective speed of VDP changes with the method of doing the indication of sprite,", was raised then. However, when it experimented with cooperation of the volunteer, really in state of "sprite ON" is fixed transfer rate it seems always that. With perhaps that you say, in processing of sprite fixed time slot is always allotted.
Perhaps, the processor inside the processing ‚Б ‚Д of sprite executing, doing to reach. . The inner part is deep.