Side2 with U1MB

[flashjazzcat]

This appears to work in both directions (getting and setting the date/time):

 

 

Have sent to Marius for testing.

[flashjazzcat]

Briefly tested driver with source code (based on code from the 'Z:' driver in the U1MB PBI BIOS):

 

SpartaDOS 3.x DS1305 RTC driver.zip

 

The driver relocates to and raises MEMLO and patches into the VGETTD and VSETTD vectors. It appears to work with TDLINE. I'm sure it can be shrunk and optimised a little once any bugs are fixed. ULTD is for U1MB machines, while SIDETD targets the SIDE clock.

 

 

Edited September 9, 2019 by flashjazzcat

[Jeffrey Worley]

3 hours ago, flashjazzcat said:

Briefly tested driver with source code (based on code from the 'Z:' driver in the U1MB PBI BIOS):

 

SpartaDOS 3.x DS1305 RTC driver.zip 4.46 kB · 2 downloads

 

The driver relocates to and raises MEMLO and patches into the VGETTD and VSETTD vectors. It appears to work with TDLINE. I'm sure it can be shrunk and optimised a little once any bugs are fixed. ULTD is for U1MB machines, while SIDETD targets the SIDE clock.

 

 

Wow, I hate to report that it works in Spartados 3.2g and xd32z.dos with either tdline from the Carina kit or the original 1985 tdline, but Moe doesn't get the time.  It either reports 000000000 for time/date (Ansi26/27 moe), or the 18th of September 1985 for earlier versions of Moe.  It looks like moe is using some other vector to get time/date.  I know that TDLINE is required, and that TDline after being loaded must be TD OFF-ed, before loading MOE.  I tried all orders of loading the files, Rverter, ultd, tdline, td off, (insert version of moe here), but all failed.  I did notice that Moe bombed if I loaded the tdline and ultd before the rs232 handler, but that is the only crashy behavior I saw and is normal.  What could MOE be doing to get the time/date?

 

I can give you a hint, I think.  Moe updates it's time/date during the login process by some mechanism provided by the gateway module.  It happens at, I think, line 4080, but I've not been able to dial it any closer than that.  That is an area where it gets a time from a file that reflects the time to enter network mode and suspend user access.  It does some machine language call that I suspect may be the culprit, but since variables aren't set up after break, I can't make it do it when I want.  It does it each time you log on.

 

So Moe updates itself from tdline if tdline was set from an rtime8 automatically or if gateway lines 4000-4090 do thier magic, or if the user manually configures time and date before or after loading tdline, but Not from the ultd.sys (I renamed it .com for convenience) whether tdline is loaded or not or whether tdline is on or off.  How wierd.

 

I don't know the deep coding stuff you do, but I am guessing that there is a mechanism that the RT8 handler built into tdline? uses and that the time/date commands use that the Ultd.sys module is not using?

 

Best,

 

Jeff

[Kyle22]

Do you have a Z: Handler installed?

 

[+Nezgar]

6 hours ago, flashjazzcat said:

Briefly tested driver with source code (based on code from the 'Z:' driver in the U1MB PBI BIOS):

 

SpartaDOS 3.x DS1305 RTC driver.zip 4.46 kB · 4 downloads

 

The driver relocates to and raises MEMLO and patches into the VGETTD and VSETTD vectors. It appears to work with TDLINE. I'm sure it can be shrunk and optimised a little once any bugs are fixed. ULTD is for U1MB machines, while SIDETD targets the SIDE clock.

 

 

Happy to report SIDE2TD.SYS works on my real hardware (SIDE2 only, no U1MB) with Sparta 3.2f after COLD /N from SDX on SIDE2!

 

When used in conjunction with the "CTH Y2K Display Time/Date" TDLINE.XEX (attached) it shows the correct day-of-the-week as well.

 

Onto RealDOS... SIDE2TD.SYS fails with message "Requires SpartaDOS 3.x!" ... The 'SETVER32.COM' trick doesn't work either.

tdline.xex

[_The Doctor__]

