1088XEL Alternative Mother-Board Project

[+mytek]

 

Including all the Phi-related instability issues?

 

Probably not. But I'll know for sure when I get it powered up. Using HCT parts for all of the logic gates should minimize some of the delay issues while not exacerbating the ringing that really high-speed logic can create. Combine this with a much better power situation due in large part to the 4-layer board, and we should see some very clean logic signals as a result. Will that be enough? Time will tell

 

- Michael

[+MrFish]

Probably not. But I'll know for sure when I get it powered up. Using HCT parts for all of the logic gates should minimize some of the delay issues while not exacerbating the ringing that really high-speed logic can create. Combine this with a much better power situation due in large part to the 4-layer board, and we should see some very clean logic signals as a result. Will that be enough? Time will tell

 

I'm half joking, of course. I know you did give the issues thought and had some input.

 

It'll be interesting though, as we all know how people like the push the limits.

[+ZuluGula]

Michael, have you thought or asked Bryan about using his UAV circuit in your board? Not as ad on, but integrated part.

[+DjayBee]

Maybe I missed it, but is our only option for a keyboard just a ps/2 one?

 

Would be kinda nice to use a more Atari like one.

 

If you want it really hardcore then go for this¹⁾:

 

http://blog.tynemouthsoftware.co.uk/2017/03/atari-400-usb-keyboards.html

 

*ducks* and *runs*

 

 

¹⁾ Link taken from Episode 41 of ANTIC podcast

[+mytek]

Michael, have you thought or asked Bryan about using his UAV circuit in your board? Not as ad on, but integrated part.

 

Bryan and I have talked about collaborating on stuff, but I never considered integrating his UAV circuit directly because there would be no real savings in space, especially since my goal was to do this as an all through-hole design. And to be quite honest saving a few dollars by including this, just didn't seem like a big deal to me at the time. Plus it would only feel right to me if Bryan got some sort of kickback from the inclusion, so factoring this in, the savings would be minimal.

 

 

If you want it really hardcore then go for this¹⁾:

 

http://blog.tynemouthsoftware.co.uk/2017/03/atari-400-usb-keyboards.html

 

*ducks* and *runs*

 

 

¹⁾ Link taken from Episode 41 of ANTIC podcast

 

Wow all that work to have the 400 membrane keyboard as a USB device Doesn't seem worth it to me, but then it does have a certain coolness factor all its own.

 

- Michael

Edited April 6, 2017 by mytekcontrols

[jvas]

[Van]

msg-7778-0-53500000-1453592287.jpg

hummm... is that a key sticker set or a very (Atari) stylish KB. Like it!

Yogi

[jvas]

hummm... is that a key sticker set or a very (Atari) stylish KB. Like it!

Yogi

Stickers

[+mytek]

Aww ok... I'm glad that Yogi asked that question Because I was searching for some more detail on where that came from and the CKS (Comfort Keyboard Systems) aspect kinda threw me. For being stickers it really looks nice! Must have taken extreme patience to get them all perfectly aligned

 

I still plan on biting the bullet at some point and ordering a custom Cherry key switch keyboard from WASD Keyboards with the Atari key mapping. But it'll end up being the most pricey single Atari related item I've ever purchased (at least in this century).

 

- Michael

[+mytek]

The XEL has lifted off !!!

 

 

 

 

 

I know I promised a video on the first power up, but due to my own ineptitude in the moment, I accidentally installed the CPU in backwards, as in flipped around 180 degrees. So when I did a quick power-up and didn't see anything happening I kinda freaked out, and then failed to even setup or start a recording. Sorry

 

Anyway miracles upon miracles, when I flipped the CPU around the right way and tried again I was greeted with FJC's U1MB loading screen (Yipee!!!). I then went on to test a few things, and so far stuff for the most part appear to be working. However I am seeing some strange behavior concerning the RAM test which looks fine in the above shot, but that's because I was running a 1200XL OS at the time. When I try it with either a standard XL or XE OS I only get 20 squares (20K) appearing before the test repeats.

 

This is as far as the memory test goes when using a standard XL or XE OS.

 

 

And of course enabling SDX doesn't fair too well, with the system locking up not to far into the boot-up sequence, although it does make it through the credits. This happens no matter what the memory is set to. However the SIDE2 SDX will come up if I leave the memory set to stock. But it looks like this if I set to something other than stock...

 

 

When doing a ?FRE(0) in Basic (with no SDX or SIDE2) I only see 17422.

 

Very odd indeed, but maybe something that rings a bell for someone. I do find it interesting that the memory check works fine only with the 1200XL OS.

 

