Altirra 2.80 released

[lemiel]

Phaeron, could you change name Tiger to Tygrys as it is its original name, translated name is not to good. I should wrote this request in better way.

[phaeron]

http://www.virtualdub.org/beta/Altirra-2.90-test13.zip

http://www.virtualdub.org/beta/Altirra-2.90-test13-src.zip

 

• Fixes reboot issue with Happy 1050. The problem was that the controller CPU was getting reset before the ROM banking logic, so sometimes it was trying to boot from one bank with the reset vector of the other.
• Rename Tiger 1050 -> Tygrys 1050. The firmware tag and device name have changed, so you will have to re-set those up.

 

phaeron, would it be possible

 

- either to expose the real disk emulation via an API to external programs like RespeQt?

- or to make a library from it which could be linked to disk emulators?

 

Then it would be possible to create ATX images using a Happy drive and a PC - without Kryflux or ijor's VAPI imaging tool.

 

There are a few reasons that I don't consider this a viable path.

 

The primary issue is timing. The timing precision of PC serial hardware is in general atrocious by Atari standards. There is so much buffering and timing slop that serial drivers don't generally even report events in the correct order -- when I was prototyping a drive emulator myself I found that even the best regarded USB serial drivers had a nasty habit of reporting the RI control line asserting after data bytes when the Atari had clearly done so in the other order. Flush and speed switch timing is also sloppy such that high-speed operation for certain protocols is difficult. As it turns out, the Happy protocol is particularly bad because it has a speed switch so tight that I had issue with the timing in the emulator, much less with a physical serial port. You could hook up the drive emulator to software like AspeQt, but getting it to communicate reliably with the Happy backup software would be a tougher proposition.

 

The other issue is effectiveness. Currently the full drive emulator only does basic parsing of Write Track commands, and so there are a number of oddball copy protection patterns that the Happy software could write that the drive emulator wouldn't be able to parse, like overlapping sectors. That could be improved. However, there are also patterns that simply can't be written by the drive because the Write Track command is not fully general -- the FDC doesn't allow direct control of clock bits and can't write all data bytes due to some bytes being stolen for special control functions. So even if the drive emulation and the link to the computer could be perfected, it would still be unable to copy disks that the original Happy drive couldn't copy, for the same reasons.

 

In the end, this would be unnecessary anyway since a viable disk can be reconstructed just on a standard 810 or 1050 drive. Since standard Atari drives only support a high-level disk interface and have no direct disk hardware access like a Disk II or a 1541, simply analyzing multiple read sector passes in a ProSystem-like fashion with a 10502PC interface is enough to create an ATX image, and with some work, a flux image that reproduces the same read results. This software doesn't yet exist but would be far easier to write and get reliable than trying to connect Happy drive emulation. The main thing that an enhanced drive would get you is the ability to control the retry behavior and thus speed up the process, but in a situation where the additional passes are a problem, such as a deteriorating disk, it would still be a much better idea to get the disk imaged in one pass on a modern drive with a Kryoflux or a SuperCard Pro.

 

[+DjayBee]

Thanks for your detailled explanation.

[ijor]

In the end, this would be unnecessary anyway since a viable disk can be reconstructed just on a standard 810 or 1050 drive. Since standard Atari drives only support a high-level disk interface and have no direct disk hardware access like a Disk II or a 1541, simply analyzing multiple read sector passes in a ProSystem-like fashion with a 10502PC interface is enough to create an ATX image, and with some work, a flux image that reproduces the same read results. This software doesn't yet exist but would be far easier to write and get reliable than trying to connect Happy drive emulation.

 

Beg to differ but I don't think this is realistic. In first place, if you really want to record all the possible protections, it would be awfully and unbearably slow. How many revolutions you need to reliably detect all dup sectors? Twice per sector is surely not enough. What for those sectors that have not one, not two, but many dups (sometimes more than a dozen) for the very same sector?

 

