XEP80-II a new beginning

[+Stephen]

53 minutes ago, Mathy said:

Hello guys

 

After Michael finishes the XEP80-II somebody else could come up with XEP80-III with "feature creep deluxe" and untie the cheetahs legs.      (not me!)

 

Sincerely

 

Mathy

 

 

No - adding colour is not easy, there's no chance for a blitter.  If you want the untied cheeta, please buy a VBXE and help spread it rather than re-inventing a wheel and further segmenting a market with a few dozen people at best.

[Faicuai]

1 hour ago, mytek said:

Sometimes you've got to stick to the main target and resist adding bells and whistles

Well, after using the XEP80 regularly for over a year, now, I could say:

 

1. You may consider working closely with Phaeron to improve and extract down to the last bit of performance (line-rate speed) out of the new PCB. Would it make sense to buffer inout and output lines with a simple improvement on the data-interface circuit (?) I don't know, but any improvement there may be simple enough, could be easily supported in SW, and will reverberate on everyone's day-to-day use of the unit. Avery's ULTRA drivers rock on the XEP80!
2. Include a simple video-switch (on / off) addressable through SW or driven from NS405, similar to how Bit3 FullView works on the 800. Why? Because if the end user has the ability to turn on and off video output (while keeping the XEP main processor running), the CRT, TV or external video processor will quickly detect this change and switch to the next active signal, automatically, which will GREATLY enhance users with a single-screen setup, including cabling and interfacing (another way to solve this is a dual-screen setup, bit this may not be generally feasible for everyone).
3. PAL / NTSC is switchable via SW command (in current XEP80). Could it be done on XEP80-II?
4. Keep an eye power consumption and stability over DB-9 port, since each one of those ports is rated for 50mw, IIRC. The current XEP80 draws about 4-5 watts, as it is (although it is clear the new PCB seems more optimal on this regard).

 

That's about it. 

 

A very nice project, indeed!

[+DrVenkman]

1 hour ago, Stephen said:

No - adding colour is not easy, there's no chance for a blitter.  If you want the untied cheeta, please buy a VBXE and help spread it rather than re-inventing a wheel and further segmenting a market with a few dozen people at best.

For real - VBXE is awesome and if only it didn't require a 15.7kHz-compatible monitor, it should have taken over the A8 world. Alas.

 

That said, I love where Michael is going with this and I am not ashamed to admit I want one, and ASAP, just because it's a ridiculously great idea. 

[Atari8guy]

Yes. Cool project. If it becomes available I’ll buy one.


Sent from my iPhone using Tapatalk

[Faicuai]

4 hours ago, jaybird3rd said:

The original XEP-80 used the NS405-A12N, but the NS405-B12N is much more readily available.

My current XEP80 has a Rev. D motherboard... only main processor, and seemingly RAM and ROM are socketed. Everything else, soldered in.

 

But what's interesting is that it came with a NS455-A12N (not 405), date +B8624... and for the life of me, I just can't find a datasheet for that damned 455 to understand the differences with 405...

[+x=usr(1536)]

4 hours ago, mytek said:

I use one of these that I got off eBay. Haven't tried this Amazon one yet, but I will.

Ah, cool.  Be interested to hear how that one works out for you; it's one that I haven't tried yet.

 

FWIW, the model I'm currently using is this:

 

RCA to HDMI, GANA 1080P Mini RCA Composite CVBS AV to HDMI Video Audio Converter Adapter Supporting PAL/NTSC with USB Charge Cable for PC Laptop Xbox PS4 PS3 TV STB VHS VCR Camera DVD

 

Pros: it converts composite to HDMI, so is at least doing the thing it's supposed to do.

 

Cons: neither it nor the TV like the XEP80's output, so vertical roll is taking place.  Works fine from the composite output on both the 800XL and 1200XL, though.  Having said that:

 

4 hours ago, mytek said:

The thing is none of these Chinese converters are necessarily great at dealing with the color video coming out of the Atari, but the XEP80's monochrome signal with phaeron's XEPVHOLD parameters applied is a simpler signal to deal with. I'll be trying a few more converters, but I suspect it'll be pretty consistent in this usage. BTW, I'm assuming you've applied the following file after loading the XEP80 driver?

 

