XEL-CF Compact Flash Adapter for 1088XEL (formerly XEL-I3)

[flashjazzcat]

While testing the TK-II's U1MB screen tracking I noticed something interesting and kind of inconsistent. If you have SDX enabled, after 1st entering the LOADER screen, then going to SETUP, upon returning with either ESC or X you will be put back into the LOADER. This makes sense, and will consistently do this until you either do a restart (CTRL+R) from the LOADER, or do a restart (C or B) from SETUP. But if SDX is not enabled, then it doesn't matter if you were in the LOADER before going to SETUP, because ESC or X will always bail you out to the Basic prompt. I don't see how having SDX enabled or not should influence this, but it does.

It's easy to see why this happens, I think. When SDX is disabled in the setup menu, it actually completely deactivates the exposed ROM banking register (so SDX should be completely invisible to the system once the configuration lock is applied). The exception to this is when the loader is booted while SDX is disabled. In that case, the SDX banking register is left exposed on a one-off basis so that the OS can boot with the correct bank present. When you subsequently perform reset, the BIOS - aware that SDX is disabled - completely hides the SDX banking register again. Therefore, when you come out of setup, you end up in BASIC.

 

The unfortunate thing with the banking register is that it's write only, and believe me that made the bank handling quite difficult given all the extra functionality. For instance, if we do a COLD /N from the SDX prompt, we have to make sure we never touch the banking register at all on warm reset (not until we re-enter setup). The upshot of this is that setup can't tell which ROM bank was present when we entered setup.

 

A solution might be a persistent flag which keeps track of the state of the system on the previous boot. But that may in itself bring about unwelcome side-effects unless carefully managed. For instance, if you launch a BASIC program from the loader, then enter setup, do you really want to be back in the loader when you leave setup again? I think you'd really want to be in BASIC, so having a flag in the IO RAM which shadows whether we're in the loader or not might solve the problem.

 

Be nice if the action of ESC or X from SETUP would always return you to where you came from irrelevant of whether SDX was enabled. So if you came to SETUP directly from the LOADER, then you would return to the LOADER when ESC or X were issued in the SETUP screen. And vice versa if you came from either the DOS CL, or the Basic Prompt into SETUP, then that's where you would return instead. Don't know if there is an underlying mechanism that mandates the current method be used, but if not it would be great to see this changed. And if it can't be changed to what I have suggested, then perhaps it is better to have ESC and X always take you back to the DOS CL or Basic prompt, irrelevant if you came to SETUP from the LOADER.

I definitely wouldn't want to mandate a return to any particular place when coming out of setup. Ideally, we'd want to end up exactly where we started, as you suggest. Simply implementing the loader as a separate external cart at the board logic level would have made life so much easier, but there's nothing we can do about it now.

 

Separate topic related to CF Reset...

 

In the LOADER, CTRL+D executes this function, with out doing a visible reset of the Atari. However outside of the LOADER using the alternative SHIFT+RESET CF Reset does appear to do a system reset as well. Any reason for this? Be nice to have the more silent action like CTRL+D does in the LOADER. Is there a reason for the difference?

Yep, because the only way the PBI BIOS gets to see there's a hotkey held down is on system reset (and during SIO calls, but hotkeys during IO would be ugly as sin). The loader is issuing a card reset off its own back and then calling the SIO with the "refresh partition table" command.

 

No reason you couldn't have a small tool (as I think I mentioned previously) on the SDX CAR: drive which would reset the card without a system reset.

 

I noticed the effort put into state tracking of the U1MB via the TK-II, and while it's impressive I'm slightly unsure why it's necessary. Is this just so that you can have single-key assignments for what would normally be multi-key actions?

 

Caution is probably advisable, anyway, since a minor change to a BIOS key assignment or some other aspect of behaviour could upset everything. I'm not saying things will necessarily change at all, but it would seem to be something else to go wrong, so to speak.

Edited July 12, 2017 by flashjazzcat

[+mytek]

I definitely wouldn't want to mandate a return to any particular place when coming out of setup. Ideally, we'd want to end up exactly where we started, as you suggest. Simply implementing the loader as a separate external cart at the board logic level would have made life so much easier, but there's nothing we can do about it now.

 

That's cool. Just thought if this were an unknown bug that escaped your attention, that I would at least flag it's existence.

 

Yep, because the only way the PBI BIOS gets to see there's a hotkey held down is on system reset (and during SIO calls, but hotkeys during IO would be ugly as sin). The loader is issuing a card reset off its own back and then calling the SIO with the "refresh partition table" command.

