Jump to content
IGNORED

Altirra 2.80 released


phaeron

Recommended Posts

Update:

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

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

 

Implements variants I and II of the 1050 Turbo, which wins the award for the most unique ROM banking scheme. Type I is compatible with the Top Drive firmware. The standard disk emulator also has high speed timing tweaked so that SuperDOS 4.3T boots.

 

Fixed the XFD disk image routines to handle double density and quad density... which means that Indus CP/M can now be booted. It occurred to me that while ATR doesn't support storing full 256 byte boot sectors, XFD might... and that's when I realized Altirra didn't actually support double density XFD! That's fixed now, and attached is a version of the Indus CP/M disk with Trub's boot sector patch. To boot CP/M, you have to first boot a regular Atari disk with the terminal software, then swap in the CP/M disk and hit System / Console Switches / Indus GT: Boot CP/M menu option, which does the Drive Type + Error button combo on the drive panel to trigger the boot.

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?


It was probably one of the enhanced firmwares. The 810 firmware does still write without checking IRQ, so if the FDC tries to signal an error, the drive hangs. That's why in order to reimplement VRWSafe mode the emulated FDC signals a write protect error after receiving the track.

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 .


The meanings are documented, but not that they are continuously updated. I actually found that out by reading some helpful posts in Atari ST forums. Thankfully, the 8-bit disk interface disallows that level of craziness!

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.


I don't know myself since I don't have hardware to test it, but the Indus GT's built-in Synchromesh tries to work that way and is known to be unreliable. That having been said, I've never found any software that actually tries to use it, instead of uploading a working version that uses asynchronous mode. Altirra's handling of this is pretty simple -- it will inject errors into the receive stream if a program attempts to receive in synchronous mode unless the device sets a flag indicating a matched clock.

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


Got it working. You are right, it uses the clock from the computer when clocking in bits during a receive operation. Would have been pretty quick were it not for this #$&* code that took an hour to track down:

        767:125: 22 | A=43 BC=0004 DE=0000 HL=781D (S - - N ) | 0A4F: CB 7E         BIT     7,(HL)
        767:125: 27 | A=43 BC=0004 DE=0000 HL=781D (SZ-H-   ) | 0A51: FA 15 0A      JP      M,0A15H


In case you're wondering, Zilog documents the sign flag as undefined after a BIT instruction. This was causing the drive to reply at high speed, until I fixed the CPU emulator.

The interesting thing about this is that the Atari does not always output a valid clock when sending serial data. If I'm right, the TOMS Turbo Drive should not be able to boot Cross-Town Crazy Eight correctly, which is the only program I know of that does disk I/O with channel 2 as the output channel. POKEY can only output channel 4 as the clock.

post-16457-0-64636000-1479282813_thumb.png

Indus CPM Fixed.zip

  • Like 4
Link to comment
Share on other sites

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

...

It was probably one of the enhanced firmwares.

If you came to the conclusion that the FDC asserts DRQ right away (as it seems according to your sources), I don't think that is right. The FDC asserts the first DRQ before the index pulse, but after the head load settle time.

 

Probably not very important. The format time might be slightly changed. In the worst case, it might affect the Happy 810 logic when formatting tracks with skew align.

 

The 810 firmware does still write without checking IRQ, so if the FDC tries to signal an error, the drive hangs. That's why in order to reimplement VRWSafe mode the emulated FDC signals a write protect error after receiving the track.

 

Ah. I think I see what was going on. The 810 firmware does wait for DRQ, and also it does check for timeout. The problem is that at the first write of the command, the RIOT timer wasn't yet triggered. So even when the firmware does check for timeout, no timeout will actually happen. And if you never deliver a DRQ (not even after head load settle time), then the firmware deads lock.

 

But this doesn't seem to be related to any FDC undocumented issue. As I said, the 810 firmware expects one DRQ before the index pulse, not necessarily before the head load settle delay.

 

The meanings are documented, but not that they are continuously updated. I actually found that out by reading some helpful posts in Atari ST forums.

I did understand you were talking about the continuous update. And I think that it is documented. It is not fully explicit, I agree. But it is more than implied by the context. What is certainly not documented, is how the status bits are affected by the Reset/Force Interrupt command. It is different if the FDC was busy or it was not. But reading your sources I think you got it right.

Edited by ijor
Link to comment
Share on other sites

Stereo audio suddenly broken in 2.90-test 5. Updated to test 15 and it's no different. It worked before, so perhaps some Windows 10 update is to blame. If I turn off stereo in the audio fly-out menu, I get sound again.

 

Windows 10 Pro 64-bit

