warerat

Wow, seriously? OK, I'll jump in on this insanity. I'll sell my Metalguy MIO serial #0002 with special mods no other MIOs have for $750.

I've been really busy at work, but here you go.. Updated firmware, version 1.4.1. Works on any 256K or 1Meg MIO. This is mainly bug fixes from v1.4.0, so I recommend you update. - APE commands now passed to SIO (allows use of APETIME and APE remote commands) - 128-byte single density support added (reports 128, 256, or 512-byte sectors to DOS) - Reinstated LUN support - Fixed disk operation hang under certain operations (MyPicoDOS users, rejoice!) - Fixed serial port interrupt bug due to bank relocation I only put the LUN support back in because I have a multifunction SCSI card reader. Really, really need to re-do the menu program.. It's getting quite limiting squeezing stuff into this thing. miov141.zip

Thanks for your RAM select info on the 8K/16K boards. The Mosaic boards were pretty unique. There was an auction on eBay one time for the interconnect cable and documentation, but missed out on that one. I'm not 100% on this because information is sparse, as opposed to the Axlon stuff that I physically own, but here's my understanding of how they work. I base this on information from emulators and the Mosaic Superdrive floppy I have. - There can be up to three 64K Mosaic boards installed. This gives up to 144K (192K-48K) extended RAM. One card enables 4 banks, two have 20 banks, three have 36 banks. - Banks are 4K, visible at $C000-$CFFF. - RAM is enabled through an address latch (not data). Writes to $FFC0-$FFE3 enable the bank ($FFC0=bank 0, $FFC1=bank 1, etc), writes to $FFXX not in that range disable the memory. I, too, would like to see what they physically look like.

These are invalid sector configurations. The maximum number of sectors is 65535 ($FFFF), not 65536 because the Atari doesn't normally use sector 0. Any Percom config queries to those drives will show them as 0 sectors because you have them set to 65536 sectors ($10000). The MIO firmware does allow for 24-bit sector addressing from the Atari but there is no DOS that can interpret it, yet. A sane config would be 1 to 65536 and 100001 to 165536.

These are interesting, but searching the internet I have found that some of these devices have READ ONLY firmware. I'm not saying that those from this seller are, but it should be confirmed before ordering. They are DEFINITELY Read/write.. I spoke to the guy on IRC about them for quite a while.. I can confirm the SCM PCD-50B sold by this fellow works read/write with the MIO. I've tried a 8GB CF card directly, through a Transcend PCMCIA adapter, a SD card, and Sony memory stick. I/O speeds are comparable to having a SCSI->IDE bridge installed. Caveat is you must have a parity circuit on your MIO (mine is modified) and run the new firmware for LUN support I haven't released yet. Theoretically you don't need the PCMCIA adapter, but the MIO stores the config on ID 0, LUN 0 so you'd have to reload the config RAM every time you power down the MIO.

So... Banning these entities seems to be bringing out the Atariksi in all of us. Anyone want to go grab some beers? I'm bailing out early today. CTFO, people.

Given the intensity of his personality, make no mistake-- he will be back. A narcissist like that cannot survive without getting the last word in. Who knows, maybe he already has another account waiting in stealth. So beware of any new users obsessed with LDA/STA to joystick ports, multicolor GTIA modes, Dr. Frog, mental speculation, "PC simulators", and the moon being made of cheese.

The single memory slot on the 400 by default maps four 8K selects, so 32K is possible without soldering. The additional 16K is implemented by pulling in additional signals, hence the reason soldering is required on 48K kits. The 800 has three memory slots so the 48K can be directly populated. Left carts can occupy up to 16K in the third 16K zone the memory map (XL/XE/XEGS only have the left cart). 800 right slot only maps the lower 8K. Even with banking, the bank still occupies the same area. This implies you can map 16K of RAM in the cart slot to bring a 32K 400 to 48K RAM without physical modification. The original Mosaic 64K board mapped four 4K segments above the 48K area (used by the XL OS) allowing for 52K of contiguous memory. It was just a RAM board and did not piggyback onto the CPU board (if you've seen the clearance in CPU board cavity on the either the 400 or 800 you'd see why). I highly doubt it would be directly XL compatible and allow for running software that required RAM under the OS.

