The V9958 is a bad design. No, really.

Рет қаралды 12,948

Күн бұрын

Пікірлер: 106

@steveroberts3512 8 ай бұрын

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....)

@johneygd 8 ай бұрын

That little smart ass just should,ve said part 1 in the title,damnit.

@andyhu9542 7 ай бұрын

Part 2 is now out!

@christkv 8 ай бұрын

Great talk. I always wondered why the MSX2 with the specs it had seemed to always underperform compared to its "official" specs.

@mirabilis 8 ай бұрын

Thank you for using the correct SI prefix, kibi. ❤

@XenonG 8 ай бұрын

We would have never needed to use Kibi/Mibi/Gibi if it wasn't for those damn hard drive vendors!!!

@mirabilis 8 ай бұрын

@@XenonG perhaps, but kilo should always be 1000 if you ask me. That being said, I say megabyte to avoid confusion among my peers.

@Mordecrox 8 ай бұрын

@@XenonGand for that alone I'll go out of my way to not use kibi until my last breath.

@timwilliscroft9615 8 ай бұрын

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.)

@GodmanchesterGoblin 8 ай бұрын

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.

@andyhu9542 8 ай бұрын

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.

@GodmanchesterGoblin 8 ай бұрын

@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.

@emanuellandeholm5657 8 ай бұрын

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...

@andyhu9542 8 ай бұрын

Are you planning to make an emulator that runs on the PC?

@emanuellandeholm5657 8 ай бұрын

@@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

@Xsiondu 8 ай бұрын

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.

@timhorton6502 5 ай бұрын

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.

@static-san 8 ай бұрын

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.

@dan_loup 8 ай бұрын

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.

@andyhu9542 8 ай бұрын

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!)

@Steckschwein 8 ай бұрын

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.

@lennartbenschop656 8 ай бұрын

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.

@Steckschwein 8 ай бұрын

@@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.

@andyhu9542 8 ай бұрын

@@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.

@andyhu9542 8 ай бұрын

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).

@railsrust Ай бұрын

I feel like the V9958 is an excellent chip if you understand what it's good at, and what it's not. It clearly needs more cpu grunt to really take advantage of it than a 3.58Mhz Z80 if you're working on a modern project. I've been wanting to use it with a 4-8Mhz 65C02 or 65C816 in a homebrew project, and see what it could do for a few years. I've had various thoughts on to handle things. The nice thing about the 65XX chips is that they have really tight memory access times, so this could help things or hurt things depending on your view. Depending on what you're doing, it can run circles around faster clocked chips of the time at the cost of programming, so you have to treat it like an early version of a RISC chip and be efficient. I was thinking of the possibility of using a single 1K dual port ram in conjunction with standard main ram, or even using some logic to handle ram access. Possibly even have it where the CPU accesses things only on clocks the VDP does not. I do know from reading that the V9958 apparently DOES NOT like the block transfer operation of the 65C816, so a direct access to the ram would be really nice. And talking about weird to program for, the 65C816 will really shake things up here. Throw in a YM2203 and a DAC and it could be an interesting little project. I had thought of potentially using one or two FIFOs in it, and use a clone of the Disney Sound Source for PCM audio. An alternative would be a YM2413 instead, but I was trying to keep some little bit of distance from the MSX. There's quite a few possibilities here, each with their own tradeoffs. I've had time to think about things, so we'll see what happens. Still haven't actually started it yet.

@chrismcovell 8 ай бұрын

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.

@andyhu9542 8 ай бұрын

Can you send me a link to that interview? I am very interested.

@SianaGearz 8 ай бұрын

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 ...

@andyhu9542 8 ай бұрын

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.

@SianaGearz 8 ай бұрын

@@andyhu9542 Probe's Savage on Speccy was probably a horrible idea to anyone with taste.

@OGmolton1 8 ай бұрын

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

@cesvlc5211 14 күн бұрын

While I agree that V9938/V9958 are a missed opportunity in what they could have been if their design was cleaner, however they are still my favourite choice when I choose what graphics feature set to use in retro development projects. Look: the X68000 has a really weird square resolution, and besides it has lots of features very hard to master. The HAM mode in the Amiga is a dirty hack that I never enjoy programming for. The NES has a very limited color palette. In the end, the V9938/V9958 offer exactly what I want, and no other chips from the era come close. Even the later V9990 got it wrong by not supporting sprites it bitmap modes (it supports them in pattern modes only). I know the V9938/V9958 have sad limitations, but they are the vintage graphics with the best feature set. No other chips got it better (they were faster, but their features were poorer or even dirtier to program).

@cesvlc5211 14 күн бұрын

Ah, and I forgot: the Atari ST has no hardware sprites (yes, its blitter is fast enough for emulating them, but you don’t get hardware sprites). In the end, it’s like I said: the V9938/V9958 end up being the ones with the best feature set from that era. No matter what you try, the answer is always the same: they are the only choice (unless you sacrifice features for performance…. but then, if what you want is performance, why go retro when you get TFLOPs of performance with modern GPUs?)

@timhorton6502 8 ай бұрын

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.

@andyhu9542 8 ай бұрын

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.

@timhorton6502 8 ай бұрын

@@andyhu9542 theit RGB outputs are extwrnally multiplexed and their color busses are linked

@timhorton6502 8 ай бұрын

@@andyhu9542 Their color busses are externally multiplexed but their color busses are also connected.

@espfusion 8 ай бұрын

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.

@justinmijnbuis 8 ай бұрын

Can the speed problem be mitigated by using dual-port VRAM (if that is still available) aka direct CPU access to VRAM?

@Mueller3D 8 ай бұрын

Sure, but if you want more performance and are using more advanced hardware, why not use something like Matthew Hagerty's F18A ?

@justinmijnbuis 8 ай бұрын

@@Mueller3D FPGA's are not period-correct ;-)

@andyhu9542 8 ай бұрын

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.

@andyhu9542 8 ай бұрын

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.

@Mueller3D 8 ай бұрын

You'd want to use true dual-ported RAM, not VRAM. It's typically SRAM, so you'd need to unmultiplex the address lines.

@richardtwyning 8 ай бұрын

I thought so, the Geneve uses the 9938 because it has to maintain compatibility with the TMS9918A/TMS9929

@Michael-it6gb 7 ай бұрын

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.

@andyhu9542 7 ай бұрын

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!)

@AppliedCryogenics 18 күн бұрын

I try to cut my V9958 some slack because of it's age... but it is starting to get on my nerves! On my 3.57MHz bus-clock system, I have to insert TWELVE NOPS after each pixel write in GRAPHIC7 or in YJK modes. So drawing a full 256x212xYJK frame takes like 0.5 seconds. I'm starting to consider using a Pi Pico 2 for video in my project.