sup8pdct

I'm not sure... but is this on an atari XE which has the ceramic capacitors on the SIO bus? I have had same issues with other sio devices on that XE. Once I removed those capacitors on the sio lines the problems appeared to be gone. But I'm not sure this is your problem... Greetz M. Mine is an XL, and just to make sure it wasn't that machine, I connected a 2nd xl and the same thing happened. So there is still an issue. tracking this one down will take some time. James

It is rather odd this error. first time it boots up, things appear to be fine, but after a while it will start to play up to a point where doing a directory listing will have the timeout happen. At least with the BlackBox, the timeout is short. without the Blackbox, the timeout is so long, I gave up. James

While digging through the rom, I found 1 2K block to have a little message in it, It says: Please turn Dipswitch #2 off. Thanks. So no harm is done if Dipswitch 2 is on but the BB will always boot up with that message till it is Off James

Have you tried it with SpartaDos 3.2D? mine keeps timing out once dos is loaded. ie load several sectors, wait till timeout value in seconds is reached, load more sectors etc. Real PITA. was burning a new BB rom at the time. took 10 times longer then what it should have doesn't seam to affect SDX however. Haven't tried it with RealDOS yet tho old version of firmware did have same problem. James

Yes indeed. works a treat. Tried everything except the floppy formater, but went into it to see so it should work. James

Update. The Pigwa site only has Old versions. I managed to assemble a complete rom from Mathy's site despite 2 missing parts. While pulling apart my rom to see how it was assembled with the intent of sending a file to mathy to get the complete image, I discovered 3 blocks of code are the same 2 of which are the missing ones. Simply copy bbpg11.bin twice and rename them to bbpg00 and bbpg10. Assemble the parts in order and you have the rom image. James

I am in need of the above. Mine is at 2.11. it is fully optioned with Floppy board etc. I know Mathy's site has it BUT it is missing 2 parts. Thank you in advance. James

There is a new firmware release that should fix those problems. Have noticed an improvement for Sparta dos at least. James

Not quite true. Atari in there own wisdom made the 1064 so that the upper 48K only is usable. the first 16K uses internal ram. then it switches to the 1064. Also I must add here that 5V is available only on the 600XL PBI to power the 1064. So the 1064 is ONLY for the 600XL I knew someone who had this combination, it wasn't the most reliable. James

I have done this about 17 years ago to a friends unit. I used the Zip chips and an eprom and several small caps. MANY holes need the solder to be removed. just as many holes need to be re soldered with chips in place. Getting the $%$$ stable again was the hardest. All I had was a multimeter with a logic function. I found that by placing the probe on places making it slightly more stable, i placed a cap there. Finally got it but it still was a bit temperamental at times. Not the method I would recommend. James

You'd actually only gain 6k by doing that... My hardware skills aren't up to scratch either.............. James

