Incognito - Now's your chance!

[Gunstar]

21 hours ago, Faicuai said:

I was on the exact same position years ago, when planning the install. I quickly came to the conclusion that the suggested mod of the LED console (fixed) button was a NO-go (not worth the physical changes, nor it seemed solid enough, plus being irreversible, as repairing cut-traces or leaving drilled-holes on the power-board is not really a reversion).

 

If you are (and will remain) undecided, you can just safely extract the ATR-switch cables through an underneath side (left-or-right) taking advantage of the multiple vents available there. Then SOLDER the switch externally (and isolated it with thermo-wrap), and have it functional, until one day you define where exactly is your best place. The flashing led eventually becomes a meaningless / repetitive distraction over time (saw that happening with my SIDE 1/2), and these latest Incognito boards already have a bright, flashing-LED when I/O takes place, which is enough for diagnostics. 

 

That's probably the best advice for anyone on the fence, as you will have a 100% functional install (with working .ATR switch button) and still a complete and unmodified PCB and external case, until the time comes for final install.

 

 

 

I'm only undecided right now, and contemplating several different possibilities because I have not yet started the installation. I will make a final decision when I come to installation of the ATR switch . But in the slim chance I can't decide, I will take your advice. My desire to mount it in a place besides where the power LED is isn't from not wanting to make permanent changes to the mother board or modify the LED light tube, but merely because I don't wish to have the button or ATR LED light where the power LED is. I would only do that if I had a spare 800 function switch and key to replace the power LED fake key cap and then I would install the power and ATR LED's in the keycap (I have mini LED's to use there).

Edited November 5, 2019 by Gunstar

[Jeffrey Worley]

4 hours ago, flashjazzcat said:

This is possibly the problem. One Incognito owner sent me some very interesting DMs on the matter of the LED driver circuit having to power two LEDs (the SMD part and the secondary LED). It's something I'd never thought about, but it may well explain the lacklustre glow of the HDD light.

 

These are three volt led outputs,  i think.  Behind a board-mounted resistor that would explain dimness.  Of the 3volt leds I bought,  the blue ones are brightest.

[adam1977]

Has anyone got the specs for the JTAG socket at all? I bought some off eBay but they're too big... 

[flashjazzcat]

11 minutes ago, adam1977 said:

Has anyone got the specs for the JTAG socket at all?

It's a 2mm pin pitch. DC3-10P from this seller will do:

 

https://www.ebay.co.uk/itm/2-0MM-Straight-IDC-Header-Connector-DC3-6-8-10P-12-20-30-40-60P-ISP-JTAG-Socket/223488914481

 

Edited November 8, 2019 by flashjazzcat

[adam1977]

Thank you very much 

[toddtmw]

So. Does SDX still not support long filenames?

 

