What's currently hot in 80-column upgrades?

[Mazzspeed]

35 minutes ago, GoodByteXL said:

Please look up the doc files on the original XEP80 disk from Atari.

 

The picture with the Philips shows the 80 column output, but by SDX' ED command the output switches to the 40 column display. Looks like this

I believe you, your comments make perfect sense.

 

So, essentially, as I stated, the XEP80 is a 24 line device with the 25th line used as a status line only, as was the case with the IBM PC. There should be a number of analogue monitors from the time compatible with 80x24 lines, modern monitors with scalers may confuse the output, which is possibly the case here.

 

Thanks for the explanation and picture of your setup, very nice! That's what I call a 'pure rendering path'.

 

EDIT: Difficult to display in 40 columns under ED, but there's the explanation on page 6 of XEP80.DOC:

 

Edited May 10, 2021 by Mazzspeed

[GoodByteXL]

1 hour ago, Mazzspeed said:

EDIT: Difficult to display in 40 columns under ED, but there's the explanation on page 6 of XEP80.DOC:

 

ED is not really useful for displaying files having lines longer than 39 chars.

With SDX use MAN instead. With an additionally registered viewer like LESS it is a very handy tool. Please see the manual for it.

 

The picture I posted was just a test to see if the ANTIC screen comes up properly ...

Edited May 10, 2021 by GoodByteXL

[Mazzspeed]

1 hour ago, GoodByteXL said:

ED is not really useful for displaying files having lines longer than 39 chars.

With SDX use MAN instead. With an additionally registered viewer like LESS it is a very handy tool. Please see the manual for it.

 

The picture I posted was just a test to see if the ANTIC screen comes up properly ...

A very handy hint, thank you.

 

I thought there would be a better option, I was just too lazy to check the manual!

 

EDIT: I could have also used the TYPE [Filename] /P command in hindsight...But, I've configured MAN anyway.

Edited May 10, 2021 by Mazzspeed

[+x=usr(1536)]

21 hours ago, Faicuai said:

That is not an NTSC monitor,  not a multi-sync one. It lists PAL as the format supported for its (only) composite input.

Correct.  I was just surprised at the idea that there might have been an NTSC version made, because I've never seen one of those monitors in the US.  As far as I was aware, they were PAL-only, which appears to have been the case.

21 hours ago, Faicuai said:

Latest drivers are always included in the ADDITIONS.ATR image that comes included with every Altirra's release.

 

Just grab yours. and upgrade to Ultra drivers. You several loads to try, and v/h range-running utility. You will see the effects immediately.

Thanks for the pointer on that - I'm not running Windows as a desktop OS, so my familiarity with Altirra is relatively minimal.  That said, I was able to extract the ALTXEP80.SYS and ALTXEP8F.SYS files from the additions disk and a make a couple of bootable test images.  While I haven't had a chance to test extensively, both drivers do boot properly and kick over to the XEP80's display.  Speed tests, etc. will have to wait until it's not almost 5am

 

[GoodByteXL]

22 minutes ago, x=usr(1536) said:

I was just surprised at the idea that there might have been an NTSC version made, because I've never seen one of those monitors in the US.  As far as I was aware, they were PAL-only, which appears to have been the case.

Hm, this is might be wrong thinking, because the 80 column monochrome monitors BITD were capable of catching 60 Hz and 50 Hz video signals.

 

It comes down to the question if it was made for 120 V power systems. And yes, there were the ones for Apple as well devices from Sanyo, Hitachi, and some no name brands. I remember having them seen at Radio Shack in the 1990's.

[+x=usr(1536)]

32 minutes ago, GoodByteXL said:

Hm, this is might be wrong thinking, because the 80 column monochrome monitors BITD were capable of catching 60 Hz and 50 Hz video signals.

Which appears to be the case with the Cub, at least according to the service manual.  Having said that, I don't believe that any of the Cub range were ever monochrome; their big selling point was that they were inexpensive full-colour monitors at a time when those displays were not cheap.

32 minutes ago, GoodByteXL said:

It comes down to the question if it was made for 120 V power systems. And yes, there were the ones for Apple as well devices from Sanyo, Hitachi, and some no name brands. I remember having them seen at Radio Shack in the 1990's.

WRT the Cub, the manual's stating input voltage of 180V-265V, so it doesn't appear as though they were made for use in 100V-130V regions.

[Faicuai]