Intel Core i5

Realtek ALC audio codec

 

Neither DirectSound nor Waveout produces stereo.

 

Please ignore... hardware fault. :)

Edited by flashjazzcat
Link to comment
Share on other sites

 

So the plug was not fully inserted or the jack has a cold solder joint or something?

 

The jack had most probably worked its way out just enough so that I was only getting one channel, and when enabling stereo in Altirra, the keyclick and SIO sound happened to come out on the silenced channel... I assume.

Link to comment
Share on other sites

Update:

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

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

 

Adds full XF551 emulation. As usual, you need an XF551 firmware for this to work. The version I tested with is revision 7.7, with CRC32 38B97AE3. High-speed, double density, and double-sided disks are supported.

 

There are a couple of interesting things about the XF551's firmware. First, it is unusually strict about the timing of the SIO COMMAND line in that it will not accept a command if /COMMAND is not still asserted through the end of the last byte, which most other drives don't check. Currently the emulator stretches the command pulse a bit to work around some timing issues in the transmit path.

 

The second issue is the way that the XF551 switches densities. As far as I can tell, the XF551's density switching strategy is kind of FUBAR in that (a) it will only auto-switch to DSDD, never SSDD, and (b) it only switches to DD if it sees a long sector on a sector read other than a boot sector. The latter causes problems because while the drive successfully switches from SD (FM) to ED (MFM), it will fail to switch from ED to DD if the ED track/sector mapping causes a record not found error from trying to read a sector >18 instead of the lost data error. This happens if a picoDOS is booted or SpartaDOS X attempts to read a MyDOS disk. Would be interested if anyone has seen different behavior on a real drive on stock firmware; I've gone over the firmware many times and haven't found a way for the drive to successfully switch to double density when only sectors 1 and 361 are read.

 

  • Like 10
Link to comment
Share on other sites

Afaik,

 

XDOS 2.4, BiboDOS 6.4 XF and a few other DOS versions for the XF551 do (always?) read sector 4 to check the density. There was a long article in one of the older Compyshop magazines, where E.Reuss describes the (then) new XF551 and all its flaws; he also wrote that it would be best to read sector 4 to check the density. Bibo-DOS was then updated for the XF551 (well, they made a separate XF version)...

 

There is also a great article from Bob Woolley about the XF551 and how to convert it into a 3,5" drive, which also describes many or all of the XF551 flaws...

 

Besides, the XF551 does not automatically switch from SD to ED, if you use DOS 2.5 for example (or another DOS 2.x that has not been written for the XF and thus does no automatic/smart density check), boot a 90k disk and then insert a 130k disk, it will show a false number of free sectors (the free sectors of a 90k disk); or do the opposite, boot a 130k disk and then insert a 90k disk and you will get an Error 144 because the XF still searches for the second VTOC... you have to make a second attempt to read the directory to get the correct free sectors and correct disk density.

 

The XF also has big problems to differ between 180k and 360k (SSDD and DSDD) and it completely hangs up, when you boot a 360k disk (DS, DD, MFM) and then insert a SD disk (SS, SD, FM)... at least thats my experience with XF551 drives (with OS on Eprom, PAL country you know)...

 

There might be fewer density problems with (disk-based) Sparta-DOS or SDX than with DOS 2.x DOS types, but afaik most of the disk-based Sparta-DOS 2.x and 3.2x versions will give you an "Error - no DOS!" when you first boot a disk, so you have to do a second boot or patch Sparta-DOS for the XF drive (there are two or three patch programs for this purpose).

Link to comment
Share on other sites

Besides, the XF551 does not automatically switch from SD to ED, if you use DOS 2.5 for example (or another DOS 2.x that has not been written for the XF and thus does no automatic/smart density check), boot a 90k disk and then insert a 130k disk, it will show a false number of free sectors (the free sectors of a 90k disk); or do the opposite, boot a 130k disk and then insert a 90k disk and you will get an Error 144 because the XF still searches for the second VTOC... you have to make a second attempt to read the directory to get the correct free sectors and correct disk density.

 

Odd, this isn't quite the behavior I'm seeing, at least with the rev 7.7 firmware. The drive has to detect an SD->ED density change or it won't read anything; it first tries a read in FM, finds nothing, then does a Read Address successfully in MFM and switches to ED. DOS 2.5 does a normal VTOC read before it issues a status command, so it sees the density change too and reads the extended VTOC. Going ED->SD seems to work as well. Perhaps your firmware has different density switching logic -- which firmware do you have?

 

