XEP80-II a new beginning

[+Nezgar]

Thanks for the explanation and satisfying my curiosity @mytek. ?

[+mytek]

Ready to Send Out PCB for Manufacture

 

I made some final tweaks and tested most everything that I could without a new board to assemble. I did see some strangeness with integration of the new timing parameters in the ROM, but that'll hopefully get worked out on the actual board. Looks to be more of a software issue than a hardware one, so I feel it's time to commit on the PCB design. I'll be sending out a small sample order later today, and should see boards arriving next week.

Schematics: XEP80-II_schema_7-22-2021.pdf

 

Before and after comparison of power draw: Stock XEP80 = 430 ma, XEP80-II = 210 ma (5 VDC Side).

 

That looks within acceptability for the Atari 1 AMP PSU on a stock un-modified machine without any 3rd party upgrades attached. I know I've seen it said that the joystick port is only rated for 50 ma, but that has nothing to do with the capability of the joystick port itself (there is no current limiter, the traces and a possible inline inductor should handle at least 1/2 amp without issues). So we're really looking at total power draw from the PSU itself as being the limiting factor. On a stock 130XE with my board attached, you'll see 0.9 amps being drawn on the 5 VDC side. Since a LM7805 regulator that was often used in the Atari PSU can handle up to 1.5 amps, the limitation is in the heat sink and the transformer feeding it. On the small 1 amp rated Atari PSUs, I wouldn't push it too much above what the label says. However Atari did make some bigger PSUs with a rating of 1.5 amps on the sticker. These would be the ones I would recommend using with an XEP80-II connected.

 

 

[+MrFish]

Of these common power supplies, only two are 1 amp (the little one, and the ribbed one on the lower-right -- which I think are generally for 65XE and XEGS respectively); the rest are all 1.5 amps. Well, forget about the one with the big red circle.

 

 

 

Edited July 22, 2021 by MrFish

[massiverobot]

54 minutes ago, MrFish said:

Of these common power supplies, only two are 1 amp (the little one, and the ribbed one on the lower-right -- which I think are generally for 65XE and XEGS respectively); the rest are all 1.5 amps. Well, forget about the one with the big red circle.

 

 

 

i always wanted an XL style PSU but never found one. So pretty.

 

[+MrFish]

17 minutes ago, massiverobot said:

So pretty.

Pretty massive. I prefer the one in the upper-right -- for being a little more compact.

 

I had a black (800XL) one before, which I ended up selling with the machine.

 

Now, I just have a Creative (of Sound Blaster fame) 2.4 amp (non-wallwart type) switching. It's compact (though more substantial than a lot of the more modern ones) and dependable.

 

Edited July 22, 2021 by MrFish

[Faicuai]

14 hours ago, MrFish said:

I prefer the one in the upper-right -- for being a little more compact.

Way to go, quite reliable and field-serviceable, too (IIRC, will re-look at the bottom plates of mine).

 

14 hours ago, MrFish said:

2.4 amp (non-wallwart type) switching.

 

This one sounds good, too. Have you checked for any patterned noise-ingress with a poke 710,2 and poke 710,4 gray-fields?

 

Anything shows up there, instantly...

[+MrFish]

On 7/23/2021 at 8:07 AM, Faicuai said:

Way to go, quite reliable and field-serviceable, too (IIRC, will re-look at the bottom plates of mine).

Yeah, I've never had any trouble with these. Typically come with 130XE's.

 

On 7/23/2021 at 8:07 AM, Faicuai said:

This one sounds good, too. Have you checked for any patterned noise-ingress with a poke 710,2 and poke 710,4 gray-fields?

 

Anything shows up there, instantly...

I don't have any machine set up right now.

 

What am I supposed to see or not see with the above color changes, video patterning/noise?

 

[Faicuai]

20 hours ago, MrFish said:

What am I supposed to see

You should easily see / detect the presence of ANY type of ingress-noise, either random "speckled", or structured (vertically, horizontally or diagonally aligned). They would appear barely above these two luma-levels (generally). There are some specific color-fields which are also ideal to exposing them, as well... but for the most part, these two gray levels should help.

 

