Side2 with U1MB

[Jeffrey Worley]

9 minutes ago, flashjazzcat said:

As I suspected.

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?

No, I haven't actually tested the Persistence of the time-date commands, so I can't answer what  I think you're asking.  What I used the Time/Date commands for was to see if that would resolve Moe's issue with Side2 in a single session ala the jiffy clock, which does work.  I will test further, answer the question of persistence (does the Time/Date command actually SET the clock's time and date) with one and then the other clock installed, and will test sio and U1MB with the newest version of the driver (side2 on u1mb was the only configuration that was using the latest version) and report.

 

Which clock gets precedence when the combination of Side2 and U1MB are used?  There's a mode bit there in one or ther other I'm sure.

 

Best,

 

Jeff

Edited September 13, 2019 by Technoid Mutant

[flashjazzcat]

OK: many thanks. I have verified that on a machine with no U1MB, the driver does find the SIDE clock. It tries to write a value to an unused area of the RTC's NVRAM and read it back, first targeting the U1MB RTC and - if that fails - the SIDE RTC. If you need a version of the driver which explicitly indicates which RTC is being used, just let me know.

[+Nezgar]

3 hours ago, flashjazzcat said:

OK: many thanks. I have verified that on a machine with no U1MB, the driver does find the SIDE clock. It tries to write a value to an unused area of the RTC's NVRAM and read it back, first targeting the U1MB RTC and - if that fails - the SIDE RTC. If you need a version of the driver which explicitly indicates which RTC is being used, just let me know.

Just a thought... when 'setting' time, why not set both U1MB & SIDE RTC's if present? Now for feature creep - When 'getting' the time, allow the existing priority preference, but allow manual ovverride with a switch, or maybe have some sanity logic to detect if one is 'not set' and use time from the other. Some simple visual feedback of which RTC the time came from would be nice. I'm thinking of occasional cases where my SIDE2 has mysteriously lost it's time, defaulting to 0:0:0 - haven't found the pattern yet what causes it, I don't have a U1MB (yet) so don't know if this condition afflicts that too. Maybe something like "Warning: [U1MB|SIDE] RTC appears unset".

 

Would be nice to figure out a reliable way to reproduce the issue first though. Anyone else seen this happen?  Maybe from having the cart present during memory tests like XRAM, Sys-Check, or  Shoestring's memory tester, if all it takes is some spurious writes to the hardware addresses to wipe it out...

[+Nezgar]

7 hours ago, flashjazzcat said:

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). 

So, most of the ridiculous bootup process is just from the STARTUP.BAT that has been included in the distribution ATR for some reason... (again, it seems to be a snapshot of his personal development environment or something) just press reset once the DOS is loaded to skip all that, it's all unnecessary. Like any other SpartaDOS, copy the .DOS file from that distribution ATR to a new disk along with whatever other commands you actually need, use the BOOT command on it and you have a much simpler startup environment to start with.

 

The text birdies I think ony showed up once his ramdisk driver loaded. It seems Steve set 1 bit of the space character on to indicate bank switching for some reason... But then I use John K. Pickens Hyper-Speed Ramdisk. (which unfortunately does not support D9:) It's waaay faster than SDX's ramdisk.

 

Another trick I figured out with RealDOS... it will not load a highspeed SIO routine by default, which can be enabled with one of the included utilities after the fact, but hold down select on boot and you'll get a menu where you can then press Start to engate the UltraSpeed handler.

[flashjazzcat]

31 minutes ago, Nezgar said:

Just a thought... when 'setting' time, why not set both if present?

