Jump to content
phaeron

Altirra 3.90 released

Recommended Posts

Hi @phaeron,

 

Here's an update on my previous over scan issue, which has now been corrected so that I can see the entire 80 characters across.

 

XEP80_Samsung_SyncMaster_730MW.thumb.JPG.121191e0b4c4afa4fddb01dc4eeaabd0.JPG

 

What I discovered is that there is a delay line made up from spare gates and a capacitor in the XEP80's HSYNC feeding the video output stage. I was designing an external video driver stage of a simpler design which had omitted this delay, hence the reason I was missing the last 3 characters. However even when feeding straight out of the XEP80's video output which incorporates the delay, I was still seeing a cut-off of the very last character. So I went ahead and added the delay line into my circuit and adjusted the capacitor value to pull the image slightly more to the left, and that did the trick.

 

But I noticed another issue with the lowercase descenders getting cut off on the bottom, which can be seen in the 'pyqq' in this enlarged image. Looks like maybe 1 pixel is missing.

 

XEP80_Samsung_SyncMaster_730MW_close-up.JPG.59fe087814e441b771b31c56d513ec49.JPG

 

Looking at the XEPVHOLD program, it appears that a PAL version has a 7x11 character cell, whereas the NTSC one only has a 7x9 character cell. Perhaps it needs to be a 7x10 instead. BTW, I am currently running in NTSC mode with a NTSC synced monitor connected to the XEP80.

 

Now I realize that adding more character height could possibly knock the last line partly off the bottom of the screen, but it looks like there is possibly enough free room at the bottom of the screen to allow for it. However I'm still scratching my head to make sense out of the interaction of the display timing chain parameters. Other than blindly changing stuff to see what happens, it would be better if someone in the know could give me a few pointers or suggest some new parameters.

 

But I gotta say I'm really liking what I'm seeing using your new drivers, and the VHOLD correction parameters. My intention is to still incorporate the new display timing parameters into the ROM, and I will be adding a bank select jumper to allow for both the NTSC and PAL versions to co-exist on the same 8Kx8 EEPROM that'll get substituted for the factory ROM.

 

EDIT: The more I think about it, I don't think adding another pixel to the bottom of each character cell is going to fly, because that would be a total of 24 pixels - or in other words slightly over two extra character cells in height - I don't have that kind of room. Probably more realistic to create new lowercase characters for the character ROM that stay within the 9 pixel high limit.

 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, mytek said:

Looking at the XEPVHOLD program, it appears that a PAL version has a 7x11 character cell, whereas the NTSC one only has a 7x9 character cell. Perhaps it needs to be a 7x10 instead. BTW, I am currently running in NTSC mode with a NTSC synced monitor connected to the XEP80.

 

Now I realize that adding more character height could possibly knock the last line partly off the bottom of the screen, but it looks like there is possibly enough free room at the bottom of the screen to allow for it. However I'm still scratching my head to make sense out of the interaction of the display timing chain parameters. Other than blindly changing stuff to see what happens, it would be better if someone in the know could give me a few pointers or suggest some new parameters.

The truncated 7x9 character cell is a compromise due to limitations with the NS405 and the built-in firmware. NTSC only has around 240 max active scanlines with reasonably visible being more around 220-230, so using a 10-high character cell would be pushing it heavily with overscan even if you ignore the status row.

 

However, there is a more pressing issue, which is the inflexibility of the NS405's vertical timing parameters. The NS405 requires vertical sync to occur within the first blank character row in vertical blank. This, combined with the hardcoded end-of-row interrupt handling in the firmware, limits the timing parameters that can be used since moving the row interrupt can scramble the regular displayed rows. This is why for NTSC XEPVHOLD actually configures the display for 26 rows and adjusts the VINT register to insert an additional active row off-screen to delay vertical sync. Without doing this it is basically impossible to get the NTSC vertical overscan situation under control since the last non-status row has to be within a dozen lines or so of vertical sync.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, phaeron said:

The truncated 7x9 character cell is a compromise due to limitations with the NS405 and the built-in firmware. NTSC only has around 240 max active scanlines with reasonably visible being more around 220-230, so using a 10-high character cell would be pushing it heavily with overscan even if you ignore the status row.

Yeah I came to the same conclusion. Since I plan on replacing the ROMs with EEPROMs pretty soon, I can look into maybe bumping the lowercase character set up 1 pixel within the cell to allow for a more complete looking lowercase character.

 

3 hours ago, phaeron said:

However, there is a more pressing issue, which is the inflexibility of the NS405's vertical timing parameters. The NS405 requires vertical sync to occur within the first blank character row in vertical blank. This, combined with the hardcoded end-of-row interrupt handling in the firmware, limits the timing parameters that can be used since moving the row interrupt can scramble the regular displayed rows. This is why for NTSC XEPVHOLD actually configures the display for 26 rows and adjusts the VINT register to insert an additional active row off-screen to delay vertical sync. Without doing this it is basically impossible to get the NTSC vertical overscan situation under control since the last non-status row has to be within a dozen lines or so of vertical sync.

Pretty tricky way to fool the NS405 into submission 👍

 

But from what I've seen it really does the trick well. Besides the Samsung monitor now working good (it rolled terribly without the new parameters), I can also use my Retrotink 2X to send it to a couple of different HDTVs, and in all cases it looks perfectly centered, displaying all the characters and rows.

Share this post


Link to post
Share on other sites

Hi @phaeron,

 

Unfortunately I have another issue to report, this time related to the Altirra XEP80 driver that looks a bit more serious. Just to be clear I'm running all these tests on real hardware (576NUC+ with Fujinet installed - Original Atari XEP80 connected to Joystick port 2 -  - files are booted from the Additions.ATR on the Fujinet SD card slot).

 

So I'll start this out by saying the problem seems to relate directly with the ALTXEP80.sys driver, and it appears to be a case of something getting out of sync between the 80 column screen and the internal interpretation of that within the Atari. I see the effect when editing a BASIC listing (either BASIC Rev C or the Latest Altirra BASIC). It doesn't happen immediately, and I haven't determined what leads up to it starting to happen, but it'll occur sometime in the process of editing and /or adding lines of code in BASIC. The best explanation I can come up with is that I think it gets off by one line position, with the XEP80 screen showing it's on a blank line, whereas the Atari OS probably sees that there is actually something already on that line - hence the error message. If I move down another blank line or two I can enter stuff without the errors occurring.

 

I think it'll be easiest to convey the problem by showing you images of the following sequence of errors when the problem first appears.

 

Image 1: I just did a listing, and then immediately follow that up by entering NEW where the cursor is resting on the next line after the READY prompt. When I hit Enter I get the error that is seen below. This is the first time in this programming session that something has gone wrong (probably about 15 minutes in).

 

1.png.c1414e1444e89dd04c1fc16495136e9b.png

 

 

Image 2: Next I decide to add a test line (line 16).

 

2.png.8cb61bd34ddc7d47eebd142e35e90a54.png

 

 

Image 3: When I then hit Enter I get another error.

 

3.png.525f4b182286e51980e5b9e303373b1d.png

 

 

Image 4: So at this point I want to see if the program is still in memory after the failed attempt at previously entering NEW. This results in something strange, with the cursor jumping back to the beginning of the line, but no READY prompt or listing appearing. No error this time either.

 

4.png.ca106403b6b17abc92442c6eab232056.png

 

 

Image 5: So I cursor down one more line and try it again. This time the program does list, although there is no added line 16 (no real surprise, since there was an error when I tried that earlier).

 

5.png.b2ebe7d1de72106f72cfc8bed411697f.png

 

 

From this point on the errors continue, and the only way to set things right is to reboot the system and reload the XEP driver.

 

So I decided to give the original Atari Driver a try, and still use the XEPVHOLD after it's loaded. I then go on a marathon programming session with never an issue. So I try rebooting and using the ALTXEP80.sys driver again, maybe another 10 minutes goes by of editing and running programs, and then the same sort of errors start occurring once again. So it's back to Atari's driver - with no issues to report.

 

I have since tried this on another 8-bit computer with a UIMB and XEL-CF3, and I see the same pattern. However I really don't know what that pattern is that sets this off, or if it's just totally random. These are the worse kind of bugs, because it's difficult to know when you've fixed it, due to the random nature.

 

BTW: I'm using the additions disk from TEST 35 for the source of the ALTXEP80.sys file.

 

And here's the source of the Atari XEP80 driver that appears to work without any issues: XEP80_Boot_Disk-DX5087.atr

 

Share this post


Link to post
Share on other sites

ZERO problems here, after editing for months on all sorts of Basic packages, editors. etc.

 

Operating environment, however, is SDX booting 0.93 driver (ULTRA-speed) as altxep.sys /p /u,  outputting PAL and converted as 576/i format, rendering 80x24 matrixplug-and-play:

 

