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

[flashjazzcat]

The PBI driver has some rudimentary error detection in as much as it attempts to catch DRQ being high after the last byte of a sector is transferred or it going low before the last byte is transferred. In either case, a retry is performed (up to five attempts). It seems unlikely that this is masking errors which would mess up the loader, but I suppose it's possible.

 

Since I have three SIDE2 carts and four U1MB machines here, I'd appreciate the chance to test a copy of the FAT partition.

[flashjazzcat]

Here's the same v.1.29 main BIOS with an XEL-I3 plugin which hopefully has the proper IO pin assignments as described in the other thread. If not, they're easily changed.

 

Ultimate 1MB BIOS v.1.29 with XEL-I3 Plugin.zip

 

 

 

 

S0 = VGATE-ENABLE

S1 = 2nd POKEY IRQ-ENABLE

M0 = POKEY-STEREO

PS: Should probably sense-test the 2nd Pokey IRQ control at startup and grey it out if it's not connected, but I'm assuming this isn't possible with VGate.

PPS: Disabling the IRQ on the second Pokey will break second Pokey detection, so we'll have to first enable 2nd IRQ, test for stereo Pokey, then disable the 2nd IRQ and test for Pokey again to establish whether S1 is connected.

Edited June 27, 2017 by flashjazzcat

[+mytek]

The PBI driver has some rudimentary error detection in as much as it attempts to catch DRQ being high after the last byte of a sector is transferred or it going low before the last byte is transferred. In either case, a retry is performed (up to five attempts). It seems unlikely that this is masking errors which would mess up the loader, but I suppose it's possible.

 

Since I have three SIDE2 carts and four U1MB machines here, I'd appreciate the chance to test a copy of the FAT partition.

 

I just verified that both CF cards work fine in the SIDE2 with the SIDE BIOS in the U1MB. So apparently there is nothing corrupted with the FAT on either card. Do you still want a copy of the FAT? And if so, how specifically would you like that to be done?

 

But here's the good news. If I disconnect the CF RES line from the /$D1Cx decoded output and reconnect it to +5V as it was originally, all is fine. Getting an O-Scope on the 74AC138's output for the CF reset line shows us a very short term low going spike occurring when doing disk access. I've tried simply putting a capacitor across this output and ground, but in order to squelch the spike, we also squelch the reset pulse when it is actually desired. Probably could extend the reset command in the xPBI BIOS to get past this, but first I would like to try changing from a 74AC138 as it is now over to a slower HCT part instead.

 

 

EDIT: I'm connected to Channel 1

 

- Michael

Edited June 27, 2017 by mytekcontrols

[flashjazzcat]

Do you still want a copy of the FAT? And if so, how specifically would you like that to be done?

Since it's a hardware issue, I guess I don't need the FAT. But I'll take a copy anyway if you don't mind since it looks ideal for general testing (several levels of directory nesting and plenty of files). Just zipping up the content of the FAT as files would be fine. I could then copy them to a card here. Only if it's no trouble, though.

[+mytek]

Changing all the IC's to their HCT equivalent seems to have done the trick (they were all originally 74AC high speed parts). Both aspects (Loader and APT access) are now working properly. And the sacrifice in logic speed capability doesn't seem to be an issue.

 

RWCRC --- PASSED

 

 

RWTEST --- Not sure how best to evaluate these results

 

 

How does the RWTEST compare to a SIDE2?

 

- Michael

[flashjazzcat]

RWTEST result is fine: same as SIDE.

[+mytek]

Since it's a hardware issue, I guess I don't need the FAT. But I'll take a copy anyway if you don't mind since it looks ideal for general testing (several levels of directory nesting and plenty of files). Just zipping up the content of the FAT as files would be fine. I could then copy them to a card here. Only if it's no trouble, though.

 

I tried to upload a zipped copy in a PM to you, but no dice (too big). So I just emailed you a 'share' link to my DropBox where I temporarily stashed it. Let me know when you download it, so that I can delete it and recover the space.

 

- Michael

[+mytek]

 

Here's the same v.1.29 main BIOS with an XEL-I3 plugin which hopefully has the proper IO pin assignments as described in the other thread. If not, they're easily changed.

 

Ultimate 1MB BIOS v.1.29 with XEL-I3 Plugin.zip

 

bios.png

 

bios2.png

 

bios3.png

 

S0 = VGATE-ENABLE

S1 = 2nd POKEY IRQ-ENABLE

M0 = POKEY-STEREO

PS: Should probably sense-test the 2nd Pokey IRQ control at startup and grey it out if it's not connected, but I'm assuming this isn't possible with VGate.

