NEW MIO production run.

[drac030]

$D510 LDA #data

$D512 STA somewhere

$D515 BVS $D510

 

Now we have 11 cycles per byte which is well over 100KB/s.

 

I see 9 (2+4+3) cycles here, not 11. Slightly over 11 is doable without these tricks (by loop unrolling), and in KMK/JŻ/IDEa, which is not so clever (it has little hardware support for this, actually) the rate is 25 cycles per two bytes, i.e. 140 KB/s, but one has to subtract the CHS calculation overhead, the disk overhead, and also the ANTIC steals something, and so I never saw a better result for a raw transfer than 100 KB/s.

 

By the way, the line that sets the V flag of the CPU is not present on any external connector (PBI, ECI, Cartridge), so this solution can't be used in an external interface.

Edited August 19, 2008 by drac030

[ijor]

Theres alot of people who have various MIO source code versions... The ones Steve has dont even build stable working ROMs.. They do give some kind of idea how things are being done though..

 

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.

 

And if they are indeed lots of people with sources for different MIO versions, then please release them all! I would be happy if at least one of them would be made public.

 

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.

 

May be somebody has a collection of sources for all Sparta versions (guess Drac030 would love to see them). May be somebody else has the source for the XL Rom (for the one actually released in the 800XL). May be somebody has the source/schematics/netlist for (insert your favorite Atari product, part or component) that we all thought it was lost.

 

So not only that the community is missing the documents, it is also seem to be missing the fact that many aren't really lost. They are lost "only" to the public.

Edited August 20, 2008 by ijor

[ijor]

Actually, I think that an interface with own CPU may actually be slower than the one without, because own CPU = (one more) intermediate buffer for data between the disk and the computer. Plus, you of course fall into temptation of tranferring data from that processor to 6502 in 8-bit portions (instead of 16-bit in case of IDE), and this also reduces the speed a bit. I don't know for SCSI, but for IDE there is little overhead in command generation, except that in CHS mode you have to do two divisions, and so to reduce the overhead imposed by this, your divide routine must be really fast. Using an interface with own fast CPU solves this, but other things I said above still apply (and there is no difference in handshaking in this case). To avoid divisions you can use LBA, but not every drive supports this mode (sure, new drives all have LBA, but relics like Seagate ST-225A do not).

 

Unless you want to do WIDE SCSI, (which would require a different hardware, connector, etc) SCSI is 8-bit. The overhead for SCSI is also pretty small, and LBA is the only available mode.

 

SCSI is pretty complex when it comes to initialization, configuration, detection, etc. But then you do that only once (if at all, most of that stuff is optional), so you don't care too much.

[MEtalGuy66]

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...

 

Anywayze, I have heard of several people who have this source code, many of which did development work for various third party applications back in the day whose "OS of choice" happened to be SPartaDOS.. I get the idea that ICD was pretty open about releasing source to developers, in order to facilitate and increase incentive for [development for/support of] their products. Some random person emailed me not too long ago and made reference to ALL of the above referenced source versions, offereing to give them to me, in exchange for credit towards an MIO board. I told him I already had access to the source, and that he'd have to wait until after I finish the preorders, and he could buy one like everyone else.. And from his email, I did NOT get the impression that this guy was any kind of "ICD Insider"... He was just some "average joe" who happened to know a few people back in the day..

 

Now.. Let me tell you why this is totally useless to us....

 

a) Everyone has the production ROM binaries already...

b) Theres less than 16bytes free in each 2k bank of the ROM, and this is not enough space to implement any siginficant functional improvements without deleteing other features of the firmware..

c) We are not going to change the MIO hardware spec to increase the ROM size, as this would not be compatable with original ICD MIOs..

 

Here is what we ARE going to do about it...

 

Or at least what I would LIKE to see happen...

 

Before we can discuss strategies for improving the firmware, we must discuss the nature of the current firmware and hardware..

 

