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.