The latter are very, very common from switched power-supplies. This will be hidden, for the most part, if examining through Sophia's DVI-D output. But when inspected on stock RF, Composite or S-video (which should all be operative), you may find noise-ingress there.

[+mytek]

So to get this back on topic, I tested my first assembled XEP80-II PCB today, and it worked out of the box ?

 

Blog Post

 

I'm still missing a few parts related to the HDMI output, so I'll get much more into this when that stuff arrives.

 

[Bee]

That is mighty sweet.  Great work!  I'm interested if you want or need more testers when the time comes.

 

Thank you

[+Larry]

What is the resolution of the XEP80?  I want to say 640 X 280?

[+mytek]

On 8/8/2021 at 5:12 AM, Larry said:

What is the resolution of the XEP80?  I want to say 640 X 280?

I'm thinking it's actual display was 560x250 based on the original 80X25 characters (character cell = 7x10 pixels), but with over scan you are probably correct. However this gets reduced in my variation via new screen parameters being used in the ROM.

 

Here's a video I made a few minutes ago that shows the new prototype XEP80-II being run through a couple of tests (modified NTSC parameters in play).

 

 

You'll see this new board doing some automatic switching between the 40 to 80 column screen, and then back again. And there is always the option of manually toggling between video sources via a momentary push of a button switch on the front side.

 

Since only 2 of the available 4 I/O bits on the joystick port were needed to communicate with the 80 column display processor, I used the two left over bits to convey what video mode the board is in, and to provide a means for toggling the source video. The assembly source code that I display in AtariWriter, is what is responsible for interrogating the port, and if in 40 column mode, automatically switching it to 80 column instead. This routine is run as a pre-driver prior to AtariWriter being loaded. So if you watch carefully, you'll see very soon after initiating the load process the video changes from the 40 column screen, over to the 80 column one.

 

Whenever the board is power cycled, it'll default to 40 column video output.

 

All video and audio is being piped through an AV-to-HDMI converter daughter board, and looks quite nice, with only one display serving both needs. My monitor also had a USB port, which I used to power the converter separate from the 80 column board (which gets it power from the joystick port). So the only power adapter required is the one powering the computer.

 

[Mazzspeed]

So this device has the ability to auto switch between 40 and 80 columns depending on source used?

 

Did the original XEP do that?

[cathrynm]

4 hours ago, Mazzspeed said:

So this device has the ability to auto switch between 40 and 80 columns depending on source used?

 

Did the original XEP do that?

Nope.  XEP has a seaparate connector on the back, hooks to an 80 column screen only.

This looks like a nice feature. Fussing with two monitors or switching monitors just for XEP80 is awkward.

[+mytek]

5 hours ago, Mazzspeed said:

So this device has the ability to auto switch between 40 and 80 columns depending on source used?

The 'automatic' aspect does require the use of a small 31 byte 'toggle' program which I added to the AtariWriter 80 ATR after modifying the DOS to allow for multiple AUTORUN.SYS files to be executed.

 

39 minutes ago, cathrynm said:

Nope.  XEP has a seaparate connector on the back, hooks to an 80 column screen only.

Yep this is definitely a new twist on this XEP80 remake. However just to be clear, this feature relies on utilizing the optional AV-to-HDMI converter, and is not something that would work via a composite or S-Video output. And although it will still be possible to plug in a composite monitor as was done in the day, doing so relinquishes the HDMI output and video source switching capability (it becomes more or less like the original XEP80). So in other words, the switching between the standard Atari video and the 80 column video only applies to what is sent to the onboard HDMI converter.

 

By utilizing the AV-to-HDMI converter, it gives an easy path to modern monitor usage on our Atari computers. And it also solves the issue of audio integration vs DVI. Now with that said, it will not match the quality of the DVI output of the Sophia2, or the RGB output of the earlier Sophia and VBXE. And although it looks pretty darn good when the S-Video source is of a high quality (e.g., UAV), it does have its quirks, with certain color combinations revealing those quirks. However for the most part it will render a perfectly acceptable and clean image.

 