1 hour ago, GoodByteXL said:

It comes down to the question if it was made for 120 V power systems.

No, it comes down to the question of whether such CRTs analog-decode stage could properly handle the inherent (and very real) sync.-timing differences between NTSC or PAL encoded signals (eg. line-blanking intervals, front porch. back porch, etc.)

 

50hz-60hz vertical-range means little in the above context. 

 

 

Edited May 10, 2021 by Faicuai

[Faicuai]

8 hours ago, GoodByteXL said:

Please look up the doc files on the original XEP80 disk from Atari.

 

The picture with the Philips shows the 80 column output, but by SDX' ED command the output switches to the 40 column display. Looks like this

 

Ok, so that confirms it: the little Philips CRT is showing the XEP80 in PAL mode, and it does NOT show (or partially shows a bit) the 25th line. The 25th line is ALWAYS present on the XEP80 video signal, and it is always active, whether or not any characters are placed there at any given time.

 

The GOOD "news" here (for Euro or dual NTSC/PAL Americas users) is that, when running [display + XEP] in PAL  (or 576i in modern terms), it is easier to extract 80x24 whether CRT or LCD (TV or monitor+video processor / scaler), thanks in part to the increased horizontal and vertical resolution of PAL, and how the XEP renders the character set on this video format.

 

Generally speaking, 24-rows would suffice almost ALL needs, because OS-provided E: handler has historically been exploited using 24 rows (and rarely 25).

 

Ok, so here's the moment of truth:

 

Could you, please, issue a DIR command on SDX, fill the XEP screen vertically, then go to Basic and type:

 

? CHR$(172);:XIO 20,#1,12,237,"E:", then RETURN.

 

Once done, could you please take a picture of the Philips screen, up-close, making sure that just a bit of the top/bottom/left/right monitor frame / bezel also appears in the pic?

 

Thanks!

 

Edited May 10, 2021 by Faicuai

[GoodByteXL]

2 hours ago, Faicuai said:

 

Ok, so that confirms it: the little Philips CRT is showing the XEP80 in PAL mode, and it does NOT show (or partially shows a bit) the 25th line. The 25th line is ALWAYS present on the XEP80 video signal, and it is always active, whether or not any characters are placed there at any given time.

 

The GOOD "news" here (for Euro or dual NTSC/PAL Americas users) is that, when running [display + XEP] in PAL  (or 576i in modern terms), it is easier to extract 80x24 whether CRT or LCD (TV or monitor+video processor / scaler), thanks in part to the increased horizontal and vertical resolution of PAL, and how the XEP renders the character set on this video format.

 

Generally speaking, 24-rows would suffice almost ALL needs, because OS-provided E: handler has historically been exploited using 24 rows (and rarely 25).

 

Ok, so here's the moment of truth:

 

Could you, please, issue a DIR command on SDX, fill the XEP screen vertically, then go to Basic and type:

 

? CHR$(172);:XIO 20,#1,12,237,"E:", then RETURN.

 

Once done, could you please take a picture of the Philips screen, up-close, making sure that just a bit of the top/bottom/left/right monitor frame / bezel also appears in the pic?

 

Thanks!

 

Hm, after having done the tests for SDX last month to write up the updates for the user guide I put that stuff away in the attic.

 

But I can tell you, this is leading nowhere. The XEP80 by default works in NTSC mode. Up to SDX 4.40 this was a show stopper in PAL county as many people tried to use it with their colour displays. Only monochrome 80 column monitors where always able to display the NTSC like output of the XEP80. It needed a little bit of adjustment of the H sync at the monitor as the signal of the XEP is a bit bogus. None of the software for the XEP80 I have ever seen and used showed 25 rows. It is uncommon for Atari 8 bit. Please look up the documentation on the original Atari disk for the XEP80 for explanations.

[Faicuai]

39 minutes ago, GoodByteXL said:

But I can tell you, this is leading nowhere. The XEP80 by default works in NTSC mode.

I do believe it is leading somewhere, though. 

 

It turns out I could not verify your story in Altirra: I purposely configured the system in PAL and launched the original XEP driver (on Atari-supplied disk), and, lo-and-behold, the XEP80 outputs automatically in PAL (the rendition of charset immediately reveals it, as it is markedly different from NTSC rendition). 

 

