Rybags

Amiga-type sound would be the perfect companion to the graphics upgrade. Hacking in Amiga hardware would probably be to complex and expensive, but really, to simulate Amiga sound is just a case of 4x 8 bit D/A convertors and a DMA interface.

I think they were mostly educational/language/learning programs which used that feature. Other computers? I doubt it, since the Atari 8-bit is the only machine I can think of which has audio-in from the cassette interface and mixes the tape audio into it's own. Many other computers of the era just used normal cassette players with an earphone socket, which on most players will mute the speaker.

Does anyone here use a PC power supply for their Atari? I'm thinking of doing so (just for the computer). Either an old AT style (have a few spares, and might put it inside some type of enclosure. Or, a nice little slimline ATX one (although it's only a 100 Watter, but should be heaps for a 130XE). Also, can the 1050 be modded to run on one too, or does the drive mech use some non-standard setup?

The values you put in AUDCn for timers don't affect the timers, so just store 00 there. Just out of interest, how many samples does this routine do per second?

That protection scheme has been a known "problem" for some time now. That article didn't mention the fact that Starforce can actually cause some newer DVD burners to have permanent hardware failure... since many drives are not supposed to operate at lower speed. Another link: http://www.glop.org/starforce/

I also tried forced volume output to create triangle and sawtooth waveforms. Levels 0 through 7 have fairly consistent steps but 8 thru 15 are slightly smaller. Note: to get a truer representation of the waveform (graphically), use the Invert option in Audacity once you've taken a sample.

It should be easy to check music "tune" with Audacity alone, assuming RMT is being used. Since it allows turning off voices in the editor, you can capture just 1 voice, or a filtered note at a time. Then zoom into the captured wave and check the delays between the peaks. I only have the SB Vibra, but it still allows sampling at 48000 Hz, which is sufficient for just about any music. Another interesting thing is the decay in the square waves, like some people have mentioned before - there is a noticable difference between real and emulated POKEY sound.

There are software oscilliscopes you can download which use Line-In on the PC's sound card. Been meaning to try one of them myself. Or, just use almost any .WAV file editor. http://audacity.sourceforge.net/ - Audacity is very good - free, plus you can zoom in on the captured waveform.

Strange that at least a few other keys don't work. You would assume that at least some other keys on the same row or column of the matrix would also funtion. Could indicate a mechanical problem, or maybe the thing is just really dirty? The console keys (start, reset etc) are seperate from the rest of the others (ie not matrixed and going to GTIA, not POKEY, so will usually be fine when the keyboard plays up. Keyboard matrix here: http://www.mixinc.net/atari/pinouts/keyxl.htm See if any of the keys on the same rows/column as <space> still work.

OK. I tried writing individual sectors, groups of sectors and entire tracks, after stepping in or out by half. It's a hit/miss affair at times, sometimes the drive will seek back to 0 and retrack before writing them, other times it will happily write them straight away. ijor was right about the differences in the steps, there is a definite visible and audible difference in the stepping of the head when going by "half" - it seems to be a pattern of one small followed by a larger step, and going back follows the same. As for "bad" sectors, at best I think I was able to make "weak" sectors, which made the drive either read a little slower, or at worst, reseek track 0 then go back to where it was and read the sector again successfully. Normal status was returned by SIO, but a "copy protection" scheme could possibly use timing to detect the anomoly. I modified my program a little further - this time adding the option for "bad" track writes. Note that it's still fairly simplistic and assumes "tracks" as per 810 Single Density, ie 18 sectors / track. All it does is read in the sectors, then write them back after optionally half-stepping. The stepping options available are In (-ve), Out (+ve) and none. hidden4.zip

There was some software (although few titles) that utilized the 128's faster CPU in C-64 mode. From memory, there were 2 extra registers on the VIC-II chip, and you could double the CPU speed during the 112 scanlines that the screen wasn't being drawn which resulted in about a 25% speed boost. I've only ever used a real Apple II once and actually downloaded an emulator and a ton of games. Not impressed is an understatement. I think that Apples huge dominance in schools, plus the fact that they had some "killer apps" in the business software scene was the main reason for their greater success. That, and the fact that unlike Atari - they develop a computer system then proactively promote and support it and it's users.

I might try the bad sector creation later. In any case, it's fairly pointless and redundant, and only the really old software used "bad" sectors. More sophisticated software used sectors with CRC errors (data still good though), or duplicate sectors, both of which are impossible to recreate on a standard 1050. As for the stepping not being exactly half track, I did notice that some steps seemed a little smaller than others (I had my drive opened up when playing around with the software yesterday).

Got it. 1050 source here http://ftp.pigwa.net/stuff/collections/ata...0Source%20Code/ Command $23 has subcommands as follows: 02 test step rate on all tracks 03 half-step, as I already found out before 04 diagnostic (involves format, write and readback tests) 05 seek to track (illegal tracks will not work) Command $24 is for testing rotation speed, subcommands: 00,01 send time of 1 revolution 00,01 send RPM of drive It would appear that out of the extra commands for a 1050, the half-step is probably the only one of use for accessing the area outside the normal Track 0-39 bounds. It was fun to play around and learn something new. But with the fact that other drives (810 as well?) probably don't use these commands, plus the fact that most of us are running APE and have gigs of free space on emu'd drives kinda makes the whole thing useless in a practical sense. If anything, the speed sense command ($24) is probably more useful to most people. As for generating "bad" sectors, I guess that half-stepping might work. I've put my 1050 away for now, but with the program I uploaded it would be easy for someone else to play around with it. I think that if writing to a half-track did work, it would be a fair chance that the entire adjacent track would become useless, since one or two sectors (of which we couldn't be sure which ones) might be overwritten or "weakened".