On the 80 column side, it really shines via the HDMI output, and is only limited by the quality of the HDTV being used (the one in the demo video was purchased on sale from Target for $99, but still does a fair job).

 

[+Nezgar]

17 hours ago, mytek said:

Since only 2 of the available 4 I/O bits on the joystick port were needed to communicate with the 80 column display processor, I used the two left over bits to convey what video mode the board is in, and to provide a means for toggling the source video.

Very cool, thanks for the video -- I love the two input/one output switcher model. Does this function also work for CVBS without the AV-to-HDMI converter? There's also a button to toggle it manually right? (Sorry if these questions have already been asked/answered...)

 

7 hours ago, mytek said:

The 'automatic' aspect does require the use of a small 31 byte 'toggle' program which I added to the AtariWriter 80 ATR after modifying the DOS to allow for multiple AUTORUN.SYS files to be executed.

Instead of modifying the DOS, could you have just chained/appended the existing AtariWriter executable to the toggle program for a single AUTORUN.SYS?

 

As someone not familiar with XEP operation since I've never used one before, is the speed that AtariWriter fills text to the XEP80 in your video using the slower speed of Atari's original, or Avery's faster driver?

[+mytek]

2 hours ago, Nezgar said:

Very cool, thanks for the video -- I love the two input/one output switcher model. Does this function also work for CVBS without the AV-to-HDMI converter? There's also a button to toggle it manually right?

All video switching is conducted 'thru' the AV-to-HDMI converter only. So it will take either a CVBS or S-Video signal from the Atari via the external signal jacks (only using one or the other, not both), and switch between this and the 80 column XEP output, feeding the result into the AV-to-HDMI converter inputs along with the audio. So this is only going to be an HDMI thing. I posted a schematic HERE.

 

5 hours ago, Nezgar said:

Instead of modifying the DOS, could you have just chained/appended the existing AtariWriter executable to the toggle program for a single AUTORUN.SYS?

I suppose so, but silly me has never appended files before - how is that done?

 

5 hours ago, Nezgar said:

As someone not familiar with XEP operation since I've never used one before, is the speed that AtariWriter fills text to the XEP80 in your video using the slower speed of Atari's original, or Avery's faster driver?

Unfortunately as far as I know, there is no simple way to replace the built-in XEP driver with Avery's alternative drivers. If someone knows how this can be accomplished, I'm all ears.

 

[+Nezgar]

21 minutes ago, mytek said:

All video switching is conducted 'thru' the AV-to-HDMI converter only.

Fair enough, thanks for summarizing for me.

 

21 minutes ago, mytek said:

silly me has never appended files before - how is that done?

In windows/msdos: (2 files combined to a new 3rd file)

copy /b file1.bin + file2.bin outfile.bin

In Atari DOS 2.5: (appends file1.bin to existing outfile.bin, so good to make a copy first)

C
D:FILE1.BIN,D:OUTFILE.BIN/A

SpartaDOS:

COPY D:FILE1.BIN D:OUTFILE.BIN/A

This "hack" results in the standard 2-byte "FFFF" header for executable showing up mid-file, which is supported, but utilities like StreamLiner can remove them extra bytes. Or use a hex editor of your choice to do it. There might be some other quirks like making sure the first segment has an init address not just run, etc...

21 minutes ago, mytek said:

Unfortunately as far as I know, there is no simple way to replace the built-in XEP driver with Avery's alternative drivers. If someone knows how this can be accomplished, I'm all ears

Yeah there's another thread recently about potential to replace the AW XEP driver - I had just never seen it in live operation... It looked faster than I expected from the stories, so Avery's driver must really fly!

[+bob1200xl]

Looking good Tuesday night, Michael!

 

Bob

 

 

[+mytek]

19 hours ago, Nezgar said:

Yeah there's another thread recently about potential to replace the AW XEP driver - I had just never seen it in live operation... It looked faster than I expected from the stories, so Avery's driver must really fly!

