Interfacing old PC cards to homebrew 8-bit computer - Page 1
Forum section: electronics / general

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 22, 2019, 03:04:26 pm
content: I am considering making an ISA interface onto my homebrew 8-bit Z80 computer.The idea being that I perhaps may then reuse some of the old 8/16-bit ISA PC cards, like parallel ports, network and perhaps even video cards...? (I have some 8/16 bit parallel, serial and network cards)I just have no idea how hard it is to reverse engineer these card to a degree that I could write the drive code for it, or if this type of information is freely available these days. Perhaps there is even the source code of one of these (x86) drivers to be found somewhere...?Or perhaps there is one specific model (card) that has been cracked and choosing that one will enhance my chances of success?Are there user groups / communities that do this sort of stuff?I have found info on the parallel port - it's pretty basic and standardized.Not so sure about video and network cards though...Is this a path worth exploring or is it a waste because I am never gonna find enough info to get these (more complex) cards actually working?Ideas?

author: Kean
author_rank: Unknown
timestamp: June 22, 2019, 03:43:07 pm
content: There would be plenty of driver source code in open source operating systems like Linux or Open/FreeBSD.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 22, 2019, 06:59:54 pm
content: You have some advantage here because the binary "drivers" are already on the card -- the boot ROM.Not that that's terrifically helpful to you, as it's x86, but, it's a starting point?As for things that need OS device drivers, you'd have to port those to your OS API as well as the actual IO operations. If you have DOS drivers, you can still do some disassembly, but it will be that much more faffing...Does you computer have all the bus operations that ISA supports/requires? Easy to inspect the card pinout and see if it needs them, only a little harder to substitute... Say if it needs DMA and you don't have it?.. Well, good luck...Tim

author: Ian.M
author_rank: Super Contributor
timestamp: June 22, 2019, 08:09:52 pm
content: IMHO you've missed the bus by about 15 years, and more like 25 if you want to interface to 8 bit XT bus cards.8 bit cards are rare like hens-teeth and generally not particularly useful even if you have some. e.g. good working monitors for pre-VGA graphics cards are rare and expensive (except CGA cards with composite TV out), and you'll have a hard time finding 8 bit network cards with even 10base TX - they are usually 10base2 or AUI or worse, something entirely proprietary and non Ethernet compatible.Considering 16 bit ISA (AT bus) cards:4:3 aspect ratio VGA monitors are getting harder and harder to find and most old VGA cards cant sensibly drive widescreen monitors. Also the 8:16 bit bus conversion is going to be a real bottleneck - I would expect graphics modes above CGA resolution/bit-depth to be unusably slow, just due to the size of the bitplanes and the convolutions you will have to go through to map them in the Z80 address space.Z80 <> ISA AT bus for PATA IDE used to be worth doing, but good PATA IDE drives are also getting rare, so you might as well bite the bullet and buy new CF cards and get guaranteed 8 bit mode support.Ethernet's just about possible, but its going to be a bitch porting the protocol stack to run on a Z80, and when you've done that you wont have enough memory or processing power left to do anything useful. You'd be better off designing a Z80 fast hardware SPI port to access aWIZnet W5100Ethernet controller as that has a built-in TCP/IP stack.ISA sound cards might be fun, but they are likely to require DMA, although if you dust off the *REALLY* old 8 bit ones in your collection, you might find something that's usable without.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 23, 2019, 12:23:45 am
content: FYI, my Amstrad PC has EGA on board, but still through 8 bits. Of course it's in the full address space so the 128k is fully accessible.To be fair, 640x350ispainfully slow to use for much graphics...

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 23, 2019, 07:20:35 am
content: So it either too much work to get working or not really usable if/when I have it working.I was afraid of thatI guess I have to find some other use for the ISA backplane I've got...Thanks.

author: woodchips
author_rank: Frequent Contributor
timestamp: June 23, 2019, 05:22:54 pm
content: How depressing, if you have missed by 15 years then what about my Burroughs accounting machines?Get hold of a copy of the PC-XT, or PC-AT technical reference manuals, full of circuits, assembler code and everything else you need. Then make an informed decision.There is also the ISA BUS technical reference from Intel which will tell you all you need to know about the 8 and 16 bit busses.

author: Ian.M
author_rank: Super Contributor
timestamp: June 23, 2019, 06:49:44 pm
content: There's a considerable difference between a native 'retro' build using period appropriate parts, and hacking together an interface to build a Frankenstein machine. IMHO legacy ISA PC cards are best used in a 'retro' DOS era PC build, though I admit I have a strong preference for the end of that era and Windows for Workgroups 3.11 on a 486.I may have been a little too scathing about 8 bit cards. *SOME* 8 bit cards are very useful. e.g there was a Maplin 8255 based 24 line I/O card, or Microsoft Inport Mouse cards which with an adaptor could be used with any two or three button TTL level quadrature mouse, not just the original Microsoft one, and were the best way of adding a mouse to a pre-PS2 mouse motherboard if you had a slot free, or multiple COM port and LPT port cards. All applications where 8 bit I/O wasn't a significant bottleneck and half or 1/3 length cards were always better for airflow in the case.

author: David Hess
author_rank: Super Contributor
timestamp: June 23, 2019, 08:00:52 pm
content: There used to be some great books on this subject which included all of the ISA bus details. The 8088/8086 datasheet and application notes along with the 82xx peripheral datasheets pretty much cover it. On the card side, it comes down to an 82xx series peripheral chip and some external address decoding to drive the chip select line as needed. You can literally make an ISA to IDE/ATA controller board with an address decoder and a couple of buffers and transceivers; I have done it.

author: wilfred
author_rank: Super Contributor
timestamp: June 24, 2019, 01:28:17 am
content: Quote from: obiwanjacobi on June 23, 2019, 07:20:35 amThere's no rule that says you have to find ISA cards to add a ISA backplane to your Z80.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 24, 2019, 05:16:09 am
content: Quote from: woodchips on June 23, 2019, 05:22:54 pmI think I have scanned a couple of them, but I (remember I) could not find any details on how to address specific cards. I think I did saw LPT ports sample, but that is pretty basic.Quote from: woodchips on June 23, 2019, 05:22:54 pmThis one?https://ia801602.us.archive.org/33/items/bitsavers_intelbusSpep89_3342148/Intel_ISA_Spec2.01_Sep89_text.pdfQuote from: wilfred on June 24, 2019, 01:28:17 amI thought of designing my own bus based on the backplane I have -only a couple of pins are dedicated or have pullups- but I liked the idea of being able to reuse some of that old tech.Another idea I played with was using the ISA bus (backplane) to create a multi CPU computer. I have a working core Z80 compute unit (lets call it that, it has only RAM, no storage and only serial IO) and thought that perhaps I could add one or two to do parallel tasks (like driving the video display). To that end I scribbled down a schematic that interfaces the Z80 compute unit(s) with a dedicated (bus) DMA controller (and a couple of bus registers: 74xx646) to the ISA bus. This should allow the Z80 compute units to talk to each other and to every IO card in the backplane.Quote from: Ian.M on June 23, 2019, 06:49:44 pmI am definitely making a frankenstein version here. Have a PSoC5 and a CPLD on there too.

