2012-03-12 19:56:08
Just added two documents to the Download section :)
1) A HW/VHDL/SW description
2) The SuperVidel memory map

2012-03-11 18:21:42
We're busy updating our PHP scripts to help you get all the necessary information when buying your SuperVidel + Svethlana + Extenders. When we're done in a few days, the prepayment period will really start! :)

2012-03-05 07:17:19
Forgot to mention that we have updated the SuperVidel project page with the last specs before production. You'll find it under Projects.

2012-03-04 22:02:06
We got new quotes from the Chinese supplier, and they looked OK, so we will order the connectors as soon as possible. We have included these prices in the SV, Svethlana and Extender boards calculations.

We have decided the final prices for all three products now, in Euro. You find them under the SV poll page, which you get to from the Start page. There you can update your number of boards too. Unfortunately the somewhat better component prices from the manufacturer didn't do much for the final prices.

Note that the prepayment period has not yet started.
Since we're in Sweden we get all your payments converted into SEK, and the exchange rates we've seen on our bank and Paypal are not so good. We've not yet decided if we should go ahead and accept Euros anyway, or translate the Euro prices into SEK, so you send us SEK instead. For those of you who live in a non-Euro-country it makes little sense to convert to Euro (at a possibly lousy rate) and then we must convert from Euro to SEK (at another lousy rate).

2012-03-02 10:09:54
Finally we got an answer from the Chinese connector supplier. Now we'll just verify that their old quotes are still valid, before placing an order. When these prices have been verified, we should have everything we need to be able to finally set the prices for the SV, Svethlana and Extender boards.

2012-02-27 16:18:31
We visited Vinterhack in Tidaholm this weekend. It was the same old guys as always and great atmosphere. The party place was new though, and it was very good. While there we worked on the SuperVidel project with Pep. He added more stuff to the XBIOS+NVDI drivers and we added things to the VHDL code. Now we have a SuperBlitter-done interrupt, and separate VSYNC interrupt vectors for the VGA and DVI outputs. Also added a new 32bit alpha blitter mode, but had no time to test it.

Regarding the production of SV, Svethlana and Extenders:

We have emailed our chinese connector supplier to verify offered prices, but haven't heard anything yet. These connector prices are necessary for the SV and Extender boards, but not for the Svethlana.

We had some discussions with the manufacturer, and got more sensible prices on some components, but not all.

2012-02-18 10:27:47
We have received the quote. It looks ok, but it's not great. The result is a combination of component prices, high fixed startup costs and that we need to make 4 new SV-prototypes to be sure that everything works after all the changes we've made. This makes the final price including 25% Swedish VAT end up slightly above 300EUR (slightly above 240EUR for all non-EU customers and VAT-registered EU companies). :-/

We pointed out to the manufacturer that some component prices were way too high and now we're awaiting their adjustments. This might take a week.

The SVEthLANa has also been struck by the high startup costs. 30EUR + VAT is no longer realistic. It will be more like 40EUR + 25% VAT.

We haven't determined the final price for the Extender-boards yet, but we have decided to let people buy them separately even if they don't buy a SuperVidel.

2012-02-14 22:57:34
The manufacturer phoned us today and told us we should get the quote tomorrow or the day after that. They had some questions to be answered before they can put the quote together. But they were no big issues so they should be able to finish it now.

2012-01-24 06:16:30
Yesterday we emailed the manufacturer, so now we're waiting for a quote from them. :) It should normally take 2 weeks.

2012-01-22 19:40:02
And now we're done with the Svethlana and Extender boards too!!! Tomorrow we'll email the manufacturer to start the quotation process. :)

2012-01-14 19:04:06
Just finished the Gerber files and BOM for the Supervidel! :) They are ready to be sent to the manufacturer.

We need to do this for Svethlana and the Extender boards too, but they need no additional checking since we have already tested this version of the Svethlana by soldering one ourselves.

2012-01-10 21:49:46
Today we finished checking the layout and the mechanical properties of the board, which included making a card board copy of the SV and see that its components fit in an original falcon case with the internal keyboard. Next up is generating Gerber files for the manufacturer, and do some checking of them too before we send them to the manufacturer for the final quote. :)

2011-12-28 21:47:03
Finished checking the schematics today. The layout is next.

2011-12-26 19:13:03
Just an update of what we did before Christmas: We have done 90% of the schematics checking. Will do the rest before New Year's eve since we're on holiday until then. Then we need to check the layout too, but that should be the final step before sending our files to the manufacturer. :)

2011-12-13 17:32:41
Finished the list below and started comparing all schematics to the 3 years old ones (for the prototypes) to more easily see what we have changed.

2011-11-27 21:38:30
The last 3 weekends we fixed all DRC errors, and then we went through an old list of things to do and check, which we're almost done with too.

2011-11-07 11:15:07
Yesterday we fixed most of the DRC errors/warnings. Not 100% done yet though.

2011-10-30 18:16:58
Placed those vias too. Did a DRC check of the layout and found that we have a bit of work to do there too.

