1088XEL Atari ITX Motherboard DIY Builders Thread

[+mytek]

Herb to answer your question...

 

Yes there is a working GOS test Rom for the U1MB, and I have it somewhere saved on my desktop system but it's late and I'm on my tablet in bed at the moment. Jon will likely read this and beat me to uploading it.

 

Sorry to hear you had so many problems attempting this earlier, and boy did that sound like a lot to go through (almost gave me a headache reading about it).

[flashjazzcat]

I dug through Jons site and realized his old GUI demos are for flash solutions OTHER than the U1MB. I searched the forums and found a U1MB .ROM hed posted a couple years back and decided to give it a try. So I fired up UFLASH, shrunk SDX down to 192K, flashed an appropriately-sized version of 4.49, then flashed the GUI .ROM Id found.

Do you have a link to the ROM you used? I'd be interested to see if I can possibly replicate this remarkable saga.

 

When I rebooted and enabled the GUI in the settings, I was able to boot to the desktop but my mouse didnt work, whether set (via the Mouse Select board) to either port 1 or port 2. When I disabled the mouse select port and tried a CX-22 Trak-Ball, I was able to get random, mostly down/left movements but nothing useful.

Sounds like a GOS build for Amiga mice...

 

So I said screw it and hit F12 to go back to the U1MB BIOS. The system just reset (e.g., SYSTEM RESET was the only key registering). Uh, oh. So I tried F8 + F10. Same thing. Each time, right back to the static GUI display with non-responsive mouse. I powered off the system, waited a moment and powered up. I got the 1088XEL splash screen, then the progress bar and menu, but F10 didnt work to go to setup. F11 would work for the loader, but I couldnt get into the actual U1MB setup.

At first sight it rather looks as if the BIOS hotkey has been changed from 'Help' to 'Start'. Since this is a binary option described by a single bit in the battery-backed RAM on the DS1305 RTC chip, it has to be one or the other (it can't be 'neither'). And the only way to change this bit (on a system which isn't blighted by instability) is via the main BIOS setup menu or some other software which writes to the SPI register at $D3E2 in a sufficiently cohesive manner that serial writes actually occur. No GOS ROM does this, so I suspect magic.

 

Finally I did what I shouldve done when I couldnt F12 to the setup menu to disable the GUI - I pulled out a screwdriver, opened her up and popped the battery on the U1MB for about 20 seconds. After that, I was able to get back to the setup menu to set the date/time again, reset all my colors and profiles, and boot back to SDX. I still got a weird error about ATARIDOS.SYS so I launched UFLASH again, sized SDX back up to the 320K I had been using before, then reflashed 4.49 (the same tweaked version I had made a few weeks ago with the Hidden attribute set for all the FDISK .OVL files).

It seems that you have a copy of SDX floating around with a corrupt CAR: volume (hence the ATARIDOS.SYS error); perhaps the shorter versions were improperly truncated. I'm really fascinated by the NVRAM corruption on the U1MB, however. The configuration is CRC checksummed, so any bits flipped outside of the proper channels - unless two perfectly complementary bits flipped at the same time - would result in a mandatory jump directly into the BIOS setup menu and notice that the configuration had been reset (owing to it being corrupt). Likewise, had the misadventure in flashing somehow resulted in part of the main BIOS being corrupted in ROM, your machine would have been completely bricked. I'm tempted to conclude that the BIOS hotkey was inadvertently switched to 'Start' until another viable theory can be provided.

 

So ... all this is a very long way of asking, is there a version of the GUI that will at least work to let me play with it on the 1088XEL?

This is what's flashed to my 1088XEL's U1MB ROM:

 

gos1088.zip

 

Please let us know how you get on.

 

Like I say: this detailed account seems to document three observations:

• A GOS build for Amiga mice was flashed to the U1MB
• The 'Help' key stopped working as a means of entry into BIOS setup because the assignment was somehow changed
• Various problematic SDX ROMs were subsequently flashed until a working one was found