Therefore, either Altirra got it right (because the driver may auto-detects PAL / NTSC environment and instructs the XEP accordingly, with code that already exists on its firmware) OR Altirra is getting it "wrong" (that is, it switched the XEP emulation into PAL on its own, and the original OEM driver was written with total disregard of PAL, and divorced from the XEP´s own firmware).

 

So, until further results, or until I don't see the XIO output mentioned above. that Philips CRT sample is in PAL-mode and it is NOT showing the 25th line, fully. (which I personally dońt have any problem with, because that is the default XEP80 modus-operandi of my twin-LCD setup here). 

 

At the end of the day, it would have been really interesting to see what tuning would be required on that little CRT to cover the ~600 lines the XEP outputs in PAL.

Edited May 10, 2021 by Faicuai

[Mazzspeed]

It's a 24 line device with the 25th line used for status, as is the case with all 25 line 80 column devices. IMO, using all 25 lines looks terrible anyway.

 

Furthermore, in certain situations the extra line makes the device a flawed product. As GoodByteXL stated, it's all in the XEP documentation on the supplied software disk, he even provided a demonstration on how to use the 25th line as intended.

 

None of it has anything to do with bandwidth.

Edited May 10, 2021 by Mazzspeed

[phaeron]

8 hours ago, Faicuai said:

It turns out I could not verify your story in Altirra: I purposely configured the system in PAL and launched the original XEP driver (on Atari-supplied disk), and, lo-and-behold, the XEP80 outputs automatically in PAL (the rendition of charset immediately reveals it, as it is markedly different from NTSC rendition). 

 

Therefore, either Altirra got it right (because the driver may auto-detects PAL / NTSC environment and instructs the XEP accordingly, with code that already exists on its firmware) OR Altirra is getting it "wrong" (that is, it switched the XEP emulation into PAL on its own, and the original OEM driver was written with total disregard of PAL, and divorced from the XEP´s own firmware).

Both of you are correct.

 

The XEP80 always powers up in 60Hz text mode, and thus is 'natively' NTSC. However, the stock XEP80 handler checks the PAL register on open, and if it detects a PAL GTIA, issues the 'switch to 50Hz' command. This is dependent upon the software handler, though. It also gets reverted if the MASTER_RESET command is issued independently, or if you power-cycle the XEP80.

 

The SpartaDOS X 4.20 handler issue with PAL is a bit different, it tries to receive from the XEP80 with ANTIC on using a technique that has a lot less timing margin than the stock driver and gets into trouble with the difference between PAL and NTSC system clock speeds.

 

[Faicuai]

1 hour ago, phaeron said:

The SpartaDOS X 4.20 handler issue with PAL is a bit different, it tries to receive from the XEP80 with ANTIC on using a technique that has a lot less timing margin than the stock driver and gets into trouble with the difference between PAL and NTSC system clock speeds.

 

Thx!

 

Now it is clear that SDX built-in driver woes (even TODAY) go beyond what I tested right upon purchasing my XEP80, quite some time ago. Not only is slow as molasses, wastes CPU processing-power, FAILS the DEMO80.BAS, EIGHTY.BAS and WINDOW.BAS tests on Atari XEP80 Disk, and now it seems it failed to handle NSTC / PAL auto-detection properly.

 

What would be FANTASTIC with current Ultra-drivers would be:

1. The ability to track 559 register (SDMCTL, if IIRC) so when it reads 34, the Ultra drivers switch into "low-gear" timing-set prior to next E: write, and when the register reads "0", it goes into high-gear, high-performance timing-set, in same fashion. I know it would take up just a bit more of RAM, but may be well worth considering.
2. A service-vector for "sleeping" and "waking-up" the driver, in and out of HATABS, to enable temporary fall-back to Antic E: session, while always remaining resident in memory. This could be done, of course, completely outside of the driver, by manually patching HATABS and re-starting E:, and keeping lomem vectors. But having it available on the driver-space would be be something really special!

My 0.02c

Edited May 11, 2021 by Faicuai

[Mazzspeed]

And it's a 24 line device with the 25th line used as a status line that nothing supports. As evidenced by official Atari documentation. Furthermore, most of those examples of 84x25 lines look terrible.

 

However, there's better implementations, *cough* VBXE, available today. We also need to consider that in the day there were many 80 column analogue monochrome monitors that could display the XEP80's output just fine (perhaps with slight tweaking) as 80x24 lines with the 25th line being used as a status line wasn't unusual.

Edited May 11, 2021 by Mazzspeed

