frogstar_robot

In the good ole days, you either dialed into a BBS that ran off a phone line in some kid's house or you dialed into something like TymeNet. The times have moved on. There are some old-school BBSes here and there but they have mostly moved to being accessible by telnet on the Internet. Dial-up services today expect the connecting terminal to speak the PPP protocol and have a TCP/IP stack. Apparantly this is barely possible for C-64s and isn't a plug-n-play sorta deal and the software doesn't exist or is in prototype form for the A8s. What you can do at least in major metropolitan areas is dial into ISPs that provide UNIX shell accounts. Once connected, you are sitting at a command prompt on a UNIX, BSD, or Linux machine. You may then be able to run text based web browsers like Lynx and W3M which are typically provided. Once so connected, you may even be able to telnet to an Internet hosted BBS. A possible problem is that their modems won't negotiate as low as 300 Baud. I'd leave the XM-301 out of this if you are at all serious about this. You can replicate this by using various means to connect to a serial port on an Internet connected computer in your home. Windows can be made to work this way but a BSD or Linux is easier "out of the box" for doing this sort of thing. We had a thread last week about putting A8s on the net. http://www.atariage.com/forums/index.php?showtopic=127917 The consensus was that what I've just outlined is the closest you'll get to doing that. There may be a die-hard or two running an old-fashioned BBS in your area but I doubt it. The scene has moved on.

INTO A UNIX SHELL PROVIDER....MAYBE. But you'd be better off using SIO2PC to make a serial connection to an Internet connected PC that you already have. BTW: TURN OFF THE CAPS-LOCK AND LEARN TO USE THE Shift key.

It gets even worse when the original display was a vector unit. When playing Asteroids in a darkened arcade on a real cab, your shots look like Great Bloody Balls Of Plasma Fire and the cabinet provided big echoey acoustics when they connected that you could often feel through the controls. In MAME, your shots are dim little dots by default. If you mess about with the parameters, you brighten and fatten things up a bit but you still can't get anywhere near that original vector monitor. An even on my 1280x1024 screen, you can still see jaggies that just aren't supposed to be there. Antialiasing just produces a fuzzy effect that isn't anything like clear sharp bright vector lines. Now if your emulator is driving one of these: http://www.zektor.com/zvg/index.html then I'll allow that emulation can provide a satisfactory recreation of the old vectors. As for any hypothetical new Atari device, NTSC and PAL monitors will still be commonly accessible for a number of years (unlike vector units!). Just provide composite outputs for those who want an accurate video experience.

Anything along these lines would require significant engineering for a very little return. Very few people with the needed skills will do this for "Oh! That's Cool!" factor because this thing isn't likely to have a significant financial return. There have in fact been a few 65c816 efforts. None have gotten further than the partially functional prototype stage. And no wonder, there would be few developers for what would essentially be a boutique machine. It would spend 99% of the time in Legacy Compatibility Mode. Ditto for ultra leet VideoBoards that require getting inside the machine and soldering to install. There is another thread about the possibility of a graphical enhancement addon that would be a PBI/ECI or cartport hardware/software combination video overlay type thingy. That likewise has limited viability but since it wouldn't require opening the machine it would be more accessible. Even so, it would have to bundle some homebrew or reworked classic software to do interesting things out of the box. Don't hold your breath for that one either. The very best you can hope for is FB3 type of thing with an implementation of the A8 chipset as an epoxy blob. MAYBE those who do this will be nice enough to expose all the buses for hardware hacking.....assuming it happens at all. On the other hand, there are cool things people like Beetle and Heckendorn are doing today. A cased A8 equipped with a 130XE motherboard, multi-OS roms, 576K RAM, built-in flash memory port, sio2serial hardware, and decent video output wouldn't be too hard to do with "off the shelf" components. Basically, get an out of the box experience for the most common and useful mods that are commonly done today. You wouldn't make much money on a thing like that but it is attainable as a labor of love and a few people would buy them and be able to use them to the fullest.

