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