View unanswered posts | View active topics It is currently Thu Mar 28, 2024 11:45 pm



Reply to topic  [ 12 posts ] 
 FAL6567 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I figured I would mention what I have been working on for a few days now. The project actually started six years ago, but recently moved back off the shelf. FAL6567 a MOS6567 compatible display controller circuit. FAL6567 is going to have HDMI output though instead of composite video.

A couple of enhancements I am making are support for 16 sprites versus the 8 in the standard chip, and an 80-column text mode. If one looks at the waveforms the VIC-II (6567) uses one could swear there’s very little room to add features.

Squeezing 80-column text out of the display system may seem impossible, and it is except for a few tricks up my sleeve. 40-column text mode by itself uses a peek of 100% of the display memory bandwidth, so 80-column mode would use 200% of the bandwidth. The obvious approach would be to double the access rate to screen memory. But that is not practical to do if the circuit is to be used in a legacy system. The memory is only so fast. So instead, the video timing is being modified to include 40 extra character times in the horizontal row. This of course clobbers the horizontal timing. Meaning the refresh is only 8kHz instead of 15kHz. And the screen refresh would end up being at 30Hz instead of 60Hz. But guess what, I think it does not matter because a scan rate modifier circuit is needed anyway to display things at the HDMI rates. A 640x480 standard VGA format is used as a base for timing. The 640x480 format is quad the resolution of the VIC-II. Double horizontal and double vertical. The scan buffer ends up being filled at a 30Hz rate in 80 column-mode, but read back out at a 60Hz rate from the scan buffer. Display data fetch for the scan buffer takes place at ½ the display rate. Made possible through the magic of dual-port RAMS.

I have got the circuit coded, over 3000 LOC, and it turns out to fit very easily in the FPGA. It uses only 2800 LUTs out of the 20,800 available. The dual-ported scan buffer is what sets the size of the FPGA. 134kB of ram is needed for the scan buffer.

I may add some easter eggs to use up some of the logic resources.

_________________
Robert Finch http://www.finitron.ca


Sun Jul 10, 2022 2:05 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
interesting idea to run at half-rate on one side and full-rate on the other.


Sun Jul 10, 2022 5:46 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Thanks BigEd for describing the workings more succinctly.

The whole clocking issue has to deal with several items:

The color-burst clock, 14.318182 MHz NTSC / 17.734475 MHz PAL, must be used as a timing source. The 8.18 MHz dot clock cannot be used because the minimum operating frequency of the MMCM clocking circuit in the FPGA is 10 MHz So, the dot clock must be derived internally.
A clock of approximately 32 MHz is needed to drive the VGA logic. It is also the clock signal used to derive the RAM timing, RAS and CAS signals and phi02 clock. So, it needs to be substantially higher in frequency than the 1.023 MHz phi02 clock.
With a VGA dot clock frequency around 32 MHz, an *exactly* five times clock, or 160 MHz clock is required to drive the RGB to DVI interface.
The circuit uses a 32.71705MHz dot clock NTSC or 31.55295 MHz PAL instead of a 25.175MHz clock for the VGA timing. I recalculated the number of clock periods for a 640x480 VGA horizontal timings. (800x480).

A 163.58523 MHz NTSC or 157.76293 MHz PAL clock is used as the base clock, trust me it was not easy to come to this clock frequency. It needs to be *exactly* five times the VGA dot clock frequency for the RGB to DVI circuit to work. And all the clocks are ultimately derived from the 4x color burst clock fed into the VIC-II chip. Also required is an 8.18182 MHz dot clock. This clock is provided to the VIC-II by external logic (8701 chip). However, the external clock is not used. Instead, an 8.1792625 MHz clock derived as the VGA dot clock divided by four is used. It should not matter that this clock is a little off the dot clock rate as it does not drive the display. The external 8.18MHz clock remains driving the expansion bus clock. Another clock required is the phi02 clock used to drive the processor, peripheral chips and other logic. This clock is provided by the VIC-II chip so it must be generated by any replacement circuit. The phi02 clock is normally 1/8 the dot clock frequency, or 1.023 MHz for an NTSC machine. However, the phi02 clock is derived by dividing the 32.717MHz VGA dot clock by 32, resulting in a frequency of 1.022MHz, just 0.001MHz off the original frequency. For PAL this is 0.9860 MHz slightly off the 0.985248 MHz. This is the clock that has me worried the most because it is not synchronous to the external 8.18 MHz dot clock and there may be timing loops depending on the phi02 frequency. If there are expansion cards requiring the clocks to be exact multiples, this may cause issues.