I had no idea that that file existed; thanks for the heads-up. What's your recommendation for loading it?  I've been trying to load it semi-blind from DOS, but have got nowhere trying that.

[+Allan]

@mytek Does the joystick connector on the XEP-80 have all the necessary lines to run your XEP-80-II in a XEP-80 case? Or would you need to find new joystick cables to use this?

[BillC]

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

I had no idea that that file existed; thanks for the heads-up. What's your recommendation for loading it?  I've been trying to load it semi-blind from DOS, but have got nowhere trying that.

I don't think XEPVHOLD works with the stock DOS 2.5 or SpartaDOS drivers, it does work with the XEP drivers on the Altirra Additions disk.

[gozar]

This sounds like a cool project, 80 columns is what I've always wanted. However, wouldn't hooking a Pi Zero up to the joystick port and writing an XEP80 emulator for the Pi be a more powerful and flexible solution? Full color ANSI graphics for starters. All for <$10. 

 

[Mazzspeed]

So in relation to the HDMI daughter board, it that an assembled component, or an off the shelf device adapted for use with the modern XEP-80 recreation? If it's an off the shelf solution, will people have to buy one particular device in order for things to work optimally?

[+x=usr(1536)]

1 hour ago, BillC said:

I don't think XEPVHOLD works with the stock DOS 2.5 or SpartaDOS drivers, it does work with the XEP drivers on the Altirra Additions disk.

Good point.  I ditched my handmade boot disk and booted straight from the Altirra Additions disk with the vertical hold utilities included.  Both direct connection to the TV's composite input as well as HDMI via the converter are now working correctly.

 

FWIW, that HDMI converter introduces a ton of what I can only describe as squirm into the picture - it's almost like individual pixels are twinkling.  I'll fiddle with a bit more after I've had some sleep.

Edited June 25, 2021 by x=usr(1536)
Realised my mistake

[Mazzspeed]

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

Good point.  I ditched my handmade boot disk and booted straight from the Altirra Additions disk with the vertical hold utilities included.  Both direct connection to the TV's composite input as well as HDMI via the converter are now working correctly.

 

FWIW, that HDMI converter introduces a ton of what I can only describe as squirm into the picture - it's almost like individual pixels are twinkling.  I'll fiddle with a bit more after I've had some sleep.

Without rehashing another debacle of a thread, you cannot use a composite input expecting chroma and Luma, doing so will likely loose part of the Luma signal due to filtering within the scaler/convertor device itself. Assuming the device can handle sync on Luma via svideo, try connecting the Luma output of the XEP-80 to the Luma input of the Svideo connector.

 

Edited June 25, 2021 by Mazzspeed

[+mytek]

6 hours ago, Stephen said:

No - adding colour is not easy, there's no chance for a blitter.  If you want the untied cheeta, please buy a VBXE and help spread it rather than re-inventing a wheel and further segmenting a market with a few dozen people at best.

Yep Stephen's absolutely correct. If you want color in 80 columns (and who wouldn't) go for a VBXE. This is not what this project is about. It is about providing a very inexpensive hardware driven 80 column text display.

 

3 hours ago, x=usr(1536) said:

Cons: neither it nor the TV like the XEP80's output, so vertical roll is taking place.  Works fine from the composite output on both the 800XL and 1200XL, though.  Having said that:

 

I had no idea that that file existed; thanks for the heads-up. What's your recommendation for loading it?  I've been trying to load it semi-blind from DOS, but have got nowhere trying that.

Yes the XEPVHOLD program is specifically aimed at correcting that vertical roll problem, as well as fixing a few other issues. It gets loaded after the XEP80 driver is already in memory, so yes you'll probably be flying blind while you are doing that. just create a boot disk with a batch file that preloads both the driver and the VHOLD programs sequentially.

 

3 hours ago, Allan said:

@mytek Does the joystick connector on the XEP-80 have all the necessary lines to run your XEP-80-II in a XEP-80 case? Or would you need to find new joystick cables to use this?

No unfortunately it's missing 5 VDC, so a custom cable will need to be made.

 

2 hours ago, BillC said:

I don't think XEPVHOLD works with the stock DOS 2.5 or SpartaDOS drivers, it does work with the XEP drivers on the Altirra Additions disk.

It does work with the original driver on the XEP80 boot disk, and is DOS agnostic.

 

2 hours ago, gozar said:

This sounds like a cool project, 80 columns is what I've always wanted. However, wouldn't hooking a Pi Zero up to the joystick port and writing an XEP80 emulator for the Pi be a more powerful and flexible solution? Full color ANSI graphics for starters. All for <$10.

Sounds good. Let us know when you got that working   You can consider this a challenge, since I've heard this same thing talked about for a couple of years now. Not trying to say it wouldn't work, or that it isn't worthwhile, but I think we need someone to actually sit down and code it.

 

2 hours ago, Mazzspeed said:

So in relation to the HDMI daughter board, it that an assembled component, or an off the shelf device adapted for use with the modern XEP-80 recreation? If it's an off the shelf solution, will people have to buy one particular device in order for things to work optimally?

You should just check out my blog for the answer on that.

 

28 minutes ago, Mazzspeed said:

Without rehashing another debacle of a thread, you cannot use a composite input expecting chroma and Luma, doing so will likely loose part of the Luma signal due to filtering within the device itself. Assuming the device can handle sync on Luma via svideo, try connecting the Luma output of the XEP-80 to the Luma input of the Svideo connector.

Well if the device with the composite input is properly designed, and no colorburst is present, it will revert to B&W only operation with the same result as if you fed the signal into a luma input. This is also the case for a decent TV let alone a converter. It shouldn't confuse luma as chroma if there is no colorburst directly following HSYNC. The circuit is better known as the 'color killer' which is an apt description of it's function.

 

BTW, the XEP80 does put out a composite video signal (the composite designation doesn't necessarily mean its in color). However it is merely missing the colorburst (for color synchronization) and the chrominance signal (color information). What composite actually represents is a signal that combines luminance and sync information. It can also combine color information as well, but that isn't necessary in order to call it composite. Here'a good article going over the details: How Television Works

 

[Mazzspeed]

25 minutes ago, mytek said:

Yep Stephen's absolutely correct. If you want color in 80 columns (and who wouldn't) go for a VBXE. This is not what this project is about. It is about providing a very inexpensive hardware driven 80 column text display.

 

Yes the XEPVHOLD program is specifically aimed at correcting that vertical roll problem, as well as fixing a few other issues. It gets loaded after the XEP80 driver is already in memory, so yes you'll probably be flying blind while you are doing that. just create a boot disk with a batch file that preloads both the driver and the VHOLD programs sequentially.

 

No unfortunately it's missing 5 VDC, so a custom cable will need to be made.

 

It does work with the original driver on the XEP80 boot disk, and is DOS agnostic.

 

Sounds good. Let us know when you got that working   You can consider this a challenge, since I've heard this same thing talked about for a couple of years now. Not trying to say it wouldn't work, or that it isn't worthwhile, but I think we need someone to actually sit down and code it.

 

You should just check out my blog for the answer on that.

 

Well if the device with the composite input is properly designed, and no colorburst is present, it will revert to B&W only operation with the same result as if you fed the signal into a luma input. This is also the case for a decent TV let alone a converter. It shouldn't confuse luma as chroma if there is no colorburst directly following HSYNC. The circuit is better known as the 'color killer' which is an apt description of it's function.

 

