Jump to content
IGNORED

New (alt) BIOS for Ultimate 1MB/Incognito


Recommended Posts

Sorry for the incomplete information in my initial question.

I've verified the issue with version 2.0 of the BIOS and SIDE loader.

This is what I do:

- PBI BIOS with HISIO is active

- Enter the SIDE Loader

- Configure D1 as regular SIO with a real drive and a DOS 2.5 DUP Disk

- Mount an ATR as D2 and reboot.

- DOS/DUP are booted from D1

- Put a new empty disk into D1

- Use "J - Duplicate Disk" to copy from D2 to D1

- As a first step the target disk is formatted. The format command is sent to the dirive and the drive starts formatting.

- The Atari does not wait for the formatting to end but stop with error 138 after around 10 seconds.

- Note: If I use a SIO2USB drive as D1: formatting is fast enough so the error does not occur. The probably also is true for Happy Drives as formatting works differently there. But it occurs with and standard 1050.

 

Fixed. ;)

 

This was arguably a bug, although it depended on some unexpected (to me) behaviour of DOS 2.5, which derives the value eventually loaded into DTIMLO ($0306) from DSKTIM ($0246), which in turn derives its value from 'the third byte of the status frame'. What I didn't realise is that this status frame does not need to originate from the drive about to be formatted. It appears the last status frame accessed on any drive has its third byte stored in DTIMLO, and since the third byte returned by a status command issued to a PBI-mounted ATR was $03 (not a value intended to be used as an SIO timeout, obviously; it's actually an internal platform ID code), problems ensued.

 

My test scenario was booting DOS 2.5 from a PBI-mounted ATR on D1: and attempting to then format a disk on a 1050 at D2:. Although a status command issued to D2: returned the correct value ($E0), $03 was nevertheless stored in DTIMLO prior to the format command being issued, simply because a status on D1: returned $03 in the third byte of the frame. :)

 

Well... you live and learn. Thanks for spotting that one, Peter. It's an extremely good catch.

 

Safest (and tested working) fix is to just return $E0 in the third byte of the status frame for PBI mounted ATRs.

Edited by flashjazzcat
  • Like 5
Link to comment
Share on other sites

Thanks Jon. The behaviour of DOS 2.5 is surely unexpected here. I had in mind that the timeout is bound to the format command only. Using the status information of one drive to control the handling of a totally different drive is surely more an accident than intention. At least the DOS should have issued a status command to the target drive in this case as the last operation before the actual access (here: format).

 

EDIT: A kiler feature in the SIDE Loader would be the ability to format & writeback an ATR from the FAT to the physical drive. Or maybe even the other way around. That is what I actually tried to achieve.

  • Like 1
Link to comment
Share on other sites

It should already be perfectly possible to do what you describe, in either direction (albeit from DOS). The PBI ATR handler includes a dummy format command which simply returns an empty bad sector list to enable DOSes which have no facility for the suppression of low-level formatting to nevertheless initialise a disk. So - with the fix in place - duplicating a physical disk to an ATR and vice-versa in DOS 2.5 should work.

  • Like 3
Link to comment
Share on other sites

Sorry for the incomplete information in my initial question.

I've verified the issue with version 2.0 of the BIOS and SIDE loader.

This is what I do:

- PBI BIOS with HISIO is active

- Enter the SIDE Loader

- Configure D1 as regular SIO with a real drive and a DOS 2.5 DUP Disk

- Mount an ATR as D2 and reboot.

- DOS/DUP are booted from D1

- Put a new empty disk into D1

- Use "J - Duplicate Disk" to copy from D2 to D1

- As a first step the target disk is formatted. The format command is sent to the dirive and the drive starts formatting.

- The Atari does not wait for the formatting to end but stop with error 138 after around 10 seconds.

- Note: If I use a SIO2USB drive as D1: formatting is fast enough so the error does not occur. The probably also is true for Happy Drives as formatting works differently there. But it occurs with and standard 1050.

Very odd...

 

I actually decided to test this at an SIO-to-SIO level but with PBI-BIOS in the middle (Hi-speed SIO).

 

Not even booting DOS is required:

 

=>a blank floppy on D1, and .ATR (1050-density with Dos 2.5) on D3 (Sdrive NUXX)