Everyone who's responded has done a pretty good job explaining why it's better. I'll chime in as I reworked the firmware to work with new drives. The underlying reason for why the 512-byte sectors are faster has to do with the native block size of the hard drive. Modern HDD's have a minimum block size of 512 bytes (most of them, at least the ones we'll use for this). From a low-level SCSI firmware perspective we focus on the data phase where the asynchronous transfer from Initiator (MIO) or Target (HDD) occurs. This transaction is always the size of the native block size of the target. Therefore, we must always read/write 512 bytes in the data phase. There is no way to abort this in mid-phase cleanly. I could in theory attempt to interrupt the data transfer after I read a short (128/256-byte) sector but the hardware isn't set up for the initiator to send an abort message to the target to cancel the current data transaction. Even if I was able to do this, the SCSI standard is murky and there is no guarantee that every vendor's drive will abort right after the message is received or if we must still keep strobing ACK- until the drive's buffer has cleared. Because of the latter, it really wouldn't buy any performance. The key point here is I have to read/write 512-bytes in the data phase. If you request 256-bytes from the Atari, the read/write operation still requests 512-bytes but the second half of the transaction is discarded. When I reworked the firmware to work with newer devices I decided on a 1:1 sector mapping. By doing it this way, I don't have to have an additional buffer for the second half of the data not to mention having to monkey around remapping the second half to a physical sector. We have millions of sectors addressable, so burning them up only using half or a quarter of the capacity isn't an issue. So the bottom line is a sector operation to/from the drive takes the same fixed amount of time, regardless if it's 128, 256, or 512. Therefore the throughput you observe is directly related to this. Reading a handful of sectors probably feels about the same. But if you're copying large blocks of data back and forth, that's where using the native block size really shines and truly is better.

I have a yellow Basic XE and an orange Basic XL that work on my stock 800's. I put a standard 16K MAC/65 v1.01 ROM image on the Basic XE PCB and it works also. I'm very sure OSS language carts work on the 800, with the exception of the extensions you load from disk for Basic XE.

Did you ever make a switch that can turn off the XL compatibility mode or is that impossible? Glad to hear you're still working on this. Tempest Yep, you can select between stock 800 and XL. So one board can look like seven different Ataris.

I'm back after a long hiatus. This thing hasn't been forgotten. From a design and prototype perspective it is complete and does exactly as advertised (and more). I'm not going to lie-- I've been a slug and have had other things going on so I haven't finished the PCB layout for this. But it is a single card solution and does require soldering some jumper wires.

*IF* you can find one, I'm using an I-O Data ISDC21-E SCSI-to-IDE adapter on the MIO. No parity required. Seems to work with a couple of IDE drives I tried (540MB all the way to 80GB). RWTEST.COM speeds are comparable to the native SCSI. Disclaimer: I have substituted four IC's on the MIO board with 74F-series logic. Your mileage may vary.

Logic Analyzer sold to local Atarian....

Not too heavy, I'd say right around 20 lbs. I'll find a box and let you know.

Hi folks, I'm cleaning out my closet of some equipment I no longer need. If you want to graduate past a DMM and a logic probe without breaking the bank, here's your chance. Sorry for the crummy pictures-- I can send you others in PM if you want them. (1) HP 16500A Logic Analyzer: Has a 16510B 35MHz State/100MHz Timing analysis card installed. This gives you 80-channels. You can install the 16510A-B, 16532-4A oscilloscopes (250MHz and 500MHz dual-channel), and 16550A 100MHz State/500MHz Timing cards on this series. Passes all power on self-tests, but the back floppy drive is unreliable. Includes all filler panels for the four unused slots. I'm including the latest (last) version V6.0 of the analyzer software on six floppies and a work disk. Also including two 6502 inverse assemblers I made myself-- one for a standard 6502 and the other for a 6502C SALLY w/ ANTIC. With the inverse assembler you can find out what's wrong with your 6502 machine in minutes. DOES NOT INCLUDE PROBES OR DIP CLIPS. This uses the standard 01650-61608 HP/Agilent probes. These are available on eBay all the time. Each pod gives you 16-channels and 1 clock, so you need five to be able to use all 80 channels. With most 8-bit based machines you'll be able to get away with two to look at the CPU in action, 16-bitters will likely need three or four. $75 OBO (2) Hitachi V-302F Dual-Channel 30MHz BW Oscilloscope: Includes two probes, power cable. Needs some TLC-- the switches are dirty and need some contact cleaner to get them glitch-free on the display again. $25 I would *really* prefer you're in the Houston or surrounding area because the logic analyzer is heavy and I prefer not to ship it as it will be expensive. Send PM if you're interested.

This is really weird behavior. Do all carts do this in general or is it specific carts? The ones that do this, are they mask ROMs or EPROMs? If you know of any others I'd like to replicate this on mine (I don't have Congo Bongo). Would putting weak pull-downs on all the data bus lines fix this?

