_The Doctor__ Posted June 29, 2018 Share Posted June 29, 2018 ah, keeping the sector layout the same but pushing the speed limit might be possible but DOS's might need to be aware then... I wouldn't mess with the interleave too much... it will inevitably make inter-opt-ability of disk reads across indus, 1050 usd, happy, xf..... very slow on reads depending on the drive... the whole idea is to make this seamless and work speedily across the board.... the next cool thing would be to synchromesh the US Doubler roms DoublerMesh Bridging Indus and ICD US Doubler drives as a unified image... who knows where it could lead? a modified XF rom as well? etc. WE ALWAYS GET CARRIED AWAY, though sometimes the results are super c00l! 1 Quote Link to comment Share on other sites More sharing options...
Nezgar Posted June 29, 2018 Share Posted June 29, 2018 Hehe, yep very exciting to think of the possibilities at this point. it's just so tangible now! You're right keeping the skew the same would be best for compatibility, and this will be the case with most common ultraspeed skew formatters since it's sent in software. Increasing the SIO divisor I'm hoping would be a somwehat minor incremental improvement, and at least allows someone (like me ) to test formatting with faster custom skews to see how fast a non buffered drive really can go. Buffering would definitely be the next real practical benefit, as reducing the wait time between sector request and response is the key reason most RWtests are about half the SIO rate... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 29, 2018 Share Posted June 29, 2018 (edited) divisor 0 interleave? lol think that require straight on track buffer/disk buffer.... ... makes you wonder just what a real drives sio limit actually is or could be.... Edited June 29, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Nezgar Posted June 29, 2018 Share Posted June 29, 2018 (edited) SpartaDOS and many high speed patches already work well with divisors faster than 3x. Lots of people using divisors all the way to 0 with SIO2PC interfaces, ie with Hias highspeed patch. Divisor 6 is still pretty stable with stock sparta SIO drivers too. I think the existing SDX INDUS.SYS uses a faster than 54000 bps divisor, but continues to format with same ultraspeed skew. Edited June 29, 2018 by Nezgar Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 29, 2018 Share Posted June 29, 2018 Real drives may have chips that are not be able to drive the sio at those speeds, so it's and interesting limit to explore...getting the divisor up and the skew until it breaks While sio2sd and APE/Respeqt can do divisor zero all day, real drives might not.... Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted June 29, 2018 Share Posted June 29, 2018 Another way to do it is to check if buffer+5 =4 and buffer+7 = $80 then format = enhanced. Not sure if it will result in more compact code tho. As a side note, ICD usd rom also accepts a smaller value for number of tracks in its special format command. So you could format a disk with 3 tracks if you wanted or mixed mode disks. No idea why you would do that tho. James Quote Link to comment Share on other sites More sharing options...
Nezgar Posted June 29, 2018 Share Posted June 29, 2018 Real drives may have chips that are not be able to drive the sio at those speeds, so it's and interesting limit to explore...getting the divisor up and the skew until it breaks While sio2sd and APE/Respeqt can do divisor zero all day, real drives might not.... Exactly what I'd love to see we know the GT hardware is at least capable of 68kbps since that's what it's native SyncroMesh operates at. Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 29, 2018 Author Share Posted June 29, 2018 (edited) For the Doubler rate of 52.6K baud or 19 us per bit, on a standard (no track buffering) drive, for 18 256 byte sectors, the interleave for ultra-skew is 7, so 7 revolutions per track, and one more revolution for a track step, so a total of 8 revolutions per track for sequential read / write operation. I tried using an interleave pattern of 7, 7, 6 (6 on track wrap around) and it ended up slower due to missing sectors and costing a revolution. For 128 byte sectors, the gap at the end of a track is a bit longer than sector to sector gaps, so for 18 128 byte sectors, the interleave pattern is 5,5,5,4, with the 4 occurring on track wrap around. For 26 128 byte sectors, the pattern is 7,7,7,6 (the 6 on track wrap around). Both of these 128 byte sector patterns start with sector 4, so that reading from sector 1 to the last sector doesn't break up the pattern (the actual issue is placing sector 18 4 sectors away from the end of a track for the 5,5,5,4 pattern and sector 26 6 sectors away from the end of a track for the 7,7,7,6 pattern). This also increases the distance from the last sector on a track to the first sector on the next track, which may save a revolution on a sequential read / write. For 256 byte sectors, the interleave is fixed at 7 (7,7,7). The GT super syncromesh is 14.5 us per bit on the drive side, while on the Atari side, using a divisor of 6 for 895000/(6+7) = 68846 bps, close to the 68695.5 bps stated for supersyncromesh rate and corresponding to 14.5 us per bit. 14.5 us per bit is possible with the Indus GT Z80 running at 4 Mhz, but the 1050 6502 runs at 1 Mhz, so it can't do a xx.5 us per bit transfer rate. Keep in mind that the Indus GT and Atari 1050 don't have UARTS, and use timing loops to fix the delay per bit. Edited June 29, 2018 by rcgldr 5 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 29, 2018 Share Posted June 29, 2018 Exactly what I'd love to see we know the GT hardware is at least capable of 68kbps since that's what it's native SyncroMesh operates at. Wait! But what you guys NEED to see is how fast the Indus works within a pure CP/M environment! I have clocked 7,200 bytes / sec. loading Microsoft Basic Compiler... around 4.1 secs... That is (relatively) way higher than ANYTHING I have been able to extract on SDX via SIO... So it is clear that a pure disk-surface / WD-controller / [Z80 + ROM] / RAM read pipeline seems to be able to operate at a nominal throughout that is HIGHER than SuperSyncho or ANYTHING you can get in SDX, even with a pre-formatted SuperSynchro. floppy... To understand the meaning of all this, all you need to look at is the MAX. speed attainable in SDX + SuperSynchro. format: around 3,400 Bytes / sec. We are a LONG WAY to reach 7,200 Bytes/sec (!!!) 2 Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 29, 2018 Author Share Posted June 29, 2018 (edited) Another way to do it is to check if buffer+5 =4 and buffer+7 = $80 then format = enhanced. Not sure if it will result in more compact code tho. As a side note, ICD usd rom also accepts a smaller value for number of tracks in its special format command. So you could format a disk with 3 tracks if you wanted or mixed mode disks. No idea why you would do that tho. James True, but at that point in the code, A already has the sectors per track count, since it was needed to put a terminator on the interleave table used by the Indus ROM. I could save a branch instruction by changing the sequence to "LD A, EMU1050 | JR Z,FNI1", but there are 40 bytes of space left out of the 1024 bytes in the current Indus Doubler for a standard Indus GT emulator load, so I haven't tried to optimize for space yet. As for the number of tracks, the received parameter field already puts the number of tracks in the same place that the Indus GT ROM wants it for formatting. As for the Indus CP/M, the interleave factor is 2, but with no apparent track skewing, it's 3 revolutions per track on sequential read / writes. Track buffering with ramcharger could be clever by doing something similar to SIO2PC by reading sectors out of order to end up with an effective interleave of 2, after determining interleave factor on the first track read. Edited June 29, 2018 by rcgldr 2 Quote Link to comment Share on other sites More sharing options...
lemiel Posted June 29, 2018 Share Posted June 29, 2018 With this Doubler enabled is super/synchromesh still available? And X command? Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 29, 2018 Share Posted June 29, 2018 With this Doubler enabled is super/synchromesh still available? And X command? NO. Indus-Doubler is an emulation-layer of US-Doubler, exclusive for Z80-powered IndusGTs. You will need to power-cycle the drive to uninstall it. SuperSynchro covers SIO acceleration, disk-level-formatting, and dynamic sector-cache (or "track buffering" with RamCharger 64KB board) all in one package. And it runs faster (read-ops) than Indus-Doubler (although I suspect for not too long). Cheers! Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted June 30, 2018 Share Posted June 30, 2018 Wait! But what you guys NEED to see is how fast the Indus works within a pure CP/M environment! I have clocked 7,200 bytes / sec. loading Microsoft Basic Compiler... around 4.1 secs... That is (relatively) way higher than ANYTHING I have been able to extract on SDX via SIO... So it is clear that a pure disk-surface / WD-controller / [Z80 + ROM] / RAM read pipeline seems to be able to operate at a nominal throughout that is HIGHER than SuperSyncho or ANYTHING you can get in SDX, even with a pre-formatted SuperSynchro. floppy... To understand the meaning of all this, all you need to look at is the MAX. speed attainable in SDX + SuperSynchro. format: around 3,400 Bytes / sec. We are a LONG WAY to reach 7,200 Bytes/sec (!!!) Here is the sector layout for indus CP/M init program. SECTMAP DEFB 01,10,02 ; 81CA 010A02 ... DEFB 11,03,12 ; 81CD 0B . DEFB 04,13,05 ; 81D0 04 . DEFB 14,06,15 ; 81D3 0E06 .. DEFB 07,16,08 ; 81D6 07 . DEFB 17,09,18 ; 81D9 110912 ... DEFB 128 ; 81DC 80 . Not quite fast enough for 1:1 James 1 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 30, 2018 Share Posted June 30, 2018 Here is the sector layout for indus CP/M init program. SECTMAP DEFB 01,10,02 ; 81CA 010A02 ... DEFB 11,03,12 ; 81CD 0B . DEFB 04,13,05 ; 81D0 04 . DEFB 14,06,15 ; 81D3 0E06 .. DEFB 07,16,08 ; 81D6 07 . DEFB 17,09,18 ; 81D9 110912 ... DEFB 128 ; 81DC 80 . Not quite fast enough for 1:1 James Not sure how that correlates to actual throughput, though. The reality (what really happens out there) is that 32KBytes (Microsoft Basic Compiler for CP/M) get loaded in 4.2s, from end-to-end, day-in, day out, whether it is the first or the N load-attempt, right from the CP/M prompt. And that translates to 7,619 Bytes / sec, and it is happening as we speak in my Indus + CP/M setup... It WILL NOT happen, however, with the CP/M disks that I initially downloaded as the most "current" from the web, at the site dedicated to this preservation. The above is giving us a glimpse of what this drive is potentially capable of. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 30, 2018 Share Posted June 30, 2018 (edited) I am pleased as punch that we have doubler emulation making the INDUS the choice for other DOS use with the INDUS.... very nice indeed. This for me, it's a big deal... Edited June 30, 2018 by _The Doctor__ 3 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 30, 2018 Share Posted June 30, 2018 I am pleased as punch that we have doubler emulation making the INDUS the choice for other DOS use with the INDUS.... very nice indeed. This for me, it's a big deal... Now, IMAGINE this: You are right at Incognito's / Ultiamate's FlashJazz's wonderful BIOS screen. Go to the SIO menu (the dual-end SIO-cable shaped icon). Plenty of entry-space left on menu... Select / toggle an option that says "Upload INDUS-DOUBLER", right from BIOS (!) Imagine we could also re-flash Indus-Doubler somewhere in the BIOS... Now you are talking about finding a mainstream channel for Indus-Doubler, everywhere! Would not that be lovely? We will never have to upload via external floppy (NOTHING wrong with that, considering that it takes 1.5 secs), but we will not have to worry about finding the floppy either... Very, very nice opportunities, if you ask me... 1 Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 30, 2018 Author Share Posted June 30, 2018 (edited) Note that despite actual sector size, CP/M file read interface reads 128 bytes at a time, so the CP/M "bios" holds on to a sector buffer, and the pair of calls to read a 256 byte sector may explain the need for an interleave of 2, and the Indus may not have DMA. I don't recall if the ATR8000 also needs an interleave of 2 for it's CP/M disks or if it has DMA. It's sector sizes go up to 1024 bytes. A PC has DMA to read/write with a floppy and usually one or more clusters of sectors at a time (more than one at a time if a files clusters are sequential), so it uses an interleave of 1. To speed up PC sequential I/O, I use a track skew factor of 1/3rd the track size, (for 9 sectors per track, sector 1 will be located 3 sectors later on each successive track). Edited June 30, 2018 by rcgldr 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted June 30, 2018 Share Posted June 30, 2018 As far as the BIOS thing goes, it sounds great, but WHERE would you store the code that gets loaded to the drive? There's not enough space for it in the BIOS area. It would be far easier to make a SDX INDUBLR.SYS file to use in CONFIG.SYS. 2 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted July 1, 2018 Share Posted July 1, 2018 As far as the BIOS thing goes, it sounds great, but WHERE would you store the code that gets loaded to the drive? There's not enough space for it in the BIOS area. It would be far easier to make a SDX INDUBLR.SYS file to use in CONFIG.SYS. No, no, that defeats the essence or main goal of Indus-Doubler. If there is NOWHERE to flash it on Incognito 512K flashable space or PBi BIOS, then the mext best option is to use an executable with SIO access, which you would load via "L" loader, from main BIOS screen, and have it upload it to D1, D2 or any Indus drives it sees on the SIO chain. In this way, it will work with EVERYTHING, including SDX, and a *.sys will NOT be neeed in SDX as that is exactly how it operates today when uploaded from floppy & Drive / Error buttons. Cheers! 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 1, 2018 Share Posted July 1, 2018 No, no, that defeats the essence or main goal of Indus-Doublrer. If there is NOWHERE to flash it on Incognito 512K flashable space or PBi BIOS, then the mext best option is to use an executable with SIO access, which you would load via "L" loader, from main BIOS screen, and have it upload it to D1, D2 or any Indus drives it sees on the SIO chain. In this way, it will work with EVERYTHING, including SDX, and a *.sys will NOT be neeed in SDX as that is exactly how it operares today when uploaded from floppy & Drive / Error buttons. Cheers! The existing SDX INDUS.SYS sets up the Indus to operate in it's XF like Synchromesh high speed. This is different from Ultraspeed. It would be nice to have both available for SDX. Possibly a unified driver with a switch? DEVICE INDUS /U for example. I like the Loader idea. 1 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted July 1, 2018 Share Posted July 1, 2018 The existing SDX INDUS.SYS sets up the Indus to operate in it's XF like Synchromesh high speed. This is different from Ultraspeed. It would be nice to have both available for SDX. Possibly a unified driver with a switch? DEVICE INDUS /U for example. I like the Loader idea. Did you notice the 16K space called "Recovery OS" in Incognito's ROM-space layout, as shown in UFLASHer? I captured what originally was there and stored it on HW for backup... it looks like an old Incognito BIOS (Candle's era)... But not really sure if it is effective or operational... I can't find any mention of it, anywhere... 2 Quote Link to comment Share on other sites More sharing options...
rcgldr Posted July 1, 2018 Author Share Posted July 1, 2018 If a standard Indus has a SIO command similar to the button boot command that would transfer a loader into the 1024 byte area, which in turn would use SIO commands to load the actual doubler or any emulator code, that could be used instead of a button boot, but how would you get the code to do this in the Atari, perhaps a cartridge? Quote Link to comment Share on other sites More sharing options...
Nezgar Posted July 1, 2018 Share Posted July 1, 2018 (edited) If a standard Indus has a SIO command similar to the button boot command that would transfer a loader into the 1024 byte area, which in turn would use SIO commands to load the actual doubler or any emulator code, that could be used instead of a button boot, but how would you get the code to do this in the Atari, perhaps a cartridge? there's quite a few programs that do this sort of thing for Happy and 1050 upgrades. For example, the 'Happy.com' included with RealDOS will upload relocated US Doubler to Happy RAM and execute it, so it becomes an emulated us doubler until powered off, and at least a few others that do the same. Just a DOS executable, or bootable disk that sends the sio commands to the drive. there's other utilities that do the same to have it operate as a 1050 archiver/Chip, or a stock 1050 again. This would be the easiest way if the indus has a command to upload and trigger execution of the code via SIO. I don't know for sure, but I figured the INDUS.SYS with SDX does something like this. Maybe that should be checked out to see how it's doing it? Or analyse the SIO commands it's sending to the drive. Edited July 1, 2018 by Nezgar Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 1, 2018 Share Posted July 1, 2018 (edited) The boot floppy is still the way to go until then, the upload of (high-speed or emu) code as done in Sparta etc. the biggie is to do it for all the DOS versions. For MyDOS an AR0, AR1, etc.. for AtariDos chained autoruns etc... and for those who use OSS A+ DosXL Sparta the usual batches, .sys cfg etc. Edited July 1, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 1, 2018 Share Posted July 1, 2018 The recovery BIOS area sounds promising, but how can that area be accessed? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.