Jump to content
mytek

1088XEL Alternative Mother-Board Project

Recommended Posts

It's just a guess and depends on what the U1MB is doing with it. I don't know how the U1MB handles the mobo Basic ROM. Always de-selected? Which begs the question, for me at least, IS the mobo Basic needed? I know U1MB has a flash slot for Basic but IF it will use the Mobo ROM also (as default?).

 

As a side note, My original U1MB has the PB0, 1 and 7 pins ( MMU pins 6, 9, 18, all the PB port pins) removed from the box header ( Header pins removed: 5, 12, 18), which is not the case on the new version (?). Also a couple adjacent pins are connected to the empty donuts to aid routing ( header pin footprints shorted together 3-5, 17-18). The on board PIA outputs may be interacting with S5 (MMU pin 9) and S4 (MMU pin19). So for a original version U1MB, will have to bend the PIA PB pins so they do not go into the socket. This may be a quick test to see if this effects the memory issue, yes? I can try to get some close-up pixs if you like.

 

The only other things I have seen that caught my interest is the SRAM CE logic, as its handled different from the XL circuit or at least a SRAM mod I've seen. In that application /CASINH was driving into CE, the Hi cycle, CASINH, enabling RAM, but of course /EXTSEL was handled else where on the mobo. Your design logic should work but with a gate delay of ~10nS, no big deal. I'm not real clear on the XL handling of /CASINH but I think it is gated on and off depending on I/O, Cart or ROM accesses. Which would fit with the symptoms so it's suspect, but can't see how unless it was being pulled high ALL the time, some where, with the SRAM enabled on all buss cycles.

 

The other 'issue' is with PH2; the 'conventional wisdom' has been to gate it with R/W and /(R/W) into /OE and /WE, the theory being that CE is slower then /OE. This would require another NAND gate and I would expect that IF there was an issue with PH2 you wouldn't be able to access ANY ram.

 

Yogi

 

I'm pretty sure the gating of the SRAM is ok since it works perfectly under a 1200XL OS. Although my way of doing it differs from others, some of this was done as you saw to allow also adding in the /EXTSEL signal as well, and to utilize the gates that I had available without needing to add yet another IC. I've also seen this exact same method used in other 6502 designs, including directly tying PH2 into one of the chip selects as I've done. But I won't rule anything out for the time being ;)

 

 

damn Soboloa Schematics strike again

 

Yep I should have known better, and should have really scoped out the situation better. Kind of surprised no one else noticed either, especially the AA people that have designed memory enhancements in the past. Live and learn :)

 

- Michael

Share this post


Link to post
Share on other sites

 

I'm pretty sure the gating of the SRAM is ok since it works perfectly under a 1200XL OS. Although my way of doing it differs from others, some of this was done as you saw to allow also adding in the /EXTSEL signal as well, and to utilize the gates that I had available without needing to add yet another IC. I've also seen this exact same method used in other 6502 designs, including directly tying PH2 into one of the chip selects as I've done. But I won't rule anything out for the time being ;)

 

Only brought it up to cover all possibilities, like you say the mem problem is intermittent so I had discounted the SRAM logic as a cause the other day :)

Yogi

Share this post


Link to post
Share on other sites

I am a bit late to this thread, and am really excited by the project. If there is a run, will it be PAL compatible?

Share this post


Link to post
Share on other sites

I am a bit late to this thread, and am really excited by the project. If there is a run, will it be PAL compatible?

Short answer: Yes and Yes.

Slightly longer answer: mytekcontrol will be releasing the project open source so anyone or group can do a board run and source parts, and another member has plans to do a kit run.

And the board has both clock circuits, so can be built either way.

Yogi

Share this post


Link to post
Share on other sites

 

This looks good and it should fit fine on top of the XEL's Pokey as you've shown it. Can you explain more about what external signals are specifically needed for operation? And what is the 12v/5v jumper thing about? Perhaps there is way that I can better support this in the released version of the XEL PCB if I know what you require (i.e, extra header with desired signal connections).

 