BTW, the XEP80 does put out a composite video signal (the composite designation doesn't necessarily mean its in color). However it is merely missing the colorburst (for color synchronization) and the chrominance signal (color information). What composite actually represents is a signal that combines luminance and sync information. It can also combine color information as well, but that isn't necessary in order to call it composite. Here'a good article going over the details: How Television Works

 

Due to the way both chroma and Luma frequencies overlap and due to the fact that a composite output is designed to seperate these signals, there is usually (almost always) a loss of Luma signal in the process - I have yet to see a scaler, including expensive hometheater scalers, that disable such circuitry where a Luma only signal is detected.

 

If Luma is lost via composite in, which usually results in a loss of text intensity and possibly twinkling in the case of digital displays, and using a Luma only input resolves the issue - This will be why.

 

I never stated the XEP-80 outputs chroma, in fact I stated the polar opposite.

Edited June 25, 2021 by Mazzspeed

[+mytek]

23 minutes ago, Mazzspeed said:

I never stated the XEP-80 outputs chroma, in fact I stated the polar opposite.

Message received. But I wasn't implying that you had said that either. Instead I was merely pointing out that a color capable composite input would not try to interpret a monochrome only signal as having color information, since that source would be missing the colorburst which is key to it switching into color mode.

 

EDIT: BTW that info I provided at the end of my post was not directed specifically at you, but really meant as general information for other people reading these posts. Sorry if you thought otherwise

 

23 minutes ago, Mazzspeed said:

Due to the way both chroma and Luma frequencies overlap and due to the fact that a composite output is designed to seperate these signals, there is usually (almost always) a loss of Luma signal in the process - I have yet to see a scaler, including expensive hometheater scalers, that disable such circuitry where a Luma only signal is detected.

 

If Luma is lost via composite in, which usually results in a loss of text intensity and possibly twinkling in the case of digital displays, and using a Luma only input resolves the issue - This will be why.

Yes I can see this being a problem, and it might very well explain what x=usr(1536) was seeing as well.

[Mazzspeed]

1 hour ago, mytek said:

Message received. But I wasn't implying that you had said that either. Instead I was merely pointing out that a color capable composite input would not try to interpret a monochrome only signal as having color information, since that source would be missing the colorburst which is key to it switching into color mode.

 

EDIT: BTW that info I provided at the end of my post was not directed specifically at you, but really meant as general information for other people reading these posts. Sorry if you thought otherwise

 

Yes I can see this being a problem, and it might very well explain what x=usr(1536) was seeing as well.

All good my Friend. I'm very interested in this device.

[Faicuai]

11 hours ago, gozar said:

However, wouldn't hooking a Pi Zero up to the joystick port and writing an XEP80 emulator for the Pi be a more powerful and flexible solution? Full color ANSI graphics for starters. All for <$10. 

That's a pretty good idea.

 

NS405/455 emulation could be by-passed altogether and just write code to support E: handler functions (mixed with anything else) and running either joystick-port and/or as SIO device.

 

In the near future, who knows...

[+mytek]

2 hours ago, Faicuai said:

14 hours ago, gozar said:

However, wouldn't hooking a Pi Zero up to the joystick port and writing an XEP80 emulator for the Pi be a more powerful and flexible solution? Full color ANSI graphics for starters. All for <$10. 

That's a pretty good idea.

 

NS405/455 emulation could be by-passed altogether and just write code to support E: handler functions (mixed with anything else) and running either joystick-port and/or as SIO device.

 

In the near future, who knows...

Yes this would be a great project as well, and could really go places if someone with the knowledge to do so were to get behind it. However I would please ask that a new topic be started specific to this alternative for further discussion, so that this one can be allowed to document the progress and suggestions associated with this NS405 based derivative of the XEP80. BTW, my goal is to keep this project as close as possible to 100% compatibility with the original from a software/driver viewpoint, so as not to alienate any existing XEP80 applications with baked in XEP drivers.

 

Thank you

 

 

I missed this one when you first posted it.

15 hours ago, Faicuai said:

My current XEP80 has a Rev. D motherboard... only main processor, and seemingly RAM and ROM are socketed. Everything else, soldered in.

 

But what's interesting is that it came with a NS455-A12N (not 405), date +B8624... and for the life of me, I just can't find a datasheet for that damned 455 to understand the differences with 405...

 

That is a good question. And I found this which appears to answer it (although still no datasheet, but it must be very close to the NS405 anyway)...

Quote

The NS405 and NS455 Terminal Management Processor chips from National Semiconductor provide complete video terminal functionality, including a CPU which can use either internal or external ROM.

The NS455 has firmware in the internal ROM; an input pin allows selection of either this, or code in an external ROM. The NS405 is the same chip, but for use with external ROM only. (The internal ROM is still present, but the contents are unknown.)

 

And then I looked once more at the NS405 datasheet...

 

So apparently I was incorrect on an earlier statement I made saying that the 'A' variant was with internal ROM, and the 'B' variant was not. As indicated by that quote all variants, including the NS455, have an internal ROM, but only the NS455 was meant to allow for it to be presumably mask programmed at the factory, and selectable by the application.

 

[Faicuai]

19 minutes ago, mytek said:

all variants, including the NS455, have an internal ROM, but only the NS455 was meant to allow for it to be presumably mask programmed at the factory, and selectable by the application.

NICE finding, there (I could not locate myself, THANKS !)

 

Now it begs the question what would be in that XEP80 '455 on-board firmware space. if enabled? What would we find? Maybe someday...

 

Also, you were dead-on right about chroma-kill circuitry response and handling of luma in a composite-input. My 800XLs have an on-board chroma-separation switch (installed right at the juncture of Luma+Chroma add-stage). When I flip-it in Antic 80-cols emulation (for instance)  my video-processor goes from artifacts-garbled output to a crisp, balck-and-white, NO artifacts rendering, with no chroma processing anywhere (seen also in ACP, etc.) This explains also why there is very, very little difference between feeding the XEP80 output through composite or component, in my end.
 

Therefore, users out-there equipped with just a mere composite (RCA) input and XEPVHOLD utility should be able (in most cases) to enjoy their XEP80-II, without any complication. This will ease adoption of the new board, to essentially anyone interested.

 

Kudos!

[+mytek]

3 hours ago, Faicuai said:

Now it begs the question what would be in that XEP80 '455 on-board firmware space. if enabled? What would we find? Maybe someday...

Probably nothing of use with the Atari, since it either never got programmed, or if it did, it was probably for another customer application and Atari picked these up cheap from that customer as over stock (the Tramiel way). At any rate it would be doubtful that it would communicate at the same odd serial frequency that was used on the XEP.

 

3 hours ago, Faicuai said:

...users out-there equipped with just a mere composite (RCA) input and XEPVHOLD utility should be able (in most cases) to enjoy their XEP80-II, without any complication. This will ease adoption of the new board, to essentially anyone interested.

Yes that is my goal, to keep it backwards compatible. Even if I can get the same parameters as the VHOLD program baked into the firmware ROM it should still work for an older application, with the only caveat being no more vertical rolling or over scan on modern displays.

[Mathy]

Hello Michael

 

25 minutes ago, mytek said:

Even if I can get the same parameters as the VHOLD program baked into the firmware ROM it should still work for an older application, with the only caveat being no more vertical rolling or over scan on modern displays.

 

Would it be possible (for the user) to piggyback a second ROM on top of the modified ROM, so the user could switch between the old ROM and the patched ROM?

 

Sincerely

 

Mathy

 

[Mathy]

Hello Michael

 

20 hours ago, Allan said:

@mytek Does the joystick connector on the XEP-80 have all the necessary lines to run your XEP-80-II in a XEP-80 case? Or would you need to find new joystick cables to use this?

16 hours ago, mytek said:

No unfortunately it's missing 5 VDC, so a custom cable will need to be made.

 

Would it be possible to solder in a female DB9 port, so one could use a joystick extension cable?

 

Sincerely

 

Mathy

 

[Mazzspeed]

1 minute ago, Mathy said:

Hello Michael

 

 

Would it be possible to solder in a female DB9 port, so one could use a joystick extension cable?

 

Sincerely

 

Mathy

 

Wouldn't it be easier to just solder a hacked USB cable of the appropriate type to a DB9 connector?

[+DrVenkman]

Why not just get a crimped-on Dsub connector for the Atari side and some ribbon cable and then just solder the XEP80 side? Cables don't need to be difficult or complicated, especially something as simple and ubiquitous as the 9-pin type used by Atari, Commodore, Sega and others. 

[+mytek]

21 minutes ago, Mathy said:

Would it be possible to solder in a female DB9 port, so one could use a joystick extension cable?

Yes I've been kicking that around, and I agree that would be the easiest solution, thus allow one to buy an off the shelf cable instead of having to build a custom one.

 

19 minutes ago, Mazzspeed said:

Wouldn't it be easier to just solder a hacked USB cable of the appropriate type to a DB9 connector?

Mathy is referring to the communications cable that goes between the Joystick DB9 and the XEP. In the original XEP80 that was terminated to a 4-pin header similar to what I have shown on my board iteration.

 

BTW, you were absolutely correct about it being better to go through the Luma input on the S-Video connector instead of feeding through the composite connector on my converter. Before if I looked real close I could see a bit of squirmy-ness on some text, switching to the Luma only input on the S-Video completely fixed that. So just to be sure I put it up on my 55" HDTV and it looks absolutely flawless.

 

 

Thanks for the tip ?

 

Now it would be nice to get an adapter that breaks out the S-Video to two RCA plugs, preferable very short in length (I was using a cut S-Video cable for my test).