some software goes directly to the r-time-8's cart addresses to read them and set their time from there... a bit of modification would be needed to read the new time clock directly or some juggling will be involved to pass along the data...

Edited September 10, 2019 by _The Doctor__

[flashjazzcat]

6 hours ago, Technoid Mutant said:

It looks like moe is using some other vector to get time/date

In that case I give up. If Marius' tool works (possibly because it consumes no extra memory and/or because does not change the time/date vectors), you should use that one. My driver is intended as a complete resident replacement for the RTime-8 clock driver (which means you can set the DS1305 RTC's date and time as well as read it), and as such it raises MEMLO, which perhaps MOE objects to. With both ULTD and TDLINE installed, SD 3.2G's MEMLO climbs to $1FDB.

4 hours ago, Nezgar said:

Happy to report SIDE2TD.SYS works on my real hardware (SIDE2 only, no U1MB) with Sparta 3.2f after COLD /N from SDX on SIDE2!

 

When used in conjunction with the "CTH Y2K Display Time/Date" TDLINE.XEX (attached) it shows the correct day-of-the-week as well.

Great: thanks for confirming. Please test setting the clock as well, since this is really the important extra functionality provided by this driver over other solutions and workarounds.

 

Regarding day of the week: that's worked out in software by TDLINE, but my driver does correctly set the separate day-of-the-week variable in the RTC's NVRAM as well (although neither the U1MB BIOS nor DOS actually relies on it being set correctly; something might, however).

4 hours ago, Nezgar said:

Onto RealDOS... SIDE2TD.SYS fails with message "Requires SpartaDOS 3.x!" ... The 'SETVER32.COM' trick doesn't work either.

That's a cute feature: changing the DOS signature and/or version number at $700/$701, despite the fact RealDOS is basically a re-branded SpartaDOS 3.x. That's gonna block any software which checks to see it's running on SpartaDOS.

 

If you can send me the PEEKed values at $700/$701 under RealDOS, I'll update the driver to work with it. I think I'll combine the SIDE RTC and Ultimate RTC drivers into one executable, as well: it's easy enough to poll the U1MB clock first and then fall back onto checking for the SIDE clock.

[flashjazzcat]

2 hours ago, flashjazzcat said:

If you can send me the PEEKed values at $700/$701 under RealDOS, I'll update the driver to work with it.

OK: I downloaded the ATR from ILS (after being bitterly and pre-emptively reprimanded for unregistered use in the red text above the download link I eventually found after wearing out the scroll wheel on my mouse) and after having my eyes raped by the boot sequence, it turns out that - as expected - $700 = $52 ("R"). The version number is $10. Checking for these values allows ULTD.SYS to work with RealDOS. Will upload updated driver this evening.

[flashjazzcat]

Here's a build of the driver (with source code) which is compatible with RealDOS and BW-DOS:

 

SpartaDOS 3.x RealDOS BW-DOS DS1305 RTC driver v.1.0.zip

 

Resident driver footprint has been reduced to just over 256 bytes, enabling MEMLO to stay under $2000 in BW-DOS. The same driver now works with both U1MB and SIDE/SIDE2 RTCs.

Edited September 10, 2019 by flashjazzcat

[_The Doctor__]

useful bits like this are what makes using the machine a pleasure, thanks for that.  The time and date showing from your gui will be a nice touch.

[Faicuai]

On ‎9‎/‎6‎/‎2019 at 4:59 PM, ebiguy said:

Hi

I am aware that there is a problem with the extension since it was reported several weeks ago.

To be honest, I did not know about the extension that's why I did not test it when patching OSS carts.

I have never used Basic XE and I have yet to get the extension disk.

I will have a look at this issue but give me some time as I am not full time on Atari stuff.

Meanwhile, if anybody has some hints about the diagnostic, it will help when I start working on the issue.

I guess that this kind of issue can be tracked with Altirra.

Sorry for getting back to you so late!

 

The extensions disk is all over the Internet. Attached is a working image of such extensions (for BASIC-XE).

 

BASIC XE Extension Disk.atr

 