PPS: Disabling the IRQ on the second Pokey will break second Pokey detection, so we'll have to first enable 2nd IRQ, test for stereo Pokey, then disable the 2nd IRQ and test for Pokey again to establish whether S1 is connected.

 

 

I just checked this out, and it appears to be working well with the 1088XEL hardware

 

However I think the menu item XEL-I3 Vgate should actually be GTIA Vgate instead since it is directly built into the 1088XEL motherboard and not associated with the XEL-I3 CF Adapter board. And yes there is no way to know if the Vgate hardware exists, but since this is a 1088XEL specific U1MB BIOS it doesn't matter because it isn't optional hardware. EDIT: maybe swap menu line positions for this and the 2nd Pokey IRQ, so that both Pokey items are next to each other.

 

With all of your custom changes, this is going to be real slick

 

Thank you,

- Michael

Edited June 27, 2017 by mytekcontrols

[flashjazzcat]

Many thanks for the ZIP file. Downloaded, so you can delete it now.

 

I'll make the specified changes to the plugin and upload the source code here (may be useful to those interested in writing plugin modules).

[+mytek]

Sounds like a plan. I'll be looking for the next download, with it likely being the last piece to the puzzle.

 

When I first embarked on this latest project, it was initially based on the simple version of MyIDE by Mr Atari himself. I remember reading how he went from 74LS to 74F chips because of perceived reliability issues, which I think really related more to other concerns and hence the incorporation of the 373 address latch circuit that came about later on. So still thinking that high speed logic was required, I went with 74AC parts as a compromise between speed vs power requirements. Now I'm rethinking that strategy, and will most likely be using all 74HCT parts instead. Higher speed parts should only be used where absolutely required, due to the other issues they raise.

 

- Michael

[flashjazzcat]

The only area where the speed of IO could vary is waiting for DRQ to go high after issuing a command. Everything else is governed by the speed of the host CPU, so I guess stability is more important than response time when it comes to IDE.

[flashjazzcat]

BTW: Are we gonna stick Rapidus enable on M1 in the standard XEL-I3 plugin?

[+mytek]

BTW: Are we gonna stick Rapidus enable on M1 in the standard XEL-I3 plugin?

I don't see why not, since this seems to be the most likely usage for now. And if a future MPBI device needs it instead (assuming no Rapidus installed), I would assume a different plug-in could be written.

 

- Michael

[flashjazzcat]

I don't see why not, since this seems to be the most likely usage for now. And if a future MPBI device needs it instead (assuming no Rapidus installed), I would assume a different plug-in could be written.

Yep - no problem. Very often it's just a case of changing the menu text, menu number, or reversing the logic.

[+mytek]

Jon in the main BIOS is it possible to extend the time period that the U1MB looks for the HELP key to be pressed during power up, in order to go straight into Setup? Reason I ask is that I have been trying to allow for this in the latest rev of the TK-II firmware by having it extend the system reset on power up, so as to give the PS2 keyboard a chance to initialize so that it's key presses are seen during the Cold Boot. First attempt works, but requires in my opinion that I hold the reset condition too long, adding many seconds before the U1MB is allowed to begin it's boot up. I have an even newer version with a much shorter delay which still allows held keys like Option or Start to be seen and acted upon during the power up phase, but unfortunately U1MB no longer sees a held Help key. It looks to me like if the U1MB were to keep looking for a couple of seconds (probably 2 seconds max required or about as long as the splash screen is present), that the keyboard would be fully initialized and able to send the held Help key, thus being seen by the U1MB.

 

- Michael

Edited June 29, 2017 by mytekcontrols

[flashjazzcat]

So are you saying that the TK-II keyboard isn't ready by the time the splash screen has disappeared? Or is a 2 second delay required before Pokey is initialised and prior to the splash screen even appearing (if enabled)? Can you get into BIOS setup via the Start key (BIOS Settings -> BIOS menu key -> Start)?

[+mytek]

So are you saying that the TK-II keyboard isn't ready by the time the splash screen has disappeared? Or is a 2 second delay required before Pokey is initialised and prior to the splash screen even appearing (if enabled)? Can you get into BIOS setup via the Start key (BIOS Settings -> BIOS menu key -> Start)?

 

So basically this is the sequence of events being controlled by TK-II...

1. Reset line held low for 2 seconds, then released (allowing power stabilization under load and ignoring keyboards while they run self diagnostics)
2. Reset command sent to PS2 keyboard ports 1 & 2
3. Waiting for responses and setting flags for active keyboard(s) (250 milliseconds)
4. LED update command sent to PS2 keyboard(s) (max 150 milliseconds if two keyboards are present)
5. Wait 300 milliseconds, then repeat item 4 (required by some keyboards to initialize properly)
6. Keyboard key presses now available to Atari