And how you deal with the firmware retry logic for detecting dup sectors with crc error? Plus in this case, for each time you attempt to read the sector the firmware retries several times, increasing even more the number of revolutions. On top of that you have to retry several times on those sectors for detecting weak bits. And you have cases with dup sectors combined with weak bits. In some cases the number of revolutions per track would be so high that it might not be healthy for the disk, even if the disk is still in good physical shape.

 

Let alone that you can't reliably get a good timing information. Not only for the sectors but for the track skew alignment as well. You might be able to produce a working image for most cases. After all, the original software checking the copy protection is also limited on how it can access the disk. You may say, who cares if some sector has more than 20 dups, the protection probably can't reliably confirm that anyway. May be. But I'm not sure we want to have images that just barely work.

Edited November 7, 2016 by ijor

[phaeron]

 

Beg to differ but I don't think this is realistic. In first place, if you really want to record all the possible protections, it would be awfully and unbearably slow. How many revolutions you need to reliably detect all dup sectors? Twice per sector is surely not enough. What for those sectors that have not one, not two, but many dups (sometimes more than a dozen) for the very same sector?

 

And how you deal with the firmware retry logic for detecting dup sectors with crc error? Plus in this case, for each time you attempt to read the sector the firmware retries several times, increasing even more the number of revolutions. On top of that you have to retry several times on those sectors for detecting weak bits. And you have cases with dup sectors combined with weak bits. In some cases the number of revolutions per track would be so high that it might not be healthy for the disk, even if the disk is still in good physical shape.

 

Let alone that you can't reliably get a good timing information. Not only for the sectors but for the track skew alignment as well. You might be able to produce a working image for most cases. After all, the original software checking the copy protection is also limited on how it can access the disk. You may say, who cares if some sector has more than 20 dups, the protection probably can't reliably confirm that anyway. May be. But I'm not sure we want to have images that just barely work.

 

Yes, it is not ideal. But then again, if you are worried about a marginal disk wearing out, it is already suboptimal to be using even an enhanced drive -- each track read will still take at least two revolutions and probably more when transfer time is taken into account. It's still much better to use a modern imaging setup.

 

I don't think the timing situation is quite that bad -- the computer can measure the end of the sector pretty accurately. It will have skew due to the time for the drive to process the sector, but this will be consistent for all sectors on the disk.

 

There are some protections that would be difficult to image by this method. There are also others that are relatively simple and just have a few CRC errors or deleted sectors. Unfortunately, AFAIK there isn't a readily available solution to image even the latter with a standard drive and get the results into an ATX image.

[ijor]

I don't think the timing situation is quite that bad -- the computer can measure the end of the sector pretty accurately. It will have skew due to the time for the drive to process the sector, but this will be consistent for all sectors on the disk.

It will probably be reasonable for simple tracks. It will get less accurate as soon as you have dup sectors because you will start measuring time from different anchor points. And precisely here it is where timing is more critical. And it will become even worse when measuring sectors with errors where the firmware retry logic would make you measure across multiple revolutions, which makes the rotational speed and jitter affect the measured time significantly.

 

Then you have to measure skew (inter track) alignment. Again the rotation across multiple revolutions is involved. Electronic Arts it's quite strict when verifying skew align. And it is not uncommon to see even original disks fail to load for this reason.

 

On top of this, your timing would be affected by the PC serial stack latency and jitter.

 

There are also others that are relatively simple and just have a few CRC errors or deleted sectors. Unfortunately, AFAIK there isn't a readily available solution to image even the latter with a standard drive and get the results into an ATX image.

Yes, there is a fair number of titles with very simple protection. Sometimes just a couple of bad (RNF) sectors. We have Steven's ProSystem for this purpose already.

Yes, it is surely possible to improve. Didn't try but I assume it is possible to convert from PRO to ATX if you want, from inside Altirra itself?

[+DjayBee]

It will get less accurate as soon as you have dup sectors because you will start measuring time from different anchor points. And precisely here it is where timing is more critical.

 

This is correct. Example: Broderbund's 1983+ protection (i. e. Gumball or Karateka).

It reads a sequence of its duplicate sectors twice. The first read uses some small delays between the reads and yields the "hidden" sectors, whereas a normal sequential read of the sectors yields the "public" sectors.

 

