Jump to content

Photo

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

IDE CF Incognito XEL

194 replies to this topic

#176 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Wed Jul 12, 2017 12:00 PM

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 by flashjazzcat, Wed Jul 12, 2017 12:40 PM.


#177 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Wed Jul 12, 2017 12:41 PM

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  :ponder: ).

 

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 :thumbsup: .

 

- Michael


Edited by mytekcontrols, Wed Jul 12, 2017 12:48 PM.


#178 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Wed Jul 12, 2017 1:10 PM

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  :ponder: ).


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.

#179 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Fri Jul 14, 2017 11:33 AM

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).

#180 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Fri Jul 14, 2017 12:21 PM

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



#181 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Sat Jul 15, 2017 2:03 PM

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.

#182 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Tue Jul 18, 2017 12:05 AM

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

#183 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Fri Aug 18, 2017 2:49 AM

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 by mytekcontrols, Fri Aug 18, 2017 3:04 AM.


#184 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Fri Aug 18, 2017 3:20 AM

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

#185 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Sun Aug 20, 2017 7:31 PM

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



#186 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Mon Aug 21, 2017 2:59 AM

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.

#187 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Mon Aug 21, 2017 2:11 PM

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: Attached File  xbios129 Versions.zip   39.37KB   14 downloads).

 

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 by mytekcontrols, Mon Aug 21, 2017 2:24 PM.


#188 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Tue Aug 22, 2017 6:14 AM

I think it's this:

http://atariage.com/...-7#entry3798417

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. :)

#189 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Tue Aug 22, 2017 6:33 AM

I think it's this:http://atariage.com/...-7#entry3798417Unfortunately 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

#190 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,593 posts
  • Location:United Kingdom

Posted Tue Aug 22, 2017 6:53 AM

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!

#191 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Wed Aug 30, 2017 12:16 AM

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)

UQMA78f.png
 
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.
 
5sVdEPE.jpg
 
Test results with the long cable looked great!
 
xIjrP3U.jpg
 
These CF card to IDE44 adapter boards are readily available and cheap (just under $2).
 
nhsn8ZE.jpg
 

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



#192 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Sat Sep 2, 2017 10:08 PM

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

#193 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Mon Sep 11, 2017 6:21 PM

NEW SCANNED IMAGES OF REAL PCB's

 

YFZxoZA.jpg

 

IuD4LcA.jpg

 

- Michael



#194 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,012 posts
  • Location:Santa Rosa, CA

Posted Mon Sep 18, 2017 2:28 PM

ASSEMBLED...

 

VWFjojw.jpg

 

Gl2AyqZ.jpg

 

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.

 

GVRatBG.jpg

 

cSUWFUA.jpg

 

9IPI7L9.jpg

 

Complete Package

aE5rF0M.jpg

 

- Michael



#195 Brentarian ONLINE  

Brentarian

    Moonsweeper

  • 300 posts
  • Location:Columbus, Georgia USA

Posted Mon Sep 18, 2017 2:55 PM

Looks good! Can't wait to try it!





Also tagged with one or more of these keywords: IDE, CF, Incognito, XEL

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users