Urchlay

Thanks for the info. I probably don't want to use 1.1, if it's not 100% compatible with the more modern disk formats. Parsing the human-readable error messages in 3.x or SDX will be the better solution... can 3.x read/write SDX-formatted disks (including hard disks), or will it have the same problem?

SpartaDOS experts, is there a way to turn off the English error messages in the CLI of Sparta 3.x or SDX, and have it print numeric error codes like other DOSes? Without boring you with too much detail... I'm working on a project that involves a program that communicates with various Atari DOSes (sends them commands and parses the results), running inside a modified version of Atari800. If any errors happen, my program needs to be able to convert the Atari error number (or message) to a UNIX-style error message (e.g. -ENOSPC, aka "No space left on device", whenever it sees an error 162). I've already got code that can handle numeric error messages for Atari DOS and MyDOS, so it'd be really nice to have SpartaDOS spit out numeric errors instead of me having to write more code to handle Engligh messages... IIRC, SpartaDOS 1.1 uses numeric errors, but I doubt I can use it (how well does it handle large volumes, particularly ones formatted by Sparta 3.x or SDX?)

If you aren't married to xasm or mads, there are several other cross-assemblers that run on Linux with no emulation or other weirdness required: - DASM (my favorite), http://sourceforge.net/projects/dasm/ - Atasm, very compatible with Mac/65, http://sourceforge.net/projects/atasm/ - ca65, part of the cc65 suite (ca65 is the assembler; cc65 is a C cross compiler), http://www.cc65.org/ All of the above are cross-platform (can be built for Linux, Windows, Mac, heck Solaris or AIX if you like). They all support macros, include files, and all the other good stuff you'd want from a 6502 assembler.

Used to work at a place that did hosting... one client was a porn site, owned & operated by the model who appeared on the site. My boss showed me some of the pictures (not bad I thought), said "How'd you like to meet her?". Later on, she showed up to pay her bill in person... the word "skank" came to mind, as did the words "photoshop" and "crystal meth". You'd hardly believe she was the same person.

Here's a thought... you can get "crypto accelerator" chips that are basically DES/3DES/etc done in hardware. Hang one of those off the PBI, write a driver to talk to it... the rest of the SSH protocol is much less CPU-intensive, an Atari could handle it I think... or if not, you could just do encrypted telnet (aka telnets), which gives you the security benefits without the nice fringe benefits like X11 forwarding (which would be useless to an Atari anyway) and key-based authentication (which might not be useless on an Atari...) What exactly would you use ssh for if you had an ssh client on the Atari, though? Replacement for telnet, for internet BBSes?

This kind-of already exists, in the form of telnet BBSes and the telnet chat. Of course you need a modern machine or a Lantronix type of device to actually use them. Another thing people could do would be to create new Atari-oriented web sites (or low-bandwidth versions of existing sites) using very basic HTML, designed to work well with lynx/links/w3m (text-based browsers). You'd use the Atari as a dumb terminal and browse via a browser running on a Linux/BSD/whatever box... for those not interested in Linux, someone could build a self-installing version of qmeg or bochs (virtual machine software) that includes a pre-built "Atari Linux" OS (with a standard windows "next, next, next, finish" type installer). Here's a thought: it should be possible to implement the PPP (standard Internet dialup) protocol on an Atari. You'd be able to get a dialup account and truly get the Atari on the Internet with its own modem, no assistance from a PC required... there'd have to be Atari-native FTP, telnet, irc, etc. clients written... a web browser (even a dumb text-only one) is probably out of the question, though a web client (downloader like wget) would be do-able. There's already a SLIP implementation (uIP versions 0.5 and 0.6) that's written to be compiled with cc65 and run on a Commodore 64, which should be easily portable to the Atari 8-bit... too bad no ISPs offer SLIP as an option any more. PPP is more complex, but probably possible on the A8... the transfer rate wouldn't be very fast (less than 1Kbyte/sec at 9600 baud, maybe 1.5K/sec at 19200), but you'd honestly be able to say your 8-bit was on the Internet, under its own power.