Since you've experienced odd keyboard issues in the past, I can't be absolutely sure about the diagnosis of the second issue, but the others don't seem too mysterious.

Edited February 24, 2018 by flashjazzcat

[+DrVenkman]

 

This is what's flashed to my 1088XEL's U1MB ROM:

 

gos1088.zip

 

Please let us know how you get on.

 

Like I say: this detailed account seems to document three observations:

• A GOS build for Amiga mice was flashed to the U1MB
• The 'Help' key stopped working as a means of entry into BIOS setup because the assignment was somehow changed
• Various problematic SDX ROMs were subsequently flashed until a working one was found

Since you've experienced odd keyboard issues in the past, I can't be absolutely sure about the diagnosis of the second issue, but the others don't seem too mysterious.

 

Thanks, I'll let you know how that version works. Here's the version I found with the Forum search last night. At the time I didn't even think about an Amiga/ST mouse dichotomy, though I remember know the zip file on your site has them split up that way.

 

The SDX versions were all straight out of the zip file downloaded from the SDX Project site a few months back. The only change I made to any of them is to set the Hidden attribute on the FDISK .OVL files of the 320K version. However, a variable here is that when I reflashed the U1MB Firmware slot and then resized/reflashed SDX, I did it using an older version of UFLASH from your APT Tools disk, since it was self-booting and would get me to a command prompt at a time when the machine kept loading straight to the non-responsive GUI. That version of UFLASH did give a warning about SDX using memory under the OS, but since I couldn't access Setup to disable SDX, there wasn't much I could do about it, so I continued. There was an odd pattern of bits across screen memory during flash operations - looked almost like old-school RF interference but clearly tied to the write operations. However, each slot verified correctly after writing.

 

In retrospect, at the beginning of all this I probably should've pulled the U1MB battery to dump any corrupted settings to see if I could get back to the Setup screen, especially since I'd already verified that F11 allowed me to get into the Loader. I also guess I should keep the latest copy of UFLASH in the FAT partition to access from the Loader. Ah, well. Live and learn.

 

And finally, as for keyboard issues, there were really only two. First off, F12 was not allowing access to Setup at all until I flashed your first XEL-specific test builds. Once that was sorted, I had issues on cold-boot/power-on access to Setup or the Loader during the splash screen progress bar prompts, but after the system had powered up completely, things worked as normal. Michael worked up several test builds of the TK-II PIC firmware which he had me test. All my keyboard issues have now been corrected. I don't think that version (TK-II version 2.3) is yet on the 1088XEL project page but I'm sure he'll get around to updating the zip file there soon.

[+DrVenkman]

Hey, the GUI looks great! Mouse input is fast and smooth. If I win the lottery, I'll be underwriting the rest of your development costs.

[flashjazzcat]

Here's the version I found with the Forum search last night.

That one's clearly labelled for ST mice and it works fine here (just tested it), so you had the right one.

 

However, a variable here is that when I reflashed the U1MB Firmware slot and then resized/reflashed SDX, I did it using an older version of UFLASH from your APT Tools disk...

OK: say no more...

 

In retrospect, at the beginning of all this I probably should've pulled the U1MB battery to dump any corrupted settings to see if I could get back to the Setup screen, especially since I'd already verified that F11 allowed me to get into the Loader. I also guess I should keep the latest copy of UFLASH in the FAT partition to access from the Loader. Ah, well. Live and learn.

As I say: it's hard to imagine neither 'Start' nor 'Help' allowing access to the BIOS menu unless the flash ROM has been comprehensively mangled, but an old version of UFLASH which probably has little or no knowledge of the newer firmware could conceivably overwrite crucial parts of the BIOS such that setup becomes inaccessible without the system being bricked. I guess we have the answer there, and clearing the NVRAM recovered the system from a completely undefined state.

 

Hey, the GUI looks great! Mouse input is fast and smooth. If I win the lottery, I'll be underwriting the rest of your development costs.

Yes: mouse control feels very pleasant with Michael's interface. Sadly, a lack of money is not what's elongating the project timeline, but the incentive is most welcome nonetheless.