The MIO is a group of hardware devices connected to the PBI/ECI bus of the atari. It includes a SCSI/SASI hardisk interface, a 6551 UART based RS232 serial interface, and a (somewhat) standard paralell port interface. It also includes anywhere from 256k to 16megs of on-board DRAM. (for our purposes here, we'll assume 1 meg of installed MIO memory).

 

The MIO's internal memory is "kept alive" as long as the MIO is powered on. Various configuration & firmware operation variables are stored in the first 256 byte bank of the MIO's internal RAM. So.. When the ATARI is powered up (or hard-reset), the first thing that the MIO firmware does is examine this "config area" of the internal RAM for an arbitrary 16 byte "validation key"... If it see's this key, it assumes that the MIO has not been powered off since the last reset and it uses the configuration as stored.. If it does not see the validation key, it first checks for a valid device on SCSI/SASI ID 0... If it finds one, it attempts to load the config data from the first sector of that drive.. If it does not see a device on ID 0 (or the config data loading process is unsuccessful,) it initializes the "config area" to default values (as set up in the firmware) and continues...

 

The next thing it does is check to see if [sELECT] is being pressed.. If true, it loads the 4k configuration program (which takes up two 2k ROM banks) into the ATARI's memory, and executes it. This program provides the User Interface for changing the configuration variables which, as stated before, are stored in the first 256 byte "bank" of the MIO's internal memory. It also allows the user to "save config" which copies all of the configuration variables onto the first sector of the hardisk so that they will be reloaded the next time that both the ATARI and MIO have been powered down and restarted.

 

This configuration data contains settings/definitions for all Dx: device mapping, Serial Port settings, Paralell port settings, Print spooler settings, MIO RAM partitioning/allocation and assignment to Dx: designators, etc. These config variables are used by the handler code which is executed out of firmware each time one of the devices on the MIO is accessed.

 

If [sELECT] was not pressed (or apon exit from the USER CONFIg PROGRAM), it maps its devices according to the config, initializes its handler states, and returns control to the OS for booting.

 

Here is how the firmware is currently organized in the ROM:

 

2K BANK #1: MIO initialization rotuines, serial handlers, paralell port handlers, serial/paralell printing/print spooler operational routines, etc.

 

2K BANK #2: SCSI code, RAMDISK initialization code, USER CONFIG PROGRAM loading & initialization routines, etc..

 

2K BANK #3: USER CONFIG PROGRAM

 

2K BANK #4: USER CONFIG PROGRAM

 

We are wasting half of the ROM space that could be used for improved device funcionality on a USER CONFIG PROGRAM, and this program leaves alot to be desired in flexibility and user friendliness.. Given, it's pretty good for 4k... But we have got a MEG of ram, and an entire hardisk at our disposal..

 

Heres the main idea:

 

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..

Edited August 20, 2008 by MEtalGuy66

[sup8pdct]

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

[drac030]

May be somebody has a collection of sources for all Sparta versions (guess Drac030 would love to see them).

 

Much more I would like to talk to the original Sparta X developer, as there are traces of some ideas in the code, which haven't been implemented. Such things can be now made, but first I would like to know what the original idea was behind this and that.

 

For example, there is a subsystem called BLOCK_IO, its even mentioned in the user's manual. It has 5 functions defined, and all of them are called by the filesystem driver, but only three are actually implemented. What was the projected purpose of the remaining two, I can only guess (and I do).

 

Also, it seems that it is not an accident at all, that SDX is so similar to MS-DOS. From some parts of the original code one can have thoughts that it originally might have been an actual MS-DOS clone. For example, in 4.22 the code of the SEEK function is totally brain-damaged (and it doesn't work well, we had to rewrite it), but, actually, its structure perfectly fits the method the SEEK should be implemented for FAT filesystem.

 

So, you see, I really would like to swap some mails with the original developer, whoever he was

Edited August 20, 2008 by drac030

[+bob1200xl]

OK... someone may have hardcopy of some of those things but how do you distribute it? You're looking at a whole lot of "stuff" and a LOT of work to turn them into something electronic that can be distributed. If you had source for DOS 2.5, for example, would you send it off to 'someone' so they could scan it? And, who is going to stand up and be a target for the lawyers?

 

I do happen to have a copy (on diskette) for DOS 2.5 source. Bill Wilkinson sent it to me so I know it's OK. What should I do with it? Where do we keep such things? Can we set up an upload site for source or something?

 

You can't assume that we all know these things.

 

Bob

 

 

 

Theres alot of people who have various MIO source code versions... The ones Steve has dont even build stable working ROMs.. They do give some kind of idea how things are being done though..

 

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.

 

And if they are indeed lots of people with sources for different MIO versions, then please release them all! I would be happy if at least one of them would be made public.

 

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.

 

May be somebody has a collection of sources for all Sparta versions (guess Drac030 would love to see them). May be somebody else has the source for the XL Rom (for the one actually released in the 800XL). May be somebody has the source/schematics/netlist for (insert your favorite Atari product, part or component) that we all thought it was lost.

 

So not only that the community is missing the documents, it is also seem to be missing the fact that many aren't really lost. They are lost "only" to the public.

[ijor]

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:

...

Now.. Let me tell you why this is totally useless to us....

 

a) Everyone has the production ROM binaries already...

b) Theres less than 16bytes free in each 2k bank of the ROM, and this is not enough space to implement any siginficant functional improvements without deleteing other features of the firmware..