I tried to write a little XEX to extract the hidden ones and could not find a common delay to accomplish this.

[phaeron]

Didn't try but I assume it is possible to convert from PRO to ATX if you want, from inside Altirra itself?

It can, but the conversion will usually fail because PRO stores tracing information instead of timing information, which means it can't be converted viably without also knowing the read sequence and timing. The .pro format is not the part of ProSystem that I would advocate.

[Kr0tki]

This is Altirra's current firmware autodetection list, by the way. First entry is CRC32, second is size, third is type, fourth is readable name, fifth is specific firmware used by compatibility engine.

1. The names "Atari 5200 OS (4-port)" and "2-port" are a bit imprecise (though I guess it was a necessary shortcut) - apparently some early 2-port units still contained the "4-port" OS revision. Example

2. 1200XL OS rev. 11 is missing from the list.

3. It's worth noting that the 800 OS rev. B PAL was assembled from sources, not dumped from a real system. We can be fairly sure that this OS version was never produced - even the systems from late 1983 still contained Rev. A.

4. Why not include the Xformer OS's origin in it's name? Something like "Atari 400/800 OS-B NTSC (Xformer hack)" would be self-explanatory.

[phaeron]

1. The names "Atari 5200 OS (4-port)" and "2-port" are a bit imprecise (though I guess it was a necessary shortcut) - apparently some early 2-port units still contained the "4-port" OS revision. Example

4. Why not include the Xformer OS's origin in it's name? Something like "Atari 400/800 OS-B NTSC (Xformer hack)" would be self-explanatory.

 

2-port OS and 4-port OS were how I saw them referred to by 5200 regulars. It's not quite accurate as you point out, but it's close enough. The 4-port OS seems to be the predominantly available one.

 

As for the Xformer patched OS-B, the exactly nature of the patch isn't so much important as that it's patched at all. For the vast majority of cases the Xformer OS-B works fine -- I think I've only seen one case far where a game broke with it but worked fine on the real OS-B. Sadly, I don't have which one it was in my notes. I suppose it wouldn't hurt to indicate the origin. It's more about raising awareness that it isn't the real OS-B, so that for instance people aren't confused when tools report a checksum mismatch on it or do run into the rare incompatibility.

[danielcg]

Why Xformer patched OS-B rom had been hacked? What functions someone hacked Xformer patched OS-B rom for? I was UNAWARE of Xformer patched OS-B rom was HACKED for EXTREMELY LONG TIME until NOW! I verified Xformer patched OS-B rom supplied by Xformer Emulator and confirmed this patched OS-B rom is DIFFERENT than ORIGINAL patched OS-B rom. I am lucky that I also have ORIGINAL patched OS-B rom so I restored ORIGINAL patched OS-B rom as atariosb.rom for Altirra emulator.

[Keatah]

Now I'm even more confused.

[Kr0tki]

Why Xformer patched OS-B rom had been hacked? What functions someone hacked Xformer patched OS-B rom for? I was UNAWARE of Xformer patched OS-B rom was HACKED for EXTREMELY LONG TIME until NOW!

I think I get what you are trying to say, but the wording you used is somewhat confusing. "Patching" and "hacking" are interchangeable terms that mean modifying a ROM dump to change it's functionality. In case of the OS-B ROM from Xformer, it was hacked by Xformer's author to make it work with his emulator.

I verified Xformer patched OS-B rom supplied by Xformer Emulator and confirmed this patched OS-B rom is DIFFERENT than ORIGINAL patched OS-B rom. I am lucky that I also have ORIGINAL patched OS-B rom so I restored ORIGINAL patched OS-B rom as atariosb.rom for Altirra emulator.

Confusing wording again. If a ROM dump is patched, it is by definition no longer original.

 

Now I'm even more confused.

Hard to blame you.

[phaeron]

Speed.

 

