Jump to content
IGNORED

Indus "doubler"


rcgldr

Recommended Posts

I can now make copies of the Indus "doubler" boot floppy for standard Indus drives (the ramcharger is not needed).

 

Currently the only way I can make these is with a Indus drive with ramcharger, a CPM bootable floppy with a debugger and the init program. The init program copies the boot sectors, but it reads the boot sectors before any user prompts. By using the debugger, I can load the init program, switch to the "doubler" boot floppy, then start the init program running from within the debugger, in which case it reads the "doubler" boot sectors, and then prompts the user to switch to the destination floppy, optionally format the destination floppy and then copy the boot sectors. It also initializes the CP/M directory to empty, which is unneeded in this case, but doesn't cause any problems.

 

I'd like to mail a copy of a "doubler" floppy disk to someone here who has some way of doing an image backup of this floppy or whatever tools the community uses here for this type of stuff.

 

From what I recall, one of the local retailers back in the 1980's was giving away the Indus "doubler" for free to customers that purchased an Indus drive. I wasn't aware at the time of how rare it was.

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

VERY NICE !!!!!!

 

Your "doubler" floppy is a Double-Density one? If so, could you please, inspect the first three sectors, and determine if they carry 128 or 256 bytes?

 

(P.S.: bought my Indus back in the day (~1984), which I loved since day one... but never knew or learned about the Doubler-floppy giveaway...)

 

To this day, I still maintain that, bit-by-bit and gram-by-gram, the Indus-GT has no substitute in the Atari 8-bit constellation.

 

THANKS!!!

Link to comment
Share on other sites

Your "doubler" floppy is a Double-Density one? If so, could you please, inspect the first three sectors, and determine if they carry 128 or 256 bytes?

 

A standard Indus GT is double density and has 2048 bytes of ram, and it appears the intent was to allow an emulation mode, but other than the "doubler", I don't know if there were any other emulation modes, maybe it needed one to work the the Commodore 8 bit computers.

 

The first 3 sectors are 256 bytes, so in my case, making copies required using CP/M mode on an Indus with a ram charger. A PC with a 5.25 inch floppy drive could do this, but the floppy drive needs to be slowed down to about 288 rpm. There's a rpm utility for the Atari 8 bit computers to help set this. I recall adjusting the speed on some very old full height 5.25 inch floppy drives to use with an ATR 8000, using a small screw driver to turn the input to some timing circuit on the drive. I don't know if this is possible on a 5.25 inch floppy that could be purchased today.

 

In another thread I created about copying such a floppy, I got a few responses, but I don't have the software or hardware that was mentioned, and no current way to transfer external files to the Atari.

  • Like 1
Link to comment
Share on other sites

 

A standard Indus GT is double density and has 2048 bytes of ram, and it appears the intent was to allow an emulation mode, but other than the "doubler", I don't know if there were any other emulation modes, maybe it needed one to work the the Commodore 8 bit computers.

 

The first 3 sectors are 256 bytes, so in my case, making copies required using CP/M mode on an Indus with a ram charger. A PC with a 5.25 inch floppy drive could do this, but the floppy drive needs to be slowed down to about 288 rpm. There's a rpm utility for the Atari 8 bit computers to help set this. I recall adjusting the speed on some very old full height 5.25 inch floppy drives to use with an ATR 8000, using a small screw driver to turn the input to some timing circuit on the drive. I don't know if this is possible on a 5.25 inch floppy that could be purchased today.

 

In another thread I created about copying such a floppy, I got a few responses, but I don't have the software or hardware that was mentioned, and no current way to transfer external files to the Atari.

 

THANKS!

 

One last question: could you please, check if the first three 256-bytes sector of the Synchromesh floppy are DIFFERENT than the first three 256-byes sectors of a normally bootable CPM disk on the Indus (e.g. what you get right after invoking INIT targeting a blank or recently formatted floppy on the IndusGT, under CPM)?

Link to comment
Share on other sites

I don't have a synchromesh floppy, or the original CP/M floppies.They're either stored somewhere that I haven't found yet, or I was counting on the ATR-8000 to read/write 5.25 inch floppies for CP/M stuff. I haven't found the 5.25 inch floppy drives I used for the ATR 8000 either, just the ATR 8000 and a heavy cabinet with two full height 8 inch floppy drives, and ADM monitor via the serial port. I have no clue if it sill works yet. That will be a project for next week.

 