Jens at Individual Computers has pointed out that the fast page mode DRAM access cannot be made to work on the C64 since the VIC-II chip has the row and column addresses flipped. This put the kibosh on having 16 sprites unless 80-column mode is selected. 80-column mode does not need to use fast page mode.

_________________
Robert Finch http://www.finitron.ca


Mon Jul 11, 2022 12:52 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I have subsequently modified the clocking approach to use a 12MHz clock source and two clock generators. This allows to get exactly 40MHz and 200MHz for the HDMI interface. And 32.72727 MHz (8.18182 MHz dot clock, 1.023 MHz phi02 clock) exactly. The 12MHz clock source is available on the FPGA module, while the color clock input could not be placed on the module pins.

Previously only a single clock generator was being used, but there are five available in the device, so I figured why not make use of them.

_________________
Robert Finch http://www.finitron.ca


Mon Jul 11, 2022 5:32 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I have been working on getting a facsimile of luma output available as the C64RMK2 requires this signal for it to determine the VIC-II chip type. I also want the signal for diagnostic purposes. It should be possible to connect up a composite monitor and get mono-chrome output from the luma signal. Unfortunately, there are not enough pins on the FPGA module to output chroma as well. So, full color is not going to be available for composite output.

The conversion from RGB to composite is interesting. It is basically a bunch of multipliers, adders, shift registers, and sin lookup tables. It effectively does subcarrier modulation using digital signals. RGB is first converted to YIQ, then YIQ is converted to composite.

The luma output is four bits wide and an external four-bit resister DAC is used to set the level. Here is a screen-shot of the luma values in simulation. It looks like it could be close to correct which is all that is needed.
Attachment:
File comment: FAL6567 Scanline
scanline.png
scanline.png [ 21.06 KiB | Viewed 3303 times ]

_________________
Robert Finch http://www.finitron.ca


Tue Jul 12, 2022 12:05 am
Profile WWW

Joined: Mon Oct 07, 2019 2:41 am
Posts: 585
Why are we sticking to old TV scan rates? TV's are a hard to find. Used VGA's monitors (narrow width) can still be found for a song if you look.
24 lines by 132 sounds like real display for the man cave, but not sure what you display that as. Did they ever plan a better C64 before AMIGA took over?


Tue Jul 12, 2022 4:00 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Found a mistake in the schematics. A ‘573 latch is being used to capture address bits A8 to A11 and it was supposed to latch on the CAS signal but I had it connected to the RAS signal. The FPGA module did not have enough outputs so rather than have explicit copies of A8 to A11 like the VIC-II chip does, an external latch is being relied on to capture these address bits.

The latch is used only by the VIC-II to supply high order address bits. These bits will appear during the CAS active period. Meaning the ROMs and color RAM hooked up via these bits have only about 180 ns to respond. If the character bitmap ROM is not fast enough, then I will have the core use an internal ROM. It is a ROM so the FPGA could have its own internal copy. I hope the color RAM is fast enough, it is a 2114, these are quite slow by todays standards. May have to substitute a faster color RAM to use my circuit.

Quote:
Why are we sticking to old TV scan rates? TV's are a hard to find. Used VGA's monitors (narrow width) can still be found for a song if you look.
24 lines by 132 sounds like real display for the man cave, but not sure what you display that as. Did they ever plan a better C64 before AMIGA took over?

Yeah, the C64 is really retro, designed for TV. That is part of the fun challenge to get something working. There was the C128 successor to the C64 but not as popular.
AMIGA another great machine. These machines were designed when memory was faster than the CPU so it made sense to slice up the cycles into CPU and VDU access.

_________________
Robert Finch http://www.finitron.ca


Tue Jul 12, 2022 4:23 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Modified the timing generator. There should now be enough time during CAS, 300+ns, to accommodate slow color RAMs and ROMs. There was a way too much time allocated for the DRAM pre-charge time. This has been reduced to 122ns. It should work with 250+ns DRAMs. Access time for RAS is a whopping 367 ns. The timing generator uses approximately 30ns clock ticks. There should be loads of time for a PAL system which has a slower clock.