How can we possibly fill up a harddrive with files that are limited to 8.4? (I know, DOS did it for a long time, but this isn't the 20th century anymore.)

 

I read one thread where it said SDX wouldn't run in 64k if it supported long filenames. Who uses 64k anymore?

 

what is everyone doing to work with this limitation?

 

Thank you.

[toddtmw]

Oh, and I GOT MINE WORKING!

 

I just put a switch on the bottom. Haven't tried to confirm it works yet.

 

It would have been nice if the wiring harness provided by Lotharek had been long enough to actually reach the plug on the incognito board. The two outside wires need to be about 3-4 inches longer.

[flashjazzcat]

I'm hesitant even to support long FAT filenames in my GOS owing to the tremendous overheads, but apart from that, SpartaDOS would need a completely redesigned raw directory structure in order to cope with long filenames in its native filesystem, let alone FAT LFNs. And even if they were supported, what application has a 128 byte filename buffer (more, in fact: imagine the size of a full path with long directory names)? Simply not worth considering for a file system which needs to work with existing applications.

 

Since the FAT loader handles long filenames and the SDX FAT driver allows access to the same files via the short alias, I don't think it's too much of a deal breaker.

[+DrVenkman]

32 minutes ago, toddtmw said:

It would have been nice if the wiring harness provided by Lotharek had been long enough to actually reach the plug on the incognito board. The two outside wires need to be about 3-4 inches longer.

Agreed, though I suppose if you either didn't care about squishing the wires or are willing to do more invasive surgery on the PCB slot/cart guide plastic, you could run those wires more directly to the Incognito instead of running the wires out around the side and up through the slot-gap as Jon suggests. I ended up using 4 of Lotharek's wires and a new Dupont connector, along with two new, longer wires to the CPU board.

[toddtmw]

2 minutes ago, DrVenkman said:

Agreed, though I suppose if you either didn't care about squishing the wires or are willing to do more invasive surgery on the PCB slot/cart guide plastic, you could run those wires more directly to the Incognito instead of running the wires out around the side and up through the slot-gap as Jon suggests. I ended up using 4 of Lotharek's wires and a new Dupont connector, along with two new, longer wires to the CPU board.

I just squished the wires under the plastic cage. Just sayin', the cost to increase the length of the harness by 3 inches is nil.

[Gunstar]

9 minutes ago, flashjazzcat said:

I'm hesitant even to support long FAT filenames in my GOS owing to the tremendous overheads, but apart from that, SpartaDOS would need a completely redesigned raw directory structure in order to cope with long filenames in its native filesystem, let alone FAT LFNs. And even if they were supported, what application has a 128 byte filename buffer (more, in fact: imagine the size of a full path with long directory names)? Simply not worth considering for a file system which needs to work with existing applications.

 

Since the FAT loader handles long filenames and the SDX FAT driver allows access to the same files via the short alias, I don't think it's too much of a deal breaker.

I don't mind the short alias, when it comes to something you have a bunch revisions/versions, I just create a new folder (sub-directory) with a short alias of the program and in the folder are files with dates and version info

Edited November 8, 2019 by Gunstar

[+DrVenkman]

1 minute ago, toddtmw said:

I just squished the wires under the plastic cage. Just sayin', the cost to increase the length of the harness by 3 inches is nil.

I'm not disputing that at all. I suspect it was just an oversight or mis-measurement when making wiring harnesses. 

[+DrVenkman]

And this thread reminded me that I need to buy one more little thing this weekend for my Incognito - a new CF card! I have a pair of these currently, one in my 1088XEL and another in my 1088XLD. I have been testing my Incognito with one of them and they work great. The capacity is far out of proportion to the need, but with reliable, non-counterfeit CF cards sometimes hard to find, it's an easy purchase.

 

https://www.amazon.com/gp/product/B00GHBBK82/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

 

Just one thing about this card - it does *NOT* work in my SIDE2 cart, which is too bad. I had a same-series 8GB version of this card that did work in my SIDE2 cart, but that card was destroyed in a power-supply snafu in my 1088XEL a few months ago. The 8GB version is no longer available on Amazon so I'm back to using an ancient, relatively tiny 512MB card in my SIDE2 instead.

[toddtmw]

16 hours ago, flashjazzcat said:

I'm hesitant even to support long FAT filenames in my GOS owing to the tremendous overheads, but apart from that, SpartaDOS would need a completely redesigned raw directory structure in order to cope with long filenames in its native filesystem, let alone FAT LFNs. And even if they were supported, what application has a 128 byte filename buffer (more, in fact: imagine the size of a full path with long directory names)? Simply not worth considering for a file system which needs to work with existing applications.

 

Since the FAT loader handles long filenames and the SDX FAT driver allows access to the same files via the short alias, I don't think it's too much of a deal breaker.

How does PicoDOS do it? I don’t care what it calls it behind the scenes, I’d just like to see more than 11 characters of the name. Even allowing 20 characters plus the extension would be a huge improvement. 

[flashjazzcat]

None of the file management systems supported by MyPicoDOS support more than eleven characters in the filename anyway, so I am not sure from where the long names are derived. But it's essentially a game loader, and the SIDE loader supports 128 character filenames and reads FAT (and supports CIO access to FAT), so I am not sure what the perceived shortcomings are.

[Jeffrey Worley]

I think the law of diminishing returns applies here.  I DO wish there were some easy way to display long-filename directory entries from the command line in Spartados for Fat 16 partitions.  The algorithmic 8.3 produced at present has a hard time making human-sensical.  I often have a hard time telling what dir or what file I'm operating on.  The prevalence of long-filenames exacerbates things.

 

Jeff

 

[flashjazzcat]

33 minutes ago, Jeffrey Worley said:

I DO wish there were some easy way to display long-filename directory entries from the command line in Spartados for Fat 16 partitions.

If such a tool would be genuinely useful I could produce one, but you'd still have to use the short alias when actually doing anything with a file other than viewing its name in the directory listing, so it might be better to name files appropriately in the first place. The sensible workaround is to use 8.3 names for files you intend to access from DOS, and long filenames for files you propose to access from the SIDE Loader. Directories are supported in both environments, so you need only create a 'DOS' folder and use 8.3 names for everything in it. Or better yet, use separate partitions - one for DOS, and one for the loader. A prevalence of long filenames will no longer be a problem, since there will be no files with long names present in the DOS FAT partition.

[flashjazzcat]

1 hour ago, toddtmw said:

How does PicoDOS do it?

From the MyPicoDOS manual (which, now that I am home, I can read):

Quote

If MyPicoDos finds a file named PICONAME.TXT in a directory, it
will read the disk/directory title and the long filenames from it.

MyPicoDos displays the long filenames in the same order as they
appear in the PICONAME.TXT file. So you can easily arrange the
order by simply editing PICONAME.TXT by hand.

Only file found both in the directory _and_ in the PICONAME.TXT
file are shown. So, if you add another file, be sure to update
the PICONAME.TXT file, otherwise it won't appear in the listing.
On the other hand, you can simply hide files by omitting them
in the PICONAME.TXT file.

i.e. user-generated metadata.

[+mytek]

22 minutes ago, flashjazzcat said:

user-generated metadata

Actually I could see that working very well for a MIDI player, where the files could be numerically named (i.e., 001.mid, 002.mid, 003.mid) and then a more intelligible name could get substituted in the directory (Eagles - Hotel California).

 

[flashjazzcat]

3 minutes ago, mytek said:

Actually I could see that working very well for a MIDI player, where the files could be numerically named (i.e., 001.mid, 002.mid, 003.mid) and then a more intelligible name could get substituted in the directory (Eagles - Hotel California).

Yes: I think we discussed this exact idea previously on the understanding that it would be a good compromise between working with available file system drivers and displaying verbose information not present in short filenames. Alternatively, files could themselves contain metadata in their file headers, although the overhead for retrieving same is somewhat higher than simply scanning through a text file. The player could of course trawl the file-hosted metadata once and cache relevant information in an automatically generated metadata file which would facilitate rapid retrieval of the extended data from the cache during subsequent cataloguing of the file list. The advantage of metadata is that one is not constrained by the limitations of the file system, even if it allowed long filenames (it would be easy to make provision for tags, genres, playlists, etc).

[Jeffrey Worley]

What?  No "L A S E R"  beams?  From space, or anywhere?

 

I want "L A S E R S".

 

Jeff

[+mytek]

1 hour ago, flashjazzcat said:

Yes: I think we discussed this exact idea previously on the understanding that it would be a good compromise between working with available file system drivers and displaying verbose information not present in short filenames. Alternatively, files could themselves contain metadata in their file headers, although the overhead for retrieving same is somewhat higher than simply scanning through a text file. The player could of course trawl the file-hosted metadata once and cache relevant information in an automatically generated metadata file which would facilitate rapid retrieval of the extended data from the cache during subsequent cataloguing of the file list. The advantage of metadata is that one is not constrained by the limitations of the file system, even if it allowed long filenames (it would be easy to make provision for tags, genres, playlists, etc).

Yes I do recall some talk about using the built-in metadata of the MIDI file, but I suspect its not very consistent. However once an agreed upon standard was decided for a separate 'text' based metadata file, it could also serve double duty as an easy index that could be printed out for the numbered .mid files, since keeping track of their musical content otherwise would become difficult outside of the MIDI player.

 

[+DrVenkman]

I got the height dialed in for the structural support standoff on my power board mod this morning and my ATR swap/rotate button works like a charm!  

 

The light pipe stands a little taller than stock currently but I kind of like it that way. Still unobtrusive but it helps knowledgeable Atari-folk know that it’s a button rather than a bezel light. And the click action is smooth and very deliberate - no flexing or forcing.  Just a very tangible, haptic little click. Perfect!

 

So the only mystery left to solve is the HDD activity light. I’ve verified (again) the continuity of the wiring for the LED all the way from the Incognito to the LED, and verified again both the orientation and the functionality of the LED. So I think the almost 3V forward voltage necessary to drive the light is just too much for the Incognito. I might replace it later, or simple swap the two LED’s. It would be fun to see a green power LED on an 800 that otherwise looks almost completely stock. 
 

But that’s a project for another weekend. 

 

 

[adam1977]

5 hours ago, DrVenkman said:

I got the height dialed in for the structural support standoff on my power board mod this morning and my ATR swap/rotate button works like a charm!  

What length standoff did you end up with?

[+DrVenkman]

1 hour ago, adam1977 said:

What length standoff did you end up with?

I used a 20mm standoff with a small screw inserted into the bottom - I simply rotated the screw to dial-in the insertion depth, which in turn set the total height. I think it was very close to 22 - 22.5mm, I think.