If you look at the source code to ST Xformer, specifically in X6502.S, you'll see several simplifications to memory access in the core -- namely that it has no handler support for reads and PIA write handlers only handle XL/XE banking. This means that the PIA initialization in OS-B has to be modified or else it will bank out the kernel ROM in the emulator. Similarly, with the 4K at $C000 mapped and no cartridge, an unmodified OS-B would plow through that memory range and into hardware registers during the memory test. Nowadays, this is handled simply with read/write handlers on those regions, but back then it was a big deal and quite necessary to cut corners in order to run at full speed on an 8MHz 68000 or a 16MHz 80386. The PIA issue at least doesn't affect much software besides the OS, though I believe Caverns of Mars might have an issue (it sets port 2 to output mode to mask port A input).

[danielcg]

Phaeron, thank you so much! I understood!

 

I will use original (non-hacked) OS-B ROM as my computer (3.5Ghz Pentium Core i7 processor with 3.9Ghz turbo speed) is MUCH faster than 16Mhz 80386 processor so original (non-hacked) OS-B ROM can run at full speed as well as Altirra has full PIA support. I must use 800 mode, not XL/XE mode so $C000 would not be mapped as memory and will allow original OS-B ROM to work. For XL/XE mode, Altirra will automatically use atarixl.rom I already have so no problems will occur.

[Mclaneinc]

Just to add a little, depending on how many OS roms you have by default Altirra will auto select for one you, if you want to use a particular version of a rom you can select it via system, firmware, operating system on the fly or set it as default in the firmware images panel. I believe that Altiira's auto select will choose a real rom if one had been added before it will use the internal version.

[+DjayBee]

 

I think I've only seen one case far where a game broke with it but worked fine on the real OS-B. Sadly, I don't have which one it was in my notes.

 

Original Zaxxon verifies the OS checksum and only accepts unmodified OS-A and OS-B. You made me aware of this when I complained that Farb's then latest dump did not work for me.

[Roydea6]

I:\PICV\DIR PCL:Y?D*.

Volume:    PCLink
Directory: MAIN

YORRICK        2549  7-18-16  8:46p
YOGII          3072  7-18-16  8:46p
YOGIBEAR       2000  7-18-16  8:46p
YODA2          4821  7-18-16  8:46p
YODA           3576  7-18-16  8:46p
YEAR2010       5415  7-18-16  8:46p
65535 FREE SECTORS

I:\PICV\

Having an issue with PCL: not copying or listing directory. It seems to ignore the '?' mark as a valid search string.

 

 

[flashjazzcat]

Same here back in test5 ("?" is effectively treated as "*").

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-2.90-test14.zip

http://www.virtualdub.org/beta/Altirra-2.90-test14-src.zip

 

Adds support for emulating the Indus GT. Caveats:

• Audio is not supported yet.
• Controlling the SIO bus from the drive is not supported.
• SIO clock signals are not supported.
• The Z80 emulator is kind of wedged in there, so some parts of the debugger don't like it very well, but basic execution stepping and history do work. Other parts still think a 65xx is being used and will act oddly. Part of the problem is that the Z80 has a lot more internal state than even the 65C816 does, so the existing structures aren't big enough, but I don't want to bloat them for the 6502.
• Some, but not all, undocumented Z80 instructions are implemented.
• I had to hack the receive timing in order for SuperSynchromesh writes to work. The high-speed receive routine has what looks like critically bad timing for data bits in that it waits almost two bit cell times from the leading edge of the start bit until it begins sampling data bits, even though the optimal time is 1.5 bit cells. To work around this the emulator stretches the start bit by a quarter cell, but I'd love to hear if anyone has insight into what's going on here.
• RAMCharger is supported and SuperSynchromesh track buffering works, but the track buffering code relies on a hardcoded high-speed interleave and performs very poorly with a standard interleave. Recommend disabling accurate sector timing. This isn't a problem under SpartaDOS X since INDUS.SYS has the track buffering code disabled.
• The button combo for booting CP/M is exposed but it will not work yet due to the ATR disk image issue noted by Trub at atari8.info/index.php?ref=indus_cpm_en. I have gotten this to work, but only by hacking in the missing data in the FDC. Once we have a format that can cleanly bring in a full 256 bytes for sectors 1-3 this can be supported.

