warerat

Not a problem anymore... Run this to cold start the 850 without powering anything off so it will answer polls again. reset850.xex

My contribution so folks stop plugging mask ROMs in backwards trying to read them, breaking clips, and mangling sockets. I wrote this utility tonight to download the firmware from the 850 using the undocumented "test and execute" command in the source code. This is done by pushing a couple of bytes of 6502 code to it via raw SIO. It will save a 4096 byte file called to D1:ATARI850.ROM that is the contents of $F000-$FFFF running on the 850. It will take about minute and make noises you've never heard coming from it. No R: handler or screwdriver required and no 850's were harmed in the process. Enjoy. dl850rom.xex

I didn't see where you connected TDI to actually clock data into the CPLD to be able to communicate properly. It's pin 10 on a 14-pin JTAG connector or pin 9 on the 10-pin.

It's an Amiga cable for MPDOS from the infamous "envious snake" atariksi. http://www.krishnasoft.com/sps.htm

The way I added I/O noise to the MIO firmware is pretty basic and doesn't really incur much of a penalty. If you turn it on you'll notice the beeps happen only for read/write operations and sound the same. All I do is stuff values into AUDF1/AUDC1 before the main I/O loop happens and turn it off when it's complete. So essentially the duration of the beep directly correlates to the time it takes to select the drive, send the command frame, and pull all the data off during the data phase. Does it sound authentic? No, but it provides some auditory feedback and doesn't waste any cycles during the critical I/O region.

The original ICD firmware is hardcoded for a 256-byte data phase so it will *not* work with any devices where the native block size is larger and may fail to select devices that are expecting the initiator ID on the bus with the device ID as explained a few posts above this one. In other words, your chances of success are zero without updated firmware.

The MIO is non-standard, period. The MIO SCSI hardware implementation is very minimal and is from a time when SASI/SCSI-1 was the dominant standard and even with its quirks the 5380 is much better. Device compatibility depends on if the vendor chooses to honor the ancient SCSI-1 selection schemes to access the drive. This, in my opinion is a huge shortcoming as the interface cannot support the SCSI-2 and higher arbitration sequence (this requires the ability to assert both the SEL- and BSY- signals, whereas the MIO can only assert SEL-), leaving only the SCSI-1 selection sequence without arbitration possible (in SCSI-1, arbitration is optional but required in SCSI-2 and higher). Most modern SCSI devices support this mode (as well as many SCSI/IDE bridges), but again it can be hit or miss. You can have multiple devices, but you can't have multiple initiators. The other shortcomings in the original ICD firmware is it is hard-coded to deal with 256-byte data phases and it uses the old 21-bit CDBs to read/write sectors. I modified the firmware to work with variable sizes to use 32-bit CDBs, allow newer 512-byte or larger blocksizes to work, and modified the selection sequence a bit to include the initiator ID on the bus instead of single-initiator as was done initially. While some of this I attempted to address in software, you still have to keep in mind you're missing the bi-directional BSY-, parity, the databus is logic true (instead of SCSI standard which is logic false), and you're missing ATN- that would normally be on a fully-implemented interface. The statements that the MIO writes data to the drive inverted can be misleading depending on how you look at it. From a digital logic point of view, it is writing data to the drive exactly as presented as logic true. From a standards point of view, this data is supposed to be logic false and not doing this saved adding additional logic on the board. It can of course, be done in software (and it is, when sending CDBs, just not in the data phase) at the cost of performance.

By software, I mean the firmware. I'm assuming you've got the drive jumpered and terminated correctly as it appears the ICD formatter started. Also make sure the "P" jumper is off (this disables parity). I don't suggest running any of the old ICD HDFMTPHX for this, but that is my opinion based on looking inside on how the defect list is handled. I'd trust the format if done from a PC-based SCSI host adapter. If you're sure the media is good and if the block size is 256, then the usable sectors are 0-173399, if it's 512 you should be able to use 0-86699 at half capacity. Naturally on the Atari you'd start with sector 1. One day I'll finish my MIO APT-compliant firmware but don't expect it to be remotely compatible with any of the original configs.