Following system reset, while U1MB and the Atari is now allowed to boot up, approximately 700 milliseconds of that actual boot up time the keyboard(s) are not active, so holding the Help key (or any key) can not be seen by the Atari during that time period. Or in other words nearly a second into the actual boot process no held key presses can be seen. This apparently is too late for the U1MB to act on a held Help key and jump directly into the setup screen. However the Atari OS is still able to process Start and Option keys held before making the decision of doing a cassette load or a Basic disable before the boot process finishes, so that aspect does work.

 

So ignoring the 2 second held system reset, since for all practically purposes the Atari or the U1MB haven't yet started, we are looking at nearly 1 second before key presses can be seen by the U1MB (which from what I am seeing, I'll assume that is too late).

 

Not sure what you exactly mean by using the Start key instead, isn't that reserved for initiating a cassette load? Or are you saying to change it from the Help key to the Start key in the U1MB setup? So if I interpret that correctly, since held console keys (processed by GTIA) appear to be recognized by the OS in spite of the keyboard delay, using one of them as the substitute for Help (which goes through Pokey) should also work to launch the U1MB setup. I'll have to try that But will that change the Help+RESET hot key sequence to launch Setup when not in boot-up?

 

- Michael

 

EDIT: I know this discussion about the TK-II might seem a little off topic, but since we have been working on special U1MB BIOS for XEL-I3 integration, as well as the 1088XEL (which has the TK-II integrated), it seemed appropriate due to the BIOS changes that are already ongoing to support these products.

Edited June 29, 2017 by mytekcontrols

[flashjazzcat]

Following system reset, while U1MB and the Atari is now allowed to boot up, approximately 700 milliseconds of that actual boot up time the keyboard(s) are not active, so holding the Help key (or any key) can not be seen by the Atari during that time period. Or in other words nearly a second into the actual boot process no held key presses can be seen. This apparently is too late for the U1MB to act on a held Help key and jump directly into the setup screen. However the Atari OS is still able to process Start and Option keys held before making the decision of doing a cassette load or a Basic disable before the boot process finishes, so that aspect does work.

 

So ignoring the 2 second held system reset, since for all practically purposes the Atari or the U1MB haven't yet started, we are looking at nearly 1 second before key presses can be seen by the U1MB (which from what I am seeing, I'll assume that is too late).

Right: I think I follow now. This is similar to the short delay required for the old VBXE 1.x to start up. Would simply spinning on an extra one second delay before doing anything at all (initialising Pokey, bringing up the display, etc) work? I don't think that will impact on the user experience too much, although it will require modification to the base code (it can't be handled via a plugin).

 

Not sure what you exactly mean by using the Start key instead, isn't that reserved for initiating a cassette load? Or are you saying to change it from the Help key to the Start key in the U1MB setup? So if I interpret that correctly, since held console keys (processed by GTIA) appear to be recognized by the OS in spite of the keyboard delay, using one of them as the substitute for Help (which goes through Pokey) should also work to launch the U1MB setup. I'll have to try that But will that change the Help+RESET hot key sequence to launch Setup when not in boot-up?

This is exactly what I mean: going into BIOS setup and setting the hotkey to Start instead of Help. It's a direct substitution in all areas, so will get you into the BIOS on power-up, cold-restart or system reset. As for the cassette: well, you'd have to be quick off the mark to use it, but a) who cares, and b) that's why it's user configurable. IDE Plus 2.0 also uses Start+Reset to enter setup.

 

EDIT: I figured out how to put the power-on delay in the plugin header and use the default value (eight frames) if an older plugin is used.

Edited June 29, 2017 by flashjazzcat

[+mytek]

This is exactly what I mean: going into BIOS setup and setting the hotkey to Start instead of Help. It's a direct substitution in all areas, so will get you into the BIOS on power-up, cold-restart or system reset.

Just tried substituting Start as the BIOS menu key and that didn't work either, so I guess that means the OS key service routines wait a bit longer than the U1MB. And to tell you the truth I'd much rather leave the hot key as Help (the default) if at all possible.

 

EDIT: I figured out how to put the power-on delay in the plugin header and use the default value (eight frames) if an older plugin is used.

That sounds encouraging Just so that I am understanding correctly, you aren't actually talking about delaying the U1MB boot-up, because if you are, that would not be desirable. However if you are merely delaying how long the U1MB will look for the BIOS menu key before moving on, that would be what I need.

 

