Jump to content

FPGA as graphics card?


Mutz03 Zockt
 Share

Recommended Posts

On 12/29/2021 at 8:47 AM, Mutz03 Zockt said:

... so i may have maybe not used the right term here.
what i tried more to say, is, that i think the goal was to build a computer with 5V ASIC chips, not depending if they were avaiable in the 80s.

but still i do beleve, that if commodore made his in the 80s, they would at least have had the Vram seperately and some other capabilities wich the Vera chip now has would have been seperately. ...

In the 80s, sure, it would have been separate VRAM just like the MOS 8563 in the C128, for exactly the same reasons. An integrated RAM component would have been prohibitively expensive. It would have been DRAM, for cost reasons.
Today, the integrated RAM comes with the commodity priced FPGA part, so that's the cheaper approach.

Whether it would have all been that integrated ... I guess it depends on whether it was TED philosophy Commodore or Commodore 128 philosophy Commodore.

Link to comment
Share on other sites

On 12/29/2021 at 5:55 AM, Mutz03 Zockt said:

im gonna leak a bit here, because the developement of my proect is technicly still unnanounced and secretive.

but i and a couple of friends of mine are right now developing on a CX16 Graphics solution with only ASIC chips.
the main idea is to use CPU driven graphics. A circuit witch displays the content of a deticated Vram out onto a VGA port (ben eather made a excelent Video about that) and with a bit of enhancing you can use that circuit fairly well.

then we are planning on using a Motorola 68K CPU because it has a 24bit adressbus, wich means support to up to 16Mbyte ram, witch we gonna use almost nothing of it, because 256Kbytes are enough for the simple prototype first.
(ideas of supporting higher resolutions and so on more ram are existing, we just dont want to bite more than we can chew.)
this CPU should then make all the Tilelogic, sprites and look up of two character sets, one is hardcoded in rom, and the other one is loadeable...

as i said, it is still in early developement, but i have high hopes that it may work fairly well.
(I do not expect or even hope that it gets added to the CX16 stock, but maybe it will be a fun addon card)
 

I think that's going to require much more than a bit of enhancing. I don't want to discourage you, but I would encourage you to focus on crawling before flying. How will communication between your card's CPU and 6502 take place? The 6502 bus has strict timing constraints that are extremely difficult to meet via software implementation on a microcontroller. It's pretty much impossible to handle 6502 bus IO using interrupts on the 68K because that CPU has a 44 clock cycle minimum latency to service interrupts. An 8MHz 6502 bus read has an allowance of about 50ns from the rising edge of PHI2 until the data needs to be stable on the data bus to meet the data setup time constraint (tDSR in the datasheet, I think). If you're using all discrete logic, the fastest discrete 7400 series logic chips have a propagation delay of 4-8ns under ideal circumstances. The problem could probably be solved if you're sufficiently clever, but it would be quite the labor of love compared to just sticking a low cost FPGA in there for interfacing with the 6502 bus.

  • Like 1
Link to comment
Share on other sites

On 12/29/2021 at 9:28 AM, Ed Minchau said:

Like on the X16, VERA would have been a daughter board, in much the same way Soundblaster was. Those edge connectors can have lots of pins.

The original VERA looked much like a video chip in an odd package, containing only pins. The video ports were on the X16 board. Regardless that doesn't address the issue raised with regard to the necessary bus widths to meet VRAM latency requirements. I don't follow the relevance of the edge connector width.

Link to comment
Share on other sites

On 12/30/2021 at 2:22 PM, Wavicle said:

The original VERA looked much like a video chip in an odd package, containing only pins. The video ports were on the X16 board. Regardless that doesn't address the issue raised with regard to the necessary bus widths to meet VRAM latency requirements. I don't follow the relevance of the edge connector width.

The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.

Link to comment
Share on other sites

On 12/30/2021 at 8:48 PM, Ed Minchau said:

The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.

The problem is the number of pins needed by the component that ultimately composes the line buffer. It must be able to perform 32 bits worth of access to a 128K VRAM space every 40ns. Using 1980s era tech, one could only hope to do this by making the data and address paths wide. Making the data bus 32 bits and using a non-multiplexed 15 bit address bus might put the goal within reach, but that is 47 pins taken up just for the basic address and data bus. The chip will also need power, ground, clock, reset, data direction, video out signals, and some sort of interface to the host.  I'm not aware of any 8 bit system that had a DIP component larger than 40 pins; nor any DIP component larger than 64 before everything went SMT.

