ivop

We need to add Slight Sid, SIDE, IDE plus 2.0, any more? And what's the exact mapping of those devices?

HCT will probably even sound better as the signal transitions will be faster and synchronous. Think going from 127 to 128 where seven bits go from 1 to 0 and one bit goes vice versa. In CMOS technology, both transitions are equally fast. In NMOS technology, going from 1 to 0 is faster than the other way around, hence there will be a short value of zero in between 127 and 128. As for mixing with pokey signals, a simple passive mixer will do, for example, route them through a 4k7 resistor and tie them together. If you use a 10k pot and use the wiper as output, you can adjust the balance as you see fit.

If I seemed to imply that redundancy is the sole purpose of using wave files for preservation, I'm sorry about that. It's just something extra on top of being closer to the original. For day to day usage I'd use a .cas file, too. @marius, I hadn't even thought about the timbre of the sounds. Thanks for pointing that out. As for whether the arcane skill of copying data to preserve it will be lost, I don't think so, but it can be forgotten (i.e. the act of copying). For reference, think about all the celluloid films from the early 20th century that are already lost because they were not copied soon enough and those that will be lost in the coming years because there is not enough time and manpower to preserve them. BTW There are people that actually make hardcopies of digital text to prolong preservation in case making a digital copy in time is forgotten. Quite recently somebody on here wrote he made hardcopies of all Atari related documents he downloaded from the internet. A decent pigmented ink on quality paper and stored under proper conditions will be good for hundreds of years. Yes, this might be a bit overkill, but who knows....

I am not saying CAS files have no use, they definitely have. But for long time preservation one needs something better, too, IMHO. I reread a statement above saying that digital data stays the same, no matter how many times you copy it. That's not true. Each time you copy a file, send it over a network, or do something similar, there is a possibility that it gets corrupted without being noticed. Sure, for the short term, just copying the damn file will suffice, but what'll happen in hundred years when we're all dead? This is where redundancy and error-correction codes and the like come in. And, paraphrasing Freddy here, having a copy as near to the original as possible leaves open the possibility to reprocess the original in different ways in the future. If you discard this near-original signal this won't be possible if the originals (i.e. the tapes) have degraded even further.

