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

[Van]

Such a list was posted here some time ago (so it may not be complete). If I find it, I'll post the link in this thread.

 

I can't find it now.

I bookmarked this a while ago, http://atariage.com/forums/topic/157241-list-of-hardware-registers/It might help.

 

$D100 - $D1FF PBI

$D100 - $D107 MyIDE Internal

$D100, $D104, 1400XL/1450XLD Modem, Voice and Disk interface

$D108, $D110 "

$D114 "

$D170 - $D171 BlackBox

$D17C, $D1BC "

$D1BE, $D1C0 "

$D1C0 - $D1C1 SmartIDE LCD

$D1E0 - $D1E3 MIO

$D1FF PBI Device Enable / IRQ Mask

[+mytek]

I bookmarked this a while ago, http://atariage.com/forums/topic/157241-list-of-hardware-registers/It might help.

 

Nice

 

Well it looks like I'm only in conflict with the SmartIDE and the MIO. Not really a serious problem since mine is also a HDD solution. And nothing really permanent anyway, since a person could always re-flash a different PBI ROM, pull my board, and you're back in business. And actually no surprise that most stuff on that list is aimed at being an HDD solution first and foremost. This seems to be the common theme in PBI devices, and what the PBI is obviously well suited for.

 

Thanks Van.

 

- Michael

[+mytek]

Ok perhaps $D1C0-7 isn't the best place for the CF Reset to be mapped to out of the available choices I have from the on-board 138 decoded outputs. I also missed a few possibilities and misplaced a few others on that first posted allocation list I did (too much Sangria that day ). So here is an updated and correct memory map of that chip in the XEL-I3.

 

Note: each one of these covers 8-bytes ($D1x0-$D1x7)

 

/Y0 = $D10x
/Y1 = $D12x
/Y2 = $D14x

/Y3 = $D16x

/Y4 = $D18x
/Y5 = $D1Ax
/Y6 = $D1Cx
/Y7 = $D1Ex (dedicated to the 8 IDE registers)

 

And here are some known $D1xx allocations from that list that Van posted earlier...

 

$D100 - $D1FF PBI
$D100 - $D107 MyIDE Internal
$D100, $D104, 1400XL/1450XLD Modem, Voice and Disk interface
$D108, $D110 "
$D114 "
$D170 - $D171 BlackBox
$D17C, $D1BC "
$D1BE, $D1C0 "
$D1C0 - $D1C1 SmartIDE LCD
$D1E0 - $D1E3 MIO
$D1FF PBI Device Enable / IRQ Mask

 

If we ignore the $D1Ex allocation which is already in use by the XEL-I3 for it's IDE registers, this appears to leave the following possibilities free and clear...

 

$D12x

$D14x

$D16x

$D18x

$D1Ax

 

So Jon any input on this? Out of the 5 possible (non-conflicting???) mappings for the CF Reset, which one do you think looks to be the best bet?

 

- Michael

Edited June 22, 2017 by mytekcontrols

[flashjazzcat]

What's the problem with $D1Cx?

[+mytek]

What's the problem with $D1Cx?

 

It does appear to be used by the BlackBox. So I was just thinking that it might be possible to co-exist with that device if I stayed out of it's territory. But I must admit to being quite a newbie (or simply uniformed) when it comes to PBI device conflicts.

 

Edit: I have no problems with sticking with $D1Cx as I have it now, but if there is a better choice now's the time to lock it down

 

- Michael

Edited June 22, 2017 by mytekcontrols

[ivop]

If I'm not mistaken, a well behaved PBI device should be completely invisible if it is not selected through $D1FF. I don't know if the Blackbox or SmartIDE LCD work that way. I do know that the internal MyIDE is just a relocated cartridge and is always visible.

[flashjazzcat]

This isn't a PBI device, though: it's the U1MB PBI ROM which is the (internal) PBI device. We're simulating Incognito, whose IDE controller sits at the same address regardless of whether the PBI ROM is selected. Remember also that the XEL-I3 can be used on a non-U1MB machine via a custom OS or SDX driver.

 

I don't think BB was too observant of other external devices, so I wouldn't worry too much about that.

[+mytek]

This isn't a PBI device, though: it's the U1MB PBI ROM which is the (internal) PBI device. We're simulating Incognito, whose IDE controller sits at the same address regardless of whether the PBI ROM is selected. Remember also that the XEL-I3 can be used on a non-U1MB machine via a custom OS or SDX driver.

 