I say open it up. In any case, you wouldn't want to hook it up not knowing what it is supposed to be. Either a XFormer or APE cable I'd say. But if it's an APE cable, you'd need a gender changer plug to plug into the PC. Might have just been built that way because the owner didn't want to cannabilize a SIO cable (I built my first one in a similar fashion).

Of course it does, nobody said it doesn’t. But the stepper motor in the 1050 is not connected at all to the FDC. So you can issue step or seek commands and the head won't move. Why you don’t look at the 1050 schematics? Is the “STEP” pin of the FDC connected at all? No, it is not. The ST is completely different. It uses standard industry drives which have a minicontroller integrated. The FDC in that case send the step pulses, and the minicontroller in the drive actually handles the stepper. Fair enough. Anyway, we've proven the initial "hidden sector" theory true anyway. It would be nice to have some source code for the 1050, or a ROM dump. I have a file here, but it's probably for a Happy drive.

hidden2.zip Slightly enhanced version. It does a seek of sector 200 before read and format operations, which should make it unnecessary to power down the drive to get it to recognise the proper position of track 0. The program does r/w to sectors 1 and 2. The USR routine is of the following format. All parameters are required: <var> = USR (1536, [status buffer],[aux1&2],[# ops],[data buffer],[command],[device],[dstat],[dbyte],[buffer length],[dunuse],[retries] ) [status buffer] - an area where the status returned from SIO is put (1 byte per operation) - just point it at 45000 so it's harmlessly written over the BASIC ROM [aux1&2] = AUX1 and AUX2 (*256) of the SIOCB. The program will increment these if multiple operations are performed [#ops] - number of operations to perform. AUX1/2m and the SIO buffer address will be incremented accordingly for each operation [data buffer] - your data buffer to send or receive into [command] - the SIO command to issue [device] - the device ID [dstat] - DSTAT flag. $40 for a read operation or $80 for a write operation [buffer length] - length of buffer for each operation (usually 128). The buffer pointer is incremented by this amount for each operation [dunuse] - SIO DUNUSE flag (not sure if it's needed, but has to be supplied) [retries] - number of times the program will retry if a SIO call fails)

The controller does recognize step commands (look at the datasheet). I've written programs on the ST which did all sorts of stuff, although it has a different controller. It's just that, like the Commodore 1541, the Atari 1050 drive is capable of half-track stepping.

HIDDEN.zip Here's a BASIC program which will create a hidden track, and leave a message on Sector 1. It's SAVEd, so LOAD it, with DOS loaded in Atari BASIC, since it uses the XIO command to get DOS to do the formatting. It can also display the real and "hidden" sector 1. It's a bit of a rush-job, but works. I used an SIO interface routine that I wrote decades ago. It prompts you to power off/on the drive at times, but it should work without powering off. It does a sector read (of sector 200) to get the head off track 0. Problems can arise using this program, since the drive can get confused if stepped backwards, but powering off the drive always fixes it. As was posted initially, the trick works by stepping back the head, doing a format, then resetting to the real Track 0 (which would be track 1 now), then formatting again, which doesn't affect track -1. I had my drive open while developing this, to see what was going on. The step command does half-tracks, and it seems you can get the drive to go beyond it's logical limits, although I doubt we could do writes to tracks above 39.

Thanks, Bryan. Similar to one I already located. It seems the bytes I'm sending don't correspond to controller commands, so some pre-processing must be done by the drive software. In any case, I've successfully written to the "hidden track" and have a program in progress which I'll upload shortly.

I've just tried sending some SIO blocks with COMMAND = $23. I'm sending a block of 128 bytes, experimenting with the first 2 bytes of the block. They seem to alter what happens: Byte 1 is command? Byte2 is parameter? byte 1=04 seems to do a format operation? byte 1=03 steps the head (by half a track) in this case, byte 2 controls the direction (0=positive, $80=negative) You can step to track = -1 then do a read of sector 1, it doesn't step the head in this case (as previously stated) Next thing is to do a format and see if the whole scheme really works. A datasheet for the floppy controller would be handy. Might be able to work out commands a bit easier.

Can you open it up?

The tape trick works by causing the disk to move slightly - so that a sector will be written but deviate from the track. So, I suppose that the sync marks or some of the data will go missing - but in any case the sector should come up unreadable. The speed trick would probably cause the data to be spread out too thinly and not read back properly. The problem with both is that only very early games, and few later ones used a simple I/O fail as a test for a bad sector - probably partly because the Atari drives give very little information relating to I/O errors. Things like fuzzy and duplicate sectors and long tracks were much better schemes, and harder to reproduce. I can remember copying American Road Race (Activision) - by simply formatting a disk and ejecting it after about track 50 - then writing the data to it.

The only easy way to remain compatible with 2600/800 joysticks and have 2 buttons is to have the 2nd one coming into a paddle input. Paddle inputs work by applying resistance to +5V, then sampling it each VBlank.

So the question is, has anyone else put it into practice lately? I assume the COMMAND value is $23 or $24. I can remember years ago discovering 1 or 2 command values that were undocumented, but never took it further. I suppose you would need to plug in the right AUX1/2 values to get it to work properly. Might try it sometime later.

ATR are disk images, and you can mount them in APE and just copy straight to normal floppy (provided the sector sizes are the same). If the ATR is huge or any other problems crop up, you can just copy files off it (assuming its a DOS compatible disk). XEX are binary load files, so use the "PC Image Drive" option in APE then copy from the PC directory to a normal Atari disk.