Compare this to the C128D (probably the Apex of real 8 bit systems) which used the 8563 VDC with an 8 bit wide data bus to DRAM chips with a multiplexed address bus. The best case transfer rate for those chips was 8 bits every 230ns (~0.035 bits per nanosecond). VERA requires a bandwidth of 0.8 bits per nanosecond, 23 times faster than what the 40 pin VDC could achieve.

That's the fundamental problem that would have to be solved to make a 1980s era VERA.

Incidentally, the largest package Commodore was capable of manufacturing was 84 pins. This is what constrained Fat Agnus on the Amiga line. They could make that a PGA or PLCC, not DIP.

  • Like 1
Link to comment
Share on other sites

On 12/30/2021 at 10:09 PM, Wavicle said:

I think that's going to require much more than a bit of enhancing. I don't want to discourage you, but I would encourage you to focus on crawling before flying. How will communication between your card's CPU and 6502 take place? The 6502 bus has strict timing constraints that are extremely difficult to meet via software implementation on a microcontroller. It's pretty much impossible to handle 6502 bus IO using interrupts on the 68K because that CPU has a 44 clock cycle minimum latency to service interrupts. An 8MHz 6502 bus read has an allowance of about 50ns from the rising edge of PHI2 until the data needs to be stable on the data bus to meet the data setup time constraint (tDSR in the datasheet, I think). If you're using all discrete logic, the fastest discrete 7400 series logic chips have a propagation delay of 4-8ns under ideal circumstances. The problem could probably be solved if you're sufficiently clever, but it would be quite the labor of love compared to just sticking a low cost FPGA in there for interfacing with the 6502 bus.

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register.
i have not thought out everything completely, but i am trying, and not really confident that it will work well.

just the idea and the proof of concept would be cool.

  • Like 1
Link to comment
Share on other sites

On 12/31/2021 at 9:30 AM, Mutz03 Zockt said:

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register. ...

Yes, you can use a register to buffer a write from the 65C02 bus and buffer the five address lines to know where the write is going.

The bottleneck is the read from the 65C02 bus. A Vera register is read in a single clock cycle, so you might need a register file for some of the Vera registers.

Edited by BruceMcF
Link to comment
Share on other sites

On 12/31/2021 at 5:32 PM, BruceMcF said:

Yes, you can use a register to buffer a write from the 65C02 bus and buffer the five address lines to know where the write is going.

The bottleneck is the read from the 65C02 bus. A Vera register is read in a single clock cycle, so you might need a register file for some of the Vera registers.

thats fine though, it doesnt have to be extremely fast and accurate, i just want to build something wich is not a FPGA

 

  • Like 1
Link to comment
Share on other sites

On 12/31/2021 at 1:20 PM, Mutz03 Zockt said:

thats fine though, it doesnt have to be extremely fast and accurate, i just want to build something wich is not a FPGA

If you are just building something which isn't an FPGA, then a mix of the way the 80-column chip from the C128 and the way the Vera interfaces could be used.

Two registers, one is the address register for the other. The "address" register is just a register, which allows for up to 256 register addresses for the second, which is a normal 65C02 register. But if you limit it to 128 register addresses, the top bit can specify whether it is going to be a read or a write, and if a read, it can pre-fetch the value for the data register location.

And VRAM data port, and two address registers, with the bottom two or three bits implied $00 when the low address register is set, and incrementing after a read or write of the data port. Then a counter provides the bottom bits, with the reset for the counter set to the write of the bottom address register. That allows for 256K or 512K of VRAM.

That whole approach is quite different from the strategy that was used for the VIC-20, C64, C128 etc., with an FPGA being the closest feasible hobbyist equivalent to the CBM approach of building a dedicated ASIC video chip. But there's obviously no rule about sticking closely to that approach ... building the display from discrete electronic components is more like the Apple I approach, though I take it that you are aiming at a substantially more capable display.

Edited by BruceMcF
Link to comment
Share on other sites

On 12/31/2021 at 6:30 AM, Mutz03 Zockt said:

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register.
i have not thought out everything completely, but i am trying, and not really confident that it will work well.

just the idea and the proof of concept would be cool.

There are (or were) logic chips specifically for mailbox registers. E.g. 74xx172 (which I cannot find a source for) provides multi-ported access to eight 2-bit registers or 74xx670 (which has a long 45ns propagation delay) has four 4-bit registers @ $2/each. You could create your own using discrete components; if you do so and meet the bus timing constraints, then my hat's off to you.

