ICD MIO ROM variants? Dump yours!

[ICD MIO ROM variants? Dump yours!]

Its all the same program, feature-wise.. The only difference in any of the versions is how it's organized on the storage medium.. It well may be that the same ROM version works on either the os rom socket or the SDX cart, now that you bring up the fact that it's only 8k.  I cant remember. I do remember testing MIOs by running that program all 3 ways though. Steve Carden would be a better guy to ask about the particulars, and if anyone, he would be the one who has the authority/decision on sharing the source code. 

 

[ICD MIO ROM variants? Dump yours!]

There's no difference in the ILS version. Steve Carden just "rebranded" it.. 

The program came from Mike Gustafson of ICD.. original designer of the MIO..  

In addition to the executable version, there are also two ROM versions of that test program. One is made to drop into the Atari's OS ROM socket, and one is made to go into an original ICD SpartDOS X cartridge..

 

I do have the source code for that program. 

 

 

 

 

[US Doubler Chipset]

Yeah. Those are the original 1050 chips that someone put back in the original packaging.. 

Don't worry though, it's easy to make your own US doubler. All you need is two 6810 SRAMS and a 2732 EPROM. 

 

Build this module using the two SRAM chips:

 

 

Then, burn THIS BINARY IMAGE onto the 2732 EPROM.

 

Walla.. You now have an ICD US doubler.  Plug the hybrid 6810 module you built into the 1050's SRAM socket, and plug the 2732 EPROM into the 1050's ROM socket..  Follow the instructions in the manual that you have there, to make sure the jumper settings on the 1050 board are correct. 

 

You can now use ICD SpartaDOS to enjoy Ultraspeed (52kbps) and true double density (180k) capability..

 

[Dust covers for Mega STe/TT?]

19 hours ago, calimero said:

Not for Mega ST/TT but I have a need to share some dust covers that I made for my retro computers

 

  Hide contents

Those are bad-ass, Calimero.

You have my total admiration for the dust covers.. 

The yuppie-assed "feng shui" type presentation environment, not so much.. But the covers themselves..  Righteous, man.. 

[ICD Multi I/O overheating]

If you hook an external 5VDC PSU to J7, the regulator and rectifier will be bypassed and the MIO will run much cooler. If its a 1meg model, make sure your PSU is capable of doing at least 1A sustained, preferably more..  You'll have to rig an inline switch if the PSU doesn't have one, because this also bypasses the power switch on the MIO. This is what smart BBS sysops did back in the day after realizing that even extra fans wouldn't save the MIO's pitifully underrated PSU components from eventually cooking themselves, during 24-7 sustained useage..  

 

J7 pinout:

1&2 9VAC circuit (do not connect anything here)

3&4 9VAC circuit (do not connect anything here)

5&6 GND

7&8 5VDC

 

 

note: make sure your MIO has the 5V PLL upgrade. In other words, it has to have the newer U19 IC that runs on 5VDC. Otherwise, you will need an additional 12VDC supply to pin 16 of U19. If your board is missing VR2, then it has the upgrade. If VR2 is populated, then it does not have the upgrade. 

 

 

 

 

[Apple II games ideal candidates for some conversions?]

The Apple II doesn't do 280x192x 6 colors..  It's 290x192 monochrome pixels in HI RES.   The color pixels are effectively artifacts so it's only actually 140x192x6 colors.. 

In double hi-res, you can have 560x192 monochrome pixels, or effectively 140x192x16 colors.

 

The apple has the ability to turn off the chroma signal to the composite video output when in text-only screens, to avoid the color artifacting. and thus utilize the full monochrome resolution for text, but in hi-res graphics modes, with a color composite monitor, you are going to see the color artifacts whether you like it or not. You can plot pixels on the full resolution of the bitmap, but you are actually only going to see 140 color artifacted perceivable pixels horizonatally.. 

 

  

[Apple II games ideal candidates for some conversions?]

Prince of Persia

Wings of Fury

Bard's Tale series. 

Wizardry Series..

Legacy of the Ancients

 

 

[The PBI Device We Need]