I mainly brought up the 'system reset' aspect when doing CF Reset outside of the LOADER, just to be sure that this was normal behavior, although it would be nice if it was more subtle like the CTRL+D action in LOADER, it really isn't necessary.

 

I noticed the effort put into state tracking of the U1MB via the TK-II, and while it's impressive I'm slightly unsure why it's necessary. Is this just so that you can have single-key assignments for what would normally be multi-key actions?

 

Caution is probably advisable, anyway, since a minor change to a BIOS key assignment or some other aspect of behaviour could upset everything. I'm not saying things will necessarily change at all, but it would seem to be something else to go wrong, so to speak.

 

I really liked the idea of grouping commonly used U1MB multi-key assignments into a single group of Function key commands. I find it makes hoping around into the different aspects, and/or remembering what key does what much easier. I suspect that what looks unnecessary on the surface, would probably surprise many as to how handy it is in reality. However I do agree it is a bit dangerous since it doesn't have any real linkage to what's actually happening on the inside, and could perhaps get out of sync. And this was my biggest concern when I saw the different SETUP exit strategy's going on, since this could easily disrupt the CF Reset action (maybe that CAR resident command might be a better way to go if it can create a commonality in the CF Reset activation key ).

 

Some of the tracking also applies to other aspects such as executing Caps re-syncing when in TK's special Caps Mode, and also to allow the special Console key action to only occur when in SETUP. This stuff is unaffected by the U1MB exit strategy differences (assuming you use the shortcut keys).

 

I also just got done adding recognition of held keys on power-up, such as HELP or L that would launch directly into either the SETUP or the LOADER. And to be on the safe side, with some recent code changes I also handle a HELP+RESET entry into SETUP as well. Of course what I can't see is if someone has chosen to use a menu function instead of the shortcut keys, but I figure that's more of a learned aspect to what not to do if you want to take advantage of the single Function key equivalents. Of course no harm done if someone really wishes to do things as they would have done before, and just completely ignore the Function key equivalents altogether.

 

EDIT: Something really good came out of all this experimentation. I had been seeing unexplained instances in the past of the keyboard hanging and then resetting on the PIC's watchdog timer timing out. This was happening much more frequently after I added this new code, and got me suspecting that I had exceeded the PIC's hardware stack, so that it was loosing it's way back from nested macros. Sure enough once I implemented a software stack, all of these seemingly random resets stopped happening .

 

- Michael

Edited July 12, 2017 by mytekcontrols

[flashjazzcat]

That's cool. Just thought if this were an unknown bug that escaped your attention, that I would at least flag it's existence.

Yep - I appreciate that. I put so much effort into making the setup menu's exit behaviour predictable (simply being able to return to the underlying OS via ESC wasn't even possible before) that it might be worth going the extra mile with these corner cases, providing it's not a big headache.

 

I mainly brought up the 'system reset' aspect when doing CF Reset outside of the LOADER, just to be sure that this was normal behavior, although it would be nice if it was more subtle like the CTRL+D action in LOADER, it really isn't necessary.

Yeah: I understand. This was a illustration of the fact PBI-based code can't do much outside of system reset and SIO calls unless the PBI IRQ line is hooked up to something. If you hook a button up to the IRQ, you can trigger the PBI interrupt handler from anywhere you like providing IRQs are enabled.

 

I really liked the idea of grouping commonly used U1MB multi-key assignments into a single group of Function key commands. I find it makes hoping around into the different aspects, and/or remembering what key does what much easier. I suspect that what looks unnecessary on the surface, would probably surprise many as to how handy it is in reality. However I do agree it is a bit dangerous since it doesn't have any real linkage to what's actually happening on the inside, and could perhaps get out of sync. And this was my biggest concern when I saw the different SETUP exit strategy's going on, since this could easily disrupt the CF Reset action (maybe that CAR resident command might be a better way to go if it can create a commonality in the CF Reset activation key ).

I had a feeling that TK-II tracking was the reason these little idiosyncrasies were suddenly an issue. I can't fault you for the desire to make navigation easier, but I come down hard on the "keep it simple" side of the fence. Of course I can't ignore the fact that using a PC keyboard adds an extra level of abstraction ("Help" is now an F-Key, etc), although I've been testing the BIOS in Altirra for so long that pressing F5 while holding down F6 to simulate Help+Reset is second nature.

 