There is a lot of generalization, speculation, and misinformation here on how the MIO operates. - (1050) No sense data error is likely due to SCSI 1 and SCSI 2 differences in the returned data field, you won't be able to get around it until you re-write the MIO software to comply with SCSI 2 data returned as well as handling SCSI 1 data fields. Huh? After the data phase is complete, the message phase starts that has data indicating the status of the operation. If the error bit is set, then you send a Get Sense CDB to get a more specific sense key/code describing the error. There is no "complying with SCSI-2 data returned". Instead, what the MIO lacks is the proper SCSI-2 Arbitration/Selection phases that some devices at strict SCSI-2 spec require. How do I know this? I rewrote the SCSI routines in the MIO software to improve compatibility with newer devices and not rely on a fixed 256-byte data phase. These two limitations are usually the cause of SCSI devices not working properly. - (1050) IIRC even 2048 byte sectors are not outside the possibilities on some SCSI drives. IIRC again 1024 byte sectors are matching what CDs have and use. Data CD-ROMs use 2048-bytes (excluding the ECC). The updated MIO ROM can handle these large sector sizes, assuming the DOS can. The parameters for cylinders and heads are irrelevant in this context and won't make any difference. Those are sent to the device only if you use the original 1.1 firmware and the device is set to SASI. The CDB for the SASI drive config command is long obsolete and not recognized by modern SCSI controllers that aren't attached to an ancient MFM/RLL SCSI/SASI bridge. What is still relevant is the starting and ending sectors. The original MIO firmware uses the older 6-byte CDB to read/write sectors to the disk, allowing only for 21-bit sector addressing. The re-written one uses the newer 10-byte CDBs that allow 32-bit LBA and can also send a Read Device Capacity CDB to find the number of blocks (size) and the default block size. MacRorie: If you want a basic confidence test, all that is required is simply write the config to the disk. This is stored in LBA sector 0, so just set a configuration and write it and upon reset if the drive is able to restore it correctly then you will know if you have a chance of the device working. If it errors while writing the config and you're using the original ROM then its either: - The device is expecting parity and the MIO isn't modified to supply it (this can be fixed in hardware) - The device doesn't honor the SCSI-1 single initiator sequence the MIO provides (quasi-fixed in software) - The device data phase is > 256-bytes (fixed in software) - There is a problem with the media Last but not least, using the old ICD formatters that are coded for long obsolete drive types is not recommended or a guarantee for success.

I remember calling this and chatting with your brother!

Yep.. This goes on a 2732, but really only about 1.5K is used. SWP_8088.ROM

All this talk about the Co-Power made me pull mine out. My ATR-8000 came equipped with the Co-Power Plus with 1MB of memory. This board and the regulator are mounted below the Z80 motherboard. It's a pretty simple setup and would be trivial to reproduce with a handful of ICs, a CPLD, and some SRAM. Unfortunately I don't have CP/M up and running to test it.

The nibble data from low-to-high order addresses is: $1, $1, $3, $2, $4, $3, $5, $4, $e, $e, $e, $e, $f, $f, $1, $0 D0 => !A1 & !A2 & !A3 # !A0 & A1 & !A3 # !A0 & A2 & A3 # A0 & !A1 & A2 D1 => !A0 & !A1 & A2 & A3 # A1 & !A2 # A0 & !A1 & A2 # !A1 & !A2 & A3 D2 => A1 & !A2 & A3 # !A0 & A2 & !A3 # A0 & A1 & A2 & !A3 # !A1 & A3 D3 => A1 & !A2 & A3 # !A1 & A3

Hi Jim, I have the bit sequence and equivalent GAL equations for this PROM. Only 16 bytes are used. I am out of state for Thanksgiving but will post them when I get back tomorrow or maybe someone can beat me to it.

You mean this? BONJOVI.XEX

I'll be in Austin this weekend and will certainly stop by the AtariAge booth to say hello!

