Fox-1 / mnx

Tried with "smart" and "less". Lines keeps showing up. Just at other locations.

I expected dithering to kick in a bit on the background too but it didn't so at hind sight it was better if I made the background a solid blue, which I didn't. Posting anyways. Input png 640*430 - rc Fox-1_SugarHill.png /h=215 /pal=g2f /brightness=-5 /contrast=2 /init=smart /threads=11 /dither=line2 Altirra screenshot Fox-1_SugarHill.xex

Far side left is part of the issue too but I only mentioned the two most visible positions. The "ZOO" letters... yes, they aren't very thick but the introduced disturbing line appeared just above that problematic area. I guess I'll have to live with it. It's not like I can improve the code myself to let it do a better job... by far...

It may be an edge case. I really have no idea. Restarting the conversion, with or without switching dither pattern, won't solve it. Sooner or later the lines creep in again but not necessarily at the same scan line(s). Any position with a lot of changing colors per scan line is a potential candidate.

All true, but the regular end user won't use it commercially so it's of no concern for the vast majority. And yes, it's design is a bit odd. Configuring the thing is, let's say, not the way I would've chosen when making such a tool. The fact to extend the supported formats by using plug-ins is a positive thing for me. As far as talking Atari 8-bit, converting other multi colored formats (bmp, png, pcx, whatever) to the platform ain't that easy. If you want to keep the coloring, there are a many different ways to display them on Atari platform. Unless you convert those to only 4 colors or grey scale, this may be a hell of a job. Nevertheless, it'd be something I'd like, even it was just 4 colors. There are several tools around to convert multi color "PC" pics to Atari multi color ones but all of those, of course, require complicated DLI's and/or interlacing to display them. There aren't many solutions for those who want to convert to old plain low-color formats.

Translated it to MAC/65 format and it assembles without problems. Are commented versions of the older ROM around? If so, it's equates could be included to see what comes out. 810ROM_B.ASM

The program may be nice (didn't try it yet) but it seems to be very similar to IrfanView with the plug-ins. Converting TO old-computer formats in stead of FROM would gave it a unique feature as there's no such multi-format tool around.

I wonder why every comic-like pic I try ends up with strange horizontal lines in the .EXE that aren't visible in the .PNG Altirra screenshot - Output PNG - At a certain point in time lines appear out of thin air (mid-left: blue line thru "ZOO" letters and mid-right: white line on stairs) that won't go away. Only common factor with earlier attempts is the typical black lining in the drawing. rc Fox-1_DirkjanIssue5.png /h=240 /pal=laoo /dither=knoll /dither_val=1.2 /dither_rand=0.8 /brightness=8 /contrast=-5 /init=smart /threads=11 Fox-1_DirkjanIssue5.xex b.t.w: It's a part from the cover of a Dutch comic featuring the anti-hero "Dirkjan", a character by Mark Retera. Totally unknown outside the Netherlands and Belgium I guess :-)

Hmm. I have one that doesn't spin and never get's going. Not that this is of any help...

Really, the fundamentals are easy. Anyone who can PEEK and POKE in BASIC can code something in assembly. Just a matter of knowing the syntax of your assembler and a bit of reading about opcodes but this in no different with BASIC where you also walk the way from A to B to C to D to reach your goal. The difference is that the way in assembler doesn't stop at D but at Z in stead. And beyond for some. (and waaaay beyond for a few) It's gets tricky once you're going into VBI's, DLI's and "beam racing". You need to develop quite some know-how about O.S. vectors, hardware registers, etc...

Like this? CUSTOM.XEX :-)

The short answer is "no". Cassettes are cassettes, cartridges are cartridges, but... there are a lot of "if's". Too many to answer, but that's why the sticky topic http://atariage.com/forums/topic/176545-topic-for-newbies/#entry2199612 was created.

Step 1: Burn the 16KB O.S. in a 16KB EPROM and exchange it with original ROM. Step 2: There's none That's all it takes and probably the reason why there's no how-to guide. People who can, and know, how to burn an EPROM know what to do but in case they don't, feel free to ask.

The source of this one was a highly compressed 640x480 jpeg picture someone took at the parking lot of UnConventional 2001 Party in Lengenfeld, Germany. Because of the extensive artifacts I didn't expect much of it but it came out not as bad as I thought it would (but not that good either). .png Input - .png Output - rc Fox-1_MazdaVanUnCon2K1.png /h=180 /pal=real /dither=knoll /dither_rand=0.6 /brightness=4 /contrast=6 /init=smart /threads=11 About 4000000000 Evals Fox-1_MazdaVanUnCon2K1.xex

You really should repair it. The 800XL's with those special keyboards are really rare.