c) We are not going to change the MIO hardware spec to increase the ROM size, as this would not be compatable with original ICD MIOs..

 

Ken,

 

There are two separate things. One is the historical value of the original source. Many people consider this kind of stuff invaluable, regardless of how useful or useless it is for practical purposes.

 

I fully agree that is not that difficult to reverse engineer the firmware from the EPROM. I also agree that given complete hardware specs, you don't even (necessarily) need the original firmware at all.

 

But no reverse engineering can restore the original commented source, I am sure you would agree with that.

 

We are wasting half of the ROM space that could be used for improved device funcionality on a USER CONFIG PROGRAM, and this program leaves alot to be desired in flexibility and user friendliness.. Given, it's pretty good for 4k... But we have got a MEG of ram, and an entire hardisk at our disposal..

 

That doesn't sound as a bad idea at all.

 

Much more I would like to talk to the original Sparta X developer...

So, you see, I really would like to swap some mails with the original developer, whoever he was

 

There was a thread some time ago about who was the developer. I'm afraid I don't remember if it was here or on the Usenet newsgroup. May be some search and googling could help.

 

What I do remember is that, according to info posted in that thread, it wasn't Mike Gustafson. I understand he developed the first versions of Sparta DOS. But later on, when SDX was released the company was much bigger, and he was probably more in the role of technical lead (CIO, CTO) of ICD, than directly developing.

Edited August 20, 2008 by ijor

[MEtalGuy66]

...

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...

 

 

If you notice, D5 is already being used to select bank 3... The inverted outputs of D2-D5 are used to enable/disable the ROM..

 

You see, in the current configuration, the state of d5 is "implied" to be "1" if D2-D4 are all "0", but D2-D5 are not "all 0" This is how bank 3 of the ROM is accessed.. Doing what you suggest would eliminate bank 3..

 

Below are some Crude tables showing which banks are selected by the states of bits 2-5 of $D1E3/$D1FF

 

Current configuration:

 

Bank 2

1000

1001

 

bank 4

0100

0101

1011

1010

1110

1111

1100

1101

0110

0111

 

 

bank 1

0010

0011

 

bank 3

0001

 

ROM DISABLED

0000

 

 

What you are talking about (using D5 to control the state of A13 of the 27128):

 

Bank 2

1000

 

BANK 6

1001

 

bank 4

0100

1010

1110

1100

0110

 

bank 8

0101

1011

1111

1101

0111

 

bank 1

0010

 

bank 5

0011

 

bank 7

0001

 

ROM DISABLED

0000

 

And as I said before, I dont plan to change documented hardware specs of the base MIO...

 