17 hours ago, BillC said:

Yes, this is from the documentation for the W65C51 and means rewiring of the crystal would be required to use it as the external clock signal. Doing so would also disable the internal baud rate generator unless it was done with a switch that allows both settings.

Total bullshit, I'm afraid..

All that is required is setting the register to 0..

 

Like I said before, it's done pretty commonly on apple IIc, apple super serial cards, etc.. for fast serial transfer of disk images on the apple II.. And there's no switch involved.. And on those implementations the chip is also clocked at 1.8432mhz..  Its pretty standard..  

 

 

 

[The PBI Device We Need]

On 1/9/2021 at 12:40 AM, BillC said:

So an MIO/Black Box may be capable of 115,200 baud by adding a 1.8432MHz external clock connected to the 6551 ACIA(may also require a W65C51N), and modified firmware.

 

 

It's already running on a 1.8432Mhz external clock.. There's a big assed 1.8432Mhz crystal right there next to the chip.. On both devices.. 

 

And yeah, it can be done in software. ADTpro on the Apple II does this using the 6551 based serial ports.. 

 

[The PBI Device We Need]

 

The fastest data throughput you can get from a 1.7mhz 6502 is about 200Kbytes/sec.  You can subtract from that any cpu time and propogation delay caused by software/hardware handshaking.. But theoretically, you could could probably do over a megabit/sec if everything was reasonably well implemented.  What would be the point? No standard RS232 device operates at that speed. 

 

I think that something like the Fujinet on PBI would fill/replace many roles. 

 

As far as crisp 80 columns, get a VBXE and a 14khz capable analog RGB display..  

 

As far as the nonstandard MIO DB9/DB25 ports..  I hear ya..   I corrected them on my reproduction MIO board design. There are at least 35 MIOs out there somewhere that have PC-standard serial & parallel ports.. 

 

 

[ICD Multi I/O]

10 minutes ago, Peter Rabitt said:

Hi, MEtal, I have a mio and the 4 diodes, one end of them are up on the board.. I don't remember if I did it or it was given to me back in the 1988 or so.. 

My question or two are when the diodes / IC reg. went, did it do and of the other IC and things bad. did it over voltage them or ???

Did you see any other problems when the reg/diodes went?? What was the input voltage for the unit??

Sorry to ask but I just found all my Atari stuff and I am trying to remember all the parts and put my old BBS back on the air...

 

Peter

 

 

Usually, the diodes get so hot that they delaminate the copper traces from the PCB, burn off the green soldermask, and even turn the fiberglass of the board dark brown/black..  Before finally prematurely failing due to obvious over-heat (over-current and lack of cooling) conditions.  

The large aluminum plate is adequate heat-sink for the 7805 regulator, but I have seen those fail too. 

 

If you want to fix the power circuit back to factory functionality, just replace the 7805, diodes (Id go much bigger or use a 2A+ rated bridge rectifier unit instead,) and the 3 largest electrolytic caps (these are probably dried up and shorted with age).

 

If you send me a pic of your board in PM, I can make further suggestions. 

 

 

[ICD Multi I/O]

The 1090 was dropped before the modern XL/XE existed.. By the time the 800XL and 600XL were finalized, ATARI's current product development dept. had resigned themselves to a)producing the XL line cheap enough to compete with the C= 64 price point and b)only using the PBI port for a memory expansion for the 600XL.  Any 3rd party developers wanting to use the PBI bus for complex expansion devices basically had to deal with any problems incurred on their own.

 

The last machines that had a buffered expansion bus were the 14xxXL line. And even some of that was never standardized. The 1090 has provisions on the board for full buffering, but it can be assembled to bypass it. I have seen 1090 prototypes built multiple ways, in this respect. I'm not sure of the level of functionality/stability any given spec had in this regard. They were ALL still prototypes and limited promo/beta/show units. Anywayze, the main point is that Atari originally envisioned the PBI as a workable expansion system, but it got bastardized before it ever saw consumers' hands.. Sad but true.. 

 