The Indus GT also seems to have the track 0 sensor wired inverted. Not sure why, but I had to invert the input into FDC compared to the 1050 to get it to recalibrate properly.

 

Other changes:

• Fixed an issue with the full disk drive emulators accidentally using normal reads for the debugger, which could cause the debugger to damage emulated state.
• The PCLink issue with ? should be fixed now.

 

[Kyle22]

. . .

• I had to hack the receive timing in order for SuperSynchromesh writes to work. The high-speed receive routine has what looks like critically bad timing for data bits in that it waits almost two bit cell times from the leading edge of the start bit until it begins sampling data bits, even though the optimal time is 1.5 bit cells. To work around this the emulator stretches the start bit by a quarter cell, but I'd love to hear if anyone has insight into what's going on here.
• RAMCharger is supported and SuperSynchromesh track buffering works, but the track buffering code relies on a hardcoded high-speed interleave and performs very poorly with a standard interleave. Recommend disabling accurate sector timing. This isn't a problem under SpartaDOS X since INDUS.SYS has the track buffering code disabled.

. . .

 

Hi Avery,

 

I have an idea about what's going on here. About 20 years ago, I was trying to fix the SDX track buffering problem.

 

I had an Indus with 64K RAMCharger, and programmed the drive with SuperSync from DOS-XL. Under SDX, it worked really fast, but would randomly lock up due to a timing error.

 

The Indus is a bit-bang device, so all the serial timings are adjustable in software.

 

I fixed this problem, and put a replacement INDUS.SYS that enabled track buffering and high speed in (the un-released) SDX 4.23.

 

The problem is that I forgot exactly what I did, I think I just added a NOP or 2 in a timing loop (in the Z80 code). And, I lost the one and only cartridge of 4.23 I ever made. This was not an official FTe version, but it would have been if we hadn't went broke...

 

I hope this helps you find the timing problem. I still have a RAMCharger, and really want it to go as fast as possible

[lemiel]

WOW! It is unbelivelable!

 

Many ROMs to test.

 

But - there is no 1050 Turbo emulation?

 

1050 Turbo: 2 ROMs from MegaSpeedy package

turbo1050-34.rom

turbo1050-35.rom

4 moded in Poland:

topdrive_serious6and9.zip - eprom from Serious 6 and corrected schema from Serious 9.

http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/Atari%201050%20%28Top%20Drive%20-%20german%29.rom

http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/Atari%201050%20%28Top%20Drive%20-%20Happy%29.rom

http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/Atari%201050%20%28Top%20Drive%20-%20Karen%29.rom

 

 

And for INDUS GT:

http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/Indus%20GT%201.2.rom

http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/Indus%20GT%201.4.rom

http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/LDW%20Super%202000.rom

CA2001 ROM yet to find or read from my own drives - to do.

 

And some extensions:

Ultraspeed ROM from Mr Martian: http://atariage.com/forums/topic/115434-new-indus-gt-firmware/page-2?do=findComment&comment=1402457with sources http://atariage.com/forums/topic/115434-new-indus-gt-firmware/page-3?do=findComment&comment=2364591

 

Tygrys 2.0 for LDW2000 and CA2001 (works with CA2001 with WD 1772 instead of WD2797A): http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysk%C3%B3w/CA2001%20%28Tygrys%20Turbo%202000%29.rom- http://atarionline.pl/v01/index.php?subaction=showfull&id=1247853956&ucat=6&ct=wynalazki

 

TOMS Turbo Drive - description from Serious Magazine 6 - additional switch controlled by drive closing key - connects pin 40 WD2797A with GND. When key is opened this switch is on (pin 40 connected to GND), and drive sends to computer menu with fast transmission procedure load address selection menu.

Wires connected originally to diode(?) checking Write Protect whole in diskette envelope. But with this firmware all is controlled by Write Protect switch. An they are connected in another way. Do not saw how in description in Serious and lost my installation manual from TOMS but can someday trace wires and cuts in my CA2001.