But this is actually pretty good considering it's the first test of real hardware on a newly designed motherboard. And I can load games in from various sources UnoCart, SIDE2, and yes even the SIO2PC-USB works fine (assuming the ATR's contain a DOS), and they play just fine. I was also amazed that the CPU could be powered up in a backwards orientation and survive (and yes I did swap it out for another chip just to be sure that wasn't the cause of my memory problem).

 

Anyway I've got some troubleshooting to do, and I am open to suggestions about possible causes for what I am seeing.

 

BTW, I never see any red squares in the memory test, it just acts like all is fine except for the apparent lack of memory when utilizing the stock XL or XE OS

 

- Michael

 

EDIT: I just popped in a Basix XL Cart and brought the system up as 1200XL, did a ?FRE(0) and got 37902. But when setting the OS to a stock XL, I once again only see 17422.

Edited April 6, 2017 by mytekcontrols

[Awch]

This is fantastic! Congratulations!!

[foft]

Incredible. I'm sure the memory fix will be, relatively speaking, trivial.

[Kyle22]

Have you tried an OS such as OmniMon that doesn't have PBI code?

[+DrVenkman]

Have you tried an OS such as OmniMon that doesn't have PBI code?

 

Or OSb padded up to 16K?

[+mytek]

Have you tried an OS such as OmniMon that doesn't have PBI code?

 

No haven't yet, but I did transfer the U1MB board I was using temporarily into my XEGS and everything works fine in that system.

 

 

Or OSb padded up to 16K?

 

So are both you and Kyle thinking that the PBI aspect is somehow causing the problem? Because the 1200XL OS does allow the RAM test to work completely, and it doesn't have PBI code built-in?

 

- Michael

[+DrVenkman]

Can't speak for Kyle, but I'm just spitballing ideas ... my usual first ham-fisted attempt to troubleshoot starts with ranging shots across all sorts of possibilities, noting what works and what doesn't, then narrowing down common and disparate elements between the tests.

[+mytek]

Can't speak for Kyle, but I'm just spitballing ideas ... my usual first ham-fisted attempt to troubleshoot starts with ranging shots across all sorts of possibilities, noting what works and what doesn't, then narrowing down common and disparate elements between the tests.

 

Yeah I've been studying my schematics for the last few hours and taking continuity readings on the U1MB interface connections, and other than leaving something in from my earlier XEGS version schematics where instead of pin 14 of the MMU = /MPD instead it's called out as /RSEL which is routed to A13 on the OS ROM. I had meant to leave this out and just have the OS ROM A13 pin go to A13 on the address bus. But its really a mute point since nothing on the U1MB is actually connected to the OS ROM A13 pin. The U1MB picks up the A13 signal from the MMU connection side of things instead.

 

So in other words I haven't found anything in hardware yet that would explain the memory problem. I did run another test on my XEGS using the same U1MB board under a 1200XL OS, SDX enabled, and the full 1088KB of RAM with no ill effects. However as I stated earlier, this combination (or anything other than the stock RAM) will cause the screen corruption and subsequent lock up. I guess I could try another OS, but I fail to see what that will do, since this definitely feels more like a hardware issue.

 

Have to do some more head scratching, but thanks for the suggestion.

 

- Michael

[Kyle22]

The 1200XL OS stood out in my mind right away because of the lack of PBI code. That lead me to wonder if there is some hardware issue that only shows up when the PBI area of RAM is accessed.

 

Just a thought.

[TangentAudio]

Very exciting! That's great progress for a first (OK, second) boot of a new board!

 

My instinct with the symptoms you describe is something related to a chip select being slightly wrong.

[+mytek]

The 1200XL OS stood out in my mind right away because of the lack of PBI code. That lead me to wonder if there is some hardware issue that only shows up when the PBI area of RAM is accessed.

 

Just a thought.

 

Oh I definitely appreciate your train of thought, and it's also what I was thinking as well. I also noticed that on the original Atari boards they had 3.3K pull-ups on all of the PB lines associated with banking, which my board didn't. So I tacked on some pull-ups and re-tested. Sadly no change . So I'm left wondering what is it that I'm not seeing

 

 

Very exciting! That's great progress for a first (OK, second) boot of a new board!

 

My instinct with the symptoms you describe is something related to a chip select being slightly wrong.

 

Yeah it was exciting a few hours ago, but now not so much. I'll feel much better, and once again be excited if I can get this all working.

 

 

So here's a bit more of what I have done in the testing aspect...

 

U1MB Settings

OS: 1200XL

RAM: 1088KB RAMBO

SDX: Disabled

 

Loaded MacGyver Test ATR through SIO2PC

 

Good sign -- RamDisk being setup

 

 

System specs as reported by test program

 

 

This program does not see all of the extended memory, but what it does see matches my U1MB XEGS system.

 

But if I go into setup and enable SDX with the extended memory still enabled the system will lock up. However it doesn't garble the display like when I'm in either a stock Xl or XE OS. If I put the memory back to stock, then SDX boots all the way up and is operational. BTW I am using the reduced footprint version of SDX that is meant to work with GOS on board (also same as what I have on U1MB XEGS system). So only 1200XL OS and stock memory will allow SDX to work ok.

 

- Michael

Edited April 7, 2017 by mytekcontrols

[Kyle22]

Logic in the area of the MMU related signals? $Dxxx? There must be something going on...

 

Just grasping at straws here.

 

[Van]

First, great to see signs of life!

By symptoms, it seems like bus contention. So given that the U1MB is operating correctly in your other system, I checked this MMU pinout https://www.atarimax.com/jindroush.atari.org/achmmu.html;from your MMU header pin 15 is routed to PIA Port B6, pin 16, where as it's listed as an output to BASIC ROM CS. I think the U1MB ignores the mobo Basic ROM (?) but having 2 outputs tied together isn't good, or it could be a typo on that page. Just a thought, will continue looking...

Yogi

EDIT: just confirmed the MMU connections to PIA- PB0, PB1 and PB7, all have pullups. PB6 is left unconnected.

Edited April 7, 2017 by Van

[phaeron]

FRE(0) returning 17422 instead of 37902 is a difference of 20480 bytes, which means that the OS is only seeing memory up to $5000 instead of $A000. This suggests that the issue is related to the self-test ROM mapping.

 

The pull-ups on the port B lines are needed, or else anything that sets an OS-B like PIA configuration could see weird behavior. That having been said, I thought Ultimate1MB shadows accesses to PIA port B rather than using the actual PIA outputs.

[JoSch]

Out of curiosity: The U1MB, you use has straight headers. Did you get it like this, or did you change that.

I have the more recent version with the right angled headers, that go sideways.

Do you think, that some short cable from headers to motherboard will do?

[+mytek]

First, great to see signs of life!

By symptoms, it seems like bus contention. So given that the U1MB is operating correctly in your other system, I checked this MMU pinout https://www.atarimax.com/jindroush.atari.org/achmmu.html;from your MMU header pin 15 is routed to PIA Port B6, pin 16, where as it's listed as an output to BASIC ROM CS. I think the U1MB ignores the mobo Basic ROM (?) but having 2 outputs tied together isn't good, or it could be a typo on that page. Just a thought, will continue looking...

Yogi

EDIT: just confirmed the MMU connections to PIA- PB0, PB1 and PB7, all have pullups. PB6 is left unconnected.

 

Yogi I did try adding 3.3K pull-ups on all the PB lines that were mapped to the MMU, but that didn't make any difference (probably for the reason that phaeron mentions below).

 

Here is the present mapping of the U1MB in the XEL with the exception I mentioned earlier about the OSROM A13 line (the inner numbers are referring to the ribbon headers, and the outer to where they would have gone on the original IC's). I should also mention that this is an inverse view of the U1MB headers since the board gets mounted upside down in the XEL, which provides easy access to the battery.

 

 

Several of these signals are not used by the U1MB, but I felt it important to still provide them for the option of substituting an entirely different board in place of the U1MB.

 

 

 

FRE(0) returning 17422 instead of 37902 is a difference of 20480 bytes, which means that the OS is only seeing memory up to $5000 instead of $A000. This suggests that the issue is related to the self-test ROM mapping.

 

The pull-ups on the port B lines are needed, or else anything that sets an OS-B like PIA configuration could see weird behavior. That having been said, I thought Ultimate1MB shadows accesses to PIA port B rather than using the actual PIA outputs.

 

When you say "... the issue is related to the self-test ROM mapping", any ideas on what could cause this to be in error?

 

 

Out of curiosity: The U1MB, you use has straight headers. Did you get it like this, or did you change that.

I have the more recent version with the right angled headers, that go sideways.

Do you think, that some short cable from headers to motherboard will do?

 

I had to change it myself, although it is my understanding that at one time, possibly back when Candle made an early run, they would have been vertical as well. Anyway there is an ongoing discussion with Lotharek about the possibility of being able to purchase the U1MB in this configuration so that no modification will be necessary. Yes you could use short cables and use male headers on the XEL side, but a much nicer and neater solution is obtained by having the vertical male headers on the U1MB.

 

- Michael

Edited April 7, 2017 by mytekcontrols