NEW MIO production run.

[MEtalGuy66]

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.

 

I dont want to wait for something to "unpack" every time I enter the user config menu.. The user config menu is available "instantaneously" to change configuration "on the fly".. If we were going to do that, we might as well just load it from disk every time..

[MEtalGuy66]

Well, for all the owneres of original ICD MIOs out there who want to "upgrade" them to match the specs of the new one, here is the upgrade instructions..

 

This works the same on either a 1meg or 256k MIO, and upgrades it to 1meg, with the possibility of using the planned future expansions (eg. 16meg SIMM, VGA, etc.) In fact, once this upgrade is installed, your MIO will be electrically equivelant to the new MIO boards.. Anyone who finds any errors/problems with this should contact me immediately so I can correct/resolve the issue.

 

 

And here is the Service Manual:

 

MIO SERVICE MANUAL Ver. 2.0

 

I am still working on the PHI2 section.. It will be released when Im done.

 

Anywayze... There ya go... Enjoy..

Edited August 27, 2008 by MEtalGuy66

[ataridano]

I dont want to wait for something to "unpack" every time I enter the user config menu.. The user config menu is available "instantaneously" to change configuration "on the fly".. If we were going to do that, we might as well just load it from disk every time..

 

I agree 100% with your idea of moving the user config to disk and re-using that ROM space for handler code, etc. I would only make one request: Can the ROM retain some of the configuration code shown on the "main menu" of your previous post? Specifically the serial/parallel/video/drive enable and disable portion. The reason being, if someone were to somehow really screw things up, at least they'd have the option turning the hardware on or off before attempting to boot. Also, it would be nice to be able to turn on some basic "default" settings (like enable serial, enable parallel, hard drive set for D1) for those of us who don't have a harddrive to save the settings to. I understand this would be limited to only a few different combinations, yet I think it would be very nice to have available.

[kurtm]

I agree 100% with your idea of moving the user config to disk and re-using that ROM space for handler code, etc. I would only make one request: Can the ROM retain some of the configuration code shown on the "main menu" of your previous post? Specifically the serial/parallel/video/drive enable and disable portion. The reason being, if someone were to somehow really screw things up, at least they'd have the option turning the hardware on or off before attempting to boot. Also, it would be nice to be able to turn on some basic "default" settings (like enable serial, enable parallel, hard drive set for D1) for those of us who don't have a harddrive to save the settings to. I understand this would be limited to only a few different combinations, yet I think it would be very nice to have available.

 

How about a backup configuration cartridge? Not a perfect option, as it basically requires extra hardware (even if it is just a cartridge). But might be a handy option...

[MEtalGuy66]

How about if you loose your cofiguration, it defaults to booting from floppy drive 1 (which is already the case,) and you simply run the program that puts the user config program back in MIo RAM..

 

The point is.. If you dont have a hardisk, you still have to boot an OS from somewhere anywayze.. Might as well have "MIOMENU.COM" on your OS boot disk..

 

If you do have a hardisk, and let's say the config area of it gets corrupted, it will simply default back to booting from floppy.. same deal..

[+Stephen]

Well, for all the owneres of original ICD MIOs out there who want to "upgrade" them to match the specs of the new one, here is the upgrade instructions..

 

This works the same on either a 1meg or 256k MIO, and upgrades it to 1meg, with the possibility of using the planned future expansions (eg. 16meg SIMM, VGA, etc.) In fact, once this upgrade is installed, your MIO will be electrically equivelant to the new MIO boards.. Anyone who finds any errors/problems with this should contact me immediately so I can correct/resolve the issue.

 

IMG SNIPPED

 

And here is the Service Manual:

 

MIO SERVICE MANUAL Ver. 2.0

 

I am still working on the PHI2 section.. It will be released when Im done.

 

Anywayze... There ya go... Enjoy..

 

Awesome! Thanks for posting this Metal. I just got an original 256K MIO. I'll try to power it up this weekend.

 

Stephen Anderson

[Shawn Jefferson]

I was thinking about the MIO and how to utilize it. I was wondering, how does the MIO get control when pressing RESET ? If it would be possible to copy an arbitrary program into the MIO RAM at some location, and then run that program (just like the configuration utility is now) with some other keypress besides RESET+SELECT, that might be interesting and all sorts of programs may be created to take advantage of that, for instance, off the top of my head:

 

- "freezer" type program that takes a snapshot of memory, with the ability to restore to a previous snapshot.

- debugger type program: adjust memory locations while a program is running

- multi-tasking applicatoin like the snapshot program created by Tom Hunt

 

probably a lot of other very useful things that I'm not even thinking of.

 

Maybe this functionality could be built into your new firmware?

[MEtalGuy66]