Link to comment
Share on other sites

On 12/31/2021 at 3:38 PM, Wavicle said:

There are (or were) logic chips specifically for mailbox registers. E.g. 74xx172 (which I cannot find a source for) provides multi-ported access to eight 2-bit registers or 74xx670 (which has a long 45ns propagation delay) has four 4-bit registers @ $2/each. You could create your own using discrete components; if you do so and meet the bus timing constraints, then my hat's off to you.

If you want a mailbox, and have active processing on both sides, you can use dual ported SRAM, though that might not be period specific enough.

Link to comment
Share on other sites

On 12/25/2021 at 5:23 PM, Ed Minchau said:

Look at it this way: in the 1980s, Commodore had their own chip fabrication plant.  That's how they produced things like the VIC chip and VIA chips for audio and video for the VIC-20.

The VERA daughterboard is definitely something Commodore could have done in the 80s, though it would be a much bigger board.  And of course we're already using 512kb RAM ICs, which for Commodore would have been an enormous PCB flooded with 2kb RAM chips.  Point is, Commodore could have produced VERA, and all the rest of the Commander X16.  Their only real obstacle would be the RAM, and SD storage was just a dream back then.  An FPGA like VERA would have been a factory-programmed gate array rather than field programmable, or several such ICs.

The ATtiny used for Reset and power on wouldn't have been present on Commodores because of the external power box feeding a single voltage to the computer, but if they had needed something like that it would have probably been done with a special-purpose chip that they fabricated themselves as well.  It isn't doing a whole bunch of 16 bit or higher math, and might have been implemented with a bunch of TTL logic gates instead.  If they were putting 2Mb of banked RAM in a machine, the case would already be big and would contain lots of PCBs, so what's one more?

Then again, there are a few "crochet hook" ideas that in hindsight, should have been dope slap obvious, but back in the day no one ever thought of.

Take stacked RAM.  The idea of stacking four to eight DRAM dies using through-silicon vias, plus DRAM refresh logic and possibly a DMA and/or MMU on a package no larger than a then-typical DIP should have been blindingly obvious, but it didn't happen.  Done right, a 64K Pseudo-SRAM version should have drawn no more power and/or generated no more heat than an 8K SRAM on the same package, and massively reduced the chip count of, say, the Commodore 64 and subsequent follow-up motherboards.

Unity Semiconductor, creators of CMOx Flash, was poised to turn the nonvolatile RAM market upside-down, but then they were bought out by Rambus, which scared all possible potential licensees off, due to Rambus' reputation as sharks.  They had white papers that it could have been produced on conventional CMOS tools, and tested the concept at a five micron node.

Edited by Kalvan
Link to comment
Share on other sites

I will point out that VERA has been recently cloned (re-implemented) for the Roscoe 68000 based retro computer.

https://www.tindie.com/products/rosco/xosera-fpga-video-r1/

Doesn't look like it re-uses any of Frank's work, but rather the same features have been implemented on an upduino and modified. Same 120K video memory, etc.

I really like the 16:9 aspect ratio option that was added for those that do not have an old monitor hanging around.

No mention of sprites here, which makes me wonder if they are implemented. 

They did add an Amiga style co-processor (copper).

It is nice that it is already open sourced.

Edited by Lasagna
  • Like 1
Link to comment
Share on other sites

On 1/6/2022 at 1:43 PM, Lasagna said:

I will point out that VERA has been recently cloned (re-implemented) for the Roscoe 68000 based retro computer.

https://www.tindie.com/products/rosco/xosera-fpga-video-r1/

Doesn't look like it re-uses any of Frank's work, but rather the same features have been implemented on an upduino and modified. Same 120K video memory, etc.

I really like the 16:9 aspect ratio option that was added for those that do not have an old monitor hanging around.

No mention of sprites here, which makes me wonder if they are implemented. 

They did add an Amiga style co-processor (copper).

It is nice that it is already open sourced.

I like that they based it around the Upduino and Icebreaker which are relatively easy to get.

That said, this looks more like a VERA-inspired project and not a clone. It has a few features that VERA does not, but if I'm reading the RTL correctly, there is no space available for sprites. The VRAM data path is 16 bits wide, clocked at the dot clock frequency, and playfields have priority. Since the effective memory bandwidth is 2 bytes per dot clock, there are no spare cycles for anything else (e.g. sprites, host VRAM access) with two playfields active. Reading or writing to memory during active display may only take place during blanking periods. It looks like software needs to check a VRAM read/write address register to make sure that VRAM access goes to the intended location. While only allowing access during HBLANK or VBLANK was a common limitation for several early computers and consoles, it was not for the C64 and is not for VERA.