C9FBBD4E-A2D9-4091-B061-12E22733A0EE.thumb.jpeg.469fb75e4352b9c53b1df0ffd284b5bb.jpeg

 

Any command, at any line gets processed correctly, including line 24.
 

Launching driver with /V optimization produces same results as above (no issues on live-editing, at any usable line), rendering (80+4)*25 matrix.

 

Have NOT tested long enough on [NTSC node + out of SDX + non-ultra drivers], though.

 

 

 

Share this post


Link to post
Share on other sites
1 hour ago, Faicuai said:

ZERO problems here, after editing for months on all sorts of Basic packages, editors. etc.

 

Operating environment, however, is SDX booting 0.93 driver (ULTRA-speed) as altxep.sys /p /u,  outputting PAL and converted as 576/i format, rendering 80x24 matrixplug-and-play:

As you said you are using a different driver and DOS (SDX). I'm testing using the CL DOS included on the Additions.ATR with the standard ALTXEP80.sys (NTSC) driver that I'm seeing the issues with. I copied onto that same ATR the standard Atari version which has been working without problems. It does take a bit of time before the problem appears, but once it does it's persistent.

 

Share this post


Link to post
Share on other sites
5 hours ago, mytek said:

From this point on the errors continue, and the only way to set things right is to reboot the system and reload the XEP driver.

So, the thing about the XEP80 is that it runs nearly the whole screen editor by itself. It's rare for the Atari to desync from the XEP80 in any way because the XEP80 manages the entire framebuffer, cursor position, and logical line state, and sends the cursor position back after every character. Lines entered with the XEP80 are retrieved by actually reading back from the XEP80.

 

One thing that can invisibly cause errors is hidden characters on-screen, which can cause line splices that you wouldn't otherwise get with the standard E: device. This is because the XEP80 handles logical lines differently, by using invisible EOLs in the framebuffer instead of a bitmap. Some of the symptoms you are seeing could be explained by a line splice, especially since the XEP80 is also responsible for moving the cursor back to the start of the logical line. But if this were the case, a good clear-screen should fix it up, it shouldn't be able to persist beyond that. It is possible to visualize this state by activating the internal character set (

 

The other thing that could cause problems is ANTIC DMA getting turned back on. Check if ANTIC is producing a screen the next time this happens. The ultra-speed driver forces DMACTL off if it sees it turned back on but the standard speed driver doesn't; it tries to coexist with ANTIC in this case though it hasn't been extensively tested.

 

Last thing, in your screenshots you have POKE 83,80. This sets RMARGN to 80, but RMARGN is inclusive, so this is actually extending the right margin behind the normal screen to make 81 columns. Is this intentional? The contents of the 81st column may not be well defined, and furthermore, the XEP80's clear screen routine only clears 80 columns. This may result in strange behavior as the XEP80 relies on the contents of the right column for managing logical lines.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, phaeron said:

So, the thing about the XEP80 is that it runs nearly the whole screen editor by itself. It's rare for the Atari to desync from the XEP80 in any way because the XEP80 manages the entire framebuffer, cursor position, and logical line state, and sends the cursor position back after every character. Lines entered with the XEP80 are retrieved by actually reading back from the XEP80.

 

One thing that can invisibly cause errors is hidden characters on-screen, which can cause line splices that you wouldn't otherwise get with the standard E: device. This is because the XEP80 handles logical lines differently, by using invisible EOLs in the framebuffer instead of a bitmap. Some of the symptoms you are seeing could be explained by a line splice, especially since the XEP80 is also responsible for moving the cursor back to the start of the logical line. But if this were the case, a good clear-screen should fix it up, it shouldn't be able to persist beyond that. It is possible to visualize this state by activating the internal character set (

Good info, and I'll try the clear-screen command next time I see it happen to see if that corrects it.

 

9 hours ago, phaeron said:

The other thing that could cause problems is ANTIC DMA getting turned back on. Check if ANTIC is producing a screen the next time this happens. The ultra-speed driver forces DMACTL off if it sees it turned back on but the standard speed driver doesn't; it tries to coexist with ANTIC in this case though it hasn't been extensively tested.

I'm pretty sure DMA is not  being reactivated, since I leave the main system monitor on the entire time, and it remains blank.

 

9 hours ago, phaeron said:

Last thing, in your screenshots you have POKE 83,80. This sets RMARGN to 80, but RMARGN is inclusive, so this is actually extending the right margin behind the normal screen to make 81 columns. Is this intentional? The contents of the 81st column may not be well defined, and furthermore, the XEP80's clear screen routine only clears 80 columns. This may result in strange behavior as the XEP80 relies on the contents of the right column for managing logical lines.

Yep me bad. That was a remnant from some of my first tests, and not even correct. I see that the default is already set for 80 columns (POKE 82,0 and POKE 83,79) so there is no need for that first line, I'll remove it.

 

Thanks for all the suggestions :)

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Improved XEP80 driver issues follow-up...

 

I switched over to using the ALT+L combination from my TK-II equipped 576NUC+ computer whenever I want to list something, and I haven't had any more problems. That key combination first issues a Clear Screen command, and then automatically sends 'LIST<enter>' to get a listing of the program memory.

 

For those that might be curious about why I am testing all this XEP80 stuff, check out this Blog Post ;)

 

