Just popping in to say I recently acquired a dumb Terminal and inside was the SCN2674 driving it all, and googling the chip to try and find schematics your video was the first thing to pop up again.
It's funny that - the SCN2674 videos were very popular for some reason, I'm not sure why as it is an obsolete part that's no longer in manufacture, and wasn't even very significant in its day compared to something like the 6845 which seems to have been much more common! Still something clicked with them and I guess Google likes these videos!
Haha yes, sorry not to show any image at all, I did warn at the start though that that would be the case! Really this chip is all about timing though, not image generation - the image generation is going to look pretty similar to in my other videos. And create all the same problems - amount of RAM needed, access speed, etc.
Yes, it's surprisingly capable and cheap, and it has a great sample rate as well. Given what I later discovered about the vsync, it's possible it would have been able to sample it as well if the circuit was actually working.
Thanks for this! The chip looks very interesting. I'm building a 65C816 system and I have a 68B45 on order. My goal is 800x600 resolution and your SCN2674 looks very interesting. I may order one. By the way, I currently use a ATF22V10C to stretch my clock for slower peripherals (such as a PCF8584 for I2C and a NHD0440 display).
Nice, yes I think this is capable of about double the character rate of the 6845, though I don't know the specific figure for the 6845. You can always squeeze more pixels in horizontally by just using longer shift registers - you'll need at least 10 pixels per clock - the problem is more that features of this chip like hardware scrolling and split screens will have worse horizontal granularity. You can add your own adders of course to fix that but you start to lose the benefit of the monolithic IC. Vertically, though I didn't mention it, this chip has a "graphics" mode where the repeated scanlines actually keep counting up through memory addresses, so you cover a lot more addresses contiguously. One thing I don't think it supports is a custom stride. If you're interested in whether a specific combination of register values works then let me know and I might be able to try it, if I have the right oscillator handy.
@@GeorgeFoot Thanks for the offer. I found the SCN2674 on Jameco for $5. I'm going to order and compare them to the 68B45. I had a 6845 (not the 'B' version) working with a 1Mhz 6800 back in 1980, but I've forgotten more than I remember. Had it working at 80 chars by 50 lines on a surplus word processing monitor. It's a shame I can't use the GD6410 ($11 on Jameco). It's a 5V part but that QFP-160 pin package is a bit beyond my skills. PLCC-84 Through Hole seems to be my current limit. Let me know if you need help with using the atf22v10c for 'glue' logic. They seem to work fine for me now that I have some experience with them. The TL866II Plus programs them just fine. WinCupl is rather finicky though. And I'm starting to gain some experience with the ATF1508.
I wouldn't be too afraid of QFP soldering, you can buy some cheap chips and practice boards and get the hang of it in the end - then solder the real thing into an adapter board. Another option is to try to find it with J-leads then maybe you can solder a through hole socket to put it in. I have a pretty good setup for programming the 22V10s etc - I stopped using WinCupl and found command line for running the compiler and simulator so I can automate that better, and it was a much smoother experience after that. ATF1508 looks nice - I got an ATF1500 before realising it wouldn't work with the TL866.
Nice video, one point, 5v rail decoupling capacitors on the video board ! In the 70s people were paranoid about crowbaring supply rails so one per chip became common, in the 80s people relaxed and used less.
Great video, I'm think about using it's BIIGGG brother the SCC63484C8A68 which I scavenge from some sort of old terminal computer. This is by far the most ridiculously large DIP chip I've ever seen
It looks like the longest part number I've ever seen too! Maybe it integrates more of the support chips, like the character generator and attribute/colour processor
I am writing a code for this baby as it is used by a retro machine I'm playing with called Iskra Delta Partner. Thx for this video, I really learned a lot from it. Hope you make part II.
Great, it'll be good to hear how that goes! I was just experimenting with actual video output, having trouble getting crisp pixels at the moment though, hopefully I'll find a solution soon
My hardware is this (see the link below). I'm a software guy so I have troubles understanding it. But I do understand that it combines graphical card Thomson EF with an SCN - unconventionally gluing outputs of two cards together. The SCN part has its own SCB chip to generate attributes and its own logic to generate characters. Maybe you can get some info from it for your project. drive.google.com/file/d/1OSoaMkrv7T39G1Ct_5qzWgFxN8izR2_x/view This is an actual graphical card from 1983. I'm currently trying to find out how I can produce custom graphics. I can see an EPROM (characters, I guess?) and static RAM chips both connected to the SCB chip sharing the bus so my uneducated guess is that characters must be loaded to static RAM somehow and there is something that overrides EPROM to leave control over the bus to the static RAM. But still guessing. This is officially a text only card. But legend says that custom graphics can be done on this hardware, but no docs, no one to ask an no one has ever done it. :)
Cool, I'll check it out. Meanwhile here's a collection of datasheets for various Signetics parts that might be used together in that application. It also includes suggestions of how they could be combined, which your manufacturer may or may not have followed! www.bitsavers.org/components/signetics/_dataBooks/1986_Signetics_Microprocessor.pdf I'm going to get text output working next, I'm halfway through that right now. Generally the SCN produces addresses (one per character) that you feed into a RAM's address pins to read an ASCII value per character. Then that value is shifted left a few bits and combined with a row count from the SCN2674 to get an address to look up in character memory (ROM or RAM) that contains e.g. 8 bytes per character with each byte defining the lit pixels for one row of that character. That then goes to a shift register to display the pixels one by one on the screen. Other ICs that may be involved could be reading colour/background data (character attributes) and combining that with the character generator's output; adding cursors, underline, etc; and double height or width processing which are all sorted by the SCN2674 but subject to the rest of the circuit knowing what to do with them.
The VSYNC width field isn't in a weird order: it's using Gray codes by the looks of it. There's probably some good reason to do with the chip's internals as to why they're used here.
Nothing nearly as ambitious as this project, but I implemented the ACM CORE graphics standard from a book with pseudo code in College, and I remember the challenges of coding to the card with the VGA hardware after the relative EASE of CGA and EGA coding. Yeah it looks odd, but it actually makes pretty good sense once you take a look at it.
Another great video, thanks for sharing! One thing I can’t understand is why, with the abundance of retro CPUs and peripherals still being manufactured, video chips are not one of them. Sure, I know you could use FPGA, or depend on eBay/AliExpress, but in my designs I try to avoid those…
Yes, this one is recycled for sure, it has solder tinning on the pins. I wonder if one reason is that the video signals these were designed for are so obsolete, and useless without the right display hardware. The TMS9918 is essentially SDTV only; this one here is barely capable of the horizontal sync needed for VGA. I guess the next level up that's is EGA or VGA (which were custom ASICs). The trouble with SDTV is the horizontal sync rate being low (about 15kHz) which modern monitors don't necessarily support. There were too many standards and too many connector types. SCART is great but never existed in North America. And all these things are less and less supported on modern TVs. Who knows how long they be around now. 🙁 So there probably is a lack of demand for the authentic through-hole ICs of the day due to modern display hardware limitations; and on the other hand, the 31kHz "HD" schemes like VGA and up were never available in this form factor, they've always been SMD ASICs. Bearing that in mind then, the most authentic answer probably is in fact to use an FPGA after all! Or roll your own solution from more parts, which I certainly enjoy doing. The EEPROM sync approach is the most compact I've found. I have another design using your ATF22V10 PLDs but it still needs separate counters to be useful, so ends up a little bit more complex than the EEPROM approach. I also had a design using tons of downcounters that was logical and I liked it a lot, but that's about twice as many ICs again. It's great how many options there are though and they all work well except using upcounters and logic gates which is a nightmare!
I've actually got one of these on order, along with some 64kx4bit 15ns RAM and a suitable crystal for outputting a PAL signal. It'll be interesting seeing how it handles VGA.
Great - it should be good for PAL. What speed is your crystal? I think you want 13.5MHz for 640x512. I used a 27MHz crystal divided by two for that in another circuit. The exact pixel clock didn't matter much in the analog days, and the BBC Micro used 16MHz, but modern TVs don't like that so much.
@@GeorgeFoot It's a 17.734 Mhz crystal, to be divided by 4 to give me 4.433 Mhz. My homebrew design is built around the Hd63c09 and it only gets to be tinkered with here and there when time allows. It'll be good to finally connect it to a display.
Great video! I liked the how you analyzed why the VSYNC doesn't work and a good reminder that unused input pins need to be tied to either high or low. I would love to see some image this chip generates, either text or graphics mode, if you are up for it!
Thanks! I uploaded a short last weekend showing some test displayed, and am in the process of putting together the usual kind of walkthrough of how that was done
Thanks for this, I really enjoyed it. I've been trying to work out a way of making an analog video mixer that actually syncs the signals and I think you may have given me the key phrase I needed to google. Really keen to see an image being produced by the Ic. I wonder if you can make a tiny rom that would program those 16 instructions and get it running independently of the 6502.
Ah it's the wrong phrase though, I got mixed up! AC Line Lock is for synchronizing the vsync with the power lines, not with another video source. It was important when you were filming a roomful of CRT monitors, you need your camera and all of the monitors to have synchronized vsyncs to avoid flicker. To synchronize with another video source, you should just let it provide the vsync and hsync, then do your own counting within the frame based on those to work out when you're in the active area and what your pixel coordinates are. Using a ROM to initialise is an interesting idea and should be possible at least as far as I've gone. But getting data into video ram later also requires some communication with the chip.
@@GeorgeFoot thanks for the heads up! I should comment more, but I enjoy your content very much! It possibly helps yours aren't an hour video saying "part 107".
Thanks, good to know! It is hard to decide where to draw a line between giving interesting information thoroughly and cutting to the chase. This video is an interesting case because although it's a lot longer than I normally aim for, it got a lot more views than normal as well. But I can see from the analytics that a lot of people weren't very interested in the details in the datasheets, they stopped watching or skipped ahead. It's a hard line to walk, and editing actually takes me longer than filming!
@@GeorgeFoot Editing if done right tends to be invisible and take a lot longer than people expect. I love Ben Eaters approach of showing the datasheet, explaining what it does, the pin outs, hooking the chip up and seeing what happens. Then he usually shows some odd behaviour then goes back to the data sheet to explain why, I'm *pretty* sure that's you have done here. If I'm totally honest, and I may be unique in this respect but I usually watch these electronics video through the lens of wondering if I want to build the circuit myself, or how I could apply it to my project. So when you see 'part 108' and see a huge mess of wires or PCBS being connected it interests me less because it's a bit more project specific. I hope this doesn't sound like a backhanded complement, but I feel like the last few months you have really found your feet with these videos.
Thanks for the well presented and informative video. I currently have 3 VDPs, and have yet to design an implementation for my 6809-based computer. As far as simplicity, which would you choose: - TMS9918ANL - SCN2674 - MC6847
I think the TMS9918 and MC6847 are more compete solutions as they decode the memory contents into a pixel stream for you. But I think they limited to low resolutions. The SCN2674 I used here only really generates addresses to feed into the memory, it doesn't pick up the results - hence here I used a character ROM and shift register to get a pixel stream out.
It would be nice to have a video which shows how to do the same thing with a IC that is still in production. I was looking to DIY a 8-bit ISA bus video card but the open source options are using the TVGA9000 chip which is hard to solder and expensive. High performance video is not on my list since I will be running mostly Retro video games that run on the original intel 8088 IBM PC era.
Unfortunately there aren't really any good options that I'm aware of, I expect there's no commercial market for it given modern display technology. It is possible to program a PLD to assist quite a lot but generating addresses to scan video RAM requires a lot of output pins. Most of my video output circuits have just been based on discrete counter ICs for this reason.
You might want to look at Other legacy (old) Video chips that can do VGA / CGA such as : The NEC upd7220 (D72020 CMOS) in DIP40 or PLCC44 The Yamaha V6366 PLCC84, as used I some 'Hercules' legacy/old PC video cards I also saw someone trying to use a Thomson TS68483...which looked quite interesting .
I'm a little confused about the 6522. You mentioned that you can't talk directly to the chip because of clock speeds, so you instead latch values into the 6522. But in the 6502 code, you seem to write one value the port, and then the next. How do you ensure that the writes to the 6522 don't overwhelm the SCN?
The STA instruction takes 4 CPU clock cycles, and LDA or EOR takes another 2 - so it's about 6 cycles overall, which with my 6.3MHz CPU clock rate should last about 1us. I think the SCN only requires a few hundred ns, so this should be fine. There are some other constraints on the SCN bus timing as well - such as sometimes having to wait at least until the next CCLK - but my CCLK is fast enough that I don't think that is a problem.
It's the one I demonstrated here, just built on veroboard instead: th-cam.com/video/DyxhS2SbpGM/w-d-xo.html I made some improvements to the original circuit since then but this veroboard version is, I think, exactly what was in the video above.
![Build an 8-bit retro computer powered by a Z80 ! [Zeal 8-bit]](http://i.ytimg.com/vi/n_eEDAQWMdY/mqdefault.jpg)
Just popping in to say I recently acquired a dumb Terminal and inside was the SCN2674 driving it all, and googling the chip to try and find schematics your video was the first thing to pop up again.
It's funny that - the SCN2674 videos were very popular for some reason, I'm not sure why as it is an obsolete part that's no longer in manufacture, and wasn't even very significant in its day compared to something like the 6845 which seems to have been much more common! Still something clicked with them and I guess Google likes these videos!
@@GeorgeFoot I think it's mentioned on a wiki page on video chips mentions it- that's why I started looking it up
Nice job finding the floating input. That would have stymied me for a good long while.
ohh no, now we have to wait for another episode that shows that VGA is really working: the text mode and the graphical mode. hurry up! :)
Haha yes, sorry not to show any image at all, I did warn at the start though that that would be the case! Really this chip is all about timing though, not image generation - the image generation is going to look pretty similar to in my other videos. And create all the same problems - amount of RAM needed, access speed, etc.
Very interesting chip and process. Total aside: I have that same meter and I never imagined it could measure frequencies that high.
Yes, it's surprisingly capable and cheap, and it has a great sample rate as well. Given what I later discovered about the vsync, it's possible it would have been able to sample it as well if the circuit was actually working.
@@GeorgeFoot Am I right in thinking this is the AN8009?
It's AN8008, I saw it on EevBlog a while ago and I think his only complaint was related to the ranges available for current measurement.
Thanks for this! The chip looks very interesting. I'm building a 65C816 system and I have a 68B45 on order. My goal is 800x600 resolution and your SCN2674 looks very interesting. I may order one. By the way, I currently use a ATF22V10C to stretch my clock for slower peripherals (such as a PCF8584 for I2C and a NHD0440 display).
Nice, yes I think this is capable of about double the character rate of the 6845, though I don't know the specific figure for the 6845. You can always squeeze more pixels in horizontally by just using longer shift registers - you'll need at least 10 pixels per clock - the problem is more that features of this chip like hardware scrolling and split screens will have worse horizontal granularity. You can add your own adders of course to fix that but you start to lose the benefit of the monolithic IC.
Vertically, though I didn't mention it, this chip has a "graphics" mode where the repeated scanlines actually keep counting up through memory addresses, so you cover a lot more addresses contiguously. One thing I don't think it supports is a custom stride.
If you're interested in whether a specific combination of register values works then let me know and I might be able to try it, if I have the right oscillator handy.
@@GeorgeFoot Thanks for the offer. I found the SCN2674 on Jameco for $5. I'm going to order and compare them to the 68B45. I had a 6845 (not the 'B' version) working with a 1Mhz 6800 back in 1980, but I've forgotten more than I remember. Had it working at 80 chars by 50 lines on a surplus word processing monitor. It's a shame I can't use the GD6410 ($11 on Jameco). It's a 5V part but that QFP-160 pin package is a bit beyond my skills. PLCC-84 Through Hole seems to be my current limit.
Let me know if you need help with using the atf22v10c for 'glue' logic. They seem to work fine for me now that I have some experience with them. The TL866II Plus programs them just fine. WinCupl is rather finicky though. And I'm starting to gain some experience with the ATF1508.
I wouldn't be too afraid of QFP soldering, you can buy some cheap chips and practice boards and get the hang of it in the end - then solder the real thing into an adapter board.
Another option is to try to find it with J-leads then maybe you can solder a through hole socket to put it in.
I have a pretty good setup for programming the 22V10s etc - I stopped using WinCupl and found command line for running the compiler and simulator so I can automate that better, and it was a much smoother experience after that. ATF1508 looks nice - I got an ATF1500 before realising it wouldn't work with the TL866.
Nice video, one point, 5v rail decoupling capacitors on the video board !
In the 70s people were paranoid about crowbaring supply rails so one per chip became common, in the 80s people relaxed and used less.
Great video, I'm think about using it's BIIGGG brother the SCC63484C8A68 which I scavenge from some sort of old terminal computer. This is by far the most ridiculously large DIP chip I've ever seen
It looks like the longest part number I've ever seen too! Maybe it integrates more of the support chips, like the character generator and attribute/colour processor
I am writing a code for this baby as it is used by a retro machine I'm playing with called Iskra Delta Partner. Thx for this video, I really learned a lot from it. Hope you make part II.
Great, it'll be good to hear how that goes! I was just experimenting with actual video output, having trouble getting crisp pixels at the moment though, hopefully I'll find a solution soon
My hardware is this (see the link below). I'm a software guy so I have troubles understanding it. But I do understand that it combines graphical card Thomson EF with an SCN - unconventionally gluing outputs of two cards together. The SCN part has its own SCB chip to generate attributes and its own logic to generate characters. Maybe you can get some info from it for your project.
drive.google.com/file/d/1OSoaMkrv7T39G1Ct_5qzWgFxN8izR2_x/view
This is an actual graphical card from 1983. I'm currently trying to find out how I can produce custom graphics. I can see an EPROM (characters, I guess?) and static RAM chips both connected to the SCB chip sharing the bus so my uneducated guess is that characters must be loaded to static RAM somehow and there is something that overrides EPROM to leave control over the bus to the static RAM. But still guessing. This is officially a text only card. But legend says that custom graphics can be done on this hardware, but no docs, no one to ask an no one has ever done it. :)
Cool, I'll check it out. Meanwhile here's a collection of datasheets for various Signetics parts that might be used together in that application. It also includes suggestions of how they could be combined, which your manufacturer may or may not have followed! www.bitsavers.org/components/signetics/_dataBooks/1986_Signetics_Microprocessor.pdf
I'm going to get text output working next, I'm halfway through that right now. Generally the SCN produces addresses (one per character) that you feed into a RAM's address pins to read an ASCII value per character. Then that value is shifted left a few bits and combined with a row count from the SCN2674 to get an address to look up in character memory (ROM or RAM) that contains e.g. 8 bytes per character with each byte defining the lit pixels for one row of that character. That then goes to a shift register to display the pixels one by one on the screen.
Other ICs that may be involved could be reading colour/background data (character attributes) and combining that with the character generator's output; adding cursors, underline, etc; and double height or width processing which are all sorted by the SCN2674 but subject to the rest of the circuit knowing what to do with them.
The VSYNC width field isn't in a weird order: it's using Gray codes by the looks of it. There's probably some good reason to do with the chip's internals as to why they're used here.
Nothing nearly as ambitious as this project, but I implemented the ACM CORE graphics standard from a book with pseudo code in College, and I remember the challenges of coding to the card with the VGA hardware after the relative EASE of CGA and EGA coding. Yeah it looks odd, but it actually makes pretty good sense once you take a look at it.
Another great video, thanks for sharing!
One thing I can’t understand is why, with the abundance of retro CPUs and peripherals still being manufactured, video chips are not one of them. Sure, I know you could use FPGA, or depend on eBay/AliExpress, but in my designs I try to avoid those…
Yes, this one is recycled for sure, it has solder tinning on the pins. I wonder if one reason is that the video signals these were designed for are so obsolete, and useless without the right display hardware. The TMS9918 is essentially SDTV only; this one here is barely capable of the horizontal sync needed for VGA. I guess the next level up that's is EGA or VGA (which were custom ASICs).
The trouble with SDTV is the horizontal sync rate being low (about 15kHz) which modern monitors don't necessarily support. There were too many standards and too many connector types. SCART is great but never existed in North America. And all these things are less and less supported on modern TVs. Who knows how long they be around now. 🙁
So there probably is a lack of demand for the authentic through-hole ICs of the day due to modern display hardware limitations; and on the other hand, the 31kHz "HD" schemes like VGA and up were never available in this form factor, they've always been SMD ASICs. Bearing that in mind then, the most authentic answer probably is in fact to use an FPGA after all!
Or roll your own solution from more parts, which I certainly enjoy doing. The EEPROM sync approach is the most compact I've found. I have another design using your ATF22V10 PLDs but it still needs separate counters to be useful, so ends up a little bit more complex than the EEPROM approach. I also had a design using tons of downcounters that was logical and I liked it a lot, but that's about twice as many ICs again. It's great how many options there are though and they all work well except using upcounters and logic gates which is a nightmare!
@@GeorgeFoot could it be possible to make a drop in replacement board based on Atmega8 ?
WOW, this is amazing work!!!
I've actually got one of these on order, along with some 64kx4bit 15ns RAM and a suitable crystal for outputting a PAL signal. It'll be interesting seeing how it handles VGA.
Great - it should be good for PAL. What speed is your crystal? I think you want 13.5MHz for 640x512. I used a 27MHz crystal divided by two for that in another circuit. The exact pixel clock didn't matter much in the analog days, and the BBC Micro used 16MHz, but modern TVs don't like that so much.
@@GeorgeFoot It's a 17.734 Mhz crystal, to be divided by 4 to give me 4.433 Mhz. My homebrew design is built around the Hd63c09 and it only gets to be tinkered with here and there when time allows. It'll be good to finally connect it to a display.
Incredible just what I want
Great video! I liked the how you analyzed why the VSYNC doesn't work and a good reminder that unused input pins need to be tied to either high or low. I would love to see some image this chip generates, either text or graphics mode, if you are up for it!
Thanks! I uploaded a short last weekend showing some test displayed, and am in the process of putting together the usual kind of walkthrough of how that was done
@@GeorgeFoot Awesome, can't wait!
Have you tried working with the Vic 20 video chips that shipped with the Commodore 64?
Thanks for this, I really enjoyed it. I've been trying to work out a way of making an analog video mixer that actually syncs the signals and I think you may have given me the key phrase I needed to google.
Really keen to see an image being produced by the Ic. I wonder if you can make a tiny rom that would program those 16 instructions and get it running independently of the 6502.
Ah it's the wrong phrase though, I got mixed up! AC Line Lock is for synchronizing the vsync with the power lines, not with another video source. It was important when you were filming a roomful of CRT monitors, you need your camera and all of the monitors to have synchronized vsyncs to avoid flicker.
To synchronize with another video source, you should just let it provide the vsync and hsync, then do your own counting within the frame based on those to work out when you're in the active area and what your pixel coordinates are.
Using a ROM to initialise is an interesting idea and should be possible at least as far as I've gone. But getting data into video ram later also requires some communication with the chip.
@@GeorgeFoot thanks for the heads up! I should comment more, but I enjoy your content very much! It possibly helps yours aren't an hour video saying "part 107".
Thanks, good to know! It is hard to decide where to draw a line between giving interesting information thoroughly and cutting to the chase. This video is an interesting case because although it's a lot longer than I normally aim for, it got a lot more views than normal as well. But I can see from the analytics that a lot of people weren't very interested in the details in the datasheets, they stopped watching or skipped ahead. It's a hard line to walk, and editing actually takes me longer than filming!
@@GeorgeFoot Editing if done right tends to be invisible and take a lot longer than people expect. I love Ben Eaters approach of showing the datasheet, explaining what it does, the pin outs, hooking the chip up and seeing what happens. Then he usually shows some odd behaviour then goes back to the data sheet to explain why, I'm *pretty* sure that's you have done here.
If I'm totally honest, and I may be unique in this respect but I usually watch these electronics video through the lens of wondering if I want to build the circuit myself, or how I could apply it to my project. So when you see 'part 108' and see a huge mess of wires or PCBS being connected it interests me less because it's a bit more project specific.
I hope this doesn't sound like a backhanded complement, but I feel like the last few months you have really found your feet with these videos.
Thanks for the well presented and informative video.
I currently have 3 VDPs, and have yet to design an implementation for my 6809-based computer.
As far as simplicity, which would you choose:
- TMS9918ANL
- SCN2674
- MC6847
I think the TMS9918 and MC6847 are more compete solutions as they decode the memory contents into a pixel stream for you. But I think they limited to low resolutions. The SCN2674 I used here only really generates addresses to feed into the memory, it doesn't pick up the results - hence here I used a character ROM and shift register to get a pixel stream out.
It would be nice to have a video which shows how to do the same thing with a IC that is still in production. I was looking to DIY a 8-bit ISA bus video card but the open source options are using the TVGA9000 chip which is hard to solder and expensive. High performance video is not on my list since I will be running mostly Retro video games that run on the original intel 8088 IBM PC era.
Unfortunately there aren't really any good options that I'm aware of, I expect there's no commercial market for it given modern display technology. It is possible to program a PLD to assist quite a lot but generating addresses to scan video RAM requires a lot of output pins. Most of my video output circuits have just been based on discrete counter ICs for this reason.
Genius stuff, wow
You might want to look at Other legacy (old) Video chips that can do VGA / CGA such as :
The NEC upd7220 (D72020 CMOS) in DIP40 or PLCC44
The Yamaha V6366 PLCC84, as used I some 'Hercules' legacy/old PC video cards
I also saw someone trying to use a Thomson TS68483...which looked quite interesting .
I'm a little confused about the 6522. You mentioned that you can't talk directly to the chip because of clock speeds, so you instead latch values into the 6522. But in the 6502 code, you seem to write one value the port, and then the next. How do you ensure that the writes to the 6522 don't overwhelm the SCN?
The STA instruction takes 4 CPU clock cycles, and LDA or EOR takes another 2 - so it's about 6 cycles overall, which with my 6.3MHz CPU clock rate should last about 1us. I think the SCN only requires a few hundred ns, so this should be fine.
There are some other constraints on the SCN bus timing as well - such as sometimes having to wait at least until the next CCLK - but my CCLK is fast enough that I don't think that is a problem.
What’s the details of the power supply board you’re using? Looks interesting.
It's the one I demonstrated here, just built on veroboard instead: th-cam.com/video/DyxhS2SbpGM/w-d-xo.html
I made some improvements to the original circuit since then but this veroboard version is, I think, exactly what was in the video above.
@@GeorgeFoot cool, thanks! Must’ve missed that one when I was binging your channel. :)
Please post if you find a chip that outputs vga or better.
Can you please send a schematic my way?
Can’t see what you’re pointing at on the chip diagram.
Yep sorry about that - I had a lot of issues with my camera this time around and lost patience a bit by the end and decided to just go ahead anyway!
What happened to your Arm2 computer? No more development?
It looks similar to chip used in CGA adapter is it a clone?
I think the CGA used the 6845 CRT controller, so it's not exactly the same but they do similar jobs
watched for 30 minutes the reading of the manual for to get presented with a black screen. thank you very much for this waste of time.