The expansion board will incorporate logic to fully decode all existing MIO registers, and correctly add additional registers without hogging up more adress space. It will most definitely have the ability to access aditional ROM space. In fact, it will probably have its own (larger) on-board ROM (or flash) that overrides the one on the main MIO board, and contains all of the handler code for all of the hardware on both boards.

 

But for now, we are trying to improve the base firmware before we adding any additional hardware specs.

 

If we are going to (eventually) have a single USER CONFIG PROGRAM that will work with or without the planned expansion board installed, the best thing to do (I think) is to include the hardware handler code in ROM and have the USER CONFIG PROGRAM check for the presence of the additional ROM to determine whether the expansion board is there or not. For now, we are just concerned with the BASE MIO.. The kewl thing about having a disk/ram based USER CONFIG PROGRAM is that we can expand it at a later date, when the expansion board is finalized. This way we can go ahead and make the original MIO "Be all it can be"...

Edited August 20, 2008 by MEtalGuy66

[ijor]

OK... someone may have hardcopy of some of those things but how do you distribute it? You're looking at a whole lot of "stuff" and a LOT of work to turn them into something electronic that can be distributed. If you had source for DOS 2.5, for example, would you send it off to 'someone' so they could scan it? And, who is going to stand up and be a target for the lawyers?

 

I am sure there are lot of people that hold historical "stuff" without meaning bad. As you are saying, some might have technical difficulties, some might be reluctant for legal reasons. And probably some people don't even know that they hold stuff that the Atari community would consider invaluable. Others might have more selfish intentions, but I am not in the position of judging anybody.

 

You certainly fall in the first category (the good guys ). I personally think that also Steven, the one I thought was the only one having MIO sources, doesn't mean bad. And I'm sure whoever gave all those MIO sources to Ken, ask him to not make them public. So I am definitely not blaming anybody here.

 

I do happen to have a copy (on diskette) for DOS 2.5 source. Bill Wilkinson sent it to me so I know it's OK. What should I do with it? Where do we keep such things? Can we set up an upload site for source or something?

 

Wow ! Please post them here. Once you post such a thing here, most people mantaining archive sites would grab them and post it in their site. Or whatever other way you might prefer, it would be good enough.

 

You can't assume that we all know these things.

 

You are absolutely right. And that was precisely my intention. To make people aware how important is historical stuff for the community.

 

If somebody has technical problems, such as a big hardcopy, then please let as know. We always could find a way to overcome technical issues.

 

If somebody is reluctant for legal reasons, it might be more difficult. But please at least let us know and talk about it. In some cases there shouldn't be any problem whatsoever. I.e, if it is Atari copyrighted, you could send it to Curt in the wost case.

[MEtalGuy66]

Yep.. Im not worried about legal threats.. I just wish to maintain myself as a trustworthy individual, and not piss off the people who let me "borrow" the source for evaluation purposes. But as I said before, I've run across others who claimed to have the MIO source code, and appeared to know too much about it to be lying..

[+bob1200xl]

So... I have the two 5 1/4" Atari disks full of DOS 2.5 source code. First, I load up BobTerm on the old 1200XL...

 

and...

 

will this be Xmodem?

 

DiskComm, first?

 

Convert ATASCI to EBCDIC?

 

Maybe we could come up with an optimized format and process? Some kind of 'wrapper' we can use to keep these files in while they're unataried around?

 

Bob

 

 

 

OK... someone may have hardcopy of some of those things but how do you distribute it? You're looking at a whole lot of "stuff" and a LOT of work to turn them into something electronic that can be distributed. If you had source for DOS 2.5, for example, would you send it off to 'someone' so they could scan it? And, who is going to stand up and be a target for the lawyers?

 

I am sure there are lot of people that hold historical "stuff" without meaning bad. As you are saying, some might have technical difficulties, some might be reluctant for legal reasons. And probably some people don't even know that they hold stuff that the Atari community would consider invaluable. Others might have more selfish intentions, but I am not in the position of judging anybody.

 

