Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

rcgldr

Members
 View Profile  See their activity

  • Content Count

    135

  • Joined

  • Last visited

Posts posted by rcgldr

  1. Posted · Edited by rcgldr

    I tested rates with SpartDos 2.3.

     

    Using SpartaDos with floppy formatted on the 1050 with interleave of 7, the 1050 doubler is a bit faster on writes than the Indus doubler. 2900 bytes per second versus 2500 bytes per second. Both of them read just under 3000 bytes per second. The 1050 takes longer to format, one more revolution per track than the Indus, but I'm not sure what that means. I repeated the test, this time formatting on the Indus with interleave of 7 (doing this using XINIT from SpartaDos 2.3). Speeds about the same, Indus write speed was a bit less at 2400 bytes per second, but it could be a variation in where the test file is located (what sector of a track the write starts from).

    Translating the rates = Indus write rate (2457 bytes per second) is equivalent to an interleave of 9, while 1050 write rate (2997 bytes per second) is equivalent to an interleave of 7.389 (7 + 7/18), so there is some form of track skewing during format. It seems unlikely that the drive track skews by analyzing the interleave table, and it's more likely that it's just a fixed delay after stepping the head to format each track.

    The write times using the APE interface are faster because it's all sequential writes, no directory or linkage updates.

  2. Posted · Edited by rcgldr

    I've been trying to benchmark read and write times with the Indus master super-sync atr file (DOS XL 2.35I2), using INITSYNC to format a real floppy on the Indus GT. When I run a write read test, the read rate is ~3686 byte per second, which would correspond to an interleave of 6, but the write test is ~ 900 bytes per second, which would correspond to an "interleave" of 24 (18 + 6), like a full rotation after every sector write. I though verify was stuck on, but it's using command hex D0 ("P" + hex 80) for writes without verify, and D7 ("W" + hex 80) for writes with verify, slower still at 517 bytes per second, which would correspond to an "interleave" of 42 (18 + 18 + 6).

  3. Posted

    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?

  4. Posted · Edited by rcgldr

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

    • Like 1

  5. Posted

    Bally Astrocade joystick with pinout swap adapter cable.

     

    http://rcgldr.net/atari/ballystm.jpg

     

    The joysticks have light touch, short throw, but there's only 1 button (a trigger). The knob on the top is a pot, used for games like gunfight or football to move the character's arm independently of the characters movements, and I don't use it for the Atari.

     

    For PC, I use CH USB joysticks (flightstick + combatstick), again a light centering touch, but these are fairly expensive. I use them as a pair, similar to radio control, left stick forward/back for throttle, right stick left/right for steer. For aircraft, left stick left/right for rudder (or helicopter yaw), right stick forward/back for elevator. I also have Real Flight USB transmitter, based on a Futaba transmitter mechanics.

  6. Posted

    Link to zip of atr file:

     

    http://rcgldr.net/atari/ivptfl.zip

     

    It is a bootable game loader, where one of the games is Pitfall 2 modified so that if the player's character is touched by one of the animals it won't reset the player's position to a prior checkpoint, but the animal graphics make look a bit weird if there is a touch. This doesn't include the rat near the start that pushes the character off a ledge into the water, it only prevents the reset to last checkpoint position.

     

     

     

     

     

    • Like 1

  7. Posted · Edited by rcgldr

    Is there a list of games that run from floppy disks here? I have about 20 atr images, each image includes a directory display and game loader for a collection of 8 bit games on each floppy image, but all of them could be duplicates of what is already here. The only possible unique feature is that some of the images use doubler interleave and transfer rate for quick loading.

  8. Posted · Edited by rcgldr

    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.

    • Like 2

  9. Posted · Edited by rcgldr

    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.
    • Like 5

  11. Posted · Edited by rcgldr

    Not talking about double.

    Remember enhanced is 26 128 byte sectors using MFM. I dont see where this is checked and 1050 mode set if required.

     

    James

    Based on the timing, the Indus is either trying to format 26 128 byte sectors in single density or 26 256 byte sectors in double density, overwriting the tracks, causing this problem. I'll look into this.

  12. Posted · Edited by rcgldr

    Not talking about double.

    Remember enhanced is 26 128 byte sectors using MFM. I dont see where this is checked and 1050 mode set if required.

     

    James

    I knew about that. I only have Sparta Dos 2.3, since this was one of the formats back then, there should be someway I can force this? Currently I edit on PC, use SIO2PC software to go from mirrored single density to double density image using DOS, then boot into CP/M and use ICDS to transfer to CP/M, where I can build a test code. ICDS doesn't support single density dos transfer, and APE mirror doesn't support double density dos emulation, so there's an extra step. I'll check to see if there's enough space to put Wordstar on a "build" floppy for CP/M so I can do this from CP/M and then update the PC file later. I'm low on floppy disks, but I've ordered some and it's currently being shipped, which should help.

  13. Posted · Edited by rcgldr

    I ask this because the special format command doesn't check for 1050 emulation. It sees 128 bytes sectors and assumes single density but with 26 sectors. So my guess is it wont work.

     

    James

    There's a check here for double density from the parameter buffer + 7 in the format with interleave function on line 407. It's been so long that I don't recall if I verified this.

    	LD	A,(BUFFER+7)	;BR IF SGL DENS
	SUB	80H
	JR	Z,FNI0
	LD	A,EM815		;SET 815 MODE