I'll further note these images are the best way to produce custom packages that aren't provided by stock package repositories. The Linux load on the EEE goes out of it's way to be an appliance. It can be used just fine as a general purpose Linux machine but the usual niceties that a distro like Ubuntu or Fedora provides to make this easier like a GUI package management tool and an extensive repository of prebuilt recent software are either absent or severely truncated. This is all fixable but takes a bit of tweaking. Basing the things on Etch was a somewhat nasty touch. I like Etch, I really do since I can configure things like LDAP and mail servers and they just sit there and run for years and I don't have to worry about the security and bugfix patches breaking things. But a stodgy frozen server OS isn't the thing for a trendy consumer OS where more demanding users are going to want to run newer software. You can run newer software but you'll have to build backport packages yourself. That's what these VMware images are good for. You can stuff them up with build-essential and all those -dev packages. Anyone who tries that route let me suggest the following: Debian Sid has debianized source packages for almost anything you'd want. Pulling down tarballs and manually figuring out deps is for the birds when Debian will do this for you. The secret is to chuck in a deb-src line pointing at Sid and regular pointer at the Etch package repository thusly in the /etc/apt/sources.list file: deb-src http://http.us.debian.org/debian unstable main contrib non-free deb http://http.us.debian.org/debian stable main contrib non-free So say I want a recent and proper Atari800 package for my EEE with stock OS. I build it thusly. #apt-get update (this updates the database of available binary and source packages) #apt-get install build-essential debhelper (pulls in all the compilers and Debian package building tools. only need to do this one once....) #apt-get build-dep atari800 (pulls in all the things you need to build atari800 and run it when done) #mkdir atari800 (place for atari800 source to live) #cd atari800 (change into that directory) #apt-get source atari800 (will pull the highest version of the Atari800 source available to the package system. Since we chucked in a Sid deb-src line....) #cd atari800-2.0.3 (these source packages come as a source directory and several control files. you need to change into the source directory) #dpkg-buildpackage -b (this will build the deb package and place it in the atari800 directory we made earlier. go have a cuppa or a beer) Then copy the deb to a card or ship it over the network to the EEE and install. I did that for awhile with various things then said screw it and went to Debian Lenny since they provide an install image that configures most of the EEE's little custom bits. Lenny isn't more than three months behind on the software I care about and I usually can't be fussed with the procedure I just detailed (plus Atari800 is a simple case with few dependencies. Backporting recent software can get hairier and I Just Don't Bother). I'd rather just install the damn thing and use it already...but I don't mind helping out now and again.

do "ls -l /bin/mads" and post the results back here.

Do these tools just display text to a console for their output? If so, that may be your problem. If you run a console tool from a gui then at most you'll get a blip of text and shutdown and probably not even that. If so, right click on your tool and see if their is a toggle box to "run in a shell" or some such. Otherwise, ctrl-alt-t, cd to directory (save this if dumped right in home like previous post), ./name_of_tool. Later on today, I'll see if I can get a chance to run them on my Etch box and sort this for you.

One other helpful hint: If running binaries from a console and they are not in your $PATH (type "env" to see) then you'll have to prefix a "./" eg ./atari800.sdl A single period means "this directory" and when you run a program in a directory a trailing slash indicates that it is in fact in a directory so that is why "./" means "run the following executable in the present directory". It makes more sense if you are running something in a different directory eg /usr/games/atari800.sdl (run the copy of atari800.sdl stored in /usr/games) ~/Documents/atari++ (run the copy of atari800.sdl sitting in the stupid place in my Home Directory that my browser likes to drop things) Incidentally that single period business is more broadly useful: cd ~ (change to the root of my Home Directory. "pwd" will tell you where that is in absolute terms btw) mv Documents/atari++ . (move that file to the present working directory)

You may have to set the executable bits. Linux doesn't use three letter extensions like .com, and .exe to mark files executable. Instead, "executable" is one of three basic permission types. The other two are Read and Write. Try right clicking the files and seeing if you have an option to toggle them executable. If not, press ctrl-alt-T to get a shell. "cd" to the directory containing the executables and do "chmod 755 atari800.sdl" followed by "chmod 755 atari++". You will also need the OS roms and so-forth same as when you use them on Windows. I can give you configs for those if you have trouble. You'll only need fix the directory names to match you put things.

