800 / INCOGNITO: Floating Data-Bus woes...

[Faicuai]

Ok, here's the deal:

 

There are a couple of loose-ends left out there without a clear answer (regarding Incognito), and here they are, for which inputs from ANY 800 user (Incognito or NOT) are more than welcome:

 

1. Following this very interesting post by phaeron, and assuming that the expected traces are still valid, it turns out that 800/Incognito responds with (213 or 0) to looped PEEK(54528), with ROM basic, or with external Basic cart, or loaded in ram (does not matter which source):
   2. The above response from Incognito suggests a 130XE (single) floating data-bust, but... it turns out we are getting it in COLLEEN /800 MODE (!!!), where, in reality, we should be getting (212 or 0), due to the dual floating data-buses unique to the 800 (one of them being linked to the Personality board itself). Would this then suggest that INCOGNITO does NOT implement or replicate 800's dual floating-buses an, instead, adopted a unified bus, like 130XE, even in Colleen mode (???) Could ANY 800 user here (non-Incognito) run a PEEK(54528) from Basic, on their end (15 times) and report back their value here?
2. Furthermore, and here's where the mystery deepens even more: if we issue a constant PEEK($D013) from either Basic or EYE2 (being $D013 = TRIG3, or ACMI Cartridge Interlock register, permanently patrolled by the OS, and at the CORE of its COLD/WARM restart dispatcher), guess what happens? Instead of getting either "0" (ext. cart not installed or Basic ROM in use) or "1" (external cart plugged in) as in Ultimate/1MB, we get... FLOATING-BUS DATA (!!!) In other words, we get $D0 most of the time, and a MYRIAD of other values, less of the time...

 

