sup8pdct
-
Content Count
935 -
Joined
-
Last visited
Posts posted by sup8pdct
-
-
Hello JamesSo you've got 2.16 running succesfully on your BlackBox?
Greetings
Mathy
Yes indeed. works a treat.
Tried everything except the floppy formater, but went into it to see so it should work.
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
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
-
For the people who were not able to see the movies...Compare the two mp3's.
Summary:
Sio2USB has trouble with BlackBox HighSpeed loader. You hear this in the sio sounds. Because of this, it is slower than it should be, and sometimes other problems occur due to this.
The two files:
File 1: SIO2USB (DOS_25.ATR) + BLACKBOX. Listen to the sound. The problem is clear.
File 2: SIO2USB (DOS_25.ATR) + Qmeg. Listen to the sound. No problems here.
Greetz
M.
@CAS:
Are you positive that you used the Standard Atari OS in Beetles computer? this problem happens when you use the HighSpeed Sio driver in BlackBox in combination with Standard Atari OS.
There is a new firmware release that should fix those problems. Have noticed an improvement for Sparta dos at least.
James
-
Dude, the 64k interface for the 600XL DISABLES ALL MEMORY inside the machine by keeping /EXSEL asserted at all times.. Its not a PBI device.. It does plug into the same connector as a PBI device..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 the docs for this upgrade which was written by Rich Mier (SPACE), and although the author advises against trying to do it, says that it works. This upgrade uses 1 Mbit DIPS and desolders the original ZIPS from the board. There are also no pics with my docs, so this looks like a pretty "hairy" upgrade. Has anyone here attempted this upgrade?I'm also curious if anyone has upgraded one of these by populating the pcb with additional ZIPs or seen any docs for doing this type of upgrade? Parts cost would be higher and certainly the operational heat load would be higher, but seems like it might be a lot easier. (?)
Why would I want to do this? Well, I have two fully-working 256KB MIO's sitting in a box...
Thanks,
Larry
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
-
...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?
...
You'd actually only gain 6k by doing that...
My hardware skills aren't up to scratch either..............
James
-
Whatever Steven has, is a hell much more than all the rest of us have, which is zero, nothing. It would be a great service to the community if he would agree to release the sources. If they are usable or not, that's a minor issue. The greatest value of such a thing, is for historical purposes....
Honestly, I'm amazed to hear that many people have different versions of a document, that until recently, we thought it was lost forever. When you hear that, you start wondering if there aren't other people holding other invaluable historic documents, sources, schematics, etc, in secret.
...
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
-
1.) The 6551 UART (used in the MIO and BLACK BOX) is capable of 115kbps serial operation. If you dont believe this, look at the datasheet, and then ask Apple II users who do it all the time (Its implemented the exact same way in both of the apple IIc serial ports, as well as the Super Serial Card for the IIe/II+ as it is in the MIO and Blackbox. even clocked at the same exact frequency, but the Apple hardware doesn't even have the handshaking lines connected!). This amounts to a simple and minor change to the serial handler (ROM).. You totally cant compare a P:R connection, Rverter, 850 interface, or any other SIO connected serial port solution to the MIO or BLACK BOX serial ports..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
-
Drac030's RWTEST was used for all those tests. The benchmark test is athttp://drac030.krap.pl/en-inne-pliki.php
But a somewhat different test than you describe. Drac030 explained in the ICD Multi-I/O thread:
" The program works as this:
1) open the file for write
2) get clock state
3) write, write, write, write
4) get clock state
5) close
6) calculate & display the result
And the same for reading."
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
-
1.) The 6551 UART (used in the MIO and BLACK BOX) is capable of 115kbps serial operation. If you dont believe this, look at the datasheet, and then ask Apple II users who do it all the time (Its implemented the exact same way in both of the apple IIc serial ports, as well as the Super Serial Card for the IIe/II+ as it is in the MIO and Blackbox. even clocked at the same exact frequency, but the Apple hardware doesn't even have the handshaking lines connected!). This amounts to a simple and minor change to the serial handler (ROM).. You totally cant compare a P:R connection, Rverter, 850 interface, or any other SIO connected serial port solution to the MIO or BLACK BOX serial ports..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
-
Hi James-Well, almost the fastest... The XE internal ramdisk is slightly faster, but not by very much. And the KMK/JZ interface is faster using SDX with 512-byte sectors. Check out the the last page of this thread where all the benchmarks are summarized:
http://www.atariage.com/forums/index.php?s...26074&st=40
But there still may be some "apples to oranges" in these numbers. The MIO is still a killer piece of hardware -- just wish I'd gotten a 1-MB instead of 256-KB. But at the time I bought mine, there was a "ram shortage" and the 1-MB's were out of sight. Good as the BB? Maybe not quite since the BB has such good firmware. IMO, of course.
-Larry
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
-
It's good to know many Atari users are interested,... but until now, I don't understand what is a MIO.I have the idea is a device that provide SCSI ports to the XL, XE series using the PBI port. So, I see, the useful thing is that I can use SCSI HDs, printers on it.
Is there other advantages I am losing? For example, all this memory on the MIO is only for buffer purposes or it works like an memory expansion?
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
-
800 with super 800-xl upgrade and superram with xe like mod.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
-
Is good to see someone actually reading my sometimes correct comments in the listing
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
-
Hallo Marius,I have worked (=programming) on Friday about 3 hours on Beetles 1450 XLD with Blackbox and my SIO2USB. I have copied data several times between SIO2USB and the Blackbox Harddrive, always with Highspeed. I not have seen any issue or failure. It just worked like a charm. I have used BEWE DOS 1.30 and REAL-DOS 2.4.
Best regards
Carsten
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
-
Must look for that key combo tho i would have thought that would have been a bit of extra code loaded to the indus when one loaded the terminal program for indus cpm.No, this key combo works even when nothing was loaded before. It loads the sector 1 to the drive's RAM (at $7F00) and jumps there to execute the code. Obviously it can be used to boot anything, not just CP/M.
As about the verify error, yes, I noticed the comment in your listing. So there'a at least one thing to fix already
The bad thing about the $23 Synchromesh command is, that the opcode is the same as DSDD formatting in the XF551.
The things one learns. I must look for that code that does the loading.
Is good to see someone actually reading my sometimes correct comments in the listing
As for the Command, At least SDX is smart enough to know the difference.
The High bit is set anyway, so it may not interfere with the XF.
Don't know of any other dos that can talk to the indus and XF at highspeed, so that problem may never arise anyway
James
-
In the Indus field service manual, the main circuit board is referred to as the WART board.
Guess nothing much has changed...
James
-
I have disassembled the IndusGT V1.2 rom , the Syncromesh code, the ramCharger code and the loader for both.I have put some comments to things I have worked out but it still needs work. (very big HINT)
The version Number of the rom is also stored at $CF5 for V1.2.
The SDX version of syncromesh excludes the ramcharger code and some changes are made to the loader as noted
Any comments, please let me know.
Have not checked if it will assemble yet.
James
Something I forgot to Add.
The write with read verify doesn't actually verify properly.
It checks the first byte only by the number of bytes in the sector.
You can see it starting at 2BB and 7C5A in the syncro code.
James
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
New SIO2USB Production run
in Atari 8-Bit Computers
Posted
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