I was thinking about the MIO and how to utilize it. I was wondering, how does the MIO get control when pressing RESET ? If it would be possible to copy an arbitrary program into the MIO RAM at some location, and then run that program (just like the configuration utility is now) with some other keypress besides RESET+SELECT, that might be interesting and all sorts of programs may be created to take advantage of that, for instance, off the top of my head:

 

- "freezer" type program that takes a snapshot of memory, with the ability to restore to a previous snapshot.

- debugger type program: adjust memory locations while a program is running

- multi-tasking applicatoin like the snapshot program created by Tom Hunt

 

probably a lot of other very useful things that I'm not even thinking of.

 

Maybe this functionality could be built into your new firmware?

 

Hmmm. kinda like the black box does its sector editor/copier, and super debugger?

 

Yep. Its easily done.. The way it "gets control" at reset right now, is that PBi devices are initialized on system reset.. and part of the firmware simply checks to see if {select] is being held.. if so, it loads the config program from ROM.. if not, it simply passes control back to the OS.. (I went over all this about 10 posts back..)

 

Anywayze.. The way the black box does it, (and the way I want the new firmware to work) is that at initialization time, it installs an OS hook that watches for the button to be pressed.. When this condition is met, it copies the contents of all the ATARI ram that the conmfig program will use (as well as relavent system variables, etc.) into a dedicated SRAM(We would use a small secxtion of MIO ram for this) on the Blackbox, then loads the config program from ROM and executes it.. When the user exits the config program, it copies everything back into the ATARI's ram just like it was before the button was pressed, and returns the machine to whatever program was running... This is absolutely "the way to go" on this...

 

But you are right, we could add the ability to run other MIO RAM resident "modules" from the user config menu... This way you could decide exactly how you want to utilize your MIO ram, and how much functionality you want to keep "resident" at all times..

 

damn good idea..

[Kyle22]

Metalguy66,

 

What is the current status of the new MIO? I may be interested in one. I tried to ask about this on blackendtech, pressed "submit" and it seemed like nothing happened. I hope you can get all that, cause it's long, all about what I wanted to do with the MIO while I was with FTe, and I don't feel like typing all that again

 

my e-mail is kyle22@operamail.com.

 

 

I generally see that before I read here.

 

Thanks!

 

-K

[MEtalGuy66]

Metalguy66,

 

What is the current status of the new MIO? I may be interested in one. I tried to ask about this on blackendtech, pressed "submit" and it seemed like nothing happened. I hope you can get all that, cause it's long, all about what I wanted to do with the MIO while I was with FTe, and I don't feel like typing all that again

 

my e-mail is kyle22@operamail.com.

 

Email sent.

 

And as far as status, it's shipping..

[jorevall]

Metalguy66,

 

What is the current status of the new MIO? I may be interested in one. I tried to ask about this on blackendtech, pressed "submit" and it seemed like nothing happened. I hope you can get all that, cause it's long, all about what I wanted to do with the MIO while I was with FTe, and I don't feel like typing all that again

 

my e-mail is kyle22@operamail.com.

 

Email sent.

 

And as far as status, it's shipping..

 

Any plans for a new run?

[MEtalGuy66]

I have 6 ready to ship, and 5 more to assemble/test/ship after that.

 

After those are gone, I will Reopen Ordering, and you can "get on the list"..

 

I am not taking any money from now on, until each order is ready to ship..

[Roydea6]

I have 6 ready to ship, and 5 more to assemble/test/ship after that.

 

After those are gone, I will Reopen Ordering, and you can "get on the list"..

 

I am not taking any money from now on, until each order is ready to ship..

 

 

I hope you will start a new thread. I am interested and ready to order also.

[MEtalGuy66]

Please re-download the MIo Service Manual.

 

The Parts List was totally "out of whack".. I fixed it.

 

Same download link as before..

[atariksi]

...

Yep. Its easily done.. The way it "gets control" at reset right now, is that PBi devices are initialized on system reset.. and part of the firmware simply checks to see if {select] is being held.. if so, it loads the config program from ROM.. if not, it simply passes control back to the OS.. (I went over all this about 10 posts back..)

 

Anywayze.. The way the black box does it, (and the way I want the new firmware to work) is that at initialization time, it installs an OS hook that watches for the button to be pressed.. When this condition is met, it copies the contents of all the ATARI ram that the conmfig program will use (as well as relavent system variables, etc.) into a dedicated SRAM(We would use a small secxtion of MIO ram for this) on the Blackbox, then loads the config program from ROM and executes it.. When the user exits the config program, it copies everything back into the ATARI's ram just like it was before the button was pressed, and returns the machine to whatever program was running... This is absolutely "the way to go" on this...

...

 

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

[+warerat]

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

 

