1088XEL Atari ITX Motherboard DIY Builders Thread

[flashjazzcat]

Does anything stand out on my results of the Transend card?

Just that the 4GB Transcend card passes all the tests, so I assume problems with that one are confined to hot-swapping, or that there's some other obscure compatibility issue. The 512MB Transcend is clearly a complete wash-out, meanwhile.

[AtariGeezer]

Just that the 4GB Transcend card passes all the tests, so I assume problems with that one are confined to hot-swapping, or that there's some other obscure compatibility issue. The 512MB Transcend is clearly a complete wash-out, meanwhile.

It must be some other obscure compatibility issue then after trying a Refresh, since there wasn't any hot-swapping involved...

[AtariGeezer]

I received the Refurbed SanDisk cards yesterday and still getting this glitch with the latest firmware:

 

So I tried flashing older versions and the only version that worked with these cards was from June 29, 2017.

 

Both of the Refurbed SanDisk 4GB cards and the Transend 4GB cards will boot to D3: all day long with all of the firmware releases, but only the firmware from June 29, 2017 works with the loader using the 2 different card types...

 

[Brentarian]

I have USB keyboards and mice working on my 1088XEL now. Well, truthfully they are going through a Belkin Omniview Pro KVM that has USB inputs and outputs PS/2. I have the 4 port unit and is quite large, but this should work until another solution comes around with a smaller footprint.

 

[AtariGeezer]

Here's something to ponder, the stand-alone SIDE Loader for Incognito runs okay and displays the FAT32 contents just fine and even runs all xex's without a hitch. So it's not a hardware issue that I'm experiencing ...

[AtariGeezer]

Got it working now and it was software related, but, only from user error

I had set the SDX size to 192k so I could install GOS. Reflashed SDX, then GOS, then updated the Firmware <- this was the problen as I used a 256k SDX image..

 

Today I changed the SDX size back to 256k, reflashed SDX and the Firmware. Loader isn't having any glitches now

 

Sorry Jon for thinking you had overlooked something, when I made it wonky

[+Spaced Cowboy]

What is involved if I wanted to convert an NTSC 1088XEL to a PAL one ?

 

I'm planning on playing with some APAC graphics stuff, and from reading, PAL is the way to go here. I seem to recall it was relatively straightforward, involving a crystal and chip-swaps but wanted to make sure.

 

I have a Sophia/DVI module installed, which is my only video output, would that have any effect ?

 

I'm assuming I can just hit up MacRorie for any and all supplies He da man!

 

Cheers

Simon

[+MacRorie]

What is involved if I wanted to convert an NTSC 1088XEL to a PAL one ?

 

I'm planning on playing with some APAC graphics stuff, and from reading, PAL is the way to go here. I seem to recall it was relatively straightforward, involving a crystal and chip-swaps but wanted to make sure.

 

I have a Sophia/DVI module installed, which is my only video output, would that have any effect ?

 

I'm assuming I can just hit up MacRorie for any and all supplies He da man!

 

Cheers

Simon

 

 

Shifting ot a PAL unit is real easy:

 

Replace ANTIC and GTIA, Replace X1. Shift J21 from NTSC to PAL Done.

 

This assumes you installed all of the X2 PAL Colorburst stuff. Which you would have to expressly NOT install items from the Official BOM, so most everyone is good to go.

 

And, yes, I have all of the PAL chips/crystals you need.

 