=> HSIO active on PBI BIOS for D1 and D3...

=> Load CopyMate 3.8 ,xex directly from SIDE loader and, bam!

 

CopyMate "copy-and-format" operation from D3 to D1 will FAIL if PBI-HSIO is active on D1, and will do OK, with PBI-HSIO is disabled from D1. The error reported is "density mismatch", which is impossible, because D1 floppy has been mandated to be formatted per D3 source's density. When going to SIO-floppy without PBI-HSIO, density-scan, density-setting, and format operations all run perfectly.

 

Not sure if related, and not sure if problem is at Copymate, Atari-OS or PBI-BIOS level (or incompatibility between these), but behavior is very, very similar (had not seen this before....)

 

(!?)

Edited by Faicuai
Link to comment
Share on other sites

Does the same thing work with the High-Speed patched OS? Normally it's pretty redundant now, but if the same issue occurs there, it would save a lot of time. There are sure to be applications which simply object to high-speed polling, etc.

This particular issue is solved. After testing a million times, problem was directly at CopyMate 3.8 level, specifically in the speed of cycling of "FORMAT Yes/No" option (in other words, erratic config.)

 

So no anomalies at SIO-to-SIO level that I can see, although the ability to transfer .ATRs from EITHER [sIDE-resident storage] or [sIO-bus solid state drive] to [sIO-based floppy drive] is truly welcome, as it has been a need on my side as well.

  • Like 1
Link to comment
Share on other sites

OK: After four days, I'll take this as a) No-one here runs Rapidus with the July 2018 U1MB firmware, or b) they do, but there was no problem. :)

 

I am keen to hear from owners of Rapidus/U1MB/VBXE equipped machines who would be willing to test the forthcoming update and establish if any (apparently rare) issues with software attempting to detect the VBXE FX core have been properly dealt with. Right now I have one complaint received nine months after the firmware was released, and one reproducible issue on my own hardware which was fixed with a simple code change. However, the person who reported the issue is no further forward with things yet.

 

Unfortunately I can't release the new update until I know one way or another whether my fix is universally effective.

 

Hi Jon,

 

I run my 130XE with VBXE, U1MB and Rapidus but so far, I did not experience any problems. Maybe I should try harder... ;-)

This is my config:

 

post-20150-0-74934600-1557137115.jpg

 

If I should test something, let me know...

Edited by Tigerduck
Link to comment
Share on other sites

Can i use the Config Selector with my SIDE2 cartridge and SDX 4.49c ?

I made a subdirectory SPARTA.DOS on my Side2 C: boot partition
I then put 2 diferent config files with extension .CFG in that SPARTA.dOS subdirectory.

After rebooting my SIDE2 cart I still do not see a config selector.

What am i doing wrong ?

 

I used paragraph 8.3 (page 161) of the Spartados X 4.48 User Guide.

 

PS: I do NOT have an U1MB in my standard 130XE.

Link to comment
Share on other sites

...although the ability to transfer .ATRs from EITHER [sIDE-resident storage] or [sIO-bus solid state drive] to [sIO-based floppy drive] is truly welcome, as it has been a need on my side as well.

Just as a follow-up on this: subject to the DOS 2.5 formatting issue Peter identified, have you actually attempted to perform a raw sector copy of an ATR to a disk or vice-versa (bypassing formatting if necessary), and found it not to work? Or did you simply assume the facility was unavailable? As I say: apart from the DOS 2.5 status/formatting issue, raw disk duplication should always have worked.

 

I run my 130XE with VBXE, U1MB and Rapidus but so far, I did not experience any problems. Maybe I should try harder... ;-)

Thanks: that's good to hear. You don't have the Rapidus plugin installed by the looks of it, but it's not essential unless you have the Rapidus GND wire connected to U1MB for the purpose of enabling and disabling the Rapidus core in software. As long as the S_VBXE.SYS driver and demos/applications which require VBXE work, then all is well.

 

Can i use the Config Selector with my SIDE2 cartridge and SDX 4.49c?

 

I made a subdirectory SPARTA.DOS on my Side2 C: boot partition

I then put 2 diferent config files with extension .CFG in that SPARTA.dOS subdirectory.

 

After rebooting my SIDE2 cart I still do not see a config selector.

 