I know widening the VRAM data path is listed as a TODO item, but the Upduino+VGA version's FPGA has used 100% of the BRAM and 83% of the LCs. Sprites are a pretty big deal on retro hardware. I think the design would be vastly improved by completely dropping the second playfield in favor of sprites.

  • Like 2
Link to comment
Share on other sites

On 1/7/2022 at 2:06 PM, Wavicle said:

I like that they based it around the Upduino and Icebreaker which are relatively easy to get.

That said, this looks more like a VERA-inspired project and not a clone. It has a few features that VERA does not, but if I'm reading the RTL correctly, there is no space available for sprites. The VRAM data path is 16 bits wide, clocked at the dot clock frequency, and playfields have priority. Since the effective memory bandwidth is 2 bytes per dot clock, there are no spare cycles for anything else (e.g. sprites, host VRAM access) with two playfields active. Reading or writing to memory during active display may only take place during blanking periods. It looks like software needs to check a VRAM read/write address register to make sure that VRAM access goes to the intended location. While only allowing access during HBLANK or VBLANK was a common limitation for several early computers and consoles, it was not for the C64 and is not for VERA.

I know widening the VRAM data path is listed as a TODO item, but the Upduino+VGA version's FPGA has used 100% of the BRAM and 83% of the LCs. Sprites are a pretty big deal on retro hardware. I think the design would be vastly improved by completely dropping the second playfield in favor of sprites.

Well, maybe for the Xosera II, they could use a bigger FPGA to implement hardware sprites.  Since this version doesn't seem to include the sound channels and FIFO, presumably that should leave some room in the FPGA for more features.

Link to comment
Share on other sites

  • 6 months later...
On 1/7/2022 at 7:06 PM, Wavicle said:

I like that they based it around the Upduino and Icebreaker which are relatively easy to get.

That said, this looks more like a VERA-inspired project and not a clone. It has a few features that VERA does not, but if I'm reading the RTL correctly, there is no space available for sprites. The VRAM data path is 16 bits wide, clocked at the dot clock frequency, and playfields have priority. Since the effective memory bandwidth is 2 bytes per dot clock, there are no spare cycles for anything else (e.g. sprites, host VRAM access) with two playfields active. Reading or writing to memory during active display may only take place during blanking periods. It looks like software needs to check a VRAM read/write address register to make sure that VRAM access goes to the intended location. While only allowing access during HBLANK or VBLANK was a common limitation for several early computers and consoles, it was not for the C64 and is not for VERA.

I know widening the VRAM data path is listed as a TODO item, but the Upduino+VGA version's FPGA has used 100% of the BRAM and 83% of the LCs. Sprites are a pretty big deal on retro hardware. I think the design would be vastly improved by completely dropping the second playfield in favor of sprites.

Sorry to resurrect an old thread here, but I just found this and thought I’d correct a few assumptions 🙂

First off, you’re totally correct that Xosera is not a VERA clone, but it is inspired by VERA. Given our primary target is a 16-bit rather than an 8-bit, we changed things that it made sense to change, and what we wound up making was much closer to the Amiga hardware than the C64 - not because the C64 hardware isn’t great, but because Amiga fits our interests more.

You’re right that we don’t have hardware sprites at the moment, but your read on memory bandwidth is not quite correct - in fact we have multiple subsystems with memory access on a per-pixel basis. Obviously the display hardware has to fetch pixels on every dot clock, but because of the way we’ve segregated BRAM we also have a pixel-synchronised COPPER fetching instructions and writing registers, along with four channels of audio hardware doing it’s thing and the BLITTER running in tandem to do things like async block copies and BOB rendering (all controllable by other systems). We don’t have direct host bus access on the UPduino due to lack of pins, but I do have a prototype Xosera which acts as a full 68k bus participant (including vectored interrupts and bus mastering for host memory access) for when we, in the fullness of time, have a bigger FPGA (I.e. more IO pins).

FWIW your call on disabling playfield B may have been prescient, we’ve currently done that to make things fit (for audio, not so much sprites) but we’re relatively confident we can get back to a place in which all the main options fit. That said, we’re not overly worried about sprites - we believe we have the computational and memory capacity that we can live without them beyond the one or two we’re currently targeting (possibly for bigger FPGAs).

caveat; I’m a mere collaborator on Xosera, but the designer of the rosco_m68k.

  • Like 3