When the XE line came along, there were a whole new crop of people at ATARI (both engineering and marketing).  The ECI bus was basically just a more centralized/complete connection standard for what had been the "XL PBI PORT" (and a few additional choice signals) so as not to "close the door" on the possibility of more 3rd party local bussed expansion hardware, but also to reduce costs even further by making the cart port and "ECI" physically overlap..

 

Even in the XE era, ATARI, itself had no intention whatsoever of selling a complex parallel-bus connected device.. They knew the stability problems (and related support nightmare) that would cause. Hence the ridiculous nature of the XEP-80 80 column "solution"..

 

Both ICD and CSS had "custom tuning" departments that required you to ship them your ATARI so they could hook it up in conjunction with the device (MIO or Black Box) and make necessary timing adjustments (add caps.. Swap ICs.. etc.) to various circuits in the event of stability issues that could not be resolved by normal user operator means.  Most cases of this involved heavily expanded machines, but not all.  You can read about a lot of these cases on the old Compuserve, Genie, and usenet archives from the late 80s to mid 90s..  

 

The last thing that's worth noting here is that in recent decades, a lot of people (Candle, HiasSoft, Mega-Hz, Simius, Warerat, myself, and others) have all tried to come up with a somewhat universal "PHI-2 timing fix" that would address these stability issues in a way that would negate (or at least reduce) the amount of "custom tuning" needed to achieve/maintain stability on an ATARI with a heavily expanded parallel bus.  To my knowledge, there is no universal system-wide fix.. There are device specific solutions that can be added to hardware designs which will augment the PHI2 timing in relation to the onboard chips on that device.. But there is still the possibility (Heh. Probability) of the total bus load/capacitance effecting the PHI2 to bus timing with respect to the Atari's internal chips and causing flakiness in many cases. The more bus capacitance (the more crap you've got connected to the system's physical bus), the more likely/prominent this is.. 

 

So.. This, I'm afraid, is simply the "nature of the beast" with these systems...  And as I said, it's all about cost reduction back in the 80s.   

 

For contrast, Apple II is a good example of a 6502 platform on which a relatively stable expansion bus standard was developed.. 

 

 

  

 

 

[ICD Multi I/O]

The lack of a proper buffered expansion bus on the atari 8bit platform means that anything connected to the data bus skews the bus capacitance/timing all to hell and creates flakiness & instability.  That is the problem with developing for PBI. The PBI standard, itself is very straightforward. 

 

This is not a unique problem n the 8-bit world. The C=64 is in no better shape in this respect.  It was all about cost reduction..  

 

[ICD Multi I/O]

Obviously I wasn't comparing a floppy drive emulator to the MIO when I specified "mass storage".

 

SIDE2/3 is very stable now, works reliably, is much faster, and much cheaper. If you don't need local-bus speed, SDrive, SIO2SD, Fujinet, etc..  are all good options.  

 

I do prefer IDE Plus 2.0, although I am not aware of how/where it is still being sold. 

 

The MIO is a dinosaur. The design is based on alot of older generation power hungry ICs and it is extremely temperamental and succeptable to bus-load/timing related instability issues.

 

Also, compatible drives are hard to find and/or expensive. It's not a real SCSI interface. It's missing an output that all but the most archaic SCSI operation modes depend on as a key part of the interface. Even modern devices that work via the firmware updates we did, do so as a result of their firmware supporting this archaic mode of operation. It's kind of "in between" SASI and SCSI-1, strandards-wise..

 

There's also the fact that it isn't a legal PBI device and hogs the PBI interface almost exclusively..  

 

Let's see.. The original ICD design has pitifully inadequate heat dissipation on the power circuits..  The rectifier diodes cook themselves, along with the PCB..  ESPECIALLY on 1meg models.. 

 

I'd much rather have a device that works with ~90% of storage devices you can plug into it... Doesn't need to be fine-tuned based on bus load/capacitance/timing skew in order to reliably operate in a system with other expansions.. Can actually work with other PBI devices on the same bus...   Is not a fucking HEATER....  

 

It was fun to play with back in the day when we didn't have much better/cheaper options. Now, it's a collector's item.. 

 

 

 