TOMSTurboDrive.zip

And it uses clock sio lines - now read this: SIO clock signals are not supported.

 

 

TOMS Multi Drive for LDW and CA - Serious Magazine 8 and corrected by Pecus version http://ftp.pigwa.net/stuff/misc/PECUS.ZIP(Multi4o.256 file)

TOMS Multi Drive LDW (CA with WD2797A and Indus GT probably too)

tmd_serious8.zip - There is something with data alignment in eprom. It is probably same as in Multi4Z.256 file in PECUS.ZIP.

 

 

Is it possible to emulate open drive closing key? Needed to download Turbo transmission code?

topdrive_serious6and9.ziptmd_serious8.zipTOMSTurboDrive.zip

Edited November 15, 2016 by lemiel

[phaeron]

The problem is that I forgot exactly what I did, I think I just added a NOP or 2 in a timing loop (in the Z80 code). And, I lost the one and only cartridge of 4.23 I ever made. This was not an official FTe version, but it would have been if we hadn't went broke...

 

I hope this helps you find the timing problem. I still have a RAMCharger, and really want it to go as fast as possible

 

That would work, but wouldn't really address the problem -- the issue is how the stock software worked at all, and how to get it working at least about as well as it does on real hardware without hacks. The problem is that from what I can tell, it isn't reliable with ideal timing and it's not clear what would need to be adjusted to fix that in a realistic manner.

 

My first thought was an analog effect since some XL machines are known for having speed-killing parts on their SIO ports, but that doesn't quite fly here because at the analog level there is no difference between the start bit and any other bit. A fault in the Z80 emulation is another possibility, but I've recounted the T-states in the receive routine manually several times and haven't found an error yet.

 