You certainly fall in the first category (the good guys ). I personally think that also Steven, the one I thought was the only one having MIO sources, doesn't mean bad. And I'm sure whoever gave all those MIO sources to Ken, ask him to not make them public. So I am definitely not blaming anybody here.

 

I do happen to have a copy (on diskette) for DOS 2.5 source. Bill Wilkinson sent it to me so I know it's OK. What should I do with it? Where do we keep such things? Can we set up an upload site for source or something?

 

Wow ! Please post them here. Once you post such a thing here, most people mantaining archive sites would grab them and post it in their site. Or whatever other way you might prefer, it would be good enough.

 

You can't assume that we all know these things.

 

You are absolutely right. And that was precisely my intention. To make people aware how important is historical stuff for the community.

 

If somebody has technical problems, such as a big hardcopy, then please let as know. We always could find a way to overcome technical issues.

 

If somebody is reluctant for legal reasons, it might be more difficult. But please at least let us know and talk about it. In some cases there shouldn't be any problem whatsoever. I.e, if it is Atari copyrighted, you could send it to Curt in the wost case.

[sup8pdct]

...

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

[MEtalGuy66]

My hardware skills aren't up to scratch either..............

James

 

I thought it was a very relevant suggestion, and i'm glad you pointed it out..

 

The "rom bank 3" compatability issue really wouldnt amount to much since the firmware would have to be reorgnized/recoded anywayze.. and if all I hoped to do was improve the SCSI code, Id probably consider that a perfect solution.. But I really am serious about expanding the capabilities of the stock MIO as much as possible, and then going on to produce the expansion board.. And Id rather cut to the chase and work on something that can be a final solution (or evolving solution) rather than having several different "rom releases" for everyone to burn on eprom and worry about having the latest one..

 

Oh, and as far as your MIO being only 256k, thats actually excellent.. I hope I can count on you as a beta tester, at least...

 

When it's all said & done, the firmware will autodetect the installed RAM size.. So, if you ever wanna upgrade to 1meg, just drop the extra ZIPPs in.. But for testing purposes, a working 256k MIO is great to have, because it represents the extreme low-end of the installed DRAM spectrum, and we need to make sure it works in that configuration without issues.. The fact thats its an original ICD unit is even better, because I dont have a 256k original MIO here..

[kurtm]

Oh, and as far as your MIO being only 256k, thats actually excellent.. I hope I can count on you as a beta tester, at least...

 

When it's all said & done, the firmware will autodetect the installed RAM size.. So, if you ever wanna upgrade to 1meg, just drop the extra ZIPPs in.. But for testing purposes, a working 256k MIO is great to have, because it represents the extreme low-end of the installed DRAM spectrum, and we need to make sure it works in that configuration without issues.. The fact thats its an original ICD unit is even better, because I dont have a 256k original MIO here..

 

I've actually got a 256k MIO also. Originally I bought a 1 meg off someone, and it didn't work. So he threw in the 256k MIO for free, and if I could fix the 1 meg, bonus for me. Never did get the 1 meg working...

 

Although, I look forward to your service manual

 

I've actually never got around to putting a hard drive on my MIO, but I'd love to be a beta tester for you.

[Shamus]

So... I have the two 5 1/4" Atari disks full of DOS 2.5 source code. First, I load up BobTerm on the old 1200XL...

 

and...

 

will this be Xmodem?

 

DiskComm, first?

 

Convert ATASCI to EBCDIC?

I think you're overthinking this--all you'd have to do is make disk images of those floppies and let people who want to extract the source from them worry about the rest. I've written (as I'm sure many others have) utilities to extract files from disk images. It's really not a problem.

[MEtalGuy66]

Yeah Ive got a 1 megger here that someone took a heat-gun to... They repopuated the entire board with sockets afterwards (everything except the ZIPPs) and it doesnt work. The underside of the board is pretty fried from the heatgun.. Im gonna have to continuity check every circuit on it to get it going again, i'm sure..

 

The boards ICD used are not very heat-gun friendly.... modern PCBs can take that kind of abuse if you are careful, but not the ones ICD used..

 

