The V9958 is a bad design. No, really.
Vložit
- čas přidán 21. 02. 2024
- As I design the HEC, I have to work with the V9958 VDP from Yamaha. This video is the culmination of me getting increasingly frustrated with the quirks of this chip. It is an ingenious design yet bogged down by several key design decisions.
What are your thoughts on this chip? Have you got any experience programming for it? Please leave the ideas in the comment section below. - Věda a technologie
I was really pleased when you said that there is going to be a part 2, as at that time I was thinking that I would have liked a longer video!! I an considering using this chip in one of my own designs in the future so this is very interesting for me . Please continue - you remind me of the enthusiasm I had looking at data sheets when I was very young, designing hardware as a schoolchild in the early 80's dreaming of building systems that I never could realise because of the cost. Now that I'm retiring I will have the time to do this!!!!!! (better late than never....)
That little smart ass just should,ve said part 1 in the title,damnit.
Part 2 is now out!
Great talk. I always wondered why the MSX2 with the specs it had seemed to always underperform compared to its "official" specs.
Thank you for using the correct SI prefix, kibi. ❤
We would have never needed to use Kibi/Mibi/Gibi if it wasn't for those damn hard drive vendors!!!
@@XenonG perhaps, but kilo should always be 1000 if you ask me. That being said, I say megabyte to avoid confusion among my peers.
@@XenonGand for that alone I'll go out of my way to not use kibi until my last breath.
As a kid, I used to program the 9918A back in the day. It was frustratingly limited, compared to a C64. The 9958, when I heard about later MSX hardware, seemed so much better... but thanks for pointing out its (dire) limitations. Sadly, the 9918A was not the most awful graphics hardware I ever programmed, but as you rightly point out, insufficient bandwidth from CPU to the VRAM is a killer. (Worse was to come for me with, doing graphics on custom hardware in the 2000's.)
I love your channel. 90 percent of it is way over my head but you explain your reasoning so well I am able to appreciate what you are sharing and then i go and look at examples of what you talk about and i see what you were describing. Thank you again for your work.
Hello again Andy, I'm having trouble with the output ciecuitry on my V9958 video card and I need your help. Do you think you could give me the necessary commands needed to get some form of video output from the V9958 (that isn't just a blank screen)? I need this instruction sequence to be very robust and idiot-proof as I have no way of knowing if my video signal circuitry works.
This was fascinating, thank you. Comparing DRAM driver specs to DRAM chip timings... Maybe it's a lifestyle choice... Been there quite a bit, especially in the 1980's. But this chip certainly pushed the limits of what was possible at the time. There was a short lived chip in the mid-80s that had even greater capabilities than the 9958 - that was the 82716 (from Intel and Matra-Harris) which supported sprites and multiple planes with text and bit-map modes concurrently, but it disappeared before being widely used. It also used standard 4-bit wide DRAMs, but it was neither MSX nor TMS9918 compatible, and the PC market was already on the verge of moving to VGA.
There are always new graphics chips out there that I don't know it seems. No matter how many I do know. The 82716 is tightly integrated into the 8086 lineup, however (multiplexed address and data lines). Using it on a Z80 would be hard.
@andyhu9542 Using it on a non-multiplexed bus is not too bad - it's how I used it back in 1987 / 88. But yes, it was obviously designed for x86. The Intel 82786, which came along a little later, was a much better chip but was aimed at serious workstation graphics applications with features and a price to match.
I was already subbed!
The funny thing is I was just daydreaming of creating a virtual (software emulated) MOS 6510 paired with a custom video chip a bit like the V9958. With chunky pixels and maybe some kind of primitive blitter. I even scribbled down a few pages of notes on geometry, DMA, memory banking and timings.
Then this video was randomly suggested to me, and I now think I should definitely design my video chip to do some kind of tiling. And make it super easy to program in 6510 assembler. The algorithm is kind of scary sometimes...
Are you planning to make an emulator that runs on the PC?
@@andyhu9542 Yes. Using something like Unity or SDL. Maybe Vulkan? I'll prototype in Python and then switch to C++ for performance. I will probably do development in Linux.
And I've been thinking about this some more. Maybe two or three tiling engines working in parallel, using their own RAM, plus some kind of sprite engine. As well as a way for the 6510 to shuffle data, one byte per cycle, to these virtual co-processors off screen.
I used to program the MOS 6510 to do video tricks on my C64 as a kid. I also did some stuff on the Amiga, but the 8 bit stuff was more fun! :D
Always a great video, good work!
Can the speed problem be mitigated by using dual-port VRAM (if that is still available) aka direct CPU access to VRAM?
Sure, but if you want more performance and are using more advanced hardware, why not use something like Matthew Hagerty's F18A ?
@@Mueller3D FPGA's are not period-correct ;-)
If you look at the datasheet for actual 'VRAM' (like, TMS4161, not GDDR stuff), you will find that the read port is a big shift register. It's designed for bitmap only (which, the V9958 happens to lean heavily upon, but the command engine also needs random access). It would be an engineering nightmare to implement 2 devices accessing 2 different ports, one being a non-standard serial port. The V9990, however, does use VRAM as far as I know (I haven't seen a real board), but it still uses an address port +data port design for VRAM access.
Also, VRAM access via VDP can sometimes be more efficient (given fast enough VRAM) with things like LMMC allowing you to transfer data to a 2D region without calculating the address using CPU time.
You'd want to use true dual-ported RAM, not VRAM. It's typically SRAM, so you'd need to unmultiplex the address lines.
I like to try new things in V9958 and I agree with you.
Cool video. We got so much more out of hardware when everything had to be a hacky barely possible solution. Today my ryzen 4gHz 8-core cpu computer hangs at the cursor all the time in windows. It's nice we dont have to mess with hardware like the V9958 but dang we got lazy. I agree limitation breeds creativity
I programmed the TMS9918, V9938 and the V9958 for the MSX.
The first was pretty good for its time, the V9938 was almost a good chip too, the lack of proper hw horizontal scrolling was its biggest key down, the lack of blitter power 2nd. The 256 'screen8' mode was cool, but already limited by the blitter AND the sprite engine. Breaker is perhaps the nicest looking 'screen8' action game. A proper new tile mode would have been a real game changer indeed, even if supported just 16 colors without further limitations. A 256 color tile-mode could have been a killer-feature.
The V9958 was indeed severely hindered by the lack of increased blitter power. The high color modes were just photo modes, there was no 'power' to support it. So it effectively was a V9938 with proper horizontal scrolling, but years too late. The cancelled V9978 should have been the V9958 at that point in time.
There is an improper way to do horizontal scrolling on the 9938, but it's quite jank and has a pretty easy to recognize visual defect.
@@dan_loup Yes, you can use the horizontal offset-registers to scroll max 16 pixels in hw; giving you X frames to do blitter-copies (depending on required scroll-speed). The location-'jank' can be masked with sprites, but then you'll use up some sprite-quota :)
I've done that to create smooth pixel-perfect 8-way scrolling, but you're left with hardly any blitter-capacity (assuming 1 or 2 pixel scrolls) to do other copies/writes if you try doing it for the full vertical resolution. EIther you gotta go 25/30fps or use max 160px vertically to have decent headroom. Or use SCREEN 4.
It's quite arguable the "no tiles" point. Screen 4 is pretty capable with it's 16 colors per tile (but only 2 per line), and depending on your art style, you can pull pretty impressive graphics on it.
Space manbow is entirely made in screen 4 and almost look like a sega genesis game.
On the other hand, if a genesis game looks like Space Manbow, I would consider it a poorly written genesis game (minimal parallax scrolling, 16 colors on screen, small sprites and not a lot of them). I would argue that Screen 4 is more master system than genesis (16 color tile and sprites, single scrolling plane), but a bit weaker since the 2-color-per-line limit and palette sharing between tile and sprites (less colors on screen than an NES!)
I thought so, the Geneve uses the 9938 because it has to maintain compatibility with the TMS9918A/TMS9929
I happen to be working on a GPU based on two V9958s, please let me know if you have any ideas as to how I could fix some of these issues in hardware.
Are you chaining them using the transparency feature? Then I think you already avoided a bunch of them. Graphics 3 on top of Graphics 4 or even 7 can make some impressive parallax effects for platforming games. The RGB signals can be multiplexed externally, and you get double the number of colors. And double sprites, too, with 32 in front of the top plane and 32 behind. Plus, you get effectively double VRAM bandwidth as you can do something clever like writing to two V9958s alternately.
@@andyhu9542 theit RGB outputs are extwrnally multiplexed and their color busses are linked
@@andyhu9542 Their color busses are externally multiplexed but their color busses are also connected.
Whilst I never had the fortune of programming on an MSX, I did have a TI-99/4a and did lots of programming on it. The 9918 was badly under-used on the '4a, at least outside some of the games (such as Parsec, which I think a lot people don't realize used Graphics 2). I've read up on the 9938/9958 a few times and looking back I would've loved to have done things on them in their era.
From what I understand, the 9958 was still basically an upgraded 9918. So Yamaha missed a few opportunities: it could've had a version that supported faster memory, but that could've been expensive for implementers; it also could've had more innovative graphics modes, like the tiles of the NES and SNES. But at that point of the industry, people were aiming for 256-colour bitmap modes, instead of innovating on the character/tile modes that were so much more bandwidth efficient.
I always thought that the Amstrad CPC+ line had also a blitter chip (ASIC).
Nope, it doesn't. But it does have better colors and hardware sprites.
You think people remember what type of CPU people had in their computer back in the 1980s? I can barely remember what I had 10 years ago.
I talked to a lot of people who do remember their CPU back then. I think it's because there were only a few types that were widely used (6502, z80, 8080, 6809) and they were very different from each other. Meanwhile, CPUs from 10 years ago are mostly compatible and similar in performance. (Not a lot of people can tell Athlon from Phenom from Pentium to Core!)
I couldn't agree with you more. The 9938/9958 were technologically several years behind the curve, and even the Yamaha engineers admitted in an interview that they had been beginners at home computer/video game console-style graphics chip design. I love some of the distinctive 'look' of MSX2(+) games but the video chip was almost the worst of every world: can't do tiles, has a blitter but can't do fast 2D; OK then, fast 3D? Nope, too.
Can you send me a link to that interview? I am very interested.
I have only limited experience with the V9958: my custom 6809 board used one. The indirect VRAM access was certainly the biggest pain. I chose the part because it has a 80 column text mode. Scrolling was a killer; a real dog. I had to implement scrolling in half screen increments.
Still, I quite liked programming it. But I never did anything particularly clever.
I saw a V9938/V9958 add-on for a Tandy Coco/Dragon at a meetup, it runs ported MSX1 games. Is that your project?
@@andyhu9542 Google is horrendous for removing comments now.
Not mine. MAXI09 is mine. Your favourite search engine.
Wow it even deleted my comment that moaned about comments being deleted. Holy sh1t.
MAXI09 is me
It's long been claimed that ASCII straight up didn't care about games which is why they did a chip with proper vertical scrolling only (for console output)... and that more subtle things like the sprite enhancements were snuck past them by the designers.
A more enhanced pattern mode would have been nice for sure, not to mention less lazy blitter timings.
MSX may not be as elegant as a C64, but it sure beats the CPC and the ZX Spectrum. Please it's an old home computer, its place is entirely different from game consoles.
But yeah one always wishes it was better doesn't one ...
If I want to nitpick (I don't), I can compare games like Chase H.Q. on ZX Spectrum and MSX (which would be unfair as the MSX version is a lazy port, BUT I've seen demos of people trying racing game on the MSX2 and the result isn't good) and say that even MSX2 is not good at games that require a lot of CPU rendering. The fair comparison in my opinion would be that the feature of Spectrum games is that they are dynamic, with a lot of stuff flying around a low-res screen with blocky colors. On the other hand, MSX feels static with a lot of beautiful colors (not only in YJK/YAE modes, 16 colors out of 512 on a 256 x 212 screen looks good). the CPC strikes a good balance between the two but is bogged down by the lack of hardware sprites (until the plus range) and low resolution for its 16-color mode.
@@andyhu9542 Probe's Savage on Speccy was probably a horrible idea to anyone with taste.
I made a homebrew v9958 video card once. I never bothered to use anything other than G4 mode and the text modes. I made a subroutine to copy fonts to the screen in G4 mode to try to make a pseudo color text mode but that was kind of slow. I plan to try using the v9958 graphics card on my 486 homebrew computer if I ever get it working well enough for that.
What's especially annoying about this chip is that it's hard to make it output a vga signal that works with normal monitors without some kind of adapter so I don't recommend it as a hobbiest chip. You can build a better version of Ben Eaters "worlds worst video card" for less than the ebay price of a single v9958.
I do wonder what chipset you are planning to use for your 486? I wanted to make one but couldn't find a source for my chipset.
@@andyhu9542It's better to make your own chipset. I'm using an ICE40 fpga.
@@andyhu9542 It's better to make your own chipset with an fpga.
@@scotts-tech That's going to be some work, but is a good solution.
Hey, Andy. No fucking idea about the chip. This is the first I'm hearing of it. But it does sound terrible to work with when you describe it. I trust your judgement.
If building a new retro inspired 8 bit computer with this chip you could use dual ported ram for bypassing the cpu to vram bandwidth bottleneck
I was thinking the same thing, but I am sure there will be a lot of timing issues. Also, 128k dual port ram will be costly. Still worth a try.
The timing design will be hard. Especially converting those alternating CAS signals to something dual-port RAM compatible (they usually use SRAM timing).
I think the ASCII V9938/V9958 was hampered by the slow hardware around it.
I have some doubts around that. The V9938/9958 is highly integrated and sits on the bus as a black box. It doesn't require a lot of external support hardware either. There's not much to hamper it, honestly.
I didn't know it was so weak, I thought adding scrolling to castlevania would be fairly easy. A few games really do look better than mostl amiga games.
Castlevania has received some pretty extreme patches (like, turning the entire game into its NES counterpart, btw, the game is called Vampire Killer on MSX, I might have made a mistake somewhere in the video). But no smooth scrolling yet. I think the difficulty is that the game design is kind of tied to the room system, if smooth scrolling is introduced, some game flow may need to be rewritten (I haven't personally tried to patch the game, so I can't say for sure).
I know this is for a computer but It was so much more interesting back when each console used it's own custom chips. Nowadays consoles are just stripped down PCs. There is no mystery or amazement when a new console comes out because the latest PC GPU is already going to be more powerful. Back when N64 launched now that was amazing. There wasn't anything like Mario 64 on PC. In 1996 the best PCs had was stuff like Quake,Diablo,Tomb Raider and Descent II. Somewhat decent graphics in those games but not as good as Mario 64. Even with the Dreamcast when Shenmue came out in 2000 as far as I know there wasn't a game that looked that good on the PC. We already pretty much know what the PS6 and Nextbox graphics will look like. Take the most powerful GPU thats on the market now and something similar will be in the next consoles in the next couple years. The games will look slightly better.
Yes, agreed, sadly.
Awesome (and pretty funny) video... but how can say mean things about bit planes? C2P algorithms makes the Amiga (and the ST, I guess) so much more fun than straightforward chunky graphics (please note, this is sarcasm). That said, the challenges with chunky display high color, high-res modes in an era of 150ns (250ns+ full cycle time) memory is precisely why the vast majority of mid 80's chipsets used bit planes (simpler distribution of planes across physical memory and interleaved access). By the early 90's we had ever faster VGA/SVGA hardware wired to ever larger and faster dedicated framebuffers that made chunky no big deal. But in the mid 80's, every chipset was trying to figure out how to maximize bandwidth, minimize latency, squeeze maximum color palette options (e.g. not bound to powers of 2) using less memory and, through things like display list processes (e.g. copper lists) provide programmers with options on display manipulation with some programmable concurrency... all because full cycle time was brutally slow. Planar was the way to go at that time (hell, even EGA was planar, and VGA has well publicized planar modes).
Frankly, that makes the V9958 really interesting, because they basically were just way ahead of the curve. It's a bad design because, like a lot of "out-of-sync" hardware, the engineers took the "they'll figure it out" approach (the "they" in this case being programmers). It's the same reason I hated the Cell processor in the PS3 - theoretically amazing, but practically a really stupid design that ignored certain realities. Namely writing a distributed pipeline of highly optimized SIMD code as shader-like pseudo threads on the Cell's SPE's, making that code entirely non-portable, was just asinine in the extreme. In the real world, nobody wants the hassle of ego-engineered hardware. But retro computing isn't about the real world, so things that likely looked incredibly obnoxious at the time, now look like fun hacking challenges.
Yes, and I totally agree with you! But I also want to point out that there are people (me included) programming for retro hardware looking for more than fun hacking challenges. I'm planning for a shooter game on the MSX, and I really want a tile mode sometimes.
C64 uses chunky. Which 68k based or 8 bit computer used interleave? EGA did use it on an 8bit databus. At least page 99 in the manual very much looks like interleave.
@@ArneChristianRosenfeldt Almost all 68k home micros are interleave... The Amiga is a textbook example of interleaved (planar) graphics, the ST has a hybrid of chunky and interleaved pixels. A lot of 8-bit home micros of the time uses essentially 1-bit bitmap with tricks (for example, ZX spectrum). The NES is interleaved in its tile and sprite graphics design.
@@andyhu9542 there are two kinds of interleave. The EGA card interleaves the memory chips, while Atari interleaves the 68k and the shifter.
@@ArneChristianRosenfeldt Oh, I didn't realize that. I thought it just means planar graphics.
Uhm, your calculations are not accurate. copying a 512x212 block from one page to another in G6 takes about 1 second in logical move. That is the VDP carry out the following access for 512x212 pixels = 108544 pixels:
- 1) Read a byte from source
- 2) Read a byte on destination
- 3) (Perform a logical operation so no I/O) access
- 4) write a byte on destination
So three byte accesses for every pixels. Because the VDP is not optimized to avoid a double I/O for adjacent pixels when processing in 16 color mode, two adjacent pixels this operation is performed two times, in other words the vdp accesses the same byte even if it has just accessed before. So what number of accesses do the vdp in the above example?
108544*3 i/o accesses =325632 i/o about 318 Kb/s.
In byte mode the number of accesses is rougly 170Kb /s of data mode, but because to copy a byte you need two I/O operation the memory access speed is something in the ballpark of 340Kb/s
the problem with cmd engine is not vram speed. on VBLANK there are plenty of slot available because no screen redrawing, no sprites. Unfortunately the vdp cannot make use of those accesses because it's internal state machine is extremely slow at performing internal operations required for command processing such incrementing source and destination coordinates, decrementing counters and check if they reach zero and so one. So while those operations are in progress, a number of possible data access slots is wasted because no I/O access in done.
This is proved by the fact that both blitter and cpu share the same time slot, so teoretically if one is doing a byte move operation through blitter and at the same data output data at maximum speed via CPU, the blitter should slow down because cpu has priority over the blitter. this effectively happens, but it is negligible on a copy command because the internal operations leave enough time slot to perform cpu accesses while the blitter I/O is idle.
things change a lot if the command is a byte fill command. why? simple, because this command does require less internal time used to increment internal register values the I/O blitter accesses are more frequent, so they are more stopped if the cpu is writing data . In this case the blitter speed decrease a lot
Very detailed calculation! One thing that I wonder is that the command engine may not be a state machine, but an CPU running internal ROM code. Because 1, in the block diagram in the official document, it is called a CPU. 2, there are just too many cycles, and too big difference between different types of instructions. This is just my intuition, but I think a hardware-based state machine would work faster and be more consistent. The cycle count feels like there is code being run behind the scenes.
@@andyhu9542 It could be.. My idea of state machine is only speculation. It would be interesting, if there is CPU executing ROM code, to hack this to get more speed reducing cycle count, but, it is not feasible...
@@gasparinizuzzurro6306 I mean, if Yamaha let that CPU to fetch code from VRAM, we would have a coprocessor synchronized to the dot clock that will do beam racing stuff for us. That's my dream.
@@andyhu9542 unfortunately.... a dream.Yamaha lost a lot of opportunities some very easy to implement, like a interrupt on command execution terminated, It was very easy to achieve, there is a status bit that goes from low to high or viceversa (i do not remember) to indicate "vdp busy in command execution". Should be easy to link to the bit value transition the action of triggering an interrupt. 😞
@3:00 so they invented DDR without knowing it? :D
Sort of. The issue is that the definition of DDR (sampling data on both rising and falling edge of the clock) requires a clock signal sent to the DRAM chips. The CAS signal is not a clock signal. But they did 'Double' the 'Data Rate' without doubling the bus width, so...
你好！你的英语很好。
Maybe do a video too where you just roast a keyboard that is a "poor" design... Right? Do that next.
What do you mean by that?
What a shame the MSX was, I would have been much better with an Amiga or even a Spectrum :/
XD ohh no you angered all 1.6 people that are fans kf those system
You say that vdp chip is bad but you say that it is still a great chip,then is it really that bad as you do claim in the title? No, you just fakingly make that up,by just saying that it uses slow Dram,and whether it is true or not,it’s not that bad as it sounds like,dang it,
Well how about talking about the idyssey 2 because that system is really bad,why? Because not per se for it’s low specs but for it’s graphical restrictiions for both sprites and backgrounds,because you can only use it’s builtin tile sets for creating your own backgrounds and sprites,that’s absolutely unforgivingly BULLSHUT☹️
It is great to an engineer, but terrible for a programmer. There are many examples for this. Ask an engineer about the Space Shuttle and the engineer will tell you that the aerodynamics is great. Ask a pilot and the pilot will say that the Shuttle flies like a brick.
The Odyssey 2 launched in 1978 and the only competition is Atari VCS. Comparing the specs of the two, you would realize that the Odyssey 2 is fairly competitive. The MSX2 launched in 1985 against machines like the Famicom/NES and Master System, and those two often beat the MSX in terms of graphics performance. I didn't look at the datasheet, see DRAM and start ranting from there. I played the games, found them underwhelming (comparing to what the specs suggest) and started looking for root causes.
Well than it is the same problem with both the sega saturn,N64,ps2 and ps3,they are great systems but they are hard to program for🤣
go away, You and Your z80 clickbait
The V9958 is still the best still available video chip if you are out to design a retro homebrew computer using "period correct" chips. When we started our project "Steckschwein", we used the TMS9929 (european version of the TMS9918) first, which was an impressive chip for it's time.
Later, we upgraded to the V9958, as the specs do look rather impressive, and we were kind of expecting it to be a great deal faster than the 9929. What was really disappointing was to discover that the V9958 can't do multi colored sprites. Something the VIC-II could do in 1982.
So, the V9958 really is a capable chip, but with certain serious drawbacks. I do enjoy the 80 col text mode though.
I think the best video chips for 8-bit retrocomputers are the 32-bit microcontrollers like ESP32 and RP2040 that can generate video signals in software. AgonLight uses an eZ80 with 512kB RAM as its main CPU and an ESP32 as its graphics chip. Only problem with the design was poor bandwidth, limited by a 1.15Mbps max. UART. This is 115k bytes/sec. I thought this was an order of magnitude slower than MSX could do, but MSX limits transfer rate to just 125kbytes/sec.... But the ESP32 in Agon can do lots and lots of high-level commands internally, such as line drawing, scrolling, bitmap blitting etc. And you can cook up your own novel modes and commands as the ESP32 is a fully programmable device. Another recent retrocomputer is the Neo6502, where an RP2040 (with the help of some buffer chips) emulates RAM and all devices for a 6502. The 65c02 can run at up to 6.25MHz. The RP2040 is basically the only thing the 65c02 communicates with. the RP2040 generates DVI video and can also drive an SD-card and USB.
@@lennartbenschop656Yep, if you want your homebrew to have some more graphics power and a modern video output, rolling your own using a capable µC or an FPGA would be the way to go.
With the Steckschwein, we are trying to use more or less "period correct" components, so the V9958 is one of the better options of what's available, if not the best.
@@lennartbenschop656 It's not only the bandwidth. The data sent on those serial lines are not graphics data, but BASIC commands encoded in text. The problem is that the entire program could also be sent over to the ESP32 and run much faster. And the question becomes a massive 'WHY', since the eZ80 side can be entirely discarded and the whole thing would probably be faster.
Agreed. The V9958 is also the chip of choice for the HEC project, too. However, I'm planning to do something to make the chip less painful to interact with (for example, add a simple DMA to it using some TTL gates).