SCART is mainly just a replacement for a collection of regular audio/video signals. It has pins for Audio and Video-In/-Out, RGB, and so on. The video signal is exactly the same one as used with the typical yellow RCA connectors. Audio is just like a regular amplifier. Red RCA for right, a white one for left. http://mixinc.net/atari/pinouts/scart.htm Problem is that many manufactures don't implement all signals. My modern TV screen has a SCART but only Video-In, Audio-In and Audio-Out are wired. No RGB, no S-video and the quality sucks.

Input Connector: SCART female x 1 for CVBS/y/c (PAL, NTSC), RGB (480i, 576i) S-video PAL (576i) NTSC (480i) HDMI female x 1 Input Video System Support: PAL B/G/D/K/H/I NTSC_M, NTSC4.43 SECAM CVBS/y/c does it for me, which is part of a full blown SCART connection.

What I tried to say is, users of classic systems using various modern HDMI monitors. Those are the typical persons that use these things. And, yes, if the output signal doesn't match with what a monitor can handle it simply won't work, but that's why the O.S.S.C. has settings to tweak the output. This also has it's limitations, because no frame buffer, but the open source nature helps a lot and updated firmware may solve issues. Still no guarantee but unfortunately there's only one way to find out if it works for ones system.

Too late for an edit... The SDV500 seems to be able to do it all, accepting both Vid/S-vid and RGB as well to convert to HDMI. It's not overly expensive but no idea about the lag. There isn't much "neutral" info around for this one like a review or something. http://www.ambery.com/hdscrgtohdsc.html

Tried Rasta with a few simple comic pics but it really isn't suited for those. Too much solid colors I guess. After about 5000000 evals banding creeps in to never go away, no matter the settings or how long it's left to run. Anyways, a first, more or less, serious attempt, just for fun. Fox-1_IntelOutside1997.xex - rc Fox-1_intelOutside1997.png /h=191 /pal=g2f /dither=chess /dither_val=1.75 /dither_rand=0.6 /contrast=18 /init=smart /threads=11 Cropped source:

The O.S.S.C. uses several different ways/algorithms to produce a usable signal and only buffers a single scan line. The later versions also have settings to slightly change timing parameters for picky HDMI inputs. The list of classic systems it's been used with without problems is a long one so it can't be that bad. This, of course, isn't a guarantee that it'll work with ones particular set-up. The long list is of no use if your system is not part of it. I won't use anything that adds lag. I'd rather go for less quality with plain video, or even RF out.

ID3V2 Is way overkill. The fixed and padded 128 bytes length of ID3V1 makes it much more suitable for smaller systems and is (should be) backwards compatible.

A quick overview of a few DOS'. (not necessarily DOS 2.x format compatible). Dos 1.0: As Dos 2.x (1st char. NOT a number, "_" and "@" NOT allowed at all) BiBoDos 6.4: 1-0, A-Z (1st char. may be a number, "_" and "@" NOT allowed at all) DOS 3: 1-0, A-Z (1st char. may be a number, "_" and "@" NOT allowed at all) DOS 4.0: 1-0, A-Z (1st char. may NOT be a number, "_" and "@" NOT allowed at all) DOS XE: 1-0, A-Z (1st char. may be a number, "_" and "@" ALLOWED anywhere) DOS XL 2.30: 1-0, A-Z (1st char. NOT a number, "_" and "@" NOT allowed at all) DOS XLE: 1-0, A-Z (1st char. may be a number, "_" and "@" NOT allowed at all) HappyDOS / DOS II+D v4.5M: 1-0, A-Z (1st char. may be a number, "_" and "@" NOT allowed at all) K-DOS: 1-0, A-Z (1st char. may be a number, "_" and "@" NOT allowed at all) MachDOS 3.7a: 1-0, A-Z (1st char. NOT a number, "_" and "@" NOT allowed at all) SuperDOS 5.1: 1-0, A-Z (1st char. may be a number, "_" and "@" ALLOWED anywhere) TopDOS 1.5a: 1-0, A-Z (1st char. may be a number, 1st char may NOT be "@". "$", "#", "&", "_" and "@" ALLOWED) TurboDOS 2.1EX: 1-0, A-Z (1st char. may be a number, "_" and "@" NOT allowed at all) XDOS 2.4: 1-0, A-Z (1st char. may be a number, "_" ALLOWED anywhere. "@" NOT allowed) Note: Not all DOS' return an error at attempts to use "_" or "@". Some will just ignore that one character and skip it in the new file name. In some cases this will lead to problematic double file names or blank file names.

Maybe, just maybe, you can remove a part of the shielding from the RF box (not the main shield). Or, another maybe, AMenard was referring to that.

Atari must have produced an awful lot of XEP80's. About 10 years ago those things seem to come out of the walls as they popped up everywhere in Europe. A big Atari club, literally, gave them away, all NIB. Too bad there isn't much supporting software for it. It may be a bit slow but it's a nice device nevertheless. On an 800 you can even connect up to four of those and I think that a simple wire-swap enables the use of 4 of those per port. Nice, in theory, but no idea what to do with 17 displays.