The bottom-line is BasicXE will NOT work on either my Ultimate or Incognito setups (REAL HW). Without extensions, they will eventually lock-up after issuing instructions or loading some programs (especially when calling them with "CAR" command, after booting SDX). And As for Extensions, they just make BasicXE crash right after loading.

 

Also, please, consider that there is a special version of BasicXE that was patched (in the past) specifically for SDX, here's attached:

 

BASIX_XE-v41_SDX_patch.arc

 

I don't think it directly address the issues we are having today with BasicXE on SIDE 1/2, but you may want to take a look at it, and decide whether you would like to incorporate such patches on yours.

 

A big thanks, in advance, for all your great work, here!

Edited September 10, 2019 by Faicuai

[_The Doctor__]

Yes you use the patched for SDX (but not incog/side/ult) BASICXE and follow the Action guidelines (and subsequent BXE guidelines) in the SDX manual pdf based on the memory you have available.

[Jeffrey Worley]

15 hours ago, flashjazzcat said:

In that case I give up. If Marius' tool works (possibly because it consumes no extra memory and/or because does not change the time/date vectors), you should use that one. My driver is intended as a complete resident replacement for the RTime-8 clock driver (which means you can set the DS1305 RTC's date and time as well as read it), and as such it raises MEMLO, which perhaps MOE objects to. With both ULTD and TDLINE installed, SD 3.2G's MEMLO climbs to $1FDB.

Great: thanks for confirming. Please test setting the clock as well, since this is really the important extra functionality provided by this driver over other solutions and workarounds.

 

Regarding day of the week: that's worked out in software by TDLINE, but my driver does correctly set the separate day-of-the-week variable in the RTC's NVRAM as well (although neither the U1MB BIOS nor DOS actually relies on it being set correctly; something might, however).

That's a cute feature: changing the DOS signature and/or version number at $700/$701, despite the fact RealDOS is basically a re-branded SpartaDOS 3.x. That's gonna block any software which checks to see it's running on SpartaDOS.

 

If you can send me the PEEKed values at $700/$701 under RealDOS, I'll update the driver to work with it. I think I'll combine the SIDE RTC and Ultimate RTC drivers into one executable, as well: it's easy enough to poll the U1MB clock first and then fall back onto checking for the SIDE clock.

I've heard that RealDos is just SD32 in drag, but there are a whole lotta utilities added on.  I thought it might be an incarnation of Tom Hunt's dos I was beta testing in the early 90's.  He stripped everything out, had an incredibly low memlo, a path for .com files.  Everything was external, copy, everything.  Maybe even dir.  I'm trying to remember what he called it.  He had a hard disk crash and lost the code.  I mentioned it online and he got in touch.  I got him the executables again, but I"VE since lost them.  AH!  I remember now, SRP dos.  I was running my Carina on a MUX using MUXSRP.DOS.

Jeff

[_The Doctor__]

My bet is 3.3 dos, with whatever utilities that could be modified, improved, or re-coded and then version locked or something.

 

SRP!  WOW, I miss Hunt

[+Nezgar]

Steven J. Carden modified/optimized SpartaDOS 3.2 to make 3.3, and it was included for use with BBS Express Pro, or at least that's how I acquired it back in the day. It had 3 variations, A, B, and C. Not sure which specifically, but one of them excluded UltraSpeed SIO to lower memlo a little, and one of them added MUX support.

 

You could say RealDOS was the successor to SpartaDOS 3.3, but it's also highly likely that a lot of it was rewritten from the ground up, as Steve REALLY wanted to get away from the anything to do with SpartaDOS, due to past legal 'debates', but maintain good compatibility.

 

As 'untidy' as the initial dive into RealDOS looks, its pretty clean once you pick and choose components you need and make your own disk. I like exploring the myriad of tools and utilities he's included... He has so many widgets to support all kinds of generations of hardware, ehanced drives, MUX, ramdisks, etc... The released disk image looks a lot like its just a snapshot of his development environment.

[+Nezgar]

14 hours ago, flashjazzcat said:

Here's a build of the driver (with source code) which is compatible with RealDOS and BW-DOS:

 

