Altirra 3.20 released

[phaeron]

3 hours ago, ijor said:

So the problem is that the edge is triggered too early? It seems that the diagnostic code just calls the firmware format routine at $FA2A, or it uses its own format routine? Because, if my math is correct, the firmware routine seems to be ok. The DD format routine waits for the initial DRQ, then fires the RIOT timer with a 1024 usecs timeout. Even when the value is rather low in comparison, it still should be more than enough for the 3 bytes delay that take less than 100us. That is, the FDC asserts the initial DRQ, delays 3 bytes, then it is ready to detect an IP edge. There are some small additional delays involved, but they shouldn't be too significant.

I think I have it working, but it needs a lot of testing across all of the supported drives. The main issue is that the initial DRQ is being fired too early by the emulator, before head load delay instead of after, but there are also fixes to the FDC and RIOT timings that I need to retest.

 

The issue with the FDC timings is that the various chip versions have different head load delays and the Atari drives run them at non-default clock speeds. So when the data sheet says "10ms" it means 10ms at a 2MHz clock, which doubles since the 810 and 1050 run their FDCs at 1MHz instead. The current emulation code just always uses 10K cycles, which is wrong. But there are also some small delays in command processing that I need to eventually measure and get to, as the emulator completes commands like a 0-track seek in 0 cycles, while on the real hardware it seems to be minimum about 150 cycles or so.

 

The RIOT timer is just an undocumented morass. It's well documented that the timer switches from prescaled to 1T mode when it underflows for the first time. It's not documented that it continues to underflow and fire interrupts every 256T after that, which many drive firmwares depend on for timing out the FDC on 5 revolutions. It's really not documented that clearing the timer interrupt flag by reading the timer resets the timer back to prescaled rate, for which the only reference I found is a short mention in one of the Atari 2600 docs. Rockwell's version of the timing chart is wrong, because they added a trailing edge to the IRQ state that isn't reflected properly in the cycle counts after it, which they copied from the MOS diagram that didn't have the interrupt flag getting reset. With the Happy 1050 I finally have cycle-precise timings for the interval timer.

 

I also have a fix in flight for the weird quirk when writing back to back $F7 bytes through Write Track, but am not sure if anyone has actually used it, the only reference to it being in some Atari ST research docs.

 

3 hours ago, ijor said:

I admit I never checked those values in the datasheets, but the Force Interrupt takes a variable amount of cycles that depends on exactly what the FDC is doing at the time

Yes, and this is documented in the datasheet, but they have it spec'ed at 8us (FM) and 16us (MFM) at 2MHz, which is way too short. I was pulling my hair out yesterday testing on the Happy 1050 until figuring out that it's more like 50 cycles in FM (25us at 2MHz) between forced interrupts when trying to stop a Write Track command.

 

[ijor]

7 hours ago, phaeron said:

The issue with the FDC timings is that the various chip versions have different head load delays and the Atari drives run them at non-default clock speeds. So when the data sheet says "10ms" it means 10ms at a 2MHz clock, which doubles since the 810 and 1050 run their FDCs at 1MHz instead.

 

Yes, different FDC models have sometimes different delays. And yes, the values specified in the datasheet depend on the actual frequency, in some cases also depend on the state of some pins that enable or disable an internal clock divisor (such as the ENMF pin on the 2793). Also most, but not all, values depend on the current encoding, FM or MFM.

 

Just for completeness, I should mention that most delays are internally counted in bit periods. And when the PLL is enabled, the bit period is determined by the actual frequency of the PLL output.

 

Also, as you probably already noted, the whole initial write track procedure is quite different in the older 810's FD1771.

 

Quote

But there are also some small delays in command processing that I need to eventually measure and get to, as the emulator completes commands like a 0-track seek in 0 cycles, while on the real hardware it seems to be minimum about 150 cycles or so.

 

You have to remember that the FDC processing is microcode based. In some regards, it is more similar to running firmware than hardware parallel logic. Each command is processed in steps. In this particular case the FDC must still perform the comparison between the track and the data register and this is very slow because the ALU is serial and compares one bit at a time.

 

Quote

I also have a fix in flight for the weird quirk when writing back to back $F7 bytes through Write Track, but am not sure if anyone has actually used it, the only reference to it being in some Atari ST research docs.

 