Well, Im very familiar with the MIo source code.. Its fairly well organized, and fairly tight coding.. But let me tell you this.. All the information needed (or used in the function of the firmware) is right there in plain simple black & white in the MIO users manual. Anyone who wanted to write their own utilities to manipulate the MIO has been free to do so since 1986, and with the exception of a few menial sparta utilities here and there, it's never happened. Anyone (with an EPROM burner) could have written alternative firmware for it as well, and that's never happened.. I plan to totally rewrite the firmware, and to be honest, I don't think I will end up using much from the original code, if any at all.. But for historical sake here are the firmware versions that I have personally seen source code for: v1.1 - This is the actual production release version source. Noone has this.... (or do they? heheh) fake v1.1 - This is actually v1.3beta which has had the header & filename changed. fake v1.2 - This is also v1.3beta which has had the header & filename changed. v1.3beta - This was a version that never got released. It was v1.1 with some attempted minor improvements. It does not build a stable rom, and many of the routines dont function correctly, even when you change it so that it can be assembled into something stable. v2.0beta - This is another nonreleased version of the base firmware, with some attempted minor improvements, and also some changes made to facilitate the extra 8k of "80 column board" firmware, which is also included in this version... A 1) I want to redesign the firmware to so that it loads the USER CONFIG program from the first 64k of hardisk space on MIO COLD INITIALIZATION, along with the configuration variables. The USER CONFIG program will be stored in the first 64k (256 banks) of MIO internal memory, and copied to ATARI memory as needed, when needed.. This will free up the 4k of our precious ROM space that the current USER CONFIG program occupies. This will allow us to use this additional 4k of ROM space for improved SCSI code, and device handler code which is executed when the MIO devices are actually being accessed. 2) If possible, I would also like to implement a system similar to the one the black box uses, which uses some key combination (other than RESET) to enter the USER CONFIG PROGRAM, and saves the current contents of the ATARI memory by copying it to MIO RAM, and replacing it apon exit of the USER CONFIG PROGRAM. This would involve copying the ATARI memory space occupied by the USER CONFIG PROGRAM, as well as the state of all relevant system regsiters/variables, etc.. A system like this would also require the installation of some sort of "hook" on each system reset.(to watch for a key combination that triggers the USER CONFIG MENU) This feature would allow you to enter the USER CONFIG PROGRAM from any application, and be returned to that application seamlessly apon exit (instead of having your application halted and being returned to DOS or BASIC which is the case with the current firmware) 3) Id also like to add the ability to have more hardisk & ramdisk partions set up than Dx: designators and assign them on the fly(Like the Black Box). The config/partition table for this feature would be stored on a section of the boot hardisk and reloaded on MIO COLD initialization. 4) Once all that crap is done and implemented, maybe THINK about adding some utility functions like a hardisk formatter, sector editor/copier, hardisk defrag, or even a Norton COmmander style file-manager system.... THINGS to think about: This new firmware system would require an MIO UTILITY DISK program that copies the USER CONFIGURATION PROGRAM into MIO RAM for the first time.. Once its in the MIO RAM, it would be available to the user. A "PREP SYSTEM DRIVE" function (of the actual USER CONFIG PROGRAM) would then allow it to be installed in the appropriate place on the hardisk, along with the correct organization for config data, and the hard/ram disk partition table... For users without a hardisk, Theyd simply have to run the utility program after each MIO cold start to load the USER CONFIG program into MIO MEMORY for the first time.. This shouldnt be a problem because whithout a hardisk, these people will be booting from floppy (or ATR image) anywayze.. And once its loaded, it's good until the next time you actually remove power from the MIO.. This utility program would be a simple command line executable, and could even be put into your STARTUP.BAT on your favorite OS boot floppy (or .ATR)... Whew.. Im tired of typing.... This is all completely open to discussion... I welcome all ideas... Also anyone who HAS an MIO and wants to help with the development / testing of this will be gratefully welcomed.. Very good idea's. What about soldering a wire jumper from pin 15 of U2 ls175 to pin 26 of the rom to give ya 8K of space to play with? Unless that space is planned for some expansion of some sort. I could help with testing but my MIO doesn't want to work, rom wise. ram works very well. My development skills would be what some people may call 'backwards' I can write code ok but getting things tight and fast would be hard for me and getting my head around the hex and binary maths is the part that is backwards...... James

Yea. what data sheet is that speed listed on? I have looked at 3 and max speed is 19200 with standard crystal. the MIO has a 1.8xxx speed crystal so no speed advantage there. unless you plan to change the crystal either on the fly via hardware or install a different crystal in new versions. James Look at the baud rate setting... And look what happens if you set all 4 bits to zeros... The Apple II also uses a 1.8xxx crystal.. and Im here to tell you, it DOES work at 115k.. With bits 0-3 of the control register all set to zeros, the baud rate is the external clock (divided by) 16.. The MIo uses a 1.8432mhz crystal to clock the 6551.. (as does the Apple II)... 1,843,200 / 16 = 115,200... bits per second... Ahhh, that end of the table. I was looking at the fast end, not the slow end. I see it now. Must find those glasses I never owned and wear them.......... James

I can add that the benchmark dumps 4x16k from the memory to a file, and then reads the file back. And, obviously, a hard disk is (or at least should be) faster than the internal ramdisk, for the reasons explaine. Although the buffer, in fact, can be avoided, or strictly speaking reduced to 1 byte which fits in the accumulator. But the hard drive will (should) still be faster, because either no buffer or no bank switching is necessary. The harddisk read/write speed all depends upon how the interface has been designed. if it has its own precessor then I would expect a fast interface but I don't know of any . A interface that uses the 6502 do do all the work will have a transfer overhead and device command generation and handshacking which takes time. James

Sorry I missed all of this debate earlier. The BB whn using 512 byte sectors buffers the 2nd half of the sector if the first 1/2 is read first. if the 2nd half is required, it comes from the buffer. The drive editor uses ram so recovery of what was running prevous isn't possiable. The drive editor also has a bug. try copying a whole disk from floppy to floppy writing blank sectors. the program stops after writing a blank sector before a full one and times out. very annoying. Wanted to use that to backup all my floppies and HD to sio2pc but couldn't James

