2011-03-06 20:51:53
We just had an Atari-weekend with Pep were we managed to create a dual screen desktop and also test that feeding the 25.175MHz Videl clock from the motherboard to the SV is fully usable on the SuperVidel. Someday soon we will do a 5th demo video of the dual screen desktop.

Pep also played around with Mikro's Quake port to make it write to the SV graphics RAM. This made the framerate double (estimate), when the chunky to planar conversion (C2P) was still performed. He then wanted to remove the C2P too, to get the best possible speed, but didn't have enough time. But maybe we'll soon see a Quake port running fluidly. :)

2011-02-28 23:35:32
We have just posted a 4th demo video on youtube, showing some Aniplayer playback:

http://www.youtube.com/watch?v=96epSDwfPnk

We don't have a patched Quake port yet, so we don't think it's worth to show on the SV, but if/when we do it we can show that too. Also left to do is a dual screen demo. Hopefully done during the upcoming weekend.

2011-02-21 23:22:12
Ooops, that didn't come out well...
Let's try again:

We have uploaded 3 demo videos on youtube:

#1: Basic functionality
http://www.youtube.com/watch?v=mJW2eH-ZunE

#2: Hardware demo
http://www.youtube.com/watch?v=tQZnI2MAAN8

#3: High resolution in Mint
http://www.youtube.com/watch?v=vaTGYpDt5Wo

2011-02-21 23:20:51
We have now uploaded 3 demo videos on youtube: #1: Basic functionality http://www.youtube.com/watch?v=mJW2eH-ZunE #2: Hardware demo http://www.youtube.com/watch?v=tQZnI2MAAN8 #3: High resolution in Mint http://www.youtube.com/watch?v=vaTGYpDt5Wo

2011-02-21 09:52:02
We're currently recording some demo videos to show the various aspects of the SuperVidel. We'll post them at youtube when we're done.

2011-02-10 22:00:05
SuperVidel production is closing in!

It is now time for you to re-register your interest in buying the SuperVidel. This is because we started the poll 1.5 years ago and since then the CTPCI has been released and generally people may have lost interest. So we need to get a fresh picture of how many boards to actually produce, since that will affect the price of each unit. So please go to the SV interest poll at our main page, click the update link and carefully follow the instructions.

You HAVE to update your registration to be counted, if you originally registered or updated before Feb 1st 2011. Of course we also welcome new registrations now. If you have any questions, email us!

2011-02-05 17:32:00
Time for a news update!

Our server has been down for a while because of broken hardware, but now we've moved its harddrives into a new computer, so it should work from now on.

We tested two TX slots and two RX slots with the Svethlana board, but didn't see that it was any faster than what we currently get from the EtherNat (Henrik got 1.3MB/s to/from an FTP server in the same network). In the future we can either assign more block-RAM in the FPGA to be Svethlana buffers, or implement an interface to the DDR2-RAM so we can have up to 128 buffers (max allowed by the MAC controller IP core that we use). Hopefully this speeds up things, or we need to look for the problem higher in the SW hierarchy (Mintnet).

Focus now is on preparing the SV for production, as we have now decided to not add more functionality to the FPGA than we currently have.

Last weekend we were on a nice winter NAS edition outside Falköping here in Sweden, were we met the usual Atari guys. We had many deeper discussions with Peter Persson about both MPEG-2 and 3D-support. He is currently working on patching NVDI5 so we can have a native SV driver in 16 and 32-bit, which uses all the functionality of the SuperBlitter. :)

2011-01-03 22:03:56
The VHDL issue that we had with the Svethlana was quickly fixed, and since then we have also managed to rewrite the Ethernat Mintnet driver to suit the Svethlana. It seems to work fine, as we can now surf the web and transfer large files to/from our server without errors. Just need to change the driver a bit so we use both TX packet slots that we have allocated block-RAM for in the FPGA, to (hopefully) get better speed. Right now we only use one packet slot.

2010-12-24 11:50:36
Merry Christmas! :)

Just a quick report on the last Svethlana progress:
We have come as far as testing the floodping program that we mentioned below. The pinging itself seems to go faster than with the EtherNat, but we have got the same problem with the MFP interrupt collisions that we had with the EtherNat. Our current solution in the VHDL code doesn't seem to be a very good one, so we have to try something else. But it shouldn't be a very big issue.

