kenjennings

"hard" is relative. If the game includes graphics for a different computer, then "hard" could be hard. If not, then BASIC is BASIC (mostly). Strings are the biggest difference for Atari BASIC. Most other things are easier to adapt. If you can identify the platform used for the BASIC listing, then you should be able to google for a reference guide to explain how the commands work.

I asked and found out these 1200XLs are made to order. It seems Steve has stockpiled 1200s making it harder for the rest of us to find one. It's definitely worth the price just for the time and labor to install the fixes and extra bells and whistles. I ordered one and will probably make that my primary development system.

Is that the right number? The datasheet for 41256 says it is a 256K-bit chip. I'm pretty sure the 800XL didn't originally come with those. Is this a memory upgrade in the 800XL? The number following -10, -12, -15 refer to access time. 41256-10 100ns access time 200 ns cycle time 41256-12 120ns access time 220 ns cycle time 41256-15 150ns access time 260 ns cycle time 100ns is faster than 120ns is faster than 150ns, but offhand I don't know if faster in this regard is better for the Atari or not.

Lol. Who do you think codes those editors/utilities? Right, C64 demo coders. I didn't know "C64 Demo Coders" were one person. I watched the whole video. I lost track of the number of times the presenter stated such and such member of the team couldn't do a desired technique, because the editor wasn't done. The presenter made C64 demo coders sound like script kiddies. This was the second long development video I've watched from C64 demo coders. The first focused only on how they did their various techniques. That was very educational, especially discussion of how they can abuse the C64 timer functions to change code vectors. But, by avoiding any general discussion of the C64's inherent limitations they didn't have to go any farther to disclose their motivations for the hoops they had to jump through any more than the simple fact they had to make up for a sub 1Mhz CPU.

After watching the entire video I learned that the idea I've been toying with of adding a C64 to my collection is wasted time and money. (Probably will add a 1200XL to the "museum" now.) The Commodore machine came out several years after the Ataris, but the hardware features rate little better than the older generation BEFORE the Atari. If it weren't for the sprites the C64 would have barely usable graphics. I also learned that some C64 demo coders can't do anything unless someone else writes an editor/utility for them. We're pretty *bleeping* spoiled with huge palettes, graphics modes that can reference any memory line by line, character sets only limited by 1K boundaries, etc. We get so much stuff for free that the C64 coders have to hack a beam racing kernel to fake. And ilmenit's pictures look cool.

I was working on an entire toolkit library based on the second method, some fiftee-twent-umm a long time ago. I'm currently trying to find it in my old pile of floppies and salvage it into ATR files. It started, because I was miffed at various assembly toolkits that compiled the macros' code explicitly at every invocation. No attempt at using a reusable library of subroutines. Simple programs got bloated very quickly like this. What I did different is that the subroutine/function's part that copies parameter values from main code into the library's parameter working area was a subroutine itself, so every library function started with a JSR to get the parameters. Compared to explicitly loading values and pushing them on the stack and pulling them off, this method results in less memory/less redundant code (especially when there are a lot of routines doing this.) But this method means everything in the library has the overhead of copying the parameters and recalculating the correct address for the RTS.

Look at the game's subtitle on the box: "A sucker is born every minute". I guess the seller was testing that theory.

Holy cow, it's almost the original retail price. Some Ebay sellers think they're Christie's auction house selling the Crown Jewels of England. "Vintage" refers to old grape juice in bottles. "Rare" is how to order a steak. "Mint" is flavor in candy. None of the words above adequately describe a mass marketed computer that was once (for a short time) the most popular brand sold.

Ack! Gag! Erp! I saw the title I don't know how many times and thought it was $275. That was pushing reality quite a bit. Unbelievable.

Am I alone here in believing that it was never broken?

Do you just want to know how to read it? The touched position is read as two paddle controllers. First port is paddle(0), paddle(1). Or do you actually want to know how it is wired inside to accomplish this?

Yeah, Good thing he never read a Commodore advert billing the Atari as a five color machine, or the demo would have been a lot different. Speaking of which one year (in the 80s) I made a Christmas tree demo (for Christmas, no less) for a Atari user group contest that used players/missiles, character sets, and DLIs to put 50 differently colored lights on a tree. I didn't win anything. Even forgot what the winner had showed, so, it must have been a traumatic experience if I have no memory of it.

It's the drive's firmware which truncates the first three sectors to 128 bytes, and I guess it's up to the drive which data it writes to the second half (haven't checked this, in AtariDsk I just padded the remainder of the sector with $FF). This happens at the SIO level, so a XF551 / Happy / Speedy will only accept 128 bytes for the first 3 sectors - no chance to access the remaining 128 bytes. But as the whole disk is formatted with 256 byte sectors, you could upload some code to your Happy / Speedy to access the whole 256 bytes. I found source code for MyDOS and confirmed the way it behaves. It goes out of its way to insure read/write to the first three sectors is done with only 128 bytes.