Beg to differe Ivo, but this doesn't make much sense to me. Digital data doesn't degradate (that's one of the reasons the world has gone digital). Digital data stays exactly the same no matter how many times you copy, and no matters how much time you keep it. Of course, the physical media that supports the digital file might degradate (or get damaged, or destroyed, or lost), and the data might be corrupted (say, virus). Yes, and that's exactly the problem with digital data. Current storage solutions are not built for the ages like, say, engraving in stone or titanium plates Most compression formats do not handle even slight corruption, i.e. a few bits being off. That's why most compression formats are not suitable for long (and I mean Looong) time storage on weak storage media. An uncompressed wave file is way more error-resilient. Basically, if you increase the entropy, you lose more data if a bit gets lost. You're welcome

Let me add a few things, as I have the impression that some of you misunderstand each other. If not, then please ignore me. For emulation purposes, .CAS is fine and those can always be extracted from wave files. As for preservation, think hundreds of years. If .CAS files get corrupted over the years (degradation of storage media) and there's no error-free file available anymore, the information is lost forever. Wave files on the other hand contain a lot of redundancy. A bit of corruption is less likely to destroy all of the information. A test for this might be adding some random noise to a CAS file and to a WAV file (i.e. flipping bits all over the place, or inc/dec randomly, store zero here and there). The CAS file will be totally useless. The WAV file will still convert fine to .CAS. Of course this has its limits too, e.g. too much noise or a few seconds completely missing. Multiple copies at different locations are needed too, to secure preservation even further.

Ah, I see. By garbage collecting you mean cleaning up after a normal alloc/free cycle. The points I raised relate to a "java vm-style" garbage collector, i.e. the application allocates at will and periodically the garbage collector checks for memory blocks not being referenced anymore and adds them back to the pool. This means that unreferenced memory blocks stay allocated until the gc runs, hence the too much memory allocated point I made above. BTW some people argue that garbage collection can actually be faster than the usual explicit memory management as it deallocates a lot of blocks at once and not one at the time in between normal code, but this still seems highly theoretical and does not hold up in practice, at least not for java. Haskell might be an exception, although I have not seen hard facts on that either.

I have not read this whole thread, but am I right that you are planning on using a garbage collector? If so, I would like to point out that garbage collectors always keep too much memory allocated at a certain point in time, which is generally not a good idea on systems with little memory. To minimize this effect you could run the collector more often, but this might slow down the application in unacceptable places. It's also totally unpredictable when and in what order memory blocks are de-allocated. Proper malloc and free when the application doesn't need the memory anymore is favored instead of garbage collection IMHO. Perhaps there's a time/space trade-off you have already considered and of which I'm not aware, then please ignore my rant (or elaborate ) Not meaning to disqualify your efforts BTW, I really like what you are doing.

SAM = Software Automatic Mouth

Day 6: Not really a book The quality of the source material varies. The Atari Program Text Editor http://www.4shared.c...ext_Editor.html F15 Strike Eagle http://www.4shared.c...rike_Eagle.html SAM http://www.4shared.c...Manual_SAM.html Solo Flight http://www.4shared.c...olo_Flight.html Handleiding Atari Writer (Nederlands/Dutch) http://www.4shared.c...ari_Writer.html Previous days: http://www.atariage....ederlandsdutch/ Basic Programma's voor de Atari 600XL/800XL http://www.atariage....-the-atari-48k/ Exploring Adventures On The Atari 48K http://www.atariage....ederlandsdutch/ Leren Omgaan Met De Atari 600XL/800XL http://www.atariage....ari-600xl800xl/ The Easy Guide To Your Atari 600XL/800XL http://www.atariage....ederlandsdutch/ Op Safari Door De Atari

It uses a 10MP DSLR camera. See http://diybookscanner.org/ for examples of such beasts. Presumably, ION is releasing a commercial book scanner at a reasonable price soon (~150 USD).

Day 5: BASIC Programma's voor de Atari 600XL/800XL This is a translation of The Atari 600XL Program Book. http://www.4shared.com/document/v-f2ay0X/BASIC-Programmas_Voor_De_Atari.html Previous days: http://www.atariage.com/forums/topic/190419-book-exploring-adventures-on-the-atari-48k/ http://www.atariage.com/forums/topic/190382-book-leren-omgaan-met-de-atari-600xl800xl-nederlandsdutch/ http://www.atariage.com/forums/topic/190329-book-the-easy-guide-to-your-atari-600xl800xl/ http://www.atariage.com/forums/topic/190302-book-op-safari-door-de-atari-nederlandsdutch/

I have built my own book scanner I can scan between 150-200 pages in ten minutes. After that, it takes about ten minutes to determine a few parameters for batch processing. I wrote a few scripts to automate post-processing. The end result is a pdf file. All in all it takes around half an hour of manual labor (preparations, scanning) and the rest is automated.

Book of the day! Number four. http://www.4shared.com/document/GmP1Def5/Exploring_Adventures_On_The_At.html

Here's the next book of the day http://www.4shared.com/document/1cg9Mrzl/Leren_Omgaan_Met_De_Atari_600_.html

I believe this one wasn't done yet. Second scan with my home-built book scanner: http://www.4shared.c...ur_Atari_6.html Still not 100% satisfied, but I am improving Enjoy!

First experiment with my home-built book scanner. I'm not 100% satisfied with the results yet, but for circa 20 pages per minute it works quite well and it leaves the book unharmed. I expect my next scans (some English and German books too) to be better now that I know what I did wrong the first time http://www.4shared.com/get/6kpJx14h/Op_safari_door_de_Atari.html

There's perl 5 for MiNT (Atari ST, see google...) but I have never heard of a perl interpreter for the Atari 8-bit...

Here's a vector version I just did... atari-logo.zip

Many power supplies fail, but when INGOT power supplies fail they tend to put out too high a voltage which can damage the computer. That's whey their use is not recommended. Can't this be fixed with a simple zener diode? (5.1V) Maybe it's a good idea to build something like that into he Atari itself so no bad PSU can ever fry your computer.

If basic is waiting for some kind of event result to appear, then your GUI is not running, and no result can appear. If your GUI is running, then basic is not. If you want to do this kind of thing then your GUI has to have its own thread, with all that entails. The other solution is to require that apps be completely event driven, which probably leaves basic out. Perhaps a solution to this is an interrupt that periodically saves the registers, pushes the address of a GUI routine to the stack, and jump to that with rti. The routine itself can continue basic after it has done its work, as the original return address and the register contents are still on the stack.

Awesome! It's like a second Christmas! Thanks for the good news... Yes, very good news. I asked september the 9th (just after the end of the previous range) so I assume I'll be seeing a PM at the end of the month too?

It looks like they are all photocopies. I have a bunch of such photocopies, too. A lot of them marked confidential and I was definitely not someone who wrote programs that were commercially released

I see. It is not enabled by default I guess, but with --enable-nonlinear_mixing it should work. So, does that mean that everything works like it should (except for the IRQ timing)? I remember emkay repeatedly saying this or that does not sound correct on emulators.

Hi, I was thinking about fixing the Pokey emulation of atari800. So, can anybody tell me exactly which sounds and features are not emulated properly and how to produce them on real hardware? Thanks, --Ivo