What XL/XE OS have a fast math pack?

[+Larry]

I'm not thinking of the "800-replacement" OS used in XL/XE, but real XL/XE OS that have the PBI code (among other thngs).

 

I'm 99% sure that the UltraSpeed Plus OS from CSS had a fast math pack. Others?

 

-Larry

[Rybags]

Possibly some versions of Omnimon/Omniview?

 

The old Newell fastchip should work in any OS version (ie just replace the 2K section in later single-chip OSes). There's a later FP replacement for XL/XE that from memory also uses some of the space within the main OS Rom (and it's faster again).

[+Larry]

Yes, Omnimon/Omniview have it, but they are 800 replacement -- no PBI code.

 

Maybe QMEG? I'm not familiar with it. Also, pretty sure that the 65816 OS has fast math, but it is 65816 cpu only.

 

-Larry

[Rybags]

I wasn't aware they took away the PBI code... suppose they'd have to as there's not much free space (probably <200 bytes). Unless they replaced the second character set, that frees up 1K.

[+Larry]

So far, I've found one -- I think. Clearly the "FASTMATH" OS has an improved math package. But I can't tell if it has the PBI drivers, or is just another 800 replacement OS.

 

So, a couple of questions:

 

1) Is there a way to tell if if the PBI driver is present?

I've read through the "The Parallel Bus Revealed" and as I understand it, if a PBI device is found, then when it is called, it disables the first 200 bytes of the math package to execute the PBI. So there should be a way to find the code that is responsible for finding and putting the device in the handler address table. (?) Any thoughts?

 

2) It looks like one could "roll their own" OS by taking *any* fast math package and pasting it into the $D800 - $DFFF rom address space. Should that work, or am I oversimplifying it?

 

Found a good article at

http://www.atarimax.com/freenet/freenet_material/5.8-BitComputersSupportArea/7.TechnicalResourceCenter/showarticle.php?14

 

-Larry

[Rybags]

PBI has the FPD signal (Floating Point Disable) which switches out the entire 2K FP from $D800-$DFFF.

 

Easy way... I guess you could check the IRQ handler, if there's references to $D1FF then the PBI code is probably present.

In fact, probably just search the OS Rom for occurrences of $FF,$D1 then list from just before that.

 

"Any fast math" - not quite, the fastest one I mentioned earlier uses more than just the normal 2K but with the Newell based one it should be a dropin replacement for any other Rom image.

[+Larry]

Thanks! I'll take a look!

-Larry

[Mathy]

Hello Rybags

 

PBI has the FPD signal (Floating Point Disable) which switches out the entire 2K FP from $D800-$DFFF.

 

...

 

... the Newell based one ....

 

MPD (Math Pack Disable).

 

BTW I never heard that the fast MP replaced the PBI driver inside the ROM (but it does, as you say, switch out the MP when the PBI code is accessed).

 

The fast math routines where sold/marketed by Newell, but coded by Charles Marslett.

 

Sincerely

 

Mathy

[+bob1200xl]

Any PBI device that wants the stock OS to find it sets a bit in $247, one bit for each of 8 possible PBI devices. So, if you look in $247 and it is non-zero, you have a PBI device.

 

I would guess that you can put any kind of MathPack code in $D8xx.

 

Bob

 

 

 

So far, I've found one -- I think. Clearly the "FASTMATH" OS has an improved math package. But I can't tell if it has the PBI drivers, or is just another 800 replacement OS.

 

So, a couple of questions:

 

1) Is there a way to tell if if the PBI driver is present?

I've read through the "The Parallel Bus Revealed" and as I understand it, if a PBI device is found, then when it is called, it disables the first 200 bytes of the math package to execute the PBI. So there should be a way to find the code that is responsible for finding and putting the device in the handler address table. (?) Any thoughts?

 

2) It looks like one could "roll their own" OS by taking *any* fast math package and pasting it into the $D800 - $DFFF rom address space. Should that work, or am I oversimplifying it?

 

Found a good article at

http://www.atarimax.com/freenet/freenet_material/5.8-BitComputersSupportArea/7.TechnicalResourceCenter/showarticle.php?14

 

-Larry

[+Larry]

Thanks, Bob. I should be able to test that with Altirra, otherwise I'd have to burn an eprom to test. OTOH, if I "hook up" a PBI device in Altirra and it works, then I know that the PBI code is in there.

 

-Larry

[Rybags]

Don't confuse PBI code within the OS with that provided by the device - the OS code is within the 12K C000-CFFF and E000-FFFF areas, the PBI device handlers provided by the likes of IDE +2 are the ones that switch into the D800-DFFF area.

They don't replace the FP, the switch in is only for the duration of calls to the handler by CIO, SIO and cold/warmstart routines.

[+Larry]

Hi Gary-

 

Not sure that I follow your last post. Yes, it's temporary. But if I hook up a PBI device and it does work, then the PBI (recognition code) has to be there. And if it doesn't work...

 

-Larry

[Rybags]

Yes, if the PBI device is compliant and works then the OS should be fine.

[thorfdbg]

Don't confuse PBI code within the OS with that provided by the device - the OS code is within the 12K C000-CFFF and E000-FFFF areas, the PBI device handlers provided by the likes of IDE +2 are the ones that switch into the D800-DFFF area.

They don't replace the FP, the switch in is only for the duration of calls to the handler by CIO, SIO and cold/warmstart routines.

 

In addition to that: It is not the matter of the Os to disable the math pack. This is a hardware line that is pulled by the external hardware if it wants to make its own ROM code visible, and this will - or should - only happen in case the device handler requires the ROM space, i.e. is called by CIO or SIO. Hence, whether a PBI device is present or not does not change the general availability of the math pack. Regular programs still see it. The only restriction is that PBI device handler code cannot use floating point math. But that's not a loss since usually such devices will perform I/O, and not math.

[+Larry]

 

In addition to that: It is not the matter of the Os to disable the math pack. This is a hardware line that is pulled by the external hardware if it wants to make its own ROM code visible, and this will - or should - only happen in case the device handler requires the ROM space, i.e. is called by CIO or SIO. Hence, whether a PBI device is present or not does not change the general availability of the math pack. Regular programs still see it. The only restriction is that PBI device handler code cannot use floating point math. But that's not a loss since usually such devices will perform I/O, and not math.

 

Hi-

 

I know you have a super math package, but your OS has no provision for PBI, IIRC? Does your math pack fit in $D800-$DFFF? Drop-in? I'm thinking yours is bigger than that, but it's been a while since we discussed it.

 

-Larry

[thorfdbg]

 

Hi-

 

I know you have a super math package, but your OS has no provision for PBI, IIRC? Does your math pack fit in $D800-$DFFF? Drop-in? I'm thinking yours is bigger than that, but it's been a while since we discussed it.

 

-Larry

 

Yes, Os++ does not have provisions for PBI (due to lack of documentation, and better use of the same ROM area), but the mathpack is a drop-in replacement that is the same size as the original. It does not require any additional ROM space - hence in principle it could replace the built-in math-pack.

 

However, while it is faster than the original, it is surely not as fast as dedicated fast-math packages that unroll loops. These require more ROM space than available in the original 2K the math pack takes.