Ask and ye shall receive: Atari++: http://uploaded.to/?id=q07kuw Atari800: http://uploaded.to/?id=bi9qh1 I have to run out the door right now so I won't be able to look into your XASM/MADS until later.

I brainfarted. If I had just stuck to saying "Debian Stable", I wouldn't have made an idiot of myself. I run a number of ahem! Etch boxes. Everything I said still goes. I'll fix my earlier posts.

Actually, this isn't the case. The stock OS is ultimately derived from Debian Etch and will run most packages built for it. If you google about for "Easy Mode Editor" you'll find a way to add more software to the Easy Interface. You can also turn on "Advanced Mode" where the UI resembles XP. Anyhoo, if you follow those guides, you can install Synaptic which is a GUI to the Debian package system and point an EEE at a Debian package repository. Various individuals also have repositories of software for the stock OS. Once pointed at these repositories, you'll have many many many things you can install. An older version of Atari800 IS in the Etch repos (2.0.2). The only real catch is that Etch is the current Debian Stable and it will be supported for at least two more years. The only updates made to the software in Etch are security and bugfixes: no new features. Server admins tend to like that very much but it means that anyone using it as a desktop or laptop OS has to either be happy with the software of two years ago or backport current releases which ranges from fairly simple to implausible depending on how many current libraries the new stuff needs. Building a current Atari800 would be one of the simple ones . If you ever want to get into that, I'd recommend installing Etch or the "EEE Development Kit" in VirtualBox (www.virtualbox.org) so that you don't stuff up your little machine with devkit detritus. Tell ya all what. I have an Etch box that I use to build packages for my servers. If anyone would like the Atari800 2.0.3 built for a stock OS EEE, I'd be happy to roll that up for you.

I don't know if this is your problem but Sun Java on Linux has a long standing bug on 32bpp screens. Seeing that is is ultimately a Java issue, it may be triggerable in Windows too but it seems to be much less frequent there. Just for a lark, try switching to 16bpp or "thousands of colors" and seeing if it plays then. I don't get bit by this frequently but I do have a script that launches FireFox in a 16bpp Window on Linux. Come to think of it, I cooked it up for exactly this problem and haven't had occasion to use it anywhere else.

There is a Debian Lenny install image that works quite well for these units. I chose it because it is about as polished in terms of all the little hardware bits working as the stock Xandros-derived install. It also doesn't require excessive system administration to get it working well afterward. Basically, do the bare bones install then apt-get the Desktop of your choice. I went with XFCE to keep things lightweight but richly functional. Atari800 would be an apt-get (or Synaptic if ya like point-n-click) away once done. http://wiki.debian.org/DebianEeePC If you want to stay with the stock OS, packages from or built for Debian Etch work well as long as they don't uninstall or conflict with any package that has Xandros or ASUS in it's name. This is mostly safe because the stock OS is an Etch derivative. Short of installing an entire KDE desktop or doing an apt-get dist-upgrade, I haven't encountered packages that caused problems when I ran the old OS. The Etch repositories have an older Atari800 package or you can use an Etch running in a virtual on a desktop machine to built a recent one. I went to Lenny because I want to run things like Firefox 3 which would have been a PITA on the old OS.

