Incognito in production for a limited time. Get em' while they're hot!

[Faicuai]

2 hours ago, _The Doctor__ said:

all of what was discovered (and verified +1 FJC) in a concise package to candle might get one more lose end tied up. I'll finalize my order of 2 more at that point.

Very exciting to see the progress made and what's been accomplished.

Way to go Candle!

I will get it done, ASAP.

[Kyle22]

11 hours ago, _The Doctor__ said:

kyle22, did you fix your tl and update yet?  I think you'll like it. Not saying it's a miracle, it's much better and I think you'll be happier with it.

I assume you mean the TL866. No, I do not have the cable to fix it

 

Edited August 26, 2019 by Kyle22
TYPO!

[Faicuai]

On 8/10/2019 at 11:49 PM, candle said:

i've updated jed file

Candle:

 

We all thought bringing this to your attention, so let's try summarizing our findings quickly, for the benefit of everyone's time:

1. FOUND Joysticks 3/4 on XL MODE (or at least, a clear sign of their presence): you can check addresses $D050-$D053  and read Joysticks 1,2,3,4 TIGGER toggles (buttons). 
2. However, actual "stick" read-outs from ports 3 and 4 continue to be missing. NOWHERE to be found, unless they got buried beyond $D300 in a sea of live, intractable address/data bus readouts. No activity seen at $D300, $D304, $D308 and $D30C
3. TRIG3 continues to read fuzzy (at $D013). Does not read a solid $00 (for instance) as it reads on Ultimate/1MB. This WILL have an impact on OS (XL/XE) routing and servicing of warm vs. cold resets, as well as any cartridge-presence detection code executed by O/S.

Features / suggestions (in order of priority and hopefully ease of implementation):

1. Address fuzzy read-outs from $D013 (and all mirror registers related to it).
2. Get / define actual registers to read Joysticks 3,4 inputs as well as Paddles' on ports 3,4.
3. Toggle / select {READ & WRITE} or {READ-only} mode for $C000-$CFFF ram address range, specifically in Colleen / 52K mode, which will immediately enable support of RAMROD / Newell's legacy OSN (e.g. Omnimon and Omniview 4K add-ons).

Many thanks, in advance, for your valuable and kind attention (!)

[+tf_hh]

On 8/22/2019 at 5:14 PM, Faicuai said:

... I understood (from some quite unexcepted surprises during development of The!Cart, and later further testing, revisions and documentation) that, it turns out the 800 was discovered to be the ONLY model not having access to PHI2 signal at the LEFT-cart port connector, BUT having access to it on the RIGHT port (!). The 400 seems fine, though, and it everyone was befuddled as to why was the case / choice for 400/800 production

 

This motivated the The!Cart team to develop a small dummy board to be attached to RIGHT port, and connected to the The!Cart, while sitting on the LEFT port, so PHI2 could be effectively sampled while attempting to flash The!Cart on-board the 800.

 

Sorry for late response. I wasn´t sure, so I check out a real, unmodified Atari 400:

 

 

This is what you get on pin "S" of the 400´s cartridge port  - clearly a RAS signal. Personally I never said something about the 400, because at the time I wrote the thread "how to patch the Atari 800 to make myIDE2 run" the The!Cart (version 1) won´t fit in the 400.

 

After all, the schematics in the "Atari 400 and 800 field service manual" (see Atarimania etc.) also states, that "RASTIME" is connected to pin "S" instead of PHI2 (O2). So IMHO you need to patch the 400 the same way to make The!Cart V2 and others work, independent from the question of size.

 

 

[+slx]

I remember doing some mod to the cart port of my 400 when I had it open to install the SCCC and IIRC that mod was needed for all kinds of flash-based carts to work properly.

[Faicuai]

1 hour ago, tf_hh said:

 

Sorry for late response. I wasn´t sure, so I check out a real, unmodified Atari 400:

 

 

This is what you get on pin "S" of the 400´s cartridge port  - clearly a RAS signal. Personally I never said something about the 400, because at the time I wrote the thread "how to patch the Atari 800 to make myIDE2 run" the The!Cart (version 1) won´t fit in the 400.

 