Interesting project... But unless I'm reading it wrong, the client needs to be a web browser with a full AJAX-capable implementation of Javascript... not something an Atari is likely to ever be able to run. Also, if the client doesn't support SSL, there's no encryption (you might as well use telnet)... and if you could get SSL to work on an Atari 8-bit, you could easily write or maybe port a plain SSH client, which would be a lot simpler than writing a browser with Javascript and XML support... The C++ code you're talking about runs on the server... if you extract the tarball, you'll find the client code in browser/anyterm.js, which is 19K of javascript code (so you need a javascript interpreter for the A8 that leaves enough free RAM to store that much code, plus the data structures it creates while it runs). I hate to sound negative, but I don't think it's going to work... I'd love to be wrong though, so if I'm being stupid, please correct me.

The trouble with ssh/scp is the encryption algorithms. I haven't tried to implement DES/RSA/Blowfish on an 8-bit Atari, but I bet they're too complex for the A8 to do in realtime. If nothing else, they're probably designed to work with 32-bit ints, which would cause a lot of overhead on a 6502... You might be able to do an ssh client on the A8 using the null "encryption" method (dummy method, not really encrypted), if you're not worried about security... IIRC, this requires a small change to the sshd config on the remote host.

You can definitely shoot the spikes in the original arcade Tempest. Some of the higher levels even start out with a spike in every lane, so if you couldn't shoot them, you'd always die at the end of the level.

You can already do this by compiling atari800 like so: ./configure --target=basic --disable-sound --enable-veryslow echo '#define DONT_SYNC_WITH_HOST 1' >> config.h make This gives you an atari800 binary that runs as fast as your CPU can run it, uses stdio for the E: and K: devices, and has no graphics support. You can do stuff like... # Convert a tokenized BASIC program to UNIX-readable text echo LIST | atari800 -basic someprog.bas | grep '^[0-9]' > someprog_listing.txt You could put code like the above in a shell script, then tell Firefox (or KDE/Gnome) to use it as a helper for .BAS files... or set it up as a filter in /etc/printcap so you can directly print .BAS files. You could also write a wrapper script to use Mac/65 as a cross-assembler (write code in vim/emacs/whatever, assemble and run in emulator). I suppose you could even write a grep replacement in Atari BASIC, if you're crazier than me

The bottom screenshot is "Simple Assembler", a type-in from the book "Machine Language for Beginners"... it may have been published in Compute magazine originally, before the book came out. I hated long type-ins, but made myself type that one... before that the only way I could do "assembly" language was by hand (POKE decimal opcodes/operands to memory). Also spent many hours modifying and extending the Simple Assembler. Somewhere I've got a version that requires Turbo BASIC XL, supports labels (sort-of), takes input in either hex or decimal, and can read the assembly source from a disk file. Maybe I'll go digging for it and post it here, if everyone promises not to laugh at the (probably) horrible code... If you want to do anything with your Simple Assembler disk, the directions on how to use it (and the BASIC type-in code) are in Appendix C of ML for Beginners, here: http://atariarchives.org/mlb/appendix_c.php

As far as I know, you just stay alive long enough, and you'll come to the city.

What does the tape soundtrack sound like? I've always loved Blue Max, but never seen the cassette version. Any chance you could rip an mp3/flac/whatever of the soundtrack for us poor disk users to hear?

I don't suppose the disk works with the cart version of Flight Sim? Or that the cart version already includes a driver for this stick...? Charlie, how long is that BASIC test routine? Any chance you could post it here? Mostly I'm just curious (have had Atari 8-bit stuff since 1980, never even heard of the Microflyte joystick before). It might be cool to add support for it to the Atari800 emulator, and I'm wondering whether it might be basically the same thing as the Vectrex controller...

They might be cheaper... how many people who had Atari (or whatever classic) systems back in the day have gotten drawn back into the vintage gaming world due to emulation? I bet the potential market for the games would be much smaller if there were no emulators, which would keep the (sometimes) ridiculous ebay bidding wars from getting out of hand... On the other hand, people who are gamers rather than collectors would have to spend some real money instead of just grabbing ROM/disk/tape images to play the games. However, such people (myself included) would be just as happy with a box full of pirated/cracked floppies, which would be much cheaper than buying the real thing. Actually, if there were no emulation, but SIO2PC/MyIDE/etc still existed (ways to play downloaded games on real hardware), I guess people who just want to play the games still don't have to spend so much to get them... However, if emulation didn't exist, someone would invent it, so it's a moot point

