Altirra 3.90 released

[Faicuai]

4 hours ago, Stephen said:

Is there a driver setting that can fix the overscan issue on the XEP80?  It's supposed to display 25 lines of text.

Correct, it will display a total of 25 lines, which can be seen with Avery's vertical-scan tuning... but the thing is that a) the screen looks all f_k'd up with that garbage down there, b) in standard E: operation, there are NO 25 lines being addressed (e.g. SDX uses 24 by default), c) I don't really know applications that use 25 lines, except one.

 

On my current video-path, I can horizontally display MORE than what the XEP80 needs, and vertically I can see almost entirely all of 24 lines (PAL-mode), except the bottom two scan-lines of 5 or 7 characters). All of this with zero (0) adjustments on my end, it is all automatic. As for that last 25th line, I really don't mind at all, in practical terms, after putting the XEP80 through its paces, and seeing it on-screen.

 

With this setup, I have RF, Composite (+ artifacting), s-Video (y/c), DVI (Sophia) and Component (XEP80) interfaces, on a dual LCD setup. All interfaces are fully functional and independently operational. I can see any NTSC SW title, at any time, with any rendering intent, right from the host machine (800).

 

 

Edited March 16, 2021 by Faicuai

[+Stephen]

1 hour ago, Faicuai said:

With this setup, I have RF, Composite (+ artifacting), s-Video (y/c), DVI (Sophia) and Component (XEP80) interfaces, on a dual LCD setup. All interfaces are fully functional and independently operational. I can see any NTSC SW title, at any time, with any rendering intent, right from the host machine (800).

Nice setup, but this finally confirms what I have been saying for years and being told I was wrong.  And I was not.  The XEP-80 horribly overscans, and this cannot be corrected, nor accounted for. I'm marking a date on my calendar - on the Ides of March, 2021, it was admitted, the XEP-80 is out of video spec.  I can put this one to rest.  Now, if I could only get people to stop re-capping every device under the sun for the fun of it, I'd have a really good day.

[Faicuai]

50 minutes ago, Stephen said:

Nice setup, but this finally confirms what I have been saying for years and being told I was wrong

Whoever called you wrong is just disconnected from reality. The XEP80 DOES overscan, significantly... but wait until you see the Bit3 vertical scan.... *heartbreaking*, to say the least...

 

I am surprised Altirra does not emulate Bit3... or did I miss it on the device list? I'll re-check...

[drac030]

On 3/14/2021 at 5:53 PM, cathrynm said:

Would an updated Spartados Driver allow that EDX editor to work on XEP80?

 

On 3/15/2021 at 6:36 PM, Faicuai said:

EDX on SpartaDos requires RC_GR8.SYS or VBXE drivers to work. It seems it calls upon them, directly, and as far as I can see, such implementation model does not seem compatible with XEP80 drivers nor the way they address the editor-screen, itself.

