FPGA in DIP package in 2k23? (Also, generic FPGA rant)

[and3rson]

I've seen this thread - viewtopic.php?f=10&t=3693&hilit=dip+fpga - but since it's from 2016, I've decided to start a new one (not sure if necrobumping is welcome on this forum?)

Anyone aware of any actual off-the-shelf DIP-packaged FPGAs? Best I could find is https://hackaday.com/2023/06/21/fpga-br ... enanigans/ (which just arrived, heading to the post office to pick it up), but even though it looks "dual in-line", it's not a real DIP.

FWIW, here's some context.

I've been researching various options for a video chip for a while, and it seems like FPGA is an only option. My constraints were:
- Must be DIP
- Must be still made
- Must be off-the-shelf, i. e. no CPLDs.

Obviously I had to give up the third option, which leaves me with FPGAs. Still, there are things like Parallax Propeller, but it seems way too powerful for me. I really don't want my video chip to be thousand times more capable than the rest of my entire board combined. I'd like to stick to the bare minimum, to make it "barely doable" in the spirit of a "perfect" 6502 SBC. (Yeah, I'm an FPGA hater, lol.)
I still have several TMS9918 which seem like a great choice for my task (simple interface, not much glue logic required, outputs video signal out of the box), but ofc they aren't made anymore.

I feel like if one day someone came up with some sort of modern basic ASIC video chip (e. g. 320x240, 256 colors, text/graphics mode, limited number of hardware sprites), this would be a big day in homebrew computer community since it would make it possible to build a factory-new purist SBC without the need to build an entire video subsystem by yourself, and would standartize the video interface, so that more people would be able to share graphics-related code, make & port new games to their own SBCs, etc. I'd be happy to pay top dollar for such thing. Alas, people seem to stick to FPGAs.

[Paganini]

and3rson wrote:

I feel like if one day someone came up with some sort of modern basic ASIC video chip (e. g. 320x240, 256 colors, text/graphics mode, limited number of hardware sprites), this would be a big day in homebrew computer community since it would make it possible to build a factory-new purist SBC without the need to build an entire video subsystem by yourself, and would standartize the video interface, so that more people would be able to share graphics-related code, make & port new games to their own SBCs, etc. I'd be happy to pay top dollar for such thing.

I'm right there with you. There are plenty of NOS / pulls of old CRT controllers, but none of them go faster than 4 - 6 MHz, which makes them challenging to pair with modern WDC 65c02s, at least if you want to go fast. It sure would be nice if someone made something like a VIC chip, or even just a WDC 65c45-14 would be cool.

The closest thing I know of is the VERA for the Commander X16. https://github.com/fvdhoef/vera-module It is an FPGA. Maybe it would do what you need?

[Proxy]

I have never heard of an FPGA in a DIP package before, especially ones still being made.
It wouldn't make a lot of sense for any company to be producing them as the market would be basically non-existant.

i'm sorry but your requirements seem pretty much impossible.

also the last requirement is a bit confusing. you say FPGAs are your only option while also excluding CPLDs.... even though CPLDs and FPGAs are functionally the same thing (ie they're both progammable logic), main differnces being that FPGAs are usually faster, have more IO, and a lot more logic available.
still that doesn't mean CPLDs can't be used for Video generation as seen by various projects on this site. plus CPLDs are still being made, though in PLCC package which i think is the closest you'll get to DIP without resorting to a breakout board.

if you were to get rid of your second requirement (which IMO is only really needed if you plan on mass producing systems) then you have a lot of older chips as options. though even with modern fast RAM and logic, a 6845, TMS9918, or similar will only get you so much VRAM capacity and throughput depending on the time it was made in...

Paganini wrote:

There are plenty of NOS / pulls of old CRT controllers, but none of them go faster than 4 - 6 MHz, which makes them challenging to pair with modern WDC 65c02s, at least if you want to go fast.

very true, atleast for the really old chips. there are slightly more modern ones like the HD63484 or the F65535. but of course the more modern you get, the more specific and complicated the interface to it.
i would love a modern CMOS version of the 6845, running at like 20MHz and with more address lines and features. though that would likely require a larger package like PLCC-68 or DIP-64.

.

anyways for Microcontrollers you said

and3rson wrote:

but it seems way too powerful for me. I really don't want my video chip to be thousand times more capable than the rest of my entire board combined.

though ironically FPGAs are also likely thousands of times more powerful than your system as they can house all the logic for a 65C02 SBC running much faster than real silicon.
but besides that, if you were to choose a Microcontroller i would recommend the Raspberry Pi Pico. it's very cheap, comes in something close enough to a DIP package, and is powerful enough to run 320x240 @ 256 colors by itself while only using one of the CPU cores.

but if you're dead set on using an FPGA then i'd recommend just getting a decently priced FPGA dev board and hooking your system into that (assuming it also runs at 3.3V, or you have level shifters) so you can experiment with the design without having to make a custom board and soldering a QFN or TQFP IC.

overall i'm sorry if i couldn't be more of help, but when it comes to video and sound there just isn't an off-the-shelf option anymore that doesn't require programmable logic or old stock chips.

[BigEd]

> you say FPGAs are your only option while also excluding CPLDs.... even though CPLDs and FPGAs are functionally the same thing (ie they're both progammable logic)

I pretty much agree with this, although there are nuances: in particular, a CPLD powers on into the desired programmed state, whereas an FPGA takes some milliseconds to load the configuration into the machinery. A person might think of a CPLD as a small programmable element, like a bigger PAL or GAL, and that would be accurate, whereas an FPGA is more of a sea of logic elements which is configured into some particular circuit. (Since an FPGA is bigger and more flexible, it does surprise me to see CPLDs rejected but FPGAs accepted.)

> though ironically FPGAs are also likely thousands of times more powerful than your system as they can house all the logic for a 65C02 SBC running much faster than real silicon.

I don't think this is a great way to look at things, and the reason is that an FPGA is programmable, and while it could house a whole MPU subsystem, it could alternatively house a hardwired video controller. In the latter case, I can see why it might be more acceptable, in some set of preferences, to a Propeller or other MCU.

Of course, anyone figuring out which technologies they'd like in their project, and which they wouldn't, is free to figure out their own preferences. But it feels to me better if those preferences are based on a good model of what those various technologies are, and how they work.

[hoglet]

Have you considered the SiPEED Tang Nano 9K modules:
https://wiki.sipeed.com/hardware/en/tan ... no-9K.html

This module has a wide 40-pin DIP form factor, approx 9K LUT4s, 52KB of Block RAM and 76KB of User FLASH. They are also pretty cheap.

Smaller (1K/4K) devices are available, and very recently they have launched a Tang Nano 20K
https://wiki.sipeed.com/hardware/en/tan ... o-20k.html

Dave

[and3rson]

Paganini wrote:

The closest thing I know of is the VERA for the Commander X16. https://github.com/fvdhoef/vera-module It is an FPGA. Maybe it would do what you need?

There are few things I dislike about VERA - specifically, to me it's doing "too much" in addition to video (uSD, sound, etc) and is rather bulky.
But now it seems to me like all FPGAs need some glue logic (I never did anything with them, so my knowledge of FPGAs is nearly unexistent).

Proxy wrote:

I have never heard of an FPGA in a DIP package before, especially ones still being made.
It wouldn't make a lot of sense for any company to be producing them as the market would be basically non-existant.

i'm sorry but your requirements seem pretty much impossible.

Yeah, I guess that's true.

Proxy wrote:

also the last requirement is a bit confusing. you say FPGAs are your only option while also excluding CPLDs.... even though CPLDs and FPGAs are functionally the same thing (ie they're both progammable logic), main differnces being that FPGAs are usually faster, have more IO, and a lot more logic available.
[...]
though ironically FPGAs are also likely thousands of times more powerful than your system as they can house all the logic for a 65C02 SBC running much faster than real silicon.

Sorry for introducing the confusion, my bad. I understand that FPGAs are a kind of CPLD, I just used those terms in my post interchangeably. What I meant is I tried to avoid any CPLDs in general, but I was forced to entertain a possibility to override my wishes and use FPGAs anyway.

Proxy wrote:

but if you're dead set on using an FPGA then i'd recommend just getting a decently priced FPGA dev board and hooking your system into that (assuming it also runs at 3.3V, or you have level shifters) so you can experiment with the design without having to make a custom board and soldering a QFN or TQFP IC.

Do you have something you can recommend? I found it hard to find 5V-tolerant FPGAs, and seems like some of the popular ones are discontinued (such as Spartan II). Also, the one I've received (based on MachXO2-1200HC) is 3.3V, so I'll stick to level shifter for my upcoming tests.

BigEd wrote:

Of course, anyone figuring out which technologies they'd like in their project, and which they wouldn't, is free to figure out their own preferences. But it feels to me better if those preferences are based on a good model of what those various technologies are, and how they work.

I totally agree. My main gripe with CPLDs in general is (and you might find it irrational) that they "pollute" my board with an "uninteresting" solution. Not to offend anyone! The funny reason to this is probably because I've been programming for a living for 15 years now, and I learned the software engineering rather well, so now as a result I find software solutions to problems less amusing than mechanical or hardware ones.
P. S. I don't find FPGA itself "uninteresting" - in fact, quite the opposite: I want to learn them, and I'm amused by this technology. But at the same time I try to keep them away from my '02. (Though, as I mentioned in my first post, an FPGA seems to be the only sensible solution for my SBC use case.)

hoglet wrote:

Have you considered the SiPEED Tang Nano 9K modules:
https://wiki.sipeed.com/hardware/en/tan ... no-9K.html
[...]
Smaller (1K/4K) devices are available, and very recently they have launched a Tang Nano 20K
https://wiki.sipeed.com/hardware/en/tan ... o-20k.html

Thanks for pointers, these links are very much appreciated. I'm very new to FPGAs, and there's so many of them!

[BigEd]

OK, understood that you're talking about any kinds of complex programmable logic.

For me, modularity and encapsulation are useful ideas here: a video chip is a particular fixed function, which happens to be quite complex and which happens to have been available back in the day. For me personally, any kind of subassembly which does the job of a video chip, and only that job, is a reasonable substitution, especially if it allows for the project as a whole to be finished sooner, or more easily.

Many projects use a USB adapter chip of some kind, without worrying too much that it has a CPU system inside. It's encapsulated and dedicated. So, for me personally, using a programmed FPGA board, or a programmed microcontroller, for some specific subsystem, is almost always a reasonable thing to do.

Of course, as noted, preferences differ! (From person to person but also from project to project)

[GARTHWILSON]

and3rson wrote:

I've seen this thread - viewtopic.php?f=10&t=3693&hilit=dip+fpga - but since it's from 2016, I've decided to start a new one (not sure if necrobumping is welcome on this forum?)

This seems to be a significant-enough change of subject (not being about Antti Lukats's DIPSY projetc) to justify starting a new topic.  Otherwise, if it's about the same thing, please, please continue on in the same topic, no matter how old the last post is, to keep related stuff together and avoid cluttering the forum with repeat topics.  An added benefit is that anyone who has posted in the old topic gets an email notice that a new reply has been added (when the email notifications are working).

[strik]

Would the good old GODIL qualify as FPGA in DIP? Unfortunately, as far as I know, it is not for sale anymore.

[BigEd]

I think the Tang boards are the new GODIL, in some ways. Except the GODIL had level shifters on board wheres the Tang boards are 3V3.

[sburrow]

and3rson wrote:

some sort of modern basic ASIC video chip (e. g. 320x240, 256 colors, text/graphics mode, limited number of hardware sprites)

This is a tall list of requirements! I don't know how many 6502's were running this capability in the 80's.

Doing some simple math, 320x240 with 8-bit color = 76800 bytes of memory. That's if you don't overscan or anything else. Typical expected memory on a simplified level would be 128K, just for video, yet the 6502 can only officially access 64K. If you have a 6502 running at 1 MHz for low end users, or even something around 4 MHz let's say, and updating each pixel on the screen takes at minimum LDA/STA statements, you are looking at a LOT of time to update a single screen. Imagine running this thing at 60 FPS!

My bigger point is that 6502-land is not designed for 320x240x256-colors, and that's why you see the Commodore 64 and the NES have very particular ways of accessing, modifying, and using the video side of things. Yes, they had separate dedicated chips, but it was still not bitmap graphics like the PC's had. Even then, while 6502 was popular, the best bitmap graphics on the PC was CGA using only 4 colors, because of memory and refresh speeds.

I was searching for just such a video card myself, and that's why I eventually designed my own. And I found that you have to make compromises somewhere: access speed vs simplicity, color depth vs refresh rate, pixel size vs clock speed. I personally think 4 colors at 320x240 is a perfect compromise for 6502 based systems!

Thanks for the interesting topic!

Chad

[cjs]

and3rson wrote:

My main gripe with CPLDs in general is (and you might find it irrational) that they "pollute" my board with an "uninteresting" solution. Not to offend anyone!

It's not irrational, it's just about the particular aesthetic approach you want to take to the hardware you're building. I totally understand this; I myself prefer to build things using technology from around the 1975-1984, or more modern technologies that work the same way.

Given that, there's an argument to be made that you should have no issue with using a CPLD or an FPGA: those are effectively the modern hobbyist equivalent of the ASICs that commercial designers could call upon to be built for them if they had sufficient financial resources to do so. Effectively, you're just taking on the job of the MOS chip designers who were working for Commodore, as well as the system designers using those chips. Alternatively, you can go the route of programming an FPGA with someone else's design such as a TMS9118 clone, which is the modern equivalent of ordering a TMS9118 from TI.

Personally, I'm not so much into those video chips because they often tend to be pretty system-specific and proprietary: nobody but Commodore could get hold of VIC-II chips, for example. I like systems that anybody in 1980 could have built from commonly available parts with multiple sources.

It also helps that I have slightly different preferences for video than you do: I don't feel any need for sprites at all, nor lots and lots of colours, but I do like high resolution. So instead of going for 320x240 with 256 colours and sprites, I'd aim for 640x200 or 640x220 with 8 colours and digital RGB output. (You can't get effective resolutions above about 160 pixels across on 15.7 kHz NTSC video systems due to the nature of how colours are encoded; that and the much greater simplicity of RGB output guide me towards RGB.) You could of course even bump this up if you don't mind sourcing a monitor that can handle higher resolutions; 640x400 on 24 kHz video was very common on 8-bit computers in Japan starting around the mid-80s.

Going in this direction, a video system can be built up out of mainly 7400 series parts, just as the Apple II did it. And you can make it fairly simple if you just use a flat, bitplane frame buffer: three banks of 16K for red, green and blue at one bit per pixel makes for a (relatively) simple circuit to generate RGB output.

You then have the issue of dealing with text, scrolling, and where to put that 48K of RAM; one good option is simply to off-load all this to another 8-bit CPU dedicated to the task. Give that CPU some ROM for its code and character glyphs, a small area of RAM shared with the main CPU for communications, and now you have a flexible, reasonably powerful system built entirely with '80s technology.

And in fact, that's exactly what Fujitsu did with the FM-8, released in May 1981. (There are a number of custom chips in that video system, but they all do simple things that can be fairly easily replicated with 7400 logic, at least if you're Steve Wozniak.)

[fachat]

There are many ways to build a video system. You could even have 640x400 in lots colors with a 1MHz system - you just need to make the bus wide enough. Commodore PET internally used 16 bit (2x8) video memory on some models to produce 80 cols video (640px). Double that and you have 4 colours. Add a LUT for the colors and you can expand the color range etc. The only reason the PET does not do hires is how the address lines of the CRTC are wired (and the lack of a 1:1 characterROM). Something I kind of fixed in my Video board for the CS/A multiboard computer (which is PET compatible).

Oh, and btw, the original PET video is in TTL also, and IMHO nicer than Apple II video. You don't need to be Steve Wozniak to do that.

The real question is what trade offs you want to make. How much memory do you have? Is it separate from main memory or shared? E.g. can accessing video memory be slower than main memory? How fast is the memory? That also determines the access width/modes. Depending on the bandwith required per video mode - high resolution for b/w, but for colour: more bandwith or less resolution? What screen refresh frequency is needed?

For my MicroPET I decided to optimize for space, so I used 8bit video bus, separate from main memory (video has prio) run at 12.5 MHz, for a VGA output of 640x480 (400 actually used). For B/W I need two video reads per 8 pixels - one videobdata and one for char 'ROM' if in character mode. 25MHz pixel clock means two pixels per memory access or four memory accesses per 8 pixels. So half the memory bandwith is CPU the other half is Video.
Adding colour means reading an additional byte of color (in this case per 8x8 pixel cell), so only 1/4 of memory bandwith available for the CPU.
And there the CPLD with 288 macrocells was already full (granted with timing generator and memory mapper included). For me that means I am currently testing an FPGA instead of that CPLD. But that only solves issues with how video memory is addressed but not the bandwidth problem.

Still, I am looking forward to employing tricks similar to the C64 like pre-loading data in the off-screen area to add morenfeatures (sprites?) In the end my MicroPET will (hopefully) have capabilities similar and in some points exceeding the VIC-II. But that just doesn't work without FPGAs.

[BigEd]

It feels to me like there are two tensions pulling in different directions - more resolution and colour depth, on the one hand, which results in lots of data to move and difficult animation, or a push towards interactivity and faster updates, which results in lower resolutions or systems of tiles and sprites. And in both cases, one needs ways to work within a 64k logical address space. But different applications will head in different directions.

[drogon]

BigEd wrote:

It feels to me like there are two tensions pulling in different directions - more resolution and colour depth, on the one hand, which results in lots of data to move and difficult animation, or a push towards interactivity and faster updates, which results in lower resolutions or systems of tiles and sprites. And in both cases, one needs ways to work within a 64k logical address space. But different applications will head in different directions.

I think there are also 2 other directions too... One is the "poke pixels at the screen" approach, the other being to off-load most if not all to some external Graphics Processing Unit...

Which is what I was faced with when I wrote my BASIC Interpreter some 12+ years back - never having done any Linux graphics work (but have done a lot of bit-mapped pixel poking in the past) I asked how pixel poking was done under Linux to get as much much sneering and derogatory comments as positive ones (so no change there then), however I did find what I wanted and ported all my pixel poking code into the system and it works fantastically...

... on a 32/64 bit CPU with 24bpp and full HD resolution on a 1GHz CPU in a somewhat very optimised C.

but take that down to an 8-bit CPU running at < 16Mhz and life starts to become quite complex - even something as simple as clearing the screen starts to take time - visibly noticeable on the Apple II for example.

So many decisions to take..

My Ruby project offloaded the graphics - initially to the ATmega host with 320x240x1 display on compost video - subsequently upgraded to anything I wanted on my Linux desktop using the same serial protocol to get stuff going on the ATmega version. (and using the same Linux code I wrote for my BASIC)

The TI99 chip was probably the first one in the home computer department that offloaded graphics completely, (separate video RAM) but other systems at the same time were building hardware to do graphics assist with RAM the CPU could pixel-poke...

So local RAM that the 6502/816 can address - but visibly slow if the CPU is doing all the work, or add hardware to do stuff like tiles/sprites/planes call it what you like, or offload completely and use a high level protocol to the GPU...

There's never an easy choice to make... The VERA graphics chip on the Commander X16 does look quite interesting though... But it's FPGA.

I take the view that we don't have to do everything and I accept a little black box here and there but I know many others like opening that black box and making their own...

Heres a thought... Design a little board. You plug a 65C02 into it and it plugs into a 65C02 socket (or 816). That board has some 32KB of RAM that can appear anywhere in the memory map, but lets say from 8K to 40K. It's normally transparent. Code running in the upper few K can poke a register to enable writes to that RAM, and disable underlying RAM. So that high code can do the pixel poking. Code running anywhere else just needs to call some routines in the high code to do stuff like plot, line, character, and so on.

And you've just re-invented the BBC Master.

https://en.wikipedia.org/wiki/BBC_Master

-Gordon