Of course what I can't see is if someone has chosen to use a menu function instead of the shortcut keys, but I figure that's more of a learned aspect to what not to do if you want to take advantage of the single Function key equivalents. Of course no harm done if someone really wishes to do things as they would have done before, and just completely ignore the Function key equivalents altogether.

Yeah: the discrepancy between menu items and function keys would have made me back away quietly, but if you've made it work in a way which doesn't trip up, great.

[flashjazzcat]

Right: I think I addressed the issue with the loader when SDX is disabled, although it was fiddly and will require testing to ensure it doesn't break anything else. The BIOS - when deciding whether to leave the SDX banking register open on reset as a "special case" (usually if the loader is launched or the GOS is active) - now checks for either bank of the loader being present at $A000-$BFFF if SDX is disabled in the config. If the loader ROM is present, the SDX ROM banking is left active.

 

Takes a bit of code space and also requires a change to the loader (ROM signature now has to appear in both banks), but it's probably a worthwhile fix. Usefully, it doesn't affect behaviour is the loader has already turned itself off (after loading an XEX, etc).

[+mytek]

Right: I think I addressed the issue with the loader when SDX is disabled, although it was fiddly and will require testing to ensure it doesn't break anything else. The BIOS - when deciding whether to leave the SDX banking register open on reset as a "special case" (usually if the loader is launched or the GOS is active) - now checks for either bank of the loader being present at $A000-$BFFF if SDX is disabled in the config. If the loader ROM is present, the SDX ROM banking is left active.

 

Takes a bit of code space and also requires a change to the loader (ROM signature now has to appear in both banks), but it's probably a worthwhile fix. Usefully, it doesn't affect behaviour is the loader has already turned itself off (after loading an XEX, etc).

 

Cool! I'll be more than happy to test this when you have it ready

 

- Michael

[flashjazzcat]

I'll be more than happy to test this when you have it ready

That's great: I'll post it here in a day or two when I've finished making a few other changes, so general testing will be most useful. I changed over to a simpler solution for the loader issue too: there's simply a flag is set whenever the loader is launched and which remains set until changes are saved which require a coldstart. If the flag is set, the SDX banking register remains open regardless of whether SDX is explicitly enabled in the BIOS. This seems to work well.

[+mytek]

Ok I'm ready on my end. Used the weekend to finish up my TK-II firmware updates, and everything is looking stable with my U1MB access tracking. Of course it still trips up on whether SDX is enabled or disabled causing different ESC (or X) exit strategies. So if your changes cure this, then I think all is good. I also have the two key SETUP entry HELP+RESET keys (F10+F8) tracked as well.

 

And while I was at it, also cleaned up some non U1MB related aspects in the code as well. So this latest version should be very nice.

 

- Michael

[+mytek]

I decided to rename this board. When this topic first began I was looking at creating an IDE interface to utilize the XEL MPBI, based loosely on the early MyIDE design. Then FlashJazzCat and I started talking and this led into the idea of him modifying the Incognito PBI BIOS to work from within the U1MB and recognize my board. Soon following that the board design began and it got a name 'XEL-I3' with I3 part standing for Incognito IDE Interface. As the project continued it migrated away from being a generic IDE interface, and instead focused on being a CF card interface. So with that in mind, I've decided to rename the board 'XEL-CF' which makes better sense.

 

So Jon if you read this post, I was wondering if you could modify the XEL-I3 PBI BIOS to be the XEL-CF PBI BIOS instead, and have it titled as such when the system is booting up?

 

Note: The next revision of the PCB will also get the name changed on it's silkscreen. That rev will also release the board manufacturing and design files into the public domain.

 

Thanks in advance,

- Michael

Edited August 18, 2017 by mytekcontrols

[flashjazzcat]

No problem. I'm testing the Incognito update at the moment (finally!), so I'll make that change tonight.

[+mytek]

Jon I just discovered a problem with the custom XEL BIOS, that I apparently missed until now. It concerns being able to disable VGATE from within setup. If I hit return, I can see it go to 'Disabled', but no matter how I exit setup it gets re-enabled. If you get a chance while debugging the CF aspects can you have look at this also?

 

Thanks

 

- Michael

[flashjazzcat]

Jon I just discovered a problem with the custom XEL BIOS, that I apparently missed until now. It concerns being able to disable VGATE from within setup. If I hit return, I can see it go to 'Disabled', but no matter how I exit setup it gets re-enabled. If you get a chance while debugging the CF aspects can you have look at this also?

 