Probably used only on the ST, and only on a couple of cases that I'm aware. Mainly a famous demo that was released copy protected, but included its own copier to copy itself!

The Read Track command has quirks even more weird. That is your next challenge if you want to support the full DiskMaster 1050 functionality

 

Quote

Yes, and this is documented in the datasheet, but they have it spec'ed at 8us (FM) and 16us (MFM) at 2MHz, which is way too short. I was pulling my hair out yesterday testing on the Happy 1050 until figuring out that it's more like 50 cycles in FM (25us at 2MHz) between forced interrupts when trying to stop a Write Track command.

 

The datasheet is indeed obviously blatantly wrong (btw,  you swapped the FM vs MFM values, but I guess it was just a typo). The worst case should be something like 20 cycles, and the average probably in the order of 8 cycles, at least in the middle of a track format command. Cycles here mean bit times.

 

Quote

The RIOT timer is just an undocumented morass ... for which the only reference I found is a short mention in one of the Atari 2600 docs

 

I believe there are reverse engineered schematics or logic, and probably simulations as well. The 2600, including the CPU, TIA and RIOT, was the very first "decap" performed by the Visual 6502 people.

 

[TheMontezuma]

On 8/9/2019 at 6:17 AM, phaeron said:

I'm not sure it's a good idea to co-opt command IDs on another device's ID, especially for a multi-function device implemented in various versions on a PC. I would suggest switching to another device ID for adding a new function like this.

I didn't want to polute SIO device ID space with a new ID just for such a small feature.

As _The Doctor__ suggested, I wrote an e-mail to Steve (Atarimax), but he has not answered it (yet?).

 

Anyway it was just an idea, but it is OK, when the emulators support B: device emulation only (like Altirra and Colleen).

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.90-test7.zip

http://www.virtualdub.org/beta/Altirra-3.90-test7-src.zip

• Fixed history pane not nesting properly in Z80 disassembly mode due to using the wrong stack pointer.
• Fixed 810 Turbo missing drive select configuration dialog.
• Fixed 6532 RIOT interval timer based on checks against hardware -- now implements re-enabling of prescaler on timer read and should now be cycle-exact.
• Fixed FDC Write Track, now has proper adjusted head load timing and head load -> initial DRQ -> index wait sequence.
• FDC Write Track with $F7 F7 F7 sequence alternates CRC and $F7 data bytes as it does on the actual chip.

Also went ahead and implemented PERITEL mode, which now has an option under Video. I wouldn't have bothered with this except for how simple it was to implement and how insanely awesomely goofy it looks. It's just a palette modification, which you can get onto other emulators by exporting the palette. I did try implementing SECAM color at one point but had trouble with color reproduction -- replicating the red/blue encoding as in the FGTIA doc wasn't hard but the colors didn't match the pictures from the actual systems.

27 minutes ago, TheMontezuma said:

I didn't want to polute SIO device ID space with a new ID just for such a small feature.

As _The Doctor__ suggested, I wrote an e-mail to Steve (Atarimax), but he has not answered it (yet?).

 

Anyway it was just an idea, but it is OK, when the emulators support B: device emulation only (like Altirra and Colleen).

I'm likely going to go ahead and implement support for this under device ID $45, but it seems strange to overload the APE device ID when the RespeQt device ID $46 could have been used instead, which would be easier to coordinate usage for.

2 hours ago, ijor said:

You have to remember that the FDC processing is microcode based. In some regards, it is more similar to running firmware than hardware parallel logic. Each command is processed in steps. In this particular case the FDC must still perform the comparison between the track and the data register and this is very slow because the ALU is serial and compares one bit at a time.

I'd love to see the actual microcode for the FDC, though from an emulation standpoint it's irrelevant -- short of a proper LLE implementation, all that matters is the delay timings. The actual timings on hardware are interesting, though, as there's quite a lot of variance in timings even for write and sometimes seek commands. I'm guessing that's due to a relatively slow loop for responding to new commands that's causing jitter in the command start.

2 hours ago, ijor said:

The Read Track command has quirks even more weird. That is your next challenge if you want to support the full DiskMaster 1050 functionality