[ICD Multi I/O]

Yeah. We don't build those any more. At the time we did, there were very few mass storage solutions available for the ATARI 8 bit. Now there are many that are much cheaper and better in every way than an MIO. 

 

Here are a few: 

https://lotharek.pl/products.php?id=41

 

https://www.vintagecomputercenter.com/

 

 

 

 

[Rescue on Fractalus New Computer Version:]

F*ckin awesome.. Took them 35 years to port it from Atari 8-bit to PC..  

Guess the PC hardware has finally evolved to a state that it can handle it. 😆 

 

Should port it BACK to atari 8-bit, but utilize Rapidus and VBXE..  

 

[Is Bob Out There? Still Kicking? 1200XL Guy]

Bob Wooley is tha man. 

[XL or XE Inside a 1200XL Case?]

You know.. 

After collecting my thoughts on this subject.. 

Here's what I will say, as I'm sure Flashjazzcat will agree, it's probably the most relevant point concerning this topic:

 

Alot of people have great love for the look, ergonomics, and keyboard of the 1200XL.. 

Years ago, you couldn't do things like "separate antic & CPU access to extended banks" in DIY mods without extensively additional wiring & assembly of discrete logic..

You certainly couldn't even dream of things like a meg of ram in 2 chips on a single small upgrade board that goes in any Atari with only a few wires to hook up. So back then it made a lot of sense to start with the motherboard that was closest to the "end product". 

 

Thanks to the huge increase in availability, economy, and scale of programmable logic devices, and the hard work of people like Candle, Lotharek, Mega-Hz, Simius, Flashjazzcat (and many others that I apologize for not mentioning,) the situation has changed tremendously in the last 2 decades.  There are quite a few easy options for these, and many other previously "formidable" upgrades these days. 

It matters much less which XL/XE motherboard you start with these days, from a mod installation complexity standpoint..

For me, the PBI is still the deal-breaker for the 1200XL board, but others may be happy with the alternatives that Flashjazzcat mentioned.   

 

And if you are willing to do a "motherboard transplant" then why not go with something truly bad-ass like the Eclaire XL? 

 

 

 

 

[XL or XE Inside a 1200XL Case?]

Kind of an irrelevant response. The point I was making was on the amount of internal wiring and clutter. Obviously you do have to have an exit holes for the stuff.  And I dont remember what stage that photo you posted was from, or even which machine, but needless to say, it can be "cleaned" up alot further. 

 

Jon, your the best coder Ive ever seen on the Atari. And your hardware work that I've seen is fantastic as well. I cant fault it.

But everything I stated above is still the truth. 

 

 

 

[XL or XE Inside a 1200XL Case?]

Oh yeah.. heh. And the U1mb and SIde will NEVER make PBI "redundant".. 

I strongly disagree with Flashjazzcat on that point. 

I understand that Flashjazzcat has an enormous amount of time and effort invested in those two upgrades, and without him, they would truly be TOTAL SHIT. He's done a wonderful job in that regard. I still would not have them in any of my machines. And that is a personal preference. I really don't want to start a debate on the subject here.  

 

[XL or XE Inside a 1200XL Case?]

1)I no longer have 4 of those machines.. Sold 2 of them. Still have 2. 

2)Connecting the keyboard is NOT a trivial matter. On the 1200XL, the decoders are built into the keyboard PCB. On the 130XE, they are on the motherboard. So this requires modification of one or the other for compatability. On mine, I chose to remove the decoders from the keyboard PCB and create something pin-compatable with the XE keyboard connector.

3)While I respect Flashjazzcat, I must disagree on the "superiority" of the 1200XL motherboard. That's a pure matter of preference. Personally, I like to use PBI/ECI devices. Also, the XE design has newer/better integration in the form of the Freddie IC. Also, you can get a 130XE in 64kx4 configuration which greatly reduces the load on the data bus and is a better baseline for an expanded machine from that standpoint. Yes all of this can be "modded" into a 1200XL motherboard, but It's alot nicer to start with somthing that is already there and thus reduce the final level of clutter and mod-wiring.. Just my preference.. 

 