Edited by mytek
I corrected the key combo, ALT+HOME doesn't do anything
  • Like 3

Share this post


Link to post
Share on other sites
7 hours ago, mytek said:

Improved XEP80 driver issues follow-up...

 

I switched over to using the ALT+L combination from my TK-II equipped 576NUC+ computer whenever I want to list something, and I haven't had any more problems. That key combination first issues a Clear Screen command, and then automatically sends 'LIST<enter>' to get a listing of the program memory.

 

For those that might be curious about why I am testing all this XEP80 stuff, check out this Blog Post ;)

 

nice work so far, are you planning on getting color out of the xep II as well or is that a bridge too far?

Share this post


Link to post
Share on other sites
8 hours ago, _The Doctor__ said:

nice work so far, are you planning on getting color out of the xep II as well or is that a bridge too far?

Thanks Doc :)

 

Color would not be easy. Despite what some have inferred that Atari dropped the ball on doing this, it's not like the display processor chip was really able to handle this easily out of the box. For one BITD it would have really required an RGB monitor, since composite or for that matter S-Video would not been sufficient to the task. If you look more in detail at the NS405 datasheet, you'll see what I am talking about hardware-wise.

 

Then there is the matter of support software and drivers. And also throughput speed considerations, since deciding what color a character is going to be at any given point on screen requires more information - more bits to be sent down the already limited serial link in other words. No Atari didn't mess up when they didn't supposedly exploit this feature.

 

So long story short, I will not be changing how the XEP80 presently works. This is simply a reboot of the hardware in a form factor 1/5 the size of the original (yep you heard that right), and due to the sweeping use of lower power support chips, able to do away with the external power pack, now getting its needs met entirely from the joystick port instead.

 

EDIT: It would be best to start a new topic if further discussion is required. I don't want to derail this one more than I already have :)

  • Like 1

Share this post


Link to post
Share on other sites
6 minutes ago, mytek said:

able to do away with the external power pack, now getting its needs met entirely from the joystick port instead.

That would be a home-run, considering that all the firepower we can muster on each of those ports would be 50mw (IIRC)... and I would trust the 800 power supply and routing more than my 800xls, for this particular matter (but have never actually measured how far we can go).

Share this post


Link to post
Share on other sites
1 hour ago, mytek said:

This is simply a reboot of the hardware in a form factor 1/5 the size of the original (yep you heard that right)

Sounds like maybe it could be integrated onto the 576NUC's fujinet/cartridge adapter board....  😀

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, StickJock said:

Sounds like maybe it could be integrated onto the 576NUC's fujinet/cartridge adapter board....  😀

Not gonna happen :)

 

For anymore questions, please let's continue this conversation over here...

 

Share this post


Link to post
Share on other sites

 

I'm using the latest beta and have been getting all the images kindly put up by SoulBuster in this thread

 

But all the CAS files bring up a command line error in this version of Altirra whereas they are fine in 3.90.

 

The error complains about missing bytes at line 0...

 

I just want to check if its just me getting this error, I've dumped my settings, and it's the same.

 

I only ask as I see only me reporting this so kind of wondering if I have a dud setup?

 

 

Share this post


Link to post
Share on other sites

@phaeron 4.00 test 31

 

I attached a existing ATR image and used the "Disk drives" dialog to create a new disk as D2:

Using the File/Attach Disk/Rotate option I swapped the drives.

However I accidentally hit 'Save' instead of 'Save as' on the new disk and this didn't seem to do anything (I checked it hadn't overwritten the ATR).

 

I retried afresh with just a new image on D1 and similar thing, so if an unsaved new disk image uses the 'Save' option then could this present the file dialog? 

 