Couple of comments. When I reworked the source, I first assembled what was originally provided (with some syntax changes) and then did a byte compare with my ROM (mine has a printed label of "3.02+"). I renamed the originals .orig with the exception of rom.mac, but really there are only a handful of differences between the original commented source and what I patched: - rom.mac : There is an additional byte, $95 that was not in the original but is in my ROM. No idea why it is there as it isn't referenced anywhere. I added the macro at the end to align the "ATR8000 ver 3.02" text string to the end of a 4K boundary that was missing from the original, but it doesn't have to be there. - diskio.mac : Delay appears to have been shortened from original source in subroutine "RESTORE". Original had 30, ROM had 0. - minimon.mac : The 'D'ump feature was not on the production ROM, so I commented this out - globals.mac : Another mystery byte here, $73 The changes above yielded an exact byte-for-byte match to what I have and also matches what was posted earlier in this thread. The ATR8000 is strapped for an 8K ROM, so you could conceivably add the dump code back and fit it on a 2764, assuming the ram-resident BDOS doesn't bump up against $F000 in the memory map and the CP/M jump vectors are left undisturbed. I'll probably end up doing that later this week just for fun. My ATR8000 is serial # 2675 with a fully populated Co-Power88 daughter board underneath with 1MB of memory. I have made dumps of the PAL on the Z80 daughter card, the PROM on the mainboard, and the EPROM for the Co-Power88 if anyone needs them. Thanks to you guys for your work and dedication to getting these disk images squared away.

There is commented source available somewhere, but I don't remember where it is. I found my copy and hacked it slightly so that it will create the ROM binary file. It is interesting to note there are some monitor functions commented out in the source that is not in the production release. Apologies for the ugly hacks in globals.mac and rom.mac, but it does build! I found the pasmo Z80 assembler (http://pasmo.speccy.org) was closest to the syntax that was used to build it originally. I used version 0.6.0.20070113.0 with the following switches: pasmo --bin --nocase rom.mac atr8000.rom This will create the atr8000.rom file which is an exact match to the v3.02 ROM that exists in my ATR8000. Hopefully someone can take this and do something useful with it. atr8000_source.zip

I was there for the GTC back in 2012. The conference was held in downtown San Jose (about a 20 minute freeway drive in the morning) but I stayed at Country Inn off of Carribean and SH 237 in Sunnyvale- a mere ten minute drive from all the old Atari buildings. Funny how our travel system picked out that hotel as "preferred" and I simply couldn't resist. The 1265 building itself and surrounding area looks well kept, and most of the office buildings there are available for lease. In the evenings I'd make it a point to drive by and it was surreal to go back in time for a moment. You can see my reflection in the doors between the posts (my legs, anyway). Feel free to call the number and lease it out...

You can find the manual here: http://www.atarimuse...its/atr8000.PDF I used DT80 to have software 80-columns to connect to the ATR8000. Page 50 in the manual above tell you how to bootstrap the CP/M disk image from the ATRMON prompt so you have to have one to use it. The rom image to DT80 should be floating around somewhere.

Here's mine that I scanned, although it's got some handwriting on it from the previous owner. Bit3_UsersGuide.pdf

This may come off as a little strong, but please, quit busting my balls this upgrade. There are several people on this forum that I have modified OS boards to give 64K 800XL (and one even has a 576K version). Rather than doubt my claims, a simple polite PM would suffice. I do have an active work life outside of this forum, and it requires me to travel. I'm sorry if my schedule and the way I've implemented the design (read: Facaui) does not meet your criteria. I would like nothing more than to mass produce it, but I cannot at this moment. Not saying that it will never happen, but the way I've implemented it to be an all-in-one solution and the constraints of the 800 is a little more involved than the skill set of most hobbyists. Please correct me if I reading you wrong, but to modify an OS board (or Ramrod) to provide minimal 64K 800XL compatibility (with RAM under ROM) can be achieved easily and if it placates the community I will do a write up.

My personal favorite is HDSC from drac030: http://drac030.krap.pl/en-sparta-pliki.php

The stock OS board is designed to take custom mask ROMs with extra chip selects that don't exist on EPROMs so you don't need additional external decoding circuitry. My advice is if you don't want to redesign the OS board, design a piggy-back board that plugs into the the ROM socket that swaps pins and provides the logic to further decode the chip enable for an EPROM, or perform the decoder circuit modification for an EPROM, don't plug in the wrong chip and just to use a mask ROM that the socket is wired for.

It is none of those. It is a custom mask ROM with two active-high and one active-low enable.