What, the new one that's in development now? I volunteered to port it over, when it's ready, but they aren't interested... said they have no plans to ever create an A8 version. I never got any response to this post: http://www.atariage.com/forums/index.php?s...t&p=1477070 I dunno whether it'd help to bombard them with requests to do an A8 version... on the one hand, they might decide to do an A8 version if lots of people chime in with "I'll buy it". On the other hand, they've already said they aren't doing it, so it might just irritate them.

The PAL mixing doesn't occur for me anyway, I've only got NTSC Ataris and monitors. The flicker would be less annoying (30Hz instead of 25Hz), but I'm the type of person who can see a fluorescent tube flickering, when it's used for room lighting... Maybe I've misunderstood what CIN mode is... does it do alternate GR.11/15 scanlines on the same frame, or does it alternate frames of GR.15 and GR.11? Yeah, I've done some thinking about this, too... haven't thought of anything I like well enough to try to code it yet.

Ah, I meant interleaving frames, not scanlines... the GTIA mode bits would be turned off, for the mode 4 frames. Basically it'd show GR.11 on even frames and mode 4 on odd frames (what people like to call "interlaced", but I don't like to call it that because the A8 doesn't do true interlaced video).

I had a thought, reading another thread about "extended" graphics modes... There's a mode that alternates GR.11 and GR.15 every other frame, for 16 chromas * 4 lumas = 64 colors (I think this is known as CIN mode). How about extending that by alternating between GR.11 and Antic mode 4, with every 3 lines (120 characters) having a DLI to change character sets? This would be the same resolution as GR.15, but you get the possibility of an extra color (by setting bit 7 on the characters). Setting the color regs to whites/greys, you can have 5 possible luma values, but each 4x8 pixel cell only has 4 of them (the top 4 or the bottom 4, I suppose). This gives 16 chromas for the GR.11 frames and 5 lumas for the Antic 4, which would be 80 colors... but you lose the "any point, any color" nature of the CIN mode, and you eat extra CPU for the DLIs, and you use more RAM: Need 960 bytes of screen RAM and 8 full 1K character sets, except the last 8 characters of each wouldn't be used. Charsets have to fall on a 1K boundary, so you end up with 8 64-byte holes (the mode 4 display list and DLI code could live in a couple of them, the rest could be used for small tables/subroutines by whatever app is using this mode). The on-disk format wouldn't be as wasteful: could store 2 standard 62-sector images, plus 960 bits (120 bytes) to hold bit 7 of each character of the Antic 4 screen RAM. The rest of the bits don't need to be stored because each 3 lines of mode 4 would always have 0-119 in the bottom 7 bits, in order. Does anyone think this sounds worthwhile, or is it way too much effort for not enough gain?

Hm, so your effective resolution is 80x64 (assuming 192 scanlines)... on the plus side, no flicker/interleave, and you only use 8K of video RAM... I'd be interested to see what a photo of a person's face looks like, in this mode. Got anything you can post?

End the game early if someone hits $65535 and declare that player the winner? (No idea if that'd be easy to squeeze into the existing game logic)

Can you post images of these (the forum software requires you to zip them first and post the zip files, BTW), or do you have URLs where they can be downloaded?

Have you got any real Atari 8-bits? Get an SIO2PC cable... You can do virtual drive support in AtariSIO or use APE's PC Mirror mode to "mount" a directory on your PC and make it appear as a D: device. If you run MyDOS or (maybe) SpartaDOS, you can have up to 16 megs of files in the directory, with subdirectory support. To me, none of the emulators sound quite right anyway, if I were into AMS music I'd want to use the real thing to listen to them.

I don't know anything about AMS players, but I do know the monitor wants addresses in hex. Try "c 22f 0", that should blank the screen.

One minor gotcha regarding I/O with channel #16: if you plan to compile your program with the Turbo BASIC XL compiler, don't use this trick. It'll work in interpreted Turbo BASIC, and the compiler won't complain about it... but the runtime will stop the compiled program with an error message (in German, can't remember what it says) when it gets to the INPUT #16.