-
Posts
3,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Nezgar
-
-
A very similar cartridge is the "Uno" cart - main difference is 128KB of RAM instead of 1MB like the Ultimate, so it can do 64KB carts just like the Ultimate, but not 1MB biggies like Bad Apple or Atariblast.
-
I've definitely corrupted disks in drives attached to an ATR-8000 by powering it up with a disk in and latched. I've personally never corrupted a disk in a 1050 or 810, but I believe I saw there are design enhancements in the 1050 schematic that protect the write head from surges during poweron/poweroff.
There are issues with the original power board 810's that could corrupt data if a disk was in & latched as there is also no write circuit protection there, but I believe was later improved with the Grass-valley set of upgrade boards that present in "most" but the earliest of 810's, as many people back then would have upgraded them if they didn't have it already for the reliability improvements.
Since the 810's always relocate the head to track 39 when spinning down, it was most likely that you would corrupt a sector on track 39 - which I guess was a design decision to protect against otherwise corrupting important boot/VTOC sectors on track 0...
-
1 hour ago, MrFish said:
What's the story on this supposed "Rev. E" ROM, which is 2,054 bytes (?) and says "DAVE STAUGAS" towards the end of the file?
I think I got this from Pigwa, as it appears to be the same as what can be found there.
That ROM is 2048 bytes with a 6-byte DOS 2 style binary save header... (FF FF 00 A0 FF A7, meaning load at memory location A000-A7FF (2048 bytes). I believe EPROM programmers like the Bob-Burner saved files with this header format...
Without those 6 header bytes, the remaining 2048 bytes that produce a CRC32 of aad220f4. This matches the CRC32 for Rev. E noted in the Altirra Hardware Reference Manual (2022-01-03 Edition). Here is what Avery reverse engineered for the additional commands in Rev. E... These commands could have allowed some nifty tricks if Atari had originally included them in Rev B or C...
QuoteRevision E changes
The revision E ROM adds a few new commands to the 810 over rev. C, specifically ones that allow execution of custom code on the drive.
$20 (execute code)
Command $20 takes a 128 byte data frame sent from the computer and executes it on the 810 at address $80. The firmware sends the command and data frame ACKs before calling the custom routine, and expects that routine to return with RTS. Afterward, the firmware sends the Complete signal back to the computer. $80-FF and $180-1CF are available for use by the custom routine, the former for temporary storage during the routine's execution, and the latter for permanent storage (not used by the firmware at all).
$4F
The bug in revision C that allowed $4F as an alias for $57 (write sector) has been fixed; rev. E rejects $4F with a NAK.
$54 (transfer memory)
Reads 128 bytes of memory starting at the address specified by AUX1 and AUX2, where AUX1 is the LSB of the
address, and sends that buffer back to the computer.
$FE and $FF are trashed by this command and cannot be read back.Now need to look more into where "Dave Staugas" comes in... Googling shows he was a prolific Atari Programmer that wrote NEOchrome for the ST, Hover Strike for the Jaguar, Millipede for the 2600, and Rampage for the 7800.
Methinks he may have "patched" the 810 ROM to add those features that would be useful to an programmer like himself? It was probably only meant for internal use, and only "leaked" similar to many other things that were leaked / cleared out of Atari...
-
1
-
1
-
-
8 minutes ago, KG7PFS said:
So are they or are they not 360k?
XF551 can do SSDD 90K, SSED 130K, SSDD 180K, DSDD 360K
Astra's are various combos depending on the mech in each model.. Single sided they can do SSSD or SSDD, not SSED. Double sided adds DSDD. I can't remember if they could technically do single density double sided, that would be silly though heh.
Looks like Astra 1620 and 2001 had 2x single sided mechs. Astra "Big D" was 2x double sided mechs.
-
Astra drives are actually Percom derivatives with a prettier face. ROM dumps revealed the code is almost identical to Percom code with some minor alterations.
As for comparing to an XF551, Percom/Astra drives can't handle "Dual" aka "Enhanced" density format, and also have no highspeed SIO option like an XF551.
-
Reproduction of the Turbo Freezer demonstrated in action:
-
If it's a Tandon mech (drive made in Singapore) just get new belts here:
https://console5.com/store/fabric-reinforced-belt-for-atari-1050-tandon-tm100-4p-floppy-drive.html
The whine could be coming from the felt pressure pad (try carefully turning the pad where it's clipped in) or the top/bottom spindle, which you can work in some 3-in-1/sewing machine oil into.
-
The power at the DIN connector is just +5VDC, so just use whatever power supply is appropriate for the location the machine is currently operating in.
A 240V AC PSU will generate +5V DC from a 240V AC power source, and a A 120V AC PSU will generate +5V DC from a 120V AC power source.
So yes, using a USA PSU on a PAL 800XL will be just fine, other than the other challenge of dealing with the PAL video output.

-
The de-facto go-to resource is probably Best Electronics, NOS items. Lots of long write-ups on the most common failure points of the 810's like you have already on your hands. The proprietor is quirky, so keep your requests consise and short. Personally I'll email, but have called sometimes to finalize payment via credit card, or just paid via PayPal.
I do have my own collection of 810's in various states of health, primarily one that due to stupid poor shipping receiving the case was shattered to smitherines, but the drive itself was still fully functional, so it has become a handy test specimen.

Personally I'm looking for a particularly obscure part for an MPI mech... that little clicky latch that releases the spring that pushes the disk back out when you open the latch... I would trade the faceplate for that lol. Maybe I can find a picture somehwere.
-
On 3/27/2022 at 5:43 PM, joe r said:
most intel 8051 and derivatives can be popped to reveal code even when secured...
Man, it's been two (almost three) years since my last post on this thread, I still have to check the CPU/ROM configuration of my two (no longer three) XF551's and I had since forgotten the details I apparently knew so well in that last post.
Do you know what equipment is required to dump the ROM from an 8051? If you or anyone have the means to do so, I wonder if we could arrange getting said chip to that person to dump the ROM...
-
I believe one of the ANTIC interviews with maybe Rob Zdybel? had a story where Atari had surplus inventory of 810's mechanisms and boards but no cases, and potentially functional issues due to the high return rate, that employees and some resellers were able to purchase the parts for cheap, repair them and built their own cases and were resold for profit. I know B&C Computervisions was another supplier of these 810's as well.
Honestly, I'd say these are better looking than the original cases... More durable that's for sure!!
-
3
-
-
What is your programmer? 21V 2732's may be hit & miss with the popular TL866's.. the v1 claimed to be able to do 21V, but was really more like 16V, and the v2 doesn't claim to do 21V at all, so try to find 2732's that are 12.5V ideally, but I can't remember if this is even an option for 2732's a the moment.
With that said, I have successfully programmed 21V volt 2732's with the v1 TL866, but in some cases it took many passes & retries before the whole write succeeded with 0 bit mismatches, highly likely due to the borderline Vpp...
You might want to consider using a 2732 adapter board with a larger, more common EPROM like a 2764, with the added bonus of being able to switch between two different Indus GT ROMS - ie 1.2X patched, and a standard ROM that is still compatible with CP/M and 64K Super-Syncromesh upgrade. (I Don't think that 1.2X patched ROM is compatible with CP/M).
Such as this adapter, which you can wire to an external switch: https://store.go4retro.com/23xx-adapter/
If using a 2764 EPROM, you just program the two 4K ROM's one after the other, or repeat the same one twice to just use one OS, and use the adapter just to use an easier to acquire and program EPROM chip.
-
Did you "print" this into a physical thing for your drive? I tried once to 3d-print a faceplate from a previously available STL and in my case it was difficult to print, didn't fit, and looked ugly

-
Turbo BASIC is not a cartridge (or a cartridge-like BASIC ROM in XL+ machines) - it's just a binary loaded executable, so there is in fact no cartridge present as DOS indicates.
To return to Turbo BASIC you'd have to binary (L)oad the Turbo BASIC program, probably AUTORUN.SYS.
-
If you make a USB --> DIN power cable, I've done it (briefly) -- but yes it works.... as long as your USB portable power source can supply at least 1.5A at 5V.

-
One option if an exact part isn't found would be stacking another header strip on top of the ones soldered to the board...
-
1
-
-
What model hard drive? At 10MB it's more likely to be a drive with an ST506 type connector (Maybe the ST412?), requiring a separate SCSI controller (ie Adaptec 4000A) to connect to an MIO or black box.
Do you recall if when you originally used it with MIO then switched to Black Box if you used the drive in "MIO compatibility mode" on the black box, or if you re-formatted it for use on the BlackBox?
If the former, you should be able to read it with an MIO or a BlackBox - if the latter, only with a BlackBox.
Basically, if you no longer have that extra hardware you can probably only read it with that hardware, meaning the best bet is to send the drive to someone who can hook it up and try to read off the data for you.
I have an MIO + Adaptec 4000A controller and I could potentially try for you - but if it was reformatted /partitioned by black box, you'd likely need someone with a black box to give it a go...
-
What program are you using to measure RPM? I know there is one as part of SpartaDOS, as well as the Atari 1050 diagnostic utility... (though that program shows the timing in ms per revolution versus revolutions per minute)
These disks can absolutely lose their ability to be read or written over time... It's good to test disks you plan to regularly use with an occasional full re-format. A known good working 1050 is also useful if you have one.
Also make sure the read/write head is clean - dirt on it can reduce the ability for successful data read/write, as well as cause physical abrasion and scratch the disk further degrading your disks...
Also inspect the drive belt beneath the mechanism - these are also often worn out, loose, or falling apart and can also lead to erratic RPM if it is slipping or the disk itself is too hard to turn within a disk sleeve with too much friction...
-
It could very well be a bad disk, or a dirty head in the drive.
If you can boot DOS, and write a small file (ie. save a small BASIC program) and read it back, then the drive is probably fine. The thing with formatting disks is that even a single bad sector will cause the entire format to return an error. If the write immediately fails, it could be as simple as the write protect function is failing, causing all disks to seem write protected, whether or not the disk has a notch on the side.
The format routine should attempt to format all 40 tracks stepping from track 0 through to 39, and then it verifies, tracks 39 to 0. If you listen carefully and count (or even easier to watch if you have the cover off) you can see at what part in the process there is a failure. If the failure happens on the first/innermost verified track, vs some part further past that point, will help give a hint.
I would inspect the particular disk you are using for blotches which might indicate mould on the surface, or lines etched into the disk which might indicate a dirty head is scratching it. Clean the head inside the 1050 with a q-tip/cotton swap any isopropyl alcohol. If you are able to remove some amount of brown gunk from the head that is a hint that some of the disk coating has been wearing off onto the head.
-
1
-
-
8 minutes ago, tep392 said:
I just discovered that the CPS disk tests don't work with my Super Archiver/Bitwriter or Mini-speedy drives either. I would have thought that the SA drive would work since it wasn't "opened". It doesn't even start the drive motor for the speed test. Almost like Atari made it intentionally not work with the modded drives.
It simply boils down to the fact that ICD US Doubler didn't implement the $23 service & $24 diagnostic commands used by Atari's 1050 diag utility supported in the stock ROM. A US Doubler will just respond with NAK to those two commands. A super archiver will also respond with a NAK to those command, and if opened I can't remember if those commands are become available for something else...
-
16 minutes ago, Mrshoujo said:
But if the disk emulator loads the entire file at once into memory, it would be automatically decompressed. The original file on the storage medium wouldn't be altered until the emulator was told to Save it back out to update it. That's been my experience and understanding with Altirra and SDrive Max.
As far as how the format works, it wouldn't require more than a few days of keen observers to figure it out. Or they could ask Bob Puff.
I see ATR as the uncompressed version.
All well and true nowadays. But remember, the original SIO2PC host software was designed to run on PC's much less capable than today -- ie a 4.77Mhz IBM XT with 640KB RAM and a 20MB hard drive.. Back then disk images were read/written in real time, and not read into RAM and written back out later as a whole chunk, and the associated compression/decompression that would be associated with a DCM file. Even more so with larger "virtual hard drive" images up to 16MB. I know a friend who ran their Atari BBS solely on a "hard drive" setup solely relying on the storage of an SIO2PC connected PC providing all of the storage this way. Not having the data written to physical disk in real time could have been catastrophic if the host crashed, powerout, etc...
The fact that it was easy to reverse engineer the Disk Communicator format is evident exactly because it is directly supported in more tools today like Altirra. Actually, I just checked my currently installed (old) version R3 of RespeQt, and it supports ATR, PRO, XFD, but not DCM - maybe it was added to a later version. XFD is also an uncompressed image format introduced by the ST / PC XFormer -- even simpler format: pure sector dump, not even headers. Only indication of disk density was the file size.
Edit: Ancient Nick Kennedy SIO2PC for DOS software DID have the option to load disk images into PC RAM if you had enough, and there were separate utilities to convert between ATR<>DCM -- just not directly within the program...
-
Just now, Mrshoujo said:
I am surprised Bob Puff's Disk Communicator .DSK files didn't become a standard for emulating Atari disks. Doesn't it also encode density information in the DSK files his utility makes?
Most people used 'DCM' as the extension for Disk Communicator... Problem was the file format was never documented, so anyone else who supported it was purely from reverse engineering. DCM being compressed, also didn't lend well to real-time changes, so wouldn't work nearly as well as ATR's for single sector changes etc. It also didn't support disk sizes other than the basic single sided SD, ED, and DD as far as I know...
-
Great! I can see this being very useful for archiving disks from the Atari directly to a PC drive over SIO2PC via PCLINK RespeQt and SpartaDOS X, skipping the need to create/mount/save ATR's on the PC side for each disk.
Re skipping bad sectors - drives like the 810 and 1050 will actually return the data it was able to read from a corrupted sector along with the error status response. You might want to take advantage of this and somehow note in a separate file which sectors were affected. You could even employ a mechanism to read a sector multiple times to see which specific bytes fluctuate, and which are stable. (This is a popular copy protection mechanism where sectors are partially 'fuzzed' on purpose...). This would aid significantly in a data-recovery effort.
I'm not sure how this might work in 3rd party drives, but I believe most ultraspeed SIO handlers don't return the data bytes when a bad sector is encountered, so disks with bad sectors would have to downgrade to the OS SIO driver to read those sectors. It might also be a limitation of drive firmware like US Doubler when operating in the faster SIO mode, I can't remember...
I think @HiassofT was considering an update to his highspeed SIO driver to return bad sector data, I don't think it's happened yet.
Another thought might be to support command line switches to speed operation from SpartaDOS X?
Adding high-speed SIO code shouldn't be necessary - you should be able to rely on the OS or DOS to provide that, so the user can enable their preferred driver.
Automatic density detection is possible, there are a some nuances with 1050 stock and US Doubler enhanced density detection- ie US Doubler's percom block returns incorrect info for an ED disk, but the Query STATUS command is correct... 😕
Look forward to trying it out for my backlog of disks to archive!
-
2
-
-
Just now, Larry said:
Did the 810 Happy use the 6507, or replace it with a 6502?
6507, just like the 1050. The happy 810 also continues to use the 6507 and as such has to do a lot more to bank switch the larger ROM/RAM, but 1050 happy enhancement replaces it with a 6502 (as does many other 1050 upgrades) to allow for much more addressible memory and simpler/linear memory map. The ability to track buffer an entire DD track was also likely a contributing factor. (4.5KB of RAM needed just for that)
-
1
-

Real Atari SIO Devices in Altirra
in Atari 8-Bit Computers
Posted
No, but with full emulation of drives and other peripherals you can emulate their function very faithfully.