[Faicuai]

34 minutes ago, Mazzspeed said:

And it's a 24 line device with the 25th line used as a status line

 

It is simply a 80x25 device, that internally runs a 256x25 char. matrix (which can scroll pretty fast), and the last line can be used actively by any application that may need it, as such. It operates at a higher line rate (16.3Khz, hence bandwidth) than that of 480i and 576i, and thanks to Avery work (and not your immaterial babbling), we can now extract most of what it has to offer, in almost any modern screen, and on any Atari computer, with virtually no effort.

 

Those who just need a basic and usable E: session on 80 columns, plus running their host machines as fast as their clocks go, will be well served.

 

And, considering that you are the only participant on this thread that DOES NOT own (and does not really know) the HW being discussed, it would be safe to say that whatever you like or not on this topic, it is completely inconsequential.

 

Edited May 11, 2021 by Faicuai

[Mazzspeed]

1 hour ago, Faicuai said:

 

It is simply a 80x25 device, that internally runs a 256x25 char. matrix (which can scroll pretty fast), and the last line can be used actively by any application that may need it, as such. It operates at a higher line rate (16.3Khz, hence bandwidth) than that of 480i and 576i, and thanks to Avery work (and not your immaterial babbling), we can now extract most of what it has to offer, in almost any modern screen, and on any Atari computer, with virtually no effort.

 

Those who just need a basic and usable E: session on 80 columns, plus running their host machines as fast as their clocks go, will be well served.

 

And, considering that you are the only participant on this thread that DOES NOT own (and does not really know) the HW being discussed, it would be safe to say that whatever you like or not on this topic, it is completely inconsequential.

 

It's an 80x24 line device with a 25th line that's never used as a status line. It's bandwidth can't be that colossal as it runs via a limited composite connection containing luma and sync only and there is no evidence that component 'Y' has any more bandwidth whatsoever, it's simply filtering within the scaler stripping away luma information that results in a degrated signal via composite compared to component 'Y'. You exaggerate.

 

Even the manual states time and time again to use a dedicated luma input as opposed to composite expecting colour for best picture quality due to issues separating the chroma and luma signals on composite connections expecting a chroma signal.

 

84x25 looks bloody horrible. Furthermore, I'm in no way interested in owning a fairly flawed device like the XEP80.

Edited May 11, 2021 by Mazzspeed

[Faicuai]

Now onto some cool things that can be done with the XEP (just for the heck of fun):

 

The recent crop of Ultra drivers, not just run fast, but provide good abstraction from the host-machine configuration. That means, not only you can run the drivers on pretty much any A8, but we can locate them in MEMLO-side of base-ram (SDX) and MEMTOP-side (std. drivers, which ALSO work on SDX!)

 

Therefore, and with help of a bit of extra code, plus existing OS boot-manager facilities (OS/b, OS/n,  XL 02/03/04, Qmeg 4.04 and Altirra 3,31), we can wrap the drivers to "extend" the reach of an open XEP80 session to literally any E: compliant app., regardless of its age, original intent or loading protocol), as long  as nothing else beyond E: is required (of course).

 

What about booting your favorite E: compliant cart, or DOS-XL disk directly into 80-cols.session, right from SIDE-loader? Or what about doing that FROM your SDX prompt, and your active  XEP session there, just for fun?

 

Here's a cool example of the above, Atari Accountant (rarity = 10), requiring Basic and OS/b compatible OS, and 48K of base-ram. The whole package was close to $5,000 (or more) including all the necessary HW, back in the time:

 

 

 

More here:

 

https://atari8bit.net/the-atari-accountant/

 

 

For those 800 users with 52K (Incognito, RAMROD) or 48K users with 52K RAM expansion from Jurgen), you can "bootstrap" Atari Acccountant directly into a XEP 80-col session, right from your favorite SIO .ATR device, and run it along with your favorite OS/b FP-pack and Basic (in this case Altirra Basic 1.57), @ 1.79Mhz, much faster and zippier, still with the very same 1981 CPU ! (and even if 40-cols are hard-coded on the SW package).

 