C-64 users have a roundabout way of putting a C-64 on the net. The HyperLink Parsing Proxy is a Perl program that runs on a Unix shell account with dialup access or on a local unixy host running a shell on the serial port. It does the heavy work of decoding jpegs and so forth and sends decoded bitmaps and text to the C-64 which dials in on a modem or connects by RS-232. (http://www.armory.com/~spectre/cwi/hl/manual/hl25ic.html) There is browser software called HyperLink to go with it: http://www.armory.com/~spectre/cwi/hl/ Now this isn't putting the C-64 in the net in terms of having a TCP address and so-forth but the end result is the same. Browsing at least some net content is possible. A similar approach is technically possible with an A8 although the software doesn't exist AFAIK. Like others, I'd have to ask....why?

Indeed. Plonking is a wonderful thing. I plonked a few invaders from Lemon64 and a few of our own more curmudgeonly members and the A8 boards got waaaay more pleasant to read. It just takes a minute or two and really cuts down on the urge to feed trolls. I highly recommend it.

The DTV has a re-implementation of the C-64 that takes up waaaaaaaaaaaay less room on a board than the C-64 of old. Unless someone re-implements the A8 in the same way then it isn't happening. Even so, it would make more sense to me for the A8 to have it's own plug-n-play rather than be wodged in the C-64 one. As usual, when these ideas come up, they are being much too ambitious. I'll ask a more basic question. Would it be worth it to create an expansion chassis ala the 1090 XL? If it were created, would we see cards designed for it? Given how physically awkward such a combo would be, I like the idea of an A8 in a mini tower better. This need be nothing more than a 130XE motherboard in the case along with a 1090-like baseplane.

But of course and that is collectible just after death.

Huh? English is littered with random special cases in syntax and vocabulary. English is a mashup of the non-latin derived Anglo language and Old French which then evolved for 100s of years. My understanding is that it is one of the most difficult languages for a second language. I remember well the amount of time I spent in school on "spelling demons" and verbs with unusual conjugations that didn't fit the normal rules. To make matters worse, the two primary families of spoken English UK and American are both littered with insane amounts of idiom. The only thing making English "easy" is that some of us were raised speaking it. It's a hard go for everybody else and was spread by aggression like Spanish and French. Although Spanish and French have the fact that they are Romance Languages going for them. Learn one of those and the other along with Italian won't be so bad.

Being able to merely view source doesn't suffice. If one can freely and legally modify and re-distribute relying solely on the included license then the code in question is Open Source. There are some other attributes like not restricting platforms or fields of endeavor but the legal ability to modify and redistribute is core. I picked around atarixl.de and was only able to find the vague term "freeware" as far as licensing goes although that generally means "free to use" as opposed to "free to hack on".

*plonk*

War-bait right there...... That's not entirely true. There are ways of finessing a bigger perceived pallette out of the machine. Of course, these techniques entail tradeoffs the way things like HIP and APAC do: http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm Of course, at no time is the hardware generating anything but the 16 hard wired colors but mixing them in various ways between frames and lines allows for a greater number of perceived colors and quite impressive displays are possible.

No 8-bit is going to toast bread. It takes a fully tricked out A4000 or a Falcon with a CT63 just to keep bread warm. Now a NetBurst P-IV on the other hand.......

And that is your problem. You are looking for an argument that you can feel good about winning and you've picked a really stupid place to have it which is strange since you seem to be fairly intelligent otherwise. And the A8 vs C-64 argument is a moldy oldy. Most us here are just wanting to understand how things work for themselves or to get a machine to do what we want. Nobody really cares if a given result requires some technique not necessary on a C-64 (or vice versa) unless they are developing for both platforms and even then the only thing of any importance is the result. Let's just make the guy happy and give him what he wants so we can get back to discussing how the get the best displays out of an A8. All together now: The C64 is the best 8-bit ever made. No other 8-bit is worthy to so much as grovel at it's feet.

If you can be counted on to define standard A8 practices as "trickery" then what is the point of discussing anything with you? DLI, VBIs, scanline changes, and so-forth were how the chipset was meant to be used in the first place which glancing at De Re Atari will tell you. ANTIC may be a primitive video coprocessor but coprocessor it is and meant to be used as such. It has some preset configs which the developer may use or not. I suppose using anything but a stock DLI program is "trickery" to you. I've been seeing some innovative uses made of GTIA+ANTIC but bottom line is the developer is reproducibly getting the machine to behave as he intends. If that is "trickery" then so be it. Incidentally, that early source De Re Atari also hints at possibilities now being found with ANTIC/GTIA. This is an A8 forum. You can argue superiority of your preferred obsolete platform till you're blue in the face and I wish you luck with it. It's been fun to watch in a train wreck sort of way.