Problem with 850 driver and DOS 2.5

[sanny]

Hi,

 

following up on Thom's recent problems with the serial driver and 850, I tried to investigate this a bit.

 

I could reproduce the problem (crash when accessing R: device) with a simple assembler test program. So no cc65 runtime or such involved.

I found out, that when I load the 850 driver with the attached ATR's AUTORUN.SYS, parts of the R: driver seem to be overwritten by DUP.SYS.

 

To reproduce, load the attached ATR image in Altirra. Then run the included HATABS.COM file, which prints the entry points of all installed drivers. For R: the "special function" entry point is at $1F20. (In fact $1F21.)

Open the debugger and look at $1F20 area, and you'll see parts of the DUP.SYS menu there. Wtf??

 

Load the included MEM.COM, and you'll see that MEMLO is at $22AE.

 

What's happening here?

 

regards,

chris

sercrash.atr

source-codes.zip

[tschak909]

I'm so glad it's not just me.

 

-Thom

[tschak909]

Something DEFINITELY goofy with Altirra's handler, because:

 

HATABS.COM on my Atari shows:

 

6 R Hndl: $226D Open: $0344 Clos $1DA9 Read: $459D Writ $A903 Stat $8D44 Spcl: 1DF1

 

-Thom

[tschak909]

SERTST.COM hangs

SERTST2.COM shows Program Started... followed by Program #2.

 

-Thom

[tschak909]

This is certainly interesting, if I create a MEM.SAV file, _AND_ use Avery's RHND850.COM (which loads its own resident copy), then PLATOTerm loads...

 

See disk image:

 

plato-dos25.atr

 

-Thom

[_The Doctor__]

I wouldn't be too hard on Avery's driver

 

part of the problem is there were 4 or 5 versions of the 850 rom and what it loaded, each had it's plus and minus... seems like they fixed one thing and messed up another each time. The ideal would be to put them all spliced together with just the best parts... many people copy whatever handler and 850 polling boot they have and tweak it a little but depending on what they started with, it could be a problem. It used to be that the 850 could have 1 baud rate out and a different baud rate in as well as letting incoming data to flow even after the control line to stop data was dropped the software wasn't suppose to ignore the incoming data but rather wait for the data to stop before doing disk I/O etc... the send (tx) from the Atari was not to occur unless it was clear to send... but the incoming rx was suppose to allow data to pass and the attached device was suppose to stop the data, it was up to the program to realize to something might still be coming, but each rom had this idea a little different, worried about disk data corruption things got borked on almost all versions, at most only a couple bits up to a couple bytes only ever made it through after the line was dropped. I have no idea how many of the decent roms ever made their way out to the world and if the switch from mode to mode just shuts the whole port off anymore. I simply do not remember and it is a source of aggravation.

 

I wouldn't blame anyone too much if they tried to reverse engineer from an 850 because the chances are almost any 850 you get has their built in handler messed up in one way or another. There were user groups who dissected the 850 and it's roms back around late 80's and again in early 90's who put in their newletters the best rom version and why, as well as RBIN drivers for the best experience for each one. Sadly no one seems to be coming forward with them. If lost to time, will anyone take on the challenge to re create what was done then again or even better?

 

I know it is frustrating but hopefully if it gets looked into again it will be solved once more.

 

Please know all this pain might lead to a gain. I haven't found the styrofoam crate with the different 850's or the paperwork yet, but I do look from time to time. I hope it will turn up, but with all the people we have online you would think we could still compare what ends up in the Atari and go from there, some one as good as Avery might be able to frankenstein the best together or even restore the desired behavior to the interface. It would still require the handler/program combination to wait for data to stop coming in before drive operations commence.

 

It is strange that mem.sav makes things work, I am to understand that what you see on the real Atari is different as to what is on Altira when running the same atr?

[tschak909]

Ok, Chris.. Try this:

 

Boot your SERCRASH disk.

 

Press 'N' to create mem.sav, Y to create it.

 

Reboot.

 

now load the serial test programs.

 

Do they load okay?

-Thom

[phaeron]

Altirra doesn't use the same loader/relocator or handler as the real 850. It uses replacements rewritten from scratch. The problem is that R: loads at the bottom of memory and the fixed address that DUP.SYS loads at is too low, overwriting the R: handler. As it turns out, this is actually expected behavior even for the real 850 and is documented in the 850 Technical Manual in Chapter 3:

 

 

Caution:The RS-232-C handler shares RAM space with a portion of the DOS utilities. When DOS is called (by typing DOS and pressing RETURN from BASIC), DOS will overwrite the RS-232-C handler and destroy it. To protect against this, add MEM.SAV to your diskette (item N on the DOS Command Menu). Then, when you call DOS, the RS-232-C handler will be saved with your program.

 

[_The Doctor__]

I recall something about the first 6k being copied to mem file before dup.sys loaded. but that shouldn't be an issue when basic cart is not in the machine 4/800 or selected (XL XE)?

 

PlatoTerm should have loaded as basic isn't needed.... it shouldn't have gotten stepped on and mem.sav wouldn't be acting on. I always thought 2.5 only modified the address when using mem.sav to give us 'insta dup' which is a niggle over XL vs 130XE

 

This raises another question in my mind, from within DOS menu copying from disk to r: or e: to r: is not possible in 2.5?? unless using perhaps handler re-located?

Edited September 11, 2018 by _The Doctor__

[tschak909]

Altirra doesn't use the same loader/relocator or handler as the real 850. It uses replacements rewritten from scratch. The problem is that R: loads at the bottom of memory and the fixed address that DUP.SYS loads at is too low, overwriting the R: handler. As it turns out, this is actually expected behavior even for the real 850 and is documented in the 850 Technical Manual in Chapter 3:

 

 

 

Yup, that's what I'm seeing.. Putting MEM.SAV on the disk works for now. I've now cut a test release based on DOS 2.5.

 

https://github.com/tschak909/platoterm64/releases/tag/TEST_20180911

 

-Thom

[sanny]

Thanks, Avery!

 

Bah! I used to know that. 10 to 15 years ago. Funny how one forgets things over time...

 

After creating MEM.SAV, SERTST.COM and SERTST2.COM work, in Altirra and on real Atari.

 

regards,

chris