It actually works pretty good with the AtariWriter 80 built-in XEP driver, especially now that I have new screen parameters loaded via a modified XEP ROM. I was also running Avery's standard ALTXEP80.SYS driver today while in the Assembler/Editor Cart, and didn't notice any speed problems with that what-so-ever. When listing a program, it sped by pretty darn quick. However I do see some flakiness whenever I try to use the faster ALTXEP8U.SYS driver instead.

 

During my testing today, I did notice something that DOS 2.5's DUP.SYS program does, and that is to alter the margin settings, so that when you return to your program it's now got a right margin setting of 38 instead of 79 like it was before. I took a look at the DUP.SYS file in Omnivore, and saw no less than 4 places where the right margin setting gets messed with. Be nice to automatically fix that when returning to the cart, so that it's back to 79 again.

 

BTW, thanks for all the good info on appending files ?

 

1 hour ago, bob1200xl said:

Looking good Tuesday night, Michael!

Thank you Bob

 

Yeah it's getting very interesting as this project progresses, but it never would have begun without you providing a couple of the original XEP80s to experiment with.

 

[phaeron]

4 hours ago, mytek said:

It actually works pretty good with the AtariWriter 80 built-in XEP driver, especially now that I have new screen parameters loaded via a modified XEP ROM. I was also running Avery's standard ALTXEP80.SYS driver today while in the Assembler/Editor Cart, and didn't notice any speed problems with that what-so-ever. When listing a program, it sped by pretty darn quick. However I do see some flakiness whenever I try to use the faster ALTXEP8U.SYS driver instead.

The ultra-speed driver is a bit of a hack since the rise time of the joystick output signal is poor at 31.5Kbaud rate -- V0.7+ of the driver applies precompensation to 1 bits to get the signal level above threshold in time with varying models of PIA. One thing I notice in the schematics is that you have a 47K pullup on the RxD line that the original XEP80 doesn't have. That should only make it more reliable, but you may want to check the signal on the computer input if you're concerned about this case.

 

[+mytek]

2 hours ago, phaeron said:

The ultra-speed driver is a bit of a hack since the rise time of the joystick output signal is poor at 31.5Kbaud rate -- V0.7+ of the driver applies precompensation to 1 bits to get the signal level above threshold in time with varying models of PIA.

Yeah I kinda figured it was pushing the hardware a bit in order to accomplish what it was doing. Probably with just the exact right combination of hardware it works well, but have something less than exact and you're likely looking for trouble. Your standard driver works good enough as is, and really isn't all that much slower than the ultra-speed one from a practical usage standpoint. Sure you can get a program listing to zoom past quite a bit faster, but that really isn't necessarily a desirable thing. And bottom line this is really aimed at text display, not graphics (something the standard Atari video output does far better).

 

2 hours ago, phaeron said:

One thing I notice in the schematics is that you have a 47K pullup on the RxD line that the original XEP80 doesn't have. That should only make it more reliable, but you may want to check the signal on the computer input if you're concerned about this case.

Actually all 3 of the original XEP80's I got from Bob Woolley had this resistor. However Sobola's schematic did not. I will check without the pull-up to see if that makes any difference.

 

-----

Overall I'm seeing good results using either your standard drivers, or the one built-in to AtariWriter 80. I just wish that TurboWord 80 would work with Altirra Basic to round out the selection of XEP80 compatible word processors. Also be nice to modify the XEP Character ROM to somewhat restore the chopped off descenders in NTSC with the new display timing parameters. I figure just moving the very bottom pixels of the descender up 1 pixel in height would likely do it, and yet still look decent. However I'm not about to manually fix all the descenders in the 8Kbit ROM - need some kind of program to do this instead.

 

[nebpehtira]

On 8/11/2021 at 4:50 PM, mytek said:

The 'automatic' aspect does require the use of a small 31 byte 'toggle' program which I added to the AtariWriter 80 ATR after modifying the DOS to allow for multiple AUTORUN.SYS files to be executed.

 