The MIO is a PBI device and follows certain conventions to access its ROM space. Only 2K of the MIO ROM is visible directly at any given moment to the machine when it is enabled, from $D800-$DFFF (you lose the OS floating-point ROM while it's switched in). So that's the only part of the OS ROM you're switching in/out with PBI ROM.

[MEtalGuy66]

...

Yep. Its easily done.. The way it "gets control" at reset right now, is that PBi devices are initialized on system reset.. and part of the firmware simply checks to see if {select] is being held.. if so, it loads the config program from ROM.. if not, it simply passes control back to the OS.. (I went over all this about 10 posts back..)

 

Anywayze.. The way the black box does it, (and the way I want the new firmware to work) is that at initialization time, it installs an OS hook that watches for the button to be pressed.. When this condition is met, it copies the contents of all the ATARI ram that the conmfig program will use (as well as relavent system variables, etc.) into a dedicated SRAM(We would use a small secxtion of MIO ram for this) on the Blackbox, then loads the config program from ROM and executes it.. When the user exits the config program, it copies everything back into the ATARI's ram just like it was before the button was pressed, and returns the machine to whatever program was running... This is absolutely "the way to go" on this...

...

 

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

 

Dude... You seriously code and develop hardware for the atari, and you are asking this?

[Shawn Jefferson]

Yep. Its easily done.. The way it "gets control" at reset right now, is that PBi devices are initialized on system reset.. and part of the firmware simply checks to see if {select] is being held.. if so, it loads the config program from ROM.. if not, it simply passes control back to the OS.. (I went over all this about 10 posts back..)

 

Anywayze.. The way the black box does it, (and the way I want the new firmware to work) is that at initialization time, it installs an OS hook that watches for the button to be pressed..

 

How is the OS hook installed? Is the RAM under OS turned on and patched, or is a vector changed somewhere? I'd think the RESET method would be most compatible with different programs. Hmmm, I was just reading the manual for the Black Box (I don't have one) and there is a push button on the BB itself that you push to get into the config menu and monitor. Is that what you are referring to? I'm assuming that would generate an interrupt to load the config program... (??)

 

Thinking about this a little more and looking at the MIO docs... how do you determine which memory in the MIO is free? I see a couple of locations that might be applicable:

 

$D652: last RAM page number allocated to print spooler

$D658: number of pages allocated for each drive (hi)

$D660: number of pages allocated for each drive (low)

$D668: total number of RAM pages (high byte)

 

But you are right, we could add the ability to run other MIO RAM resident "modules" from the user config menu... This way you could decide exactly how you want to utilize your MIO ram, and how much functionality you want to keep "resident" at all times..

 

That's exactly how I see it working... maybe in the config menu you have 2 or more "slots" that you can assign and how much memory is to be assigned to each, and the corresponding hotkey to launch that program. It would be great to be able to upload any program into the MIO ram to be launched from those "slots". If you are going to have a routine to dump the machine's 64k of RAM and CPU registers to MIO RAM, it would be nice to have a vector to that routine in the firmware so it can be used by other programs like these.

[MEtalGuy66]

Thinking about this a little more and looking at the MIO docs... how do you determine which memory in the MIO is free? I see a couple of locations that might be applicable:

 

$D652: last RAM page number allocated to print spooler

$D658: number of pages allocated for each drive (hi)

$D660: number of pages allocated for each drive (low)

$D668: total number of RAM pages (high byte)

 

If you are going to have a routine to dump the machine's 64k of RAM and CPU registers to MIO RAM, it would be nice to have a vector to that routine in the firmware so it can be used by other programs like these.

 

We arent going to dump the full 64k.. Just the section of ram that the user config program will occupy, plus the zero page, and relevant sytem/OS variables.. I dont want a "5 second delay" when you try to enter the menu..

 

The way you can determine how much MIO ram is free with the existing firmware is by reading all of the drive config variables, determining how many ramdisks you have, and then reading the corresponding "number of pages allocated" varaible for each ram drive, add those together, then add the number of pages allocated to the print spooler, to get "total number of allocated banks" Then subtract the total number of allocated banks from the "total number of ram pages" variable... The result is how much is unallocated by the firmware..

 

I think the new firmware will store a "free banks" variable for that so you dont have to do all that..

[atariksi]

...

...

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

 

Dude... You seriously code and develop hardware for the atari, and you are asking this?

 

I specialize in optimizing things so just wanted to get to the limits of what can be done...

 

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

 