I'll get to it eventually, I did some testing on Read Track yesterday using flux level testing patterns written out from an SCP. The way that command is designed you have to wonder if it was actually intended to be used for anything or if it was just for testing. Between only being able to read the entire track, not being able to distinguish address marks from regular bytes, and pushing bytes at up to double speed around address marks it's hard to find any reliable use for it.

 

I should try sending a flux chirp through it to see what the FDC's actual PLL capture range is, though....

2 hours ago, ijor said:

 

I believe there are reverse engineered schematics or logic, and probably simulations as well. The 2600, including the CPU, TIA and RIOT, was the very first "decap" performed by the Visual 6502 people.

Looks like 6502 and TIA have been fully reversed and published, but not the RIOT. Fortunately, there isn't much to the RIOT beyond the interval timer.

[ijor]

3 hours ago, phaeron said:

• Fixed FDC Write Track, now has proper adjusted head load timing and head load -> initial DRQ -> index wait sequence.

 

Note that as documented, the sequence is quite different on the 810's FD1771. Seems you implemented it unconditionally regardless the FDC model. Probably not very important, but I thought I should mention.

 

Quote

I'd love to see the actual microcode for the FDC, though from an emulation standpoint it's irrelevant -- short of a proper LLE implementation, all that matters is the delay timings.

 

I reverse engineered most of the microcode. I need to find the time to complete, clean it up, and release proper documentation. It is not just about the timing. The microcode, and the main logic as well, produces some subtle effects that are, obviously, not documented. The $F7 format quirk is a consequence of how the microcode works. A similar quirk produced by the microcode when performing the read track, is that the FDC might miss an index pulse when reading a sync mark. Of course, you don't necessarily need the microcode for emulation accuracy. But there are even more subtle effects that are very difficult to implement otherwise.

 

For instance, what exactly happens when you write to the command register when the FDC is still busy processing a different command? Does the new command overrides the old one, it is completely ignored, or it is applied partially? The, unsurprising answer is that, it depends. It depends on the microcode and the timing. It is true that you probably don't care because in the Atari 8-bit platform there is normally no direct access to the FDC and you don't really need cycle accuracy. But it becomes more relevant in other platforms.

 

Quote

The actual timings on hardware are interesting, though, as there's quite a lot of variance in timings even for write and sometimes seek commands

 

The main reason for this jitter, at least when starting a command, is the slower frequency. The microcode, and actually most of the FDC logic, runs at the data bit frequency, 250 KHz at MFM, and 125 KHz at FM. The clock division is not reset when starting a new command. So obviously there would be jitter depending on the current phase of the clock divisor.

 

Quote

I'll get to it eventually, I did some testing on Read Track yesterday using flux level testing patterns written out from an SCP.

 

The behavior is quite different between FM and MFM. At FM is pretty much straightforward. But at MFM, the detection of the different sync marks produces some ill effects. Yes, it was probably originally an internal command implemented for diagnostic purposes only. But then, I guess, they were forced to carry it on for backwards compatibility. The main use is for detecting some copy protections, such as custom data at the gaps. It was used extensively on the ST. It can be rather reliable as long as you are aware of its limitations. It is also possible to use it for fitting slightly more data bytes than you could when using sectors.

 

 

[solaris104]

Please support cartridge "99-JRC 64kB" in new version ?

[Mclaneinc]

Have you got any rom dumps for this cart?

 

I presume this is another Eastern european cart?

[solaris104]

I attach dumped cartridge. It is function on real AVG cart :-).

99-JRC 64kB.zip

[Mclaneinc]

 

Thank you for the dump, I'd not seen any of these on sites,

 

How popular were they?

 

At least if Phaeron needs a test he has one now (may even already have some)

 

So many cartridge variations, I understand some of them but most just seem like clones with subtle changes...

[phaeron]

This probably won't be hard to emulate, but I'm not finding the source of where this mysterious CAR type 160 was introduced. It's not from Atari800, they would have allocated sequential numbers instead and trunk version of cart.txt still lists only up to 70.

 

 

[tmp]

that type was introduced by me, it's just some random number that's high enough to not clash with existing types, i was going to change that once it gets an official type

[Keatah]

This isn't working in Altirra, but the previous version does.

I'm referring to the file in post #24

 

 

Edited August 19, 2019 by Keatah

[flashjazzcat]

30 minutes ago, Keatah said:

This isn't working in Altirra, but the previous version does