2010-12-20 00:00:33
The JED-file for the EtherNat that we mentioned a few days ago is now available for download. Instructions on how to update your EtherNat(s) is in the zip file too. :)

2010-12-18 18:41:15
We have now got both sending and receiving packets working on the svethlana board, with interrupts too. The next step is too write a simple ping program and test the stability, while a floodping is running on an ethernat. Then we can adapt the ethernat driver to the svethlana hardware (with the mac controller in the fpga). That should'nt take long since the integrated mac controller in the fpga is much easier to use than the 91c111 chip on the ethernat. After that the svethlana work is complete and we can focus on preparing the supervidel board for production.

2010-12-14 13:59:45
We have decided a simple interrupt daisy chaining protocol with Rodolphe to be used when two or more boards are on top of each other on the CT60. With this in mind we have made a final JED-file to use when updating your Ethernat. The file will be put in the Download section soon.

Instructions:

You need a Xilinx USB cable or equivalent parallel cable to connect between your ethernat and a PC. A cheap alternative, which we have NOT tried ourselves, is this: http://www.renaelectronics.com/product_x_cable.htm

You need to install Xilinx Webpack (free) on your PC. Any version is ok.

Make sure the power is OFF on your falcon, and the Ethernat is in its usual place on the CT60. Set the CT60 to 030-mode. Earth yourself by using a wristband, or touch something grounded. Don't wear syntetic clothes.

Connect the GND wire on your cable to the GND pin in the Ethernat's JTAG header. The header is in the top left corner of the Ethernat board, 7 pins long. GND is the 2nd pin from the left. See the printed pin names on the board. Then connect all other pins, except the 3.3V (VREF or VCC on the cable) which is connected last. Power on the falcon.

How to use iMPACT (from my memory): Start the accessory iMPACT, press cancel if a dialog shows up, select Boundary Scan on the left. Right click in the big space and select "Initialize chain". The program will then search for the cable and what it is connected to. A symbol resembling a chip should show up. Right-click on it and select "Assign configuration file". A file selector appears. Select your JED-file and press OK to exit file selector. If a dialog appears, exit it using cancel. Right-click on the chip-symbol again and select "Program". A progress bar appears while programming is in progress. "Success" should appear in blue when it is done.

Turn off the falcon. Disconnect the cable from the Ethernat CAREFULLY by holding one finger on the green PCB of the Ethernat while two other fingers remove each cable wire. NEVER press on a chip! Disconnect the GND-pin last. Switch back to 060-mode. Turn on the falcon. Enjoy! :)

2010-12-08 22:04:16
Last weekend we found and fixed a serious bug in the VHDL code for the EtherNat CPLD! This fixes problems where the falcon could freeze during heavy network traffic. The bug was trigged when the MFP chip on the motherboard sent a level 6 interrupt to the 060, if a LAN interrupt arrived during a very small window when the MFP was already answering the interrupt acknowledge bus cycle. This would screw up the interrupt vector supplied to the 060 and hang the bus.

The EtherNats we currently are repairing will get reprogrammed with this fix, but we have to clear some things with Rodolphe first regarding the CTPCI +EtherNat problems before we send the boards back.

2010-11-29 20:26:30
Work has begun again on the Ethernet MAC parts of the SuperVidel for the Svethlana board. It is not quite finished for simulation of the VHDL code, but not very much work remains. We have also taken a new look at the Ethernat driver code (the one modified by Alan H in the Freemint CVS) and the CPLD VHDL code itself, while repairing some Ethernats. We have found at least two (old) bugs in the driver which we have fixed. The source code will be checked in to the Freemint CVS when we're done.

2010-09-21 12:59:47
Just to let you know that we're still alive I'd like to say that I (Torbjörn) am currently busy moving into a new appartment in Gothenburg. This takes a lot of energy so not much has happened on the SV since I looked at the Vsync problem mentioned below. But when I get settled in I will start developing the needed ethernet MAC controller for the SVEthLANa board. The Vsync problem has not found a solution yet, but some more measurements might solve it. Or not. :P

2010-08-24 18:53:36
Today I (Henrik) finished soldering the SVEthLANa prototype and now we got the first life signs from it. The SVEthLANa performs autonegotiation automatically from poweron and the LEDs of the ethernet connector are now nicely lit to show a successful autoneg to 100Mbit. :) What remains now is instantiating

