2010-02-20 19:38:58
We have just successfully repaired Torbjörn's CT60! :) After replacing the ABE chip the 060 mode didn't boot, so we spent a few days measuring the bus signals. But what made the CT60 boot at last was that we did some additional soldering on the back och left side of the ABE. Apparently when you keep removing and inserting the CT60 some ABE pin solders develop cracks when the PCB is bent and eventually the CT60 won't boot. We now believe this is the problem with Henrik's CT60 too. Finally at last we can try out our Videl compatibility code in the Super videl...

2010-01-31 15:40:04
Forgot to mention below that the Videl register settings for the VGA resolutions that we tested in simulation were taken using Screenspain after having set a resolution from the desktop. So we're testing the actual TOS settings, not our own made up resolutions. This means we should see Videl screen output being mirrored on the SV output when starting the falcon in for example VGA 640x480 16 colors.

2010-01-31 15:30:43
In simulation we have now verified that a VGA 640x480 16-color resolution and a VGA 320x240 16-bit one are correctly translated into SuperVidel register settings, so we get the correct VGA timing and data output. We have also run the VHDL design through the Xilinx ISE synthesis and place-and-route, and we now have the mcs-file necessary for testing the Videl translation on the SuperVidel in reality.

The problem now is that my (Torbjörn) CT60 is under repair since its motherboard connectors as well as the ABE chip were broken. And now Henrik's CT60 is also making trouble, because of bad motherboard connectors. Those connectors seem to wear out too easily when we remove and replace the CT60 on the motherboard. Henrik is now replacing the connectors with our own CT60-extender boards, to make the CT60+SV fit in the standard Falcon case.

After that we can test the Videl translation.

2010-01-24 20:49:41
We have figured out the crashes in the Xilinx ISE Simulator at last, and have also made some progress on the actual Videl register translation. Now we get correct VGA hsync and vsync timing in simulation. Just some minor details to fix before we can test the Videl compatiblity in reality.

2010-01-16 20:03:37
After a bit of in-depth Videl register researching, we have implemented a Videl-to-SuperVidel-registers translation block in our VHDL code. We're following Mikro's Videl guide and just like Mikro says, the horizontal timing registers are the most complicated to get right. We're currently simulating our code and Xilinx ISE Simulator has given us some strange crashes to figure out, which of course follow no logic. But at least we're on the right track.

2009-12-15 13:45:17
We have begun adding the Videl registers to our VHDL code of the SuperVidel. The purpose of these registers is to snoop all writes going to the old Videl registers, so that we may interpret what was written and set our SuperVidel registers so that we get the same resolution as the Videl would have produced. That's the main purpose of this entire project. :)
The heavy part of these registers is the interpretation though, not the registers themselves.

We've also been thinking a bit more about the Videl compatibility. During discussions with Peter Persson we realized that the Timer-B of the MFP-chip wouldn't work with our current SuperVidel construction. For this to work we have to feed the video clock of the old Videl into the SuperVidel and let the old Videl work as before. This way you'll get the old Videl picture out through the SuperVidel, as well as the Timer-B HBL-interrupts from the MFP correctly synchronized. In order to feed the old Videl clock into the SuperVidel, a wire will have to be soldered from the old Videl chip. Note that soldering this wire isn't a requirement for getting the SuperVidel to work, but without it the Timer-B won't work correctly in old games and demos. And it's only near the Videl chip that you'll have to solder. The other end of this wire goes to a small 1.27mm connector on the SuperVidel, for easy detachment.

/Henrik

2009-11-25 20:40:51
During the weekend we attended this year's NAS in Falköping, Sweden. It had a very nice atmosphere as always :)

We had set our goal quite low this time: to solder a flat cable at the bottom of the SuperVidel DVI connector to break out the VGA output so we could demonstrate dual screen output via DVI and VGA. The other thing we needed to do was the actual dual screen register settings. It all worked out fine in the end, though we couldn't show any higher than dual 1280x1024x16bit screens, since one of the flat screens we had with us was only 1280x1024. But people got the general concept. :P