Unfortunately I'm trying to keep the driver as small as possible, otherwise MEMLO tends to become uselessly high (i.e. above $2000 under BW-DOS or when the TDLINE is installed under Sparta). I could make the driver even smaller (than 256 bytes or so) if I didn't bother calculating and setting the RTC's day of the week variable, but I do so anyway for the sake of completeness. When an U1MB is present, the SIDE RTC isn't touched at all (either by the U1MB firmware or the RTC driver), and if you don't have U1MB, you can guarantee the driver is working with the SIDE RTC, so there's probably not too much scope for confusion. Perhaps signalling which RTC the driver is using wouldn't hurt, nevertheless. I was basically following the example of the SDX ULTIME driver, which (IIRC) works with both devices, employs the same precedence, and doesn't give any visual feedback regarding which RTC it's driving. Basically my driver is intended as the Sparta 3 equivalent of the ULTIME.SYS driver. I wasn't aware of one existing already, so hopefully this plugs a little gap.

 

I've observed both the U1MB and SIDE (and Incognito) losing the time (and/or the entire contents of the NVRAM) once in a while, usually because of some loose connection in the machine which (presumably) resulted in some invalid SPI communication which either messed one byte of the date/time (which the U1MB firmware sanity checks and resets if corrupted) or the configuration checksum. Happens once in a blue moon (my machines get moved around a lot and dismantled from time to time), though, so not something which registers as an 'issue'.

21 minutes ago, Nezgar said:

So, most of the ridiculous bootup process is just from the STARTUP.BAT that has been included in the distribution ATR for some reason... (again, it seems to be a snapshot of his personal development environment or something) just press reset once the DOS is loaded to skip all that, it's all unnessary.

Yes: that's appreciated. And you are basically left with what appears to be a re-branded SD 3.3.

21 minutes ago, Nezgar said:

But then I use John K. Pickens Hyper-Speed Ramdisk, but unfortunately does not support D9:. (its waaay faster than SDX's ramdisk).

Meh... RAMdisks. Hard disks blow away every RAMdisk with the possible exception of the MIO (and BB?) RAMdisks (basically anything which doesn't have to buffer the sectors).

Edited September 13, 2019 by flashjazzcat
un-closed parenthesis!

[+Nezgar]

1 hour ago, flashjazzcat said:

Perhaps signalling which RTC the driver is using wouldn't hurt, nevertheless.

This information could just be printed when the driver is loaded, the code doesn't have to stay resident. Would an option for a 'read only' mode implementing only VGETTD, but not VSETTD save enough MEMLO bytes to be worthwhile for a user that is trying to be frugal?

1 hour ago, flashjazzcat said:

Basically my driver is intended as the Sparta 3 equivalent of the ULTIME.SYS driver. I wasn't aware of one existing already, so hopefully this plugs a little gap.

Indeed it does! It's kind of fantastic honestly having Disk based sparta able to pull time this way after all this time, I'm was so used to the workarounds of polling time from APE or stick an R-Time 8 in if I wanted correct time when dropping to disk-based Sparta/RealDOS. For that, I am very appreciative. Now I just need a handler for Disk based sparta to access partitions on a SIDE without a PBI BIOS. (of course, 256 byte sector partitions only...)

 

1 hour ago, flashjazzcat said:

Meh... RAMdisks. Hard disks blow away every RAMdisk with the possible exception of the MIO (and BB?) RAMdisks (basically anything which doesn't have to buffer the sectors).

(Sorry this is getting off-topic) In conversation with JKP's BITD regarding his Ramdisk I believe he explained it was so fast because it bank switches only once per sector or maybe doing direct writes to extended memory with no main memory buffering, instead of for every byte, which is maybe why SDX's handler is slower. Whatever the trick is, it would be nice to see it incorporated into SDX's ramdisk.sys code. I would hazard to say JKP's handler IS as fast, or almost as fast as an MIO or BB RAMdisk, but I've been unable to accurately benchmark it using RWTEST. It disables interrupts during I/O, which causes wildly inflated results, so I'll have to stopwatch time some bulk copies sometime.

 

I agree flash "hard disks" generally negate the need for RAMdisks nowadays, but I still like them for ephemeral storage - In the old days, it was pretty much the only (conveniently) copy things with Sparta between disks with 1 drive. Its a place to extract archives to inspect the contents, stuff you're working on 'at the moment' without having to decide where to place them on a persistent storage device, and contribute to 'clutter' buildup. RAMdisks automatically 'clean up' after my day to day mess. There's also the arguments about reducing flash wear and fragmentation on larger disks, which I admit are practically moot nowadays.

 

I've even setup a RAMdisk on my windows PC the last few years to get out of the clutter buildup in download and temp folders, and of course the desktop. (How many people use it as their default download folder? ? )

[flashjazzcat]

2 hours ago, Nezgar said:

This information could just be printed when the driver is loaded, the code doesn't have to stay resident. Would an option for a 'read only' mode implementing only VGETTD, but not VSETTD save enough MEMLO bytes to be worthwhile for a user that is trying to be frugal?

Oh, there's absolutely no resident overhead associated with additional installation prompts; I'm just yet to be convinced they're even necessary (the only purpose I can see at the moment is debugging the driver itself). A read-only version of the driver would be ~70 bytes shorter than the current version; I'm not sure if it's even worth the bother considering Marius' driver already works perfectly well for the purpose of simply populating the system clock with the date and time from the RTC without permanently consuming any RAM whatsoever.

2 hours ago, Nezgar said:

For that, I am very appreciative.

Thank you! Your appreciation is appreciated.

2 hours ago, Nezgar said:

Now I just need a handler for Disk based sparta to access partitions on a SIDE without a PBI BIOS.

Hopefully you'll pull the trigger on an Ultimate 1MB soon. The only reason the SIDE.SYS driver even exists (and before it the MYIDE version of the same driver) is that SDX can load drivers from ROM before the system even attempts to access the hard disk.

2 hours ago, Nezgar said:

In conversation with JKP's BITD regarding his Ramdisk I believe he explained it was so fast because it bank switches only once per sector or maybe doing direct writes to extended memory with no main memory buffering, instead of for every byte, which is maybe why SDX's handler is slower.

Yes: the problem with RAMdisks which use PORTB RAM is that the data being transferred can be (and commonly is) in the same address space (i.e. $4000-$7FFF) as the banking window used to access the RAMdisk. The way around it is to either bank-switch once per byte, or some multiple thereof (caching however many bytes in between). Unfortunately caching - say - 16 bytes at a time between bank-swaps introduces yet a further overhead of copying which will partially offset the saving in writes to PORTB. Some optimisation would be possible, of course: direct copying if the buffer address is outside of the banking window entirely, for example. I don't know if the SDX driver does this.

 

I guess the MIO and BB RAMdisks use a banking window in the PBI IO space somewhere, so the buffer address and the target sector are never in the same address space. IDE hard disks are faster than anything else largely because of the fact the ATA controller handles the byte indexing inside the logical sector: so 512 unindexed absolute reads or writes from or to the data register, with indexed addressing only needed for the buffer in the Atari's RAM. Aside from seek times, which are rather slight, bandwidth is entirely governed by how tightly one can code a loop (and then unroll it by a factor of sixteen or so).

Edited September 13, 2019 by flashjazzcat

[+Nezgar]

Found some documentation for jkp's ramdisk handlers included in the files posted here: http://www.mixinc.net/atari/download_a8/sdcom.htm

 

This blurb from the documentation provides some interesting insight "from the horses mouth."

 

Quote

The RD's operate without a buffer which saves 256 bytes of low memory. This method and use of self-modifying code, enables them to access sectors faster than any other available handler (up to three times faster than the X cartridge RD).

 

[+Nezgar]

On 9/10/2019 at 8:45 AM, 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 · 28 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.

Is this the latest version? If not, is it on your website somewhere? Tks

[flashjazzcat]

41 minutes ago, Nezgar said:

Is this the latest version? If not, is it on your website somewhere?

On the toolkit:

 

https://atari8.co.uk/apt/toolkit/

[+Eyvind Bernhardsen]

8 minutes ago, flashjazzcat said:

On the toolkit:

 

https://atari8.co.uk/apt/toolkit/

I'm not Nezgar, but thanks! Fair warning, though: the version on the toolkit disk yields a higher memlo than the older build ($1FFF vs $2007 for me).

[flashjazzcat]

49 minutes ago, Eyvind Bernhardsen said:

Fair warning, though: the version on the toolkit disk yields a higher memlo than the older build ($1FFF vs $2007 for me).

Yes. Bug fixes pushed it up. If this is a problem, I will try to shrink it 

[+Eyvind Bernhardsen]

4 hours ago, flashjazzcat said:

Yes. Bug fixes pushed it up. If this is a problem, I will try to shrink it 

Well, it breaks the one thing I use BW-DOS for (a .hex converter for joy2pic that refuses to work in SpartaDOS X and loads at $2000), but I'll just use the older driver. I only need it to get the timestamp on the generated executable right 

[drac030]

16 minutes ago, Eyvind Bernhardsen said:

a .hex converter for joy2pic that refuses to work in SpartaDOS X

READHEX? You have to run it with the X command.

[+Eyvind Bernhardsen]

6 minutes ago, drac030 said:

READHEX? You have to run it with the X command.

Ahaha, that works! Thanks

[flashjazzcat]

36 minutes ago, Eyvind Bernhardsen said:

Well, it breaks the one thing I use BW-DOS for (a .hex converter for joy2pic that refuses to work in SpartaDOS X and loads at $2000), but I'll just use the older driver. I only need it to get the timestamp on the generated executable right 

OK - let me sort that out. $2000 is the magic MEMLO number anyway. One older version - IIRC - had a serious bug which broke reset-protection.

 

[flashjazzcat]

2 hours ago, Eyvind Bernhardsen said:

Well, it breaks the one thing I use BW-DOS for (a .hex converter for joy2pic that refuses to work in SpartaDOS X and loads at $2000), but I'll just use the older driver. I only need it to get the timestamp on the generated executable right 

Please test this and see if MEMLO is acceptable now:

 

ultd_1.23_fix.zip

 

The resident part is about a dozen bytes shorter than the last version (I completely jettisoned one buffer).

 

Does anyone actually have a Y2K fixed TDLINE, BTW? The one from the other thread still claimed it's Tuesday.

Edited May 22, 2021 by flashjazzcat

[flashjazzcat]

Whoops... missed a relocation label. Fixed and re-uploaded.

[+Eyvind Bernhardsen]

1 hour ago, flashjazzcat said:

Please test this and see if MEMLO is acceptable now:

 

ultd_1.23_fix.zip 880 B · 0 downloads

 

The resident part is about a dozen bytes shorter than the last version (I completely jettisoned one buffer).

 

Does anyone actually have a Y2K fixed TDLINE, BTW? The one from the other thread still claimed it's Tuesday.

Memlo is back to $1FFF with this version and I've verified that files are created with the correct time stamp (I don't have TDLINE at all). Thanks!

 

It's a bit odd that the difference is only 8 bytes, but perhaps that's a BW-DOS oddity.

[flashjazzcat]

5 minutes ago, Eyvind Bernhardsen said:

Memlo is back to $1FFF with this version and I've verified that files are created with the correct time stamp (I don't have TDLINE at all).

I appreciate it. Thank you.

5 minutes ago, Eyvind Bernhardsen said:

It's a bit odd that the difference is only 8 bytes, but perhaps that's a BW-DOS oddity.

MEMLO is completely indeterminate since the entire driver is relocated down to low memory at run time. I started with $1BA2 here with Sparta 3.2g and $1CBD after installation. TDLINE.COM (which still says 'Tuesday') of course pushes things up further ($1FA3).

Edited May 22, 2021 by flashjazzcat
typo