[flashjazzcat]

Thanks for the video BTW: enjoyed that.

[+DrVenkman]

Thanks for the video BTW: enjoyed that.

 

You're welcome. I did a quick follow up; the conversation about NTSC artifacting on an 800 in the last couple days got me wondering what the GUI would look like in Composite. The answer? Still quite excellent! I actually quite like the sunrise orange color on my C1702. I'll try it again through my cheapie capture device later today.

 

[flashjazzcat]

It may take me a few days to "unsee" that, but it's interesting nevertheless.

[_The Doctor__]

It looks much better in person, the recording does not do it justice.

the 1702 is showing it's inferior dot pitch with all the moire patterns and such, I never liked them... all of them should be replaced with quality nec monitors.

Edited February 24, 2018 by _The Doctor__

[flashjazzcat]

You mean the green and orange bits only show up on camera? OK then.

[_The Doctor__]

sometimes those artifacts are reduced when you have a good screen, with great dot pitch, and it's convergence as well as geometry is precisely adjusted.

[flashjazzcat]

sometimes those artifacts are reduced when you have a good screen, with great dot pitch, and it's convergence as well as geometry is precisely adjusted.

 

Well yeah: it can be eradicated completely by various means, but Herb deliberately enabled artifacting in his video.

[+DrVenkman]

Bear in mind, that's the GUI in Composite. In chroma-luma it looks about like it ought. I'll check it on my early 00's Toshiba later today. And while _The Doctor_ may crap on the 1702, it is a quality JVC tube and the model still in much demand today by those of who appreciate a CRT for old game and computer systems.

 

Anyway, I did two quick tests of the cheap $13 USB capture device I bought a few weeks ago. The first is Composite. Ugh. What a blurry mess. The capture card does NOT like Gr.8 2-bit graphics at all.

 

 

​Second is S-video. This looks tons better, much like it does in a real CRT.

 

[flashjazzcat]

Y/C usually looks just fine on these old CRTs once the video output is fixed up. I generally avoid composite video and was never much of an artifacting fan. I've tested the GOS on my Incognito 800 via the stock Y/C video output on a Commodore 1084S D1 and there wasn't a trace of colour.

Edited February 24, 2018 by flashjazzcat

[+DrVenkman]

