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

[Faicuai]

17 minutes ago, Justin Payne said:

Are you saying that temperature is in need of some cooling? 

Much on the contrary! Overall, on-par with most similar electronics I have around here!

 

It is pretty stable at the board-level (even at the hottest element), and also well absorbed and handled by the massive aluminum / metal case that surrounding the expansion bay!

 

Cheers!

Edited August 10, 2019 by Faicuai

[Justin Payne]

1 minute ago, flashjazzcat said:

Incognito 4? What about Incognito 5?

 

If we get to the 5th version, let's throw some Roman numerals all up in there. I'll just need a moment to do a slight modification to this image ?

[flashjazzcat]

Who was it who once wrote: 'If you think you need a fan, it's all in your head'.

 

[candle]

24 minutes ago, Mr Robot said:

 

If you no longer have the time to push your designs forward, have you considered open sourcing them? Licence them as non-commercial only if you don't want them to be sold and release all the files so that Incognito 3 can be finished and Incognito 4 can be born. Separately licence for commercial use to the people like Lotharek/Brewing Academy who will sell and give you a commision.

i never seen any open-source project that did good, or was of any quality

i'm heavly involved in porting linux kernel on platforms i've design and what i see inside this code is hair-rising - best to say it is, so it's better than nothing but still... 

if anyone belive he can mandle something and use "open source" software to drive it effortlessly one is heavly mistaken

bottom line - i do not belive in open  source

beside - this is not rocket science, and even if it was, there are tons of people better educated than me capable of doing this from grounds

 

[Justin Payne]

19 minutes ago, flashjazzcat said:

Who was it who once wrote: 'If you think you need a fan, it's all in your head'.

 

I think it was the leader of the Passive Cooling Consortium.
Now, if you're producing a certain podcast that reviews cartridge games for the 8bit line of Atari computers, you need all of the fans you can get. ?

[candle]

for anyone interested in beta testing,

i'll be putting current builds of .jed file into http://spiflash.org/atari/incognito/test/main.jed

and current production file is at http://spiflash.org/atari/incognito/release/incognito_current.jed

 

[Roydea6]

OKay after flashing the main.jed (programed) the CPLD screen when dark.  took all the cables out of the 800 reset the lid and did the AtariKey+Reset and the Bios Screen comes up but does not boot to anything but a dark screen 'L' also dark screen so probably a rom or CF card problem.

 

Reversed back to original current jed programed and restored 800 to operation condition..

 

So my beta test of the new jed file has failed.

 

 

[candle]

i've updated jed file

[Roydea6]

The newest jed file is up and running now on my 800 incognito.  Now I need to know (understand) what needs to be test to verify the reprogramming was successful.

 

I do not understand exactly why this was necessary not having ever noticed a problem, because I am just a user and not a DEV or Programmer.

 

 

[candle]

me too, but since Jon mentioned it, then i try to fix it

there is over 200 units in the wild and i think it was not a problem for average joe, so.. anyways, hope it is fixed now

 

[flashjazzcat]

6 hours ago, rdea6 said:

I do not understand exactly why this was necessary not having ever noticed a problem

The first time I became aware there was a problem was when (IIRC) @Kyle22 reported one of his hard disk partitions immediately going offline when SDX booted up. When I investigated, I discovered that SDX - as well as writing to its own banking register at $D5E0, which is perfectly proper - also writes to $D500 and $D518 during CIO calls, etc. It just so happened that the table of logical drive attributes was in the $D51x area, and somehow entries in this table were becoming corrupted. Some experimentation revealed that SDX's write to $D518 was passing through to the underlying 'IORAM' even when the PBI device selection bit in $D1FF was not set.

 

Ultimate 1MB works almost identically, and no such issue exists there (the IORAM at $D5xx is only accessible when the device selection bit at $D1FF is set, or when the configuration is unlocked), so I concluded that this behaviour was not 'by design'.  The reasons it did not appear to the typical end user as a catastrophic bug:

• It was necessary to have a logical partition attached to a specific drive number (say 'D6:') in order to trigger the issue
• The partition attribute table was subsequently moved to a higher address so that the SDX write to $D518 would not affect it. The issue was thus 'worked around'.
• Although any attached cartridge using address-bus banking (or indeed a simple series of POKEs) could potentially wipe out all partition table data in RAM, I guess the law of averages dictated that such cartridges were rarely attached to Incognito machines

In any case, it was an issue waiting to happen, since if the partition start address table in RAM becomes corrupted by spurious writes to $D5xx, you could see writes to logical partitions completely destroying partitions or the partition table itself on disk.

 

I'm pleased to report that I've just applied Candle's latest JED file, and that things appear to work as intended. The simplest test procedure to verify the primary fix is as follows (assuming recent firmware):