ANywayze, if somebody wants one, I'd sell one for a very fair price. I have lately come to realize that I can only use 1 atari at a time, and that alwayze ends up being my Rapdidus/VBXE machine these days, so someone else might as well have this stuff if they will use it more than I will. 

 

 

 

[Sophia 2 preorder thread]

Aww Hell.. I guess I'll take a couple..

 

[Fall 1986 CMO Atari Brochure 16 pages]

Just like the title says. 

 

http://www.rasterline.com/cmo.pdf

 

I found this under a stack of printouts when I was cleaning out some junk. I'm sure someone else has probably already scanned this but no idea how to find it so here it is again.  

We should have a section for historical media. 

 

[XL Design Change Intent]

5 hours ago, _The Doctor__ said:

The 1090XL did re incorporate buffer isolation in one of the cable revisions, I'd bet Curt would have information on the cable... I'm thinking a girls name like julia or something attached to the nomenclature... Just best to put the buffer back on the mobo though...

Not even remotely the same thing. 

[XL Design Change Intent]

God, this question has been asked a million times in here. I bet I've written 50 pages on it personally.. 

 

The 1400XL and 1450XLD machines were the last to have a buffered data bus between the CPU and the hardware. The original PBI expansion bus and the 1090XL both depended on this design feature/characteristic in order to have some semblance of stable operation. When it came time to actually bring machines to market, in the early 80s, many "cost cutting measures" were implemented in the design before the actual production machines (1200xl,600xl,800xl)  came to market. One of these was the REMOVAL of the buffers on the data bus. Instead, all hardware bus traffic would be directly synced by the PHI2 signal from Sally. This is fine as long as your bus capacitance is finite and known.. Which it can not be, when there's a possibility of plugging many devices directly onto the bus, as in the case of the PBI (and cartridge too, actually). So what we ended up with is a machine that, although the physical connector was still there, could never run an architecture of parallell bus expansion reliably. Atari essentially made a decision to abandon the possibility of bus expansion in favor of getting the XL series to market at a price point that they felt the market would bear..  Sad but true.. This is why the only device ever actually sold by Atari to utilize the PBI connector was the 64k upgrade for the 600XL. 

 

Aftermarket developers, however, chose to utilize the PBI bus for various interfaces such as the Supra, ICD MIO, and CSS Black Box..  But if you know anyone who has owned these, they usually require "fine tuning" of the bus timing on the machine in order to operate with any degree of stability. In fact, the more things you hang off of the data bus in general, the more phi2-to-bus timing gets skewed by increased capacitance (and thus propagation delay), and it will cumulatively cause the machine to become irrattic/unstable/unoperational unless appropriate hardware measures are taken to compensate and bring the bus timing back into valid sync with PHI2. 

 

This includes internal expansions that plug into chip sockets, cartridge based expansions, and PBI devices.  The more crap you hang off the bus, the worse it gets. And once you get a heavily expanded system like that "tuned" for stable operation, any major changes (such as removal of a cart or PBI device) often throw it "out of whack" the opposite way because now you've reduced bus capacitance/propagation delay. So you've got to "retune" again. 

 

This "tuning" can be done in a variety of ways. These range from the simple addition of capacitors on bus lines to slightly increase delay, to shortening/lengthening of entire bus interconnect cables, to complex compensation circuits. MANY hardware people in this hobby have devoted untold hours to this problem. Unfortunately, short of redesigning the XL/XE machine spec, there is no universal fix. And without that, a 1090XL like device, while not impossible, is really "asking for it" in terms of installation specific troubleshooting and "hair pulling".. 

 

 

Whew!

I hope this is the last time I have to explain that. But it probably wont be.. 

 

Short answer to your actual question:

regardless of which type of interconnects you use, internal, external chain, external back-plane ala 1090xl...   For extensive parallel bus expansion, you need reliable bus timing.. The original 1400xl/1450xld designs had this. The apple II has this..  Machines like the production atari XL/XE, the commodore 64, etc.. Do not..