Share this post


Link to post
Share on other sites
On 6/15/2021 at 3:59 AM, phaeron said:

Next time this happens, turn on System > Configure System > Output > Audio > Host Audio Options > Show Debug Info. It sounds like the emulator is getting confused about how far ahead/behind it is on audio and trying to push a ton of audio through. The debug info displayed by this mode would help show what the emulator is seeing in the sound path.

Hi @phaeron - I have managed to randomly trigger this again. Clues of what may have brought it on: typing a decent sized basic program, probably a couple of hundred lines. Realised I'd typed a line number wrong, and had overwritten an existing line... listed the line, edited the line number, pushed return, bit of a pause, and then it had switched into the weird sound/slow key repeat like earlier. As before, I'm in XL/XE OS ver 2, with Atari BASIC rev C.

 

The debug info overlay says...

Underflow count: 155 (rising slowly if I keep typing - is now 171)
Overflow count: 21890
Drop count: 261 (rising very slowly if I keep typing - is now 267)
Measured range: 24576-24576 (128.0 ms)
Target range: 15360-34560
Incoming data rate: 31671.64 samples/sec
Expected data rate: 63337.41 samples/sec
Mixing mode : mono

I'll try and trigger it in a repeatable way. And will leave the current one running in the background if there are more things to try. (Unless windows 10 update force reboots my computer without asking me... again...!)

Thanks!
W.

Share this post


Link to post
Share on other sites

Found it - ALT+Backspace seems to toggle the behaviour on/off... I must be catching that now and then when I'm attempting to edit in a hurry!
 

W.

Share this post


Link to post
Share on other sites

I'm receiving periodic save state files that do not work. Whenever I do a save state, my mind is thrown back to my 410 cassette recorder days, nervously hoping that the CSAVE was successful so I don't have to retype in my program 😬. Attached are two save states that crash. Do they contain any info that might help solve the issue? These save states produce an altirra popup, unlike my jumpman report that loads the game but is frozen with a blue overlay to the screen..

 

I'm using x64 4.00-test on windows 10. The files are from rescue on fractulus and koronis rift atr files.

rof-l25crash.atstate2 kr-r11-cr-filecrash.atstate2

Share this post


Link to post
Share on other sites

https://www.virtualdub.org/beta/Altirra-4.00-test36.zip

https://www.virtualdub.org/beta/Altirra-4.00-test36-src.7z

  • Builds are now hosted over HTTPS, so the links should work directly again. Older builds are also available over HTTPS, but they won't redirect due to annoying behavior in some browsers. I can't edit the old posts, but you can edit the links manually to https.
  • Debugger: 65C816 BRL instruction is now treated as ending a block in the disassembly.
  • Raw tape audio can now be loaded in FLAC format.
  • Fixed regression in loading CAS format tapes with FSK blocks, and fixed the read error message also always reporting position 0.

Tape editor has also received a few upgrades. It now has commands to convert selected ranges between standard (decoded bytes) and raw FSK, and also to extract files stored in standard C: format.

 

It also has two analysis features. The first is an Analyze tool that, when dragged over a selection, decodes and displays bytes in that selection. The second is an option to capture bytes as decoded dynamically through POKEY. Together, these can be used to diagnose boot errors:

 

image.thumb.png.1a63a8af36f72a900bda783c5c30a467.png

 

In this case, the problem is a poorly encoded CAS file containing a transition from a standard 'data' block (green) to an 'fsk ' block (blue). The gap in between (gray) is of the wrong polarity, causing a framing error from the start bit being shortened (red byte).

 

We can fix this by using the Draw tool to repair the start bit:

image.thumb.png.d44a97416f9280bd37a52e79727b11c3.png

 

...only to run into a problem later in the tape:

image.thumb.png.46d2a0e44b88d8b2b73ab85e11a2fb87.png

 

Here the analyzer is able to successfully decode the block with a valid checksum (blue bytes), but the boot fails with a framing error. The cause is a slight difference in estimated baud rate that causes the analyzer to just barely squeak by, whereas the OS boot is just slightly off enough for the stop bit sampling position to spill over into the next start bit (gray ticks). This is caused by another data/fsk split within the block, which causes timing problems since 'data' blocks can only specify baud rates to the nearest integer:

 

image.thumb.png.e9b860fd14d7a9cf5ed03e98c36f3519.png

 

...but since the analyzer can decode the block, we can have it rewrite the entire block as clean standard data to avoid the mid-block change in baud rate and the marginal bit sampling timing:

 