I mentioned I'd run into this issue myself a month or so back and fixed it here. I think you said you hadn't come across it at the time.

[+mytek]

I mentioned I'd run into this issue myself a month or so back and fixed it here. I think you said you hadn't come across it at the time.

 

Yes I remember verifying that it did work at least a couple of times, but I think I only did a complete check on the first 2 maybe 3 versions of the xbios129 that you gave me. And by a complete check, that would be toggling the VGATE state in Setup, saving it ('B' exit from Setup), verifying this in reality (does the VGATE chip's operational state match it), and when going back into Setup, does the setting shown still match what it got previously set to.

 

So to make sure I wasn't going nuts, I went back through this thread and collected the different versions that incorporated specific menu changes that were XEL specific of which I found four. Then so that I could individually test each one, I renamed them to: xel129a-xel129d (here's the zip file containing all the versions: xbios129 Versions.zip).

 

xel129a June 27th 2017 First iteration incorporating XEL specific menu items

xel129b June 29th 2017 (#1) Added Power-On Delay

xel129c June 29th 2017 (#2) Included as part of full collection zip (I don't believe there were any changes from the previous one)

xel129d June 30th 2017 Latest version (reorganized the menu items based upon my request to place both Pokey related items together)

 

Then I tested each one using the criteria of the 'complete check'. The first 3 had full functionality, however the 4th (xel129d) was broken as far as VGATE toggling was concerned. So apparently having seen the toggling aspect working fine in the first 3 versions, I got lazy and didn't do the full check on the 4th and last version... sorry about that .

 

Just to add to this... I'm fairly certain that I did try toggling VGATE in the setup screen after flashing the last version, but didn't verify if it had really taken or not. Since I saw it toggling between Enabled and Disabled at the time it all looked good.

 

- Michael

Edited August 21, 2017 by mytekcontrols

[flashjazzcat]

I think it's this:

 

http://atariage.com/forums/topic/265525-xel-cf-compact-flash-adapter-for-1088xel-formerly-xel-i3/page-7?do=findComment&comment=3798417

 

Unfortunately the overloaded bit shared by VGATE was Rapidus On/Off, and Rapidus is the setting I mentioned (VGATE was "other") So I'm hardly surprised that was unclear and I don't think I even released the fix I mentioned yet.

[+mytek]

I think it's this:http://atariage.com/forums/topic/265525-xel-cf-compact-flash-adapter-for-1088xel-formerly-xel-i3/page-7?do=findComment&comment=3798417Unfortunately the overloaded bit shared by VGATE was Rapidus On/Off, and Rapidus is the setting I mentioned (VGATE was "other") So I'm hardly surprised that was unclear and I don't think I even released the fix I mentioned yet.

That's too funny... completely missed that one, probably due to my brain trying to digest all of the new info about plug-in's and also juggling too many balls. Hey but I did give you a like.

 

It looks like the fix mentioned never got released (as you presumed). So I will assume that will happen as part of a future update, or possibly in what you have been working on. As always I really appreciate your contributions to this project, and because words are never enough and don't keep the stomach full, expect another donation very soon.

 

- Michael

[flashjazzcat]

Yep: fixed ages ago but not sent/released yet. People are keeping me busy with hardware jobs, but at least I started testing the BIOS update over the weekend and I can sign it off as soon as I find four contiguous hours or so.

 

Many thanks for your kind words and generosity, as always!

[+mytek]

A new version of XEL-CF board has completed development, and will be going to the board house along with the 1088XEL v1.1 a bit later this week. The reason for the new design was due to reliability issues on the previous design (XEL-I3, renamed XEL-CF) directly associated with having a ribbon cable connection between it and the MPBI port on the 1088XEL. So a new approach was taken where the device will directly plug into the MPBI, and the ribbon cable connection has now been moved to the buffered side of the interface. This new version is called the XEL-CF-][.

2-part break-away PCB (CF connector carrier board panel mount adapter / XEL-CF-][ electronics interface)

Trial tests were conducted using the original XEL-I3 board, separating the normally sandwiched CF card/IDE44 adapter board, and then using a rather long 16" IDE44 cable to interconnect the two independent parts.



Test results with the long cable looked great!



These CF card to IDE44 adapter boards are readily available and cheap (just under $2).

IMPORTANT: Make sure that you are indeed getting a V.H2 version CF-IDE44 Adapter board. Specifically ask the seller. Reason being is that sometimes a seller will use this image of what they are supposedly selling, but instead send you an earlier version that does not have the 4 required board edge mounting holes (slots).

 

Problem is they don't lend themselves to right angle panel mounting, hence the reason for the extra break-away mounting board in the XEL-CF-][ PCB. Using this along with some 4-40 threaded right angle brackets (Keystone 621) solves the panel mounting problem.

- Michael

[+mytek]

I was playing around with a very old Crucial 128meg CF card today, which seemed to be working pretty good with the Side Loader, but when I pulled it and plugged it back in it was no longer recognized (no surprise). So I pressed the REFRESH key (F9) thinking that should solve the problem, but no dice. Then I did a reset, still nothing, and then jumped into the U1MB Setup and exited with 'C', after which I did another REFRESH. Still no good. Finally did a power down and back up after which all was once again good. So it looks like some of these old cards don't recognize a hardware reset. No biggie, but something to keep in mind.

 

- Michael

[+mytek]

NEW SCANNED IMAGES OF REAL PCB's

 

 

 

- Michael

[+mytek]

ASSEMBLED...

 

 

 

Note: The hole is to enable the use of a stand-off between the motherboard and the XEL-CF. An Insulated (nylon) stand-off is a must, since there is no clearance for a metal one. So unless you like electrical shorts between the top and bottom power planes, make sure you adhere to this.

 

 

 

 

Complete Package

 

- Michael

[Brentarian]

Looks good! Can't wait to try it!

[+mytek]

I found out you can't trust the photo's that are sometimes used when ordering parts from China via eBay. So here's the story... I ordered what I thought would be a CF-to-IDE44 adapter board with 4 mounting holes, the VH.2 version pictured on the left, but instead received a V.B1 version as shown on the right. Pretty big difference if you ask me.

 

 

Not only are the mounting holes different, but the VB.1 has a defective CF Activity LED circuit, so the LED doesn't even function. This is most likely why it got superseded by the VH.1 version.

 

Anyway I found a better place to purchase these from, and at a better price when ordering more than one piece. And I am happy to say I received the correct part when I placed a test order from them. AliExpress: Twenty-second Century Digital Store

 

This would be a good candidate for a group buy. I ordered 20 for a total of $28.60 ($1.43 each), but the discounted price does seem to vary, so it could be higher at times (presently I think it would come to $1.53 each).

 

- Michael

[+mytek]

Trying to do 60fps video playback, but so far failing. The only player version I could find that at least gets through the IDE reset and begins video playback is this one modified for the Incognito. To get the PAL TRON video from that same page onto my SanDisk Ultra 4gb CF card, I used Win32 Disk Imager under Windows 7 and it appeared to work well, reporting a successful write.

 

https://www.youtube.com/watch?v=LcVdo6YbFMs

 

It's trying, but not succeeding.

 

To add to this, it appears that the player is indeed pulling data off the CF card, but the output is scrambled.

 

- Michael

[ivop]

We have seen similar issues when booting the player from SIDE2 and then swapping cards for the video. When we booted the player over SIO with the right CF card already in place, everything worked well. It would be nice if the player reset the IDE bus after one presses a key, so you can properly swap cards. Not sure if this is your problem, but it might be worth a try.

[+mytek]

We have seen similar issues when booting the player from SIDE2 and then swapping cards for the video. When we booted the player over SIO with the right CF card already in place, everything worked well. It would be nice if the player reset the IDE bus after one presses a key, so you can properly swap cards. Not sure if this is your problem, but it might be worth a try.

 

I was running the player via SIO2PC, so there was no need to swap the CF card. And although the player said it did a reset and reported ok, I doubt very much that it truly did since the XEL-CF hardware reset function couldn't be mapped the same as Incognito (correction apparently Incognito has no such ability - see FJC's comment below).

 

I think it's safe to assume the Incognito player isn't resetting the CF card, but it won't do so on a real Incognito either since there's no card reset register. So in short, I'm not sure what's wrong aside from dropped reads (yes, the dreaded Phi2 clock issue).

 

I will try to do a manual reset of the CF card prior to initiating play to see if that helps. It'll have to be jury rigged to do so without causing a system reset. Fingers crossed that it hasn't anything to do with Phi2 clocking (or some other system timing problem).

 

- Michael

[+mytek]

Success!!!

 

https://www.youtube.com/watch?v=hVipK6ByOnc

 

Had to first jump into Basic to do a forced reset of the CF card at location 53696 ($D1C0). So it looks like a special version of the MOVPLAY.xex with this implemented will be the ticket.

 

- Michael