SpartaDOS 3.x RealDOS BW-DOS DS1305 RTC driver v.1.0.zip 3.83 kB · 9 downloads

 

Resident driver footprint has been reduced to just over 256 bytes, enabling MEMLO to stay under $2000 in BW-DOS. The same driver now works with both U1MB and SIDE/SIDE2 RTCs.

Amazing work Jon. Tested, yes it works great for getting AND setting time/date, even with RealDOS on a SIDE2 only system!

 

Booting back into SDX after setting  a wonky date shows it keeps.

 

Setting time back with ASPECL TO, or RealDOS TDLINE2 maintains correct time across power cycling on both DOS's.

 

Now why does RealDOS's TDLINE2.COM have to be 7.4KB lol... it has Also combines support for polling time from APE/SIO2PC/AspeQT, R-Time 8, and has correct weekday.. but it takes a while to load off of floppy.

[flashjazzcat]

2 hours ago, Nezgar said:

Tested, yes it works great for getting AND setting time/date, even with RealDOS on a SIDE2 only system!

Many thanks for testing it.

2 hours ago, Nezgar said:

Now why does RealDOS's TDLINE2.COM have to be 7.4KB

LOL!

[Jeffrey Worley]

3 hours ago, flashjazzcat said:

Many thanks for testing it.

LOL!

  6 hours ago, Nezgar said:

Now why does RealDOS's TDLINE2.COM have to be 7.4KB

LOL!

It's mosly occupied by a steganographic ode to Steve Cardin that fortunately no longer bumps memlo.  The previous version displayed the ode at run time and then kept the ram...

 

Best,

 

Jeff

Edited September 11, 2019 by Technoid Mutant

[flashjazzcat]

Realised last night that there's a spurious read from the RTC in the driver's SETTD function; it was needed for the "Z:" driver (since either the date or time were set by the user, not necessarily both), but isn't needed here since the entire buffer is populated with TIMER and DATER every single time. So I should be able to shave another half a dozen bytes off the footprint, then I'll upload the driver to my website now that it appears reliable.

[_The Doctor__]

this time date program is going to be hard to find on AA in relatively short time, it deserves to have all of it moved to an aptly named topic with tags and all that.

on Sparta disk based and variants the time handler is normally 6 bytes or so up under the OS after TDLine or TDLine2 etc has been installed. I don't remember if tline is responsible for setting that up but it might be why some program want you to do tdline and then turn td line off. Is it basically the same under X in that one piece of software could be used for both forms of DOS without too much fuss?

 

 

Hopefully once all the tweaking and optimizations are done all the particulars will be in a document. I don't want to jump the gun so to speak.

Edited September 11, 2019 by _The Doctor__

[flashjazzcat]

On 9/11/2019 at 5:49 AM, Nezgar said:

You could say RealDOS was the successor to SpartaDOS 3.3, but it's also highly likely that a lot of it was rewritten from the ground up, as Steve REALLY wanted to get away from the anything to do with SpartaDOS, due to past legal 'debates', but maintain good compatibility.

I don't think much of it was rewritten from the ground up at all except the externally loaded tools, whose verbosity is probably the sole device used to visually differentiate the system from prior versions of SpartaDOS. The core of the file system handler is functionally identical to that of SpartaDOS, and I don't see why or how one would go about reimplementing the same core file system, especially when the majority of development time appears to have been spent on re-branding. If the file system handler is 100 per cent compatible with SpartaDOS 3.3, there's a good reason for that: it's probably SpartaDOS 3.3. BW-DOS, meanwhile, though somewhat flawed, appears to be a genuine re-implementation of SpartaDOS 3.x based on the functional specification; it runs entirely outside of the shadow RAM, and certain things - such as the fact the VGETTD and VSETTD vectors are part of the COMTAB table, which they are not in SD 3.x - suggests a significant amount of reimplementation took place.

 

My most recent experience of testing RealDOS latest about sixty seconds when I was testing my ULTD driver. After the 'wedge' loaded towards the end of the lengthy boot sequence (which resembled console output generated during the bootstrapping of a mainframe), every keystroke typed at the command line produced dots or 'birdies' all over the screen (presumably the result of bank switching the resident character set).