FNI0:	CALL	FMT

  14. Posted

    Did you try enhanced density format with skewed sectors? I don't believe The code properly supports that. Should be an easy fix tho.

     

    James

    For "skewed" or "interleaved" sectors, assuming the Atari side uses the "f" format with interleave command, the interleave table is part of the command (along with number of sectors per track), which the Indus doubler passes along to the Indus firmware for a format.

  15. Posted · Edited by rcgldr

    I forgot to mention, dblr2.atr only added two lines of code to the entire program, used for the verify after write ("W") command, starting at line 299 in XDBL.MAC. Before this change, the compare loop just compared the first byte either 128 or 256 times. Note this is only done if the CRC is good. The odds of a good CRC with bad data are pretty low, about 1 in 65536. Floppy CRC is the product of two binary "prime" numbers: hex 0003 times hex F01F = hex 11021. The 3 will detect any odd parity error, and the 11021 will detect any single burst error less than 17 bits long.

    FNW0:	LD	A,(DE)
	CP	(HL)
	JR	NZ,FNW2
	INC	DE      ;added this line
	INC	HL      ;added this line
	DJNZ	FNW0
    • Like 2

  18. Posted · Edited by rcgldr

    I changed the Indus doubler so that it is ATR "compatible". It is still double density 256 byte sectors, but sector 1 now loads the actual code from sectors 4 through 7, avoiding the 128 byte limit issue on sectors 1 to 3. I haven't changed the verify after write code yet (it checks CRC and only compares the first byte repeatedly, instead of comparing the entire sector). Note only sectors 1, 4, 5, 6, 7 are used. The rest of the sectors are all zeroes and not used. Link to zip of the atr file, or you can use the attachment.

     

    http://rcgldr.net/atari/dblr1.zip

     

    To use the doubler, insert the disk, then hold down "drive type" and then press "error". After it loads, I usually press "track" to switch to track display. This will put the Indus into a mode that emulates a 1050 doubler. You need to power cycle the Indus to get it out of emulation mode.

    dblr1.zip

    • Like 5

  19. Posted

    The Gotek is $20-ish. That's probably the most popular hardware floppy emulator on the market, and plenty of ST and Amiga owners are installing them in their systems. If you want to run games on your ST with the least amount of work, then that's the way to go as long as your ST has an internal drive [i'm not talking about the dead Mega 4 which does sound like a power supply and/or capacitor issue]. Almost all of the games released have image files posted online so if you have a Gotek, you can load the image files from a USB flash drive. That's an easier method than, say, upgrading the ST's RAM to 2MB - 4MB in order to use an UltraSatan device along with downloading modded versions of the games that support hard drive installation and the like.

     

    There's plenty of Gotek videos up on YouTube whether for the ST, Amiga, or even music keyboards that had their own floppy drives.

    I have an original 520ST upgraded to 1MB ram. No internal floppy, only the SF314 which I just bought, and the SF354 (single side) which was still working. I wrote a format program to create PC compatible floppies on the Atari ST, which makes it easier to backup, which is how I backed up most of my stuff 20+ years ago. I could try to fix the Mega ST4, but I currently don't have a convenient place to set it up.

  20. Posted · Edited by rcgldr

    >except analog pot

     

    The Atari uses the analog pots as well (paddles)

    The issue is the Bally Astrocade controller only has a single pot. It's a handle with a trigger, and joystick that extends a bit above the top of the handle with a knob on top. So 5 switches (no "right" side button equivalent), and 1 pot. It was used for a games like gunfight (or a football game). Joystick used to move characters, the pot to aim the characters arm. The nice part is the full throw on the joystick is about 1/2 inch, and not much centering spring force for a light touch.

  22. Posted

    I have this stuff in storage and plan on dumping it soon, but would give it away to anyone willing to pay for shipping, or someone near Orange County California that would be willing to drive over and pick up this stuff.

     

    Learl Siegler ADM 11 Ascii RS 232 terminal - appears to be working. I have a cable modified with an Atari style connector so that the terminal can be used as a proper 80 column terminal for the ATR 8000. I seem to recall that WordStar was able to send the ADM 11 command sequences so it would work in WYSIWYG (what you see is what you get) mode. I don't know if the cable still works since the ATR 8000 is not working.

     

    ATR 8000 with the 8088 + 512MB ram upgrade - apparently not working. For CP/M, the 8088 memory could be used as a ramdisk. It also runs MSDOS 2.11.

     

    Two full height 8 inch floppy drives - I don't know if they are working or not, and they are very heavy. They are in a case with it's own power supply. The power comes on, and I can see the drive lights flash when I power off, but I have no way to test them

     

    I have a bunch of 8 inch floppy disks for both CP/M and MSDOS 2.11, but these are worthless unless the ATR 8000 can be repaired and if the 8 inch floppy drives and the floppy disks work. Since these are not high density disks, there's a good chance that most of them are OK.

     

    One issue is that I haven't been able to find any 5.25 inch floppies for CP/M 2.2, only the MSDOS 2.11 floppies, and a floppy with ramdisk for CP/M, and all of these are the original floppies from SWP, so that means anyone trying to get this setup working again would need at least one working 8 inch floppy drive, since I would include my collection of 8 inch floppy disks, which should be enough to get all the software up and running again.

     

    • Like 4

  23. Posted · Edited by rcgldr

    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.

     

    Update, there's only 1024 bytes available for a emulator, from 7C00H to 7FFFH (inclusive). There is a main sector buffer, a command / verify buffer, some variables used by the firmware, and stack space, which uses the ram from 7800H to 7BFFH (inclusive).

    To reduce overhead, I use 5 sectors. Sector 1 gets loaded at 7F00H by the Indus firmware. It in turn reads sector 2 to 7C00H, 3 to 7D00H, 4 to 7E00H, and reads in sector 5 but leaves it in the default buffer. It then jumps to the code from sector 2 at 7C00H to do the final memory copy of sector 5 from the default buffer to 7F00H (otherwise it would be overwriting itself). This is a fairly generic boot sequence.
    • Like 1

  24. Posted

    Re write with read verify check. it is the same in the drive firmware and in the syncro code. bit of an oops there

    The odds of getting a good CRC, but a data mis-compare are 1 in 65536, and zero if there is only a single error burst less than 17 bits long, assuming a 16 bit CRC. Combine this error-misdetect with the actual error rate, and it's fairly unlikely to occur. Still, unless there's some magical hardware in the Indus, it's a bug in the code. I need to check if my Indus has the same bug in it's drive firmware.

  25. Posted

    Read or copy (a 48 Kbyte-long file) fully, and in ONE pass. It will fit entirely on IndusGT RamCharger's working memory.

     

    What is the directory structure for a DOS 2.0 file? Will the Atari side have to read sectors other than just the file data?

     

    What if you found the starting sector of the file, and wrote a program that just read sectors sequentially from the RamCharger's memory, or perhaps just read the same sector repeatedly?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...