Okay, my last post on video output ... This really makes me want to track down a 12" - 14" Toshiba screen (this one is 27" and far too big for a small desk area).

 

 

 

And even Composite looks pretty okay.

 

 

 

 

Man, Bryan's video circuit combined with Michael's super-clean power and ground planes in the mainboard design give some kick-ass results.

 

 

[_The Doctor__]

I think he likes to torture us, that capture card ghosted and did all sorts of awfulness even the bios screen looked owie oochie to the eyes.

I beg you no more good sir... please...

 

Okay I like the last post much better!

Would be cool to see all the composite monitor or tv's showing what individuals consider great or good... I don't want the ugly sweater contest though

Edited February 24, 2018 by _The Doctor__

[john_q_atari]

Just in case there are new builders out there, I thought I would share my experiences with cutting down the sparkfun extra tall female headers for the U1MB (prt-14017). I didn't have "sharp" cutters or whatever else people were using so I experimented a little bit. Just in case anyone was curious, using a hammer and chisel to cut it down to size is a VERY BAD idea. I kinda destroyed one that way. What does work well is using a utility knife with a sharp blade and pressing the blade into the plastic on top of where the metal pin is until you reach the metal pin. Then flip the header over and repeat. Then I used slip joint pliers (the ones with the flat nose end and adjusts to 1 of 2 settings) to grip the shorter end of the header I was breaking off, and an adjustable wrench (to substitute as a vice) to keep the other size from twisting, and simply used the pliers to snap off the short end. Many people seem to sand the "cut" edge smooth, but the plastic is soft and it is VERY easy to sand too much. In my opinion, when in doubt, don't sand it. Better to be ugly and functional.

 

Also with respect to cutting out the center braces of the pokey chip IC sockets, a sharp utility knife worked well. just press down. I didn't find the need to score or in any way prepare the sockets, I just pushed down the utility knife blade and it all snapped out perfectly.

[john_q_atari]

Question, my U1MB arrived today from Lotharek but he only sent me 1 even though I ordered and paid for 2. (I have emailed him just now about this.) Also the board he sent was not in an anti-static bag. Is this how he normally ships them out? If so, do people ever have a problem with ESD issues or receiving dead boards? (It will be a bit until I finish my build and can test the board I did receive).

[+DrVenkman]

I’ve purchased two U1MB’s from Lotharek over the years, plus a third that came with the BOM for the 1088XEL, which I received via MacRorie. All three of them came in a cardboard box with black/gray foam padding, no plastic baggie. All three of them have been just fine. Your mileage may vary of course.

[john_q_atari]

I’ve purchased two U1MB’s from Lotharek over the years, plus a third that came with the BOM for the 1088XEL, which I received via MacRorie. All three of them came in a cardboard box with black/gray foam padding, no plastic baggie. All three of them have been just fine. Your mileage may vary of course.

 

Okay great. That is exactly how mine came. At least that makes me feel better that the one I did receive will probably work since the ones you received in the same manor worked as well.

[+mytek]

And finally, as for keyboard issues, there were really only two. First off, F12 was not allowing access to Setup at all until I flashed your first XEL-specific test builds. Once that was sorted, I had issues on cold-boot/power-on access to Setup or the Loader during the splash screen progress bar prompts, but after the system had powered up completely, things worked as normal. Michael worked up several test builds of the TK-II PIC firmware which he had me test. All my keyboard issues have now been corrected. I don't think that version (TK-II version 2.3) is yet on the 1088XEL project page but I'm sure he'll get around to updating the zip file there soon.

 

Today I added the new version of the TK-II firmware to my website, and thought it would be nice to upload it here as well. Please note that the zip file contains a flashing ATR for use with the JOY2PIC programmer, a HEX file for use by a Microchip PICKit programmer or similar, and the FlowCode source code file.

 

New TK-II firmware: TK-II_V2.3_firmware.zip

 

Thanks to Herb's keyboard issues, a much better, simpler, and more reliable method has been implemented to provide the Auto-Sustained Console key aspect that allows for booting with BASIC disabled (held OPTION) or booting directly to the XEGS game slot (held SELECT). Also it was discovered that the original method of providing this feature was blocking other keys from being seen during the boot-up process. The new firmware addresses all of these concerns.

 

Here's a little something I put together to better explain some of the key actions during power-up, and the special U1MB function keys.

 

 

[john_q_atari]

And the 2nd one is on its way. Cool. Now I can try my luck with the U1MB headers tonight. I'm thinking about using the hot air pencil again since I had good luck with it the first time. Has anyone else gone this route? If so, any recommendations? I used 310C for the DIP removal, but I read the lead-free solder melts 20C higher than 60/40, though 310 should probably still cover the lead-free...

[_The Doctor__]

sometime I add 60/40 to the lead free before I remove them, this is the case without question on stubborn instances, you can bump up your heat slightly if so inclined. I think it's been well covered thru the thread what to do. Should be trouble free if quick and careful following the tips..

[+MacRorie]

sometime I add 60/40 to the lead free before I remove them, this is the case without question on stubborn instances, you can bump up your heat slightly if so inclined. I think it's been well covered thru the thread what to do. Should be trouble free if quick and careful following the tips..

 

 

Just to jump on this: I *always* add some solder to each of the pins before I try to de-solder them. It makes a big difference in the amount of time I spend trying to remove them. However, YMMV.

[+DrVenkman]

sometime I add 60/40 to the lead free before I remove them, this is the case without question on stubborn instances ...

 

 

 

 

Just to jump on this: I *always* add some solder to each of the pins before I try to de-solder them. ...

 

After my terrible amateur-hour experience doing this, you can damn-betcha I will be doing the same thing if I ever build out my second 1088XEL board!