Yea. what data sheet is that speed listed on? I have looked at 3 and max speed is 19200 with standard crystal. the MIO has a 1.8xxx speed crystal so no speed advantage there. unless you plan to change the crystal either on the fly via hardware or install a different crystal in new versions. James

I did my tests comparing loading pictures one after the other, The MR 'T' demo that loads from disk. A more real world application. The MIO was about twice as fast comapred with internal ramdisk. Think about it for a minute. Say the pics load from $6000 to $67ff. The internal ram disk cannot copy data directly from a banked ram to the main bank so some form of bufffer must be used or a lot of bank switching is used just to copy 128/256 bytes. That means copying data twice. The MIO ramdisk can copy data directly to destination with out the buffer. only once so there fore twice as fast. What ever was used to get those benchmarks, did it take into acount the window area? or was it just getting the same sector over and over? James

As it stands, the MIO provides the following. 1) scsi/sasi interfave used mostly for Hard drives. 2) parallel printer interface compatible with PC printer cables. 3) 64K printer buffer (default) tho that size can be set to any size upto the limit of ram on the mio 4)RS232 serial interface capable of 19200 baud. 5)extra ram used as disk drive. This is the fastest drive on the 8 bit, bar none. depending on the size of ram, a 1 gig drive can be set up. The ram can be broken in to 8 parts to emulate 8 floppy drives if you want and the ability to boot from them. I have setup bootable games on the MIO and the speed they load at....... From my under standing, future expansion plans include. ability to address 16 meg of ram. Just think, fastest drive at 16meg. niiiiiiiiiiiice. Plans for a 80 coloum display board. Updates to firmware to include support for more scsi devices including cd roms James

Nice! Do you have the specs to this upgrade? it is a plugin board for the rom board. it has 2 static ram chips , eprom and several LS logic chips to partialy emulate port B of the PIA. write only. and then is the bit for os roms on/off only. read and write of port B will get/put data from/to the real PIA. It has os rom Rev B with SuperMON. It has 2 switches, Supermon on/off and XL ram emulation on/off still with RevB os. The emulated xl os has been patched slightly to prevent the roms from being switched off. The XE ram emulation requires Superram 800. several tracks need to be cut and a 4pole double throw switch required. A wire from the rom addon board is required to emulate the xe ram. I have patched the XLrom to have 4 joysticks and 8 paddles to work with 800 xl emulator and tried it. SDX saw the 800 as if it was an XE Adding boards to the os and ram boards makes for a tight fit. I still have the bare boards here tho I need to find them again and remember what chips go where. James

I would like some cards to go into my 1090XL and a top cover. 1450XLD 65XEM 65XEP 815 800XE would be nice. Bitwriter for my 1050 archiver Bit3 80 coloum board for my 800. James

Byran. Talk like that may have your house raided by my special forces unit looking for rare and exotic contraband James

800XL with supermon and super ram, cold start switch and an extra switch that toggles RA9 line for some very special hacking. 800 with super 800-xl upgrade and superram with xe like mod. 800 with John Nickoles monintor. Never seen outside of australia. Uses bank switching to map 8K monintor into 4K 1050 that started life with supermax and superled. now has supermax replaced with superarchiver. 800XL with Printmon and Printmon interface and with superram 800XL with rambo ram upgrade. (bought that way) 1050 with happy. (bought that way) xf551 duel drive upgrade xf551 with xf update (usd compatible) and xf enhancer 600XL with 64K internal oss cart with Basic XL, XE, Mac/65 and Action all in one. 2 atari carts with 16 8k games on one and 8 16k games on the other. selectable with dip switches Indus GT with an extra switch to write to the back side of disks without a notch. 810 with archiver chip and write protect switch James Think that is all the hardware mods

Marius I have just tested my SIO2USB with my BlackBox loading Yellow dos (dos2 with a different Dup.sys) and it loaded fine at highspeed. Have also tested writing to sio2usb with the blackbox hs routines with out problems when I was fault finding SIO2USB (16meg in one hit) So my Blackbox is compatible with SIO2USB. I cannot think of what is going on with yours. Are you using a NTSC atari? does it have a PAL antic? Maybe your pokey isn't quite up to it. James

Well, I hope for updates from you. The SDX doesn't use the command, as far as I know. Will try to make sure they are correct then.. I remember trying SDX formating the indus after the syncro load, and from memory it did work. That was a long time ago so memory my be a little lacking........... James

I must test my BlackBox with SIO2USB. Must get my digit out to do so. Carsten, do both of those dos's have there own highspeed SIO routines? If they do, it could be that the BB routines aren't used except for the Harddrive. A good test would be to use Mydos. Just a thought James