Meanwhile Torbjörn is trying to fix a problem with synchronizing the VBL from the old Videl with the VBL of the SuperVidel when running in compatibility mode.

2010-07-18 01:09:41
Two days ago we fixed the 8bit chunky mode in the SuperVidel VHDL code, so now you don't have to do any more chunky to planar conversions. :)

And just now we fixed the 2bit falcon VGA mode and ST Low, Medium and High resolutions! :) So the falcon VGA mode emulation is now complete!

2010-07-06 23:04:31
Today we updated the SuperVidel project page, with more up-to-date specs and an FAQ. You find it under Projects.

2010-07-05 21:08:16
Yesterday we got home from our first Sommarhack i Dalarna, Sweden, were we met the DHS guys among other people. It was a really relaxed party atmosphere, but a bit too hot weather :P Our legs are swollen with mosquito bites...

We got the chance to take some picture of our SV card inside Evl's falcon, so now we can produce an FAQ regarding the constantly returning question about compatibility with the original falcon case. :P

2010-06-11 22:16:31
Forgot to mention that the NVDI patch uses the new blitter in the FPGA of the SuperVidel, which is why we get smooth window movement even in high resolutions. We'll hopefully remember to make a demo video of this soon! :)

2010-06-11 22:14:05
Now we're at NAS in Falköping, were we've teamed up with Pep and other people. The past week Pep has progressed on the NVDI patch code so now he's running 1280x1024x32bit and we're running 1680x1050x16bit, with very smooth window movement! :)

2010-06-01 23:20:12
Peter has now some more spare time and has already made a patch for NVDI 5 that sets 640x480x32bit when you set 640x480x2bit. It works fine under both TOS and Xaaes/Mint so far. :P Not all apps seem to understand the 32bit mode though...

2010-05-20 23:15:53
During the last week we have created a 24-bit + alpha (=32bit) blit mode, and tonight we tested this. And it works! :) We will put together some kind of demonstration video for this in due time. :)

Pep is currently busy with his school work, but when he's done he will change the VDI patch code so that it uses the blitter for moving windows. :)

2010-05-10 21:29:43
Yes! Today we fixed the last bugs in the blitter! :)

Now we can try using it to move windows around on the desktop, with Peps help. :)

2010-05-09 18:49:35
This week since Outline we've worked on the blitter and fixed some lesser bugs plus a bigger bug last night, when we solved the garbage-line bug, which some of you saw at Outline. There are still about two minor bugs before we can call this version of the blitter finished.

2010-05-09 09:54:04
On our way home from the Outline party last weekend, we got an idea together with Peter Persson (Pep). As you may already know, today we mirror all ST-RAM-writes to our SuperVidel graphics RAM, so that you immediately get the same screen output from the SuperVidel as is displayed by the Videl. This works fine of course, but naturally the speed is dictated by the ST-RAM writes. The mirror area in our graphics RAM is at 0xA0000000 -- 0xA0FFFFFF, which is 16MB. The idea we got was to fool the VDI into writing directly to our graphics RAM instead, by simply adding 0xA0000000 to each write and read access. This is done by manipulating the Logbase system variable. The negative side effect of this is that we no longer get the usual Videl output after we apply this patch, but we think you should be able to turn this feature on and off as you wish. We have run some quick GEM bench tests and it's about twice as fast on some tests when all the VDI accesses only go to our graphics RAM.

2010-05-03 23:03:10
Another great Outline has passed way too quickly, and now we're home again. The current location is really the best we've been to, so hopefully the party will be held there again. It was fun to meet all the scene people again, and witness such great contributions to the competitions as well as the fine live performances.

The party was quite productive for us too, since we managed to make the blitter work in reality. There are some bugs left to fix, but the main functionality does what it is supposed to without hanging the computer. The current speed of the blitter is below 100MB/s, but that is caused by the cache and we have a few tricks left to make it faster.

2010-04-25 18:50:20
We're working on a blitter now, since we finally realised that even MOVE16 accesses will not give you fast realtime window movement on the desktop in higher resolutions. We had planned to make a blitter anyway, but now it got higher priority.