Link to comment
Share on other sites

On 7/10/2022 at 4:06 PM, Roscopeco said:

Sorry to resurrect an old thread here, but I just found this and thought I’d correct a few assumptions 🙂

First off, you’re totally correct that Xosera is not a VERA clone, but it is inspired by VERA. Given our primary target is a 16-bit rather than an 8-bit, we changed things that it made sense to change, and what we wound up making was much closer to the Amiga hardware than the C64 - not because the C64 hardware isn’t great, but because Amiga fits our interests more.

You’re right that we don’t have hardware sprites at the moment, but your read on memory bandwidth is not quite correct - in fact we have multiple subsystems with memory access on a per-pixel basis. Obviously the display hardware has to fetch pixels on every dot clock, but because of the way we’ve segregated BRAM we also have a pixel-synchronised COPPER fetching instructions and writing registers, along with four channels of audio hardware doing it’s thing and the BLITTER running in tandem to do things like async block copies and BOB rendering (all controllable by other systems). We don’t have direct host bus access on the UPduino due to lack of pins, but I do have a prototype Xosera which acts as a full 68k bus participant (including vectored interrupts and bus mastering for host memory access) for when we, in the fullness of time, have a bigger FPGA (I.e. more IO pins).

FWIW your call on disabling playfield B may have been prescient, we’ve currently done that to make things fit (for audio, not so much sprites) but we’re relatively confident we can get back to a place in which all the main options fit. That said, we’re not overly worried about sprites - we believe we have the computational and memory capacity that we can live without them beyond the one or two we’re currently targeting (possibly for bigger FPGAs).

caveat; I’m a mere collaborator on Xosera, but the designer of the rosco_m68k.

Just looking at vram.sv, it looks to me like a 16x64K memory clocked at the pixel frequency. 16x64K is the entirety of the single-ported RAM on the iCE40UP5K. The effective bandwidth of the single-ported RAM is therefore 2 bytes per clock cycle. If any subsystem other than the video generator wants to access memory during active display, the VRAM arbitrator (vram_arb.sv) will stall it until no video generator accesses are pending. At the time I wrote the original message, there were two 8-bit playfields necessitating a minimum aggregate bandwidth of 2 bytes per pixel. There was no bandwidth to fetch sprites from VRAM, so they would have to live in BRAM. At the time, 100% of BRAM was committed (Xosera/xosera_upd_vga_640x480_stats.txt at 6c5ae5c71fc36852eee47b0d666d781bd49cccf5 · XarkLabs/Xosera (github.com)). What about my read was not correct?

Link to comment
Share on other sites

  • 2 weeks later...

Hello,

I just stumbled on this thread.  I am the designer of the Xosera retro video project (along with Roscopeco who designed the Xosera hardware board and the copper co-processor - and the main computer I am using with it). 🙂

For me, a good retro computer has to have "fun" retro graphics and an FPGA is the closest thing to making a custom ASIC "video chip" for that right now.  VERA seems a very nice design, but it wasn't clear it would be open originally which is why I started on Xosera (besides wanting an excuse to really learn Verilog).  Xosera was started before I was even sure what FPGA the X16/VERA was going to use.  Xosera is trying to extend the rosco_m68k system to be "kind of similar" to Amiga or Atari ST era computers for graphics (with a some SNES and other tiled systems mixed in due to VRAM limits). 😅

I have been a game developer for a fair number of decades (for 6502, 68K and many other systems) and I basically tried to cram in as many "video chip" features in as possible that would make sense to use to "make a game" (or demoscene demo etc.) with 128KB of VRAM and a retro CPU.  The 128KB of "VRAM" (SPRAM) seemed just enough for a reasonable video design (with some clever retro tricks - not for brute force true-color bitmaps [boring]).

The design has pretty much exceeded my expectations, but I am currently running up on some resource limits of the FPGA now when I enable every option.  The 4 channel Amiga-like audio was a bit more "expensive" than I was hoping.  Currently it seems I can fit 2-channels of audio with most of the other important features (dual playfields, blitter, copper), but I really want four channels (for good MOD audio sources). 😅

I had certainly intended to include sprites (or at least one for an "easy" mouse cursor), but this resource limit is making me having to rethink things a bit.  I will mention the included blitter can draw a large number of blitter-objects so it is not totally clear to me that sprites are required (in my initial testing I can erase and re-draw ~10 32x16 16-bpp objects in the VBLANK interval - so quite a large number should be possible with double buffering).  A few sprites would be very handy though...