• Boot SDX with the PBI BIOS enabled on Device ID 0 (hard disk on or off; doesn't matter)
• Type SET PROMPT=
• The prompt should vanish; this ensures no disk activity occurs between typed commands
• Type POKE $D1FF,1
• Type POKE $D510,0
• Type POKE $D1FF 0
• Type POKE $D510,$80
• Type POKE $D1FF,1
• Type PEEK $D510
   

$D510 should still read 0. Now Power-cycle the machine, since you deliberately corrupted IORAM with the first write to $D510.

 

I'll keep testing this version today for any regressions, but in the meantime sincerest thanks to @candle for taking the time to implement a fix.

Edited August 11, 2019 by flashjazzcat

[Faicuai]

7 hours ago, rdea6 said:

The newest jed file is up and running now on my 800 incognito.  Now I need to know (understand) what needs to be test to verify the reprogramming was successful.

 

I do not understand exactly why this was necessary not having ever noticed a problem, because I am just a user and not a DEV or Programmer.

 

 

Gents:

 

Could anyone here, please, confirm that Jtag/ISP connection for programming Incognito corresponds to pin-diagram shown on this thread? In other words, is Incognito's the SAME as Ultimate-1MB?:

 

 

Much appreciated!

 

(BTW, I am also on the camp of not having a problem with current JED code, since 2014... but if better, then it's welcome!)

Edited August 11, 2019 by Faicuai

[Faicuai]

21 hours ago, candle said:

in order to access port 3 & 4 you need to read from $d340 onwards, base address will give you only access to port A, and emulated port B, using shadows you can access remaining ports

just remember to have this option enabled in BIOS

 

if anyone would like to test cpld - pm me, but i would like to receive prompt reply either it would work or not, since i don't have original incognito board myself

 

if case anyone wonnders - incognito 2 was cancelled, since i could not fit all the logic i wanted to have, and incognito 3 was designed - unfortunatly i do not have the time to make everything i want novadays

when i was more "active" i was working from home office and nobody cared what i really do as long as on the end of the day assigned job was done - not so much right now - need to sit my time in the office, and only projects i can take there are getting done, or, in case of latest developments for commodore plus4 - simple ones

 

Just quick FYI:

 

ran EYE2 on production JED (NOT the latest version) and did not see anything moving on $D340 with BIOS Joy3/4 enabled, with a controller connected to those ports (onXL mode)... Not sure if I am missing something, bit could anyone confirm?

 

That would close this little loose end, for once and all! 

[Faicuai]

On ‎8‎/‎11‎/‎2019 at 8:27 AM, Faicuai said:

Gents:

 

Could anyone here, please, confirm that Jtag/ISP connection for programming Incognito corresponds to pin-diagram shown on this thread? In other words, is Incognito's the SAME as Ultimate-1MB?:

 

 

Much appreciated!

 

(BTW, I am also on the camp of not having a problem with current JED code, since 2014... but if better, then it's welcome!)

 

Ok, since the anwer is YES (thanks, Jon!) I will be flashing this new JED file and testing for the next 24 hours.

 

I will throw every "wrench" I have to it, as well as check (once again) for Joysticks 3 and 4 readouts on $D340 range...

 

Stay tuned...

[Faicuai]

On ‎8‎/‎10‎/‎2019 at 2:51 PM, candle said:

for anyone interested in beta testing,

i'll be putting current builds of .jed file into http://spiflash.org/atari/incognito/test/main.jed

and current production file is at http://spiflash.org/atari/incognito/release/incognito_current.jed

 

Candle:

 

While we continue to test this new JED file over the next couple of days, I have some nagging questions that I could never get answered. Maybe you know:

 

1. Register $D013 reads fuzzy on Incognito (e.g. most of the time zero, but some of the time seemingly random values). On my Ultimate's, this reads a solid zero ($00) under the appropriate boot conditions. Do you know / remember why this is the case? This is GINTLK main register, if I recall correctly, and it a key ingredient used by the OS for routing and processing COLD vs. WARM starts...

 

2. When you Jon's on-board super-flasher, as soon as it picks up presence of incognito, it presents you a structured ROM-space, with corresponding flashable slots. On that list, I can see one slot called "Recovery OS" which is 16Kbytes in length. What is this slot for? Is it user-accessible? If so, how?

 

3. On Jon's latest monster-BIOS load v3.02, as well as ALL the way back to the initial versions, there is an option called "Boot Diagnostics Cartridge"... What cartridge and what conditions this option refers to? 

 

Many thanks, in advance, for your valuable attention!!

Edited August 12, 2019 by Faicuai

[flashjazzcat]

1 minute ago, Faicuai said:

Boot Diagnostics Cartridge

I don't recall this existing in the original BIOS, but I do recall Phaeron suggesting I add it to my firmware back in 2015 (he was playing with the idea of writing a diagnostic cart at the time). I can tell you that it will start any left cartridge ROM with the diagnostic bit set, without locking the configuration. Thus the cartridge would have full access to everything. Nothing was ever done with the feature, however. But it's still there.

 

Regarding joystick register, etc: I haven't had time to test that here yet since the desk is still completely filled with bits waiting to go into this 130XE. Apologies to everyone else waiting for me to work on their stuff: I had many distractions over the weekend and am generally about three days behind.

 

[toddtmw]

19 minutes ago, flashjazzcat said:

haven't had time to test that here yet since the desk is still completely filled with bits waiting to go into this 130XE.

Is this, the "Crazy idea or not ?" 130XE?

 

If so, I'd love to see pictures...

[Faicuai]

34 minutes ago, flashjazzcat said:

I don't recall this existing in the original BIOS, but I do recall Phaeron suggesting I add it to my firmware back in 2015 (he was playing with the idea of writing a diagnostic cart at the time). I can tell you that it will start any left cartridge ROM with the diagnostic bit set, without locking the configuration. Thus the cartridge would have full access to everything. Nothing was ever done with the feature, however. But it's still there.

 

Regarding joystick register, etc: I haven't had time to test that here yet since the desk is still completely filled with bits waiting to go into this 130XE. Apologies to everyone else waiting for me to work on their stuff: I had many distractions over the weekend and am generally about three days behind.

 

Ok, now I remember exactly what happened:

 

It turns out that I had already tested this, with Star Raiders, and original CPS SuperSalt (FD100335 RevA).

 

When you select "Boot Diags. Cart" on BIOS, and cart plugged on left slot, it turns out that nothing happens. It shows "not present" while still on BIOS, which I always thought that it would seek for a special cart designed for that option, not just any cart, and did not pay further attention...

 

Just FYI, not sure if this mirrors on your side...

Edited August 12, 2019 by Faicuai

[flashjazzcat]

I'll have to have a look; the feature is largely if not entirely untested.

 

[flashjazzcat]

25 minutes ago, toddtmw said:

Is this, the "Crazy idea or not ?" 130XE?

 

If so, I'd love to see pictures...

It is. I will train the webcams on it if I get time, but I have taken still photos and am just trying to progress as quickly as possible at the moment.

[flashjazzcat]

This diagnostic cart feature - which I almost removed anyway owing to lack of use - was indeed broken, so I've fixed it and will upload an update this evening. Thanks to @Faicuai for flagging that up.

Edited August 13, 2019 by flashjazzcat

[Jeffrey Worley]

On 8/10/2019 at 2:00 PM, Justin Payne said:

I think it was the leader of the Passive Cooling Consortium.
Now, if you're producing a certain podcast that reviews cartridge games for the 8bit line of Atari computers, you need all of the fans you can get. ?

I've been a computer tech for a few years.  ?  In the early 90's I saw my first CPU with a Fan on top and I just burst out laughing.  I wasn't mocking it, it just came as a surprise and my usual reaction in cases like that is laughter.  I'd worked with computers for more than a decade by that time and not one even had a heat sink on it, much less a FAN.  I think the processor that got the giggle was a 486dx50, maybe a dx266.  Of course for ever and ever there have been various active cooling systems for supercomputers and the like, but on the bench?  I was really taken aback.  Anyway I thought I'd share.

[Faicuai]

On ‎8‎/‎11‎/‎2019 at 7:03 AM, flashjazzcat said:

The first time I became aware there was a problem was when (IIRC) @Kyle22 reported one of his hard disk partitions immediately going offline when SDX booted up. When I investigated, I discovered that SDX - as well as writing to its own banking register at $D5E0, which is perfectly proper - also writes to $D500 and $D518 during CIO calls, etc. It just so happened that the table of logical drive attributes was in the $D51x area, and somehow entries in this table were becoming corrupted. Some experimentation revealed that SDX's write to $D518 was passing through to the underlying 'IORAM' even when the PBI device selection bit in $D1FF was not set.

 

Ultimate 1MB works almost identically, and no such issue exists there (the IORAM at $D5xx is only accessible when the device selection bit at $D1FF is set, or when the configuration is unlocked), so I concluded that this behaviour was not 'by design'.  The reasons it did not appear to the typical end user as a catastrophic bug:

• It was necessary to have a logical partition attached to a specific drive number (say 'D6:') in order to trigger the issue
• The partition attribute table was subsequently moved to a higher address so that the SDX write to $D518 would not affect it. The issue was thus 'worked around'.
• Although any attached cartridge using address-bus banking (or indeed a simple series of POKEs) could potentially wipe out all partition table data in RAM, I guess the law of averages dictated that such cartridges were rarely attached to Incognito machines

In any case, it was an issue waiting to happen, since if the partition start address table in RAM becomes corrupted by spurious writes to $D5xx, you could see writes to logical partitions completely destroying partitions or the partition table itself on disk.

 

I'm pleased to report that I've just applied Candle's latest JED file, and that things appear to work as intended. The simplest test procedure to verify the primary fix is as follows (assuming recent firmware):

• Boot SDX with the PBI BIOS enabled on Device ID 0 (hard disk on or off; doesn't matter)
• Type SET PROMPT=
• The prompt should vanish; this ensures no disk activity occurs between typed commands
• Type POKE $D1FF,1
• Type POKE $D510,0
• Type POKE $D1FF 0
• Type POKE $D510,$80
• Type POKE $D1FF,1
• Type PEEK $D510
   

$D510 should still read 0. Now Power-cycle the machine, since you deliberately corrupted IORAM with the first write to $D510.

 

I'll keep testing this version today for any regressions, but in the meantime sincerest thanks to @candle for taking the time to implement a fix.

 

Well, folks, after troubleshooting a f-annoying and intractable programming-failure, it finally ended up being diagnosed (and cured) with a NEW USB Platform Cable (DCT-9G, from Amazon, plus special 2.54mm-to-2.0mm jumper-ribbons, which also eliminated my old loose jumpers). The actual .JED flashing was finally performed and took only a measly 4 secs (!) on my Incognito #2. Can't believe how much frustration for just 4-secs of glory! I am now well into the tests.

 

The .JED file that I programmed shows (internally) being extracted on 8/11/2019 (so I assume this is the latest Beta). However, I actually managed to extract my existing (as-purchased) .JED from my Incognito #2 prior to any programming, and (SURPRISE !) it was actually different than ALL the .JEDs posted here. I visually verified this with "Beyond-Compare" tool, which I would truly recommend everyone here gets a copy.

 

Now, as the preliminary results:

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). I know this is not a "mirage" read-out, because I connected multiple joysticks on ports 1-4 while concurrently pressed fire-buttons, and they ALL activate independently, on each of the 800's physical ports... And these are NOT Paddle's port-shared triggers either, because... those show up at separately at $D300, $D304, $D308 and $D30C (albeit NONE of these addresses show paddle or joystick readouts from Ports 3 and 4).
2. 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.
3. GINTLK continues to read fuzzy (at $D013), so no changes there. This WILL have an impact on OS (XL/XE) routing and servicing of warm vs. cold resets. I have already asked about this multiple times, and the crickets sound even louder.
4. Performed write-through tests at $D510 (per Jon's verification code) and they are effectively being blocked, which is Ok. I suppose this memory hole is, indeed, closed for good!
5. OSS-Carts partition on my SIDE 1 & 2 carts are FAILING on Incognito. They DO NOT work properly (I now presume is a problem with the patches loaded on them). Specifically, Basic-XE only boots with Q-Meg 4.04 (while locking up if attempting to load XE-extensions), and on XL/XE loads (rev3/4) it locks-up immediately on Ready prompt. Basic XL, however, seems to work fine (did not bother testing other carts, as SIDE 1/2 do not conform to the cart-slot space provisioned on the 800). If anyone here has obtained different results, just chime in!

Features request:

1. It would be nice to be able to toggle / select {READ & WRITE} or {READ-only} mode for $C000-$CFFF address range, specifically in Colleen / 52K mode, which will enable support of RAMROD / Newell's legacy OSN, as it was designed and structured around the following components:
   • $C000-$CFFF: 4-Kbytes, Omnimon (monitor) or Ominiview (80-col emulator).
   • $D800-$DFFF: 2-Kbytes, Newell fast Floating Point routines pack.
   • $E000-$EFFF: 4-Kbytes, OS-N 6.01, Socket #1 (4Kbytes)
   • $F000-$FFFF: 4-Kbytes, OS-N 6.01, Socket #2 (4Kbytes)

 

I will continue testing other cases, here, and report anything strange.

 

Cheers!

 

Edited August 20, 2019 by Faicuai

[candle]

remember that all xl/xe computers (with exception of 1200(xl)) are using RAS signal instead of PHI2 signal on cartridge connectors - replacing it with PHI2 (this was discussed in other thread) fixes the issue and does not introduce any compatibility issues with other (800 era) cartridges

 

[+tf_hh]

13 hours ago, candle said:

remember that all xl/xe computers (with exception of 1200(xl)) are using RAS signal instead of PHI2 signal on cartridge connectors - replacing it with PHI2 (this was discussed in other thread) fixes the issue and does not introduce any compatibility issues with other (800 era) cartridges

 

Ehm... no. All XL/XE/XEGS computers have buffered PHI2 connected to the cartridge port. The Atari 400 and the Atari 800 has RAS instead of PHI2 at the left cartridge. The right cartridge in the Atari 800 has both RAS and PHI2.