Modified the timing generator again. This time to provide RAS and CAS hold times after the clock edge. RAS and CAS are held active now for about 15ns after the phi02 clock edge. This gives time for the data to be read at the phi02 edge.

Modified the luma output to output a complete composite signal including sync, luma and chroma components. Usually, the chroma component is fed to the RF modulator separately. It is mixed in with the luma component by analog circuitry. But in this case the signals are mixed in the FPGA using digital circuitry.

Ordered a PCB for prototype. It is all DIP components, large resistors which are easy for me to solder.

_________________
Robert Finch http://www.finitron.ca


Wed Jul 13, 2022 3:17 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Screenshot of luma output containing sync, luma and chroma. A test color of solid blue was used and the output shows a sinewave like signal which should correspond to the color. The phase relationship may not be quite right yet meaning the displayed color might be off. I think it may be possible to adjust this with the palette.

A couple of potential gotcha's. I have coded negative going sync, this needs to be checked against VIC-II output. It may be necessary to mirror the output vertically so that sync is positive.

Attachment:
File comment: FAL6567 Blue color output
blue.png
blue.png [ 2.82 KiB | Viewed 3276 times ]

_________________
Robert Finch http://www.finitron.ca


Wed Jul 13, 2022 7:37 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I do not know how I did it, but I got the VIC cycle decode mixed up. Character fetches were occurring beginning at horizontal sync. They needed to be delayed several cycles. I put a settable constant number of cycles for delay.

Borders and blanking were not placed properly. When I setup the raster counter I used the leading edge of hsync as the zero-reference point, this eliminates a comparator. This is different than what the VIC-II uses. For the VIC-II the leading edge of the hsync pulse is at clock 416. Anyway, I forgot to adjust the border and blank coordinates to account for a different zero position.

Getting the output cycle exact to a VIC-II is not a short-term goal of the project. It is painstaking to get all the various counts just right. I may leave it up the implementer for the correct constants. I just want to see the screen basically working. It can be fine-tuned over time. I figure if I can get it working well enough and have the timing configurable by registers, it can be left to future endeavors to get everything exactly right.

Show is a screenshot of current simulator output. Note the right border is somewhat smaller than the left. Also, the output appears to be blank along the right and left sides of the image. Simulation is supposed to be reading random data from screen memory, there should not be any substantial black area as far as I know. So, there are bugs yet. Debugging is about 90% of the work.

Attachment:
File comment: FAL6567 border pos screen shot
FAL6567_borders.png
FAL6567_borders.png [ 25.42 KiB | Viewed 3264 times ]

_________________
Robert Finch http://www.finitron.ca


Thu Jul 14, 2022 3:15 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Had the row and column compress flag implemented in an inverted sense. CSEL and RSEL indicate 40x25 mode when they are set, otherwise 38x24.

Worked on adding an 80-column mode, this time implemented by doubling the dot clock rate so that the other video timings do not change. To support 80-column mode an internal character generator ROM is needed otherwise every display line would be a bad-line seriously hampering system performance.

_________________
Robert Finch http://www.finitron.ca


Fri Jul 15, 2022 2:13 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Came up with a way to modify the core to optionally eliminate bad lines. There is a bit of trickery to this. An internal character generator RAM must be used. The VIC-II fetches the character bitmap images in the half cycle after it fetches the character code. This means a full cycle is required to process a character causing a bad line. To eliminate bad lines the character bitmap fetch does not occur. This frees up a half-cycle for the character code to fetched in. The character bitmap fetch occurs after the character code fetch to an internal character bitmap RAM, so the external memory does not need to be addressed. The trickery involved is that the internal character bitmap RAM is loaded during the VIC-II’s border display area from the usual character bitmap area, when there is nothing being displayed. For the first 33 scanlines of the border area a character bitmap RAM access occurs. There are enough cycles to fill a 2048 byte-RAM. All cycles are dedicated to loading the bitmap RAM; there are no other cycles including RAM refresh and sprite accesses. DRAM refresh is still accomplished since RAS cycles are occurring to the DRAM and the address is cycling through 256 row addresses. Note the character bitmap RAM is loaded only for one video frame. Once it is loaded it remains constant unless the character bitmap base register, CB, is written.

_________________
Robert Finch http://www.finitron.ca


Sat Jul 16, 2022 2:57 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 12 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software