For some reason the dual screen output only worked under TOS, but not MiNT/Xaaes. We'll have to investigate this...

/Torbjörn

2009-11-07 10:48:34
We have now successfully added the dual screen functionality. It has been tested at 1680x1050 16bit 60Hz, and seems to work fine. We get both the VGA and DVI signals at the same time, via the DVI-I connector. But since we currently don't have a DVI-I to DVI-D + VGA splitter, we can't actually see both screens at the same time. Time to order a splitter then... :P Henrik has continued researching the Videl register functionality, but no implementation has started yet.

2009-11-02 22:14:33
The ST-RAM snooping, which is a vital part of the Videl compatibility, is now working correctly. :)

Despite our earlier news post that stated the cache was working fine, we've had problems with it in the highest resolutions. But during the last 3-4 weeks we've fixed 6-7 bugs in the VHDL code and now the cache works fine even up to 1680x1050. :)

Currently Torbjörn is adding a second video pipeline to our design, to enable simultaneous dual screen output (VGA+DVI). We don't expect any big problems doing this, since nothing new has to be developed, so we estimate to be able to show you this if you come to NAS (Nordic Atari Show) in Falköping/Sweden on November 20th-22nd. :)

I'm currently investigating how the old Videl registers map to our new registers, in order to implement the most vital part of the Videl compatibility.

2009-10-18 12:43:10
The bypass system is now in place in the FPGA, which means that our video pipeline now works correctly together with the cache. Both the cache and the bypass system took a while to accomplish, because we're always working close to the performance limit of the Spartan3 FPGA (200MHz).

Next thing is to incorporate the ST-RAM snooping that I (Henrik) started.

2009-09-27 23:04:55
The past week has gone to testing the cache some more plus planning the next step. We need some way of bypassing the cache when the videopipeline(s) want to read screen data, since we don't want these reads to fill the cache. That would hurt performance enormously. Henrik will start implementing the ST-RAM snooping, which is one important component of the Videl compatibility. Torbjörn will start implementing the bypass unit mentioned above.

2009-09-20 13:01:30
Some good news regarding the SV. :)

After about 6 weeks Torbjörn finally finished implementing the 32Kbyte cache and CT60-write-FIFO in the FPGA together with the necessary modifications to our internal DDR-controller and CT60-interface.

This weekend we've tested it for real and it seems to work fine. Write accesses are now 100% faster than before and now we've reached 40MB/s (90MHz 060) during SINGLE longword writes (not comparable to the move16 bursts used when measuring the SDRAM performance of the CT60). On our oscilloscope and in simulations we see that the SV gives the 060 a "Transfer Acknowledge (TA)" already during the third cycle after "Transfer Start (TS)", thanks to our write-FIFO, but the 060 itself doesn't start another write until the ninth cycle. So it seems we can't optimize the single accesses any further. To get better performance we need to implement both move16 support and a DMA unit. A small problem with this is that you have to modify the VDI as well so it either uses move16 or the DMA unit (like the CTPCI). Otherwise the VDI will still do single word writes to the screen with sub-optimal speed.

Reads are quite a bit slower (half) than the writes, because we get no advantage from our CT60-write-FIFO, so it's just our 32KB cache that helps us. Unfortunately, accessing the cache from the CT60 still involves quite long latency since the cache is close to the DDR controller and in the DDR clock domain. So the asynchronous bridging eats a lot of cycles etc. MOVE16 support will speed up this greatly though.

2009-09-17 23:31:55
Just a small status report. :) Torbjörn is still busy with implementing the cache inside the SuperVidel FPGA, which will multiply the CT60s bandwidth to the DDR memory several times. This is also necessary in order to develop the ST-RAM snooping, which is a requirement for the Videl compatibility.

2009-09-16 22:53:53
I've modified our homepage so that we can add news more easily from whereever we may be. Hopefully this will lead to more frequent news updates. :)