This blitter has only basic copying, within the SV graphics RAM, of a square from one defined square buffer to another, like the screen. It is not as simple as it sounds to do this, since we have to work with bytes in a 64-bit bus environment, which requires us to round addresses to even 8 bytes and use write-masks.

Hopefully we'll have something to show at Outline, besides the already functioning Videl screen cloning (for 1,4,8,16 bits/pixel).

2010-04-07 15:29:03
I (Henrik) have been working on a program for the CT60 which will allow you to reprogram the SuperVidel directly from your falcon, without need for a JTAG cable connected to a pc. Yesterday I run this program to erase, program and verify one of the flash chips onboard the SuperVidel and then restarted the falcon with the SuperVidel working ok. :)

What remains now is to tune the low level delays used for the JTAG signalling towards the flash chips, because currently it takes a horrible amount of time to program the flash chips. Also a nice GUI and perhaps a function that searches our server for a new version and installs it automatically would be nice. :)

2010-03-23 12:19:32
We have been informed to our great sadness that Frank Naumann passed away a few days ago. Though we never met him in person we had contact with him via email, and among other things he helped us when we began writing the EtherNat driver a couple of years ago. This important cornerstone of the Atari community will be sorely missed and not forgotten.

2010-03-18 20:37:22
Today we solved two problems. The first was a problem with getting the Videl picture on the SuperVidel after power on. It used to require pressing the reset button about 3 times. But now we get the picture immediately! :)

The second problem had to do with the SuperVidel answering some reads of the old Videl registers. This is necessary to allow us to expand the functionality of the Videl, so we can restore a high SV resolution when an old game or demo restores what it thinks is a Videl resolution. We have simply selected an unused bit in the register 0xFF82C0, which is read as '1' when a special SV resolution is running, and '0' when an old Videl resolution is used. So a game/demo which reads all Videl registers before setting its own resolution, will automatically read our "magic" bit and remember it. When the game/demo exits, the bit will be restored together with the Videl registers. The SV checks the magic bit to see if it should set the Videl resolution or restore the high SV resolution.

2010-03-13 16:01:47
Today we also tried running Henrik's dogfight game Aces High, which uses a rather unorthodox VGA-resolution of 384x250 in 60Hz using the 32MHz video clock (normally used by RGB modes). This works perfectly. :D

2010-03-12 23:58:10
During the last two weeks there has been some major development progress on the Videl emulation again. We have got both Mono and 8-bit (256 colors) modes working in all VGA resolutions: 640x480, 320x480, 640x240 and 320x240. So now we have full support for 1,4,8 and 16 bit pixels on VGA.

We have fixed minor but hard-to-find bugs that sometimes caused "skewed" bitplanes.

We have run some demos that use 256 colors to see that our Videl cloning works. We have only run VGA 60Hz, since our LCD monitors can only handle this. In one demo we selected 100Hz VGA, and the monitor reported that it couldn't display "100Hz, 31.4kHz". This is good news for us though, since it proves that our Videl register translation code translates 100Hz correctly! :) We need to try it on an analog VGA to see it for real.

RGB resolutions is still untested.

2-bit color mode seems to become a larger issue, since the Videl supports this only in ST-mode, and we have no working translation code for this yet. The question is: Should we really put a lot of time into this now, when we have other more basic/urgent features to do before production, like JTAG updating and RGB support? After all, how often do you use 2-bit mode?... :P

2010-02-28 16:03:24
WE HAVE NOW SUCCESSFULLY CLONED THE VIDEL OUTPUT to the Supervidel output when running 640x480x4bit and 320x240/480xTC!!!! :D
We have not yet made mono, 2-bit and 8-bit work, but hopefully they shouldn't present any bigger obstacle now.

We're currently moving our 256-colour palette from the old address at 0x80020000 to 0xFFFF9800, where it will snoop the old 256-colour palette. We will also make the VGA timing block active from power on, so you will get the boot picture directly out thorugh the Supervidel.

2010-02-27 16:50:11
Right now we're working on the Supervidel VHDL code again. This time Torbjorn has come to visit me (Henrik) in Gothenburg and also Pep (Peter Persson) is here. Since we managed to repair Torbjorn's CT60 last weekend, during the last week we tested the Videl compatibility code. But then we encountered a bug in our STRAM snooping code that would freeze the falcon. Now we've restructured some parts of the VHDL code to prevent this and we're just about to test it. :)

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. :)