What am i doing wrong ?

 

I used paragraph 8.3 (page 161) of the Spartados X 4.48 User Guide.

 

PS: I do NOT have an U1MB in my standard 130XE.

I've never used the SDX config selector, but I do not imagine it will work with the SIDE.SYS driver, since the moment DOS is told not to fetch CONFIG.SYS from the CAR: device (the default), but instead look for it on the hard disk, it becomes impossible to read the hard disk (since the SIDE.SYS driver is loaded by the default CONFIG.SYS on CAR:). I believe a way is provided to MERGE configuration files (described in the manual), but it's not something I've looked into personally.

Link to comment
Share on other sites

Just as a follow-up on this: subject to the DOS 2.5 formatting issue Peter identified, have you actually attempted to perform a raw sector copy of an ATR to a disk or vice-versa (bypassing formatting if necessary), and found it not to work? Or did you simply assume the facility was unavailable? As I say: apart from the DOS 2.5 status/formatting issue, raw disk duplication should always have worked.

 

I can’t speak for anyone else, but I personally have done just that in recent months - I booted Disk Wizard II from a mounted ATR, then used that same ATR to make a copy of itself to a physical disk. I then booted that physical floppy and made a copy of a different ATR mounted as D2: in the Loader

 

(ASIDE: If Disk Wizard II allowed access to more than two drives I wouldn’t have needed to boot a physical disk to make the copy - if anyone has recommendations for a good sector copier that can work with D3: and D4:, that’d be great).

Link to comment
Share on other sites

I can’t speak for anyone else, but I personally have done just that in recent months - I booted Disk Wizard II from a mounted ATR, then used that same ATR to make a copy of itself to a physical disk. I then booted that physical floppy and made a copy of a different ATR mounted as D2: in the Loader.

Thanks Herb. Nice as it is to be asked for features which are already implemented, it's also nice to know the already implemented features work. :)

Link to comment
Share on other sites

Just as a follow-up on this: subject to the DOS 2.5 formatting issue Peter identified, have you actually attempted to perform a raw sector copy of an ATR to a disk or vice-versa (bypassing formatting if necessary), and found it not to work? Or did you simply assume the facility was unavailable? As I say: apart from the DOS 2.5 status/formatting issue, raw disk duplication should always have worked.

 

(…)

 

Well, took some time to re-check this, and here's the bottom line:

  1. There are only two sector-copiers worth of my time and attention: CopyMate 3.8 and MyCopier 2.1.
  2. BOTH can be launched stand-alone from SIDE Loader (I have two special versions patch to run on Incognito, but still 100% compatible with XL-OS).
  3. CopyMate is able to see up to four drives of any kind, including those under PBI-BIOS, as well as its HSIO acceleration. Also handles extended memory, and it is the tool-of-choice for general use, and for any domain transfer (e.g. HD-based .ATR to SIO-based .ATR, SIO-to-SIO .ATR, etc.) It will NOT, however, format with US-doubler skews, etc., which you will need to do so externally, first (via SDX). It has its own HELP-key driven menu, and can gracefully quit to DOS, while also resisting System-Reset key.
  4. MyCopier 2.1 is able to see up to two drives, but WILL NOT see anything under PBIO-Bios. However, it has its OWN hi-speed SIO drivers (up to 0A divisor), and WILL RUN on Colleen OS/B (!) Will also handle extended memory if you can, but runs beautifully on A800's 52K ram mode. It WILL format with high-speed skew tuned for 0A-divisor speeds, all on its own, and without ever leaving its main menu. But due to its limited scope, it will be suited for SIO-to-SIO operations, only.

From the above (and answering now your question), I tried multiple times #3 above (CopyMate) by carefully playing with the presence of PBI / HSIO bios, and I am happy to report that it works like a charm on inter-domain transfers: reading from a SIDE-mounted .ATR into computer's memory, and then writing out to SIO-attached Indus (running US-Doubler accelerator) is RIDICULOUSLY fast, relatively speaking. Finally perfect for transferring CP/M disks, as well!

 

So it's all good, at this point, it seems!

Edited by Faicuai
  • Like 2
Link to comment
Share on other sites