(Edited to reflect MyTek's message so it is all in one post)

[+mytek]

Everything that MacRorie said, plus move the J21 jumper from NTSC to PAL so that the V-Gate chip renders invisible over scan switching.

[+Spaced Cowboy]

Everything that MacRorie said, plus move the J21 jumper from NTSC to PAL so that the V-Gate chip renders invisible over scan switching.

 

Thanks Michael, will do

[Evidious]

Fun Build. With the exception of a solder bridge that took me a week to find everything went well. Thanks to Mytek And MacRorie

[+DrVenkman]

Just wondered if Jon's latest/final 1088XEL U1MB firmware has made it out yet? I know he's making more fun hardware videos again (yay! #NerdTV!!! ) but hopefully that implies he's about as "done" with the latest U1MB stuff as he can get. Maybe?

[flashjazzcat]

Unfortunately it just implies I urgently need to complete backlog of hardware work, but yes: the firmware is done. I just don't have sufficient spare hands to get everything prepared and uploaded until these jobs are signed off.

[+mytek]

IMPORTANT ANNOUNCEMENT

 

The Cool Novelties 1088XEL to SCART cable needs to be redesigned. This is all my doing, and something I will be correcting very soon. For those that bought this cable please do not send it back for a refund, but instead PM me and I'll arrange to update it for you. Because this is not Cool Novelties fault, and they shouldn't have to suffer any income loss as a result.

 

So in the meantime please do not purchase this cable, even if the buy link still works on their site. I will try to get this straightened out real quickly, and then let you know when the revised cable will once again be available.

 

And of course I will post the corrections here as well, for those that feel like doing the fix themselves.

 

So sorry for this .

[Lavalamp]

I soldered in the the replacement LED's, and they light up as expected, 5v good, power on lights up, but i get no boot, the lights on the BOB board flicker on power up so I guess I have a short somewhere.

[AtariGeezer]

I soldered in the the replacement LED's, and they light up as expected, 5v good, power on lights up, but i get no boot, the lights on the BOB board flicker on power up so I guess I have a short somewhere.

Flicker on the BOB board is normal until you plug in a USB Cable to your PC.

 

Check the orientation of the IC's...

[Lavalamp]

Flicker on the BOB board is normal until you plug in a USB Cable to your PC.

 

Check the orientation of the IC's...

 

Oh, well that's potentially exciting, will do, thanks!

[+mytek]

Flicker on the BOB board is normal until you plug in a USB Cable to your PC.

 

Check the orientation of the IC's...

 

Good suggestion .

 

In particular check the CPU and Antic chips.

 

[+mytek]

Cool Novelties 1088XEL-SCART Cable issues have been resolved.

 

Thanks to flashjazzcat's suggestions and willingness to test this on his end, the following solution was arrived at.

 

 

Although this cable will no longer double as an ST RGB monitor cable as I had originally tried to do in the first design, it will now work on an un-modified 1088XEL. And it will be good to go with either a VBXE or Sophia Rev A or B as the RGB video driver board, also without any modifications to those devices.

 

Andy over at Cool Novelties has updated their product based on this new Version 2 design, and for people that have the Version 1 cable he said "if anyone wants to send them back for modifications it’s no problem". However I would add that if you are in the US, please send your cable to me for repair since postage will be far cheaper (PM me).

 

V2 Buy Link

[+mytek]

Did a minor and long overdue update on the 1088XEL schematic correcting what DIN-13 pins are assigned to the left and right audio outputs. The original schematic(s) showed it reversed from actuality, but correct if the original plan had been implemented properly. Unfortunately the PCB pattern for the 3.5mm audio jack had the switched audio output pin numbers inverted from reality. So I thought no sense in pretending otherwise, and it was high time to show it "as it truly is" in the schematic. I also eliminated the Pin-2 to Pin-9 jumper mod, since it's no longer needed with the new SCART cable wiring. The only mod left is the VSYNC mod, which really is only required for the ST GoldStar SC1224 RGB monitor as far as I know.

 

The left and right output orientation from the 3.5mm jack is correct. Only the audio on the DIN-13 jack was affected. BTW, the new SCART cable properly distributes the left and right channels to your TV.

 

To get the new schematic, jump over to the Main 1088XEL page and download the PDF (corrections are shown on the last page).

[+Spaced Cowboy]

I have a question regarding the H80 mini-itx case that seems to be pretty much universal with 1088XEL owners right now...

What's the clearance inside the box for a plug-in card into the XE-expansion slot ? My current board won't fit (it's 10cm tall) but I'm wondering what the maximum vertical space is that I could use, and I don't have a case myself to try it out.

We'd also have to think about the back panel. Assuming there's a need for a cat-6 cable to come out the back, can I ask opinion on what the preferred interface would be ? Options I can think of are:

• Require a panel-mount RJ45 (ethernet) jack on the back panel, and have a very short cat-6 cable internally connecting the expansion board to the externally-facing RJ45. This is probably the neatest option from an external point of view, and means you can still unplug everything.
• Simply have a small cat-6-sized hole at the top/bottom of the rear panel (we can grommet it to prevent chafing) and feed a cat-6 cable through the grommet to connect internally. The upside of this is that there's less connectors, which helps signal integrity. The downside is that you're left with a 'pigtail' cat-6 ethernet cable coming out of the back of the 1088XEL case. Putting the grommet-hole (as a 'U' cut-out) at the top/bottom of the rear panel means you don't have to feed the actual connector at the end of the cat-6 cable through the hole, it just needs to be big enough to hold the wire and grommet.
• Make the board have its own RJ45 connector in such a position that it can be incorporated into the back-panel design. This is the cleanest option of all (best for signal integrity, best for modularity) but it means (a) back-panel designs would need to be re-done, which is expensive, and (b) the location of the RJ45-sized hole on the back panel would have to be reserved for the card, which might not fly. I'd also need specific board-length requirements in this case, and to take into account clearances for any other internal options that might be installed.
• Don't bother, say "if you want the expansion bus, get a bigger case like the Cooler Master Elite 110 and make it all-in-one".

This all pre-supposes y'all are even interested in a 1090XL-style expansion box in the first place [grin]. The thing is that I'm debugging an issue with the SDRAM on the first prototype board at the moment, and it *might* need a re-spin. If so, I'd like the new board to at least be applicable to the 1088XEL, and since you've all standardised on the H80... well...

Cheers
Simon.

[+mytek]

What the heck, somebody forgot to put a hole in the back panel? When I find out who that is there will be some serious talking to

If it were up to me (which it really isn't) I would go for your first option of having an RJ45 jack hole for a panel mount connector with short internal pigtail. But by far the best option is to have it line up with a PCB mounted connector on your PBI interface board. And even better still if your board can be made small enough to fit inside the H80 case. As for how much vertical room you have to work with, I can't say off hand, but I will look into that later today and get back to you. Assuming someone doesn't beat me too it.

 

If you do take over the CART/ECI bus with your interface card, I'm assuming there will be a cart port possible from the 1090 expansion box?

[+Spaced Cowboy]

 

If you do take over the CART/ECI bus with your interface card, I'm assuming there will be a cart port possible from the 1090 expansion box?

 

 

Mmm. Possibly, actually, at least I don't want to advertise that this will be available yet... My current board ...

 

 

...provides a cartridge slot on the plug-in board, but of course that was envisioned as sitting behind a stock 130XE, so it'd be facing upwards and be easily available - that's not the case (no pun intended) for the H80, and it's something I'll have to think about. I did consider just bundling all the connections onto a 2x20 pin header and having a ribbon cable to another PCB that provides the physical interface we need for cartridges, which in turn could be secured to any case with glue/screws wherever necessary.

 

I'd actually love to get rid of the cartridge pinout (it's huge!) and have the cartridge port be available in the (much larger) external case. The issue comes from the time budget I have for the 'read' case to the cartridge memory. A valid address will appear on the bus about 177 nanosecs after the clock signal transition from high to low. I have to have the results of that read operation pushed out to the bus by 558 nanosecs after the high=>low clock transition, giving me a time-budget of 381 ns.

 

Assuming a link-speed divisor of 5ns on the XMOS link (which is about as good as I could hope for) I get about 18MBytes/sec over the link, so each byte transferred takes ~53ns. I'd need to transfer a data packet of {command, address-hi, address-lo} in the outbound direction, and {command-return,result} in the inbound direction for a total of 5 bytes. {command} and {command-result} here would identify that the far end is supposed to get the data from the cartridge and return the value.

 

Now, 5x53ns is obviously less than 381ns, but there'll be some time required to present the data to the cartridge (especially if it's old-tech) and get the result from its internal RAM. That could be 70ns. There's also the processing time at both ends of the link (say 40ns). Overall I think it's unlikely that the data would get back in time for the XL/XE to be able to use it, although it's frustratingly close.

 

 

The XMOS chips do allow a 5-way link (I'm only using 2-way links) but given that the link has to go to via external cable, I'm using a differential line driver which doubles the number of signals I need (a 2-way link needs 4 wires, doubled to 8, which just fits into CAT-6. A 5-wire link needs 10 wires, doubled to 20 for the line-driver). I'm also limited by which cables are rated for such high throughput. Cat-6 is (a) cheap, and (b) easy to come by. Just a connector that can accept higher-density cabling in a modular form would be ~$20 (at each end).

 

This is the reason there is SDRAM on the local-to-the-computer board, peripherals can upload data over the link, then trigger an interrupt on the 6502, at which point the reads are all local and easy to fulfil. The design was not-to-require the long route for read-ops from 6502->XMOS->link->XMOS->peripheral/cartridge->XMOS->link->XMOS->6502 in a single clock cycle, just 6502->XMOS->6502. Write's are easy because the XMOS bus is decoupled from the 6502 one, so there's plenty of time to fulfil the operation (not that cartridges generally need writes, just pointing out that reads are the difficult case).

 

 

Having said all that, the timing diagrams might not be very accurate, or might have more slop in them than I think right now, and maybe I have more time than I think I do. If you take the numbers above, then it *just* fits (assuming 70ns for a cartridge read) by 6ns. That's much too close for me to feel comfortable saying "it'll work" though, so I won't know until I try it.

 

 

However.... It's also possible that I might be able to squeeze a byte out of the inter-XMOS communications protocol for this special case (read remote memory) by getting rid of the requirement for a {return-result} code, and setting a flag to say 'if I've just sent a read-request for memory, the next byte back is my answer'. That shaves 53ns.

 

Further to this, I could declare one specific address (say $D1FE since that's in external-address-space anyway) to be un-fetchable, then use that address as the preamble identifier for 'this is not an address-fetch' in all other communications; that would squeeze another byte from the inter-xmos communication for the special has-to-be-quick case. There's another 53ns saved. Now it's looking more likely.

 

So I don't want to rule it out, and I actually think it would be a really nice thing to do, I just want to try it and see before I say 'yes'.

 

 

[edit: thinking a little more about the protocol...]

 

Actually, cartridge reads are all within the 8k region of $A000 to $C000, which is only 8k, which encodes into 13 bits if I send as an offset, so I could encode the 'command' into the remaining top 3 bits of the address being passed over the link, thus removing the need for a 'forbidden' address while still reducing the outbound bytes sent down to 2 bytes

 

This'd need another instruction on the XMOS to do the masking, which would take another 10 or 20ns, but it's still a good trade-off

[/edit]

 

Simon.

[flashjazzcat]

Why is the cartridge ROM apparently integral to this design? Could the device not carry all its 6502 firmware on an external PBI ROM? I've looked through the thread documenting the device design but I'm still a little nonplussed as to where the cartridge comes into it.

[+Spaced Cowboy]

Why is the cartridge ROM apparently integral to this design? Could the device not carry all its 6502 firmware on an external PBI ROM? I've looked through the thread documenting the device design but I'm still a little nonplussed as to where the cartridge comes into it.

 

 

For any in-depth conversation, we should take this to the expansion-box thread so as not to derail...

 

However... It can carry all of its *own* ROM on its own QSPI flash, that's no problem. The goal, however, is:

 

• To allow arbitrary peripherals to provide 6502 code to execute in their own memory space, (say, external midi card wants to provide an interrupt handler for when midi data is sent to the XE. That 6502 code can be uploaded onto the SDRAM by the peripheral as part of the boot process and mapped to the 6502 memory block on demand, midi data can be transferred to SDRAM as it arrives, and the IRQ handler gets called (reading from local SDRAM memory) when the interrupt is triggered by the peripheral). Not a problem.
• Also to allow any cartridges to plug in without problems. Ideally I'd like the expansion board to be transparent to cartridges, and not have to do anything like the above. As I was trying to say in the previous post, getting read-data back from the cartridge within the time-scale available is possibly a problem, given the now-extended route that the data has to take, so mounting the cartridge port in the expansion chassis, although desirable, involves me testing stuff out first.

 

[edit]

In case it's not clear, this is because I'm taking over the cartridge slot for the XE, there's no separate PBI interface, and I still want people to be able to plug in their cartridges without having to first unplug the expansion box

[/edit]

 

Now I'm off to watch the Champions League semi-final, given that my home town are playing