Urchlay

So I swapped the 4050 from the dead 800XL, but it didn't change anything. The socket looks OK (though my vision isn't what it used to be). I hesitate to spray contact cleaner into the socket, because the normal way to clean e.g. an audio jack would be to spray, then plug/unplug a cable several times to spread it around & make it do its thing... I don't really want to repeatedly plug/unplug the IC, the sockets Atari used only have a few insert/remove cycles before they die. Plus I'd likely bend a pin... Time to break out the ohmmeter and start tracing I guess. Also going to find a magnifying glass (had one, it's gone AWOL). The old c.s.a8 post linked to says the chroma mod is done by connecting the chroma pin on the jack to the resistor just above Q5. Wonder if that's where the chroma pin's already going in this 800XL (somehow I doubt it).

I hadn't yet when I posted that... but I just found the 1200XL powersupply and connected it. On the same 1702, with the same video cable, using chroma/luma inputs, the colors are correct. So the monitor's fine (as I thought). Note: I can't test composite on the 1200XL, I did the 'composite lift' when I did the supervideo mod, was going to install a switch but never got around to it... Aside: it's too bad there's not room for the 1200XL and the 1702 on my desk. By modern standards, both are big beautiful beasts. And the supervideo's output is gorgeous. I haven't yet traced the chroma pin to see where it goes on the mobo. Would a bad 4050 not also cause the composite output to be bad? Or it's a "hex buffer", could just one of the 6 buffers be dying? I might have a spare 4050 in my old box o' parts, will give that a shot. If nothing else I've got another non-booting 800XL I could steal it from (but who knows if any of the parts from that 800XL are any good?)

Not posted here in ages, been lurking a bit lately. TL;DR version: my 800XL's chroma output is connected (stock, not a mod), but the colors are very faint and completely different from what the composite output displays. The full story: About 10 years ago, I got this 800XL... it's AFAIK completely stock. All I did to it was clean the keyboard (someone had spilled what looked like orange juice in there & let it dry), and replace the RAM (worked when I got it, one of the MT DRAMs died while it was in storage, replaced them all with, eh, I dunno who makes these chips but the part number starts with KM). Using a Commodore 1702 monitor for it, which looks great. I had to clean the color adjustment pot, which works now although it's missing the plastic ring/knob that sits on top. The RF shield is missing, and so are the screws that hold the case together. Probably those are in a box in the garage somewhere... The power supply I'm using is from a Netgear router, modern switching supply rated at 5V/2A, and it seems rock-solid. All I did was salvage the 7-pin DIN connector from an Atari "ingot" and solder it to the new power supply. The next day I found in the closet an Atari "beauty queen" power supply, which works, but I'm a bit paranoid about using a ~30 year old power supply. Originally I had color stability issues, which I thought might be due to the power supply, but I fixed it by spraying out the color pot and the monitor jack with deoxit (or actually the generic 'electronics cleaner' spray from Wal-Mart, which I've used for guitars/amps/PA stuff for years without problems). The color is now stable, but read on... This 800XL has a black sticker on bottom, "Made in Hong Kong", and has Revision C BASIC (mask ROM, not EPROM). It also has the chroma pin connected (looks like it came that way from the factory, not a mod). Composite video works great, and looks as good as composite ever does on an 800XL + C1702. "Fake" S-video, with the Atari's composite output plugged into the monitor's Chroma input, works great and looks nicer than composite. There's still some artifacting in this mode, but I'm OK with that. Real S-video, with the Atari's chroma/luma connected to the 1702's chroma/luma, works... sort-of. The picture is beautiful, crystal clear, but the color is very weak (looks black & white unless I crank the monitor's saturation all the way up) and has wrong colors (green becomes orange, for one thing). I don't think the monitor's at fault here, though I do plan to dig up another monitor with chroma/luma inputs and see if it does the same thing. My questions: - Is this a known issue with late-model 800XLs, possibly with a known fix? - Shouldn't the color on composite and chroma outputs be the same, at least as far as the hue? To save time/effort: Please, nobody respond with "You should get a UAV or VBXE". This 800XL, I'm keeping as stock as possible. I just want to use it with the 1702's chroma/luma, if it can be made to work. Don't want to do ClearPic or SuperVideo mods either (not needed, I have a 1200XL with SV if I want that).

I've finally dusted off my old Ataris and started messing with my old code again... The FujiChat sources are in a git repo, and they live here now: http://urchlay.naptime.net/repos/fujichat/ There's also an ATR image in there, for anyone who can't or doesn't want to compile anything. Anyone who wants to, can clone the git repo and host it somewhere. I personally don't trust the services like github or gitlab, so it's hosted on my own server for now.

Nah, the addresses for 5200 are different, and there aren't so many of them. You might check the atari5200.inc that ships with cc65. Here's a copy: https://raw.githubusercontent.com/cc65/cc65/master/asminc/atari5200.inc It .includes a few other files, which can be found in the same directory. Edit the URL, or check out the source from git, or install cc65 on your system... vcs.h is 10K now? 10-12 years ago it was around 2K... nothing's immune from software bloat it seems.

Wow, old post... long time since I've been on Atariage. The -f3 example produces a valid Atari executable, no need to transform it. I originally was going to submit the equates.inc file to the dasm maintainer, but that never happened... there's a copy here: http://urchlay.naptime.net/~urchlay/src/equates.inc I've since pretty much completely switched to using ca65 (from the cc65 suite) instead of dasm, but that equates.inc file works for ca65 also.

Here's what looks like a copy of the original Apple source: http://www.6502.org/source/interpreters/sweet16.htm The main things that'd need to be done to it to make it work on Atari would be the usual syntax conversion for whatever assembler you're wanting to use, and using a different chunk of zero page for the sweet16's "registers" (probably the floating point area from $D0 to $FF would be fine).

I never had the patience... as I recall, at least one of the example programs on the cc65 disk I had, would grind away for an hour or so, then bail out with a compile error. Back then, I wasn't so good at C, probably was something dumb (typo or such), but it really turned me off to the idea of using cc65 on the Atari. Eh, if I read that right, you're going to knight me for converting your sources?! Done Seriously, about a 2-minute job with good old bash and sed, result here: flashjazzcat_old_cc65_iolib.zip Some of the files will compile OK with modern cc65 after conversion, most won't. You'll want to remove line 5 (#define __CC65__) from your stdio.h, as cc65 already defines this. You use 'cc65 --forget-inc-paths -I.' to stop cc65 from including its own stdio.h... also the embedded assembly syntax has changed (used in time.c). Wonder how much of a pain it'd be to integrate your sparta-specific stuff into the modern cc65 stdio library. Far as I know, cc65 lacks any of the directory-related stuff (mkdir(), getcwd(), chdir()), but there's no reason to reimplement fopen(), fputs(), etc: the ones in cc65 already work just fine (with or without sparta).

I used it to port uIP to the A8 and write the FujiChat IRC client that uses it... although I'm currently in the process of (slowly) rewriting it in straight assembly, since the compiled C code + cc65 standard library takes up so much memory that I'm unable to add much more in the way of features. Right now the client (including uIP) plus DOS leaves about 9K of free RAM, which is just about enough to load a software (GR.8 based) 80-column driver. I'd really like to get another 8K or so free, for use as a scrollback buffer (I could use XE extended RAM banks, or the RAM under the OS, but the former means it'd only work on one of the 5 A8s I own, and the latter would mean it'd be incompatible with SpartaDOS, which I don't use but some of my users do). I've also used cc65 to write a floating point library (wrappers around the OS built-in floating point routines, really), which was a lot of fun to do, but ultimately not very useful: C programs that use the OS FP math routines run roughly zero to 30% faster than the same code rewritten in Atari BASIC, depending on how math-intensive they are (which is to say, sometimes *slower* than compiled Turbo BASIC). I learned a lot about the OS and about cc65 working on this project, though. One of these days, I probably will try to patch cc65 to support the float and double types the normal way a C compiler should, though I doubt such a patch would ever be accepted by the cc65 team: it's been debated to death on the cc65 mailing list, and the consensus seems to be that any FP support would have to be implemented portably, from scratch, instead of relying on the ROMs of the various target machines (some of which lack FP support entirely, and most of which use completely different FP representations...) For the tiny bit of game development I do, I tend to stick with pure 6502 assembly. To me, the overhead of C isn't worth it... not that I'm much of a games programmer (nothing worth releasing, or even talking about, just tinkering with ideas). I've considered using cc65 to port Frotz (Z-code/Infocom interpreter for UNIX) to the A8, so we could play later Infocom titles that were never released for the A8, but haven't looked into what it'd really take to do it (I suspect Frotz expects to have enough RAM that it can load the entire game up-front...)

My original NTSC Defender cart (2nd game I ever owned, bought retail) definitely has 10 humanoids. The only 8-humanoid versions I've seen have been file versions, starting with one I got from a BBS when I lost the cart (found it again thankfully).

I'd be curious to know what happens if you do this: 1. Turn on first 850 (with a printer plugged into it) 2. Turn on Atari computer 3. Wait for the long beeeeep that tells you the 850 driver's loaded 4. Turn on 2nd 850 (with another printer plugged into it) 5. Try to print something Does the SIO protocol say that all frames have to be ACKed, even for an output-only device like a printer? It's been so long since I had a printer hooked up to an A8 that I honestly can't remember squat about how it works at the SIO level (if I ever knew).

AtariSIO's verbose logging is pretty detailed. Can't remember whether it logs its own commands when sending them, but, eh, it's open source, could make it do so if it doesn't.

IIRC, Vanguard was never actually released for the 8-bit, and the 8-bit version is a conversion from the 5200.

Here it is. Not tested on real hardware, works on atari800 emulator. super_pacman_final.xex

Agree 100%. If you consider BSD-style licenses to be "free and open source", there's Thor's OS++ (http://www.xl-project.com/, scroll about halfway down the page). This is a replacement for the Atari ROM OS and includes (tiny!) FMS and DUP replacements... though as far as I know, Thor's FMS doesn't support things like hard disks, drives with 512-byte sectors, or the SpartaDOS filesystem (but it's open source, you could always code up whatever features you want).

Aspeqt + Qt 4.5.1 works fine on Linux, if that's any help to anyone doing a Haiku port...

BASIC doesn't have any deliberate self-destruct code... However, on OSB and at least some versions of the XL OS (maybe all versions?), scrolling (or was it clearing?) the GR.0 screen clears an extra 64 bytes above RAMTOP, which is normally $9FFF... this wipes out $A000 through $A03F, which is a Bad Thing. Symptom: the NEW command quits working. If you're going to run a RAM-based BASIC, you want to prepend an init routine to the binary that does the machine language equivalent of 'POKE 106,152:GR.0' (which tells BASIC and the OS that memory ends at $9800, 1K lower than what's normal for a 48K machine with BASIC)... unfortunately this will cause some programs to misbehave.

[edited - this is a duplicate post. Moderators, please remove this post]

I don't actually use this regularly, but here's an xterm window (from my Linux box) running irssi with an A8 font and color scheme: The ~ character, I drew myself...

When you connect an SX212 to an ST, you use the standard RS232 port... Far as I can remember, the ST supports the RS232 port with no additional driver. As far as supporting the modem itself, that's up to the software that wants to use it. The SX212 is a Hayes-compatible modem, using the AT command set, so most software should work with it using the default init and dialing strings (ATZ, ATDT).

Also, mount a bootable DOS disk as D1:, if your disk full of BASIC programs doesn't include DOS.SYS.

The Stelladaptor, when you plug in paddles, just appears as an analog joystick controller with one button and one axis. I've used it in xmame and the Linux port of z26 with no patching, it Just Works (and that's in Linux... Windows is supposed to be easier, it should Just Work there, too). It also works fine with a joystick plugged in, without patching the emulators/apps (shows up as a 1-button, 2-axis controller). The quote about software patches might have been referring to the one special thing the Stelladaptor does for joysticks: on a real Atari stick, it's possible to push all 4 directions at once by pushing the stick straight down (towards the ground). The Stelladaptor handles this by sending something like "halfway to the right, halfway down" (remember, PC joystick axes are analog, even if the actual controller isn't), which an emulator would need to be able to detect if it's going to emulate all 4 directions being pressed (otherwise, it'll act like either right+down, or nothing, depending on where the emulator's threshold is set to). Also, I haven't tried driving controllers with the Stelladaptor. It might be that software needs patching to work with those...?

Get an extra PC, install Linux or FreeBSD... If you can't get an extra PC, and you're on Windows, get something like VirtualBox or QEMU, install Linux/BSD in a virtual machine. I believe you can even skip the installation process, and download a ready-to-use disk image of an installed Linux system for QEMU. There's also Parallels for the Mac, but if you're on a modern Mac, you should already have a "shell account" including a usable compiler. If you really only care about being able to run a compiler, you might try Cygwin or MSYS (gives you a UNIX-like environment on Windows, including gcc, GNU make, all the goodies). You might try a provider like these guys: http://shellium.org/ ...I've never used their service, but their home page says "Free shells to all", maybe they really mean it. With all these options available to you, a lot of us who might be able to provide you a shell account, won't (because we don't know you, and don't want to go giving random people access to our machines, and because you're perfectly able to compile your code on your own machine if you do a little research).

For even more fun, look at some ancient KIM or SYM assembly... some of that stuff requires an asterisk to indicate zero page mode (e.g. "LDA *$00" is zero page, "LDA $00" would get assembled as a 3-byte absolute instruction). Really ancient KIM assembly uses LDAZ and STAZ for zero page, LDAI for immediate... Maybe the One True Assembler shouldn't try to automagically support everything... maybe it just needs to be configurable (insane amount of command-line switches, plus a GUI front-end that shows checkboxes). Let's see... Labels can be case-sensitive or not, can optionally be followed by a colon when they're being defined, can contain various weird characters (Atari used to use an assembler that allowed question marks, BOOT? was valid)... ROL/ROR/LSR/ASL accumulator mode can be "ROL A" or just "ROL"... and I suppose in assemblers that don't require the A, someone might use A as a label. The old Compute! "Simple Assembler" didn't allow commas in indexed modes: "LDA 80X" instead of "LDA $80,X"... come to that, it only allowed hex, so the $ wasn't required (or allowed). .BYTE vs. BYTE (also byte, lowercase, and some people like to write stuff like Byte). DASM allows a dot in an expression to mean "current address" (same as asterisk in most other assemblers, lot of 2600 code was written using dot though). Also uses square brackets for grouping: [1+2]*3 Completely incompatible macro systems. Different keywords used to start/end a macro, different capabilities: some are variadic (take variable number of arguments, defaulting missing args to zero), some allow overloading (multiple macros with same name, but different number of arguments), some do neither. Some automatically make labels used inside macros local, some make you start local labels with a dot or something, some don't support local labels at all... Different syntax used for accessing arguments ($1, %1, {1}, but are they 0-based or 1-based, and if 1-based, does the 0th argument indicate the number of args?) I've seen both \ and % used for the modulus operator. As mentioned, single vs. double quotes. Also, do you use "LDA #'A" or "LDA #'A'" to load the ASCII value of the letter A? I've seen one assembler that uses each syntax, plus one that allows either. ATASM supports an "SBYTE" operator, very Atari-specific: it takes a string and assembles it into Atari screen codes instead of ASCII. No easy way to mimic this one on other assemblers, most (all?) macro assemblers don't let you pick apart a string argument and do stuff to the individual characters. *= vs. ORG Also, using either *= or ORG, does the assembler emit an Atari binary load header? MAC/65 and ATASM do, DASM doesn't, not sure about ASM/ED cartridge. CA65 doesn't, but what it does spit out is a funky object file that needs to be linked with LD65 (which will add the binary load header, but IIRC only one of them per file). A vast and bewildering array of pseudo-ops, including .OPT, which does completely different things in different assemblers... Depends on how you define the problem. If the problem is just "I need to be able to assemble this code written for Assembler X, but I only have Assembler Y", scripts can handle most of it (though the scripts haven't all been written yet), plus a bit of manual editing/cleanup. If the problem is "I need to be able to use the same assembler to assemble all code I get from anywhere", that's obviously the harder task (but if you manage to get it working, it'll be impressive). If the problem is "I need a utility that can convert from any 6502 asm syntax to any other", that'd probably be the hardest (actually impossible to make it work 100% of the time: different assemblers have different feature sets).

A while back I wrote a messy perl script to convert dasm source code to something atasm, mac65, and/or ca65 can use. Script and man page included in zip file: dasm2atasm.zip It's not really a shining example of great coding style, and it's not 100% perfect, but it does mostly work... I never did get around to converting the other way around (to dasm), and I've never looked at mads at all other than to notice its syntax is pretty weird-looking for someone who learned on mac65 and switched to dasm.