What INIT does is read the boot sectors from the currently installed disk, and it does this before any user prompts, so if you're running INIT, it's already read in the boot sectors from the CP/M floppy that INIT was run from. To get around this, I used the debugger (ZSID) to load but not run INIT, then I switched to the Doubler floppy disk, and then run INIT from the debugger. This resulted in INIT copying the boot sectors from the doubler floppy disk (it reads two tracks, but the doubler only needs 5 sectors on the first track, the extra copy doesn't matter, there's nothing on on the doubler floppy disk. The same method could be used to copy 256 byte boot sectors from any floppy.

Edited by rcgldr
Link to comment
Share on other sites

Cannot wait to get hold of this and disassemble it..

That won't be needed, I have the source code. What I don't have at the moment is a way to assemble it an produce a binary, then get it onto a Atari compatible disk. I was using the ATR 8000 for that, but it's I need to setup a space for it, mostly for the twin 8 inch full height floppy drives, an ADM monitor, and I'm not sure if it will work. I still haven't found the 5.25 inch floppy drives I used to create Atari compatible floppy disks.

 

Currently I'm just looking for one or more people here that I can mail a floppy to, hopefully so they can figure out a simpler method to reproduce it.

 

Another issue is I don't have a lot of blank 5.25 inch floppy disks. I'll look into this stuff later on this week. I'd like to be able to get the z80 assembler / tool set and my source files onto a Indus CP/M floppy. I do have a program on a Indus CP/M floppy that will let me transfer files between CP/M and Atari DOS format using the Indus, a second floppy drive, and an 8 bit Atari.

 

If the ATR 8000 will run, maybe I can switch to running it on 5.25 inch or 3.5 inch floppies.

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

Nice to see you with some of the old materials,

 

If you post the source, some of the industrious people here would be able to create boot disks and utils from it,

 

I would be very hesitant to send any originals in the mail, it would be far better to meet someone or have the needed drives purchased or even lent to you... most people love to get together and do this stuff in person though

 

although shipping 8 inch drives would not be the way to go... :) ... they do not fair well as the fedex usps and ups guys all hate how much they weigh and seem to 'drop' them 'accidentally' all along the delivery routes...

 

The Atari preservation thread might be a place to go and get pointers on stream level imaging using SCP or KryoFlux devices.

 

There are a number of individuals who have taken a fancy to creating and modifying 'frankendisks' - they've made standard Atari drive bootable versions of formally standard parallel only disks that were for atr8000, indus, or with apple/Atari compatible file system disks, some flawless some with quirks but all useable.

 

5.25 disks and drives can still be had cheaply enough, and brand new as well...

 

I still have an s-100 in semi usable condition, I have transferred 8 inch to 5.25 inch disks using the great grand daddy of APE, RESPEQT and Kennedy's sio2pc offering.... It is called the 'critical connection'... you may have one and forgotten what it is... it looks like a blue epoxy brick with wires coming out of it... ending in ....a power transformer block, a sio connector and a serial port.

 

Most of the time you can sector copy from the cp/m disk to the Atari disk and have something to work with. Though it sounds like you already have working disks... hopefully some of the fellows here will suggest a more capable sector copier that can handle mixed modes,

 

I'd think the Sparta/ OS A+ crowd would be the best fit for the most helpful and constructive thoughts/tools you could use or need.

Love to see this back in action, uploading the doubler timing emulation code from within Sparta would be nice, as using disks created on the indus, a doubler 1050, and XF 551, are all useable, having them all bootable operating with the same timing, interleave, etc. is much nicer! (not to mention faster, more pleasant)

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

I'm a bit confused. What does this Indus "doubler" do?

Uploads code to the RAM of the Indus GT to have it effectively function as a 1050 ICD US Doubler until it's powered off, which had a lot more software support for it's 'ultraspeed' protocol than the native indus gt protocol.

 

This is cool, because it's software only, and OP claims it works on a standard drive without the ramcharger expansion too.

 

There is a replacement ROM for the indus to do similar, but that requires physical changes.

Edited by Nezgar
  • Like 1
Link to comment
Share on other sites

+

I'm a bit confused. What does this Indus "doubler" do?

As already posted, it uploads code into the RAM of a standard Indus GT to put it into 1050 US double compatible mode. Being able to put a standard Indus GT drive into emulator mode was clearly intended. Code can be loaded into RAM and run by putting in a bootable floppy disk into the drive, holding "drive type" and then pressing "enter" (I usually press "track" after a boot to display the track to see when it goes idle (track 39)). A standard Indus GT ROM has it's own version of a DOS for programs loaded into RAM, it has 2048 bytes of ram, using 256 bytes for sector I/O, a few bytes for the interrupt vectors, leaving about 1700 bytes of space for an emulator program. All of the interrupt vectors go through RAM, so that a booted program can easily replace the vector addresses to do things like intercept host commands for emulation mode.

 

