| Date | Happening | |
|---|---|---|
| July 19th 2009 | We now have a form for you to fill out if you're interested in buying a Super Videl. It's here | |
| June 24th 2009 | Now we've managed to repair 12 EtherNat boards! :) The shipping process has begun. Zanier Lodovico, if you read this please contact me regarding verification of your shipping address! For some reason we don't have your email address so I have to do it this way... Contact me at "hencox (at) hotmail (dot) com", or "henrik (at) gildaelectronics (dot) se". | |
| June 17th 2009 | This week I (Henrik) am on leave from work because my next assignment seems to have problems deciding when I should start working for them... (I'm a consultant). I spend this time repairing the remaining EtherNat boards and up till now I've fixed 4 boards. :) | |
| May 26th 2009 |
Time for some news! We came home from Outline 2009 late on sunday evening. It was a great party as usual, and it was great to meet everybody again. :) This party was also quite productive for us, since we managed to make the VDI and AES output the desktop to the SuperVidel! Big thanks to Pep (Peter Persson) for all the help with tricking the VDI. We also added support for double pixel width (for 320 pixels wide resolutions) and line doubling (for 240 lines resolutions). This will be useful when patching some games and stuff, to use the higher bandwidth to the graphics RAM. | |
| May 9th 2009 | This week we have each worked on a separate area. Henrik inserted another I2C controller into the design to communicate with the DVI chip. It seems to
work fine. Feeding the monitor with a DVI screen will be a common job for us both later. Torbjörn focused on defining our own SuperVidel registers for setting screen address and
other stuff. These regs were hardcoded in the VHDL code until now. The registers have not yet been implemented, but it shouldn't be too much work. Later on we want to include a small soft CPU (maybe PicoBlaze) in the FPGA, to automatically control the two I2C units when new DVI or Clock settings have been written to the mentioned registers. The PicoBlaze should then take the register settings and output them to the right chip. When that is done, it will be much easier to change resolutions and clock rates, since we don't have to control the I2C controllers from our 060 code.
We have also resumed looking at the remaining EtherNats, which need quite some manual labour before shipping. | |
| May 2nd 2009 | Time for an update again! We promised some speed numbers two months ago(!) but we must have forgotten about that... Sorry. Since last time we have focused on getting a working video pipeline, so we could display a picture from DDR memory. Until then we really didn't have a graphics card, but now we do! :) These two months have been spent on connecting our old working video pipeline to the CT60+DDR structure mentioned earlier. So far we have only tested the 32-bit pixel mode in 640x480x60Hz, and it seems to work fine. The reason this has taken so long is that we had lots of minor bugs, and it's only during weekends we've been able to concentrate our efforts. Without the oscilloscope from Henrik's job these problems would have taken forever... The whole thing is far from Videl compatible yet, but at least now we have something to play with at the Outline party. :) By the way, now we run the DDR memory constantly at 210MHz (DDR420) and it works fine all the time... :) | |
| February 28th 2009 11:45am | We haven't run any speed measurements on the DDR memory yet, but we have just run the DDR memory at 200MHz!!! That's DDR400, people, and our goal was DDR333! This raises the theoretical memory bandwidth to 1.6GB/s from 1.3GB/s. :) | |
| February 28th 2009 01:30am | Success! After three long weeks implementing the CT60-to-DDR bridge we now have verified 060 longword write and read accesses to and from the DDR memory! :) We still have some small fixes to do to make all byte, word and move16 accesses work also, but that is a very minor job compared to what has already been done. The accesses are also a bit slow yet, because of the asynchronous bridges we've had to implement and the mandatory precharge operation that the Xilinx generated DDR controller performs after each read or write operation. We'll speed this up by adding a cache on the ddr controller in the future, which will cancel most of the cycles wasted by the Xilinx controller precharging. Tomorrow you'll get some memory performance numbers, but keep in mind that these are very preliminary and doesn't in any way reflect the final performance of the DDR memory. | |
| January 21st 2009 | A few EtherNat boards are ready to be shipped. They are targeted for: Olivier Toumelin (1 board) Dieter König (1 board) Michael Schoppe (1 board) Sasa Andrijasevic (1 board) Gisbert Siegmund (2 boards) Samuel Ferrer (1 board) Left to receive boards are: Uros Vidovic (1 board) (Additional payment required before shipment, please contact us) Raphael Zweifel (1 board) Rob Perry (1 board) Thierry Rouvroy (1 board) Jean-Gabriel Bertrand (1 board) Christiano Fittoni (2 boards) Alan Hourihane (1 board) Jeanne Martz (1 board) Frank Naumann (1 board) Thomas Brown (1 board) Alexander Beuscher (1 board) Zanier Lodovico (1 board) Mikael Degerfält (1 board) David J. Omre (1 board) Cyril Lefebvre (1 board) John Perez (1 board) | |
| January 17th 2009 22:38 | This day we've focused on generating a simple test image pattern for the analog VGA output (640x480), to prove that the DAC design works. We used the 80MHz CT60 clock for generating a 25MHz clock to the DAC at first. This was a mistake, since we soon saw that the monitor image was all jagged in the edges. Our oscilloscope showed that the 80MHz clock is very unstable in frequency (perhaps using spread spectrum to reduce EMI?), and thus not suitable for video timing. Instead we used a 16MHz clock coming from our onboard clock chip, which is intended for video timing generation. Using that clock signal (multiplied by 25/16, to get 25MHz) we got a stable output pattern and sharp screen edges. | |
| January 16th 2009 23:56 | Success! We've just managed to program the PROMs of the SuperVidel, which in turn programs the FPGA with a small test program. This program is clocked by the CT60 clock and divides by 1024. The result is used for toggling an output pin and we're currently looking at this pin using a logic analyzer. The pin shows a nice 78kHz frequency. :) | |
| January 16th 2009 20:50 | Now we've almost finished installing Xilinx ISE (7GB) to be able to check the JTAG chain. The debugger hardware itself has already verified that our 2.5V works, by lighting its LED. | |
| January 16th 2009 20:00 | You'd better have a change of underwear nearby before you take a look at this photo: SuperVidel We have just received it and we're currently trying it out on our CT60. As yet we've verified that the 1.8V and 1.2V are working and now it's time to connect the JTAG cable to check the FPGA. More news will follow... | |
| October 11th 2008 | The EtherNat boards were shipped a little more than a week ago, but not to all people mentioned in previous post since some people haven't answered. So again, Ronald Hall and Olivier Toumelin please contact us. The SuperVidel has now entered the state of "Layout finished, verfication started before prototype production." :) Here's a screenshot of the layout: SuperVidel | |
| September 8th 2008 | Another batch of EtherNat boards is about to be shipped. The following people will receive boards: Rob Mahlert (1 board) Tobias Hagemann (1 board) Gillis Robertsson (2 boards) Vincent GARONNAIRE (1 board) Ronald Hall (1 board) Guus Assmann (1 board) TOUMELIN Olivier (1 board) Thomas Reiss (2 boards) Tommy Jonaesson (1 board) Anthony Green (1 board) Douglas Duchene (1 board) If you are among the recipients above, please verify your shipping address to us. You should have received an email about this matter also. During sending of this email we got reports however that the email didn't reach Ronald Hall and Olivier Toumelin. Ronald and Olivier please contact us. | |
| August 7th 2008 | Just wanted to say that the SuperVidel has progressed some more during my vacation this summer. :) Thanks to the first two weeks of rain, some heavy routing of the SuperVidel's PCB was performed. First the DDR2 part was completed. The data lines were length-matched to comply to the tight timing margins of DDR2 333. Then the data, clock, address and control lines of the DDR2 were simulated to ensure as clean signals as possible. This actually led us to a more simple design than we had from the beginning. :) Next the DVI chip was routed, first the digital signals from the FPGA and then the differential highspeed TMDS signal pairs leading to the DVI connector. Since the TMDS signals are running at up to 1.65GHz they require careful layout considerations. But we're pretty sure we've followed all the things mentioned in the datasheet, like differential impedance and separate output grounds. :P Then the DAC was routed, its digital input signals coming from the FPGA and the analog outputs leading to the DVI connector. Dual Schottky diodes were added to the analog outputs to protect these pins of the chip from damaging voltages if the SuperVidel is running while being connected to an active display. This was something we copied from an application note, so we think it should be trustworthy. Last we began routing the CT60 connector signals. At the time of writing the CT60 data connector (upper connector) is completely routed while the address connector (lower connector) remains.When the CT60 connectors are routed not much is left to do, only small things like the Flash memory for keeping the FPGA configuration and garnishing the whole board with a lot of capacitors. One slight obstacle though is the power plane with all the different voltages that have to reach all possible corners of the board. Thankfully the SuperVidel is a six layer board and there’s a layer that serves as a mixed signal/power layer that may be used for this. Now we consider the PCB of the SuperVidel to be around 85% complete. Note that this percentage does not include the VHDL code that will control the behaviour of the FPGA, but when the board layout is finished we may finally order the prototypes to be manufactured, and then it will not be easy to stop us from developing all the cool stuff like the SuperBlitter, MPEG-support and 3D-support. :) Maybe you'd like to see what the layout looks like now? :) Here it is: SuperVidel During my vacation a few EtherNat boards were soldered also. But only half of them work right away. At least now we have 7 working boards for the upcoming batch. :P | |
| June 28th 2008 | Right now we're sitting at NAS2008 working on the Supervidel. After Outline we ran into simulation difficulties with the DDR2 SDRAM interface on the SV, but we have now found a solution. There are still some work to do with verifying all the different aspects of the DDR2 interface, but then we can go on with the CT60 bus and DVI stuff, which should take a lot less time. Our vacations have started now, so we will be able to get some more EtherNats ready too. | |
| May 12th 2008 | Some weeks ago the 17 boards mentioned below were shipped to their respective buyers (Lance Ringquist ... Jean-Luc Ceccoli). :) The next batch was started shortly after that and now it consists of 5 finished boards and 3 that are soldered but not programmed yet. | |
| March 6th 2008 | The EtherNat boards have been packaged and are about to be shipped, but I need to get in contact with Hans-Ulrich Scheele to verify his shipping address, because my email bounced when I tried emailing him. If you read this Hans-Ulrich or someone who knows you please verify your shipping address to me at "henrik at gildaREMOVETHISelectronics.se". I don't dare ship to an unverified address... :-P | |
| January 27th 2008 | Time for a news update and it's entirely about the EtherNat shipping. The next batch is now 17 programmed and tested boards. The following people is therefore due for receiving their boards during the next shipping: Lance Ringquist 1 board Mark Branson 2 boards Hans-Ulrich Scheele 2 boards Fabio Cornero 1 board Janez Valant 1 board Thomas Richard Jordan 1 board Fredrik Olsson 1 board Jarkko Pitäjämäki 1 board Alexander Ernst 2 boards Juergen Schmidt 1 board Zoran Marinkovic 1 board Christian Hellmuth 1 board Jean-Luc CECCOLI 2 boards Remaining receivers are: Rob Mahlert 1 board Tobias Hagemann 1 board Gillis Robertsson 2 boards Vincent GARONNAIRE 1 board Carey Christenson 2 boards Ronald Hall 1 board Guus Assmann 1 board TOUMELIN Olivier 1 board Thomas Reiss 2 board Tommy Jonaesson 1 board Anthony Green 1 board Douglas Duchene 1 board Dieter König 1 board Michael Schoppe 1 board Sasa Andrijasevic 1 board Uros Vidovic 1 board. Additional payment required before shipment, please contact us. Gisbert Siegmund 2 boards Samuel Ferrer 1 board Raphael Zweifel 1 board Rob Perry 1 board Thierry Rouvroy 1 board Jean-Gabriel Bertrand 1 board Christiano Fittoni 2 boards Alan Hourihane 1 board Jeanne Martz 1 board Frank Naumann 1 board Thomas Brown 1 board Alexander Beuscher 1 board Zanier Lodovico 1 board Mikael Degerfält 1 board David J. Omre 1 board Cyril Lefebvre 1 board John Perez 1 board | |
| November 24th 2007 | Though late as usual (:-/), today I shipped a total of 23 boards to the following people: Jan Sommerkorn (11 boards) Lubomir Fedorcak (5 bords) Bohdan Milar (5 boards) Ian Robert Frost (1 board) David Galvez Charles (1 board) If you have ordered your EtherNat(s) through one of the first three persons above, you should contact them to see when you could have your board delivered. | |
| October 26th 2007 | I need to get in contact with Milar Bohdan and Lubomir Fedorcak, so that you can confirm your email addresses before I ship your boards. I sent an email some time ago but I guess it disappeared somewhere on the way. I cannot ship your boards until your addresses are confirmed to avoid the risk of lost shipments. | |
| September 3rd 2007 | The batch now consists of 22 finished boards. My falcon has shown some problems like giving me bus errors when doing the flood ping tests on the last three boards so the last week not much has happened. But I suspect that it's just a matter of resoldering the connectors of my CT60 and the expansion connectors on the motherboard. I recognize the problem from long ago, and I think I cured it this way... :) | |
| August 12th 2007 | The next batch now consists of 15 finished boards and around 30 that are yet to be programmed and tested. :) | |
| August 4th 2007 | I've just returned home from visiting my brother in Halmstad for almost two weeks. Together we managed to solder the connectors on 40 EtherNat boards, so the next batch is going to be quite big. :) I got a suggestion from Sasa Andrijasevic to post a list of all the people left to receive EtherNat boards together with an estimation of batch number and likely shipping date. So here it is: Next batch will contain around 40 boards, of which 4 are soldered, programmed and tested while the others are only soldered. Completing the other boards to reach 40 will take a while, I estimate at least a month from now. After that the boards needs to be packaged and I hope I get some help from Andreas Sjöö (MRF) this time also... ;) A reasonable date for shipping of the next batch is beginning of October. The following people are likely to be included in the next batch: (order of decreasing likelyhood) Ian Robert Frost 1 board Jan Sommerkorn 11 boards Milar Bohdan 5 boards Lubomir Fedorcak 5 boards Lance Ringquist 1 board Mark Branson 2 boards Hans-Ulrich Scheele 2 boards Fabio Cornero 1 board Janez Valant 1 board Thomas Richard Jordan 1 board Fredrik Olsson 1 board Jarkko Pitäjämäki 1 board Alexander Ernst 2 boards Juergen Schmidt 1 board Zoran Marinkovic 1 board Christian Hellmuth 1 board Jean-Luc CECCOLI 2 boards Rob Mahlert 1 board The batch(es) coming after the next is harder to estimate, but I make a preliminary split like this: Tobias Hagemann 1 board Gillis Robertsson 2 boards Vincent GARONNAIRE 1 board Carey Christenson 2 boards Ronald Hall 1 board Guus Assmann 1 board TOUMELIN Olivier 1 board Thomas Reiss 2 board Tommy Jonaesson 1 board Anthony Green 1 board Douglas Duchene 1 board Dieter König 1 board Michael Schoppe 1 board Sasa Andrijasevic 1 board Uros Vidovic 1 board. Additional payment required before shipment, please contact us. Gisbert Siegmund 2 boards Samuel Ferrer 1 board The last batch: Raphael Zweifel 1 board Rob Perry 1 board Thierry Rouvroy 1 board Jean-Gabriel Bertrand 1 board Christiano Fittoni 2 boards Alan Hourihane 1 board Jeanne Martz 1 board Frank Naumann 1 board Thomas Brown 1 board Alexander Beuscher 1 board Zanier Lodovico 1 board Mikael Degerfält 1 board David J. Omre 1 board Cyril Lefebvre 1 board John Perez 1 board | |
| July 8th 2007 | The next batch is slowly coming together. It now consists of 4 finished boards. I would like to take this opportunity to ask all of you out there to please don't email me this much. I know and understand you are eagerly awaiting your EtherNat board(s), but please, I'm alone doing all this huge work and your emails take time away that I could have used for finishing more boards. Unfortunately the work I have to do here isn't just "shipping off" some boards. Each board takes me in total several *hours* to complete, not minutes. Just like you I have lots of things I have to do in my spare time and my job does its best to keep my spare time to a minimum... Now there are 77 boards left to ship. I will be building this batch up to around 20 boards again and the next receivers will probably be: The people who have ordered through Jan Sommerkorn in Germany. (11 boards) The people who have ordered through Milar Bohdan in the Czech Republic. (5 boards) The people who have ordered through Lubomir Fedorcak in Slovakia. (5 boards). | |
| June 27th 2007 | Today 19 EtherNat boards were shipped out to 15 people all over the world. Enjoy your EtherNat boards! | |
| April 24th 2007 | Since last week the batch consists of 18 finished boards. I'd like to reach 20 boards before I package them and send them off. Now though, I'm in the middle of finishing the bookkeeping of my company, which occupies my time during the evenings. So it'll be a few more days before I will be soldering the last boards to make the batch complete. | |
| April 2nd 2007 | The upcoming batch now consists of 15 finished boards. | |
| March 20th 2007 | Quite a few more boards are getting ready for the next batch. It now consists of 12 boards that are soldered, programmed and tested as well as 8 boards that are only soldered. But then there is the usual packing and posting to do also. I'll try to keep this news updated at least once a month from now on, even though it would probably feel a bit weird if I don't have anything to write... | |
| Jan 28th 2007 | Another batch of EtherNat boards is slowly coming together. I haven't as much sparetime as I had during those weeks in late November and early December, which is the reason why this batch hasn't been dispatched earlier. But as always, we're still working on it. We get emails now and then from new buyers and of it's fun that more people are interested in the EtherNat, but we can't accept anymore orders until the current ones have been shipped. The reason for this is that we've had a considerable percentage of EtherNat boards that doesn't work alright the first time, so even though we have 130 mounted boards, we want to get the current 120 orders out the door before we dare accept any new orders. | |
| Dec 4th 2006 | Today 10 EtherNat boards were shipped to seven eagerly awaiting buyers. These are: Yvan Doyeux (1 board) Florent Lafabrie (1 board) Frank Szymanski (2 boards) Lars Baumstark (1 board) Dennis van der Burg (1 board) Anders Eriksson (2 boards) Dr Christian T. Steigies (2 boards) The next batch has been started and as yet it contains two boards that have been soldered. | |
| Nov 7th 2006 | Some of you who have ordered EtherNat boards from us are writing to us about the progress of the delivery. We really understand your concern, but we assure you that we are doing progress only that it's quite slow. The last week though my job has calmed down quite a bit so now I'm starting to get into the habit of soldering a board almost each night. We can't make any promises that everyone of you will get your boards before christmas, but many of you will. Keep fingers crossed though that the current percentage of failing boards will decrease significantly along the way... | |
| June 22nd 2006 | We visited the Outline party in the Netherlands two weeks ago, which was a pleasant trip but there was quite a bit of work involved in it too. We had brought the so far finished EtherNat boards, which we gave to people who had already prepaid there boards. They were exclusively near the beginning of our list, so I hope you don't get upset by this fact. We thought it would be a good opportunity to see that our boards will work in a variety of CT60 falcons and we had only problems with one. But that turned out to be caused by inactivated CT60 caches, so actually it couldn't be called a real problem. :) Since we delivered almost all the boards we brought to Holland, we're slightly back to the beginning of making a new batch now. I haven't been able to do any boards since I got home because I didn't have the parallell cable needed to program the CPLD of the EtherNat. I've soldered one such cable during the last evenings and today it got finished. But tomorrow it's the Midsummer holiday here in Sweden, which means that everyone is drunk and dancing around a tree. This means I will be soldering and programming new boards beginning on Sunday or next week. I've updated the download section of our homepage so that you will be able to download the EtherNat MiNTNet driver + source code. There you'll also find a link to a company that sells internal USB cables and we've followed their USB pin configuration on the EtherNat, so please have a look at the first example when you click this link. | |
| May 19th 2006 | We have now soldered, programmed and tested 12 boards. Out of those only 8 works perfectly. The others either cause the falcon not to start at all or have problems either with the USB part or the ethernet. So you people at the end of our list of orders will unfortunately have to prepare for further delays, since we have to fix each of these boards. Currently we're just taking notes of which boards have problems and take another board instead so that we'll get the first batch ready as soon as possible. We will do the first send out as soon as we have at least 10 working boards (rounded up so that each person gets the correct number of boards). | |
| April 23rd 2006 | It was a while since I last updated these news and now when I finally has got the broadband connection moved from my old apartment (it took just seven weeks...) it's definitely time for an update. I believe that many of you who have bought an EtherNat is wondering what is going on, since we said that we would start sending out boards shortly after my moving to the new apartment. Today my brother and I assembled a few more boards, but there are still a few left before we'll do the first send-out. The reason everything has been going so slow is a combination of practical and relational issues and problems. I guess that the main reason is that both me and my brother has run into problems with our girlfriends (well, got dumped). I believe you understand how such things can steal a lot of your time and energy. This lies like a wet blanket on everything else. The practical stuff that I have had to take care of during the last weeks include: moving out the last things out of my old apartment. And that was a lot of stuff. This was taken care of last weekend thanks to my family, but now I have to declare last year's bookkeeping of my company to the local tax authorities before May 2nd. And the bookkeeping is only half finished from last year. Hey, I want to make hardware, not fiddle with economic babble... During the evenings of the last two weeks I've also had to help my brother's company with finishing the layout of one of their circuit boards, because they are very short on people and it's a newly started company. If the boards aren't ready in time, you know what that means... For me this meant no time left for much else. I hope you see how our relational problems and all the side tracks are slowing us down, but we'll continue to do our best to speed things up. | |
| March 2nd 2006 | Yesterday I received 130 EtherNat boards in a big box! :) You can see a very lousy picture of a few of the boards here (I had only my webcam available for taking the picture). You probably notice that the boards lack the connectors for connecting to the CT60. That's correct. We'll solder those connectors to the boards as we program and test them before sending them off to you. I inspected a few of the boards yesterday and noticed that a few had pins soldered together on the USB chip. This is something that the mounting company will pay for... Unfortunately this will delay those boards that suffer from this problem. But not by very much I think. I tried one of the boards too. Surfing the net worked fine and also flood-pinging. I didn't have time to test the USB too, since I'm moving to a new apartment tomorrow, but that shouldn't be a problem either. Since I'm moving this weekend, the process of soldering/programming/testing/sending the boards to you won't begin until next week. | |
| February 5th 2006 | We have some good news for you! :) We received the last components last Friday so now we can start producing the EtherNat boards. The production will begin slightly more than one week from now. That's the minimum setup time the manufacturer requires after receiving the components from us. Then the production should take no longer than two weeks according to the manufacturer. After that we can start distributing your boards. :) The boards require programming and testing first though, so you'll have to be patient with us during that time too. | |
| December 17th 2005 | The news updates have been left behind for a long time now. I guess that's a result of all the administration involved in receiving payments from so many people. :) I just wanted to write something about our projects now. Regarding the EtherNat we're still gathering all the required components. If you read this you probably also received an email about our problems finding the LAN-chip. That has been solved now. Instead there are two other chips that are hard to get within reasonable time: the CPLD chip and the USB power supervisory chip. We're about to evaluate a slower speed version of the CPLD to see if it still fulfills the timing requirements of the EtherNat board. If it does then we'll be able to get the CPLDs within 2-3 weeks instead of 10 weeks. Perhaps you're wondering what's happening to the SuperVidel. Well we're doing a light version of the board. At first it was only meant to give our developers something to play with while we do the real SuperVidel, but now we more and more believe that the SuperVidel Lite is perhaps the only SuperVidel. It's because of both economical and practical reasons. If we do the Lite version we'll be able to select a cheaper FPGA chip, which will help us reach the target price of 200-250 euro (our estimations have shown that it will be quite difficult to reach 200 euro otherwise). We've realized that there would be problems fitting an SO-DIMM socket to the SV because the space between the expansion connectors of the CT60 is quite limited. It would also be very hard to fit more than a single DDR memory chip, also because of space issues. So we've ended up with only one 16bit DDR memory chip on the SuperVidel Lite. Look further down for the performance differences. I've been busy routing the new board the last few weeks and now I feel it's about 80% done, so we'll hopefully have prototype in February or March. Here are the important differences between the SuperVidel and it's Lite version: DDR memory bandwidth:SuperVidel Lite: 675MB/sSuperVidel: 2700MB/s Resolutions:SuperVidel Lite: Max 1600x1200x24bitx85Hz (We might have 30bit resolutions on the SV Lite though)SuperVidel: Max 1600x1200x30bitxYYYHz (the memory bandwidth doesn't limit the vertical resolution) Internal features:SuperVidel Lite: SuperBlitter, MPEG (or just IDCT), simple 3D-support (4x4 matrix multiplier)SuperVidel: SuperBlitter, MPEG, slightly greater 3D-support than the SV Lite. At least these are our aims with the SV Lite. Space inside the FPGA might restrict us, but we've selected an FPGA that has the least chance of doing that to us. Here's a screenshot of the current layout of the SV Lite: SV Lite | |
| September 27th 2005 | This is a personal message to Thomas Richard Jordan and Ninette Kraus. We have been unable to respond to your emails because our answers to you bounce. For some reason your email addresses are unreachable to us, and we have tried many times now and from different addresses so it can't be anything temporary. Could you please provide us with an answerable email address so that we may provide you with the details you need to know to prepay your EtherNat boards? An alternative is to have a look below in this news section, where you will find the info you need to prepay the boards. :) | |
| September 26th 2005 | We suspect that some of you atarians out there might have missed the news about prepaying for the EtherNat. We have only posted those news on www.atari.org, ct60.dhs.nu and comp.sys.atari.st. So if there are people who only read the news on our homepage :o) here you have a summary on how to prepay your EtherNat to us. Please be quick, we aim to close the prepaying period two weeks into October: There are three ways to prepay your EtherNat boards: Bank transfer (preferred), PayPal (second best), and sending money in an envelope (not preferred, but the only option to some people). HOW-TO: first pick the price list below that applies to you and summarize your total amount. Then look further below for instructions on how to pay via Bank transfer, PayPal, or sending in an envelope. Price listSwedish citizensEtherNat: 1175 SEKShipping: 1-2 boards: 88 SEK 3-4 boards: 99 SEK 5-8 boards: 110 SEK EU-citizens (non-Swedish)EtherNat: 125 euroShipping: 1-2 boards: 16 euro 3-4 boards: 20 euro 5-8 boards: 26 euro non EU-citizens in Europe (e.g Switzerland)EtherNat: 100 euroShipping: 1-2 boards: 16 euro 3-4 boards: 20 euro 5-8 boards: 26 euro Rest of the worldEtherNat: 100 euroShipping: 1-2 boards: 17 euro 3-4 boards: 21 euro 5-8 boards: 28 euro Why are the prices different depending on where you live??? That's because we have to collect the Swedish VAT for all customers within the EU. Outside the EU it's exportation and no VAT should be added. So why didn't the prices of the CT60 differ in this way? That's because Rodolphe Czuba doesn't run a company for distributing the CT60. If we didn't have this company then everyone would have to pay 125 euro for the EtherNat. Bank TransferTo cover the bank charges for us please add the following depending on where you live:Sweden: +0 SEK EU: +2 euro Europe non-EU: +7 euro Rest of the world: +7 euro. THEN TRANSLATE YOUR AMOUNT IN EURO INTO SEK BY MULTIPLYING BY 9.4! This is the amount you should send us in SEK (not euro!). If your bank also charges you for the transfer, you must add that too. You need to know this when doing the bank transfer: IBAN: SE0280000829901038269286 BIC: SWEDSESS Bank name and address: Föreningssparbanken Storgatan 7-9 Box 213 521 02 Falköping Sweden My name and address: Henrik Gildå Sommarvädersgatan 24 418 33 Göteborg Sweden Examples: French citizen (1 board): 125 + 16 + 2 euro = 143 euro = 1344 SEK Swiss citizen (1 board): 100 + 16 + 7 euro = 123 euro = 1156 SEK American citizen (1 board): 100 + 17 + 7 euro = 124 euro = 1165 SEK Swedish citizen (1 board): 1175 + 88 SEK = 1263 SEK PayPalSwedish citizens use Bank Transfer instead! We don't accept PayPal transfers from Swedish citizens.Add 4% to your amount to cover the PayPal charges for us. The payment must be in EURO and sent to: "hencox (at) hotmail (dot) com" Please make sure that your shipping address is correct! Examples: French citizen (1 board): 125 + 16 + 4% = 146.64 euro Swiss citizen (1 board): 100 + 16 + 4% = 120.64 euro American citizen (1 board): 100 + 17 + 7 euro = 121.68 euro Sending money in an envelopeSend your total amount to:Henrik Gildå Sommarvädersgatan 24 418 33 Göteborg Sweden Make sure you write your name and address somewhere in or on the envelope, so we know who sent the money. :) And please remember that there's a risk involved in sending money in an envelope! | |
| June 12th 2005 | We have just updated the project page for the SuperVidel with the current specifications. We have also added a project page for the EtherNat. On these pages you should find most details if you haven't heard of our projects before. | |
| June 10th 2005 | Just a short news update: Last week we sent the updated EtherNat board for prototype manufacturing. It should arrive on or before June 17th. Then we'll have to solder all the components again, and test it using the current but slightly modified software and drivers. | |
| May 11th 2005 | The last real obstacle before we can start taking orders on the EtherNat has been that the ethernet connector might be in the way of other stuff in the Falcon as the connector is placed now. One suggestion to solve this problem was to have the ethernet connector on a separate PCB with a cable going to the main EtherNat board. But this would be very expensive. In the end we decided that we should try to keep the ethernet connector on the main EtherNat board, and only consider the space taken by the internal 2.5" harddrive when placing the ethernet connector. So we have now found ourselves a harddisk bracket. Using our 9mm thick 2.5" HD the ethernet cable just fits above the harddrive. Look at these pictures:
EtherNat pic #2 EtherNat pic #3 The question is how thick a "standard" old falcon harddisk is. But you could use a pair of connector extenders between the CT60 and the EtherNat, to raise the EtherNat board a bit. This way you can use a thicker harddrive and it won't be in the way of the ethernet connector. Another suggestion we've had is to rotate the ethernet connector 90 degrees, so it faces the keyboard. We'll have a look at this before finally deciding. | |
| April 24th 2005 | Today we got proof that the USB channels work!! :) Using Jan Thomas' latest test program we could connect a USB mouse, Konica Minolta camera and an MP3 player, and get their names and ID stuff. Have a look at these pictures, which also show how it currently looks like when a USB mouse is connected.
USB pic #2 USB pic #3 | |
| April 4th 2005 | Time for a news update perhaps? They tend to come less often when there aren't that many good things to report... We went to the Outline party in Holland during the Easter holiday. The party was great, but unfortunately our falcon broke down, and we hadn't the necessary tools to fix it there. :( Now we've had a look at it with an oscilloscope at home, and it seems that the new NVRAM chip we changed just before the party had a cracked solder joint. It was enough to just "poke" one of the legs on the NVRAM chip and suddenly the falcon booted normally again. We'll resolder it next evening and then we can get back to work... :) | |
| March 2nd 2005 | The patching board was ready almost two weeks ago, and since then we have first updated our CPLDs for the interrupts, and then we have tried to get the real LAN interrupt working instead of the 200 Hz. But everytime we have entered our interrupt handler we get a spurious interrupt afterwords, which hangs the system. Finally, today we found out together with Rodolphe that there is most probably a bug in the ABE chip, which controls when an interrupt acknowledge cycle is to be sent to the falcon motherboard or to the CT60 expansion port. So now we're just waiting for him to find and fix it. ;) Then we shouldn't have to change much in the driver to make everythnig work at maximum speed. | |
| February 20th 2005 | Since last news update we've been working a little more on the Mint EtherNat driver, and now it seems to work very well. We've been surfing the Internet for the last couple of days without problems, and we've tried ftp access. We installed an ftp server on our falcon to see how fast things were moving and reached 1MB/s. :) I'm currently creating a small patch board for our EtherNat prototype, in order to use the real interrupt signal from the board instead of polling for packets using the 200Hz system interrupt. This will hopefully yield a great speed boost. This patch board is necessary because I accidentally routed the high byte of the data bus (d31:d24) to our CPLD instead of the low byte (d7:d0). And since the low byte is used for answering Interrupt Acknowledge Bus Cycles, our CPLD can't do that right now... This will of course be fixed on the final EtherNat boards. It's fixing stuff like this that prototype boards are for. :) | |
| February 12th 2005 17:32 | Now we've moved the service routine to the 200Hz interrupt. Pinging works like a charm, with 5ms inbetween each ping! If you wonder why it's as much as 5ms, just calculate 1/200... ;) Now we'll do a flood ping, to see how many packets are lost, if any. | |
| February 12th 2005 14:30 | We have just pinged our pc here, and it works perfectly! :) Now we need to move our service routine, handling receive and transmit, to the 200Hz interrupt instead of doing all the work in the timeout function. | |
| February 12th 2005 | After resetting the router(@*#!!!), we now see using a packetsniffer that our ARP-request packets actually get to the PC and that it replies. So there is no hardware problem, after all! :) The only problem now is that this currently only works in a test program, not the actual driver. We're now comparing the test program with the driver trying to find the differences. | |
| February 4th 2005 | Just got reminded to write something about how things are progressing with the EtherNat... :) Since the last news update we have started writing the Mintnet driver for the EtherNat. At first we had trouble compiling under GCC, but that has worked out now. Thanks to Frank Naumann we got the latest Mint source archive and some really good tips how to get started writing the Mintnet driver. Now we are able to receive ARP-request packets at 100Mbit/s, when pinging from a PC. But the only problem right now is that we're not sure that any transmitted packets are actually being received by anybody on our home network! The LAN91C111 IC on our board says that transmitting worked fine every time, but the PC we pinged from says it gets no answer... We'll email the support at SMSC to see if they know a way to check if there is something physically wrong with our transmitting lines on the board. | |
| January 17th 2005 | We have now soldered almost all components to the EtherNat board. Have a look at these pictures:
EtherNat pic #2 The only thing missing are the two three-pin connectors for interrupt arbitration between multiple add-on boards on the CT60. But the most exciting news now is that we just managed to establish a 100Mbit link between the EtherNat and our router!!! After a few troublesome days dealing with the registers of the ethernet controller and despite the documentation of the ethernet controller (the doc really sucks), we finally managed to enable the auto-negotiation mode of the ethernet controller and it found our router. :) | |
| January 6th 2005 | It seems we've been fooled by the USB chip documentation regarding the byte order. The documentation says the chip is little-endian compatible (like Intel-processors), which made us swap the bytes of the data bus before manufacturing the prototypes. But during our testing yesterday, we discovered that the chip is actually big-endian like on all real processors... ;). So we have to swap the bytes of the data bus again, before producing the larger batch of boards. There is another error on the prototype boards too, but we take the full blame for that one. We had somehow confused which byte of the data bus that the 060 uses for receiving the interrupt vector number during interrupt acknowledge bus cycles. We thought it was the highest byte on the data bus (d31:d24) but actually it's the lowest byte (d7:d0). This error managed to slip through despite our rigorous checking... :P We will design a small PCB for fixing this on our current prototype, but of course this will be fixed properly on the final boards. | |
| January 5th 2005 | First of all we want to wish you a happy new year! :) Just minutes ago we managed to read the HcChipID register of the USB chip!!! :) It was a small step for us, but a giant leap for all atarians! ;) | |
| December 22nd 2004 | A few days ago the other CPLD was soldered to the board as well as the rest of the resistor packs. Since then we've been trying to access a control register which we have implemented into one of the CPLDs. It didn't work very well at first, but now it does. :) Next step is soldering the Ethernet chip so we can try accessing its registers. More news and pictures coming up. | |
| December 18th 2004 | YEESSS!!! Last week we received quite a lot of component shipments containing everything from CPLDs to bus tranceivers, but the most important shipment would wait until yesterday... I present to you the EtherNat prototype boards: Bare board pic #2 We spent yesterday evening mounting one of the boards. Here you have two pictures of it. You can see that we've mounted one of the CPLDs, the bus tranceiver, as well as a few capacitors: Partly mounted board pic #2 | |
| December 8th 2004 | At last! We finished going through the checklist last night and sent it to Elprint (after struggling until 2 am with the email procedure that they use...). We didn't use the 30 day delivery option, but went for the 8 day (working days) option instead, so we should get the prototype boards before Christmas. The price difference was not very dramatic, around 400 SEK (~44 Euro), so we thought it was worth it to be able to work on the EtherNat during the Christmas holiday. Now we're going thorugh the Bill of Materials (BOM), to see what components we already have and which ones we need to order. | |
| December 7th 2004 | Torbjörn again: While we have been busy going through the checklist we have also come up with new things to check... ;-) So we're still not quite finished. Right now we're checking that the footprints for each component have the correct dimensions. Sounds like fun eh? :) Well anyway, when this is done, we can think of no more things to add to the checklist, so then we'll send the board to Elprint. :) | |
| November 26th 2004 | More news from Torbjörn: The routing is finished, and this week has been dedicated to going through our checklist before daring to send the board to Elprint for manufacturing. During this checking we found that the 16-bit data bus of the USB chip is actually in Little-Endian byte order... ;) So a quick rerouting solved that and gave us a better looking rat's nest of signals as a bonus. :) We have gone through just above half of the checklist. Estimating how long the rest will take is difficult, but 2-3 more evenings should do it, I hope. | |
| November 10th 2004 | About time for a news update again, isn't it? This time it's Torbjörn behind the keyboard, since Henrik is too busy. So what has happened since the last update in September? Henrik's company registration has gone through ok, and regarding the EtherNat board itself we have had problems deciding which RJ45 connector (for Ethernet) to use. There is a plethora of different brands for that component, all with different things integrated, like the activity LEDs and the necessary magnetics chip, between the LAN controller chip and the RJ45 connector. Besides finding a combination with a reasonable price tag, we had to make sure that our choice would keep up the necessary signal integrity for 100Mbit Ethernet. But that problem is solved now. Another problem was the generation of the clock signals to the USB and LAN controllers. At first we wanted to use an oscillator (with integrated crystal), to reduce the needed board space. But when we couldn't find cheap enough oscillators, we had to investigate if we could fit crystals with their components instead. This lead to that the USB controller had to be rotated and moved a bit on the board, which in turn led to rerouting all the signals going to that controller. This is where we are right now. When this is done though, there are no more real obstacles before sending the board layout files to make some prototypes. Hopefully this routing will be finished this week. To reduce the costs of the prototypes we'll use the 30-day delivery option, so if we're unlucky the boards won't come until mid December. Too bad, since we really wanted the EtherNat to be sent out to you all before Christmas. But at least we're very close now... :) | |
| September 12th 2004 | Just to let you know what's happening with our projects. The EtherNat is finished as far as routing and simulation is concerned. I've registered my own company to be able to manufacture all the boards without having to pay VAT for all components that I need to buy. Registering this company will take 9 weeks (!) due to the slow and inefficient Swedish authorities. But I believe I will be able to send the EtherNat to manufacturing the prototypes before my company has gone through the complete process anyway. | |
| August 19th 2004 | Oops, the link to the screenshot below doesn't work. Now I've fixed that! :P | |
| August 14th 2004 | Time for another news update, it seems. :) Well, every time I say that the EtherNat is finished (quite a few times by now), a few days later I realize that something has to be changed... :P The EtherNat currently looks like this. Compared to how it looked on the previous screenshot, I have replaced the large CPLD (blue-coloured) with two smaller ones, which together are cheaper than the big one. I've also added series termination to all data lines going to the CT60, so that signals coming from the EtherNat will look as good as possible (which means a more stable board). We can't do anything about signals coming from the CT60 though, and simulations show they are quite nasty looking. But since the CT60 seems to work well with that, I believe there won't be any problems. I've also added series termination on data signals 'within' the EtherNat (signals going from one chip on the EtherNat to another). I've also changed the oscillators to some smaller ones. I had to do this anyway, since the ones I had chosen previously were designed for 5V operation, which I had overlooked. Now there's only one thing left to change (yeah, yeah...), which is a small 2x2 connector necessary for interrupt handling between all expansion boards on the CT60. This connector has to be placed very carefully because otherwise it will interfere with the placement of the SO-DIMM we're planning to add to the SuperVidel. Yes, you read that correctly. Memory prices has gone sky-high since last time we checked ($16 for a 256Mbit chip, instead of $9 earlier! And we need four!!!). In this way, you'll get more memory on the SuperVidel to a smaller price. I've seen that 256Mbyte SO-DIMMs cost around 50 euro. This is the same price that we'd have to pay for 64MByte, had we chosen the four separate DDR chips instead. Routing the SO-DIMM connector will be much easier too. :) Anyway, this has to be investigated first. | |
| July 17th 2004 | Ouch, this time it was a reeeally long time ago we did the last update... So I can understand the worried emails we've received from some of you out there. Obviously that means we've got a quite a lot to tell this time. :) First off, perhaps you have read the article about the Super Videl and the EtherNat on www.myatari.net? (shame on you, if you haven't... ;)) That article was a kind of indirect news out-burst. We haven't been able to update our own news for at least three weeks back, when we discovered that we could no longer log in to Torbjörn's account at Chalmers to update the web page. This together with my own busy routing of the EtherNat (see further below), news updates had to come last unfortunately. But now we've moved our home page to atari.org (thanks guys!). So what about our projects then? Well, the Super Videl is making slow average progress, but that's not because we're sitting around doing nothing. Instead our (mine, mainly) focus has been on the EtherNat board. You know, the combined USB and 100Mbit Ethernet board that we mentioned on MyAtari (in that article it's only Ethernet, USB was added later). The SuperVidel has had to stand back during the last weeks because of this (except for one week, when I had nothing to do at my job... ;)). The EtherNat was finished today, as far as I can tell (there's always something to polish), but now I need to simulate the signals going from the CT60 to the CPLD on our board to make sure they measure up quality-wise. For this I need to design some kind of pseudo-CT60 board, but only with a few of its signals, I only need to have a look at the clock and perhaps a few of the data and address lines. The outcome of that simulation might be that I need to add termination resistors to "clean" the signals from the CT60. This simulation will also be performed for the SuperVidel, when the time comes. Currently the number of people interested in buying the EtherNat amounts to 60, but we're hoping we'll get at least 160, because that's the lowest multiple in which we can buy the USB controller. But since we buy it together with Rodolphe (for his CTlink), there is a chance we won't need that many buyers. But it would be cool to manufacture 160 EtherNat boards to fill up my appartment... ;) So when will the Super Videl be finished then? Time-wise the only obstacle is the heavy amount of work required to route the DDR memories (that week I spent at my job was unfortunately only enough for the left DDR memory pair). Usually I don't get that much spare time in a month (5x8 hours) to put into the Super Videl. But as I see it (and only my opinion counts in this matter... ;D) the DDR memories are the only heavy part of the Super Videl, the rest is "Sunday trip routing". Economically we need to sell a few EtherNat boards to be able to make the very expensive Super Videl prototypes (around 2000 euro each, and of course the first one won't work as expected, Murphy tells me). The prototypes of the EtherNat won't be at all that expensive (only 4-layers & simple surface mount components, compared to 6-layers & BGAs & very fine details for the Super Videl), I estimate them to around 250 euro. The final price of the EtherNat will be somewhere above 100 euro, but it depends on how many boards we sell of course. Enough news for now, back to routing! /Henrik aka hencox, your routing slave | |
| April 15th 2004 | Quite a lot of things has happened since last update of these news, so this update will be rather large... :)
First of all a great THANK YOU to Peter Persson and Mark Duckworth for offering to donate one of their 060s to us. We settled for Peter's 060 because he lives in Sweden, making postage cheaper, but Mark's offer was equally much appreciated. So now we have a 060 (though EC, but we only need it for developing the SuperVidel anyway). :) One reason these news haven't been updated for so long is that I was very busy every evening for two weeks making the two boards for the semi-prototype of the SV for the Outline party. The larger of these two boards had to be remade six times, because I always forgot something and the UV-lamp used in the process ate three cards too... This brings us naturally onto the Outline party. :) It was really great seeing everyone again. It seems like the remaining atari-users are very loyal to the platform. I recognized many faces at the party, and some I didn't recognize. But that probably is the result of the refresh cycles of my memory being too far apart... ;) During the party a Grolsch or two was consumed while we intensively developed the SuperVidel. We had two goals, first of all getting the SuperVidel semi-prototype to display anything at all, and later display the contents of the SDRAM of the FPGA board. We achieved the first goal during the party by adding a special purpose color register inside the FPGA, which is used by the output timing block as the output data to the DAC. We then coded a small test program that continously writes to this register, and now we have a nice color fade on the screen, which may be considered the first life signs of the SuperVidel. :) Unfortunately we never achieved the second goal during the party, which would have been really cool. That's what we're working on right now. :) Yesterday I made a performance test program to see how fast we can write to our special color register. I got 100 million longword writes in 13.1 seconds, which equals 29.5MB/s or 7.38 million longwords/s. This also means that one longword write takes 9 cycles to complete (computed from 66MHz), which I personally think is a little slow. If whole cache-lines would have been written instead (thus taking 12 cycles, 3 extra because there are 3 extra longwords), we would end up at 88MB/s which sounds a lot more interesting. But lets not waste any energy on optimizing the test stuff, when we can get the real stuff working instead... ;) Right now we're busy achieving the second goal, making the SDRAM accessible to the 060 while displaying the contents of the same memory. :) | |
| March 17th 2004 | Well, I've got some good and some bad news. The bad news first: our 060 (100MHz) is broken. I broke it when I was measuring the 12V pin of the CT60 expansion bus to make sure I had placed the connector correctly on the SuperVidel. The measurement pin of the multimeter slipped for a very short moment, short-circuiting the +12V pin with TM1 in the opposite column of the connector. This was apparantly enough for destroying the functionality of the TM1 pin. Now it only outputs '1' instead of switching like it should... :( Well, only thing to do is to buy a new 060... The good news part #1: The graphics card has progressed some more: lookie-lookie. You see that the CT60 connectors have been moved to the under side of the card (where they should be...), and the lower connector has been split into a surface mount part on the left side. This to allow the BR/BG/BB signals to be handled by the SuperVidel. Yes, Rodolphe, we added that even though you said we didn't have to... :) This way the SuperVidel may be placed below your PCI-card. Good news part #2: Right now I'm not working directly on the SuperVidel card. Instead I'm designing two smaller cards that will help us display the SuperVidel at the Outline party during the Easter holiday! *Hopefully* Though it's not the real SuperVidel card, but rather the FPGA development board together with these two cards acting like the SuperVidel. The first of these two cards contain the DAC and the Cypress clock generator. The other card is just some kind of adapter card, which will enable us to place the FPGA development board on the CT60. The layout of the first of these two cards was finished 30 minutes ago. | |
| March 2nd 2004 | Now the DAC has been completely routed. Have look at it. | |
| February 24th 2004 | The Super Videl seems to be progressing at a steady rate now. If you look at this screenshot you'll notice that I've completed the routing of the DDR memories and routed some of the signals of the DAC. Now there's not much left it seems. :) I must verify the signal integrity of all the signals though, specially the DDR signals, so there's still some work to do when the routing is finished. | |
| February 16th 2004 | Again some more progress on the SuperVidel. You'll
notice that I've moved the second DDR SDRAM chip from the bottom side to the top side. We didn't want to risk touching the the oscillator of the CT60 if
the chip were to be placed on the bottom side... You'll also see that I've routed a bit more, especially on the second DDR SDRAM (the one on the right
side of the FPGA). It's the data bus that I routed this weekend. By the way, we bought another falcon from one of our friends. Unfortunately this means that he doesn't have a falcon anymore, but he thought that he wouldn't use it much anyway (he was more into the ST). Lucky for us his falcon turned out to be very stable together with the CT60, which neither of our earlier falcons were. Perhaps this has something to do with the electrolytic capacitors being replaced on the new falcon... (the capacitors are light green instead of the blue colour we're used to, we think someone has done a fresh-up on the motherboard). | |
| January 29th 2004> | The SuperVidel has progressed some more. Have a look at this picture. If you compare it to the previous picture from December 22nd 2003, you'll see that I've been doing some work on the voltage regulators on the right hand side of the card. The red areas above respectively below the regulators help spreading the heat that is generated. You'll also see that I have moved the clock circuit (called U3), this to have a shorter distance to the clock input of the FPGA for the video clock. | |
| January 18th 2004> | Seems like we fixed our falcon. :) We noticed that when pressing down slightly on one of the ICs near the keyboard connector, the falcon began to work. Since we have removed a Falcon Speed/Resolution card from this falcon earlier the keyboard ACIA had two legs cut which we had soldered back again. I just tested to solder them again, and it seems like it fixed our dead falcon. :) | |
| January 11th 2004> | Our CT60 falcon has died. Well, not entirely, it still shows some life signs like the monitor is activated , but then it goes immediately into standby. We had noticed that the falcon sometimes behaved like this after I had tried fixing our faulty cartridge port by resoldering the pins. This behaviour got worse, sometimes it would only startup one or two times out of three, and now it doesn't start up at all. We suspect that some IC on the board has been damaged. We've ordered the Atari Falcon Field Service Manual from Best Electronics to try to find the problem. Together with the logic analyser that Torbjörn's company has bought and using a digital oscilloscope at my job, I think we should be able to find the problem... | |
| December 22nd 2003> | It's been a while since the last update. Though progress on the card has been slow, it still has progressed a bit. Here you have a screenshot of what the super Videl looks like right now. In the middle you see the FPGA Spartan3 in its FG456 package. Just to the left of it is one of the two DDR memory chips with its blue pads (which means its on the underside of the card), which has been routed completely. Everything that is red in the screenshot is on the top layer of the card, everything dark blue is on the bottom layer and any light blue tracks belong to the middle signal layer inside the card. Since one of the DDR memory chips has been routed I'd like to run a signal analysis on the data signals between the DDR memory and the FPGA to see if they look alright. To do this I need to assign IBIS models to the DDR memory and the FPGA component. If you don't know what IBIS is, look it up. :) But since there exist no finished IBIS model for the FPGA, I have to create my own from the general model that Xilinx provides. This means a lot of cut'n'paste work for all the 456 legs of the FPGA... Merry Xmas! :) | |
| November 9th 2003> | We've decided to use only two DDR SDRAM chips on the super videl, due to the complexity of routing the board and also due to the size constraints of the board (roughly 90x60mm). The total memory size will be unaffected by this decision, because we'll use 256Mbit chips instead of 128Mbit, but the total bandwidth will be affected. Previously we aimed at a 64 bit databus, now we have only 32 bit, but instead we increase the clock frequency from 133MHz to 166 or even higher. This is possible because of the easier routing. When I tried routing with 4 memory chips, the address and some other signals hade to be shared among the chips. Though we had two copies of the address signals, each copy being split between two of the chips, it didn't lead to any good results and therefore we have now taken the step from 4 chips to 2 chips. Earlier with a 64 bit data bus, our memory interface could be called PC2100, but since we now have "only" 32 bit data bus at a higher frequency, we now comply to "PC1300" performance. This decrease in performance won't limit the possible resolutions in any way, since even 1600x1200x75Hzx30bit needs only 576MB/s. This leaves plenty of bandwidth left for the super blitter. :) | |
| October 21st 2003> | The tests at 200MHz were successful! :) So now we can view a 1600x1200x85Hz screen on our 17" monitor, and the picture is as sharp as a corresponding
resolution on the Ti4200 graphics card on the pc. :) I've designed another test card that will test our clock distribution solution regarding the video clock to the DAC and the FPGA. If this also proves successful, then there's nothing more to test before creating the prototype. :) Torbjörn came up with an idea this weekend: by using a part of the graphics memory of the SuperVidel graphics card as a kind of shadow area of the STRAM, all patching of games and demos is unnecessary! :) This is accomplished by letting the FPGA snoop the CT60 bus, and all writes that go to the STRAM addresses are also incorporated into the 16MB buffer in the graphics card that is assigned to this use. In this way the contents of our shadow buffer will always be the same as the STRAM. This is done completely transparent from the rest of the system and the TOS, but leaves "only" 48MB of graphics memory left to the user. If these benefits aren't appreciated then there is always the solution of patching programs to make them use graphics ram instead of STRAM. | |
| October 14th 2003 at 00:40 | With the checker pattern we now have a good idea of the picture quality, and it is razor sharp. :) Well, this has only been tested at 25MHz pixel clock as yet. Now we'll try it at 200MHz and see what happens. | |
| October 13th 2003 at 23:45 | Right now we're testing the DAC test card. :) The first test was successful, meaning that my card and
especially the DAC works... :) Now we try to output a black-and-white checker pattern to get a closer look at the sharpness of the picture... | |
| October 7th 2003 | Just a few minutes ago I finished the schematic part of the FPGA component in the PCB design program. This took four days because the sweet little
thing has fourhundred and fiftysix legs (456) legs (It's a Spartan3 XC3S1000-5FG456C)... When Torbjörn gets home from the electronics show in Stockholm he's currently attending, he'll get a
nice job of verifying all those legs. ;-> I've also just now added the FPGA component to the other schematics in the project, and have just wired all the DAC signals to the FPGA. I'm going to have a look at the signal quality between the FPGA and the DAC (at 200MHz) by running an SI-analysis. Also, when my brother gets back from Stockholm I'll finally get to see the picture quality of our chosen DAC+flatcable design, because he has got the test card with him now. | |
| September 28th 2003 | The layout of the test board was finished two days ago. Here you
can have a look at it. The actual board isn't finished yet though, but will be so in the beginning of next week. That is hopefully tomorrow. :)
Besides these news, Torbjörn is busy developing his own DCT (Discrete Cosine Transform) for the FPGA. The DCT is the basic building block of MPEG-encoding/decoding... It already works in simulations, so currently it's just a matter of optimizing. :) More news when the DAC test board is finished. :) | |
| September 17th 2003 | Well the test board mentioned below hasn't been created quite yet, mainly because we're waiting for the samples for it (capacitors from AVX...). But we've been doing other things meanwhile: Yesterday we managed to get a picture on the monitor from the FPGA development board that Torbjörn has bought from Xilinx! :) The picture looked amazingly clear despite the fact that the development board lacks 75ohm termination resistors on the R/G/B outputs. They are supposed to eliminate reflections on the signal lines, which would otherwise result in a quite less than perfect picture. This whole thing now proves that we we've grasped the concept of the VGA display... :) What's left now is to do this same test with my DAC test board with the flat cable, and make sure that the flat cable doesn't affect the signal quality. After that we can concentrate on the prototype again. :) | |
| August 27th 2003 | I noticed that I had forgot to put a link to the picture of the previous testcard (the one that tested the
thermal properties of the voltage regulators), so here it is. :) The final card looked slightly
different though, with the capacitor footprints populated. But I have no picture of it... The layout of the new test card (the one with the DAC, mentioned below) was finished half an hour ago. Now I just need to print it on some transparent film, so that I can create the final pcb at my job. Here's a screenshot of the layout. | |
| August 25th 2003 | I'm designing another test card. This one will be slightly more advanced than the first one. It will feature the DAC and two connectors, one for connecting to a FPGA test card that we have received and the other connector is for connecting the flat cable through which the analog video signals are output. At the end of the flat cable a 15pin VGA D-sub will be soldered, and we'll connect the whole thing to a monitor. Then the FPGA will output some test pattern so that we can determine if the picture quality is good enough. If it isn't we'll have to consider using the more expensice coax option instead of the cheap flat cable... Hopefully this card is finished by the end of this week. | |
| August 10th 2003 | It's been quite a while since last update. This because I'm on vacation. ;) But this doesn't mean that the graphics card has been on ice. I've completed the schematics part for the clock generation, and I'm very near finishing the schematics for the DAC and the CT60 connectors. This doesn't sound like much, considering that the DDR SDRAM and FPGA parts are left, but that's because there are a lot of components to hunt down on the internet and create models for in the design application. Currently I'm creating a test board just within the application, which only contains the DAC and the output VGA connector. I want to get more familiar with the signal integrity testing. And it would be so cool to see a PCB with the DAC, even only on the monitor. :) Speaking of connectors. We've realized that implementing RGB support will create quite a lot of hazzle for us, compared to having a standard 15-pin VGA connector. The main reason for this is that 19pin D-sub connectors are near impossible to find these days. This forces us to have for example a 25-pin connector instead, and then create adapters for RGB and 15-pin VGA... So we would really like to hear your opinion on this. If you think that you will be greatly hindered by the lack of RGB support please tell us. But only if you really think so. | |
| July 15th 2003 | A few days ago I received the last samples for the regulator test board, so that I could finish it. Then I tested
the regulators, and they work. :) I performed the test with a 0.82ohm 5W power resistor, so that it could withstand 1.5A. My instruments displayed 1.2V
at the output and 2.5V in between the regulators, as was expected. :) The only disturbing thing was that both regulators got very hot, especially the
second one that transforms from 2.5V to 1.2V. At 1.5A this equals 1.95W, which the regulator has to cope with. According to the datasheet of the
regulator it increases 38 degrees Celsius per Watt dissipated. With an ambient temperature of 25 degrees (normal room temperature), this makes the
regulator as hot as 99 degrees. Great if you want to boil some water, but not for a graphics card. Not good at all... :-/ Since I'm on my vacation now, it's a perfect opportunity to make a second test board. ;) This one will have larger copper areas below the regulators. The datasheet says that this will draw more heat from them. Hopefully it will make a great difference. | |
| July 5th 2003 | YES AGAIN! Today at the Nordic Atari Show (NAS) we finally got our CT60 running! :) It seems like we hadn't pushed the 060 deep enough into its socket. Solder lead on some of its pins was in the way, even though it was barely visible. After we managed to remove almost all of the lead we could push the 060 deeper down, and then it worked! :) | |
| July 1st 2003 | As for several other people who have received the CT60 we are experiencing great problems getting it to work. We've just managed to successfully reprogram
both the ABE and SDR chips on the board, but it didn't make any difference. We still can't reprogram the flash on the CT60. What's strange is that sometimes the programming begins but fails at
the eighth or fourth lamp, and sometimes it fails earlier when trying to erase the flash, and sometimes the program reports that the CT60 wasn't even found... :( Currently we're removing the SpeedResolution Card that was fitted in our falcon before we bought it second hand. Rodolphe said that it's best to remove it anyway. | |
| June 26th 2003 | YYYYYYYEEEEEEEEEEEEEESSSSSSSSS!!!!!!!!!!!! We just fetched our CT60 at the postal office! :) We're currently installing the beauty. | |
| June 22nd 2003 | We've received the long awaited email from Rodolphe that our CT60 is on its way! YES!! :) We've received more emails from people who are interested in our graphics card. Now we're at 83. :) | |
| June 17th 2003 | Here's a screenshot of the layout of the test board with the regulators: Test board | |
| June 11th 2003 | This week I've been developing a test board to test the voltage regulators that we're going to use on the graphics card. This is to ensure that the
thermal limitations are met, so the card doesn't burn up. :) Well it's nice if the regulators don't exceed 100 degrees Celsius either. The test board consists of the two regulators plus some capacitors for buffering and decoupling. One of the regulators is for converting from 3.3V to 2.5V, and it can deliver up to 5A. The second regulator converts from 2.5V to 1.2V, meant for the core of the FPGA, and it can deliver 3A. Though it's likely that the FPGA doesn't consume more than 1.5A during operation, it's good to be on the safe side. The 2.5V is for the DDR SDRAM, and the DAC runs on 3.3V. I just read that the CT60 will begin shipping tomorrow!!! Now I now what I'll be doing during Midsummer (the greatest Swedish holiday besides Christmas and New year). ;) Well I might have a beer or two as well... ;) | |
| May 12th 2003 | Development is progressing though slightly slower than before. This is mostly because my job is taking a lot of my time right now. I'm programming a test program that allows us to play around with the Videl registers, so that we'll learn which registers does what. | |
| April 24th 2003 | We recently visited the EIL party in Dresden, which was very nice. :) It was great to see all the other
atari-people, and many were interested in our project. We worked a lot on the project, and during two days we planned, implemented and tested a new
function block in the FPGA, so we were quite productive... :) Now there is only the actual video timing generation left to do (screen output), besides
the blitter.
Xilinx has now released the Spartan 3, which is great news for us, since it is bigger, faster and better than the Spartan IIe, at hopefully the same price. So now we're converting our project to use the new Spartan 3. | |
| April 8th 2003 | We tried to update these news a couple of days ago, but the server where our homepage is seems to have trouble
with telnet login now... Anyway, we finished the CPLD mentioned below the very same day we wrote those news, or at least I think it was on April 1st. Now we're simulating it to see that it treats the flash and the FPGA correctly. | |
| March 31st 2003 | At startup the FPGA on the graphics card will be programmed from a serial flash via a CPLD. A CPLD contains programmable logic like the FPGA, but is much smaller and slightly slower. The one thing that makes it usable for us is that it keeps its contents during poweroff, unlike the FPGA. So when power is applied to the card, the CPLD will begin reading from the flash and programme the FPGA when it is ready for it. Yesterday we had a look at the documentation for the serial flash again to freshen our knowledge. To our surprise the serial flash appeared simpler now than what we remembered. Torbjörn said to me today that he wants to design the innards of the CPLD, because it's so simple. But I won't let him do it without me, I want to do the fun stuff too... ;) | |
| March 26th 2003 | At the moment our goal is to exactly define the video part of the graphics card, so that we know which I/O will
be need from the FPGA. The last couple of days I've been looking for a good way to make it possible to switch termination between 75ohm (VGA) and 150ohm
(RGB). One solution is to have two 150 ohm resistors i parallell, and one of them in series with a digital switch. When the switch is closed the
termination would be 75ohm (150 in parallell with 150) and when open the termination would be 150ohm. In this way we'll switch between 0.7V p-p (VGA)
and 1.0V p-p (RGB). The only problem on the horizon now, is that we're near the deadline of a project at my job, so I'll have very little time for this
(more interesting) graphics card project for the next couple of weeks. :/ By the way, we're at 73 cards now. :) | |
| March 20th 2003 | And now we have 72 interested people. :) | |
| March 17th 2003 | We're at 70 cards as of last week. :) | |
| March 12th 2003 | Function Pixel_decode was finished yesterday, which means that we now support all the colour depths from mono right up to 30bit! Now we have to simulate it to make sure it works as expected. Currently we're working on restructuring of the internal data bus of the FPGA. Hopefully we'll be able to turn its speed up a few notches. :) After that we'll change the DDR controller accordingly to accomodate for the new DDR SDRAM chips we'll use (4x 16bit instead of 2x32bit we aimed at earlier). | |
| March 5th 2003 | And now we're at 69 cards! :) We've been doing some more work on the FPGA during the last couple of days, but it's merely optimizations to reach the required frequencies. The design of the PCB has come to a halt momentarily, because I want to have the pin-outs of the FPGA finished before I continue. This means that we have to implement the last pieces in the FPGA, which are the Screen_output, Flash_Write and Clock_Control functions. | |
| February 27th 2003 | The amount of graphics cards has now added up to 64! :) Ironically enough this actually increases the price when we passed 60 units, because the the FPGA has to be bought in multiples of 60. So now we have to buy 120 FPGAs and the total cost of this has to be divided up among the cards. The ideal amount of units in the range 10-150 is 120 units, since this yields the lowest price per unit. So now we're hoping to get more buyers because this will lower the price. Of course if there is a reasonable way to get around the 60-multiple limit, we'll choose that solution. Apart from the economics, I'm glad to report that we've begun the schematic design of the card! :) It's going a bit slow because we have to find the correct capacitors. | |
| February 24th 2003 | 51 people have registered their interest now, willing to buy a total of 54 cards! :) | |
| February 21st 2003 | Now you are 39 people who have emailed us your interest, wanting to buy a total of 41 cards! :) | |
| February 20th 2003 | 22 people have emailed us until now, expressing interest in buying a total of 24 cards. :) The price/card at this volume is still very high. At a volume of 45 the price begins to get reasonable. | |
| February 18th 2003 | Five people have emailed us their interest in the graphics card. I don't even dare think of what the price per card would be at that amount, so let's wait until we reach at least 30. :) | |
| February 17th 2003 | During the recent weeks we've received emails from quite a few people that are interested in our graphics
card. :) Because of this we've decided to collect some information from those who are interested, just to get a figure of how many you are. :) So we
would like you to send an email to us with your name and nothing more. We do not want to receive any money now, because the prototype hasn't seen the
light of day yet, and we have only a rough idea of what the final price will be. Please send an email to us even if you have just recently
emailed us about our project, just to make sure you get included in the list. By sending this email to us you also agree that we include your email address in a future mailing list, so that we may inform you of important details later. Of course this list will only be used for this project, and no third party will ever receive your address. For the subject line of your email, please use something like "interested in CT60 graphics card" or something like that. Besides this info, we can just say that the project is progressing as usual. Torbjörn has been working more on the Pixel_decode statemachine, while I'm constructing the schematic components required for the design of the PCB. | |
| February 12th 2003 | The project is steadily progressing. We have implemented the 24bit/30bit decoding now, and Torbjörn has been
busy optimizing it so that we'll reach above 100MHz. The latest achievments hints towards cycle periods of 8.9ns, which roughly equals 112MHz. But we'll
not have any use for more than 100MHz anyway because the chip we'll use for generating the video clock (CY22150) cannot deliver more than 200MHz. The
reason why Torbjörn is optimizing this is that we want to make sure we don't drop below 100MHz during the place-and-route of the design. Might as well
optimize while it's fresh in our minds. :)
But 200MHz is more than 100, right? Yes, the trick here is to output data on both the rising and falling edges of the video clock. That way we don't have to reach 200MHz for our statemachines and other parts in the FPGA, something that we have already discovered would almost be impossible. The CY22150 has six clock outputs, though we'll only need two, one that goes to the FPGA, and one going directly to the DAC and is twice the frequency of the first one in certain cases. That way we get a usable video clock ranging from 25 right up to 200MHz. :) While Torbjörn was busy optimizing I continued creating and updating the schematic components for designing the PCB. Yesterday I drew the schematic component for the "new" 128Mbit 16bit DDR SDRAM. | |
| February 6th 2003 | The pixel_decode function is beginning to take shape. More precisely the 16bit colour depth decoding is more
or less complete, but Torbjörn insists on implementing the 24bit and 30bit modes before we continue. He wants things to be really finished before moving
on to the next part. :) Yesterday we optimized some parts of the Fetch-unit (the one that feeds Pixel_decode with data), and fixed a bug in the CT60-block. We also changed the specifications of the graphics card, because we discovered that the 128Mbit 32bit DDR SDRAM chips we were going to use are no longer available. Now the only 32bit chips available are 64MBit, which would result in only 16MB graphics memory (we'd use 2 chips to form the 64bit DDR SDRAM interface). The alternative to this is to use 128Mbit 16bit chips, which would require 4 chips to form 64bit accesses and result in 64MB graphics memory. Guess which one was our choice. :) Luckily the 128Mbit 16bit chips cost only slightly more than half the price of the 128Mbit 32bit chips, and therefore have very little impact on the price. I (Henrik) extended the functionality of the excel-sheet that we use for calculating the price per unit depending on the number of units produced. We quickly realized that the lowest price/unit is achieved when producing 48, 60, 96 or 120 units. This is because the components has to be ordered in certain multiples. Since the FPGA is the most expensive part and has to be ordered in multiples of 60, it has a big influence on the price. | |
| January 23rd 2003 | Still working on the Pixel_decode function. With 3 nested counters, 4-5 pipeline steps and muxing of data everywhere, it seems to be more advanced than we thought at first. But this doesn't stop us. Last night we managed to get the hang of how Pixel_decode should work, and we constructed one of its important structures. Now we have something to start with, and build the rest of the function around. | |
| January 17th 2003 | We're working on the Pixel_decode function now, and have completed around 30-40% of it. During its planning we discovered that the function is more complicated than we thought, but we managed to come up with a solution. The problem was that the screen address may be on a word boundary, but we must fetch data from the DDR SDRAM on a 128bit (16 byte, 8 word) boundary. This means that we have to take into account an offset into each 128bit data chunk during the processing. How we solved it is hard to explain without a picture, so I'll let it go here. ;) | |
| January 13th 2003 | The sub-function Screen_data_fetch that was mentioned in the news-posting below, is now complete and simulated. It works as expected. We're now planning the next sub-function of the Screen-display part of the FPGA, called Pixel_decode. It's rather a bit more complicated, and it's used for decoding the screen data into pixels that will be output to the monitor by the next sub-function, Screen_output. Pixel_decode will contain decoding pipelines for all the available colour-depths: mono, 4 colours, 16colours, 256colours, 16bit, 24bit, and 30bit. The first four mentioned require palette look-up, which make them even more complicated. | |
| January 8th 2003 | The new FPGA turned out to be not much better than the one we were already
working on, and actually worse when it comes to the video clock possibilities. So now we have decided to use the
SpartanII-E from Xilinx again, since it at least supports clocks ranging from 25 to 160MHz. But don't worry that this
will limit the possible solutions (1600x1200@90Hz requires 216MHz), because we've come up with a solution that
circumvents this limit, at least so that we'll reach 200MHz. Hopefully we'll be able to go a little further than that
too... :) We've begun designing the remaining 1/3rd of the FPGA design, which is the Screen-display function. It may sound like a vital function for a graphics card, and sure indeed, it is. :) The first sub-function of this function is Screen_data_fetch. As its name may reveal, it fetches data for displaying on screen. The data is fetched through bursts of 128 128-bit accesses each (actually 256 64-bit accesses, two 64-bit per clock, because it's DDR SDRAM, but internally it becomes 128-bit). Implementation of this sub-function is 75% complete, but simulation remains. Overall completion of the FPGA is estimated to 60%. | |
| December 29th 2002 | We have more or less decided to switch to another FPGA. The reason is that the old one doesn't live up to our requirements regarding the video clock. We must be able to deliver a video clock between 25 and 240 MHz (1600x1200@100Hz). We're currently evaluating the characteristics of the Altera Cyclone FPGA, which is brand new, and seems to suite us better. It will go into production during 1Q2003. | |
| December 21st 2002 | Christmas is upon us once again, and besides wading through hordes of people downtown trying to find suitable Christmas gifts, we're busy with designing our (hopefully) highly anticipated graphics card. Torbjörn is still struggling with the internal registers, which make up the Videl and Blitter registers, while I (Henrik) has begun designing the components for the schematics of the PCB. The major components are finished, and now I'm trying to summarize which voltage levels that are required and how much current on each of them. | |
| December 9th 2002 | Yesterday we received our second PC, that we ordered some months ago. The
reason why it took so long is that it's a "Volvo computer for educational purposes". If you are from Sweden, you'll
probably
know what I'm talking about... ;) This means that we in some cases can be twice as efficient when developing the graphics card, because we can work on two different things at the same time. The new pc is also quite a bit faster than the old one, which is a welcome speed increase when synthezing and simulating the FPGA. On www.atari.org we noticed some interest in mpeg-support in our graphics card. We've had a look into it, and realized that it would be possible, but it would eat more than half the logical gates of the FPGA we're currently aiming for. So unless you buyers accept that the card will be somewhat more expensive, this won't be implemented. Note also that all extra features (like mpeg-support, super blitter, 3D), won't be implemented before we sell the card, because we want to be able to produce it as quickly as possible. Only the most required features will be included: ddr sdram control, screen refresh, videl registers. We'll release new firmware later, which you can write to the flash of the FPGA to update its functions. | |
| November 22nd 2002 | Seems like updating these news has reached a new level. :) The reason for updating today, is that yesterday Torbjörn managed to optimize the CT60-to-DDR-SDRAM write cycles, lowering it from 7 to 6 cycles. So now the writing-bandwidth has been increased to 192MB/s at 72MHz. :) | |
| November 21st 2002 | While designing, we're continously simulating the behaviour of the FPGA to
make sure it's working as expected. Yesterday we simulated writing from the CT60 to the DDR SDRAM. After some small
corrections it worked correctly, and we also tried write-on-write to get an MB/s estimation. A single write takes 5
clock cycles, and consecutive writes come out at 7 cycles per write. So the pattern is 5-7-7-7-7-7-7-7-7... and so on.
Seven cycles yield 164MB/s at 72MHz. But note that this is just the perfect case. Because this is the graphics memory,
the memory might be used for screen refreshing while the 060 tries to access it, forcing the 060 to wait some
cycles. Reading from the DDR SDRAM isn't at all near that fast. It takes around 13-14 clock cycles for the CT60 to read from the DDR SDRAM. This is because we have an asynchronous bridge between the parts in the FPGA that run on the CT60 clock(64-72 MHz), and the parts that run on the DDR SDRAM clock (133MHz). This is the only way to do it, unfortunately. 13 clock cycles per read yields 88MB/s, which isn't too impressive. This might be optimized down to 12 cycles hopefully. But the graphics memory shouldn't be used for reading from anyway. The most common use is writing from the SDRAM of the CT60 to the DDR SDRAM graphics memory. "But what was the talk about 2.1GB/s all about then?" you may wonder. Yes that's what the DDR SDRAM can deliver through the 64bit data bus at 133MHz, but that's something that only the internal screen refresh mechanism of the FPGA and the block copy function (the superblitter) can enjoy. The 060 has "only" a 32bit data bus at 72MHz (maximum) to access the memory, which results in approximately the same performance as the SDRAM of the CT60. | |
| November 20th 2002 | Work is progressing as expected
on the graphics card. Now we estimate that we have completed 50% of the
stuff that goes into the FPGA. And we hope to have the FPGA finished by
Christmas, so that we can begin designing the actual PCB. How long
designing the PCB will take is impossible to say, since we haven't fully
learned how to use the PCB design program yet. Yet, we estimate the amount
of work on designing the PCB to be less than the FPGA... We have registered a new atari.org site: supervidel.atari.org :) | |
| November 14th 2002 | We've installed a new version
of the design software, which promises a 15% speed increase of the results
produced. That's just what we need. :) We ran into some problems when synthesizing though. It seems like the chipselect logic for the videl/falcon palette/blitter registers can't run faster than 89MHz. This would be enough for the CT60 anyway, but the frequency limit usually decreases somewhat during the place&route-step, so we want to reach at least 100MHz to be on the safe side. It's a bit tough to optimize the chipselect logic, since the videl registers, the palette, and the blitter must appear in three different areas in memory: $8000xx (the new area), $00FFxx (the old area) and $FFFFxx (shadow of the old area). | |
| November 12th 2002 | Last week was quite inproductive due to a complete renovation of the apartment which my brother and I share. Now that the renovation is done, we've begun working on the graphics card project again. | |
| October 28th 2002 | We would like to ask a favour of
all of you who read this. We need detailed information about the Falcon's
Videl registers. Though we have the Atari Compendium, it looks
like it isn't enough. We discovered that code generated by Screen's Pain seem to access a register that isn't documented in appendix B of the Atari
Compendium (0x00ff82c0). So if you have any special information to give us please send us an email. Thanks! :) As you might have guessed we're implementing the Videl registers in the FPGA. It's not the only thing though, we're still working on the CT60-to-DDR access capability. | |
| October 24th 2002 | Since last update we've been struggling to get our FPGA design through the place-and-route, which is the last
step when dealing with the inner stuff of the FPGA. There's no problem to get it through, but it doesn't measure up with our timing constraints, forcing
us to take a different approach in some
cases. What's funny is that the 128bit wide databus inside the FPGA gets placed and routed perfectly and measures up to the timing constraints, but
certain single signals don't. We really can't understand what the problem is, because there shouldn't be any problems with this. While Torbjörn was struggling with the place-and-route tool yesterday, I (Henrik) implemented the chipselect logic that maps our internal registers to the addresses of the old Videl and the Blitter. The actual function of these registers isn't implemented yet though. I also reinstalled MiNT on our CT2, since it had become corrupted in a strange way. | |
| October 16th 2002 | Hencox' email address expires on October 30th 2002! This means that you can no longer use di98gihe@chl.chalmers.se to reach him. Instead use hencox@hotmail.com after October 30th. | |
| October 14th 2002 | It's been quiet for a couple of weeks, but that doesn't mean we're not busy developing our graphics card.
:) Currently we're working on the CT60 access to the DDR SDRAM. More specifically we're making it possible for the 060 to do byte/word/longword accesses to the DDR SDRAM, not just burst. It's not very much that has to be done, and then we can concentrate on the other parts. :) | |
| September 30th 2002 | Yesterday we managed to optimize the data path of the DDR controller so that it runs at 136MHz, which is an acceptable speed for our graphics card. We also discovered that Micron had updated the specifications of the DDR SDRAM chips that we're going to use. Now the lowest frequency that the DDR SDRAM accepts is 125MHz, so we can forget 100MHz. Good or bad?... Good! But the biggest surprise came this morning, when Torbjörn managed to optimize the DDR controller statemachine, so that the whole thing now runs at 165.8MHz!!! This is an estimation from the synthesis tool, it might decrease a little when doing the place-and-route, which is the final step. But hopefully we'll be able to run the memory at 150MHz, which would yield a transfer rate of 2.3GB/s. The frequency we'll choose in the end is also very much dependant on the signal integrity we manage to reach when constructing the actual PCB. It's much better with a lower frequency that actually works, than a higher one that doesn't, right? Also there isn't much left to do on the DDR controller part of the FPGA. When it's finished, we can concentrate on the other parts. Probably those parts will be finished faster than the DDR controller. | |
| September 27th 2002 | Since last week we've been optimizing the counters of the DDR controller part of the FPGA. When synthesizing earlier the program reported that we would
only be able to run the DDR controller in roughly 100MHz. We noticed that the counters probably had something to do with this, so we tried a different
approach in order to make them faster. We managed to raise them from 100.1MHz to approximately 241MHz! But the joy didn't last long, because when we
inserted the new counters into the DDR controller, its speed increased to only 103MHz. Damn! When looking at the synthesis report this time, we saw that there are other parts of the DDR controller that needs optimizing. But now at least it's not the counters that pulls us down anymore... Hopefully it'll not take long to optimize the other parts too... | |
| September 27th 2002 | I (Hencox) received reports of bugs in the Frequency converter. At first glance it seemed like nothing was wrong in the source code, but then I realized that the program relies on the contents of address register a1 after a gemdos call! A real beginner's mistake... I changed the program so that it uses a3-a6 instead of a0-a3, and now it works fine. There's an updated version of the Frequency converter available in the Download section. | |
| September 18th 2002 | Again, news about the graphics card can be found on its project page. | |
| September 5th 2002 | More news about the graphics card can be found on its project page. | |
| August 3rd 2002 | As usual, we're sorry that we haven't updated our news section more often than this... :) But today we decided to announce our latest project: a graphics card only for the CT60! We have constructed a new page under the "Projects" section which will tell you what it's all about. | |
| May 24th 2002 | InSTream: I have now released an update of NatFrame and its winframe designer program. Both can be downloaded in our download section. They are now version 1.1b. The new stuff includes some new drawing modes and justification of the text in the title bar of the window. In the designer there is now a window that shows all the loaded texture, and from there you can drag and drop textures onto the window elements in the designer window. | |
| April 15th 2002 |
I (hencox) received reports from Jan Daldrup that my program, Frequency Converter, probably had some bugs. And
when I had a look at it, I discovered that the program calls evnt_timer when in supervisor mode, which is a no-no to do. ;) I fixed it by skipping the supervisor mode altogether, since I also discovered that I don't need to be in supervisor to access the DSP Host Interface hardware. So there's an updated version of the Frequency Converter available at the download page now. | |
| February 4h 2002 |
It's been a while since I (hencox) did some work on our projects, but now I have begun working on the network
routines of Reeking Rubber. During my work on the network routines of Natris I learned a great deal about STinG, the most important being that STinG
joins packets if I'm not quick enough retreiving them. I countered that with a routine that has to be called whenever the program (Natris, RR, or whatever) wants to check for and retreive packets from STinG. After retreiving a packet and letting a special message routine process it, the packet is not released (with KRfree) if the message routine didn't process the entire packet, because this means that there are more messages in the packet. This happened because STinG had joined two or more packets. The packet is kept, and processed again when my program wants to process messages next time. And it was lack of this knowledge that crippled the network of RR before, and my enthusiasm for coding anything on it. But now I'm back... :) | |
| January 16th 2002 | I (InSTream) am currently adding a second window to the NatFrame designer. It will contain all the loaded textures, and it will allow the user to drag and drop textures onto elements in the main designer window. When this is ready we'll release another updated version of the designer. | |
| December 30th 2001 | We have now added Drag&drop to the NatFrame designer, and fixed some other small bugs. You'll find it at the download page as usual. The new version is called 1.01b. | |
| December 28th 2001 | As the end of the year is drawing
nearer, we're sad to say that we haven't done very much this year. For me
(InSTream) school has been the major obstacle, so as to give some excuse...
Before Christmas we recieved an email from Thomas Kerkloh, writer for the ATOS magazine. He had some questions about NatFrame and the winframe designer program, and he also hinted some possible bugs and improvements. So now I'll fix some things on it, and then release an updated version, at least of the designer. | |
| October 14th 2001 | I want that CT60!!! *Hencox lying screaming and kicking on the floor* | |
| September 9th 2001 | We got tired of our old homepage, so I (InSTream) made some new graphics and gave it a new look. Other development has been down for a while because school has started again. | |
| July 2nd 2001 | It's been quite a while since last update of these news, and this is because I (hencox) has been very unproductive. InSTream is playing around with a texture mapping routine, trying to make it better all the time. Perhaps we'll make something out of it. | |
| May 18th 2001 | Just a personal message for Joshua
Kaijankoski from Henrik: Hi! I've tried to answer your email about four times since you first wrote to me, but my answer always bounces for some reason. I seem to be able to get your messages anyway, since I got yours the first time, so if you see this mail me again. Hopefully we can work out some other way to communicate. =) *END of personal message* The last weeks has been very unproductive, mainly due to the fact that I never got any answer from the guys working on the Graoumf tracker. But the other day I got an email from Thomas of NewBeat. He told me how to access the different channels in Graoumf tracker. It seems so easy, I can't understand how I could have missed it. :-P | |
| April 20th 2001 | Some days ago we got back from
EIL2 in Dresden. What a great party! It was nice to meet so many people
sharing our interest for the atari-platform. I also managed to do quite a
bit on the sample playback using the Graoumf tracker sources. Now I can
play a looping sample in the first track, and modify the frequency during
playback, without resetting the sample position. This is exactly what I
need in order to play the engine sound of the airplanes in Aces High. But
I have only managed to play the first track, as I said. The track
information which I need to manipulate to change the frequency during
playback, is stored in one block containing info on all the tracks of the
replay
routine. But I have been unable to find the correct offset from the first
track to the second, and so on. I'm awating an answer to my mail regarding
this from the current developers of Graoumf tracker. During EIL2 InSTream continued development of NatLine, adding the possibility of changing the system time and date. | |
| March 28th 2001 | Development has gone a little slow the last week. I've had a look at playing a sample with the graoumf routines but hasn't been able to produce anything yet. I'll give it a second shot. | |
| March 21st 2001 | I had a look at the first example that comes with the graoumftracker sources yesterday, and though my French is virtually non-existant it seemed very straight-forward to play a sample. When I get the time, I'll make a small test program to verify that it works as I thought, and that I can play more than one sample simultaneously. | |
| March 20th 2001 | NatNet: The sever part of the
Fwrite() call is slowly beginning to take shape, but it will still take a
few days before I should be able to consider it complete. It would be nice to finally add some cool sfx to Aces High. But first I need to make the graoumf tracker sources work as I want it to. I haven't had a look into it yet, but will soon (maybe this evening). I got the tip from evl/DHS to use the graoumf tracker sources. | |
| March 14th 2001 | NatNet: Yesterday I finished the
client side of the Fcreate() call, and began working on the somewhat more
complex Fwrite(). I noticed that some people have tried Aces High that I uploaded to our home page in late decemeber, and they thought it was pretty good. Thanks! :-) | |
| March 13th 2001 | Following the success mentioned
below, I have now added support for Fcreate() on the server side. It
wasn't much more than a cut&paste operation, due to Fcreate's similarity
to Fopen... ;-) I'll do the client part of Fcreate when I get the time. | |
| March 10th 2001 | yes, Yes, YES!! I AM SO GREAT!!
... Please excuse the sudden outbreak of joy and selfgratitude, but I happened to solve the previously mentioned problems concerning NatNet. It seems like a CNget_block() call must be preceeded by a call to CNbyte_count(), otherwise CNget_block will lock up for no specific reason other than it wants to... And it won't return even when the desired data has arrived. I think I must tell Ronald Andersson about this. So now Fread() of NatNet is finally working! I managed to read 50 bytes from the file on the linux server and print the contents... Doesn't sound too sexy, but that's all that's needed to implement all other stuff. | |
| March 8th 20001 | It seems like the problems with STinG or whatever it is, will stop any further development of NatNet if they can't be solved. Since the last update of these news not much has been done on NatNet due to my final exam that I've had to study for. I'll do the exam in a couple of hours, and after that I'll have all the time in the world to fix NatNet. Wish me good luck! :-) | |
| Feb 28th 2001 | NatNet again: It's seems like STinG is the one who's giving me
a headache. When calling functions of STinG "too many times in a row" within a trap, which I have to
do in Fread, it works fine the first couple of calls, but not later on... I sat all night yesterday but couldn't figure out why CNget_block works the first time but not the second one. And the server correctly reports that it has sent data to the falcon, because the send() function under Linux returns, for example, 50 when I tried to send 50 bytes to the falcon. But why doesn't the falcon receive anything??? I've been using STinG for quite a while, and can't remember having seen anything special that has to be done to a connection. Well, well... back to the old drawing board... | |
| Feb 26th 2001 | About that network thing again, which I(hencox) from now on will call NatNet: Fopen is almost completed now. You can specify a path of the file you want to open on the server, and you receive a filehandle if the opening was successful. Fclose is very simple, and works. The last couple of days I have been working on Fread, and finished it yesterday as far as I can tell. It doesn´t work as expected yet though, and I´m busy inserting "debug-strings" here and there in the source to try to locate the source of the problem. The server reports that it has received a request for reading the correct amount of data and that it has sent the requested data too, but nothing gets back to the falcon... | |
| Feb 19th 2001 | Well, that network thing described below is actually beginning to take shape. I've (hencox) implemented Fopen, and Fclose is almost working now. Of course there is much left to do, before I can even release something, but at least the necessary basics are working now, like sending/receiving to/from the server, which is practically all that's needed. The projekt could have reached this state a week ago, if the CNget_NDB call of STinG had worked as described, but it didn't. When I switched to using CNget_block everything suddenly started to behave as expected. :-| | |
| Feb 2nd 2001 | Just thought I'd write something,
even though we haven't actually accomplished anything the last four weeks.
Currently I (hencox) am doing some research about a network based
filesystem that we (nature) would have some use for. I don't mean NFS (for
unix/linux/mint) since that already exists. The problem is NFS isn't
usable under TOS nor MagiC. I'm planning on creating a system that maps a
drive under TOS to a specifiable path under a linux/unix/mint file system
tree. For example say that you want drive N to be this network drive on
your atari running normal TOS. Then maybe you have a pc running linux,
which would have to run the server part of my network file system. On the
server you have stated which path corresponds to N:\ under TOS. When you
open drive N:\ all necessary Gemdos function calls are forwarded to the
linux machine, which returns the desired file names and so on. Well I won't bore you with more of this, and I'm currently only doing research to see if this can be done. So far I haven't discovered any problems that might arise. InSTream is talking about how much he wants that CT60. I want it too... :-) | |
| Jan 4th 2001 | The designer for NatFrame has been
updated to version 1.0b, and should now have all the features we intended
from the beginning. NatFrame itself has also been updated to verson 1.0b,
and now contains all features that were planned. Always make sure you have the latest version of NatFrame, otherwise new themes might not work. There's also a new theme available. Go to the download page as usual, to get it all. | |
| Jan 2nd 2001 | InSTream released the designer today, so that it's finally possible to make your own themes for NatFrame! Go to the download page now! | |
| Dec 30th 2000 | I (hencox) got a request for Aces High, which made me realize that it wasn't available for download on our page. The game isn't complete though, it's "only" a beta version which I have uploaded, but it will still give you a very precise idea of what the game will look like when finished. Go to the download page to get it. On the projects page you can read about the game. | |
| Nov 21st 2000 | It turned out that it was impossible to get NatFrame to run under MagicPC, since it only emulates 68000 and NatFrame was compiled for 68030. I changed that and some other stuff which you can read in the README.TXT in the NatFrame v0.91b archive on the download page. | |
| Nov 9th 2000 | Today I (InSTream) have put NatFrame v0.90b on the download page. It now properly supports textures in 16 and 256 colours. | |
| Oct 14th 2000 | Oooops, we've forgot/hadn't
had the time for updating these news for quite a while! School is the main reason for keeping us busy during this time, so almost nothing has been done on our projects. But I said almost. Some days ago InSTream updated NatFrame so that it now supports textures in 16 and 256 colors! And I must admit it looks pretty good in 16 colors too, just look at the screenshots we've added to the Projects/NatFrame page. We haven't had the time/energy to make any new themes, but there's just some small thing that InSTream wants to add before we can release a new version of NatFrame. Speaking for myself (Hencox), sadly I haven't done a thing on our projects for a long time now. This is mainly because of school, currently we're building a computer from scratch. But I also feel that I need something new and exciting to code for, like the CT60. Our ct2-falcon is quite unstable, so it's not that much fun trying to code on it, when it crashes all the time. The MilanII seems to be out of the picture now, but it will certainly fuel my enthusiasm to code again, when I get my hands on the CT60. Seeing RR running in 60fps on that accelerator will surely be something! | |
| Aug 23rd 2000 | NatFrame v0.75beta was released today. Goto the Download page to get it. New features is support for textures in 15, 16, 24 and 32bit resolutions. | |
| Aug 15th 2000 | Today we have released NatFrame v0.7b. So go to the download page now! There is also a theme available, which you'll need also, since we haven't released the designer yet. | |
| Aug 12th 2000 | What remains now before the first release of NatFrame is for me(Hencox) to complete the graphics. Actually it's only the small icons of the window, but it seems like they take abnormal amounts of time to do. We figure about three (3) days from now, we should have a release available for download. | |
| Aug 8th 2000 | The last couple of weeks I
(InSTream) have been busy coding on a new winframe for Magic 6.x. Today we
felt it was working and looking good enough to put it on our homepage.
Look here!. The whole idea behind it is to
brighten up Magics dull grey windows by letting you use textures
instead. Hencox has done most of the raytracing on the first available theme, and also spent a few hours coding the screenshot-utiltity required to take the screenshots. Besides that not much have been done, on for example the Natris network, but that is hopefully about to change. | |
| June 29th 2000 | It seems like neither of our two falcons wants to work properly together with the Eclipse, so unless we can get some really qualified help, the Eclipse will unfortunately end up in the cupboard. :-( | |
| June 22th 2000 | Progress on our projects has
come to a sudden halt due to our falcons being spread out in our mother's
house, while we're trying to install the Eclipse below the CT2. Yesterday
evening I did some extensive soldering on the Eclipse to make it possible
attaching the CT2 on top of it. It seems like the Eclipse took no damage
from the surgery. We lack one component in order to put the CT2 falcon
back
together again though, so a day or two of inproductivity... The last time I coded anything on the network of Natris was during NAS, and I managed to do quite a bit. I've begun adding simulated game commands to the client to be able to complete the server's response on these commands. I've also installed povray on our little brother's 600MHz pc, so that we can finally do some serious raytracing. We only lack a decent 3D-modeller, but hopefully there is one to be found on the internet. | |
| June 7th 2000 | Work on the network routines
of Natris is going really well. About a week ago I discovered that blocks
sent on a TCP-connection may be merged together by STinG at the receiving
end. This might cause problems for the receiver, which can't rely on that
a block of data is only one game message, leading to messages being
missed sometimes. To avoid this I had to add some sort of
'blockifying' routines to the Natris network. I had some trouble making it
work at first, but last night I got it working just fine. So now it should
be
really straight forward developing the last parts of the network routines.
But it seems like it won't be ready in time for NAS after all. When the
client part of the network is ready I have to translate it into assembler
so that we can incorporate it into Natris. The experience mentioned above will also make the network of Reeking Rubber a lot more stable. Speaking of RR, work has been standing still over the last two months, mainly because we don't have a fast enough computer at home to raytrace the required graphics. But during the following two months we will have access to a 600MHz pc. (well, to get things done withing reasonable time, sometimes you have to venture to the dark side... ;-)) InSTream seems to have lost faith in Natline too, though in my opinion it's a very usable program. There seems to be some bugs in Magic 6 that drives him crazy. We got our Eclipse about a week ago, which we ordered nine months earlier... really fast delivery... not. Anyway, it doesn't seem to work alright on one of our falcons that have a Speed-Resolution Card. We tested it in another 'untouched' falcon, and it worked ok, so it's pretty obvious we have to get rid of the accelerator card. | |
| May 30th 2000 | I got so tired and frustrated
of not having the correct keyboard mapping on one of our falcons, that has
a Swedish keyboard, that I modified a program that comes with the official
Magic developer documentation, so that it gives you the correct Swedish
keyboard mapping. I may be downloaded from the Download section. Currently InSTream is devoting 100% of his coding time on Natline. And it looks better and better every day, just some small but irritating bugs to fix are left. I'm still working on the network support of Natris. Yesterday night I finally kicked out the bugs that had been hazzling me for the last couple of weeks, and now I may continue development. The initialization part of both the server and the client is complete. What remains to do is the actual realtime handling of messages in both the client and the server. But that shouldn't be hard, since it uses the same basic principles that I learned when doing the initialization part. So there is actually no new obstacles. There's just two weeks to the Nordic Atari Show, for which we hope to have ready a fully functional Natris game network. | |
| May 15th 2000 | The end of this semester is
drawing nearer, so not too much coding should be expected over the next
couple
of weeks, but still both InSTream and I have been coding on our respective
projects. I managed to get the first version of the Natris network server
up and running together with a simple client, so it shouldn't take long
before we have a usable network support in Natris. Hopefully it will be
ready at the time of NAS. InSTream has some problems with Natline. It seems like Magic is bugging him, refusing to give Natline events after the program has topped itself. Strange, but hopefully there's a logical solution to it. | |
| May 5th 2000 | Hencox typing
again: The last week I've been coding on the network part of Natris, which we happened to promise would be ready to serve as entertainment at NAS2K early this summer. The network system of Natris will consist of a server and one or more clients, which may connect to the server. Until now I've been working on the server part, and it seems to be about half finished. It will run under a normal TOS/MiNT/Magic system using STinG, so GlueSTiK and I-fusion will be required when using MiNTNet or I-connect. Under a multitasking system, it will probably be possible to run both the server and a client at the same time. Later today I will code a simple client, in order to test the server. The client code will then be incorporated into Natris. The server is written in C, so if the maximum number of allowed connections isn't satisfactory, it's a simple task to change that and recompile. InSTream has done a bit more on Natline. It works very well now, and the first beta test version was sent to one of our beta testers yesterday. More info on Natline will appear when there's a package to download. | |
| April 20th 2000 | Hello! InSTream at the keyboard
for once! As Hencox is "busy" preparing for his re-exam (actually finding
excuses not to study), I thought I'd say something about what I'm doing
right now: The application bar hencox was talking about is now officially
named NatLine, and is a Magic-only program working the same way as
Appline. The reason for starting this project was that I missed some
functions in Appline, like showing the current time and date instead of
just the amount of free memory. Another reason was that both I and another
friend found Appline unstable at times, especially in high resolutions.
One other thing I found out when I had just got NatLine up and running for
the first time was that Appline does nothing when the list of applications
gets longer than the screen is wide, so the last applications added can't
be seen. In NatLine I fixed this by letting you scroll the list
instead. Currently NatLine works as good as Appline when it comes to viewing and switching between applications. But it seems that the two programs use slightly different methods for switching. For example, when trying to open an accessory, Appline sometimes doesn't manage to, but NatLine does, and sometimes it's the other way around. And some accessories can't be opened by either of the two programs, like for example the snapshot utility that came with GEMView. But these "problems" are not very important, since you can always open an accessory from the desktop's menu bar. The configuration of NatLine will be, unlike Appline, directly in the program, so you won't need to configure any textfiles. For NAS 2k here in Gothenburg, we happened to promise that there will be network support in Natris. We'll see how that goes... ;-) Happy Easter to all of you, especially you lucky bastards who are going to SV2K... :-) | |
| April 6th 2000 | I just wanted to say that this part of the semester is the heaviest one yet, so school is taking about 90% of all my time. Therefore development on anything from my side is standing still. InSTream however, is coding some things now and then. Currently he's creating some sort of application bar. | |
| March 18th 2000 17:38 | The sample frequency converter program is now available for download! The package includes one falcon-only version and a version that can (hopefully) be run on any atari with a 68030 or later. If you think this program should be available to the older 68000-based atari's too, just let me know. | |
| March 18th 2000 00:15 | Now that the exams
period is
over for this time, life has more or less returned to normal. Today I
finished the program I was talking about on the news of February 28th. It
supports conversion of sample files from 49170Hz to either 44.1KHz or
48KHz. If you run it on a falcon, you get the ability to run the sample
data through the DSP first. The DSP applies a high-order(121 terms
formula)
low-pass filter to the sample, so that any high-frequency noise that
might have entered
the sound during sampling won't alias into base-frequency noise. Alias, that's what I meant earlier when I wrote convolution. Convolution is something completely different, but still has something to do with sound, and I confused the two words. I'm sorry for that. InSTream has also taken up development again. He is currently doing some things on Natris, like adding a pause function. He also changed the background pictures on this homepage, as you might have noticed. We hope you'll think it was to the better when he's finished redesigning it. | |
| March 4th 2000 | The day before yesterday I
fixed the bug in the drawing of the overtake-warning-arrows that caused RR
to crash. I had accidentally read and used a word-variable as if it was a
longword... Maybe I'm getting a bit rusty. ;-) Now there's only a bug left that prevents the arrow from appearing on the right side of the car. Only the left side arrow is drawn for some reason. Sounds really simple, but I have another exam on Tuesday, so officially I have no time for it. But I usually tend to work more on our games when I don't have the time for it... ;-) | |
| February 28th 2000 | During the last days I added a
small feature to RR, that helps you keep track of your opponents during a
race. When another car is within a certain distance behind you, a
flashing arrow appears on the corresponding side of your car. Maybe this
isn't of much use when playing single mode, because of the stupid AI of
the computer controlled cars, but in the multiplay mode it will certainly
be helpful to prevent the others from passing you. There are still some bugs to sort out, and unfortunately I don't have the time right now, because the exams period starts in a week from now. We've also been investigating the possibility of making a program that converts a 49KHz sample file to 44.1KHz. Sounds quite simple, just remove every 49170/44100 part of the file, and we're done, right? No, in order to avoid the convolution (I think that's the name for it, 'vikning' in Swedish), that will arise when converting to a lower frequency, we'll have to apply a high order low-pass filter to the sound data first, to cut away everything that might be above 22050Hz in the sample file. | |
| February 5th 2000 | We haven't done that much
during the last three weeks, mainly due to lack of Milan II... ;-) With it we can raytrace new objects at home without having to wait all day for it to finish. And sitting by a pc in school just makes us feel hungry and frozen. It won't be as fast as running the raytrace in parallell on several computers in school, but it sure will be much better than our ct2, which is a welcome speed increase over a standard falcon, but not enough when it comes to raytracing. Today I transferred the latest changes made to Aces High to the graphics card equivalent. So Aces High is now runnable on any Atari with a graphics card capable of 16bit output (not just 15bit!), which includes the Hades, Medusa, TT with graphics card, and the Milan. | |
| January 16th 2000 | First of all: A happy new
year! We're sorry for not updating these news during the last five weeks. We've had the time, but not the motivation... Anyway, this is what we've been doing: InSTream raytraced a snow-covered spruce and added it to RR as a new object. Currently he's changing some parts of the intro, lacking the inspiration to do something more meaningful. ;-) Last week I finally sorted out the remaining bugs of the hashtable I coded to replace the binary search tree used in the LZW-packing. That accelerated the packing by 40%. :-) I've also added support for transparent use of packed files in RR. This means that you can choose wether you want to save some megs of harddisk space by waiting a few extra seconds when the game loads the level data, or have all the data unpacked on disk by using a utility we'll include in the next release. Finally I've fixed the problems that made the network routines not working with the latest version of STinG. It wasn't any real bug to fix, just some voodoo: change some delay values here and there, a bhi to bgt, and voila! ;-) | |
| December 3rd 1999 | We're a bit tied up right now because of school, so progress on our games has slowed down to a crawl. Last week I tried to fix the network-initialization that got screwed up when I updated to the latest versions of Sting on our computers. I had probably adapted the network routines to go around some misbehaviour of the old Sting version, and now that is probably the cause for our problems. | |
| November 13th 1999 | Yesterday I (Hencox) created
and changed some routines of the LZW-packing, so we'll be able to use it
in RR and other games. This will mean however that RR won't run on 4MB,
because it will require 1.3MB extra RAM for the unpacking.
Instead the next demo version will take approximately half the amount of
harddisk space that it does today. Today I fixed the bug that prevented RR from running on our CT2. It was just a small but fatal miss in the routine that loads the previously saved menu settings. If multiplay had been on when exiting the game it would have been saved that way. Then if RR was started without STinG, the game would still try to setup the required connections to the Slaves, waiting forever for a connection... | |
| November 9th 1999 (evening) | Well, all we
had to do
to fix the whole thing was to unplug the harddisk cable and plug it in
again... And with our ct2 lying down and the tower casing removed, it seems to work just fine. I'm writing this in 720x544xTC and the computer hasn't crashed yet, so it probably was a heating problem... | |
| November 9th 1999 | Yesterday we tried finding the
reason for our ct2-falcon crashing when running it in higher resolutions.
We suspect that it has something to do with over-heating, so we removed
the casing of the tower-case, to see if the computer becomes more stable
with better air-supply. But something must have come loose or become damaged when we did that, because now the computer won't start at all. The only things that give some sort of life-sign are the fans and the different LEDs. And the monitor doesn't react either, so no picture is being sent to it. Well, well... you're never out of things to do with this computer... :-| | |
| November 8th 1999 | This weekend I (Hencox)
completed some
old routines that implements the LZW-algorithm for packing data.
Originally it took about 11 minutes to pack 320kB, on a CT2. ;-P I coded a binary search tree, which lowered the packing time to about 2 minutes. InSTream then came up with an optimization, and now it takes about 27 seconds to pack 320kB. Still quite slow, but the unpacking is a bit faster: approximately 117 200-parts of a second. However this requires about 1280kB of RAM for the string table used when unpacking, so it's not usable in our games unless they are to be run on a 14MB falcon... Apart from this nothing more has been done. For some reason RR refuses to run on our CT2, but we suspect that this is caused by some file missing or something, because when we tried transferring the source code to our other falcon it ran perfectly. It was nice to read about our games in ST-Computer too. :-) | |
| October 28th 1999 | Quite a long time since last
update again. But on the other hand not much have been done anyway. During
this time we've added one new object to RR, a traffic light, and tried to
fix a bug that makes the computer freeze when trying to exit the game on
RGB. It works perfectly on VGA though, and it is the same wether running
on ct2 or not. We have been unable to find the cause of this bug. Yesterday we bought a new 17" monitor. It's much better than our old 14" one, but we still can't enjoy its new potential, because of our ct2. Probably we did a lousy job installing the ct2, because it always crashes when running for more than approximately 5 minutes in a big screen mode, such as 740x528xTC. This also applies to smaller screens, that runs in high refresh rate, like 95Hz. We suspect that it's one or more of the solderings that aren't good enough, so we'll have a look into it this weekend. There is also a problem running RR and Aces High on the new monitor. Natris works perfectly and uses the same screens. There seems to be a lot of things that has to be fixed... | |
| September 21st 1999 | Just some small additions to
RR has been done. Now your current position among the cars is displayed,
and you have to finish at least third to qualify for the next race. We're
also going to add so that the player receives bonus points relative to his
final position after the race. InSTream is looking for a bug in the atmosphere shading when running in 2x1. Otherwise we're more and more concentrating on doing the graphics. | |
| September 8th 1999 | Yesterday I finished a small
sprite designer needed to clear the LSB of the green part of all pixels in
the sprites. This is necessary because that bit of the pixels is used to
signal wether it is "glowing" or not. InSTream finished a utility that
makes a font sprite file out of a F16-picture. This releaves us of much
work when creating fonts for our games. So work is steadily progressing on RR... :-) | |
| August 30th 1999 | Looks like the updates of
these news is less frequent when I have nothing better to do... ;-)
But here's something anyway: The tunnels is quite complete now, only some flickering pixels here and there, but unless one is looking for them, they won't cause any irritation. InSTream changed some things on the generation of the atmosphere, so that for example the night will look better. He also added lightsources in front of the other cars, making the game a bit more realistic. In order to add lights on the cars themselves, ie brakes and such, we use the first bit of the green part of a pixel. It's done when generating the shading list, so there's no extra realtime work. This makes possible to have the start lights shine through the night or fog, or whatever. Therefore I am currently coding a small sprite-design utility, specifically for setting/clearing the first green bit of a pixel. It will hopefully be finished this afternoon. :-) | |
| August 14th 1999 | One week till I do the Maths
exam again, and what better way to spend my time than updating the
homepage? ;-) Looks like InSTream has increased development-speed on RR considerably. Now he's adding the special versions of the tunnel-routines (2x1,atmosphere and 2x1+atmosphere). This ends up in quite many routines to add, but it's not entirely new routines, so it shouldn't be that time-consuming. No progress has been made on Natris and Aces High during the last weeks for obvious reasons. Natris is InSTream's project, and he's working on RR now, and Aces High is mine, and school is claiming my time. I think most people are happy to hear we're working on RR anyway. When we get that Tempest, we'll be able to raytrace the required graphics to make the night-scenario, and give you a new release of RR. | |
| August 12th 1999 | Fixing the last bug on the
tunnels of RR required some modification of the 3D-management, which in
turn rendered some new bugs... ;-) But almost all of them were fixed during a rainy day, leaving only one which hopefully soon will be fixed too. Still quite a lot has to be done before a new release is possible, but it will feature the night-scenario. It will probably be the most spectacular of all the scenarios. Nothing has been done on the other projects, we are only two persons after all. :-) Hencox has to study for the maths-exam he failed last time. | |
| July 28th 1999 | Again a few weeks since last
update. We've been visiting our mother for some free vacation. ;-) During that time InSTream finally got his thumb out of his ass and coded the tunnels. So now the greatest obstacle of them all has been passed. There is only one bug left to fix before they're ready though. Then there is just some graphical work to do before we can make another release. It's about time, it's almost a year since the last one... :-( Hencox fixed the final things on Aces High too, so now we wait for the replay routine from NewBeat, before the release. There's not much left to code on Natris either. Looks like there will be a much needed change in our release frequency. :-) | |
| July 4th 1999 | It's been a while since last
update so here is what we've been up to: Hencox has now implemented 75% of
the bonuses in Aces High. The bonuses consist of balloons that fly around
randomly for the players to shoot or crasch into, in order to get the
bonus. What's left to code is the collision-detection between balloons and
planes. Also the assumption that the joystick-routines had to be removed
in the TT-clone version is probably wrong. It has not yet been tested, but
it sounds strange that a TT-clone would lack the mouse/joystick
ports. Hencox has also finetuned the network-initialisation in Reeking Rubber, making it much more stable. Now it is possible for a Slave to start the game before the Master does, previously this would make the game freeze. InSTream has done a lot more on Natris. The two-player mode is now bug-free (it seems, anyway), and a few more scenarios have been developped. | |
| June 22th 1999 | Aces High has now been
successfully tested on a Hades060 with ET4000 under MiNT, which means that
it's possible to make a TT-clone version of all our games! The drawbacks of this though is, as mentioned before, that sound and joypad and joystick support has to be removed. Today Hencox continued on adding the bonuses in Aces High. They will have the shape of balloons that the players must shoot down or crasch into in order to get the bonus. | |
| June 18th 1999 | Oops!, forgot to tell you
about NAS99... Well, it was pretty much as we thought it would be. It's always nice to meet other users of real computers... Also we bought a MegaST keyboard for our second falcon, so that we can use a mouse for that one too. Being forced to move the mouse pointer with Alt+arrow keys had irritated us long enough. Now I (Hencox) can draw some graphics using Rainbow on that falcon too. Hencox also explored the possibility of converting our games to make them runnable on TT-clones like Hades and the rest. It proved to be a very easy task, so now Aces High has been converted, and will probably be tested on a Hades today. The falcon version isn't quite ready yet, but when it is it won't take long before the TT-clone version is released too. There are some things that have to be removed from the games when converting them from the falcon, mainly the sound, but also the joystick and joypad support, so it's keyboard only. That means that Aces High is for up to two players only on TT-clones. The computer also must have a graphics-card supporting 16bit. During the time since last update of these news, InSTream has continued his work on Natris, the Tetris clone. The code is now 90% complete, as it now also supports two player mode. What's left to do is, as always, some fancy graphics. We won't release any demo version of this game, until it's completed. | |
| June 8th 1999 | Hencox did some small stuff on Aces High, just the necessary preparations for adding the bonuses. InSTream continued working on Natris, mainly the title and menu-system. |