- Michael

[flashjazzcat]

I thought the objective was to wait for the TK-II to initialise before we attempted to read the keyboard. The way the BIOS works:

 

* Initialise hardware (Pokey reset, etc)

* Power-on delay

* Check the keyboard and console keys in case user powered on with hotkey pressed

* If splash screen enabled, display it and poll keyboard for while splash screen is displayed

* If no key pressed during splash screen timer period or if splash screen is off, boot OS

 

I take it you're finding that Start doesn't work when pressed via TK-II PS2 keyboard? If so, and if we're waiting for the TK-II firmware to come up, a delay seems to be what we need? The only other method is to make a polling loop outside of the splash screen on cold power-on, but this would require quite a lot of changes and would need a custom BIOS build.

[flashjazzcat]

Try this:

 

xbios129_with_poweron_delay.zip

 

This is the same BIOS as previously uploaded but with a 64 frame power-on delay instead of the default eight.

 

The way I see it, if we have to wait around for the TK-II to initialise the keyboard anyway, it's pointless extending the keyboard polling loop since no key will register for the first second of that polling period anyway. So an empty delay does exactly the same job.

[+mytek]

Yes we are waiting for the keyboard to talk to us, but that happens pretty soon into the U1MB splash screen. If you check out this video you'll see what I mean (hopefully).

 

PS2 Keyboard Equates: F5=START, F7=OPTION, F10=HELP

 

https://www.youtube.com/watch?v=32SlKnlMQ7I

 

So the first test was to see if holding the HELP key (F10) on power-up will get us into the U1MB Setup menu. As can be seen by observing the NumLock LED, the keyboard is ready pretty soon after the U1MB splash screen appears, but the HELP key is ignored. However when holding either START (F5) or OPTION (F7) the OS does see the held keys and responds accordingly.

 

So what I was thinking... instead of delaying the U1MB boot-up, instead can it recognize the HELP key further into that boot-up process? And just so you know, this whole launch into U1MB Setup on power-up isn't a big deal in my book, so if this is any kind of hassle to implement then don't worry about it. I don't really want add any delay that isn't absolutely necessary into the boot-up process, and the only reason that I have added a bit is to insure that the switching PSU has a chance to stabilize (some are worse than others), and that we can do the load cassette or disable Basic aspects during power-up. So that has already been accomplished. Anything else is icing on the cake

 

- Michael

 

EDIT: I'll try that new BIOS you just uploaded while I was writing this post, and see how that looks.

Edited June 29, 2017 by mytekcontrols

[flashjazzcat]

I have no idea why Help isn't registering during the splash-screen period since as we all know, any A8 can be powered up with the Help key pressed and we jump directly into the BIOS menu. Maybe Pokey sees the initialisation sequence a little differently when TK-II is involved.

 

Anyway: see my previous comments about the first second of an extended polling loop being a waste of time and try the BIOS I posted and see if it works.

 

Even putting the power-on delay value in the plugin header seems kludgy to me, but I'm sure we'll figure something out. Note also that the splash-screen is entirely optional so we shouldn't depend on that for timing considerations. It's all about what happens during the "black-screen" phase before anything is displayed.

 

I remember internally mounted SIO2IDE devices required reset to be asserted for a longer period of time on cold-powerup to enable the Atari to boot from a mounted ATR. It's a shame reset can't simply be asserted long enough for everything to be up and ready by the time the 6502 initialises.

Edited June 29, 2017 by flashjazzcat

[+mytek]

I have no idea why Help isn't registering during the splash-screen period since as we all know, any A8 can be powered up with the Help key pressed and we jump directly into the BIOS menu. Maybe Pokey sees the initialisation sequence a little differently when TK-II is involved.

 

Anyway: see my previous comments about the first second of an extended polling loop being a waste of time and try the BIOS I posted and see if it works.

 

Even putting the power-on delay value in the plugin header seems kludgy to me, but I'm sure we'll figure something out.

 

Just tested it, and didn't see any difference

 

Like I said this is not a deal breaker, and I don't want you to worry about it, or have to spend a lot of time on it. But with that said, I am more than willing to test out anything you throw at me

 

- Michael

[flashjazzcat]

Just tested it, and didn't see any difference

I take it you mean no difference regarding keyboard behaviour. There's a delay of over one second on power-up in this build which isn't in the original. The screen remains black for over a second after the power comes on.

 

It seems odd that pushing back the point at which the keyboard is scanned doesn't make any difference. Is TK-II doing something odd to Pokey? First thing the BIOS does (before any delays) is initialise Pokey and PIA.