Having the MIO diagnostic cart is a big help.. Unless the problem is so severe that it just absolutely hangs the system and wont even let a cartridge load... It lets you see what works and what doesnt without having a functional ROM.. The diagnostic cart ROM is a 16k eprom, and you use it in a SpartaDOS X cartridge..

 

If you you can get the system to boot with the MIO plugged in (eg. remove the MIO rom,) there is a file executable (MIODIAG.COM) version of the MIO diagnostic cart and it's included as part of Steve Carden's REALDOS distribution.

 

http://www.tcpipexpress.com/REAL%20DOS%20VER%2024.atr

 

I'll release the manual before too long, but right now, my priorities are on getting the last few preordered MIOs built & shipped..

Edited August 21, 2008 by MEtalGuy66

[Almost Rice]

Yeah Ive got a 1 megger here that someone took a heat-gun to... They repopuated the entire board with sockets afterwards (everything except the ZIPPs) and it doesnt work. The underside of the board is pretty fried from the heatgun.. Im gonna have to continuity check every circuit on it to get it going again, i'm sure..

 

I think that is my MIO I left there. It worked sporadically. I got it off ebay and would have better off buying another MIO from you.

[ijor]

So... I have the two 5 1/4" Atari disks full of DOS 2.5 source code. First, I load up BobTerm on the old 1200XL...

and...

will this be Xmodem?

DiskComm, first?

Convert ATASCI to EBCDIC?

 

(I'm not sure if you are joking or not, but I will assume you are not)

 

Just make ATR images. Don't bother with any kind of conversion.

[+bob1200xl]

And, upload them where? Who is going to find them?

 

The DOS 2.5 source is corrupted, I'm afraid. Maybe half the lines are OK - the others have stray bits stuck in them. Damn. I did find BASIC source. Not the listing that's in the book, the OSS source that can produce the code itself. That seems to be OK...

 

I would assume that lots of people have this stuff - everyone who really needs it, anyway. Like the DOS 2.5 source - I got it from Bill just because I thought I might want to look at it some day. Never did until now. You just kind of squirrel it away.

 

The OS listing is 400 pages long. How could that be distributed/archived? Somebody want to type in 400 pages of source? The quality is marginal for scanning, worse for OCR. Maybe we could hand out 20 pages each to 20 people tp type in?

 

Bob

 

 

 

So... I have the two 5 1/4" Atari disks full of DOS 2.5 source code. First, I load up BobTerm on the old 1200XL...

and...

will this be Xmodem?

DiskComm, first?

Convert ATASCI to EBCDIC?

 

(I'm not sure if you are joking or not, but I will assume you are not)

 

Just make ATR images. Don't bother with any kind of conversion.

[+Guitarman]

The fact thats its an original ICD unit is even better, because I dont have a 256k original MIO here..

 

You should have 1!!! LOL It just needs fixed!! (hint, hint)

[Almost Rice]

The fact thats its an original ICD unit is even better, because I dont have a 256k original MIO here..

 

You should have 1!!! LOL It just needs fixed!! (hint, hint)

 

If he fixes mine he would have 2 in his house.

[MEtalGuy66]

The fact thats its an original ICD unit is even better, because I dont have a 256k original MIO here..

 

You should have 1!!! LOL It just needs fixed!! (hint, hint)

 

That one is completely stripped, and the board needs major repairs.. Thats a major "rainy day" project...

[MEtalGuy66]

Heres a minimalistic/conservative concept image of what the new firmware could look like

 

Edited August 25, 2008 by MEtalGuy66

[Shawn Jefferson]

We are wasting half of the ROM space that could be used for improved device funcionality on a USER CONFIG PROGRAM, and this program leaves alot to be desired in flexibility and user friendliness.. Given, it's pretty good for 4k... But we have got a MEG of ram, and an entire hardisk at our disposal..

 

I wonder if you could pack the user config program with one of the packers out there and gain enough ROM space to do some upgrades to the code? Might not be worth it if you intend to fully realize your plans, but it could be a good first step.