[Jeffrey Worley]

Yesterday  I tried a stock xl booting from sio with sd32g and the standard tdline etc.  Moe got the time right.  I tried a u1mb, booting from sio and it got the time right.  I tried U1MB booting from Side2 and it gets the wrong date (1985 or 1994) depending on Moe version.  I then tried Side2 with u1mb booting from sio -- same problem.  There is some interaction between the two on-board rtc's that is creating this issue.  Does Side2's rtc work much differently from RT8 or U1MB?  This is a duplicable issue.

 

Best,

 

Jeff

[flashjazzcat]

18 minutes ago, Technoid Mutant said:

There is some interaction between the two on-board rtc's that is creating this issue.

Does this concern the ULTD driver I uploaded earlier?

18 minutes ago, Technoid Mutant said:

Does Side2's rtc work much differently from RT8 or U1MB?

SIDE2's RTC is 100 per cent identical to the U1MB RTC, but at a different address. The RTime-8 RTC is 100 per cent different to both of them. However, DOS and TDLINE do not interact directly with the hardware at all: they interact with the RTC solely via the VGETTD and VSETTD vectors. Therefore how the hardware works is immaterial to software which gets and sets the date and time using the documented calls.

 

The driver (assuming that's what your talking about) first polls for the U1MB clock and if it fails to find it, it polls for the SIDE2 clock. So whether SIDE2 is present or not should make not a bit of difference when one is using a machine equipped with U1MB, unless the driver is having problems detecting the hardware at all. Be sure to use the correct version of the driver, of course (only the most recent one uploaded here polls for U1MB and SIDE).

 

The various booting scenarios you're describing: are you basically saying that things don't work whenever SIDE2 is plugged into the machine? And have you established that DOS (not MOE) is able to obtain the correct time in all scenarios?

Edited September 13, 2019 by flashjazzcat

[Jeffrey Worley]

5 minutes ago, flashjazzcat said:

Does this concern the ULTD driver I uploaded earlier?

SIDE2's RTC is 100 per cent identical to the U1MB RTC, but at a different address. The RTime-8 RTC is 100 per cent different to both of them.

 

The driver (assuming that's what your talking about) first polls for the U1MB clock and if it fails to find it, it polls for the SIDE2 clock. So whether SIDE2 is present or not should make not a bit of difference when one is using a machine equipped with U1MB, unless the driver is having problems detecting the hardware at all. Be sure to use the correct version of the driver, of course (only the most recent one uploaded here polls for U1MB and SIDE).

 

The various booting scenarios you're describing: are you basically saying that things don't work whenever SIDE2 is plugged into the machine? And have you established that DOS (not MOE) is able to obtain the correct time in all scenarios?

RIght, DOS, the TDline gets the date correctly regardless.  (Though I don't know which clock it is referencing), but I thought it strange that with Side plugged into the machine, Moe doesn't get the date right.  That seemed interesting,  a hardware interaction maybe worth knowing about if not actually fixing. Updating Moe from Basic via the Z: device works in all configurations.  With Side2 and U1MB I tried actually entering the date manually to see if Time and Date commands reset the issue, but it still gets the default date with Side2 on U1MB, which is strange.  No great crisis or anything, but interesting.

 

Without Side2 installed I was using, I think, the u1mb only version of the driver, come to think of it.  With Side2 installed I'm using the latest version.  I will update SIO boot to the same version and re-test.

 

Best,

 

Jeff

Edited September 13, 2019 by Technoid Mutant

[flashjazzcat]

11 minutes ago, Technoid Mutant said:

RIght, DOS, the TDline gets the date correctly regardless.

As I suspected.

11 minutes ago, Technoid Mutant said:

With Side2 and U1MB I tried actually entering the date manually to see if Time and Date commands reset the issue, but it still gets the default date with Side2 on U1MB, which is strange. 

OK: so here, are you telling me that setting the date via the DOS DATE and TIME commands only works when SIDE2 is not plugged into the machine?