Similar to a PC boot, the Indus only reads one sector, and runs it. The code in from that first sector then reads in the rest of the code.

 

The Indus GT can be used with a Commodore 8 bit computer, which I assume is a different protocol, and I don't know if this is done using a emulator boot floppy, or if they use a different ROM.

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

after a re read, you are make duplicates of the original disk using the cp/m mode to load cp/m debugger,loading init, changing the disk to the doubler emulator emulator during the process, then launching init from there, init reads the boot sectors, and then prompts for a fresh disk writing the whole thing out. That's a very nice way to do it.

 

I have no doubt, the disks will work perfectly and switch the indus to us doubler mode without an issue.

 

I have a few questions about your cp/m disks you are using to start the indus in cp/m..... are these the original INDUS disks that are used to create or are they disks that were later recreated as discussed in these forums where they couldn't get the system to boot and did some work around on the boot sectors to make it function. If you are using the originals and created working disks from them, please outline what you did to create your disks, and possibly upload images of all for comparison against the other versions. (we are crazy about preservation)

 

I have an indus, minus the charger, If you wish I could at least give it a go.

 

I suspect we may need a new tool created as most Atari Sector copiers won't look at full size boot sectors or write them... (though it would be useful beyond all reason to do so for the INDUS, XF, and almost all parallel drive add ons such as the black box floppy board, karin, and atr-8000) Maybe a scripted approach for each interface would be the way to go as they are in native modes during the startup process before firmware walls certain things off when finally serving standard Atari SIO

 

I suspect the black box floppy board task master enhanced sector editor might be able to handle copying the doubler disk, provided it does not try to 'correct' the boot sectors, it would be close to an insert disk and go method as possible... of course using pbi drives for the process :)

Edited by _The Doctor__
Link to comment
Share on other sites

+

 

As already posted, it uploads code into the RAM of a standard Indus GT to put it into 1050 US double compatible mode. Being able to put a standard Indus GT drive into emulator mode was clearly intended. Code can be loaded into RAM and run by putting in a bootable floppy disk into the drive, holding "drive type" and then pressing "enter" (I usually press "track" after a boot to display the track to see when it goes idle (track 39)). A standard Indus GT ROM has it's own version of a DOS for programs loaded into RAM, it has 2048 bytes of ram, using 256 bytes for sector I/O, a few bytes for the interrupt vectors, leaving about 1700 bytes of space for an emulator program. All of the interrupt vectors go through RAM, so that a booted program can easily replace the vector addresses to do things like intercept host commands for emulation mode.

 

Similar to a PC boot, the Indus only reads one sector, and runs it. The code in from that first sector then reads in the rest of the code.

 

The Indus GT can be used with a Commodore 8 bit computer, which I assume is a different protocol, and I don't know if this is done using a emulator boot floppy, or if they use a different ROM.

I have RamCharged GTs here... You may want to PM me, and will try my best...

 

All this comes at a time when I am about to post an Indus-GT performance review under SDX and DosXL+Synchromesh, since I have been tracking for a while some important differences.... and wondering what is the ABSOLUTE limit of Synchromesh code's performance under dos...

 

The results are surprising, though...

 

Cheers!

Link to comment
Share on other sites

I have a few questions about your cp/m disks you are using to start the indus in cp/m..... are these the original INDUS disks that are used to create or are they disks that were later recreated

 

I have an indus, minus the charger, If you wish I could at least give it a go.

 

I have two versions of Indus CP/M floppies. One is the CP/M that I created for Indus and works in double density mode. I didn't go through all of the BIOS, but I did confirm that the INIT program matches my source code for it. I also found a couple of floppies labeled "Dave Small single density CP/M", but they didn't work and i don't recall how I ended up with them. I don't know what, if any changes, were made by Indus to the CP/M that I created for them.

 

There's another program that I called ICDS.COM, which can transfer files between disks, and between CP/M and Atari DOS floppies. I've forgotten if SpartaDos floppies use the same directory structure as standard Atari DOS floppies.

 

Unfortunately, the Z80 assembler I used is on 8 inch floppies for the ATR8000, but I don't know if it will even run anymore, and I can't find the 5.25 inch floppies I had for the ATR800. It should have XMODEM on it so if I can find a PC based XMODEM, I could transfer it that way. I'm pretty sure I used Microsoft's M80 (assembler) and L80 (linker), and it looks like a few web sites have this, so I may be able to get the assembler that way and by using SIO2PC, then ICDS, eventually onto an Indus CP/M floppy. I have the 6502 assembler on an Atari 8 bit floppy so it's only the Z80 assembler I need to find.