From pokey socket (left or right): D0-7, A0-1 (maybe A2-3), R/W, Phi2

Outside: +12V power supply AD7226, but you can give 5V (covox plays weaker) - look Candle IOboard http://spiflash.org/node/8

Adress line from chip select decoding 74HCT138: pin 13 ($D2xx) or pin 7 or 9 ($D6xx / $D7xx)

 

For address precision you can add line A7 (as ONE) nad A6 (as ZERO) = example as trimming $D280-D2BF

Or another: A4,A5.... look Evie http://atariki.krap.pl/index.php/Evie

 

Exit: Gnd, Left, Right and mix to Mono.

 

EDIT: If you are willing to work with me, I was thinking that we could do a trade of one of your working Covox boards for one of the final released versions of the XEL incorporating the changes required to support your board (this would be a bare board with connector kit included).

 

I've already done Covox extension. But, first: i prefer to test it. I order parts

 

uCovox was first created. With the help of Candle. Then his experience went to SimpleStereo

Sorry my English is bad.

Edited by pajero_pn
  • Like 2

Share this post


Link to post
Share on other sites

There is the K/B interface, which Michael has already adapted for this project, but also a high-speed I/O board, that originally plugged in through the POKEY. If that second item and pajer's COVOX board can sit together in a sort of sandwhich or it can accomodate both, somehow (wasn't there plans to encorporate both the K/b interface and the COVOX on one board, at one time?), this board will accomplish quite a juggling act. :D

  • Like 2

Share this post


Link to post
Share on other sites

From pokey socket (left or right): D0-7, A0-1 (maybe A2-3), R/W, Phi2

Outside: +12V power supply AD7226, but you can give 5V (covox plays weaker) - look Candle IOboard http://spiflash.org/node/8

Adress line from chip select decoding 74HCT138: pin 13 ($D2xx) or pin 7 or 9 ($D6xx / $D7xx)

 

For address precision you can add line A7 (as ONE) nad A6 (as ZERO) = example as trimming $D280-D2BF

Or another: A4,A5.... look Evie http://atariki.krap.pl/index.php/Evie

 

Exit: Gnd, Left, Right and mix to Mono.

 

 

I've already done Covox extension. But, first: i prefer to test it. I order parts

 

uCovox was first created. With the help of Candle. Then his experience went to SimpleStereo

Sorry my English is bad.

 

It looks like the MPBI header on the XEL already has most all of the external signals your board requires. As for the audio output, it would probably be best to wire that to a pair of RCA jacks that can be mounted at a location that suits the user. However I'll think about that last aspect for a bit longer :ponder:

 

iqb0zcS.jpg

 

 

There is the K/B interface, which Michael has already adapted for this project, but also a high-speed I/O board, that originally plugged in through the POKEY. If that second item and pajer's COVOX board can sit together in a sort of sandwhich or it can accomodate both, somehow (wasn't there plans to encorporate both the K/b interface and the COVOX on one board, at one time?), this board will accomplish quite a juggling act. :D

 

Yep TK-II is already an integral part of the XEL, giving PS2 keyboard capability (with a Y-cable, it can actually support two PS2 keyboards simultaneously). Candle's last Stereo board did incorporate dual Pokeys, Covox, and the AKI keyboard interface, but its no longer available. As for stacking both the SIO FIFO and a Covox board, there is plenty of room to do that with the height defined by the Mini-ITX form factor. This is why I also didn't worry about trying to incorporate every friggin thing in my board design, since certain things just made more sense to support via the piggy-back method, and also allowed ways for the user to save some money by eliminating what they didn't need and/or had no desire for. However I did incorporate Dual Pokey's since that has garnered a lot of support over the years, with a multitude of games, demos, and music creation programs that back that up. Covox on the other hand... not so much.

 

 

There is also XRAM test http://satantronic.atari.sk/?str=xe_utils for 1mb to 4mb expansions...

 