Maybe you could get the LED inside the power button or fixed to the bottom of it, so it makes the power button light up. I'm electrically ignorant, what kind of resistor would one use?

Ohhhh, Yes. And put sio pinouts on the motherboard, so sio2sd can be installed internally. And add an interface for an external keyboard. To dreeeeam the impossible dreeeam.

Yep, it's one of those little idiosyncrasies you wouldn't know about unless you looked into the drive internals. Would anyone know WHY the original drive designers decided to invert all the bits on the disks? What does it accomplish?

The Kryoflux dump of a double density disk produced 256 byte sectors for the entire disk, including the first 3 boot sectors. However, the spec for the ATR format says the first 3 sectors are always 128 bytes. I see in the data from kryoflux that the first 128 bytes in the 3 sectors are duplicated in the second half of each sector (disk was originally written on an XF551 by MyDOS ) . Is the 128 byte limit in the first three sectors only enforced by DOS in software when writing the boot sectors in double density to insure boot compatibility with the OS? OR, is it the drive controller itself that is hardwired to do this with the first three sectors? If a floppy is formatted and DOS/bootloader is NOT written then can the entire 256 bytes of the first three sectors be read/written on Atari drives?

The colors are more saturated in the first picture.

On further review, having moved the kryoflux disk dumps to a linux box where I can get a good view of a hex dump, it appears all the bytes of the atari floppy have been XOR $FF. All those empty sectors that should be filled with $00 are filled with $FF. Weird. Not sure why that happened. I dissected the first bytes of a known bootable disk created with the APE Prosystem from an Atari drive, with one of these Kryoflux dumps (after un-XOR $FF) and the data matches, so I should be able to reassemble the disk dumps into a working ATR file.

I got kryoflux set up, and it appears I've been able to image my most important working 360K DSDD floppy (Mac/65 assembly, all my working code, etc.) using kryoflux and a generic PC 1.2M floppy drive. Oddly, neither Atari-specific format would work properly (FM or MFM). Errors on every track. Imaging it as a generic MFM disk worked fine with all the parameters specifically set for proper number of tracks and sector size. For reference (and so I don't lose it ) C:\Users\root\Desktop\kryoflux\kryoflux_2.0b9_windows\dtc>dtc -g2 -z1 -k2 -e78 -fmdml4_2.dsk -i4 The problem is it generates separate dumps for each surface, so now I have to find a way to fold them back together and turn it into an ATR file. I think I smell C code in the air. 04/10/2012 10:04 PM 184,320 mdml4_2_s0.dsk // 720 sectors * 256 04/10/2012 10:04 PM 184,320 mdml4_2_s1.dsk

Has anyone else been able to download these or find them on another site? I've tried several and can't download them. So far this is the only place I found that appears to have the 1982 issues containing the rest of The Atari Tutorials.

Google is your friend... It seems to be quite similar to the Catweasel. Sounds very interesting. What a coincidence. My kryoflux arrived yesterday. If I have time this weekend I'll try setting it up. It's part of my effort to recover my working disks. Many were unfortunately done in 360K DSDD on an XF551 and that drive now refuses to read double density from the second side (double sided, single density still works, go figure). I have some generic 360K and 1.2M PC drives and will try to recover the DSDD disks using kryoflux. It supports FM XFD, Atari 8-bit, MFM sector image, 40/80+ tracks, SS/DS, DD/HD MFM XFD, Atari 8-bit so somewhere in there I think it should read the XF551 DSDD disks. The printed docs with the kryoflux show example commands that create IPF images at the same time as specific kind of sector dump. So I figure one of the options will make it write an XFD format, and then I would use a utility (XFD2ATR) to convert XFD to ATR. Catweasel, I think, may be dead.

I vote for the first picture. White text with a black border is more legible even on the small thumbnails.

As something built by one person it's a nice homebrew effort and I think the builder has every right to be proud of it. But, as far as being Atari-like? The limited graphics options and pallette makes it more like an NES or C64 than an Atari. It's going to be tough on games -- no controller ports. I just heard the sound in the pacman game and want to cry. It does reinforce the idea that the Atari designers over 30 years ago were downright brilliant in a nearly magical way.

As long as the custom hardware is still functioning and the system is essentially backwards compatible with software for an Atari 800, then it is an Atari. Remove the custom hardware and all you've got is a CPU and memory. (Ok, that can provide some limited entertainment) So, any enhancement that doesn't remove the the desireable functionality is fine by me. (Multi-OS switcher? Ok. VBXE enhancing native graphics. Ok. Two Pokeys? Ok -- One Pokey is Atari, so two must be twice as good. 65816? It runs 6502 code, so it's OK.) The peripherals (especially the #$^&%*@$#!! floppy drives) are not essential for the Atari to be an Atari. Sio2sd/Ape/Aspect are wonderful things that save us from inconvenient peripherals and really make the Atari fun to use.