I don't think BB was too observant of other external devices, so I wouldn't worry too much about that.

 

Sounds good So I'll stick with $D1Cx as the CF Reset.

 

- Michael

[+mytek]

So these were the good old days of having a HDD on your A8...

 

Supra's Hard Disk for XL/XE Review by Les Ellingham

 

 

That's about $950.00 or $47 per megabyte of storage back in the day. In today's dollars it would cost $1,777.00 ($89 per megabyte).

 

Just doing a parts cost estimate on the XEL-I3 including a 4GB CF card, total comes to $25 or $.00625 per megabyte. Just a tiny bit less

 

- Michael

Edited June 22, 2017 by mytekcontrols

[+mytek]

XEL-I3 Updated Test Program incorporating CF Hardware Reset at $D1Cx

10 IDEPRNT=500:REM IDE PRINT ROUTINE
20 IDE=53728:REM IDE BASE ADDRESS
30 RES=53696:REM HARDWARE RESET
50 FEAT=239:REM SET FEATURE COMMAND
60 ID=236:REM IDENTIFY COMMAND
70 REM ----- DRIVE RESET -----
80 POKE RES,0
90 FOR DLY=1 TO 250:NEXT DLY
100 REM ----- DRIVE SET-UP -----
120 POKE IDE+1,1:REM SET 8-BIT MODE
130 POKE IDE+7,FEAT
140 POKE IDE+7,ID
150 REM ----- MAIN PROGRAM LOOP -----
160 FOR X=0 TO 255:DLSB=PEEK(IDE):DMSB=PEEK(IDE)
170 IF X=10 THEN ? "S/N: ";
180 IF X>9 AND X<20 THEN GOSUB IDEPRNT
190 IF X=23 THEN ?  "REVISION: ";
200 IF X>22 AND X<27 THEN GOSUB IDEPRNT
210 IF X=27 THEN ?  "MODEL   : ";
220 IF X>26 AND X<47 THEN GOSUB IDEPRNT
230 IF X=48 THEN ? 
240 NEXT X
250 END 
500 REM ----- PRINT ROUTINE -----
510 ? CHR$(DMSB);
520 ? CHR$(DLSB);
530 RETURN

Program File: IDETEST.BAS

 

- Michael

[+mytek]

Jon (FlashJazzCat) now that the choice of memory location has been tested and locked in for doing the CF Reset, can this be coded into the SHIFT+RESET partition refresh command of the U1MB? I'm also curious as to where that is done, Main BIOS or PBI BIOS?

 

I know you're a busy guy, so I don't expect you to drop everything to do this, but I'm hoping that it's at least on your radar. BTW, thank you very much for having made this project even possible by the recoding you've already done on the PBI BIOS to work with the XEL-I3.

 

On a separate subject, although still related to the XEL-I3, do you know if there is a program that can do a rigorous test of this interface? Reason I ask has to do with selection of the delay capacitor on the address latch, which allows for better compatibility and diversity in the choice of CF Cards that can be used.

 

- Michael

Edited June 23, 2017 by mytekcontrols

[flashjazzcat]

Jon (FlashJazzCat) now that the choice of memory location has been tested and locked in for doing the CF Reset, can this be coded into the SHIFT+RESET partition refresh command of the U1MB? I'm also curious as to where that is done, Main BIOS or PBI BIOS?

 

I know you're a busy guy, so I don't expect you to drop everything to do this, but I'm hoping that it's at least on your radar. BTW, thank you very much for having made this project even possible by the recoding you've already done on the PBI BIOS to work with the XEL-I3.

No problem Michael! I was going to sort this out last night, but I got side-tracked diagnosing audio-in noise on this crappy PC. I'll make the changes this evening.

 

On a separate subject, although still related to the XEL-I3, do you know if there is a program that can do a rigorous test of this interface? Reason I ask has to do with selection of the delay capacitor on the address latch, which allows for better compatibility and diversity in the choice of CF Cards that can be used.