Yeah I stumbled across that the other day, and it looks like a good tool to help me better determine what is going on with the XEL RAM apsect. Thanks for the link :)

 

- Michael

Edited by mytekcontrols
  • Like 2

Share this post


Link to post
Share on other sites

Xram Test results...

 

U1MB Setup: Stock XL OS (600/800XL), 1088KB RAMBO, SDX disabled (test in process)

 

sL8Oksz.jpg

 

U1MB Setup:1200XL OS, 1088KB RAMBO, SDX disabled (test in process)

 

rGouWuY.jpg

 

Extended memory looks good under a 1200XL OS, but utterly fails as a later 600/800XL.

 

Then I researched what phaeron was suggesting in this earlier post...

 

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.

 

So to verify a few things I pulled the PIA chip and bent out the Port B pins for the entire port and then reseated it. The XEL powered up and worked the same as before, so it can be assumed that the hardware PIA is not needed for this aspect, being taken over by the U1MB (as was suggested). To further test out this idea, I connected a voltmeter to the Bit 7 connection on Port B (with a 3.3K pull-up resistor) and toggled this line from within Basic.

 

Poke 54017,125 (Bit 7 = 0)

Poke 54017,253 (Bit 7 = 1)

 

The voltmeter stayed near 5 vdc no matter which way I toggled Bit 7. I also tested this out on my XEGS U1MB system, getting the same results.

 

In Basic on the XEL using the 1200XL OS, toggling Port B Bit 7 on and off changes the value seen by Peek(20480) from a 0 to 76 and back. However doing the same with a 'Stock' XL OS, Peek(20480) stays at 76 the entire time. So like phaeron mentioned it appears that the Self-test ROM is remaining enabled when in the Stock 600/800XL OS. This also accounts for the free memory only being 17422 as well.

 

Now the only question that remains is why the U1MB in the XEL chooses to leave the self-test ROM enabled, and only when using a later version 600/800XL OS (developed after the 1200XL)?

 

Note: I also see the same results with an XE or XEGS OS.

 

Looking at the interface between the U1MB and the XEL, and knowing that the PIA Hardware PORT B outputs do not need to be a part of that, I'm left scratching my head as to what could be influencing this peculiar behavior. If it were stock hardware (no U1MB involved), PIA Bit 7 would be the most likely suspect. However as we've seen the U1MB doesn't use or even care about the actual PIA, so that isn't it (and the PIA was already taken out of the equation by bending up it's Port B pins). Very strange indeed :?

 

- Michael

  • Like 2

Share this post


Link to post
Share on other sites

Hi Michael, was comparing XEL with Sam's Computer facts, on both the 800XL and 130XE 16K OS ROM, pin27 ( U1MB header pin 3) is tied to Vcc, you have it tied to A14. On my U1MB (orig) pin3 is isolated on bottom, can't see top side, but V1.1 may have it tied to Vcc (?). All other XEL header pins match the ROM footprint.

Yogi

EDIT: just checked continuity and pin 3 is isolated here but may be tied on newer U1MB

Edited by Van
  • Like 1

Share this post


Link to post
Share on other sites

Part 2 :) I'm questioning your use of /MPD, The 800XL feeds it onto MMU pin 14 only and Just Plain A13 to the OS ROM pin26 (header pin 5). With your wiring, A13 is always high into the U1MB. EDIT: and can't tell if the U1MB P1 'A13' is the A13 net signal, looks like it's just a wire Between P1 and P5/MPD.

Yogi

Edited by Van

Share this post


Link to post
Share on other sites

Hi Michael, was comparing XEL with Sam's Computer facts, on both the 800XL and 130XE 16K OS ROM, pin27 ( U1MB header pin 3) is tied to Vcc, you have it tied to A14. On my U1MB (orig) pin3 is isolated on bottom, can't see top side, but V1.1 may have it tied to Vcc (?). All other XEL header pins match the ROM footprint.

Yogi