That having been said, it's unfortunate that the XF551 doesn't detect density on disk change like the 1050 does. I assume the lack of a ready input on the WD1772 and the aggressive use of port pins as data storage has something to do with this.

Link to comment
Share on other sites

That having been said, it's unfortunate that the XF551 doesn't detect density on disk change like the 1050 does. I assume the lack of a ready input on the WD1772 and the aggressive use of port pins as data storage has something to do with this.

 

There is no reliable and universal method to detect disk change by hardware on low density PC drives. The Ready signal is not present in every drive and it is not always consistent and coherent. On some drives the signal is valid only when the drive is selected and the motor is on. The write protect signal is also problematic because it might not be valid when the disk is removed. If you had an IBM XT (or compatible) in the old days, you might remember the PC accessing the floppy too much trying to detect media change by software. Things changed with the PC AT and high density drives that supported hardware media change with the DiskChange signal.

 

Link to comment
Share on other sites

If this is the wrong place to post this, I apologize. I'm trying to have Altirra act just like my XEGS and start up the built-in Missile Command game if I hold down the Select key on a cold boot or boot up if no keyboard is present. However, no matter what I do, I simply end up at the Self Test. I've tried a Google search, but I was unsuccessful.

 

I do have the XL/XE/XEGS OS Ver. 4 ROM. I've also added the Missile Command game as an XEGS Game ROM. However, I've been unsuccessful emulating the built-in game experience of my actual XEGS. I've tried unchecking the Keyboard Present (XEGS) Console Switch, but it didn't help.

 

If you need additional information from me, please let me know.

 

Bob C

Link to comment
Share on other sites

Avery,

 

Thank you! I very briefly saw the Option key in the lower right-hand corner. However, it went by so quickly I never would have noticed it if you hadn't pointed it out to me. Now, I have documentation on how to get Altirra to boot directly to Missile Command. I also noticed the View/Overscan option was set to Extended which is why I saw garbage on the side of the screen when I played World Karate Championship. Setting it to Normal made the screen look as I expected it to.

 

Thanks again for your help.

 

Bob C

Link to comment
Share on other sites

Update:

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

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

 

  • Fixed LD (IX/IY+d),nn instruction in Z80 emulator.
  • Fixed index sensor again. Turns out the 1050 is the one with the inverted track 0 sensor, not the Indus GT, and the track 0 sensor also activates on track 0.5 (!). This is documented in the Tandon manual and required for the Indus GT track 0 sensor adjustment test to pass.
  • Implemented index pulse sensor; fixes Indus GT index pulse based RPM test.
  • Fixed RIOT timer not setting interrupt flag with interrupts disabled; fixes 1050 motor speed diagnostics hanging.
  • Fixed FDC type I status not being reinstated after Forced Interrupt command; fixes 1050 track seek diagnostics failing.
  • Implemented motor on and spin-up completed bits in 1770/1772 FDC.
  • Added support for Indus GT track, error, and drive type buttons.
  • Added Indus GT LED display.

A warning on the 1050 diagnostics disk: Some of the images floating around are truncated and will fail the seek test in Altirra when the test can't read any sectors on tracks above ~25. And the Indus GT diagnostics... why use Atari Microsoft BASIC!?

 

post-16457-0-48033100-1480808531_thumb.png

  • Like 9
Link to comment
Share on other sites

I can't get Indus to work.

 

 

in fact, I can't get any floppy I/O to work when the Indus is added to Devices.

 

All I get is a 138.

 

I *DO* hear SDX downloading the Z80 code in INDUS.SYS to the drive, but it just farts the 138 sound before and after INDUS.SYS loads.

 

Edit: Is there RAMCharger / CP/M support?

Edited by Kyle22
Link to comment
Share on other sites

I can't get Indus to work.

 

in fact, I can't get any floppy I/O to work when the Indus is added to Devices.

 

All I get is a 138.

 

I *DO* hear SDX downloading the Z80 code in INDUS.SYS to the drive, but it just farts the 138 sound before and after INDUS.SYS loads.

Do you have Indus GT firmware hooked up?

 

Edit: Is there RAMCharger / CP/M support?

Yes, both are supported (see post at top of this page).

Link to comment
Share on other sites

Just ran the 1050 diagnostic disk obviously under full 1050 emulation and all passed bar the motor speed test which it says is too low.

 

Is this part of the truncated disk problem or something else...

 

If there's a better image a pointer to it would be great..

 

& for others, here the INDUSGT DIAG DISK mentioned in Avery's post, when booted just type

 

LOAD"D1:DIAGS" and when loaded, RUN...Bit unprofessional looking...

INDUSGTD.ATR

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