2011-10-15 21:36:51
Managed to gather some time and energy to work on the SuperVidel. :) Just finished the rework of the DAC-layout, which was the last big change on the board. Now there are just some minor signal vias left to place. Then of course we have to do a thorough check of the entire board...

2011-09-19 14:41:18
If you're wondering why nothing has happened lately on the SuperVidel or anything else, that's because our regular jobs currently demand that we work evenings and weekends to get things done for a deadline soon. Hopefully things will get a little less hectic in October.

2011-08-21 21:36:18
This weekend we were at Hackspett 2011 in Falköping. It replaces the old Atari-only event NAS, but is still organised by SAK. Other platforms were invited, but we mostly saw the same old guys who mostly brought their Ataris, but also the odd Amiga, C64 etc.

During the event we helped Pep input the timing register values for a 1920x1080p 60Hz (mono to 32 bits) resolution into his SV_XBIOS.PRG. This resolution is now selectable from his modified TOS resolution changer (looks like the original), which uses Vsetmode() using the two-byte modecode. So we used 1920x1080 during the party in XaAES under Mint, on a DVI TFT screen. To get this high resolution we used the so-called VESA CVT-RB (reduced blanking) timing, to reach high resolutions with a reduced pixel clock (138.653MHz in this case). Our 24" TFT had no problems with this timing on the VGA input either, so as long as you have a resonably new TFT screen, it should work for you.

Pep was otherwise deep in his work rewriting his SV_XBIOS program, and Henrik was busy coding other things on his falcon. I (Torbjörn) added a new bit to the SuperVidel copy of the 0xFF8266 register, which controls the colour depth of the Videl. The new bit enables 8-bit chunky mode in Videl resolutions on the SV output. This way you can easily change a current game/demo which runs in 8bit planar mode, into an 8bit chunky mode application, so you can lose the costly chunky-to-planar conversion during each frame... :-) All you need to do is set this bit to 1 when writing to the 0xFF8266 register.

2011-08-09 15:24:32
We found it necessary to take a break from the SuperVidel stuff during our own vacation. The component price quote has not been delivered to us yet since they want all documents from us to be able to give us a full quote instead, not just for the components. We'll shortly resume the work were we left it, to finish all documents.

2011-07-08 17:42:10
Several more weeks have passed without any word about the price quote. But this morning we got an email were they said that they have got in all the quotes and will do some more work before sending the result to us. They said we'll have it next week.

Last weekend we went to Sommarhack at Grådö, Dalarna, Sweden. The weather was quite a bit more pleasant this year than the last. The atmosphere was very relaxed, and it was nice to meet everyone again. Pep did some major rework on his NVDI drivers, but otherwise we did only minor things on the SuperVidel things.

2011-06-12 20:40:02
About a week ago we went to Outline 2011 in the Netherlands, and it was a pleasure as always, except the 15 hour car drive in both directions... :) The weather was very nice this time too, and it was good to see the old people again. Some progress was done on both the PCB layout, VHDL code and VDI/NVDI/XBIOS. For example, we now have working Videl compatibility output on DVI too, which we only had on VGA earlier. So the boot picture will show up on both VGA and DVI now. We haven't yet heard anything from the manufacturer about the price quote, but we hope it comes this week. They said there was very much work right now, so we're not surprised that it has taken a bit longer than usual.

2011-05-20 17:43:42
After a few days we got an answer from the manufacturer that they will start asking for component price quotes immediately. But it will likely take about two weeks before we get the quotes since there are extraordinarily many quote requests out there right now.

In the mean time we go on layouting the final SV changes.

2011-05-16 15:25:41
We received the oscilloscope last week (later than promised) and made some important measurements to decide the final component characteristics.

This weekend we finally completed the bill-of-materials for the SuperVidel and SVethLANa, and sent it to the manufacturer so they can give us a quote for the components. We still need to fix the last things on the SuperVidel layout before we can get the complete quote though.

We hoped to have the final price of the SuperVidel ready before Outline 2011, but that will probably not happen.

But we're still working all evenings and weekends to get it ready... :P

2011-04-27 16:15:03
It seems "doing the last" preparations to make the SV ready for production takes a lot more time than expected. During the work with the bill of materials there were several parts that needed extra inspection and decisions. We're almost done now, but there are a few things left to fix that requires the new oscilloscope that we have ordered. We heard that we'll receive the oscilloscope at the beginning of next week. Until then we'll really enjoy doing the yearly financial accounting of Henrik's company... not

2011-04-04 10:57:05
Just a short notice to tell you that we're still busy making the SuperVidel ready for production. At least the Svethlana is ready now. There are a few things on the SV left to modify, both in the layout and in the bill of materials. The re-registration period will run until we have a price from the manufacturer.

2011-03-21 14:41:11
We have got a quote for the biggest components on the supervidel. It looks promising to get a low total price. But we still need a quote for the manufacturing itself and the smaller components before we can decide the final price for all who order from us. Because we haven't yet been able to decide the final price we will prolong the registration period to at least April 1st.

2011-03-09 22:27:24
Just uploaded the 5th SuperVidel demo video on youtube: here
where we show dual screen desktop and full screen Aniplayer playback.

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