The MIO is a PBI device and follows certain conventions to access its ROM space. Only 2K of the MIO ROM is visible directly at any given moment to the machine when it is enabled, from $D800-$DFFF (you lose the OS floating-point ROM while it's switched in). So that's the only part of the OS ROM you're switching in/out with PBI ROM.

 

Okay, so MIO ROM is at $D800..$DFFF and RAM window is at $D600..$D6FF (from other thread) so only part of ROM is switchable. So it's not possible to allow the reverse where RAM window is the bigger one (2K or more) and MIO ROM window is disabled/smaller? I guess self-test ROM at $D000...$D7FF is inaccessible in MIO set-up to enable/disable/over-ride.

[MEtalGuy66]

...

...

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

 

Dude... You seriously code and develop hardware for the atari, and you are asking this?

 

I specialize in optimizing things so just wanted to get to the limits of what can be done...

 

So the MIO ROM is separate from OS ROM. Anyway to override OS ROM with the MIO ROM like switching it in/out?

 

The MIO is a PBI device and follows certain conventions to access its ROM space. Only 2K of the MIO ROM is visible directly at any given moment to the machine when it is enabled, from $D800-$DFFF (you lose the OS floating-point ROM while it's switched in). So that's the only part of the OS ROM you're switching in/out with PBI ROM.

 

Okay, so MIO ROM is at $D800..$DFFF and RAM window is at $D600..$D6FF (from other thread) so only part of ROM is switchable. So it's not possible to allow the reverse where RAM window is the bigger one (2K or more) and MIO ROM window is disabled/smaller? I guess self-test ROM at $D000...$D7FF is inaccessible in MIO set-up to enable/disable/over-ride.

 

 

Its also not possible to allow your car to drive 50 miles per hour in reverse and only 10 miles per hour forward... because that is the way it is DESIGNED... and we are not CHANGING the design..

Edited August 28, 2008 by MEtalGuy66

[+warerat]

Okay, so MIO ROM is at $D800..$DFFF and RAM window is at $D600..$D6FF (from other thread) so only part of ROM is switchable.

You got it. Plus, there's a few registers in the $D1XX area to control the RAM and the other devices on it.

 

So it's not possible to allow the reverse where RAM window is the bigger one (2K or more) and MIO ROM window is disabled/smaller?

It's not practical to do that with the MIO in it's present configuration, but if you were building your own piece of hardware, it's completely possible to have some kind of banked memory (or mixture of RAM/ROM) at the 2K window.

 

I guess self-test ROM at $D000...$D7FF is inaccessible in MIO set-up to enable/disable/over-ride.

Self-test ROM is always available because it's still mapped to the OS ROM and enabled seperately. So yeah, you could in theory place MIO code in the self-test area and switch it in and out.

[Shawn Jefferson]

We arent going to dump the full 64k.. Just the section of ram that the user config program will occupy, plus the zero page, and relevant sytem/OS variables.. I dont want a "5 second delay" when you try to enter the menu..

 

Makes sense, sure.

 

The way you can determine how much MIO ram is free with the existing firmware is by reading all of the drive config variables, determining how many ramdisks you have, and then reading the corresponding "number of pages allocated" varaible for each ram drive, add those together, then add the number of pages allocated to the print spooler, to get "total number of allocated banks" Then subtract the total number of allocated banks from the "total number of ram pages" variable... The result is how much is unallocated by the firmware..

 

I think the new firmware will store a "free banks" variable for that so you dont have to do all that..

 

Are the used RAM banks all consectutive then? Also, the MIO uses the first 2 for itself as well, right?

[+warerat]

Are the used RAM banks all consectutive then? Also, the MIO uses the first 2 for itself as well, right?

 

All the banks are consecutive. Pretty sure the MIO uses the first three.

[ataridano]

How about if you loose your cofiguration, it defaults to booting from floppy drive 1 (which is already the case,) and you simply run the program that puts the user config program back in MIo RAM..

 

The point is.. If you dont have a hardisk, you still have to boot an OS from somewhere anywayze.. Might as well have "MIOMENU.COM" on your OS boot disk..

 

If you do have a hardisk, and let's say the config area of it gets corrupted, it will simply default back to booting from floppy.. same deal..

 

The reason I asked is because I can think of a few situations where it might be good to have some menu options in ROM. What if you have a hard drive, loose your configuration, and (like me) have you're floppy drive squirreled away because when you have a hard drive the floppy is never used. You just want to turn the hard drive "on" again. Another would be a case where the user has no floppy and no hard drive and uses the serial port and a terminal emulator in flash cart, and the serial port configuration gets corrupted. I suppose the biggest problem would be the user who had 80 col video turned on but did not have the 80 col monitor connected. I know that the simple answer is just to keep a floppy drive (or any SIO drive for that matter) close at hand, but part of the joy of spending lots of money on a hard drive is that you never have to look at a floppy drive again Maybe I should ask the question a different way... if I don't have a hard drive, what is the default configuration for the serial port, parallel port, 80 col video, and any other boot options? Does the MIO have any issues getting along with other PBI devices (ie would I want to disable any of the above because they conflict with another device?)? The non-hard drive user would probably be the only one who didn't have "miomenu.com" not close at hand.