I did write a low-level hardware test some years ago, but the source is probably lost now. Stuff like RWCRC (from Drac030's site) is useful for stability testing, but since the test goes through the file system, hardware problems can be obfuscated by any error-correction in the BIOS (for instance, a double read might trigger a retry in the BIOS if DRQ went low after byte 511 was read). I was thinking that it might be useful to build something around the FDISK/UFLASH UI which did a low-level test of the drive (raw speed, data integrity, etc).

 

But RWCRC offers a good real-world indication of whether the thing works properly, since most of the time we're going through the SIO anyway. There are some cases when the loader will trip up even after an RWCRC pass, but that's because the loader has zero retry logic (hardware has to be 100 per cent there). Usually a 74LS08 swap or different CF card irons out those problems.

[flashjazzcat]

Here's a main BIOS with the Ctrl-left/right key bug fix and an XEL-I3 PBI ROM with the hardware reset code:

 

XEL_I3.zip

 

As usual, the PBI code is largely untested so please let me know about any issues.

 

During the live stream I did when making the changes, I realised the XEL-I3 loader could do with a reset/refresh facility so a newly inserted card could be handled without resetting the machine. I got so far with that but will continue with it later on.

 

Another idea: a tiny executable (which could be kept on the SDX CAR: device) which resets a newly inserted card right at the command prompt.

 

PS: for both SIDE and XEL-I3, my hardware reset delay is approx. 1/2 second. Do you know off-hand the minimum reset response time for CF devices? I wondered if this could be shortened at all, since the code runs on every system reset. I can check the ATA docs later... I'm assuming there were reasons for such a long delay, but who knows (code was written years ago).

Edited June 24, 2017 by flashjazzcat

[+mytek]

Here's a main BIOS with the Ctrl-left/right key bug fix and an XEL-I3 PBI ROM with the hardware reset code:

 

XEL_I3.zip

 

As usual, the PBI code is largely untested so please let me know about any issues.

 

During the live stream I did when making the changes, I realised the XEL-I3 loader could do with a reset/refresh facility so a newly inserted card could be handled without resetting the machine. I got so far with that but will continue with it later on.

 

Another idea: a tiny executable (which could be kept on the SDX CAR: device) which resets a newly inserted card right at the command prompt.

 

PS: for both SIDE and XEL-I3, my hardware reset delay is approx. 1/2 second. Do you know off-hand the minimum reset response time for CF devices? I wondered if this could be shortened at all, since the code runs on every system reset. I can check the ATA docs later... I'm assuming there were reasons for such a long delay, but who knows (code was written years ago).

 

Thanks Jon

 

I'm away from my shop and my laptop's USB port needs a powered USB Hub to work properly at even moderate speed increases on the SIO2PC-USB, so hopefully I'll be able to pick up something locally since I'm up in the mountains for the weekend. However I did run some tests on delays required after resetting the CF cards and with the delay loop I posted below (in Altirra 1.51 Basic) a minimum of 123 seems to work well with both of my Sandisk Ultra 4GB cards. Not sure what that translates into in reality, but my intuitive guess would say around 1/4 second.

70 REM ----- DRIVE RESET -----
80 POKE RES,0
90 FOR DLY=1 TO 123:NEXT DLY

Of course this could vary with different CF cards, so perhaps 1/2 a second would be the better safer way to go.

 

Hope that helps.

 

- Michael

[flashjazzcat]

Of course this could vary with different CF cards, so perhaps 1/2 a second would be the better safer way to go.

Sounds good to me: I'll leave it as it is.

 

Just trying to figure out the most economical way to re-use existing code in the loader to fall into a re-read of the default FAT partition when the reset function is invoked.

[+mytek]

Sounds good to me: I'll leave it as it is.

 

Just trying to figure out the most economical way to re-use existing code in the loader to fall into a re-read of the default FAT partition when the reset function is invoked.

 

First of all let me say that the latest version of the Main BIOS with the CTRL+Arrow key fix in sub menus looks good

 

Secondly the CF Reset/Partition Table Refresh is also good

 

And at this point everything still looks very solid and is working well for HDD access

 

But... now with that stuff done, I spent some more time with the xloader and sad to say there appears to be a problem with it loosing its way, end result corrupted directories (see video below).

 

https://www.youtube.com/watch?v=-2FkvhJ7ze0

 

Sorry I didn't spot this sooner, but the APT access was more on my mind initially. It's really quite strange since sometimes all appears ok, and I can launch whatever game I am hovering over in the menu. But then if I back out things start to go bad, although sometimes it goes bad as I'm drilling down. There's no apparent logic as to how you can once again get a good directory listing, or at least none that I discovered (tried power-up reboot, SHIFT+RESET, hop into Setup and then reboot from there). Very random.

 

Hmm... 2nd CF card seems better behaved, although only some of the games will load and execute, but at least I'm not seeing as many directory problems. Maybe this is simply the result of me playing around earlier with FDISK adding then deleting partitions on both of these CF Cards. Could have inadvertently corrupted the FAT32 Perhaps I'll try reformatting the FAT when I get back home and reload the games. Note to self: should have left one CF Card alone, and not messed with it .

 

- Michael

[flashjazzcat]

Yeah: it doesn't look like there's much rhyme or reason to the problem, so I would advise two things before we start looking for bugs:

 

1) Try the same card in SIDE2 with the original U1MB loader