I will post the wrapped drivers, later (Avery's core drivers are untouched, virgin. They are only wrapped with OS control-logic).

 

We may of course, wait for our high-strung VBXE prima-donas to happily show us how we could afford the same luxury with a cool FPGA-based board to actually enhance our retro-experience... Oh, wait! We have 400/800s and we need OS/b to start! ?

 

Let the fun begin!... ?

 

 

 

 

 

 

Edited May 11, 2021 by Faicuai

[Mazzspeed]

3 hours ago, Faicuai said:

We may of course, wait for our high-strung VBXE prima-donas to happily show us how we could afford the same luxury with a cool FPGA-based board to actually enhance our retro-experience...

As opposed to an expensive hometheater scaler just to get the geometry right so the image 'just' fits on the screen with excessive padding at the top of the screen, and to provide a luma input where the monitors have none...

 

Righto.

?

Edited May 11, 2021 by Mazzspeed

[Mazzspeed]

On 5/10/2021 at 5:51 PM, GoodByteXL said:

ED is not really useful for displaying files having lines longer than 39 chars.

With SDX use MAN instead. With an additionally registered viewer like LESS it is a very handy tool. Please see the manual for it.

 

The picture I posted was just a test to see if the ANTIC screen comes up properly ...

I actually configured The Last Word to open .DOC files and similar from anywhere within SDX from the command line due to it's software 80 column support, it works really well.

[+DrVenkman]

3 minutes ago, Mazzspeed said:

I actually configured The Last Word to open .DOC files and similar from anywhere within SDX from the command line due to it's software 80 column support, it works really well.

And of course, TLW has a hardware 80-column mode for used with a VBXE ...  

[drac030]

3 hours ago, Faicuai said:

We may of course, wait for our high-strung VBXE prima-donas to happily show us how we could afford the same luxury with a cool FPGA-based board to actually enhance our retro-experience...

You think that XEP is competitive to VBXE, seriously? Anything in XEP, when compared to VBXE, can be called "luxury", really? The human race never stops surprising me

 

[Mazzspeed]

30 minutes ago, DrVenkman said:

And of course, TLW has a hardware 80-column mode for used with a VBXE ...  

Lol!

 

It's software 80 columns for me...Wow, look at what that manual states!

 

[Faicuai]

45 minutes ago, drac030 said:

You think that XEP is competitive to VBXE

Aha!!!! I can now see what the issue is!! ?

 

Look: per your (rhetorical) question, it seems that you are the one troubled with the relative "competitiveness" of the products, while I (in contrast) really don't care (an iota) which one is better than the other. I never cared about such question, to begin with.. Instead, I only care about how sufficiently effective they may be ON MY FLEET (since this whole thread is all about providing 80 columns, hopefully E: compliant).

 

You can keep those existential / competitive issues out of the equation, as they all belong to you (and reside in you). And to this effect, I does not matter who likes it or not, who cries about it or not, who moans or not, you can run a pretty decent E: in 80 columns session with the XEP80 (and with ALL of my fleet !!!) I don't care how much better it will be on VBXE, because I have minus-infinity interest on it.

 

And if you find my XEP adventures, findings, experimentation and observations irritating, That's square-and-center your problem.  Or, perhaps, you are welcome to show-and-tell the UNIQUE aspects of how an E: session can be enhanced (well beyond what's plain evident).

 

Enjoy the ride!!! (you may not like it, though... That's too bad!)

Edited May 11, 2021 by Faicuai

[drac030]

3 minutes ago, Faicuai said:

And to this effect, I does not matter who likes it or not, who cries about it or not, who moans or not, you can run a pretty decent E: in 80 columns session with the XEP80 (and with ALL of my fleet !!!)

Yeah. I just asked a question, can anything in XEP be called luxury when comparing to VBXE. "Luxury" is the word you have used.

 

Please remember that I have both devices.

 

 

Yeah, that is Rapidus in turbo mode (20 MHz CPU clock - the much despised ICD driver handles that without any problem).

 

And no, your experimentations are not irritating. They just make me curious: do you really think that XEP can be compared to VBXE as a real competitor? Because that is what your posts suggest.

[Faicuai]

16 minutes ago, drac030 said:

They just make me curious: do you really think that XEP can be compared to VBXE as a real competitor? Because that is what your posts suggest.

NO, they don't make you curious. Instead, you find them profoundly dissappointing and bothersome (it's just that you may have not the guts to say it out loud... but I do. ?)

 

Proof? You are again asking the same question, when you already got my real position on this matter, fair-and-square, right above. Just leave your "competitive" traumas behind here, and move on... And, PLEASE, don't get me going with "Rapidus"... I don't want you puking with my opinion on this matter... ?