author: Berni
author_rank: Super Contributor
timestamp: June 24, 2019, 07:33:10 am
content: If you are going for a Frankenstein build and have no software for any of the add in cards then indeed it might be easier to just build your own cards from scratch. You can still stick to the ISA bus specification so these cards can work in other machines provided someone writes a driver for it.A lot of expansion cards have very little smarts on them. The old parallel ports are mostly just a glorified GPIO register built from off the shelf logic. The serial cards just use a standard chip with standard register sets (Many chips use the same compatible registers, even todays modern SPI interface ones) and sound cards can be as simple as hanging a few resistors off a LPT port(Tho those are a pain in the ass to drive in software, so you probably just want a FM synth chip glued onto the memory bus and that's it). Something like a PATA IDE disk controller doesn't need much in the way of smarts in it (Its pretty much like a SD card with a giant parallel bus). You can essentially clone existing ISA cards and have both your clone or an original card work in there allowing you to mix your DIY cards with real ones.The cards that are hard are things like video cards or advanced sound cards with wavetable synthesis support and all that. These will have big complex and proprietary drivers and are going to take a lot of effort to get working. But today FPGAs can implement such functionality pretty easily. So if you want a capable video card id just simply put a $30 FPGA chip on a ISA card and give it modern VGA output over a resistor ladder DAC. Making the FPGA present a raw framebuffer on the bus and draw it to the screen is easy to do. Adding a text mode for consoles shouldn't be hard and from there you can add extra graphics functionality as needed. For example those features a lot of home computers had but the PC didn't. Like sprites, color palletes, smooth scrolling, bitblit etc..

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 24, 2019, 10:26:58 am
content: When I have to build my own cards, I don't see the need to stick to the ISA standard. Chances of my 'cards' being reused is close to zero. I would rather implement another bus designI have been theorizing on, just to see if it would work.The whole idea of reusing ISA video cards is because of my experimentation withthe PSoC5 as a video controller, which -due to my lack of in-depth PSoC knowledge-was harder than I expected.Could be that the PSoC5 just doesn't have the grunt to make a comfortable VGA processor,I did have some other ideas on that, but thought the PSoC5 could get me started in character mode anyway...The simpler stuff, like parallel, serial IO and basic sound etc are not an issue to make indeed. VGA and network are, though...(I have done some simpleCPLD logic in VHDLbut do not consider myself fluent enough to effectively implement an FPGA design - at least that would be quite a learning curve.)

author: Berni
author_rank: Super Contributor
timestamp: June 24, 2019, 11:16:15 am
content: That SAMBA bus in your link is meant more as a bus for use on ASICs and FPGAs rather than for card cages. It requires some digital smarts at every tap on the bus so every slot would need a chip next to it. The sort of bus only really makes sense if you have a lot of masters on a bus that all access different nodes on the bus.Things like an ISA bus are well suited for how most computers work. Pretty much all old school buses that provide fast agile access to peripherals work the same way. Its a big pile of data and address lines along with a few control signals. This works great with a single master and is very fast. So unless you have a weird oddball use case your optimal design will end up looking much like a ISA or PCI bus. Basic peripherals are nothing more than memory mapped registers so a simple memory bus is all that's needed.Im actually quite surprised about getting a Cypress PSoC chip to do VGA output using programmable logic. Im not familiar with those chips all that much but it feels like that's not quite what that miniature CPLD inside of it was meant to do. If you want to build a graphics card using a MCU then you are better off using a MCU that has what's commonly called a "LCD interface". Those basically have a simple "graphics mode only" video card inside that barfs out pixels in RGB format onto a parallel 24bit bus(8bit red 8bit green 8bit blue) from a place in RAM where a frame buffer sits. These are often used to drive high resolution color LCD displays, but can be turned into a VGA signal by simply sending it trough a R2R ladder DAC, or turned into HDMI/DVI via a converter chip. Often such MCUs also have a external memory controller that can memory map any external memory that looks like SRAM into the internal MCUs memory map (often useful when your framebuffer is too big to fit into internal RAM). But there memory controllers are always masters, so you can't use this to act as a memory slave for your Z80 to write into, so interfacing would have to be over some other method like bitbanged GPIO.If you want to build a video card yourself id recommend getting a real FPGA from Altera/Intel or Xilinx. You already bit the bullet by learning verilog, the rest is the easy part of learning how the vendor specific tools work. The real deal FPGAs are very powerful and can easily pump out some VGA. They can also act like anything you want to the host CPU that is going to be using the video card. Just by changing the code in it they can go from looking like SRAM memory to looking like ISA card to looking like PCI card or to even looking like PCIe card. Tho if you want to have high resolutions (past 320x240) you might need to add external SRAM to your FPGA so that it can hold the whole framebuffer. FPGAs don't have much internal memory because the memory they have is heavily speed optimized. Best to buy a dev board with SRAM already on it. These FPGAs can also run DDR3 memory, but you don't want to go there right away as it can be complex.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 24, 2019, 11:42:03 am
content: Quote from: Berni on June 24, 2019, 11:16:15 amYeah I know. But it would allow parallelism on bus level. I found that really appealing. Have not made it of course, just wrote and drew up some ideas on how to get a high level, smart bus interface. The bus would do all sort of higher level functions in order to allow interfacing with a lot of different techniques. I wanted from: bulk dump video bits -to- interface with an serial (uart) Arduino. Pretty wild and probably overly complex. Was fun to think it up though.Quote from: Berni on June 24, 2019, 11:16:15 amYeah that sort of is what that design is about, although I was set on using the EVE chip. Not so sure about that now. I got a feeling that a 180MHz STM32F4 would be plenty strong for some light VGA work. Must have misted the LCD display interface option. Will look at that again. The idea of the video controller was to provide a 'smart IO device'. This would allow using a protocol to convey the intent and not the bits to pass on the result... Which would cut down in needed bus bandwith. Higher level function in the video controller (STM32) would allow common graphic operations (scrolling/transparency and the likes). The external RAM would be a place for the program to store graphics (once) to be reused throughout the running program. Aim was to build a retro game console like platform.Quote from: Berni on June 24, 2019, 11:16:15 amYes I would love to build a VGA video card using an FPGA. I do not think I have learned VHDL yet, that code was painstakingly put to gether with about 2-searcher per line. I used Quartus to make the (Altera) CPLD code. Didn't understand the simulation yet, though. Anyway, can't decide if using the STM32 or the FPGA is a better choice. I am fairly inexperienced in both... (I do have an STM32F4 and an Altera Cyclone II laying around)To go a little back on topic: I think the consensus is that using an ISA video card is pretty much hopeless, unless I have a detailed example of how the driver works...?

author: Berni
author_rank: Super Contributor
timestamp: June 24, 2019, 12:34:36 pm
content: Quote from: obiwanjacobi on June 24, 2019, 11:42:03 amWell one of the products i designed uses a STM32F7 to drive a 640x480 LCD with 16bit colors while using 32MB of SDRAM to get more room to work with. It did need some optimization from the software guys to get it to run fast but it is perfectly capable of drawing a decent looking UI at that resolution with good responsiveness. Its being helped out by its built in 2D DMA that can move bitmaps around in memory and draw them onto frame buffers. Its pretty capable.But the functionality you are describing is actually more of a graphics accelerator than a video card. For a long time graphics cards in PCs never had any actual processing power. They would simply pump the video memory out to the screen. The most advanced processing they could do is a character map lookup or a color palette lookup. The main CPU still had to set each pixel one by one by writing to video memory. This is the reason why PC games looked like shit while being outdone by other home computers with less processing power while gaming consoles looked amazing in comparison. All of those computers with games in mind had crude 2D graphics accelerators hidden inside graphics chip. They would commonly draw sprites and titlemaps live from memory as it was drawn, so that the CPU only needed to update sprite coordinates or titlemap IDs while providing offset functionality to allow for smooth scrolling. All of this functionality is implemented on a hardware level and can take a good deal of CPU grunt to perfectly emulate since its drawn as fast as the CRT can refresh.Quote from: obiwanjacobi on June 24, 2019, 11:42:03 amWell an FPGA will provide more graphics horsepower when used correctly as video processing is what these chips are very good at, able to move massive amounts of pixels and do all sorts of things to them without slowing down at all. The advantage is that FPGAs can work on data as its moving trough it in a pipelined fashion, applying 10s or 100s or even >1000 operations to the data in a single clock cycle, pretty much only limited in speed by how fast it can be fed new pixels from RAM. Additionally the flexibility of the FPGA allows it to provide any interface to the outside, no matter how weird of a bus it is. This lets it connect to a Z80 as just another thing on its system bus, making for fast low latency access to the FPGA that is just as quick as reading from main system RAM.On the other hand a ARM microcontroller is forced to work on an image pixel by pixel, applying every operation step by step. This limits how much pixels it can push. Also since there is no native slave memory interface means that talking to the Z80 also takes up CPU time. Tho if you just want to emulate the graphical capabilities of a old home computer its still plenty fast enough. But getting SNES level graphics out of it might be tough work.Quote from: obiwanjacobi on June 24, 2019, 11:42:03 amYeah its way too hard to be worth it. You can replicate the "braindead barfing out pixels from video RAM" functionality of old PC video cards on a FPGA or properly equiped MCU within a day of work.To get the fancy smart autonomous pixel drawing abilities you need to step up to the Penium era of 3D graphics accelerator cards.

author: David Hess
author_rank: Super Contributor
timestamp: June 24, 2019, 12:53:05 pm
content: Another place to look for details on ISA interfacing are application notes which discuss interfacing Intel 82xx series peripherals to Z80 processors.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 24, 2019, 01:24:42 pm
content: @Berni: Yeah more accelerator like, indeed (although I see it as a layer on top of a generic video card). I like the parallel nature of the FPGA (many bits at the same clock cycle) but I fear having to implement (more) complex algorithms in logic. I know it can be done, I just don't know if I can do it.I am a software dev so programming a STM32 MCU would be (way) less of problem in that aspect. Also these MCU's come with nice external memory interfaces, that have to be implemented in the FPGA separately (I do not mind looking at sample code, but I really like to understand all code I add to my project - which would mean delving into interfacing synchronous dram - I don't know much about yet).Quote from: David Hess on June 24, 2019, 12:53:05 pmWhat app notes would that be then? Would that be the app notes of say the 8237 DMA controller - or would it be more Z80 related.(a quick search did not yield any usable datasheets that had app notes)

author: David Hess
author_rank: Super Contributor
timestamp: June 24, 2019, 02:40:40 pm
content: Quote from: obiwanjacobi on June 24, 2019, 01:24:42 pmThe ISA bus was based on the 8088/8086 bus which directly interfaced with the older 82xx series peripherals which were for the 8080. I know I have seen application notes about using these peripherals with the Z80 but practically everything is pre-web so difficult to find now. The 8255 Programmable Peripheral Interface, 8254 Programmable Interval Timer, and 8251 Communication Controller (UART) were popular targets.This examplesort of shows how simple it is with an 8255.I have a great book on the ISA interface but it is in storage and I have not been able to find it online.

author: Berni
author_rank: Super Contributor
timestamp: June 24, 2019, 03:15:58 pm
content: Yeah an ISA bus looks much like SRAM memory. The simplest and most widespread of memory busses, most buses from the era look similar.If you plan to implement complex functionality in your graphics accelerator then it will indeed be easier to implement using C code in a STM32. Getting the external memory controller up and running on a STM32 is also not very hard, just initialize it and set the correct timings and boom the external memory is part of the internal memory map. But keep in mind that this memory controller will only be usable to let the ARM CPU read and write some external SRAM or SDRAM memory. It will not be usable to for interfacing to a Z80 bus because the STM32 memory controller can only act as a master and not a slave. For the Z80 to talk to it you with need to connect your STM32 trough something similar to a LPT port that the STM32 drives with bitbanging, or implement some glue logic to adapt the timings of a Z80 bus to something the STM32 can drive trough GPIO pins in software. But a 10MHz Z80 will likely be able to execute read/write operations to the STM32 faster than it can respond to them in software so you might need to stick some NOPs around your graphics driver. Usually computers want a very fast interface to the graphics card (Hence why we kept sticking graphics card in special buses that are faster than all others).The memory interface to the Z80 with a FPGA is easy because it can instantly respond on the bus, and such vintage CPUs have very simple buses so its not hard to implement. As for memory controllers to run external SRAM frame buffer thats also very easy to do as you simply output an address on the pins and the data shows up on the data pins. Its the other stuff connected to the memory controllers and bridges that can become complex in a FPGA. You basically end up with another system bus inside your FPGA where the various modules sit on and talk to each other, so you need a switch fabric inside that routes the data around as needed, manages arbitration and priorities etc (Tho Altera has tools that automatically build this part for you) and of course the graphics accelerator itself where implementing complex functionality could become a lot of work.Since i assume its a hobby project, just do whatever sounds more fun to you.

author: woodchips
author_rank: Frequent Contributor
timestamp: June 24, 2019, 04:46:54 pm
content: Yes, that looks like my ISA bus specification.The ISA bus is simple, can't get it any simpler, so just use it with just about any chip that has a /WE and /RD pins, not R/W like Motorola.The PC bus has allocated memory areas for different functions, network, video etc which is why you won't see it mentioned, it is assumed.

author: David Hess
author_rank: Super Contributor
timestamp: June 24, 2019, 09:17:47 pm
content: Quote from: Berni on June 24, 2019, 03:15:58 pmIt is practically the 8080/8088/8086 bus so Z80 interfacing to ISA looks pretty trivial. I do not remember if the original PC buffered the ISA bus from the microprocessor bus but this is easy enough to do. I think latches or flip-flops are needed in some cases for demultiplexing but it has been a long time since I have done it.

author: james_s
author_rank: Super Contributor
timestamp: June 25, 2019, 12:17:26 am
content: Quote from: Ian.M on June 23, 2019, 06:49:44 pmThat reminds me, when I was about 14 I built an IO card based on a 8255, I think I found it in a magazine because there was no internet back then. I learned a ton of stuff playing with that thing, of course now you'd just do all that with an Arduino which is probably a lot more capable.

author: digsys
author_rank: Unknown
timestamp: June 25, 2019, 01:14:48 am
content: I was making cards for the ISA bus right up to 2003+ - mainly multi-comms > RS485, fiber > up to 4Mb. Used Altera CPLDs to do all the main bus decoding /interfacing. Life was so easy, being able to "talk" directly to any IO on the MBoardhttps://pbase.com/digsys/image/169402784https://pbase.com/digsys/image/169402785way earlier

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 25, 2019, 06:32:04 am
content: Yes, I understand how to interface SRAM, that's easy. I was thinking of SDRAM in order to have bigger video buffers (mutiple MBs) to store graphics for the program, where the higher graphics functions (in the accelerator) can reach them... Doing that in an FPGA sounds complex.About interfacing the Z80 to the ISA bus: I read that other cards can take ownership of the bus and that process goes through the DMA controller - to be honest, I did not fully understand that process - but then I have read the text only one or two times (I can be a bit slow sometimes).I do have a System Controller (PSoC5) that also plays DMA controller - perhaps I can reuse that for the ISA bus. However only have a few pins left to play with.[My setup is a bit unusual (see signature link for more info): no ROM (yet), max 1MB RAM. So at boot time the System Controller halts the Z80 and waits for serial commands from the PC. You load your program from the PC interacting with the monitor in the System Controller. When all is set, you release the Z80 and of it goes. I also support simple debugging (breakpoints and reg dumps) and you can pause the Z80 at any point.]Question is -the topic of this thread- is it worth it to spend the effort if I cannot -realistically- reuse old PC ISA cards?(I guess not)

author: james_s
author_rank: Super Contributor
timestamp: June 25, 2019, 02:44:04 pm
content: Interfacing SDRAM to an FPGA is not particularly difficult, there are lots of controllers out there already implemented that you can use in your own projects.

author: Berni
author_rank: Super Contributor
timestamp: June 25, 2019, 03:14:55 pm
content: Well you can still get a few MB of SRAM memory in a single chip at a reasonable price. Yes SDRAM is available in larger sizes for cheaper, but for a computer out of the Z80 era even having 512KB of video memory is a LOT. For example the SNES produces its impressive 2D graphics using 64KB of video memory. There are many reasons why so little video memory is used. The main one is that RAM was very expensive at the time, but even if they had megabyte sizes video memory it wouldn't really be usable at all because the CPU was too slow to draw to it fast enough to produce smooth animations. And even if you had a special GPU that can draw faster it would still be too slow because RAM back then had limited bandwidth. You could simply not update a full screen of 24bit pixels fast enough in normal consumer RAM memory, no matter what supercomputer was doing the drawing.The way they have gotten around the problem of RAM size and RAM speed is to have the GPU generate the image on the fly as it is sent out to the screen. The graphics are are drawn using tilemaps of small images that are assembled together on the fly and colored in using palletes. This allows the graphics to take up much less space in RAM and does not waste memory bandwidth updating a full raw framebuffer in RAM. The titlemap takes less space in ram while the CPU can update it by simply changing a single byte map id, saving bandwith to the CPU and memory space in the ROM for storing game levels. All of this lets the slow underpowered CPU push out a buttery smooth 60fps image even when lots of things are happening on screen.As for reusing ISA cards. You don't have to implement extra features you don't need. If you have no DMA controller then you simply leave the DMA pins unused. Dropping all of the fancy stuff makes the ISA bus look the same as a SRAM chip so its the simplest bus possible, and since its a standard that does exactly what you want its better to use it than to come up something new and proprietary that does the exact same thing in the end.And yes SDRAM or even DDR3 can be interfaced to a FPGA with premade modules, but for a total beginner id suggest staying away from that for now and stick to simple things. Not only is it extra complexity in the IDE tools to set everythyng up, but also SDRAM is a pipelines architecture and so only works fast when you do operations in blocks rather than individual bytes, this adds extra complexity to the GPU inside that has to be a bit more mindful of the future and so the logic inside also gets extra complexity. You don't want to drown in a pit of complexity from the get go and loose interest in the project because of it. Once something works and you get that sweet rush of satisfaction you can start adding extra things to it and build up the more complex features so that the project stays fun.

author: iMo
author_rank: Super Contributor
timestamp: June 25, 2019, 04:39:22 pm
content: QuoteEven I do understand your temptation to play with Z80 (I did 30y back) the planned effort is wasting your valuable time. I have here a pile of such chips from 80ties I collected over time and I know today I will never ever wire them, they will just gather the dust..As the other posters have indicated you have to go the FPGA route. Learn the verilog and the tools. FPGAs and the tools are getting much cheaper so you may afford even bigger FPGA capacities.And the others may also join your efforts when you create something "enough retro".Some time back I put a complete PDP-8 into a $5 Spartan6 XL9 (based on opencores sources), running the OS and the original apps off an SDcard (formatted as 4 doublesided RK05) @75MHz clock, and it was a big fun (and a valuable learning exercise too)..

author: james_s
author_rank: Super Contributor
timestamp: June 26, 2019, 12:18:37 am
content: I wire up old chips, it's fun. I use FPGAs too, sometimes I combine both.A significant part of the way the SNES made such impressive graphics with so little RAM is that the tiles were stored in ROM on the cartridge. A system that has to load data off of a disk needs to have a lot more RAM. 512k is still a lot for that era though, a Z80 can directly address only 128kB of space.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 26, 2019, 05:25:37 am
content: The idea of my accelerator is that there is no video RAM, at least not to the Z80 CPU. It just communicates with the accelerator at a higher level protocol. It is the STM32/FPGA that needs to access the large (SD/S)RAM during display cycles. That RAM stores the bitmaps, tiles, fonts, maps etc. Like said before, choose the FPGA and you have parallelism, better perf but added complexity and a steeper learning curve. Choose the STM32 and you get the SDRAM interface for free and I can program out more complex graphics routines in code instead of logic (I am a dev). And -a small point-, the STM32 is 5V capable, FPGA are not. I have to level shift the Z80 bus interface (minor issue).Quote from: james_s on June 25, 2019, 02:44:04 pmSo I understand. But if you know a thing it never is 'particularly difficult'. If you never have done anything comparable then it looks like a big mountain of problems in the mist. I don't even know how to include those ready made components into an FPGA project (Quartus), so... that is where I am at - super noob level (on FPGA's - on code I can hold my ground, although I am new to STM32 too - only did a few proof of concept projects).

author: Ian.M
author_rank: Super Contributor
timestamp: June 26, 2019, 07:14:41 am
content: There's a *LONG* history of graphics coprocessor cards, e.g. on the PC, TMS340 basedTIGAcards, or theIBM 8514/Acard, and its ISA bus clones. However its a *LOT* of work and a fairly deep rabbit hole to develop one for the Z80 from scratch, especially 'bare metal' on a processor you aren't particularly familiar with. IMHO your efforts would be far better spent developing a hosted Z80 system, similar in concept to the BBC micro Tube second processor interface with the Acorn or Torch Z80 units, or the Microsoft Z80 SoftCard for the Apple II. Of course it would be fairly crazy to build one now hosted on a legacy system, but small Linux SBCs with HDMI and USB are cheap and readily available, and using one as the graphics and I/O processor for your Z80 is really not so much of a stretch if you are already considering a STM32 based coprocessor.Personally I'd probably go for a Raspberry Pi - just because of the popularity, stability and OS support, with a FPGA or a CPLD + a bunch of tristateable latches for the bus interface (or possibly four 74HCT40105 FIFOs to support byte wide queued inter-processor communications). Do initial development under Linux, on a full-featured Pi then decide if you are a rabid enough purist to write a Pi side 'bare metal version' to run on a Pi Zero fitted as a daughter board to your Z80 system.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 26, 2019, 07:35:16 am
content: Quote from: Ian.M on June 26, 2019, 07:14:41 amMy Z80 'system' is already running. Okay, it's little more than CPU+RAM+SerialIO but it works and I don't plan to change it (very much). I am just looking for an easy way to expand its IO capabilities and (mis)using ISA "seemed like a good idea at the time". I am not familiar with the examples you give...? I guess the Z80 softcard was there to be able to run CPM?Quote from: Ian.M on June 26, 2019, 07:14:41 amYes, I have seen PI's being used for HMDI video, but I am also a Linux noob and wouldn't know where to start. If I had a clue how to use a PI (I have an old 1B laying around) as a video device, I would do it... Bare metal on the PI's SOC would be a bridge too far for me

author: Berni
author_rank: Super Contributor
timestamp: June 26, 2019, 08:19:50 am
content: There is a good reason why video RAM is almost always also memory mapped to the CPUThe fastest possible interface for a CPU is writing to memory locations. This gives the CPU flexibility to move data in and out of video memory in any way it likes. It doesn't have to ask the GPU to do something for it by setting a handful of registers. Rather than writing a bunch of registers to tell the GPU to change a tilemap ID it could simply write a single byte to the location where that tilemap is stored. It gets the job done with less memory operations and it allows you to DMA data between main and video memory. This means the CPU spends less time interacting with the GPU, it just writes what it wants to show on the screen to RAM and gets on with other tasks. Keep in mind that the CPU rarely writes raw pixels to the frame buffer, instead its usually just updating tilemaps, palletes or strings. And the video memory rarely contains a framebuffer at all, it usually just contains some graphics assets in the forms of small icons and sprites and the instructions on how to put them together. The icons and sprites are loaded in once and then just the instructions on where to put them are updated. Then the GPU follows those instructions in an endless loop, generating the video output at 50 or 60 fps live.There are some rare instanced in game consoles where the CPU does directly push pixels to the framebuffer. For example the Nintendo 64 on a few rare games uses direct CPU access to video memory in order to create some graphical effects. This is because the early 3D GPUs such as the one used in the N64 operate on a fairly non flexible 3D rendering pipeline and are so unable to do any special programmable functionality. The same was the case for early 3D graphics cards in PCs before unified programmable shaders became a thing.As for 5V there are some older FPGAs/CPLDs that are 5V compatible, but level shifting such a small memory bus is not that terribly hard. As for a raspberry pi, you most definitely don't want to run bare metal, its way too complex and undocumented. But you can still just let it boot into a linux console and autorun your C++ app on boot. If you ever wrote software for windows then linux on ARM is not that much different. From there you can use OpenGL to get full hardware accelerated graphics with 3D support and programmable sharers. Very powerful but if you ask me sticking a modern day mobile GPU onto a Z80 doesn't make for a very satisfying retro experience because its suddenly capable of the 3D graphics equivalent to a typical early Windows XP machine.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 26, 2019, 11:29:08 am
content: Quote from: Berni on June 26, 2019, 08:19:50 amOkay, that is what I would call a higher level interface. The fact that the Z80 'thinks' its writing to RAM can be implemented in several ways. My point was that I was not planning on the Z80 moving the graphic bits to the video RAM - where the video controller would simply display them.Depending on whether a 180MHz STM32F4 is fast enough for a 20MHz Z80 to simulate some virtual RAM, I may need to use real RAM - because I guess the program (Z80) may at one point want to read back what the display state is. There are dual ported RAMs (with on one side a serial interface)... Haven't decided on those details yet.Quote from: Berni on June 26, 2019, 08:19:50 amNah, I don't think level shifting would be a problem. 5V FPGAs are a pain to find and relatively expensive.Auto booting into a custom app sounds like a nice solution (C/C++ is no problem), but I'd have to learn the API to work with the GPIO header pins (the interface to the Z80 system) - assuming there is one. Not sure if OpenGL is the only option. Did work with it once on windows in the late 90's and was pretty overwhelmed. I am not targeting a full 3D Gfx engine here, more the platform tile mapped scrolling kinda graphics.But the interface with the Z80 would be IO based, unless I let the PI montor the Z80 bus and intercept certain writes (and read) to a specific Memory segment. It would have to decode my 20-bit address bus in that case, which would mean I need 30+ IO pins on the PI...Could work, though...[thinking...]

author: Berni
author_rank: Super Contributor
timestamp: June 26, 2019, 02:32:24 pm
content: Well thing is that software emulating a parallel memory bus is hard work. Even a slow 20MHz bus is actually pretty fast in terms of latency. Sure MCUs have interrupts but a modern ARM take about 10 to 20 or even more cycles to enter an interrupt routine because it has to context switch. So even if it takes 10 cycles and you have a 180 MHz CPU you can only enter an interrupt at a rate of 18MHz, but this doesn't include the time taken to also exit it so that the interrupt can be called again, halving it again to 9MHz. And this is without any code inside the routine, as soon as you add actual code that does something it will take even longer to complete the interrupt. So this makes it very difficult for a MCU to pretend as being SRAM on the bus. What is easier to do is to talk to the MCU over something like a parallel port since in that case the Z80 can talk to it however slowly it wants. But you could implement something in between by having a dual port FIFO chip for write operations to the MCU. That way the Z80 can barf data at it at full speed and get back to doing other things while the MCU works trough it as its own pace. So then only read operations would be slow.All of this means you also can't really use a Raspberry Pi GPIO bus to directly connect to a Z80 bus. Sure the CPU might run at 1.2 GHz but its still not responsive enough because GPIO is on a slower peripheral bus, interrupt latency is really long and running linux means the CPU is constantly interrupted by the OS scheduler so response times are all over the place. As for getting OpenGL working there is a nice simple library for it called RayLib (https://www.raylib.com/) and you don't have to use it for any 3D, works for 2D just as well but all of that 2D is done in hardware by the GPU so its very fast.On the other hand a FPGA could handle running a Z80 bus at 200 MHz just fine while simultaneously generating 4K video output and emulating a FM synth with 32 voices. Actually mplementing a simple GPU in a FPGA is not all that hard. Tilemaing, sprites and ROM text are easy, because its just a matter of looking up the correct pixels in memory. Things get more complicated if you want fancy features like the SNES Mode 7 effects and similar things from the 16bit era. These simple GPUs also usually have no features for drawing lines or shapes (They tend to get some of those abilities once they are for 3D ).In general FPGAs are very useful with retro computers because they can interface to pretty much anything, allowing you to easily implement custom addin cards, coprocessors, accelerators... etc by simply loading new firmware into a FPGA chip. Makes it easy to emulate the custom hardware on motherboards from home computers like a C64, AppleII etc. heck even the entire Z80 could run inside the FPGA, and run faster than your real chip even, but emulating the entire system inside a FPGA doesn't really have as much of a retro charm to it.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 27, 2019, 12:11:44 am
content: This may be of some interest:http://tasvideos.org/5384S.htmlTl;dr is, the guy used a menu corruption glitch to get ACE on the GBC, effectively making the controller port a parallel data port to bootload code. This is not nearly enough bandwidth to stream video controller register data through the CPU (which would be the easiest way to play e.g. graphics from another game on the same console, simply playing back a log of register data obtained from an emulator). Instead part of the display routines were recreated, and display state changes were streamed. Essentially, this constitutes a very special purpose and high level data compression format.Since you have so much horsepower in the STM, you might consider crafting a display command protocol that offers various powerful, rich and customizable primitives, and transmit display state change information instead. This would be built very much like modern GUI programs, where you write the main backend code which runs in one thread (which would be on the Z80), while the OS handles the graphics objects and rendering and interaction. (You'd still run interaction through the Z80 I suppose.)Tim

author: Berni
author_rank: Super Contributor
timestamp: June 27, 2019, 05:44:25 am
content: Dang that does look impressive.I have seen quite a few arbitrary code execution exploits but i never seen video streamed to the screen using controller input.But yeah the best fitting type of graphics acceleration functionality depends on what you want to run on it. Things like 2D games all make heavy use of titlesets and sprites because often the entire screen is being updated anyway and game levels are large so they can't be stored as one bitmap. For something like a UI you mostly want everything as a big bitmap, but all you really need is decent 2D bitblit to move them around, since you typically just need to plonk down premade image segments to assemble a gui along with perhaps filling in rectangular areas. Typicaly graphics chips take one of the other approach, but i don't see why you couldn't have both overlapped.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 27, 2019, 06:16:18 am
content: Quote from: Berni on June 26, 2019, 02:32:24 pmHmmm, sounds plausible...On the other hand a Z80 memory read/write cycle takes 4 clock cycles (IO reads/writes take 5 cycles). So there would be 'only' 5MHz worth of reads/writes... Also the program would probably only write to 'tilemap' RAM every so often. I do not expect a mem-copy type of operation. More some sort of game logic that decides its time to move the 'sprite' one position to the left. So the frequency of actual writes is even lower.I have no experience (to speak of) with the STM32F4 (I was planning to use) so I didn't consider interrupt setup times. Thanks for bringing this to my attention.I also have to considermy memory managementpage size (which is 4k). It stands to reason that these video-related memory parts are mapped and aligned on those boundaries. I can put any 4k memory page from a 1MB pool anywhere in the 64k Z80 address space (except page 0 - which is fixed).Quote from: Berni on June 26, 2019, 02:32:24 pmYes, the FPGA sound better and better all the time. However I am still very wary of the learning curve involved. Especially with the more advanced functionality.Quote from: T3sl4co1l on June 27, 2019, 12:11:44 amThanks, will take a closer look at this.Quote from: T3sl4co1l on June 27, 2019, 12:11:44 amYep, that was the idea. Exactly how to protocol will look, I don't know yet. I guess I will try a few things to see what works best (state-change-based, operations, share memory, etc)

author: Canis Dirus Leidy
author_rank: Regular Contributor
timestamp: June 27, 2019, 10:01:46 am
content: There is another example:fasten the ISA card to Z80 usingcrowbar and some kind of mothersome 74 chips as glue logic.P.S. And another (but without ISA) example:how to use Chinese 4.3" LCD as display for your Radio-86RK/ZX Spectrum clone.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 28, 2019, 09:07:27 am
content: The video card seems like a very easy card to interface with. It would be interesting to know where he got the information of which registers to use etc. - a quick search did not reveal anything obvious.I suspect that VGA card is an order of magnitude more complex, though...I have also looked at LCD interfaces on STM32's. What I gather from them is that they are meant to drive LCD directly. I am looking for VGA -and perhaps scart. (I don't know anything about HDMI/DisplayPort and want to keep it simple). The SMT32F4 I have, does not have an LCD interface.

author: Berni
author_rank: Super Contributor
timestamp: June 28, 2019, 09:44:44 am
content: Yes the LCD interface on a STM32 is meant for driving a color LCD directly as the name would suggest.But the thing is that the parallel RGB interface evolved out of existing video standards like VGA. Because of that it has a Vsync and Hsync signal that works the same as the sync signals in VGA. But it makes no sense to feed a analog video signal into a digital display like a LCD, so the analog R G B signals are simply sent in the digital form as a value on a digital bus. The only new signal that VGA does not have is the pixel clock, this is needed because the LCD needs to know exactly where each pixel begins and ends. So because of this you can simply connect a R2R resistor ladder DAC to those digital pins to turn the color signals back into analog form and level shift the Vsync and Hsync to the correct voltages and you now have turned the LCD interface into a analog VGA interface. All you need to do is set the LCD interface for valid VGA timings for the resolution you want.Most other digital video interfaces are just different ways of packaging up this parallel RGB bus. Like the LVDS used in laptop LCD displays? Thats just the whole RGB bus fed into a serdes chip. And DVI? Well that's almost the same as LVDS but serialized differently with some extra info. And HDMI? That's just DVI with extra coding on top and audio inserted in the display blanking periods. Because of this you can get a chip that converts this raw parallel RGB bus into pretty much any other video format, including VGA.Its when it comes to Composite, Component, SVideo etc... when its not as straight forward as those have roots in the beginning of color television. Because of that they use a different color space YUV and they differ in timings and modulation methods depending if you want to feed it into a PAL, NTSC or SECAM television, also it uses that dreaded interlacing too. Tho you can probably still generate a black and white composite video signal by feeding just one of the RGB colors into a DAC and setting the timings to match PAL or NTSC. But why would you do that when you can get nice 24bit high resolution VGA out of it using just a handful of resistors.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 28, 2019, 11:11:43 am
content: TheSTM32F4 advanced seriesI am looking at only have a serial MIPI LCD interface...Right, I thought scart also had vsync and hsync... no scartIf I will use a R2R network or one perhaps something like aADV7125I don't know yet. I probably start simple and upgrade when needed (chip is 12,= euro ex vat @ Farnell).BTW: Berni, I really appreciate talking with you like this, thanks!

author: Berni
author_rank: Super Contributor
timestamp: June 28, 2019, 03:46:54 pm
content: As far as i can see the datasheet claims that the STM32F469 is capable of both 24bit DPI RGB (aka parallel RGB) and 16bit DBI interface along with single lane MIPI DSI in both video and command modes.The one you want is 24bit DPI RGB because this is the raw RGB bus that is this "VGA in digital form". The DPI stands for Display Parallel InterfaceThe other stuff is a bit more complicated and is more specific to LCDs. The DBI mode i think stands for Data Bus Interface. This is similar to the 16x2 character LCD displays where the display has a SRAM like data bus. These type of displays have a built in LCD controller and framebuffer, so the display is connected to the main system bus just like SRAM, EPROM or peripherals and the CPU writes into the framebuffer RAM located inside the display and send it commands by writing into its registers. Its sort of a LCD with a built in "graphics card". This is mostly designed to be driven by slow CPUs without a built in controller.Then MIPI is mostly just a extra protocol layer on top of this to send it over a single diff pair. The video mode is DPI RGB sent in the form of packets and command mode is this DBI mode where write/read commands are wrapped up in packets and sent over the high speed serial link. This is a modern bus and is difficult to work with so its only usefull if you come across a LCD display with a MIPI interface already on it(Most phones have such displays).Tho i suppose if you you want the functionality of a DBI LCD display but have VGA output you could use just the controller chip. For example Solomon Systech makes a lot of these such as:http://www.solomon-systech.com/en/product/MobileDisplay/Display_Controller_IC/ssd1962/http://www.solomon-systech.com/en/product/MobileDisplay/Display_Controller_IC/ssd1906/They don't have the datasheet on there website but if you google the partnumber you can easily find it. It has the full register set and describes how to run it. And since its a DBI interface means it looks like SRAM so it can be stuck directly onto a Z80, 68000, 8086 etc.. bus So if you stuck this chip onto a ISA card with a VGA DAC you would have essentially made a graphics card for a PC, but one that you have a full datasheet from.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 28, 2019, 07:17:56 pm
content: Quote from: Berni on June 28, 2019, 03:46:54 pmYeah, typically parallel bus LCD controllers can be ran from the FSMC, along with other RAM/ROM you may need; or DBI or whatever else. (It's also easy to run from a GPIO port, of course.)Tim

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 29, 2019, 06:37:56 am
content: Doh! I didn't look past the STM32F4 advances series overview page. I see it now in the datasheet.Those display controller chips sure look nice (and cheap $3-4 on ebay). That would offload the STM32 considerably.I have foundthis datasheetand the LCD output signals seem to be VGA compatible (perhaps with some simple glue logic).Excellent suggestion, thanks!I don't see how you could use the FMC for two things, though.Simply by using a CS for one or the other (like with SPI)?That would be like bank switching memory....High level it would look something like

author: Berni
author_rank: Super Contributor
timestamp: June 29, 2019, 07:28:34 am
content: I can't really say that i agree with that block diagram. There is no point in connecting a SSD1963 to a STM32F446The STM32F4 has a built in LCD controller that is capable of generating DPI RGB video directly out of its pins, so there is no need for the SSD1963. If anything the external display controller will slow things down because the memory bus connecting the controler to the STM will likley be slower than the internal RAM of the STM32. Additionally the SSD1963 provides no "graphics acceleration" functionality, it just has a dumb raw framebuffer you write pixels into. Well if you go to a SSD1921 you do get bitblit functionality but it doesn't have a whole lot of graphics RAM so this functionality becomes useless once you get to higher resolutions.The STM32 already does all the graphics you want on its own. It has a LCD controler capable of outputting RGB with VGA timings at decent resolution. Additionally has what they call DMA 2D and this is essentially a simple 2D GPU that can bitblit images around anywhere in memory and do things like alpha blending and pixel format conversion. All of this without any CPU intervention.As for putting multiple devices on the STM32s FMC memory controller that works the same way as you put multiple things on your Z80. Trough address decoding you can automatically toggle chip select pins appropriately. Or since ST has thought of that for you the FMC actually has some CS pin outputs. This allows it to map various memory regions to various chips and automatically selects them when needed. As a bonus using the multiple chip select channels of the FMC also allows you to set it up for different bus timings for each device (Very useful if you have a device that is slower than all the others).The main reason why i have sugested the Solomom Systech SSD19xx chips is that they have a memory slave bus. This means a SSD19xx chip can be directly connected to the pins of a Z80. You still have to slowly software emulate the bus on a STM32 where it is likley going to have trouble going at full bus speed due to latency issues.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 29, 2019, 08:05:39 am
content: Yeah, if you're going to use something like that, you might as well put the display right on the bus, run it right from the Z80. Integrated (COG) display panels are cheap and plentiful, and 16 bit interfaces are very common (you'll still need some logic to sort out the 8-bit bus accesses somehow -- perhaps by latching the low byte then writing the panel when the high byte is written?).You'll probably want a pretty small LCD, to keep reasonable fill rate; 320x200 would be about the most, or kinda pushing it IMHO. Last display I used was a 160x128 panel over SPI, which had probably half the bandwidth your Z80 bus is capable. That took a good 100ms or so to fully redraw, so I think you'd be able to get limited video through one, assuming you can bring in the data of course.If you want a bigger display without sacrificing fill rate, a more advanced controller -- whether written yourself (STM32 or what have you) or with accelerator hardware -- will be required.Tim

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 29, 2019, 09:08:16 am
content: Quote from: Berni on June 29, 2019, 07:28:34 amIt does? I couldnot find any referenceto an LCD controller/interface.It does have some HDMI-CEC thingy I don't understand, but I assumed that is a different beast. Note I am specifically looking at the STM32F446(ZE) here -that's the one I've got.Also, the idea is to make a smart video accelerator that off-loads the Z80. Putting the display controller on the Z80 bus would put the Z80 in charge of filling the video ram and all the 'accelerating' is done by the Z80... Not what I was shooting for. And I want to reuse existing VGA monitors. I might buy a small LCD board (with an SDSD1963 on it) for experimentation and development, but ultimately I want to be able to plug in my monitor(s) - VGA or other.The Z80 bus <=> STM32 interfacing is something I need to look into, yes.

author: Berni
author_rank: Super Contributor
timestamp: June 29, 2019, 09:51:38 am
content: Well i did manage to run a small display over SPI displaying a youtube video at a reasonable framerate. The worst part was actually the tearing problem because the LCD refresh was not synchronized to the updating of the frame buffer. But this sort of thing was done using a Rasperry Pi using a driver where the CPU would figure out the best way to update the display (it avoids updating areas that haven't changed) and then use the DMA to have the SPI at 32MHz going full wack at 100% utilization to max out the transfer speed and avoid any pauses in between bytes. That big fast ARM CPU in there was working pretty hard to make it happen.So yeah if you plan to make fast paced smooth scrolling games run on it then the Z80 will indeed lack the horsepower to fill the framebuffer for a large resolution screen. But for a GUI this is perfectly fine and its pretty much how GUis ware made even into the 32bit era of PCs. When doing a GUI large potions of the screen stay static so not nearly as many pixels need to be moved around. It used to be pretty standard to see GUIs draw out step by step infront of your eyes in the 8bit era because it takes the slow CPU a few frames to draw everything.This is why consoles in the 8bit and 16bit era had no framebuffers and instead generated tile maps and sprites on the fly. But all these sprite based graphics chips that do this tend to be proprietary and designed for the application, such as the C64 VIC chip or the PPU chip in the SNES. But if you want to have the graphical capabilities of a DOS PC that SSD19xx chip sitting directly on the Z80 bus is all you need.Ah yes you are correct the STM32F446 you sugested does indeed not have any LCD controller built in. So just use a different chip from the STM32F4 family that does. Not all applications need a display so they don't put this peripheral in all chips.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 29, 2019, 04:20:05 pm
content: Quote from: Berni on June 29, 2019, 09:51:38 amIt is.Quote from: Berni on June 29, 2019, 09:51:38 amA character only controller is not what I am shooting for.Quote from: Berni on June 29, 2019, 09:51:38 amNot sure yet - depends on how that LCD interface works. If its all hardware, then yes. If takes a good chunk out of the CPU core(s) then I might not have enough cycles left for the interfacing with the Z80 bus. I need to look into that first, I think and I can do that with the STM32F446 I've already got.

author: Berni
author_rank: Super Contributor
timestamp: June 29, 2019, 06:13:35 pm
content: Quote from: obiwanjacobi on June 29, 2019, 04:20:05 pmI meant the graphical capability these PCs had. They had bitmap graphics modes where the CPU needed to write every pixel. The exact capabilities varied depending on how fancy of a graphics card you had, but in general the fancy cards simply had more colors at higher resolutions.Quote from: obiwanjacobi on June 29, 2019, 04:20:05 pmThat's exactly the point of having a LCD controller so that the CPU doesn't need to do anything. All it has to do is point it to where in memory the image it wants to display is located and tell it what resolution and timings to output it as. Additionaly having that DMA 2D feature then also allows you to bitblit images into that framebuffer without the CPU doing anything else but telling it where to draw it.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 30, 2019, 06:34:44 am
content: Quote from: Berni on June 29, 2019, 06:13:35 pmLike I've said - going for the accelerator type, where most of the grunt work and heavy lifting is done inside the video controller/accelerator.Quote from: Berni on June 29, 2019, 06:13:35 pmI would think so too, but I didn't read the datasheet yet and tried to make no assumptions. I think the STM32 solution depends on whether I can get the Z80 bus interface running fast enough - with time to spare to do the actual 'accelerating'. Also the FPGA solution is still in the race - but that requires me to get to know one of the HDLs a lot better in order to see if I can get those accelerator functions working in logic.I am currently working on another (software) project, so it could be a while before any of this will be tested. I started the thread to verify my ideas on reusing those ISA PC cards... (and we all know how that went)

author: obiwanjacobi
author_rank: Super Contributor
timestamp: July 20, 2019, 10:15:15 am
content: Wow that ltcd interface does everythinghttps://www.st.com/resource/en/application_note/dm00287603.pdf&ved=2ahUKEwif1qKuocPjAhVNExoKHdxcBzwQFjAFegQIBBAG&usg=AOvVaw0ntzMPTV-Mg3Q7C8cY3_NH