Interesting Peter, this might also tie into the weird issue of device done/timing errors seen while making disks etc ... it all seems oddly familiar. It might not only be the part of the puzzle for this but maybe some of the 'upgraded' flavors of different DOS's that exist today as well. As always, work a rounds abound but shouldn't have to be, provided the actual fix doesn't break or remove things of greater benefit.

 

Pounding headache atm, so I'm sure I've messed up my meaning in the above. Someone brilliant will get my drift though. :)

Edited by _The Doctor__
Link to comment
Share on other sites

Peter's prompt report is the first I heard of any such issues regarding mounted ATRs causing formatting timeouts with DOS 2.5. If only someone who has observed such problems in the past and still remembers them today had reported them at the time, the matter may have been dealt with years ago. The code in question (SIO status command for ATRs and HDD partitions) has not changed since 2013 or 2014. Likewise workarounds: if they abound, they did so quietly until the issue was clearly reported, and that was the only pragmatic means of rendering the workaround unnecessary. Hindsight apparently brings such clarity...

Edited by flashjazzcat
  • Like 3
Link to comment
Share on other sites

Hindsight absolutely can when things happen and you don't know why, you just can't put a finger on it and so you try. Finally you get it done, and your just so happy it's over you move on content with having it accomplished. I do know a few guys who thinks it better not to say anything, since they don't know why a thing happens and don't want to get the treatment if they say anything. Perhaps not wanting to be found missing a step and all that. That's why I give kudos to Peter, he stood up, pointed something out, and went the extra step to make sure and remember what was up. I am glad for this and it will only make things better. I wish more lurkers will dive in get the things rolling... they almost always have something good come of their posts!

Link to comment
Share on other sites

'The treatment' is indeed a terrible ordeal for anyone who dare speak of a potential bug. You may be asked for a description of your setup, a detailed account of what happened, and even - in the worst possible case scenario - told that you had set something up wrongly. That can be pretty tough and I know some people come out of the other end of it pretty messed up. I heard of one guy who was asked to read the manual. Terrible. I think he's still in therapy. Sometimes you get lucky, though, and it turns out to be a bug there and then. But there's always the risk of user error, and the ensuing psycho-drama of bewilderment and self-doubt. The best way to avoid abject humiliation and ostracization, however, is to not to say anything at all when you notice an issue. Then you wait, and one day, if you're really lucky, someone else will say something about it and then you get to look great by saying 'Ah yes... this would seem to confirm my previous observations on the matter' or something along those lines. :)

  • Like 4
Link to comment
Share on other sites

Safety in numbers, if it's one person... it can't be believed, if it's more than a few folks, well it's more likely to be a real bug. I do know people having mentioned issues in the past but they get written off as 'corner' cases. Might not have been on this exact subject Most wouldn't know what the underlying issue could or might be. In any event the more the merrier.

 

To keep it positive, and to prevent others from psycho therapy... I again applaud those willing to go the distance and speak up about whatever issue they are having. Waiting for another person may work. But it's best to put it out there. You might not be a super user who can follow all the steps and give techno babble, but you at least bring light to the subject and get an answer one way or another eventually.

 

Plus, super bonus! Knuckleheads like myself may even pick up that hot pan just to see if the premise is correct. Then we will have more than one person to confirm the issue. Why I bet we could get an infirmary full of folks who can confirm and attest to whatever the ailment is. That's why we sometimes ask for ATR's, Videos, pictures, or even ask for or get the off PM to give it a once over.

 

Why at this rate we could be on to a full fledged revolution of this lunacy! Come on out of the shadows, you might find some friends here.

 

It wouldn't be the first time that myself, or another posted about an issue with this DOS or that... I remember some chatter to that affect... but shhhhh that's an open secret on the forums...

Edited by _The Doctor__
Link to comment
Share on other sites

Lest my heavy sarcasm is misconstrued: I am happy to investigate issues reported by individuals. You don't need to form a syndicate first, and if you notice a problem which affects functionality and say nothing about it, it may never get fixed. Each user differs and we might wait for ever for two or three people to experience the exact same issue and buddy up in order to broach the topic on the forums in the face of some imagined threat of ridicule. Please stop passively agressively insinuating that individual users should be reluctant to report issues with my software lest they be labelled liars. At this point the thread is becoming cluttered with waffle.

  • Like 5
Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...