2) Make a dump of the card contents so we can test it in Altirra (thus ruling out hardware glitches)

 

EDIT: actually, looking at it, it doesn't look like the card is in 8-bit mode when the directories become corrupt.

Edited June 25, 2017 by flashjazzcat

[+mytek]

Yeah: it doesn't look like there's much rhyme or reason to the problem, so I would advise two things before we start looking for bugs:

 

1) Try the same card in SIDE2 with the original U1MB loader

2) Make a dump of the card contents so we can test it in Altirra (thus ruling out hardware glitches)

 

EDIT: actually, looking at it, it doesn't look like the card is in 8-bit mode when the directories become corrupt.

 

As per item 1: Don't have a SIDE2 with me, so that test will have to wait until later.

Also don't have a CF reader with me either.

 

What makes you suspect that its not in 8-bit mode?

 

- Michael

[Brentarian]

Michael, I have an extra SIDE2 cartridge I can send you to use while testing. Just say the word!

[+mytek]

Michael, I have an extra SIDE2 cartridge I can send you to use while testing. Just say the word!

 

No need to do that. I do have a SIDE2, but it's just not with me where I am at this weekend. When I get home later this evening, I'll be able to run that test. But thanks for offering

 

- Michael

[flashjazzcat]

As per item 1: Don't have a SIDE2 with me, so that test will have to wait until later.

Also don't have a CF reader with me either.

No problem. As soon as you get hold of a CF reader, I can test the image here.

 

What makes you suspect that its not in 8-bit mode?

Just a wild guess, since every other character of the FAT filename is missing.

[flashjazzcat]

Actually, those short names are the 8+3 aliases...

[flashjazzcat]

Bugs/hardware problems aside, here's a loader for the XEL-I3 with a "Refresh disk" function you can call via the "Disk" menu or via CTRL+D:

 

xload133.zip

 

I've tested this in Altirra using an emulated SIDE cartridge (original, not SIDE2, thus lacking the card removal flag; I no longer have an actual SIDE 1) and it's possible to pull the card, re-insert it, and reset/re-read it with CTRL+D. The card is reset, the partition table re-read (thus obliterating any ATR mounts, which are all invalid following a card swap), and the root directory of the default logged FAT partition is re-displayed. I thought about combining "Undo mounts" with this new refresh function, but decided to keep them separate since the unmount function really needs to confine itself to simply re-reading the partition table and nothing else.

Edited June 26, 2017 by flashjazzcat

[+mytek]

This is great stuff Jon. And I can't wait to give it a try, but unfortunately my 'real' job beckons for my time today, so it'll have to wait for a bit until I have the opportunity. I'm also searching for some CF Cards that I used to have that can be setup from scratch with a game FAT so that I can see if the problem I was seeing is possibly related to a corrupted FAT.

 

Loving it!

 

- Michael

[+mytek]

So today I did find time to load the new xloader, and I also reformatted the FAT on one of my CF cards, as well as transfer a few games over to it inside a single folder. Then I started hoping back and forth from the main to the 'Game' directory, and sure enough after a couple of jumps files began to disappear from the listing, and eventually I got a reported I/O error with a blank listing screen. Pressing CTRL+D would usually fix it, but inevitably it would happen again, and again. Starting to think there is something either wrong with the loader or possibly just altered communication timing vs working in APT mode.

 

My next test will be to revert to the original SIDE PBI and Loader and see what happens when using the same CF in my SIDE2. Good news is your CTRL+D reboot works great to unscramble things, but I must confess i forgot to test it with hot swaps of different cards (I'll do that tomorrow).

 

APT access is still solid as can be, and running the RWCRC (did I spell that right?) test turns up no errors every single time Just need to get the xloader working good (or figure out what's causing what I am seeing), and we're talking mission accomplished!

 

- Michael

Edited June 27, 2017 by mytekcontrols