image.thumb.png.102842585e30adde4d3e4a8030bc9cc6.png

 

...and now that the tape boots properly, resave a repaired .cas file.

 

58 minutes ago, pmgraphics said:

I'm receiving periodic save state files that do not work. Whenever I do a save state, my mind is thrown back to my 410 cassette recorder days, nervously hoping that the CSAVE was successful so I don't have to retype in my program 😬. Attached are two save states that crash. Do they contain any info that might help solve the issue? These save states produce an altirra popup, unlike my jumpman report that loads the game but is frozen with a blue overlay to the screen..

 

I'm using x64 4.00-test on windows 10. The files are from rescue on fractulus and koronis rift atr files.

rof-l25crash.atstate2 30.69 kB · 1 download kr-r11-cr-filecrash.atstate2 32.14 kB · 2 downloads

Please include the specific test release when reporting versions, since we're up to 4.00-test36. The save states you have work for me, make sure you're on the latest test release since I fixed a couple of save state restore bugs in 4.00-test31.

  • Like 6
  • Thanks 5

Share this post


Link to post
Share on other sites
3 hours ago, phaeron said:
5 hours ago, pmgraphics said:

I'm receiving periodic save state files that do not work. Whenever I do a save state, my mind is thrown back to my 410 cassette recorder days, nervously hoping that the CSAVE was successful so I don't have to retype in my program 😬. Attached are two save states that crash. Do they contain any info that might help solve the issue? These save states produce an altirra popup, unlike my jumpman report that loads the game but is frozen with a blue overlay to the screen..

 

I'm using x64 4.00-test on windows 10. The files are from rescue on fractulus and koronis rift atr files.

rof-l25crash.atstate2 30.69 kB · 1 download kr-r11-cr-filecrash.atstate2 32.14 kB · 2 downloads

Please include the specific test release when reporting versions, since we're up to 4.00-test36. The save states you have work for me, make sure you're on the latest test release since I fixed a couple of save state restore bugs in 4.00-test31.

I updated to 4.00-test36 and was able to load the rof-l25crash.atstate2 save state file with no problems. Fantastic! 

Share this post


Link to post
Share on other sites

This is just plain obnoxious.

 

When connected to a BBS via telnet and bobterm, I have this annoying message on the lower left corner of my screen telling me that I'm connected.  I know that.  There's no way to get RID of this message?  It blocks content on my screen and is like TOTALLY unnecessary.

 

I'm suggesting a menu option to toggle this message, or, for the message to show for just five seconds or so before deleting itself.

 

Best,

 

Jeff

annoying.png

Share this post


Link to post
Share on other sites
Posted (edited)

In the keyboard short cuts screen in tools play around with view.ToggleIndicators and view.ToggleIndicatormargin...Remember to choose the shortcut keys and press add..

 

The margin will shrink the screen a little to allow all the indicators to be beneath it, I could not get toggle indicators to do what I thought it was.. Maybe my set up.. But then again I didn't test a connect so don't know if those indicators are the ones you can toggle (which would make sense as sector and drive can be toggled..)

 

 

Edited by Mclaneinc

Share this post


Link to post
Share on other sites

https://www.virtualdub.org/beta/Altirra-4.00-test37.zip

https://www.virtualdub.org/beta/Altirra-4.00-test37-src.7z

  • Fixed a rounding problem in the PAL high artifacting engine that was causing excessive banding.
  • Fixed an issue with the windowing on the audio low pass filter and added kernel interpolation to the resampler, for reduced aliasing from ultrasonic audio (which causes you to hear sounds that should be inaudible).
  • The disk drives dialog now asks for a save path if saving a disk that doesn't have a image path set yet, and blocks saving of dynamic disks.
  • Improved the performance of the raw turbo tape decoder.
  • Turbo tape modes have a bit better descriptions.

The Tape Editor now has the ability to view and edit the turbo decoder side of the tape, as well as to show the waveform input to the decoder (if waveform caching is enabled on load, which is off by default). For the turbo signal, this shows the post-filter output. The analysis tool now also has rudimentary Turbo 2000 decoding capabilities:

 

image.thumb.png.a16991859aab9b84ccb0943cf802312d.png

 

You can also see the distortion in the source waveform due to high frequency attenuation, which is what the compensating HPF is for:

image.thumb.png.ce296818504cffdb87d22f72c9e50bfc.png

  • Like 5
  • Thanks 5

Share this post


Link to post
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...