This is very relevant because it implies that an XL/XE OS running on Incognito/800 CANNOT consistently dispatch aa COLD from a WARM start (that is, a WARM start triggered from console's SYSTEM RESET will eventually be processed as a COLD-start, instead, once $D013 register reads (as it will) different than its mirror location of GINTLK at the time the reset-handler is invoked)... There's a simple workaround here, of course, but that involves instructing the OS (externally) how to dispatch a WARM or COLD restart for Incognito.

 

Excuse my colorful English, but... WTF is going here (!?)  Is there anything we are missing from this picture?

 

Edited September 10, 2019 by Faicuai

[_The Doctor__]

isn't this behaviour not akin to when press the reset key on a 130XE super fast and slightly random and it does a cold start as opposed to a warm start?

[Rybags]

The accidental cold start is a bug that exists on XL and XE - if anything I find it easier to produce on XL since the XE performs reset when you release the key, XL when you press it.

 

The bug occurs because Page 3 is cleared before the warmstart magic numbers are restored, so if you press Reset in that in-between time, the OS won't see the magic numbers and just think a coldstart is required.

 

I don't have an Incognito but don't see why it should produce floating data on TRIG3 - that would be a critical bug which should in theory produce lockups or restarts (depends on OS revision) - the exact contents are stored in the Ram-based shadow on cold/warmstart and the Stage 2 VBlank compares the value each time it executes.

[flashjazzcat]

I see no reads of GINTLK in the OS reset handler - only in the stage 2 VBlank handler.

[Rybags]

There's a compare - LDA $D013 / CMP $3FA - to detect if cart state changed from what was detected at coldstart.

On the later OS revs that just lockup that's required to perform the coldstart.  On the earlier one, the VBlank code would just jump straight to a coldstart.

Likely it changed since you'd get an unwanted coldstart if you wanted to swap one cart for another.

[flashjazzcat]

13 minutes ago, Rybags said:

There's a compare - LDA $D013 / CMP $3FA - to detect if cart state changed from what was detected at coldstart

Yes but this appears to take place only in the VBI handler, so happens 50/60 times a second regardless of whether one pressed RESET or not.

[Rybags]

It's in the warmstart code also - look around $C290 (if using Rev 04 XL Rom)

[flashjazzcat]

5 minutes ago, Rybags said:

It's in the warmstart code also - look around $C290 (if using Rev 04 XL Rom)

Yes: you are correct!

 

[Faicuai]

Just to make sure we don't lose track of the two topics we have at play here:

 

1. Presumable disappearance of dual floating data-buses on 800/Colleen made, in lieu of a single data-bus, 130XE style (?)
2. Floating-data on direct readouts from TRIG3 while running Incognito on XL/XE mode (this is HUGE !)

 

After careful examination of the OS code (over and over, while working on the right-cart booting extensions for XEr04 OS, exclusive for Incognito), I came to the conclusion the ONLY reason that prevents Incognito from locking-up on such OS-loads is the fact that the OS DOES NOT enforce the intended values for GINTLK (derived from TRIG3) during its TRIG3<=>GINTLK equivalence test. It does NOT test for "1" or "0", with the exception of the cart boot-manager (a one-time check of presence of a cart with executive privilege, during system boot, right at $C471, where a SPECIFIC value of ZERO is tested for TRIG3).

 

In other words, Incognito works because the OS only tests for "DIFFERENT THAN" conditions between TRIG3 and GINTLK, and, lo-and-behold, floating bus-data meets that requirements, as long as the SAME floating-data is always held on the bus when specifically reading from it... Hence, this may explain why the unified 130XE data-bus model is in use, and why it appears as well on Colleen mode (this pure speculation, on my side)

 

However, what I find in profound contradiction (to above point) is that, if you fire up EYE2, then type "G" and type $D013, and then carefully watch the readout values, you will notice that they drift ALL OVER the place, being $D0 the most common one, and then a variety of others showing as well... and still the system DOES NOT crash (!!!)

 

Personally, I find this MIND-BOGGLING, to say the least...

 

Edited September 10, 2019 by Faicuai

[_The Doctor__]

once the system is up and running why would you think the floating values would bring it back down? It's expected the values change after the process is completed...  on a lighter note... nice random number generators!

[Faicuai]

1 hour ago, _The Doctor__ said:

once the system is up and running why would you think the floating values would bring it back down? It's expected the values change after the process is completed...  on a lighter note... nice random number generators!

 

Because of this (booted Monkey Wrench II on right-port, on XLXE mode, and listed ROM code):

 

 

Cartridge equivalence check begins at $C123 with LDA $D013 (being $D0 the last byte left and floating on data-bus). Then a compare with GINTLK (initial low-ram copy held at $03FA), and then a check for "NOT EQUAL" (no enforcement of any specific value, just check non-equal condition).

 

NOTICE that we are at IVN5 stage of OS IVNM (Immediate Vblank NonMaskable interrupt process). Supposedly this is happening EVERY fricking V-Blank (!!!)

 

If you run this on my 800XL/Ultimates, they will ALWAYS read a solid $00 or $01 value. That is, I could not detect floating-data on $D013 with the tools I read the register.... VERY different behavior, though...

Edited September 10, 2019 by Faicuai

[Rybags]

A value other than 0 or 1 so long as it stays constant would result in a stable system - though potentially could cause problem with software that tests for a cartridge presence by TRIG3 (I doubt there'd be very much at all).

Though to me it's a mystery why any floating/address return would need to be implemented in always populated IO space addresses.  I'd class it as a bug needing attention.

Edited September 10, 2019 by Rybags

[Faicuai]

1 hour ago, Rybags said:

A value other than 0 or 1 so long as it stays constant would result in a stable system - though potentially could cause problem with software that tests for a cartridge presence by TRIG3 (I doubt there'd be very much at all).

Though to me it's a mystery why any floating/address return would need to be implemented in always populated IO space addresses.  I'd class it as a bug needing attention.

Correct.

 

So therein lies the miracle (e.g. betting on a floating $D0 anywhere and every time an LDA $D013 issued from ROM, or from $C000-$FFFF address space), and, yes, floating-data on a populated address space is a mystery, because $D013 should be linked to LEFT-cart port address space ($A000-$BFFF), precisely where Basic resides (whether banked-in from ROM or from external cart!)

[Faicuai]

On 9/10/2019 at 5:25 PM, Faicuai said:

Just to make sure we don't lose track of the two topics we have at play here:

 

1. Presumable disappearance of dual floating data-buses on 800/Colleen made, in lieu of a single data-bus, 130XE style (?)

(...)

 

Thinking tonite, about issue #1, above, I just wonder if there are any active Incognito users here that have a REAL, ORIGINAL copy of WARGAMES (not "Computer War" stuff, but instead the real "Wargames" title) and attempt to run it in Colleen mode.

 

According to my presumptions, it should CRASH. Is anyone here in the position to check this, so we can discard or confirm issue #1?

[Rybags]

D013 in fact is a GTIA register and really it's a mystery why any addon would want to interfere with what comes from the legacy IO space (though some stuff like overriding PAL register might come in handy).

[flashjazzcat]

Possibly because the add-on has an internally implemented cartridge (SDX).

[Rybags]

I should also have noted - the TRIG3 register is just a sense input, it doesn't get mapped to the cart space (without checking the schematics I'm guessing it's just a combination of RD4/RD5)

[flashjazzcat]

TRIG3 obviously doesn't get mapped to the cart space, but it provides functionality which is not present on the 800 computer (cartridge ROM sensing in XL/XE mode as opposed to joystick 3's trigger in 800 mode). That's why it's managed by the CPLD.

 

[Faicuai]

TRIG3 readings do not float on the XL/XE data bus. 

 

On XL/XE platform, GTIA's TRIG3 input seems to be "wired" to RD5 physical line on XL/XE cart. port (that should be "LEFT" cart port on 800).

 

Therefore, if managed by CPLD on 800-i (XL/XE mode), it should read "1" when an actual physical ROM is present on cart. port (that equates to Joy.3 button DE-pressed), or reads "0" if cart. is physically absent on cart. port. NOTE that Basic ROM DOES NOT seem to count here, it does not move TRIG3.

 

The above is what should be emulated on $D013 location, by definition, when operating the 800 in XL/XE mode. HOWEVER, I've just thought about this (reading all of the above comments), and it is quite difficult at this point not going back to recent day's review of reading Joysticks 3 & 4 on 800 while running on XL/XE (which we now know is perfectly possible).

 

So if we stitch all of the above together, now the relevant question becomes:

• it is possible for CPLD to emulate actual $D013 (TRIG3) behavior on XL/XE mode (RD5 "virtual" wiring to GTIA's TRIG3), while, at the same time, reading TRIG3 inputs from Joystick 3 (&4) per underlying 800 HW (ACTUAL wiring of Joystick3 input into GTIA)?

 

That's they key to the riddle. Out of curiosity, I am going to execute Candle's PORTB setup sequence (to enable readouts from Joys3&4 on XL/XE mode) and then check $D013 behavior. If I can't see any difference, I would be more inclined to think we do have a HW-emulation bug or issue here, that needs immediate attention.

Edited September 12, 2019 by Faicuai
accuracy, fat-finger typos...

[Faicuai]

41 minutes ago, Faicuai said:

TRIG3 readings do not float on the XL/XE data bus. 

 

On XL/XE platform, GTIA's TRIG3 input seems to be "wired" to RD5 physical line on XL/XE cart. port (that should be "LEFT" cart port on 800).

 

Therefore, if managed by CPLD on 800-i (XL/XE mode), it should read "1" when an actual physical ROM is present on cart. port (that equates to Joy.3 button DE-pressed), or reads "0" if cart. is physically absent on cart. port. NOTE that Basic ROM DOES NOT seem to count here, it does not move TRIG3.

 

The above is what should be emulated on $D013 location, by definition, when operating the 800 in XL/XE mode. HOWEVER, I've just thought about this (reading all of the above comments), and it is quite difficult at this point not going back to recent day's review of reading Joysticks 3 & 4 on 800 while running on XL/XE (which we now know is perfectly possible).

 

So if we stitch all of the above together, now the relevant question becomes:

• it is possible for CPLD to emulate actual $D013 (TRIG3) behavior on XL/XE mode (RD5 "virtual" wiring to GTIA's TRIG3), while, at the same time, reading TRIG3 inputs from Joystick 3 (&4) per underlying 800 HW (ACTUAL wiring of Joystick3 input into GTIA)?

 

That's they key to the riddle. Out of curiosity, I am going to execute Candle's PORTB setup sequence (to enable readouts from Joys3&4 on XL/XE mode) and then check $D013 behavior. If I can't see any difference, I would be more inclined to think we do have a HW-emulation bug or issue here, that needs immediate attention.

Oh, boy!

 

Well, it seems we have some news (and no news), here:

 

1. Executing PORTB setup sequence to read Joys3 & 4, seems to have NO effect, whatsoever, on $D013 (TRIG3) data-float readings.
2. Executing PORTB setup sequence to read Joys3 & 4 reveals that UP-STICK input on Joystick3 is NOT being read (!) It is read, however, on Colleen mode!

 

Seems like another one in the bucket that needs to be checked / fixed, provided that there is enough room on CPLD flash-space.

Edited September 12, 2019 by Faicuai

[candle]

i wonder what is your day job?

if i would guess it would be either managment or sales - don't get offended, just wonder...

 

1. why it should have any?

2. in xl/xe mode system won't allow you to turn itself off, hence you won't read joy 3 up status, unless you will take over the controll completly, but this will reuqire custom piece of assembly code

 

[Faicuai]

1 hour ago, candle said:

i wonder what is your day job?

if i would guess it would be either managment or sales - don't get offended, just wonder...

 

1. why it should have any?

2. in xl/xe mode system won't allow you to turn itself off, hence you won't read joy 3 up status, unless you will take over the controll completly, but this will reuqire custom piece of assembly code

 

If you ask because your management is giving you trouble, let me know, I may be able to help. I do work in Management, as I directly oversee money, as well as dealing with Legal. So you can imagine the formula.

 

Now, leaving off-topics behind, and going back to what really matters, here's the list of open questions, condensed (one more time) for your convenience:

1. Is the 800's dual floating data-buses preserved with Incognito, or is it implementing a "unified" data-bus, a-la 130XE?
2. Direct readings from $D031 (TRIG3) under XL/XE mode yield in floating bus-data... They don't read 0 or 1, as expected. Why?
3. Is it possible for CPLD to emulate actual $D013 (TRIG3) behavior on XL/XE mode (RD5 "virtual" wiring to GTIA's TRIG3), while, at the same time, reading TRIG3 inputs from Joystick 3 (&4) per underlying 800 HW (ACTUAL wiring of Joystick3 input into GTIA)?

Hopefully, this would help cutting the chase.

 

[+warerat]

20 hours ago, Faicuai said:

If you ask because your management is giving you trouble, let me know, I may be able to help. I do work in Management, as I directly oversee money, as well as dealing with Legal. So you can imagine the formula.

 

Now, leaving off-topics behind, and going back to what really matters, here's the list of open questions, condensed (one more time) for your convenience:

1. Is the 800's dual floating data-buses preserved with Incognito, or is it implementing a "unified" data-bus, a-la 130XE?
2. Direct readings from $D031 (TRIG3) under XL/XE mode yield in floating bus-data... They don't read 0 or 1, as expected. Why?
3. Is it possible for CPLD to emulate actual $D013 (TRIG3) behavior on XL/XE mode (RD5 "virtual" wiring to GTIA's TRIG3), while, at the same time, reading TRIG3 inputs from Joystick 3 (&4) per underlying 800 HW (ACTUAL wiring of Joystick3 input into GTIA)?

Hopefully, this would help cutting the chase.

 

 

1.  Mainly the latter but there are conditions where accessing ANTIC and GTIA I/O space disables the databus buffer and there are conditions where it is enabled because the personality board, cart slots, PIA, and POKEY need to be connected to the CPU.

2.  Because the logic qualifying when to connect the data bus to the other half that isn't local to the CPU needs a small adjustment.

3.  Yes, the internal I/O decoder select needs a couple more address lines (A5-A7) to qualify when to turn off GTIA so the foldback addresses don't trigger the internal register.

 

Chase ended and mystery solved.

 

[Faicuai]

2 hours ago, warerat said:

 

1.  Mainly the latter but there are conditions where accessing ANTIC and GTIA I/O space disables the databus buffer and there are conditions where it is enabled because the personality board, cart slots, PIA, and POKEY need to be connected to the CPU.

2.  Because the logic qualifying when to connect the data bus to the other half that isn't local to the CPU needs a small adjustment.

3.  Yes, the internal I/O decoder select needs a couple more address lines (A5-A7) to qualify when to turn off GTIA so the foldback addresses don't trigger the internal register.

 

Chase ended and mystery solved.

 

 

Well, I am pretty happy to see that simple questions that have been floating for weeks eventually got (relatively) simple answers, and relatively quickly... I am also surprised that a third-party had to jump in to hand them (that's strange). I remember buying my fleet of Incognitos from Candle, though...

 

In any case:

1. Is Candle in full agreement with your answers?
2. So from your answer in #1, I should conclude that WarGames (floppy-original) will NOT run on Incognito, even in 800-Colleen mode, correct?
3. A5-A7 are (surely) present on 800's Personality slot. Are you talking about a physical change to I/O decoder on-board Incognito, or is it an internal SW (CPLD) fix?

[+orpheuswaking]