Quite contrary, I believe that such a driver could be designed even for a chalkboard, let alone the XEP. The only problem being that it would, I think, truly expose its (the XEP's) slowness caused by the slow serial connection (yup, even in the "ultra" mode).

 

On 3/15/2021 at 10:06 PM, phaeron said:

As for XEP80 overscan, XEPVHOLD.COM on the Additions disk will reduce the XEP80's character cell from 10 lines to 9 lines, which reduces the active area from 250 lines to 225 lines.

As I can see under the emulator, the values used in XEPVHOLD.COM may not be quite suitable for PAL. If I am not mistaken, the program sets the first 7 TCP registers as follows: $6C,$4F,$52,$5F,$80,$1C,$19.

 

This causes the lowest row(s) of each character to be cut off (which is visible on letters like "j"). With some experimentation I was able to get Altirra to produce display with the last three values set as $91,$1E,$18. This seems to improve the situation on PAL: "j" is wholly visible, and the total number of scanlines seems to be 312 (if I calculate correctly). I unfortunately have no idea how a real XEP would behave when fed with this or if it really improves anything on the real device.

 

[phaeron]

5 minutes ago, drac030 said:

As I can see under the emulator, the values used in XEPVHOLD.COM may not be quite suitable for PAL. If I am not mistaken, the program sets the first 7 TCP registers as follows: $6C,$4F,$52,$5F,$80,$1C,$19.

 

This causes the lowest row(s) of each character to be cut off (which is visible on letters like "j"). With some experimentation I was able to get Altirra to produce display with the last three values set as $91,$1E,$18. This seems to improve the situation on PAL: "j" is wholly visible, and the total number of scanlines seems to be 312 (if I calculate correctly). I unfortunately have no idea how a real XEP would behave when fed with this or if it really improves anything on the real device.

Yes, that caveat is true, XEPVHOLD.COM is not intended for or tested on PAL. Altirra does emulate reprogramming the timing chain, and it will also blank the display with an error if the timing parameters are too far off (48-52Hz vertical, 14.7-16.7KHz horizontal), but it does not attempt to emulate visible/overscan regions for the XEP80.

 

Indeed, PAL has enough visible scanlines that the standard font could be used as-is. This avoids the need to truncate characters. The main difficulty is the same as NTSC, however: the NS405's poor design which requires vertical sync to occur within the first character row. Creating a normal video display without excessive overscan thus requires programming the NS405 to display more than 25 non-blanked rows and displaying spaces in those rows. Unfortunately we cannot do this without reprogramming the firmware, and so we're stuck with workarounds that display some garbage rows.

 

Note that overscan isn't the only reason I wrote XEPVHOLD.COM -- as the name might suggest, it's actually to correct the timing so the display doesn't vertically roll. Both my LCD monitor and TV can't lock onto it, only the old C-1702 can (and even that only with tweaking the vertical hold).

 

[cathrynm]

10 hours ago, phaeron said:

Yes, that caveat is true, XEPVHOLD.COM is not intended for or tested on PAL. Altirra does emulate reprogramming the timing chain, and it will also blank the display with an error if the timing parameters are too far off (48-52Hz vertical, 14.7-16.7KHz horizontal), but it does not attempt to emulate visible/overscan regions for the XEP80.

 

Indeed, PAL has enough visible scanlines that the standard font could be used as-is. This avoids the need to truncate characters. The main difficulty is the same as NTSC, however: the NS405's poor design which requires vertical sync to occur within the first character row. Creating a normal video display without excessive overscan thus requires programming the NS405 to display more than 25 non-blanked rows and displaying spaces in those rows. Unfortunately we cannot do this without reprogramming the firmware, and so we're stuck with workarounds that display some garbage rows.

 

Note that overscan isn't the only reason I wrote XEPVHOLD.COM -- as the name might suggest, it's actually to correct the timing so the display doesn't vertically roll. Both my LCD monitor and TV can't lock onto it, only the old C-1702 can (and even that only with tweaking the vertical hold).

 

I have an old-ish Samsung TV, and if I plugin to the video connector without XEPVHOLD the screen chops off the bottom two lines and the right two characters, and XEPVHold fixes the bottom two lines, but the right two characters are still chopped. I have a retroTink to HDMI and the same monitor, and that is the same vertically, but I get most of the 80 characters on screen with the same TV only losing a few pixels on the 80th column, and this for me is mostly useable.  I do have a cheap USB video/Svideo recording dongle and I'm unable to get it to work at all with XEP80. I tried Pal Mode and NTSC mode, and nothing works with that. This thing has zero documentation at all, so I don't even know if it's supposed to work with PAL. I might try the settings above, but not optimistic.

 

I was hoping there'd be some kind of PAL to HDMI dongle out there on Amazon that might work and show all the lines, but so far my experience has been that this signal is too weird for the one I have.

How did it ever ship like this? I suspect engineering at Atari was getting sloppy in the Tramiel era.

[_The Doctor__]

cathrynm,

 

I think a lot more information is needed,

What is your location, display system (computer and crt/lcd), make and model, of display... which drivers etc etc..

Most CRT's can be adjusted to fit and have a centered, correct geometry, todays LCD displays and televisions.. not so much.

Old days I had great luck with CRT's

RCA, Toshiba, NEC, JVC, Optima, Sharp, and a few off brands never cut off the left or right hand side of anything. When adjusted and aspect ratio was maintained, just about anything that was display showed including top to bottom. The display normally would show just a touch of embedded info in the frame on normal broadcast shows at the very top of the display as you will see a faint showing might be a stray dot or so.

I spent a good deal of time adjusting other peoples televisions and monitors after users group meetings once they see what's missing. It was like that up to the S-Video craze when the manufacturers started adjusting the sets better and added better voltage control circuitry.. Sanyo however was not a good set even at that stage though... Samsung was wildly terrible and great depending on what set, very inconsistent.

 

Modern displays lock just about anything useful away in the service area of the set and it's firmware, even if you get there, most option don't exist there either. Some folks on AA have made their own firmware for both CRT and LCD sets.

 

Maybe armed with some information we could get you closer to a normal display...

 

My Samsung television in the living room chops too much off on the right hand side... and the bottom, even though you select the correct aspect ratio and turn the 16:9 off and set it to Standard definition old school aspect ratio... it still cut the bottom off on most things it really just blanks the info at the bottom out like a video gate that cuts the bottom off instead of the right hand side....

 

I have a VIZIO that does ok, but and Olevia that does it all just fine... and the odd thing is the Olevia is one of the first LCD/Monitor/VGA/Svideo/composite/old tuner combination sets.

 

A number of the HDTV tube sets did very well with this stuff as well

[Faicuai]

13 hours ago, drac030 said:

Quite contrary, I believe that such a driver could be designed even for a chalkboard, let alone the XEP. The only problem being that it would, I think, truly expose its (the XEP's) slowness caused by the slow serial connection (yup, even in the "ultra" mode).

 

Nah, I am not that concerned about slowness.

 

One thing that opened my eyes, here, was filling 80-col E: screen (in Basic) via a simple program outputting an arbitrary long string many times. Then, when ended, navigating back to the middle of the screen and then inserting / deleting chars-by-chars or pressing Return or Shift-delete several times.

 

Watch what happens with the XEP80 on, and then try with (say) RC_GR8.SYS and CON 80, on (say) exact same E: session as above. That is eye opening as to what kind of editing functions and performance could be implemented over the XEP80.

Edited March 17, 2021 by Faicuai

[phaeron]

10 hours ago, cathrynm said:

I have an old-ish Samsung TV, and if I plugin to the video connector without XEPVHOLD the screen chops off the bottom two lines and the right two characters, and XEPVHold fixes the bottom two lines, but the right two characters are still chopped. I have a retroTink to HDMI and the same monitor, and that is the same vertically, but I get most of the 80 characters on screen with the same TV only losing a few pixels on the 80th column, and this for me is mostly useable.  I do have a cheap USB video/Svideo recording dongle and I'm unable to get it to work at all with XEP80. I tried Pal Mode and NTSC mode, and nothing works with that. This thing has zero documentation at all, so I don't even know if it's supposed to work with PAL. I might try the settings above, but not optimistic.

 

I was hoping there'd be some kind of PAL to HDMI dongle out there on Amazon that might work and show all the lines, but so far my experience has been that this signal is too weird for the one I have.

How did it ever ship like this? I suspect engineering at Atari was getting sloppy in the Tramiel era.

So, about that horizontal positioning issue...

 

After some investigation, it's beginning to look like about half of the XEP80's issues are at least the fault of National Semiconductor for their NS405 design decisions, with only the other half of it being Atari's fault.

 

I sat down and recomputed the video timing against NTSC broadcast specs (SMPTE 170M), and the XEP80's screen is indeed off-center horizontally. The center of the active region should be about 44% from the leading edge of horizontal sync, and the XEP80's default timing is a bit off from that at 39% as well as the horizontal sync pulse being way too long. The NS405 timing chain is more flexible for horizontal sync than vertical sync, and so XEPVHOLD can easily be adjusted to tweak the hsync parameters. However, the NS405 documentation seems to be wrong for the HSBR and HSER registers in the timing chain. It documents them as follows:

• HSBR: Character position in horizontal scan after which horizontal sync begins. Enter desired count + 2.
• HSER: Character position in horizontal scan after which horizontal sync ends. Enter desired count + 2.

With a 109 char line, HSBR=$59 and HSER=$61 should give an 8-character (4.67us) sync pulse with a delay of 48 characters from screen center (28us), the closest we can get to the ideal 4.70us and 27.928us. XEPVHOLD.COM currently just uses the original XEP80 defaults of $52/$5F, but it's an easy change. Except... it's still off by about two characters to the right. Had to pull out the scope to look at the video signal to see that this actually gives a horizontal sync pulse that starts about 2.5 chars later and ends about 0.5 chars later than expected. So, the docs are wrong and you don't add 2 to HSBR, and there's an additional 0.5 char delay. Yay.

 

Taking this into account, HSBR=$57 / HSER = $61 centers the display nicely. But there's another problem:

 

 

What you're seeing there is the row counter incrementing four characters too late. The NS405 requires an external row counter when an external character ROM is used since it doesn't output its internal row counter. This is accomplished in the XEP80 by a 74LS163 counter. What I couldn't figure out is why this glitch was occurring since the '163 is clocked off of the leading edge of horizontal sync, so moving hsync shouldn't have changed it. Pipelining was my first thought, similar to the way ANTIC prefetches data about 5 cycles early, but there's dozens of cycles between hsync and the start of the next line.

 

That is, until I spotted this little gem in one of the reference notes:

 

However, in addition to the DMA controller the video circuits also employ a four level FIFO to ensure a smooth data flow.... The FIFO prefetch for the next line is performed shortly after horizontal blank starts.

 

In other words, the NS405 prefetches data for the first four characters for the next row almost immediately after the end of the last line. The effect of this dumb design is that in order for the external row counter to work correctly it is basically required to place horizontal sync almost at the start of horizontal blank, resulting in the display getting shoved to the right. Otherwise, the prefetch for the next line happens before the row counter increments, and you get the tearing seen in the image above.

 

I'm not sure how to work around this, since it's essentially a hardware issue with the NS405 design and the way that the the external row counter is clocked. The only solution I can think of that might work is to extend the active display region to the right, extending lines past 80 characters so that the end of horizontal blank is once again close to the start of horizontal sync. This risks garbage getting displayed in the right margin, and more importantly shortens horizontal blank time which might cause problems for the firmware interrupt handlers. This explains why Atari placed the horizontal sync where they did, though, because the hardware doesn't work properly if you place it where you're supposed to.

 

 

 

[_The Doctor__]

except maybe it's  4.9 maybe 5.something  characters which results in the 5th character sometimes appearing as a combined image shifted a pixel up and we get the lcd your using in this example showing both combined (is that due to some processing by the tv, or ???)... that might be the half character delay.

  Look closer at the  t in  xxaltirra

  Look also at the  E in   D1:XE

  in the last line the 4 is almost cut in half (truly torn), the shifting not as notice because the line it straight on the right but you can still see the effect on the diagonal

Edited March 18, 2021 by _The Doctor__

[Faicuai]

8 hours ago, phaeron said:

'm not sure how to work around this

 

There is a solution (for this and many other problems):

 

 

Just be patient in eBay and SNIPE it as soon as the right deal comes from.

 

For anyone serious about actual Atari HW, and with the advent of the multitude of video interface options (including Sophia-2), it then becomes necessary to abstract / separate ALL video decoding/routing/processing from actual rendering / viewing device. That is, the "let me hook it to my TV" approach no longer cuts it.

 

Been there. done that for years now (got mine for $90 bucks, best money I ever spent in modern times!):

 

 

 

 

DVDO iScan HD+.... Can't recommend it strongly enough.

 

 

Edited March 18, 2021 by Faicuai

[cathrynm]

2 hours ago, Faicuai said:

 

 

 

 

 

 

 

Haha, is that it, the mythical '25th line' of the XEP80 on an LCD? It actually exists.

Edited March 18, 2021 by cathrynm

[Faicuai]

1 hour ago, cathrynm said:

Haha, is that it, the mythical '25th line' of the XEP80 on an LCD? It actually exists.

NoOo!  Only 24 shown there, running in PAL mode (on Component-Luma input #1, with ample horizontal-scan range and maximum sharpness).

 

The issue that I have seen along the way is that such 25th line is hard to use or realize with environment-portability and general benefits, in mind. Even apps. that have been written to exploit the Bit3 (like LJK products, for instance) WILL NOT use more than 24 lines in 80 cols mode.

 

Three is only one (1) app I know it uses the 25th line, but I could care less about it.

 

Edited March 18, 2021 by Faicuai

[phaeron]

4 hours ago, _The Doctor__ said:

except maybe it's  4.9 maybe 5.something  characters which results in the 5th character sometimes appearing as a combined image shifted a pixel up and we get the lcd your using in this example showing both combined (is that due to some processing by the tv, or ???)... that might be the half character delay.

  Look closer at the  t in  xxaltirra

  Look also at the  E in   D1:XE

  in the last line the 4 is almost cut in half (truly torn), the shifting not as notice because the line it straight on the right but you can still see the effect on the diagonal

That's just an artifact of taking a picture of a moving target. The FIFO timing isn't precise since it depends on memory bus utilization, so the last column flickers.

 

4 hours ago, Faicuai said:

There is a solution (for this and many other problems):

Sure, but this doesn't fix anything in the XEP80, it just adds a device that's tolerant of its extremely poor output. I don't think it's worth discussing tweaks that only target this one device, it's more interesting to try to find ways to make the XEP80 workable with more displays.

[_The Doctor__]

 

interesting how real life interactions cause such oddities

 

Edited March 18, 2021 by _The Doctor__

[cathrynm]

On 3/17/2021 at 1:10 PM, Faicuai said:

 

Nah, I am not that concerned about slowness.

 

 

If the driver can use burst mode, and is able to batch all the characters at once to send to the XEP80, I think it'd be fine. Character at a time would be slower, and if there's a lot redraw, that is if it scrolls the screen by redrawing the entire screen, that would be tragic slow.

[Faicuai]

36 minutes ago, cathrynm said:

If the driver can use burst mode, and is able to batch all the characters at once to send to the XEP80, I think it'd be fine. Character at a time would be slower, and if there's a lot redraw, that is if it scrolls the screen by redrawing the entire screen, that would be tragic slow.

 

Correct!!

 

And how do we know? Well, all we need to do is take a peek on a large .TXT file under AtariWriter-80 (for XEP)... Once opened, just "Edit" and then move around... by inserting chars, deleting adding lines, and scrolling continuously.

 

Clear signs of a combination of in-buffer/ram manipulation (XEP), burst-of-chars Tx, and char-by-char Tx.

[drac030]

44 minutes ago, Faicuai said:

Once opened, just "Edit" and then move around...

XEP is basically the "E:" device implemented as a separate computer. So as long as you stick to the functions the "E:" supports and so the XEP can perform them internally (e.g. vertical scrolls of the entire screen), it will be fast. But when you want to do something "E:" does not support, e.g. the vertical scroll of a part of the screen (like one of the panels in Sparta Commander), you will probably have to redraw it character by character.

 

For now it seems that implementing an RC driver on XEP would involve buffering the entire screen in the computer's memory, then performing all complex operations there and updating the XEP's display in burst mode, possibly only those locations which changed. Even with this, I am still pessimistic.

 

And when comparing to RC_GR8, remember that 1) it is only a cheap replacement for the VBXE driver, 2) the character display in RC_GR8 is emulated using the GR.8 pixel mode, 7680 bytes of screen memory with characters having the width of a nybble each and the height of 8 bytes. No wonder that a specialized terminal microcontroller can beat it performing internal operations.

 

 

Edited March 18, 2021 by drac030

[Faicuai]

48 minutes ago, drac030 said:

So as long as you stick to the functions the "E:" supports and so the XEP can perform them internally (e.g. vertical scrolls of the entire screen), it will be fast.

Precisely the point.

 

You are describing there what a simple, basic editor is all about. Therefore, no reason to doubt that an "EDXep" version of "EDX" would not fair well, or acceptably, at least... again, for basic editing functions that do not require complex addressing or direct manipulation of sectors of screen memory / buffer.

 

That, plus Avery's ULTRA speeds (which can go HIGHER with Motorola PIA, as I have seen on my own scope), should be good enough for many here.

 

(UPDATE: even TrubTerminal for CP/M should do well re-implemented for XEP80 / Ultra drivers).

 

Edited March 18, 2021 by Faicuai

[cathrynm]

4 hours ago, drac030 said:

 

For now it seems that implementing an RC driver on XEP would involve buffering the entire screen in the computer's memory, then performing all complex operations there and updating the XEP's display in burst mode, possibly only those locations which changed. Even with this, I am still pessimistic.

I see what you mean. Maybe could be fast enough, but would be a bit of work to make it fast enough, and all for the like, 10 people who would actually use this.

[drac030]

4 hours ago, Faicuai said:

You are describing there what a simple, basic editor is all about.

Except that "E:" is neither simple nor basic. Quite contrary, it is rather complex, which means a noticeable measure of added overhead, plus it tends to do some things automatically, which means that, apart from the aforementioned overhead, you fall into additional trouble trying to prevent it doing things outside your control (like concatenation of physical lines into logical lines, scrolls).

 

"E:" is a higher level device which should have been built on top of "S:", so that if where one needs the editor's functions, "E:" gets called, and when one needs basic functions with hardware abstraction, "S:" is in use. Instead, they are hopelessly intermixed and their functions are not separated very well. The RC drivers is an attempt to provide that missing lower layer of display driverage, where, no matter what you do, you always have control on what is where (no automatic scrolls and such stuff).

 

33 minutes ago, cathrynm said:

10 people who would actually use this

That is not an argument, if I were writing programs to get large audience, I would probably write applications for smartphones and not programs for Atari.

 

Edited March 19, 2021 by drac030

[cathrynm]

1 hour ago, drac030 said:

Except that "E:" is neither simple nor basic. Quite contrary, it is rather complex, which means a noticeable measure of added overhead, plus it tends to do some things automatically, which means that, apart from the aforementioned overhead, you fall into additional trouble trying to prevent it doing things outside your control (like concatenation of physical lines into logical lines, scrolls).

 

Yeah, 'E:' is a bundle of quirks, and then XEP80 E: is yet another layer of additional quirks on top of an already quirky system.

[trub]

18 hours ago, Faicuai said:

(UPDATE: even TrubTerminal for CP/M should do well re-implemented for XEP80 / Ultra drivers).

Once I prepared a terminal prototype for XEP. However, I had to abandon it, because the speed of displaying characters through the joystick port is 15.7 KBit, while communication with CP/M-enabled drive is 19.2 KBbit. This causes characters to be lost. So the Indus CP/M performance should be slowed down to work properly with XEP. I don't think it's worth the effort.

[_The Doctor__]

1 hour ago, trub said:

Once I prepared a terminal prototype for XEP. However, I had to abandon it, because the speed of displaying characters through the joystick port is 15.7 KBit, while communication with CP/M-enabled drive is 19.2 KBbit. This causes characters to be lost. So the Indus CP/M performance should be slowed down to work properly with XEP. I don't think it's worth the effort.

however now now that avery has the xep driver moving along at a decent pace it may be a better chance now. You still have to contend with a traffic cop scenario, although isn't that kind of what the two disk drives control method juggles when using cp/m anyway.

[drac030]

XEP-80 is a device designed especially for people who have nothing but successes in their life and want some rest.