EDIT: just checked continuity and pin 3 is isolated here but may be tied on newer U1MB

Since my project originally started out based on the XEGS which had the Basic and OS ROMs combined into one chip there was an A14. But as you've seen nothing is tied to that pin on the U1MB (and just checked a recent board I purchased to confirm that it still is unconnected).

 

 

Part 2 :) I'm questioning your use of /MPD, The 800XL feeds it onto MMU pin 14 only and Just Plain A13 to the OS ROM pin26 (header pin 5). With your wiring, A13 is always high into the U1MB. EDIT: and can't tell if the U1MB P1 'A13' is the A13 net signal, looks like it's just a wire Between P1 and P5/MPD.

Yogi

Yep I already cut that trace on my board as part of diagnosing the problems I am seeing. I then tied the U1MB side to A13 as it was suppose to be, but then discovered that nothing was going to it on that pin anyway (U1MB picks up A13 from the MMU side instead). So although my tie in of /MPD was incorrect (thanks to some incorrect info I got), it also doesn't matter in this case.

 

At this point I have ascertained that all of the Port B connections going to the MMU are no longer needed (recreated internally), A13 & A14 on the OSROM connector also not used, and the Basic enable from the MMU is also not needed. And although I had some incorrect routing of some of those signals, in the grand scheme of things it doesn't matter (although I will fix that anyway).

 

So here's the deal, it looks like all the other MMU connections that do matter are going to their correct locations. Also the required address and data lines appear to be good, as well as the extra control signals /Halt, /Reset, R/W, and PH2. However in spite of this the U1MB has decided to assert the Self-Test ROM (thus disconnecting RAM $5000 and above) for any XL/XE OS above the 1200XL. But this is only happening on the XEL board, so it suggests that something that the U1MB is looking at in the XEL hardware is not correct. I just can't figure out what that can be. Perhaps if I knew how the U1MB determines why that should be done, it would be a lot easier to solve this.

 

- Michael

Edited by mytekcontrols

Share this post


Link to post
Share on other sites

Perhaps you could make a minimal os that just toggles and reads portb - and checks 0x5000?

 

Or perhaps its possible to build a new core for the ultimate with a logic analyser in then connect a jtag to debug?

 

How is reset handled? I wonder if it just powers on in the wrong state.

  • Like 1

Share this post


Link to post
Share on other sites

I haven't been able to come up with a plausible explanation for this behavior either, but I can tell you that there are differences in the PIA initialization between the 1200XL and 800XL OSes as well as some quirks in the Ultimate1MB PIA shadowing.

 

1200XL OS PIA initialization:

A=00 X=00   C584: 8D 03 D3          STA PBCTL    ;CRB=$00
A=00 X=01   C590: 9D 00 D3          STA PORTA,X  ;DDRB=$00
A=00 X=03   C590: 9D 00 D3          STA PORTA,X  ;CRB=$00
A=00 X=05   C590: 9D 00 D3          STA PORTA,X  ;DDRB=$00
A=00 X=07   C590: 9D 00 D3          STA PORTA,X  ;CRB=$00
...
A=00 X=A0   C3C5: 8D 01 D3          STA PORTB    ;DDRB=$00
A=80 X=14   C3D9: 8D 01 D3          STA PORTB    ;DDRB=$80
A=3C X=80   E740: 8D 03 D3          STA PBCTL    ;CRB=$3C
A=3C X=80   C013: 8D 03 D3          STA PBCTL    ;CRB=$3C
A=FF X=80   C018: 8D 01 D3          STA PORTB    ;ORB=$FF
A=38 X=80   C020: 8D 03 D3          STA PBCTL    ;CRB=$38
A=FF X=80   C02A: 8D 01 D3          STA PORTB    ;DDRB=$FF

800XL OS PIA initialization:

800XL:
A=00 X=00   C4DD: 8D 03 D3          STA PBCTL    ;CRB=$00
A=00 X=03   C4ED: 9D 00 D3          STA PORTA,X  ;CRB=$00
A=00 X=05   C4ED: 9D 00 D3          STA PORTA,X  ;DDRB=$00
A=00 X=07   C4ED: 9D 00 D3          STA PORTA,X  ;CRB=$00
A=00 X=09   C4ED: 9D 00 D3          STA PORTA,X  ;DDRB=$00
...
A=3C X=00   C4F5: 8D 03 D3          STA PBCTL    ;CRB=$3C
A=FF X=00   C4FA: 8D 01 D3          STA PORTB    ;ORB=$FF
A=38 X=00   C502: 8D 03 D3          STA PBCTL    ;CRB=$38
A=FF X=00   C50C: 8D 01 D3          STA PORTB    ;DDRB=$FF
A=3C X=00   C514: 8D 03 D3          STA PBCTL    ;CRB=$3C
A=FF X=00   C48C: 8D 01 D3          STA PORTB    ;ORB=$FF
A=7F X=C0   C310: 8D 01 D3          STA PORTB    ;ORB=$7F
A=FF X=6C   C324: 8D 01 D3          STA PORTB    ;ORB=$FF

Minor differences, but nothing that should cause a problem since the end state is both output and data direction registers being set to $FF. If you are using the XEGS OS (rev 4) instead of rev.2 in 800XL mode, then there is the additional difference that TRIG2 is checked as the keyboard present signal, which can in turn cause the OS to toggle PB6... but you appear to have TRIG2 pulled up, and the PB6 MMU handling is internal to U1MB.

 

As for the quirks in U1MB, one is that the reset state of PBCTL (CRB) bit 2 is inverted. This doesn't matter here, as both OSes write to PBCTL first, and at least some versions of the BIOS will also do so before handing off control to the OS.

 

The other quirk is that U1MB cheats a little bit in the 576K and 1088K modes. Normal expansions are dependent upon the outputs from the PIA, so there can only be 8 bits of state. Typically, the larger expansions steal bank bits by either disabling self-test and/or BASIC entirely, or at least when the extended window is active. The U1MB, however, latches bits 0, 6, and 7 when the extended memory window is disabled. This means that the U1MB expansion actually has 11 bits of mapping state driven by PORTB. It still doesn't explain what's happening on the XEL though since the extended memory window shouldn't be getting enabled during OS init.

 

Edit: Do you have the PIA wired up correctly? Checked the schematic again, and it has A0 connected to pin 36 (RS0) and A1 connected to pin 35 (RS1). This would put PACTL at $D301 and PORTB at $D302, but the Atari has the address lines swapped so that PORTB is at $D301. Confusingly, the 800 schematics have these labeled backwards, but the Rockwell and MOS documentation both agree on pin 36 being RS0, and the 400 schematic shows A1 connected to it.

Edited by phaeron
  • Like 6

Share this post


Link to post
Share on other sites

Perhaps you could make a minimal os that just toggles and reads portb - and checks 0x5000? Or perhaps its possible to build a new core for the ultimate with a logic analyser in then connect a jtag to debug? How is reset handled? I wonder if it just powers on in the wrong state.

 

Not a bad idea, but I'm afraid that's beyond my present coding abilities. And hopefully what phaeron just mentioned below might be the key.

 

 

Do you have the PIA wired up correctly? Checked the schematic again, and it has A0 connected to pin 36 (RS0) and A1 connected to pin 35 (RS1). This would put PACTL at $D301 and PORTB at $D302, but the Atari has the address lines swapped so that PORTB is at $D301. Confusingly, the 800 schematics have these labeled backwards, but the Rockwell and MOS documentation both agree on pin 36 being RS0, and the 400 schematic shows A1 connected to it.

 

Yikes why would Atari do that? But yes I do see the transposition of those address lines on the SAMS 800, 600/800XL, and 1200XL schematics that I have here. So that would better explain why the PIA Port B connections didn't change when poking different values into 54017, since they are all effectively inputs and not outputs as they really should be. I remember at the time when I was testing Bit 7 by toggling the bit in software I thought it strange that nothing was happening in reality. I dismissed this as the U1MB simply taking over the port.

 