Specifically, it appears to have a problem with keyboard input when run in the emulator, but other than that it appears to work fine.

 

In fact: scratch that. There may be an intermittent keyboard issue in the game (perhaps uninitialised RAM, etc), but the XEX is working fine for me.

 

In what specific way was the game observed to be 'not working'?

 

Edited August 19, 2019 by flashjazzcat

[Xuel]

I found a crash in Altirra 3.90-test7 while testing heartlight. Repro:

1. Configure System -> Devices -> VBXE -> Settings ->  "Use VBXE for PORTB extended memory"
2. Start the game and get into the maze
3. While the game is running, unset "Use VBXE for PORTB extended memory"
4. OK -> OK -> Crash

Dump file:

 

AltirraCrash.mdmp

[Keatah]

24 minutes ago, flashjazzcat said:

In what specific way was the game observed to be 'not working'?

 

The non-working file from the heartlight thread post #24

hl(post24).xex

[flashjazzcat]

Ah... works in PAL only.

 

[Xuel]

3 minutes ago, Keatah said:

 

The non-working file from the heartlight thread post #24

hl(post24).xex 98.56 kB · 0 downloads

That happens in NTSC mode. Try PAL.

[Keatah]

PAL mode it is! Sorry for not being more thorough in setting up my virtual rig.

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.90-test8.zip

http://www.virtualdub.org/beta/Altirra-3.90-test8-src.zip

 

• Major rewrite of display setup logic to fix a bunch of corner case bugs, like frame blending giving a washed out display with PAL artifacting enabled, analysis modes rendering garbage in some modes, or double color correction with VBXE. Should be better now (knock on wood).
• Optimized 32-bit PAL artifacting code path.
• Fixed crash when toggling VBXE shared memory option on the fly.
• Added option to do linear color space frame blending. This gives more accurate blended colors -- alternating luma 0 and 15, for instance, is more like luma 11 on real displays than luma 7.5. (It still flickers like crazy on a C-1702, mind you, but frame blending is also to cope when PC displays can't maintain locked frame rate.)
• Fixed an issue with the new save states sometimes not loading because a cold reset was forced on state load.
• Added the JRC 64K + RAM cartridge type. Cart type 160 is not supported for this, has to be selected manually.
• Cartridge modes now appear in the mapper UI if they are possibly valid for the cartridge image size. Previously, they were not showing up if there was no autodetection rule for them, so they were only available if you checked the 'show all formats even if they may not work' option.
• The emulator will detect and warn in some cases if you have a disk mounted in a drive that can't read it, such as a medium-density disk in an 810. This is currently implemented only for full disk drive emulation.
• The Disk Explorer now checks whether the disk image file selected is already mounted in a disk drive and suggests to mount the image in the drive instead to prevent conflicts.
• Modifying a mounted image in the Disk Explorer now forces a disk change on that drive interface to invalidate track buffers on that drive. This prevents a Happy 1050 from returning stale data.

 

[Keatah]

Love these updates. With some imagination it's a little like visiting a Factory Authorized Service Center in the 1980's for an upgrade or repair.

[+JAC!]

Hi Phaeron,

 

I cannot manage to get Altirra 3.20-test24 to load the ".lst" and ".lab" file automatically upon start/entering the debugger when I boot an ".atr".

I works when I load the both files manually via ".loadsym".

Is that a limitation of using an ATR?

 

Regards, Peter.
 

[Mclaneinc]

Hi Peter, side note, any reason why you are usings such an old version, if memory serves me there have been additions and fixes for that side (debugging etc) in the numerous updates since then...

 

Anyway, thank you for all your productions and lessons in coding..Brilliant stuff..

[Wrathchild]

1 hour ago, JAC! said:

I cannot manage to get Altirra 3.20-test24 to load the ".lst" and ".lab" file automatically upon start/entering the debugger when I boot an ".atr".

Hi Peter,

So long as the debugger is open, when you load afresh the .lst/.lab get imported too.
Mark 

[_The Doctor__]

If I understand, you are saying the debugger needs to be open before he loads or boots, then it will get everything...

otherwise it doesn't expect to do so and loads as normal for anybody wanting to boot a disk and enjoy.

[Wrathchild]

That's the long and short of it

 

Background to this can be read from here