After all, the schematics in the "Atari 400 and 800 field service manual" (see Atarimania etc.) also states, that "RASTIME" is connected to pin "S" instead of PHI2 (O2). So IMHO you need to patch the 400 the same way to make The!Cart V2 and others work, independent from the question of size.

 

 

NICE!!!

 

Maybe a good comment / update for Peter & team @ The!Cart project... unless somehow some 400 units got PHI2 instead of RAS (a production variance).

 

In any case, I must confess I have never been in favor (nor I ever will) of cutting PCB traces of any kind, nor irreversibly modifying any aspect of the hosts' computer key resources (such as its mother-board, auxiliary boards, etc.)

 

I will have no problem, whatsoever, with a basic provision made on all these devices to sample and switch PHI2 externally (besides main edge cart-connector). In this way, it will be possible to leverage the presence of PHI2 on 800's right cart-port, without physically altering the machine (I fully understand it may not be an option on the 400, but I would better route a cable terminal inside the cart port, and sampling PHI2 somewhere else, than also cutting a trace on the 400's MoBo).

 

That's what the The!Cart team did, in fact, with the exception that the trace needs to be cut at The!Cart itself  (no source-switching mechanism) and then sample PHI2 from dummy-board connected on RIGHT-slot (which is nice!)

 

Anyways, THANKS for taking the time to verify this!

Edited August 29, 2019 by Faicuai

[+tf_hh]

17 hours ago, Faicuai said:

I will have no problem, whatsoever, with a basic provision made on all these devices to sample and switch PHI2 externally (besides main edge cart-connector). In this way, it will be possible to leverage the presence of PHI2 on 800's right cart-port, without physically altering the machine (I fully understand it may not be an option on the 400, but I would better route a cable terminal inside the cart port, and sampling PHI2 somewhere else, than also cutting a trace on the 400's MoBo).

 

There´s another possible way for future revisions: Generating one´s own PHI2 signal ?

 

Mostly all modern, external (cartridges, PBI devices etc.) solutions use the monovibrator-circuit with the 74HCT123/74LS123 to get a shortened PHI2 high phase. This is needed when modern, fast switching chips like FPGA, CPLD and even the old GALs are used together with "modern", much faster SRAMs, EEPROMs or Flash-Chips. Together with the shortened PHI2 phase all write accesses to external chips etc. are made more safe when the devices sampling the state of the databuss at the falling edge of PHI2.

 

Also mostly all these solutions (incl. myself) didn´t use the second monovibrator provided with these 74s TTL logic IC. So I suggest to use it for all upcoming cartridge solutions and let  generate two "new" PHI2 signals:

 

1. The shortened one as usual (approx 170nS "high" phase)

2. A standard one with approx. 220-230ns.

 

The "new standard" PHI2 is used for all logic on the cartridge instead of the PHI2 (or RAS) coming from the mainboard. This should cure all these problems and also the cartridge should be work in ALL computers without modding or cutting any traces. I will do some experiments, but I´m sure 220nS should be enough for all read operations.

 

When upcoming cartridges uses something like that, then it doesn´t care if the real PHI2 or RAS is present at the cartridge port. The rising edge of PHI2 and RAS are nearly equal with a slightly difference of max. 10nS - that´s fine.

 

[adam1977]

This is turning out to be a great year for the 800, a new run of Incognito cards and replacement Mylars 

 

 

[Faicuai]

2 hours ago, tf_hh said:

 

(...) So I suggest to use it for all upcoming cartridge solutions and let  generate two "new" PHI2 signals:

 

1. The shortened one as usual (approx 170nS "high" phase)

2. A standard one with approx. 220-230ns.

 

The "new standard" PHI2 is used for all logic on the cartridge instead of the PHI2 (or RAS) coming from the mainboard. This should cure all these problems and also the cartridge should be work in ALL computers without modding or cutting any traces. I will do some experiments, but I´m sure 220nS should be enough for all read operations.

 

That is F-brilliant!

 

Nothing like the knowledge derived from the design and engineering of the HW itself...

 

Every single HW developer here should consider reviewing this alternative. On-board generation of PHI2, without ever butchering your host's HW. SWEET!

[candle]

average joe should give a * for phi2 signal, or any other signal in that matter