Link to comment
Share on other sites

Can you load the source here?

 

Link to source file. Upon entry, the Indus reads and loads sector 1 into 7F00H, and passes the address of the Indus sector buffer in HL. That sector in turn reads sectors 2 through 5 starting at 7C00H, except it branches to 7C00H before transferring sector 5 to 7F00H (to avoid overwrting the first sector code). The code at 7C00H moves sector 5 image to 7F00H, then sets the command interrupt vector to point to the emulator code, and returns. The drive's host interface is handled manually 1 bit at a time using timing loops. Standard rate transfers use the Indus ROM transfer functions. Fast data rate transfers are handled in the emulator code, 76 cycles or 19 microseconds per bit, about 52.6 K baud. It's my understanding that the 1050 doubler is also 19 microseconds per bit. Articles mentions that the speed is 3x from 19.2 K baud to 57.6 K baud or 17.4 microseconds per bit, which it could be on the Atari computer side, but there's enough margin that the bit sampling of the start bit, 8 data bits and stop bit will not cross a data bit boundary since the data bits are sampled at about 1.5 bit times after the start bit to end up near the middle of data bit periods. If data is from Atari to drive, then the stop bit to start bit transition takes a bit less time from the drive's perspective, and if the data is from drive to Atari, the stop bit to start bit transition takes a bit longer from the Atari's perspective.

 

http://rcgldr.net/atari/IDBL.MAC

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

Link to source file. Upon entry, the Indus reads and loads sector 1 into 7F00H, and passes the address of the Indus sector buffer in HL. That sector in turn reads sectors 2 through 5 starting at 7C00H, except it branches to 7C00H before transferring sector 5 to 7F00H (to avoid overwrting the first sector code). The code at 7C00H moves sector 5 image to 7F00H, then sets the command interrupt vector to point to the emulator code, and returns. The drive's host interface is handled manually 1 bit at a time using timing loops. Standard rate transfers use the Indus ROM transfer functions. Fast data rate transfers are handled in the emulator code, 76 cycles or 19 microseconds per bit, about 52.6 K baud. It's my understanding that the 1050 doubler is also 19 microseconds per bit. Articles mentions that the speed is 3x from 19.2 K baud to 57.6 K baud or 17.4 microseconds per bit, which it could be on the Atari computer side, but there's enough margin that the bit sampling of the start bit, 8 data bits and stop bit will not cross a data bit boundary since the data bits are sampled at about 1.5 bit times after the start bit to end up near the middle of data bit periods. If data is from Atari to drive, then the stop bit to start bit transition takes a bit less time from the drive's perspective, and if the data is from drive to Atari, the stop bit to start bit transition takes a bit longer from the Atari's perspective.

 

http://rcgldr.net/atari/IDBL.MAC

The MAXIMUM (effective) throughput I have been able to pull out of the Indus (RamCharged, and running Super Synchro + Track buffer) is 4,500 Bytes / sec (with absolutely no physicial media activity, just pure RamCharge->Z80->SIO->Atari path). All of this, under DOS XL.

 

SpartaDos X 4.49c cannot match that level of performance with its current Indus-acceleration driver. Not close enough, and all of this hand-timed, multiple times. Sparta will kill, however, DosXL in write-speed department, but when it comes to read-operation, DOS XL and Super Synchro will TROUNCE it.

 

Could you verify were the overhead may be? We are still away from 5,200 bytes/sec...

Link to comment
Share on other sites

Fast data rate transfers are handled in the emulator code, 76 cycles or 19 microseconds per bit, about 52.6 K baud. It's my understanding that the 1050 doubler is also 19 microseconds per bit. Articles mentions that the speed is 3x from 19.2 K baud to 57.6 K baud or 17.4 microseconds per bit

I think your observations are pretty accurate. US Doubler 'ultraspeed' negotiates an POKEy divisor of 0xA (10) which is about 52kbit - not quite 3x of the standard 57600 bit rate, which would match POKEY divisor 8 more closely, commonly used on SIO2PC devices that don't support all the non-standard rates.

 

Quick table i threw together of where I've seen various SIO speeds used:

divisor 40 (0x28) Standard 1x SIO 19200bps
divisor 16 (0x10) Indus SynroMesh, Happy Warp Speed, XF551 HighSpeed - 38400bps - 2x standard SIO
divisor 10 (0x0A) Happy/USDoubler UltraSpeed ~52kbps - Not quite 3x
divisor 9  (0x09) 1050 Speedy default ~55kbps (goes faster with HSS copier), Hyper XF - Not quite 3x
divisor 8  (0x08) 57600bps matching Sio2PC standard PC serial rate - 3x standard SIO
divisor 6  (0x06) 69kbps Indus SuperSyncroMesh & 1050 Turbo
Edited by Nezgar
  • Like 1
Link to comment
Share on other sites

rcgldr, you may find Avery Lee's Altirra Hardware Reference manual an interesting read, the product of his (and others) very thorough reverse engineering and observations. Maybe your knowledge will provide additional insight!

 

Description of the operation of the Indus GT starts on page 198: http://www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf#page=198

Edited by Nezgar
  • Like 1
Link to comment
Share on other sites

 

I think your observations are pretty accurate. US Doubler 'ultraspeed' negotiates an POKEy divisor of 0xA (10) which is about 52kbit - not quite 3x of the standard 57600 bit rate, which would match POKEY divisor 8 more closely, commonly used on SIO2PC devices that don't support all the non-standard rates.

 

Quick table i threw together of where I've seen various SIO speeds used:

divisor 40 (0x28) Standard 1x SIO 19200bps
divisor 16 (0x10) Indus SynroMesh, Happy Warp Speed, XF551 HighSpeed - 38400bps - 2x standard SIO
divisor 10 (0x0A) Happy/USDoubler UltraSpeed ~52kbps - Not quite 3x
divisor 9  (0x09) 1050 Speedy default ~55kbps (goes faster with HSS copier), Hyper XF - Not quite 3x
divisor 8  (0x08) 57600bps matching Sio2PC standard PC serial rate - 3x standard SIO
divisor 6  (0x06) 69kbps Indus SuperSyncroMesh & 1050 Turbo

I've since confirmed that USDoubler also runs at exactly 19 microseconds per bit, ~ 52.631 k baud I don' t know why the articles about ultraspeed mention 3x = 57.6 k baud.

Edited by rcgldr
Link to comment
Share on other sites

I've since confirmed that USDoubler also runs at exactly 19 microseconds per bit, ~ 52.631 k baud I don' t know why the articles about ultraspeed mention 3x = 57.6 k baud.

 

I think its just common confusion/assumption that Happy/USDoubler is 3x faster than standard SIO.. sio 19200x3=57600, when in reality its actually ~52Kbps as you have found.

 

Quoting from page 167 of the Altirra Hardware Reference Manual:

"The US Doubler uses POKEY divisor 10, for instance, which gives a communications rate of 52,600 baud."

 

UltraSpeed is also a protocol, which supports negotiating divisors as fast as 0. When used with an SIO2PC via ApeQt/RespeQt or APE you can configure any rate you like depending on the capabilities of the serial port. Divisor 8 = ~57,600bps which would be almost exactly 3x. Its also possible that it's close enough that if divisor 10 was negotiated, and the PC transmits at divisor 8, that the tolerance is close enough to still work as you hypothesized.

Edited by Nezgar
Link to comment
Share on other sites

 

I think its just common confusion/assumption that Happy/USDoubler is 3x faster than standard SIO.. sio 19200x3=57600, when in reality its actually ~52Kbps as you have found.

 

Quoting from page 167 of the Altirra Hardware Reference Manual:

"The US Doubler uses POKEY divisor 10, for instance, which gives a communications rate of 52,600 baud."

 

UltraSpeed is also a protocol, which supports negotiating divisors as fast as 0. When used with an SIO2PC via ApeQt/RespeQt or APE you can configure any rate you like depending on the capabilities of the serial port. Divisor 8 = ~57,600bps which would be almost exactly 3x. Its also possible that it's close enough that if divisor 10 was negotiated, and the PC transmits at divisor 8, that the tolerance is close enough to still work as you hypothesized.

Well bummer that. I always assumed (since I got it back in 89) that my US Doubler was exactly 3X faster. I've been lied to for the past 3 decades.

  • Like 1
Link to comment
Share on other sites

Wow, this document IS a bible...

 

Page 178 of the Altirra Hardware Reference manual spells out all the exact cycles/frequency & resulting bit rates for all the known drives and upgrades!

http://www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf#page=178

 

States USDoubler = 52631.6bps, so your emulator code appears to be bang on with a real US Doubler's rate.

Edited by Nezgar
Link to comment
Share on other sites

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