As far as DMA bandwidth, Wavicle is correct that *if* you use full horizontal resolution (640 or 848 for 16:9) on both play-fields with both showing 8-bpp, there is indeed no more memory bandwidth during the pixel scan out time.  However this isn't generally realistic, because of VRAM limits so as a practical matter you probably are going to either be horizontally pixel doubling or using 4-bpp - or both (I will mention Xosera does also have 10KB of "tile" memory that can be accessed in parallel with VRAM, so sprites could live there).

Given all that, still sprite bandwidth is "not really a big problem" (vs the FPGA being "full") because there are a quite a lot of off-screen cycles where the sprite DMA could occur (~275 of them on each line before the first pixel, this is also where the audio DMA currently occurs).  So using this DMA time, the sprite "line buffers" could be filled before scan-out (and then overlaid on top of play-field at the appropriate horizontal pixel).

I still hope to optimize and trim to get pretty much everything fitting, I am making slow progress (it is close - but the routing gets problematic).  For sure I plan to make some sprites available an option in the design (even if you can't enable *all* the options at once using this small FPGA).  Xosera has already been ported to other larger FPGAs (ECP5) as well as hooked up to a 6502 system https://zeromips.org/posts/2022-03-20-xosera/ (with a nice demo ported over too, linked below).  Even though Xosera was designed for use with 68K, since it is using an 8-bit parallel bus interface, pretty easy to use with any 8-bit CPU (main issue is level conversion or running at 3.3v - like I did with AVR).   So lots of "retro" possibilities.

I am still working on the SystemVerilog design, but I look forward to writing some 68K (and 6502) code to do some fun things on Xosera eventually.  I love all the older systems and programming them (and FPGAs to make new modern-retro designs).

Take it easy,
Xark
https://hackaday.io/Xark

Edited by Xark
  • Like 5
  • Thanks 1
Link to comment
Share on other sites

I had a wild, wacky idea that you might want to follow up on:

 

How about a tilemode consisting of tiles 36 horzontal X 28 vertical pixels.  In a 400x225 16:9 aspect ratio display, with the leftover columns and rows used for line buffering, you get 11x8, or 88 tiles per screen.  Each tile would consist of four stacks of 7 pixels, 36 stacks wide. You can map the biits of each stack so that 7 bits are used to map colors from a given CLUT, with an eighth set of seven bits used to select the CLUT.  This means that you can have a hypothetical maximum of 16,192 colors (128 CLUTs of 128 colors each) onscreen, and with Video RAM at 128K mapped half and half between the tile data and the scrolling field tile map, there's room for 74 unique tiles and a screen map of 256x256 tiles in a single field, or 23x32 screens (737 total) at that 16:9 aspect ratio.

If you reduce the pixel bitwidth, you can have even more tiles and/or an even larger scrolling field.

Of course, one drawback is the memory requirement for all those CLUTs, which may cut into either the tile data or the screen tile map.  And this still doesn't account for necessary  Video RAM for BOBs...

Link to comment
Share on other sites

On 7/25/2022 at 1:33 AM, Kalvan said:

How about a tilemode consisting of tiles 36 horzontal X 28 vertical pixels.  In a 400x225 16:9 aspect ratio display, with the leftover columns and rows used for line buffering, you get 11x8, or 88 tiles per screen.  Each tile would consist of four stacks of 7 pixels, 36 stacks wide. You can map the biits of each stack so that 7 bits are used to map colors from a given CLUT, with an eighth set of seven bits used to select the CLUT.  This means that you can have a hypothetical maximum of 16,192 colors (128 CLUTs of 128 colors each) onscreen, and with Video RAM at 128K mapped half and half between the tile data and the scrolling field tile map, there's room for 74 unique tiles and a screen map of 256x256 tiles in a single field, or 23x32 screens (737 total) at that 16:9 aspect ratio.

There's a lot of ways to segment your display grid. But first, you need to cover some basic points to your design; aspect ratio, bitmapped or tiled, max res, tile layers count and/or buffer surfaces. To have max flexibility, you must provide capable hardware which would be FPGA, no doubt, coupled with large framebuffer to support any given video configuration. I see VERA for example relies on on-chip 128 KB of pSRAM which outlines the grid for tile-oriented approach. 128 KB also could allow graphics modes up to 640x400x8 or 320x200x16 which is another possibility.

I'll definitely go for a more configurable design to allow more space to explore which wasn't accessible back then in the early Commodore days.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use