hardware should just work - it's up to designer to cope with all the issues that may arrise and design hardware not in a matter than everything works if world is perfect, but to include corner cases and any misuses that average joe could easly come with

besides, there is more than one way to skin a cat

 

[Faicuai]

1 hour ago, candle said:

average joe should give a * for phi2 signal, or any other signal in that matter

hardware should just work - it's up to designer to cope with all the issues that may arrise and design hardware not in a matter than everything works if world is perfect, but to include corner cases and any misuses that average joe could easly come with

besides, there is more than one way to skin a cat

 

Could not agree more!

 

Also, we need your guidance on a couple of items that we have not been able to clarify... Let us know what your thoughts are, whenever your time permts:

 

 

A big thanks, in advance!

 

[+slx]

5 hours ago, candle said:

average joe should give a * for phi2 signal, or any other signal in that matter

hardware should just work - it's up to designer to cope with all the issues that may arrise and design hardware not in a matter than everything works if world is perfect, but to include corner cases and any misuses that average joe could easly come with

besides, there is more than one way to skin a cat

 

I am very happy to have people around who know the difference between PHI2 and RAS but I do agree that I am happy if stuff just works

[candle]

in order to use joystick port 3 &4 do as follow:

poke $D343,$38 - set PORTB to data direction register mode

poke $D341,0 - set PORTB bits 0-7 as input

poke $D343,$3C - set PORTB to data register mode

now you can read both joystick values

GTIA registers (trigger 3 & 4) can be read from GTIA shadow as it was mentioned before, since in XL/XE line standard register ($D013)is connected to cartridge port

don't know if one can conduct it under basic, but surely one can under eye2

 

this is still a bug, but at least i can see what is to get fixed

in a perfect world joystick values should be read only from shadow location starting at $D340 onwards, but unfortunatly it starts from $D300

 

[Faicuai]

1 hour ago, candle said:

in order to use joystick port 3 &4 do as follow:

poke $D343,$38 - set PORTB to data direction register mode

poke $D341,0 - set PORTB bits 0-7 as input

poke $D343,$3C - set PORTB to data register mode

now you can read both joystick values

GTIA registers (trigger 3 & 4) can be read from GTIA shadow as it was mentioned before, since in XL/XE line standard register ($D013)is connected to cartridge port

don't know if one can conduct it under basic, but surely one can under eye2

 

this is still a bug, but at least i can see what is to get fixed

in a perfect world joystick values should be read only from shadow location starting at $D340 onwards, but unfortunatly it starts from $D300

 

IT WORKS (!!!)

 

Joysticks 3 & 4 are fully readable, real-time, via EYE2, an on XL/XE mode (OS) !

 

I also tried PORTB setup-sequence AFTER entering Basic, and... IT WORKS, TOO!!!! Joysticks 1,2, 3 & 4 are readable by peeking $D340 (1 & 2) and $D341 (3 & 4) directly, as their status will show up on the MSB and LSB nibbles of those registers. Even more, there are MULTIPLE additional registers that you can read these values from, past $D341 (!)

 

Now we have a much better clue of what needs to be tuned on CPLD for direct readout, instead!

 

A huge thanks!!! Mystery solved!!!

 

(UPDATE / NOTE: it seems that "Controllers 3-4" option in Incognito BIOS have no effect on this process, it does not matter if it is ON or OFF, you can execute PORTB mode-setup sequence as described above, and end up reading Joysticks 3 & 4 successfully, either way!)

Edited September 4, 2019 by Faicuai

[_The Doctor__]

almost there, almost... just for ridiculously crazy fun see if you can take the 800 version of TOBLyrae (or any 4 port games for that matter) - run a translator disk on those that need it and activate the the ports and see if all 4 are there for the game... in the current form I think the game would need modification...

this opens up the possibility for port 3 and 4 devices to continue being used in xl/xe mode now at least those that just send data to the ports... can data be sent from the ports though?

 

it's great to see that software can now be written for XL/XE mode with all 4 ports none the less

looks like this and the pbi fix and the incognito will be pretty darn solid.

Edited September 5, 2019 by _The Doctor__

[Gunstar]

14 hours ago, Faicuai said:

Joysticks 3 & 4 are fully readable

 Joysticks 1,2, 3 & 4 are readable by peeking $D340 (1 & 2) and $D341 (3 & 4) directly, as their status will show up on the MSB and LSB nibbles of those registers. Even more, there are MULTIPLE additional registers that you can read these values from, past $D341 (!)

 

11 hours ago, _The Doctor__ said:

this opens up the possibility for port 3 and 4 devices to continue being used in xl/xe mode now at least those that just send data to the ports... can data be sent from the ports though?

 

it's great to see that software can now be written for XL/XE mode with all 4 ports none the less

looks like this and the pbi fix and the incognito will be pretty darn solid.

Doesn't the above post mean it collecting data from (reading) 3 & 4, which means data can be sent from the ports? I didn't understand it as sending data too the ports myself. ??

[candle]

perhaps like for XEP80 interface or multijoy, or another serial based controller (nintendo?)

[_The Doctor__]

exactly candle nailed it- XEP80, multijoy, modem, serial based controllers etc etc.

cool when done.

 

super crazy idea...

We need a personality board for the XE that adds port 3 and 4 back to the XL/XE (perhaps incog/ulitmate?)

That way an i800 and an iultimate XL/XE have all the same features for the most part.

The top selling Atari line unified. Now that would rock!

[Sugarland]

Will these CF cards work in the new run of Ignocnitos?  They are SanDisk Extreme 32GB 120MB/s cards. They do not work in my SIDE2. They do work in my PC just fine and look to be legit SanDisk cards.  I notice this post by mytek noting the National 74HCT138 chip fixed compatibility with XEL-CF3. Is this the level of CF compatibility we can hope for?

[Faicuai]

21 minutes ago, Sugarland said:

Will these CF cards work in the new run of Ignocnitos?  They are SanDisk Extreme 32GB 120MB/s cards. They do not work in my SIDE2. They do work in my PC just fine and look to be legit SanDisk cards.  I notice this post by mytek noting the National 74HCT138 chip fixed compatibility with XEL-CF3. Is this the level of CF compatibility we can hope for?

Don't know about those two (if not working on SIDE-II, chances are they will not work on Incognito).

 

However, eBay is INFESTED with the following one (as well as its 4GB brother), which will provide you with the highest I/O throughput I have seen on Incognito, and Ultimate, so far:

 

 

You can go now and grab as MANY as you wish, and ChEeEaAaP (!)

 

Edited September 6, 2019 by Faicuai

[BillC]

On 9/5/2019 at 6:37 AM, candle said:

perhaps like for XEP80 interface or multijoy, or another serial based controller (nintendo?)

The Corvus Systems Atari Interface board also connects to joystick ports 3&4 on the 400/800.

[Faicuai]

6 minutes ago, BillC said:

The Corvus Systems Atari Interface board also connects to joystick ports 3&4 on the 400/800.

You beat me to the punch, here...

 

There's an interesting YouTube video showing off what it can do, and how fast it works... over a God-damned joystick port (!!!)

 

What I did not remember, though, was the port-range (1-2) or (3-4)... We will need to find a way to test if we have bi-directional capabilities enabled with Incognito's ports 3 & 4 (on XL mode), though...

[Kyle22]

This is very important because we have Jon's CORVUS.SYS for SDX. It supports APT and can get along with other PBI hard drives.

 

[Faicuai]

1 minute ago, Kyle22 said:

This is very important because we have Jon's CORVUS.SYS for SDX. It supports APT and can get along with other PBI hard drives.

 

Maybe this will be the little "kick" Curt Vendel needs to finally install Incognito on his 800-fleet, and enjoy them to the full potential they were always meant to attain!

??

 

What we need is some sort of loop-back cable / jumper (between Joy3 & 4 ports) and a small utility to exchange data from one port to another, in both directions, and that would seal the deal!

[Kyle22]

3 minutes ago, Faicuai said:

Maybe this will be the little "kick" Curt Vendel needs to finally install Incognito on his 800-fleet, and enjoy them to the full potential they were always meant to attain!

??

 

What we need is some sort of loop-back cable / jumper (between Joy3 & 4 ports) and a small utility to exchange data from one port to another, in both directions, and that would seal the deal!

I agree completely.

 

Edited September 8, 2019 by Kyle22
Like LapLink cable. call it AtariLink.