Page $D5 is the same for the left and right cartridges on the 800. Page $D5 and $D6 are also accessible in the last memory slot (slot 3).

All address lines and data lines and NMI are connected from top of CPU to top of ANTIC. However, I noticed that O2 aren't connected (pin 39 of CPU to pin 29 of ANTIC). Is this the same signal or do these pins not need to be connected? Stephen Anderson PHI2 is buffered through an AND gate on the 130XE. You should have continuity between pin 29 of ANTIC and pin 3 of U18 as also pin 39 of the CPU and pin 1 of U18.

For this particular part, yes, I have to drive at 3.3V as the FPGA is not 5V tolerant. If I interfaced it directly, I can kiss that $50 FPGA IC goodbye. You can drive 5V TTL logic with 3.3V LVTTL, but not always the other way around. The CPLD family I use for largish designs is XC9500XL-- they run at 3.3V core but are 5V tolerant. Unfortunately as time goes on there seem to be less parts (excluding legacy SPLD/CPLD) that are 5V tolerant.

For the metallurgically challenged (re: you suck at soldering and running jumpers but can take the computer apart), there's a paddle board that re-wires a few pins on the OS slot and only needs six connections to the CPU board. Just pull the two TTL chips, plug this board in it's place, and it's all underneath the plastics. Only needs six wires to the CPU board. If you can handle a 32-in-1 OS installation, you can handle this. Can't plug your old boards back in with this installed but at this point in the design you can turn it back to a stock 800 with the flip of a jumper.

The DCM is physical hardware that is part of the die. Picture a square-- the perimeter has the interconnect matrix to connect the I/O pins to the logic blocks and LUTs on the interior and the DCMs would be on the corners. To use one you have to instantiate one in a way that so when your definition is "compiled" the synthesizer knows you're referring to a primitive that is native to the device. This is done either with a VHDL/Verilog template or by generating one using the IP core tools that provide GUIs about which features and clock dividers/multipliers you want.

Thought about this today doing while doing some work with a dev board I have with an older Spartan 3 (XC3S1000, 1.8V core, 3.3V tolerant) that has four internal DCMs. I wired up a 3.3V buffer (74LVC244) and fed PHI2 into it and configured one of the DCMs to do CLKx16 (there's a minimum output frequency). From there I made some internal /4 and /8 counters to get the 7.16MHz and 3.58 MHz clocks. It wouldn't be any problem generating 14.318 if necessary either. The acquisition board in my HP logic analyzer only has a resolution of 10ns but it looks like the delay between the generated clocks and PHI2 is somewhere between 20ns-30ns. The buffer adds about 8-10ns, and I don't have PHI2 going into a dedicated clock port on the FPGA which would also factor in. This particular FPGA is a 4ns part. The smallest newer generation device that is flash is a XC3S50AN and is under $10. Those come with two DCMs inside. It's probably not much help if you're planning on going forward with the Atmel part, but I'd just thought I'd show you the result in a Xilinx part using the DCM for one of purposes they were designed for.

lda atariski tax cmp krishna beq normal_exit and #reason bne normal_exit txa cmp joystick_port_lda bne chewbacca_defense cmp ego bcc run_strawman_loop ldy #0 :douche_check cmp am_i_a_douchebag bne normal_exit iny bne douche_check txa and #unrealistic_fanboy_who_doesnt_know_shit_about_hardware_because_he_couldnt_figure_out_how_to_connect_a_2K_SRAM_to_his_Atari_800 beq run_strawman_loop jmp chewbacca_defense QED.