Thinking back to my PIA tests... my intention was to do a conformation check on my XEGS system as well, but I got side tracked and never did. And now that I am once again looking at where Port B Bit 7 connects to the U1MB, I see a trace connected to that pin. So there might be a very real possibility that the transposed address lines on the PIA has been the problem lurking in the shadows this entire time. The really odd part is that the joystick ports still work. How is that possible when they should have been set-up as outputs instead of inputs, and at a different address than expected? I'm not going to worry too much about that for now, and instead when I get to my shop later today I'll be swapping address lines A0 and A1 on the PIA and reconnecting Bit 7 to the U1MB. Hopefully this will finally be the solution that I have been seeking, and all will be good in XEL land.

 

Thank you so very much phaeron for taking the time to really look into this and provide such excellent feedback :thumbsup: :)

 

- Michael

Edited by mytekcontrols
  • Like 5

Share this post


Link to post
Share on other sites

SUCCESS :thumbsup: :) :-D :rolling:

 

Phaeron's notion about the transposed address lines on the PIA has paid off big time, since it was indeed the problem with the XEL. Thank you phaeron :) Bad Atari :mad:

 

Had to do a little surgery (since there were top and bottom traces involved on the PCB this was the best way to approach it for now)...

 

gWC2k5l.jpg

 

Free Memory now looks correct in Basic under an XE OS...

 

krzFGAH.jpg

 

Self Test was good...

 

KrB5Bk9.jpg

 

And running GoodByteXL's extended memory test under SDX showed no problems...

 

https://www.youtube.com/watch?v=3CvJUA2vcKI

 

Looks like the XEL is fully functional. Now it's time to run a few more tests, and then this will be passed along to some fellow AA members I selected for them to run tests in parallel to me. When it gets the kiss of approval from my BETA Test Team, it'll be time to go live with the final release (well after I've tested a V1.1 revised board).

 

EDIT: Tested joystick ports again after the changes, and I'm happy to report they are still working. Funny thing was they worked even with the transposed PIA address lines. Go figure (PIA PORT A and B must be mirrored in the OS).

 

- Michael

Edited by mytekcontrols
  • Like 20

Share this post


Link to post
Share on other sites

What mod is this on the 1088XEL?

 

That mod is to reverse the two address line inputs on the PIA chip (6520). Apparently Atari wanted to play a trick on me and routed A0 to PIA RS1 and vice versa with A1 going RS0. Or maybe this was their way of implementing a crude copy protection for their motherboard ;)

 

- Michael

  • Like 2

Share this post


Link to post
Share on other sites

OH Great news!!! It's really amazing that this minor bug ( BAD, Atari) was the only error on your prototype. It's quite a milestone, such great work!!!

Yogi

  • Like 3

Share this post


Link to post
Share on other sites

OH Great news!!! It's really amazing that this minor bug ( BAD, Atari) was the only error on your prototype. It's quite a milestone, such great work!!!

Yogi

 

Hi Yogi, that's nice of you to say, but I also made a few other errors involving the MMU and OSROM connections to the U1MB. Luckily for me, none of those were an issue, and it was just dumb luck that the U1MB didn't care about any of the mistakes I made in that aspect. However all of this will be fixed properly just in case a later revision of the U1MB were to change any of that. So yes there will be a V1.1 board release that will incorporate the changes that are needed and discovered in this first V1.0 board run. All in all, I think everything has gone quite well thus far :)

 

- Michael

  • Like 1

Share this post


Link to post
Share on other sites

 

but I also made a few other errors involving the MMU and OSROM connections to the U1MB. Luckily for me, none of those were an issue,

Nay; Those were just 'future mods' :) Very happy for you, must be walking a couple feet off the ground ( I'm am, just as a bystander) :)

Yogi

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...