Here's the pertinent routine, from sup8dct's disassembly (http://atariage.com/forums/topic/129969-indus-gt-rom-disassembly/):

 

Lb63a:  CP      (HL)                    ; 7E5E BE      7 .
        JP      C,Lb63a                 ; 7E5F DA5E7E 10  wait for start bit
        EX      AF,A'F'                 ; 7E62 08      4 .
        EXX                             ; 7E63 D9      4 .
        DEC     BC                      ; 7E64 0B      6 dec number of bytes to get
        LD      A,B                     ; 7E65 78      4 x
        OR      C                       ; 7E66 B1      4 = to zero?
        EXX                             ; 7E67 D9      4 swap registers with 2ndary
        EX      AF,A'F'                 ; 7E68 08      4 swap a and F registers with 2ndary
        LD      C,$7F                   ; 7E69 0E7F    7 Bit pattern for 8 bits to recieve
        LD      I,A                     ; 7E6B ED47    9 timing
        LD      I,A                     ; 7E6D ED47    9 instructions
Lb64a:  CP      (HL)                    ; 7E6F BE      7 .
        CP      (HL)                    ; 7E70 BE      7 .
        NOP                             ; 7E71 00      4 .
        NOP                             ; 7E72 00      4 .
        LD      I,A                     ; 7E73 ED47    9 .58 t states for recieve loop one bit
        CP      (HL)                    ; 7E75 BE      7 .

The Atari sends at 26 cycles/bit @ 1.77/1.79MHz so 58 T-states is about right for the bit receive loop. The time from the start bit being sensed to the first data bit sample is 103 T-states, which is very nearly at the trailing edge of the first data bit. Add in up to 17 cycles of jitter from the start bit loop and we're in unstable city. It should be a bit under 1.5 * 58 = ~87 T-states instead.

 

As a side note, Z80 assembly is bonkers with regard to different instructions with the same name setting flags differently, i.e. RLCA vs. RLC or 8-bit ADD vs. 16-bit ADD. It only makes sense if you also know 8080 assembly, where the names are different for those instructions.

 

But - there is no 1050 Turbo emulation?

I haven't been able to find hardware information on the 1050 Turbo. It's a bunch of work to tear apart the firmware to figure that out. If it's just a bank switch mechanism, that's pretty easy to hook up once I know what it is.

 

Tygrys 2.0 for LDW2000 and CA2001 (works with CA2001 with WD 1772 instead of WD2797A):

Note that the emulated FDC is not well defined -- it's sort of an unholy mix of 1771, 1772, and 279x right now. At some point I need to fix that. Not sure how much I trust the WDC datasheets, though, given how many vague and incorrect statements I've found in it. One example is that the datasheet says that the 1771 FDC waits for a head load time before asserting DRQ and waiting for a byte... but this is actually not true, as the 810 firmware relies on being able to load a byte immediately without even checking for DRQ. And then there's the fairly big omission about type I status being continuously updated....

 

TOMS Turbo Drive - description from Serious Magazine 6 - additional switch controlled by drive closing key - connects pin 40 WD2797A with GND.

HLT (Head Load Timing)? Might be able to do that, depending on how the firmware is querying it. Should be pretty easy if it's just using type I status.

 

And it uses clock sio lines - now read this: SIO clock signals are not supported.

If they're just being used to synchronize against POKEY's receive timing in synchronous mode, that's likely not too bad. If they're being used for communication, though, that's tougher. Currently the full drive emulation does not support having more than one drive or doing drive-to-drive communication, and I don't know if I'll get to that.

 

[ijor]

Still amazed by this level of emulation ...

Not sure how much I trust the WDC datasheets, though, given how many vague and incorrect statements I've found in it. One example is that the datasheet says that the 1771 FDC waits for a head load time before asserting DRQ and waiting for a byte... but this is actually not true, as the 810 firmware relies on being able to load a byte immediately without even checking for DRQ. And then there's the fairly big omission about type I status being continuously updated....

I don't see the 810 firmware writing to the FDC without waiting for DRQ. I assume you are talking about the Write Track/Format command. The standard rev C firmware certainly does wait for DRQ. Which firmware you see it doesn't?

Perhaps what you mean is that the firmware writes the first byte before enabling the timer. Which requires the FDC to generate a DRQ pulse before seeing the disk index pulse. But this is the expected behavior and it is documented being by design. The FDC doesn't even turn on Write Gate if the initial DRQ wasn't serviced.

Regarding the type I status bits. I don't remember for sure if they are all fully documented or not. But this is kinda obvious and well known when you have worked with WD FDCs. Not a very common task on the 8-bit perhaps. But on other platforms, like the ST, dealing with the FDC is part of the regular low level programming .

But anyway, the FDC is a pretty complex and "big" (in terms of logic) chip. No matter how good are the datasheets or not; if you want the finer details, you have to perform some kind of reverse engineering.

If they're just being used to synchronize against POKEY's receive timing in synchronous mode, that's likely not too bad.

Does Pokey synchronous mode works at all? As long as the drive uses the clock signal to autodetect the bit rate, that shouldn't be a problem. But I remember we performed some tests a few years ago and Pokey was unreliable receiving synchronously.

[lemiel]

If they're just being used to synchronize against POKEY's receive timing in synchronous mode, that's likely not too bad. If they're being used for communication, though, that's tougher. Currently the full drive emulation does not support having more than one drive or doing drive-to-drive communication, and I don't know if I'll get to that.

 

I do not know how I discovered that it is used. I remember that I was trying to copy disks via Atarimax ProSystem and Atarimax SIO2PC/1050-2-PC USB and 1050-2-PC on FT232 but it did not work with my CA2001 with TOMS Turbo firmware, with standard firmware it worked and with second one equipped with Tygrys too (this one in Ultraspeed so it was much nicer).

 

--

 

CA2001 ROM: http://www.dereatari.republika.pl/atariepr/ca2001.zip

 

1050 Turbo Schematics:

http://www.strotmann.de/~cas/Infothek/1050Turbo/tech-doc_1050_turbo_1.pdf

http://www.strotmann.de/~cas/Infothek/1050Turbo/tech-doc_1050_turbo_2.pdf

TopDrive 1050 - 1050 Turbo clone - schematic : http://www.dereatari.republika.pl/serw.htm#top%20drive%201050

Edited November 15, 2016 by lemiel