Yep this is definitely a new twist on this XEP80 remake. However just to be clear, this feature relies on utilizing the optional AV-to-HDMI converter, and is not something that would work via a composite or S-Video output. And although it will still be possible to plug in a composite monitor as was done in the day, doing so relinquishes the HDMI output and video source switching capability (it becomes more or less like the original XEP80). So in other words, the switching between the standard Atari video and the 80 column video only applies to what is sent to the onboard HDMI converter.

 

By utilizing the AV-to-HDMI converter, it gives an easy path to modern monitor usage on our Atari computers. And it also solves the issue of audio integration vs DVI. Now with that said, it will not match the quality of the DVI output of the Sophia2, or the RGB output of the earlier Sophia and VBXE. And although it looks pretty darn good when the S-Video source is of a high quality (e.g., UAV), it does have its quirks, with certain color combinations revealing those quirks. However for the most part it will render a perfectly acceptable and clean image.

 

On the 80 column side, it really shines via the HDMI output, and is only limited by the quality of the HDTV being used (the one in the demo video was purchased on sale from Target for $99, but still does a fair job).

 

Sweet! I was looking at my desk and thinking "yay, 80 columns!" and at the same time "Oh f***, two screens"

[+mytek]

Making progress on getting the descenders working in NTSC without over scan issues.

 

Captured screen with digital camera from my 55" LG HDTV - Looks even better in reality.

 

Enabled full 10 pixel height of character cell, which at 24 lines = 240 pixels tall. That's really the absolute max limit, so it requires setting the aspect ratio to "Just Scan" in the TV (the 4:3 aspect ratio is being handled by the AV-to-HDMI converter instead). My small Element HDTV also has a similar setting in it's setup menu.

 

 

 

Here's the XEP80 default 60Hz NTSC and the modified ROM parameters.

 

 

The modified parameters are a mish-mosh of @phaeron,s VHOLD and the defaults, with a twist I threw in for TCP7 which allows the first row to start sooner, thus enabling all 24 rows to fit on screen with the full height character cells. Might not fly if feeding composite directly, but it sure works well via the HDMI output.

 

Got the idea from the NS405 data sheet...

Quote

TCP7  Vertical Sync Begin Register - VSBR 4 bits
High Nibble
Scan line position in first blank row at which vertical sync begins (falling edge). Sync starts 1 . char time after
blanking for that line starts (except when VSBR = CSHR sync will start 1 char time after blanking of the last
displayed scan line).

CSHR = the high nibble of the Character Scan Height Register (TCP4) which in our case has a value of '9'.

 

EDIT: Just saw that the descenders were being chopped off on the 24th line, so altered TCP4 to be 99 instead of 91. This eliminates an extra scan line, and thus allows just enough room to show the decenders on every single line.

 

Edited August 14, 2021 by mytek
Added note

[Gunstar]

On 7/22/2021 at 4:06 PM, massiverobot said:

i always wanted an XL style PSU but never found one. So pretty.

 

Me too, I'd prefer the XL off-white colored one, but I'd take the black one too and just paint it to match the XL off-white. But I have a 1200XL that still uses the "Universal" PSU that works with the 800,810,1050 and more, with the barrel plug. I'd first have to do the direct +5V modification that gets rid of the entire circuit with rectifier and regulators and heat sink. Then I'd either have to replace the barrel power jack on the 1200XL with the 5-DIN style, or cut off the 5-DIN to the PSU and splice in the barrel connector. The latter being the easiest.

 

But same as you, I can't find them anywhere. The silver lining is that all my "Universal" PSU's are the 9V 31VA (3.4 amps!) so they are a lot better for me considering all the upgrades and power-draining attachments I have with my 1200XL 800 and 1050 drives. And these PSU's never seem to break/burnout. I've had them all for decades and I only occasionally have to replace the fuse inside of them which is usually caused by me. But now I have another silver lining in that I have a 3D printer, so I could print an XL style case and move my Universal PSU's that I use with my XL system into them.?