|  Post Your Message | |
| |
| | Previous Messages | Posted By
Retroshire
on 2024-05-01
03:34:50
|  Re: Let’s JoyTest! :)
@MCes: another Commodore 16 with broken Latch fixed today with your Phoenix!!! Nice tool!
|
|
Posted By
MCes
on 2021-12-04
10:10:38
 | Re: Let’s JoyTest! :)
Sorry for my absence....
@unclouded
Referencing to the "1 line BASIC joystick test" result:
if a joystick (port 1 OR port 2) is detected on both columns than the port is faulty, but (if the keyboard is detected correctly) Phoenix can fix the port.
|
|
Posted By
MIK
on 2021-08-26
01:00:31
 | Re: Let’s JoyTest! :)
It's possible for Ted to be damaged and still function. Normally joyports, keyboard and datasette port can be signs of something is up. Sometimes more than one of these will be faulty, and it's been known for all 3 to be faulty at the same time. The only fix is a new Ted chip.
That said, if you press the joystick in different directions and you see random characters printing on screen in BASIC, and not the normal characters as you see in Yape emulator then that's a sure sign Ted is faulty.
Crazy abuse of auto fire and keyboard mashing can also be a cause of joyports and keyboard faults. Like wise Sega pads can damage Ted chips in the same way.
It's also been known for joystick adapters to be wired wrong, this is very 'rare' but some did show up around 15 years ago. Old ones from the 1980's are normally fine though.
|
|
Posted By
unclouded
on 2021-08-25
22:55:34
| Re: Let’s JoyTest! :)
Thanks MCes. With a joystick in the first port:
- Holding UP show 1 in both columns
- Holding DOWN shows 5 in the left column but alternately with 0 and sometimes just 0, but always 0 in the right column
- Holding LEFT show 7 in both columns
- Holding RIGHT show 3 in both columns
- Holding FIRE shows 128 in both columns
The joystick is a Konix Navigator from the 80s and so might have some fractured cores in the cable or dry solder joints.
|
|
Posted By
MCes
on 2021-08-25
07:50:17
| Re: Let’s JoyTest! :)
A quick test for joystic:
10 print joy(1),joy(2):goto10
|
|
|
|
Posted By
MIK
on 2021-08-22
08:47:18
| Re: Let’s JoyTest! :)
@MCes
Yeah that's the idea. If there is room maybe something thicker. The later 48K ZX Spectrums..., they added an aluminium style plate that stat on the main CPU to stop the chips burning out. It stretched across to the back of the mother board. Obviously just a small version for plus4.
I added 3 rubber washers with small holes just big enough for the back screws to go in and added them to the back of the Plus4. Still the original screws, they are lightly pinched tight. Nothing added to the front screws so they are normal but again lightly tight and they all hold it in place, just the back screws the washer were added.
As long as your not moving your Plus4 all the time this does work and adds more space/air, typing like this was fine and you don't see the larger gap when sat in front the Plus4.
|
|
Posted By
MCes
on 2021-08-22
07:58:46
| Re: Let’s JoyTest! :)
@MIK
what about this:
(But.... do it with adhesive copper tape!)
@gerliczer
serious analog/digital hybrid chips has 2 different GND: the Analog GND (Agnd) and the Digital GND (Dgnd) because the digital currents into the chip internal connection to GND pin generate a little voltage that will be overimposed to all outputs (analog outputs included!).
So an efficient "noise cancellation" can be done only sensing the GND pins current.....
At this moment develop a "noise canceller" isn't a priority of mine. (sorry...)
Coming back to the theme:
do you have some suggest about games/SW for testing the 100% compatibility about joystick reading through Phoenix LATCH ?
|
|
Posted By
MIK
on 2021-08-17
12:50:16
| Re: Let’s JoyTest! :)
That's kind of cool and the cardboard has shown up an idea. If it can be done..., you could add a metal plate to the cartridge port shield so it rests on the Ted to help take the heat away.
|
|
Posted By
MCes
on 2021-08-17
09:45:18
| Re: Let’s JoyTest! :)
Without metal cover (or heat sink) the Phoenix can fit inside a PLUS4 (with socket too).
The top of the chip doesn't touch with keyboard, I tried to close the PLUS4 using a ribbon of paper on TED, and the paper remain free to be moved....
|
|
Posted By
BSZ
on 2021-08-16
17:07:30
| Re: Let’s JoyTest! :)
@MCes: Ok, I cheated ....
 I've tried this external latch in the past, and it seemed to be a workable solution.
@Retroshire / @MMS: Not magic, just outsourcing a TED task. 
@siz: I certainly wouldn't solder it! Such a rare & "fragile" animal...
|
|
Posted By
MCes
on 2021-08-16
13:55:51
| Re: Let’s JoyTest! :)
@siz
my hypothesis is to solder a damaged TED on Phoenix to realize the equivalent of a working TED...
Otherwise the damaged TED remain a TED that can't work properly...
|
|
Posted By
siz
on 2021-08-16
12:10:51
| Re: Let’s JoyTest! :)
> solder the TED
* NEVER DO THAT!!! *
The TED is too precious to endanger it by soldering/desoldering. And it dies too easily to have it soldered in.
|
|
Posted By
MCes
on 2021-08-16
10:08:26
| Re: Let’s JoyTest! :)
Thanks for your words,
"Phoenix" is a very new realization,
do I have to explore its possibilities.
I have to try to fit it into a plus4 (mechanically speaking), maybe that will be necessary remove permanently the top of the shield,
or it can be possible to solder the TED on Phoenix without the socket....
I have to try....
|
|
Posted By
MIK
on 2021-08-15
16:07:07
| Re: Let’s JoyTest! :)
Should do as there is a good half inch gap, the copper style flap contact that sits on Ted to take the heat to the shield is bendy.
That said, if heat sinks are on the Ted then I doubt the shield top is being used and that leaves the question what if Ted has heat sinks - the added hight might be a squeeze with the keyboard. If that's a problem then some small spacers sat on the screw holes could lift the top case/keyboard up a few millimetres, may require slightly longer screws to do it.
|
|
Posted By
Retroshire
on 2021-08-15
15:06:37
| Re: Let’s JoyTest! :)
@MCes does Phoenix fits inside the metal Plus/4 TED shield?
|
|
Posted By
MMS
on 2021-08-15
06:19:56
 | Re: Let’s JoyTest! :)
Pure magic! nice work!
|
|
Posted By
Retroshire
on 2021-08-14
14:55:42
| Re: Let’s JoyTest! :)
This is magic! Very nice job.
|
|
Posted By
zzarko
on 2021-08-14
00:10:28
| Re: Let’s JoyTest! :)
"Phoenix: an ESD port protector that can FIX the LATCH failure.... could be interesting?"
Short answer: yes
Long answer: yeeeeeeeeeeeeeeeeeeees
|
|
Posted By
gerliczer
on 2021-08-12
12:18:34
| Re: Let’s JoyTest! :)
@MCes: Cool stuff that Phoenix board. Could you incorporate into that some circuitry mitigating bus noise crosstalk like the LumaFix64?
|
|
Posted By
MCes
on 2021-08-12
08:58:16
| Re: Let’s JoyTest! :)
@BSZ
Ok, I cheated ....
I used a damaged TED with my "Phoenix" circuit, before in transparent mode (generating the "special scan" readings), after this I moved on Phoenix the jumper enabling a physical LATCH onboard for patching the TED latch failure, than the "normal scan" reading was generated....
"Phoenix" is a small board to be installed below the TED, a physical LATCH is placed as HW buffering of the port inputs, and this imply that the TED will be protect from the joystik ports ESD discharges.
A jumper select if this patch has to remain always in "transparent" mode (in this case the TED behaviour will not change, but if TED is joy-damaged it remain joy-damaged).
Moving the jumper the physical latch will be enabled to store the datas with a behaviour that imitate the lost "TED latch behaviour", the result is that the keyboard work, the BASIC function "JOY(" work, your HIDtest264-1.1work....
I have tried a couple of games and they work (I have to do more tests on the games, but I'm trustful).
So, if the damaged TED read the keyboard PERFECTLY than Phoenix can fix it (if your observation about TED port failure is right, and it appear to be right!).
Of course Phoenix is based on your investigation which is a very valuable work!
It's funny that 30 years later these machines have more secrets to uncover...
Phoenix: an ESD port protector that can FIX the LATCH failure.... could be interesting?
  
|
|
Posted By
BSZ
on 2021-08-11
15:38:13
| Re: Let’s JoyTest! :)
@MCes: Your score is the highest! Please add him to the Hall of Fame!
Is this an original, unmodified machine? I can imagine it with my "semi-broken" TED, back in my first computer in 198x. Then the problem was solved by installing a few resistors. But then the TED latch completely broke.
|
|
Posted By
MCes
on 2021-08-11
10:18:15
| Re: Let’s JoyTest! :)
Ok,
who guess how i got this wins a handshake:
@Retroshire , you cannot participate.... 
|
|
Posted By
Hifi
on 2021-06-22
09:10:08
| Re: Let’s JoyTest! :)
Helló,helló Újra Itt vagyok..... Hát mit is mondhatnék..... Előzőleg valaki a Fórumban azt elemezte ..... HA rossz a TED,KI kell cserélni, HÁT én is azt mondanám! Miért.....hát én is elővettem a szervíz gyakorlatban kicserélt TED IC-ket,és persze egy két hardware tesztet végeztem velük. Volt olyan is ami fekete-fehérben,illetve véletszerüen színesen is popázott,és persze a joy portok sem működtek. A grafika, a játékok,a programok TÖKÉLETESEN működtek ,csak a színkezelés szivárvány színekben pompázott (na azért a 121szín jelent valamit.....ugye). Ha valakit érdekel,elköldöm Neki! Hardware szempontból azt a (köcsög) diódás kíválasztást (elnézést a kifejezésért) próbáltam kihídalni, DE eredményt nem hozott (feszűltség emelés)! Azt gondoltam (én kis hülye),talán a "mérnökök" már a NÉGY szintű digitális bemenetet gyakorolják! Akik még nem tudnák, 45év után félvezető és elektronika iparból mentem nyugdíjba (TUNGSRAM(Izzó), MEV, Vishay, BOSCH(ahhhh!). 45év után csak azt mondhatom; ezek a "félvezetőSZŐRNYEK" legyenek minél kisebb hőmérsékleten, betartani a működési feszültségeket (szigoroan!) és persze betartani az ESD védelmet! HA pedig a gyártási TECHNOLÓGIA nem volt betartva (távolkelet....) CSAK az ÚR jóindulatára számíthatunk!!! Üdv.: HiFi of TLT
|
|
Posted By
TLC
on 2021-06-09
06:42:57
| Re: Let’s JoyTest! :)
@BSZ I think it's Bo Zimmerman's 264, http://ode2commies.blogspot.com/2015/07/completing-set.html.
IMHO together with those featured in Commodore 264, that makes 4 known 264s, out of them at least 3 with different setup. Bo's obviously has no 6529B keyport at all. Michael Tomczyk's one has a dead-bugged 6529B, similarly to Crock's V364. And, finally, also Crock's 264 already has a 6529B as would be usual for a production Plus/4 (which likely makes it a late 264 prototype). Interestingly, assy numbers are all identical . I couldn't recognize an EMI filter around the joystick ports on either of the boards (a standard feat for the production Plus/4, damping the buffered data bus line output signals), which suggests that these are still not fully identical to the production model, not even Crock's late one.
|
|
Posted By
BSZ
on 2021-06-08
19:14:35
| Re: Let’s JoyTest! :)
@TLC: For late 6529 extension... Here is a picture of a 264 Mobo:
I don't know where I found the picture, if anyone knows, tell me! But look for the KB 6529 on it!
@MMS: That's right! (Ha fából van a keze, az se baj, csak éljen! )
|
|
Posted By
MMS
on 2021-06-08
18:29:49
| Re: Let’s JoyTest! :)
@BSZ: Only living TED is a good TED.
|
|
Posted By
TLC
on 2021-06-09
05:47:45
| Re: Let’s JoyTest! :)
Maybe I should finally sum up how/why this all works the way it does, from a hardware point of view. Probably also with a bit of history involved, since, there is (as always) a reason behind all this.
First of all, probably anyone ever programming on other platforms (also, people who converted programs from C64) have noticed that the keyboard scan method of the Plus/4 works slightly differently to either the C64 or the VIC-20 (...or, other Commodore machines). Specifically, all the other platforms lack the "sta $ff08" part in the keyboard scan method. The basic method, by itself, is always the same in any of these machines. There is a 8x8 matrix of rows and columns (wires), with key contacts at the intersection points, organized in some clever layout. There is a port circuit, usually a 6520 PIA, 6522 VIA, 6526 ACIA, where one puts out a set of row select bits by writing the value to the port register; and there is another 8-bit port, where one can "read" the columns. This can be clearly seen on both the VIC-20 schematics (see the UAB1 6522 at the upper left part, ports PA and PB), and the C64 (check U1 6526 PA/PB in the middle of the page). For physical reasons, the keyboard matrix lines are always "low active" - that is, a "0" bit (represented by a near-GND voltage level) can bring a column port input to near-GND, and (consequently) read as "0" from the column port input register, once a key contact between the activated row and some particular column is pressed. At first sight, the "TED", the 264 series, is no different. (Someone has generously made a cut-out of the keyboard part of the C16 schematics. There is U13 6529B ($fd30) supplying the row select bits, there is the keyboard matrix, and there are the K0-K7 column inputs on the TED - and that's it.) On second sight, though, there's a difference. As said, there's no equivalent of having to "write" to the input register (the column register) to trigger it to actually read something, on any of the other platforms. Simply there's no such step. But it's needed in the 264 architecture. Why is that? That one apparently goes back to the original plans, when the TED project was conceived.
As it's probably known for most people here, the TED (i.e. the machine as they called it in the early days) was originally to be a small, low-end machine, a "ZX killer", a "9-chip machine", its system properties dictated by the chip designers. 9 chips (as per Tramiel's original order), if one breaks that down, makes a CPU, TED, 2 ROMs, 2 RAMs, 2 RAM muxes, a 7406 for the serial port, and that's pretty much all. Bil Herd has regularly talked about the development of this series. For example, he told somewhere that he in fact added the "10th" chip himself (the reset circuit, a 555). ...Anybody seen the name of the 6529B keyboard port here? Nope, and that's for a reason. Bil has also talked in detail about, that the original plan used the data bus directly, as keyboard row select "port"*. With that, the designers wanted to get rid of one of the two full 8-bit ports otherwise needed for the keyboard matrix scan task. (BTW, Sinclair, for example, has been regularly using such tricks in their machines... maybe, that's also where the idea had originated from**). But, what are the consequences of a plan like that? The data bus obviously is never static. The data bus bits can change states in every bus cycles. (With a shared bus concept like in either the VIC-20, the C64, or, the Plus/4, and in its most basic case, for every CPU clock cycles, two bus cycles are performed; one for/by the CPU, and the other by the video chip). There's no way to write some "static" row select byte to the "data bus" first, and let it wait there until "something" eventually reads the columns, this is not possible. The only way for that, is some clever hack, that "captures" the column inputs' states just at some right minute. This is what's implemented in the TED keyboard input port (i.e. the port circuit behind K0-K7). The sampling of the port is triggered by writing to $ff08. So, effectively the process goes like this. 1.) CPU writes the row select byte "to" $ff08. 2.) As the last cycle of the instruction being executed, the value written to $ff08 is put onto the data bus by the CPU. 3.) This value (in this particular minute) effectively "is" on D0-D7 as voltage levels, and, with that, it's also on the keyboard matrix' row side. 4.) In just some ten- or hundred nanoseconds, the active D0-D7 outputs bring "low" all columns, where there is an active key contact between selected row and column, the voltage levels settle and become available on the K0-K7 inputs of the TED. 5.) After this some-hundred nanoseconds (timing hardwired in the TED), the TED keyboard port latches the K0-K7 inputs into an internal temporary storage. And finally 6.), a later lda $ff08 (or, any other read command) can read out the stored column value from the temporary latch. This is practically all about it .
"Aftermath". As it turned out later, the plan wasn't actually such a brilliant idea. Misusing the data bus for a keyboard matrix row port (especially, connecting long wires to the data bus) made the thing both susceptible to EMI, and made it produce a good deal of electric noise on its own (nothing good if the thing was to pass FCC inspection). The problem was eventually fixed by adding the 6529B to supply the matrix row select side, as we know it today. Interestingly, the joysticks somewhat still retain the original schema - they're not selected by 6529B port bits, they're still fed from two (now, buffered) bits from the data bus, see the U11 gate on the schematics. (With the TTL buffers added, they now prevented EMI from the long joystick wires to interfere with the data bus. I'm not that sure, though, of the RF noise produced by the construct itself.) Maybe, the V364 prototype's wiring could shed a light whether that solution was also "invented" at the time the 6529B was added to the design.***
TL;DR - the TED's keyboard port sampling nature is an artifact of the original (minimalistic) system design plan of the machine, which intended to (mis)use the data bus as keyboard matrix row select output port. The solution effectively works by sampling the K0-K7 inputs in a particular (writing) bus cycle, triggered by a write operation to the $ff08 register.
How and why it breaks? The "why" part is most likely due to ESD. The "how" part, is still unclear. As it's seen, the port still keeps working, only its "sampling" part is affected. No idea how that happens. How it works? In fact, the "sampling" part has a small additional feature, in that it not only samples (latches) the value on K0-K7, but also incorporates a "strong" pull up resistor, which is activated for a short time early in every K0-K7 sampling cycles. Maybe, this is an added feature to meet timing requirements. After all, voltages in the keyboard matrix all have to settle in a very short time, given the construct practically all clocked at the frequency of the bus cycles. This pull-up activation nature can be observed by inspecting the K0-K7 inputs on the oscilloscope, and, on a perfect TED, it evidently only happens upon $ff08 write cycles. On the other hand, with a broken TED, the activation of this pull-up can be observed on every bus cycles. It can be concluded then, that a broken TED executes the K0-K7 sampling on every bus cycles (regardless to any other factors).
All the tricks outlined to read the joysticks on a broken TED, and, to avoid the joysticks to interfere with key scan on a broken TED, are just consequences of the broken TED sampling the K0-K7 inputs on every bus cycles (plus, the nature of the port to sample the K0-K7 inputs one bus cycle prior to the value becoming available for read from the $ff08 register).
* Interview with Bil Herd , also 264/TED/Plus4 Story on cbm-hackers .
BTW, if one covers the U13 6529B on the schematics of the production machine, (s)he'd pretty much get the original planned layout, with the data bus lines going straight to the keyboard connector pins. As a matter of fact, the known "developer units" like Prototype P15 and Prototype P19 from early Aug. 1983, both follow the original TED concept, i.e. neither of them have a 6529B, a PLA, nor any of the added extra ROM TTL logic. Crock's Commodore V364 prototype already has all the bells and whistles we know today (PLA, extra ROM logic, ACIA) and even more, but still only has the 6529B "dead bugged" in place of some passive components, which shows that the story of fixing the keyboard and joystick EMI problems must have happened very, very late; maybe late '83 or early 1984, and also obviously later than the invention of the fattened TED line-up models. Also, a comment found in the sources of the 264 series Kernal, http://www.zimmers.net/anonftp/pub/cbm/src/plus4/ted_kernal_basic_src.tar.gz, "** 01/17/84 mod for new keyboard port " at the $DB70 ROM routine (found beside the sta $fd30 instruction), suggests that "final" ROM support for the modified (6529B incorporated) keyboard hw layout was only added as late as January 1984, already past the 1984 Winter CES.
** At the same time, Sinclair never messed with using unbuffered system bus lines to connect joysticks, which might show why the method still worked for them, but not for Commodore.
*** Would be an interesting part to know. From Bil's story, EMI apparently only popped up as a serious problem, when they first got around to test the new (264 specific) joysticks. As he said, he invented and implemented the fix (the 6529B row buffer) in a matter of hours, and especially stressed why exactly he chose the 6529B / ruled out the use of any TTL gates for that role. Would really think the joysticks were still parallel connected to the keyboard matrix at this point, and the "fixed" prototypes simply activated them by using the 6529B.
@Mad you can detect the "broken" TED port by testing for a value change in the $ff08, while making sure that you're not doing $ff08 writes. Unfortunately, with no keys pressed / no joysticks moved, there's no activity that you could observe to change. The port problem can probably still be detected "hidden", parallel to some valid keyboard activity (at some point in your prod, where, running an additional detect routine is still not "critical").
|
|
Posted By
BSZ
on 2021-06-08
18:21:49
| Re: Let’s JoyTest! :)
@Mad: In my opinion, the broken TED is not detectable without any user interaction. But for simple detection enough to press any key. ("Press Any Key to Continue..." ) Simple detecting code:
LDA #%00000000 ;Select all Keyboard rows
STA $FD30
LDA #%11111111
STA $FF08
CMP $FF08 ;Any key pressed?
BEQ .NoKeypress_DoItAnything
The check comes from here:
LDA #%11111111 ;Deselect all Keyboard rows
STA $FD30
CMP $FF08 ;All Keyboard column released without $FF08 write cycle?
BEQ .BrokenTed ;If yes, TED Keyboard Latch is broken
But... What is this check for..? Handling a broken TED also works for a good TED, I think. No need to program them separately. Keyboard control is just an idea; probably no problem at this time for a required Joystick.
@MCes: Only good TED is good news!
@MMS: PLA and CPU faliure is significant higher than full faulty TED, at least that's been my experience. If only the latch is bad, we are happy!
|
|
Posted By
MMS
on 2021-06-08
16:20:51
| Re: Let’s JoyTest! :)
MCes! Lucky you!
OFF
There was a really talented guy, who started to work on a "new 364" project, but abaddonned the 264 platform due to repeating TED (?) defects and dying machines.
Maybe he was less lucky than you, or maybe he had a PLA or ROM defects, but automatically concluded a TED failures...
|
|
Posted By
MCes
on 2021-06-07
08:37:37
| Re: Let’s JoyTest! :)
It is very interesting .....
Thanks to the guys who investigate their TEDs!
Unfortunately I have not broken TEDs (what did I write ????) for analyze this behaviour.
|
|
Posted By
Mad
on 2021-06-07
08:38:13
| Re: Let’s JoyTest! :)
@BSZ: Wow this is great thanks a lot for that! You wrote there, that it would be better to have only keyboard usage in case of a broken TED. So this brings up a question which maybe not answered. Do you think there is a possibility to automatically detect a broken TED without doing anything physically with the joystick device itself? Most probably you would have done this already for yourself, if it is somehow possible in any way, I think..
I try to implement it, but the thing with keyboard is scary, maybe it's not possible to do broken TED versions then.. But anyway thanks for the description and the routine, who would have thought that this is possible :)!
|
|
Posted By
BSZ
on 2024-08-24
05:14:12
| Re: Let’s JoyTest! :)
Ígértem pár kiegészítést a témához…
Először is: elég konzisztensnek tűnik a „hibás” TED-ek viselkedése. De ez egy olyan teszt, ahol nincs „deadline”! Nevezni ér ám a későbbiekben is bármikor! Viszont… A kérdés az, hogy most akkor mindenki álljon neki a meglevő programokat „patch”-elgetni, hogy működjenek a „hibás” TED-es gépeken is? Szerintem NE! Régen nagyon sok olyan C16-os / plus/4-es felhasználó volt, akinek egyáltalán nem volt Joystick-je (talán a „szabványos” csatlakozónak hála… ), emiatt szerintem inkább az a fontos, hogy a játékoknak legyen csak billentyűzettel is játszható üzemmódja. Persze ha valaki maximalista, felkészítheti a programját ennek a szituációnak a kezelésére is, de ez azért ne legyen elvárás.
Itt feljebb már kitárgyalódott a lényeg, ami ugye az, hogy a „rossz” TED nem csak az $FF08-as regiszter írásakor tárolja a bemenetein jelen levő adatot, hanem minden memóriaciklusban megteszi ezt. (Erről – ha valakit érdekel – esetleg írhatok bővebben.) Ha a CPU dupla órajelen jár, akkor az előző ciklus az pont az olvasó utasításban szereplő ($FF08-as) cím felső BYTE-ja, tehát $FF lesz, ami nem választja ki egyik Joy-t sem. Az egyszeres órajellel pont ide sikerül „becsempészni” egy olyan BYTE-ot, ami a kívánt Joy-t ki tudja választani. Annyi viszont fontos, hogy itt a TED-nek ne legyen „más dolga”, mert akkor azt fogja olvasni a kívánt adat helyett. Ezt a „más dolgot” úgy lehet a legkönnyebben elkerülni, ha egyrészt a kép alsó/felső keretén fut a rutinunk, másrészt a rasztersoron belül is elkerüljük a kép jobb szélét (azt, ahol éppen kezdődik a keret az aktív tartalomnál). Ehhez én egy egyszerű rutint csináltam. A lekérdező rutin megszakításban fut, $0D0 raszterpozícióra van az időpont állítva, ahol (a megfelelő előkészületek után) az alábbi program indul el:
LDA #%11111111
STA $FD30
LDA $FF13
PHA
ORA #%00000010
STA $FF13
STA $FF3F
LDA $FFFF
PHA
Ez kitiltja a billentyűzet összes sorát, hogy annak a nyomkodása ne okozzon Joystick-irány érzékelést. (Ezt a nyitó posztban említettem; több (megfelelő) gomb lenyomásával még így is lehet „fantom” Joy irányt produkálni, de ez nem a „hibás” TED lekérdezésének a mellékterméke, a „jó” verzió ugyanígy működik.) Aztán 1×-es órajelre kapcsol a kód, meg bekapcsolja a RAM-elérést. (A TED, amikor azt a memóriacímet olvassa, amit itt használatban van, azt ugyanabból a memóriából teszi, mint a CPU is tenné.) Illetve állapotot ment, hogy a végén majd vissza lehessen állítani. Utána jöhet az olvasás:
LDX #%11111011 ;Joy Lo
LDY #%11111101 ;Joy Hi
LDA $FF1D
.W1 CMP $FF1D
BEQ .W1
STX $FFFF
STX $FF08
LDA $FF08
STA $0C00
STY $FFFF
STY $FF08
LDA $FF08
STA $0C01 All: 32 single clock cycles
Ez a rutin megvár egy új rasztersort, ekkor a programfutás biztosan a sor elején van, „messze van még” a sor vége (ahol a TED-nek „más dolga van”, memóriát frissít, nem $FFFF-et olvas). Utána $FFFF-be és $FF08-ba is be van írva a Joy kiválasztó BYTE, utána az így vagy úgy tárolt érték van visszaolvasva $FF08-ból. Amennyiben a TED „jó”, akkor az $FF08-ra íráskor tárolt változat lesz $FF08-ban, ha a TED „rossz”, akkor az előző ciklus, de ott is ugyanaz a Joy van kiválasztva. Azaz: ez a rutin mind a „rossz”, mind a „jó” TED-nél a megfelelő adatot adja vissza. A rasztersorban elvileg belefér mindkét Joy állapotának a lekérdezése, a beolvasott állapotok itt a képernyő tetejére íródnak ki.
A Joy-ok lekérdezése ennyi, viszont itt fontos megemlíteni egy dolgot. A „rossz” TED-nél a működési mód miatt előfordulhat az az eset, hogy a billentyűzet lekérdezésébe a Joy mozgatása „fantom” billentyű-lenyomásokat produkál. (Ha a lekérdezés alatt a CPU-t egyszeres órajelre kapcsolja a TED, akkor az általa olvasott adat engedélyezheti a billentyűzet mellett az egyik/mindkét Joy-t is!) Tehát ha egy program egy időben akar Joy-t és billentyűzetet is vizsgálni, akkor a billentyűzet lekérdezését is ennek megfelelően kell megcsinálni! Erre itt a folytatás:
LDA #%00000000 ;Double Clock mode selected
STA $FF13
LDX #%11111111 ;No Joy line selected
LDA $FF1D
.W2 CMP $FF1D
BEQ .W2
LDA #%01111111
STA $FD30
STX $FF08
LDA $FF08
STA $0C28
LDA #%10111111
STA $FD30
STX $FF08
LDA $FF08
STA $0C29
LDA #%11011111
STA $FD30
STX $FF08
LDA $FF08
STA $0C2A
LDA #%11101111
STA $FD30
STX $FF08
LDA $FF08
STA $0C2B ;4 All: 72 double clock cycles
Ez először visszakapcsolja a dupla-órajelet, majd vár egy új rasztersorra. A kereten így közel dupla annyi órajel lesz mint egyszeres módban, emiatt egy rasztersorba 4 billentyűsor lekérdezése is belefér. Az LDA $FF08 utasításoknál így mindig a cím felső BYTE-ja (azaz $FF) lesz a buszon az olvasást megelőző ciklusban, így egyik Joy sem lesz aktív a lekérdezésnél. Hogy ez a feltétel teljesüljön a „jó” TED esetén is, ezért minden egyes sor vizsgálatánál $FF van $FF08-ba írva! A fenti sorok 4 billentyűsort olvasnak be (és az eredményt kirakják a képernyőre jelenleg), a másik 4 sor lekérdezése ugyanez, kezdve az új sor várásával. (Értelemszerűen az $FD30-ba írandó értékek mások.)
A fenti kódból a nem vizsgálandó Joy-ok / billentyűsorok tetszés szerint elhagyhatók. Ezután már csak az „elrontott dolgok” visszaállítása van hátra:
PLA
STA $FFFF ;IRQ vector restore
PLA
STA $ff13 ;Chargen. address + speed restore
AND #%00000001
BEQ .RAM
STA $FF3E ;ROM/RAM restore
.RAM RTS
Itt az elrontott megszakítás vektor / $FF13 / ROM/RAM van visszaállítva a kiindulási állapotra. Remélem nem kavartam el semmit. A fenti kódból csináltam egy letölthető / próbálgatható változatot:
JoyBKQuery_for_badTED.zip
Ez – a mostani tesztelésem szerint – működik, de remélem a fentiekben sem írtam el semmit.
| Re: Let’s JoyTest! :)
I promised some supplementary information...
First of all, the behaviour of "failing" TEDs seems to be quite consistent. However, this is a test without deadline. Feel free to "enter the competition" whenever it is convenient for you in the future. Now the question is if everybody should start patching their programs to run of machines with "failing" TEDs? In my opinion NOT. Back in the old days, there were a lot of C16 and plus/4 users who had no joystick whatsoever, thanks to the "standard" connector maybe , therefore it is more important to have keyboard control in games IMHO. Perfectionists should feel free to prepare their programs to deal with such a situation but that shouldn't be a requirement.
The important details are already been discussed here above , namely that "broken" TEDs store input data not only at the writes of register $FF08 but at every memory cycle. If there is interest in this topic I may write up some more details about. When the CPU runs at double clock then the preceding cycle will be exactly the high byte of the read instruction's address ($FF08) which does not select any joysticks. It is possible to "foist" a byte suitable to select the desired joystick here while running at single clock. It is very important that TED should have no other task because that will interfere with reading the necessary data. It is the easiest to avoid any so called other tasks by running the code in the top or bottom border while avoiding the right side of the screen, that is the part where border starts in the open screen area. I wrote a simple routine for that. The query runs in interrupts triggered at raster position $0D0 where after the necessary preparations the following code runs:
LDA #%11111111
STA $FD30
LDA $FF13
PHA
ORA #%00000010
STA $FF13
STA $FF3F
LDA $FFFF
PHA
This deselects all keyboard line so key presses won't cause interference in detecting joystick directions. I already wrote in the OP that pressing some (appropriate) keys at the same time allows generating "phantom" joystick directions independent of the TED being "broken" or "good". The the code sets single clock and pages away the ROM. The address in use in this code is read from the same source the CPU would be reading it. Furthermore, it saves some states to be restored later. Next comes the querying:
LDX #%11111011 ;Joy Lo
LDY #%11111101 ;Joy Hi
LDA $FF1D
.W1 CMP $FF1D
BEQ .W1
STX $FFFF
STX $FF08
LDA $FF08
STA $0C00
STY $FFFF
STY $FF08
LDA $FF08
STA $0C01 All: 32 single clock cycles
This routine waits for the next raster line to make sure that the end of the line, where TED has the different task of refreshing memory instead of reading $FFFF, is still "far away". After that joystick selection byte is written into $FFFF and $FF08, after which the value store in one of the previous ways will be read out from $FF08. If TED is "good" then the one stored at the time of writing $FF08 otherwise the one from the preceding cycle as both select the same joystick. This routine returns the proper data independent of if TED is "good" or "broken". Theoretically it is possible to read the state of both joysticks in one single raster line; the result of which being written to the top of the screen in the routine.
That is all about querying the joysticks but it is important mentioning another thing. The mode of operation in case of a "broken" TED may result in joystick movement generating "phantom" key presses when querying the keys. If TED sets single clock for the CPU during querying it may cause enabling one or both joysticks as a side effect of the read data. So if a programme wants to query both the joysticks and the keyboard at the same time then querying the keyboard must be written accordingly. For that, here is the continuation of the code:
LDA #%00000000 ;Double Clock mode selected
STA $FF13
LDX #%11111111 ;No Joy line selected
LDA $FF1D
.W2 CMP $FF1D
BEQ .W2
LDA #%01111111
STA $FD30
STX $FF08
LDA $FF08
STA $0C28
LDA #%10111111
STA $FD30
STX $FF08
LDA $FF08
STA $0C29
LDA #%11011111
STA $FD30
STX $FF08
LDA $FF08
STA $0C2A
LDA #%11101111
STA $FD30
STX $FF08
LDA $FF08
STA $0C2B ;4 All: 72 double clock cycles
First it restores double clock then waits for the next raster line. There will be almost twice as muck clock cycles in the border as in single clock mode allowing the query of up to 4 keyboard rows. There will always be the high byte of the address ($FF) of the LDA $FF08 instruction on the data bus in the cycle preceding the keyboard row query, so no joystick will be active during the read. To make this condition met in case of "good" TEDs there is $FF written into $FF08 at every keyboard row queries. The code above reads 4 rows and put the results to the screen at this time. The query of the other 4 rows is the same including the wait for next raster line. The values to be written to $FD30 are obviously different.
You may omit the joysticks and rows not needed to be queried at will. Now all that's left is restoring the things that were messed up:
PLA
STA $FFFF ;IRQ vector restore
PLA
STA $ff13 ;Chargen. address + speed restore
AND #%00000001
BEQ .RAM
STA $FF3E ;ROM/RAM restore
.RAM RTS
Here there are the tampered interrupt vector, $FF13 value and ROM paging state restored to the original state. I hope I didn't mix up anything. There is a programme to download and test this routine:
JoyBKQuery_for_badTED.zip
That should work or at least that's what my test indicates so far. I hope I didn't make any clerical errors either.
|
|
Posted By
Mad
on 2021-06-04
08:53:39
| Re: Let’s JoyTest! :)
@TLC,BSZ: thanks for clearing this!!
|
|
Posted By
TLC
on 2021-06-04
04:54:01
| Re: Let’s JoyTest! :)
@BSZ I still merely talked about digital logic, not electronics
@Mad your assumption is correct. Yes, the borders are all idle fetches in single clock mode, except for 5 memory refresh out of every 57 cycles of a line. (Pretty easy to hit a suitable "place" on a line once in single clock mode, no need for cycle exact timing whatsoever. Roughly speaking, memory refresh cycles are always performed around the first columns of the right sideborder. The rest of the line is all fine). Writing the selector byte to both $ffff and $ff08, and performing the read from $ff08 on/after a TED idle fetch cycle, should do the trick for both normal and damaged TEDs. (...I haven't yet tested that in practice, you might want to wait for BSZ to share his experiences). Saving and restoring the high byte of the IRQ vector in $ffff is an added requirement, of course, if interrupts are to be used in your code. On a related note: you can avoid the joysticks to interfere with keyboard scan even on damaged TEDs in a similar fashion. (That one is actually even easier than reading the joysticks on a bad TED. The trick is, that, in double clock mode, the bus cycles are used solely by the CPU, and, an lda $ff08 actually looks like "ad 08 ff *value read from $ff08*" on the data bus. As you can see, the value on the bus before the $ff08 read cycle, which is, in our case, also the "selector byte" for the joysticks on damaged TEDs, will be ultimately always $ff, regardless to any other circumstances. That means, if you perform the read from $ff08 on double clock cycles, the joysticks would uniformly never play a role. Writing $ff to $ff08 is still needed to avoid interference on regular/non-damaged TEDs, of course).
|
|
Posted By
BSZ
on 2021-06-03
20:11:23
| Re: Let’s JoyTest! :)
@crock: Thank you for the testing! Seven out of seven so far! Sounds pretty consistent...
@TLC: Thank you for the description! I would have written a short novel for sure!
@Mad: The combined query works, but I'll write more about that later. There are pitfalls.
@Luca: Good news! Thank you for your effort!
|
|
Posted By
Luca
on 2021-06-03
12:25:07
 | Re: Let’s JoyTest! :)
Checked the three Plus/4s currently mounted on: no transparency. If in case, I could test the others too...
|
|
Posted By
Mad
on 2021-06-03
12:40:39
| Re: Let’s JoyTest! :)
@gerliczer: Thanks! That was my point in asking if I may combine the "brokenTED" and "workingTED" routine into one. A routine which just works for broken TED would not be what I would need.. Maybe I didn't understood it.. That's why I was asking.. Maybe only the $ffff write is needed for the normal working TEDs, too? I would need a very small routine to cover both cases (broken/notbroken).. Seems like in the border no "wait for.." is needed, because idle byte is read anyways (like on VIC)? This hardware related stuff is beyond my knowledge, sorry.. Memory refresh is done in every scanline, or? Then testing $ff1e may help. Got no info about that, yet.. I really would like to implement this routine in a tiny version for further projects..
|
|
Posted By
gerliczer
on 2021-06-03
11:39:09
| Re: Let’s JoyTest! :)
As far as I understood, you are mistaken Mad. STA $FF08 is superfluous because latch control is damaged therefore you can't use it in those TEDs. You put the row select value into the TED idle byte $FFFF (which is a bit inconvenient) then wait for a TED idle fetch. That is a similar mechanism as VIC-II idle fetch from $3FFF/$7FFF/$BFFF/$FFFF depending on the VIC-II bank. That idle fetch will trigger the latch properly so LDA $FF08 will read from the joystick. You have to be careful to time it in such a way that memory refresh will not interfere with the idle fetch that sets up the latch.
|
|
Posted By
Mad
on 2021-06-03
12:50:36
| Re: Let’s JoyTest! :)
Wow this is awesome! I dunno if I understood all. Mainly the code snippet above seems to be doable for our projects.. Have to check if it doesn't interfere with other stuff..
is a
lda #$x2
sta $ff13
lda #selctorbyte
sta $ff08
sta $fffff
lda $ff08
possible in the border? To cover both the broken one and a normal working one? I didn't understood the "wait for ..." part there..
Another question would be if this is a common issue (of broken TEDs)..
Maybe I didn't understood it at all! Sorry then..
edit: The wait part is a bit more complicated, or? Would need a very minimal solution (bytewise) for this.. Maybe I ask later for help (testing) then..
|
|
Posted By
TLC
on 2021-06-03
10:13:47
| Re: Let’s JoyTest! :)
@BSZ it looks like a case of perfect match so far, doesn't it? 
@crock Sure!
TL;DR: probably, the most convenient method is to misuse the TED idle fetches to supply the joystick selector bits. A.k.a.:
sei
sta $ff3f
lda #$d2
sta $ff13
lda #*selector byte* ; usually $fb or $fd
sta $ffff
*** wait until the next statement runs in a TED idle fetch period, like, in the vertical border, also avoiding memory refresh cycles ***
lda $ff08 ; you got the joystick's state byte
...
Explanation:
The TED keyboard latch becomes "transparent" when it's damaged, at least that's what we have thought. Apparently, that's not the entire truth. As it looks, the TED keyboard latch is designed in a way that it'd do a port latching in every bus cycles (i.e. in every CPU double clock cycles, or, twice in every single clock cycles), but this operation is inhibited, and only effectively done when the $ff08 register is written. With a damaged port, this inhibition is "gone". Using an oscilloscope, it looks evident that a "bad" TED keyboard port in fact samples the K0-K7 inputs once in every bus cycles, regardless to writing $ff08 or any other operation done. The point here is that the port doesn't become "transparent" in the true sense, sampling is still done in every bus cycles. It's known from other MOS port designs (including the 8501 CPU port), that port input sampling is typically done at least one bus cycle before a read operation can read this particular value from the input register. In the case of the "bad" TED, that means that the value read from $ff08, is always sampled one bus cycle _prior_ to reading $ff08. With the joystick selector bits having to be supplied at the time the TED samples the keyboard port, this means that the selector byte is in fact the byte, that happens to be on the data bus one bus cycle prior to reading $ff08. This bus cycle is either performed by the CPU (in double clock mode), or the TED (in a single clock mode). For a deterministic result, a deterministic byte must be "supplied" at the right time, i.e. in the bus cycle prior to reading $ff08. For that, as said, probably the most convenient way is to switch to single clock mode, write the "selector" byte to $ffff (from where the TED idle fetches are done), wait until the TED performs idle fetches, and read $ff08. For a counter-test, I have also created code that performed the read in double clock mode (having the CPU read a pre-set byte before it performed the read from $ff08... it used a jmp ($ff07), with $ff07 set-up purposely), but that method is probably not convenient to use in practice.
The only remaining question for me, is how (on Earth...) ESD only typically breaks the latch "inhibition" feature, not the port inputs. Surely haven't seen anything similar before.
|
|
Posted By
crock
on 2021-06-03
09:01:22
 | Re: Let’s JoyTest! :)
Well, this is 10 degrees of awesomeness!!!
I have many bad TED's and had 3 to hand that I new had broken latches. These are the culprits.
TED A works with the new algorithm.
TED B works with the new algorithm.
and TED C works with the new algorithm.
You have to tell me how this works. I am very familiar wit hthe issue from my work on Diag264, so would love to somehow incorporate this.
|
|
Posted By
TLC
on 2021-06-03
08:15:45
| Re: Let’s JoyTest! :)
On a slightly related note: apparently, Frank Wolf has created high resolution decap images of both the 8360R2 and 8360R3; https://www.patreon.com/posts/twins-always-42658520 . He and Dieter Müller have already reverse engineered the 8501 CPU (i.e. the specific parts with respect to other HMOS-II 6502 derivatives), http://forum.6502.org/viewtopic.php?f=4&t=6617 Maybe there's some hope that one day they / somebody else finally reverse engineer the TED as well.
|
|
Posted By
BSZ
on 2021-06-02
18:01:02
| Re: Let’s JoyTest! :)
@Retroshire: Thanks for the detailed tests! On the third TED seems to have a good latch, the fourth has another problem. But the first two work as we guessed. Four out of four so far!
@hhc: Az mit jelent, hogy "az összes port egyszerre megy"? Egy kicsit pontosíts, kérlek! A tesztprogramban mit látsz a harmadik és a negyedik oldalon?
What does "all ports going at the same time" mean? Please clarify a bit! In the test program, what do you see on the third and fourth page?
|
|
Posted By
hhc
on 2021-06-02
14:31:05
| Re: Let’s JoyTest! :)
Nálam az összes port egyszerre megy, az mit jelent?
| Re: Let’s JoyTest! :)
For me, all the ports are going at the same time, what does that mean?
|
|
Posted By
Retroshire
on 2021-06-02
06:37:09
| Re: Let’s JoyTest! :)
Result TED 1
Result TED 2
Result TED 3 (odd result, DIAG264 gives 2x clock error + bad latch though the joystick functions right as does the keyboard)
I have a 4th TED with Latch problems, but I am unable to load the testprogram because the screen is automatically filled with a PI sign.
|
|
Posted By
BSZ
on 2024-08-24
05:12:54
| Re: Let’s JoyTest! :)
Köszönöm a fordítást!
Thanks for the translation!
@Chronos: Azt mondod, túl sokat szövegelek? Remélem minden géped jó, kell a Let's Play-hez!
You say: im I talking too much? I hope, all your machines are good, need to Let's Play!
@Retroshire: Yes, the 4th. screen is interesting. Please check the Joystick's movement on the 4th. screen. We would expect a result like the one shown in the third screenshot in the opening post: shot20210530_003.png
|
|
Posted By
Retroshire
on 2021-06-01
15:12:48
| Re: Let’s JoyTest! :)
Hi there, I have at least 3 TED's with bad latch indication on Diag264.
Do I understand correctly, that you are interested in the results of the 4th test, joy only?
So first: determine a transparent latch in test no. 3
then check movement in test no. 4.
Your question is: does a broken latch still gives result in the joytest of no. 4.
|
|
Posted By
Luca
on 2021-06-01
09:36:21
| Re: Let’s JoyTest! :)
GeTE hahaha!
TLC I'm now in a hurry and can't elaboate the whole post you've written (will do later) but yes I can confirm that I too have killed the TED in the same way, and two times: I used some very cheap joystick converter cables on my very first plus/4 and it got hit by a shock though turned off when I've swapped'em, due to the capacitors still loaded after the shutoff. That's the reason why I continuously say to all the other users: detach the power cable and switch it on and off few tims to discharge the capacitors, before moving any other cable on a Plus/4, 'coz these cables have no ground!
|
|
Posted By
TLC
on 2021-06-01
09:11:50
| Re: Let’s JoyTest! :)
Not yet. Bil Herd has already talked about the pecularities he had to fix in the TED design (I mean the machine, not the chip), but AFAIR he didn't design the chip, and neither did Dave Haynie, who was a recruit by Herd himself. AFAIK both the 7501 and 7360 were designed by David DiOrio, before and around the time Herd was hired. DiOrio is unfortunately no longer with us. Maybe if someone gets around to reverse engineer the circuit from the now available die shots...
|
|
Posted By
gerliczer
on 2021-06-01
07:58:05
| Re: Let’s JoyTest! :)
@TLC: Have you considered contacting the Great Old Ones (Herd or Haynie) to see if they have some theory on this issue?
|
|
Posted By
TLC
on 2021-06-01
07:30:32
| Re: Let’s JoyTest! :)
@Luca - basically, this problem affects the keyboard port (K0...K7 inputs) of the TED. The cause is probably ESD (not proven yet, but, likely). The damage likely happens when someone swaps a joystick between the joystick ports. (Also, accidents can play a role. I myself killed at least two TEDs' keyboard ports while experimenting / fixing... the last case being a quite unlikely one by any measure).
The ports we could see so far ( --> BSZ also had his share of history with/concerning broken TED keyboard ports ) broke in a "special" way. In a standard TED, reading the keyboard port is a 2-step operation; writing to $ff08 captures K0-K7 to an internal temporary latch, reading from $ff08 reads from the latch. In a TED with a "broken" keyboard port, the latch becomes "transparent" (roughly speaking), that is, writing to $ff08 no longer has any effect, and reading $ff08 always reads a recent K0-K7 state. How-why this happens is yet unknown. We also don't know yet, whether this is "characteristic" behaviour, i.e. if all or most broken TED keyboard ports fail like that.
The direct symptoms usually affect the readability of the joysticks. They either no longer work (at all), or, there is crosstalk, and/or stutter, depending on code. A very typical symptom: in Basic, clicking the fire button of joystick in port 2 gives a "Shift + Run/Stop" combination (rather than Shift alone).
Recent experiments addressed "how exactly" the broken keyboard port works. (...This evolved out of the unlucky event of me having wrecked my second TED , and discussing ideas of how that likely happens / works / could be worked around. We both had already known about the "transparency" phenomenon, and had also known for a fact, that, with a broken TED, the joysticks could still keep working to some extent, but had no idea how that was at all possible under given circumstances). The result didn't turn out to be complicated, yet, it's somewhat difficult to explain (as it goes all down to the electronic level of how the joystick ports work). I merely created the mentioned proof-of-concept code snippets to support (or, reject) what I had suspected after evaluating some measurements. BSZ then did all the heavy lifting to incorporate the results into his tester. At this point, the question is rather the likely proportion of affected machines, and, whether the TED keyboard port fails consistently (i.e. whether a common fix could be at all feasible).
|
|
Posted By
GeTE
on 2021-06-01
07:19:03
| Re: Let’s JoyTest! :)
Embarrassing ... well, then I'll search for something in the database for a completely different post as some kind of self-punishment.
|
|
Posted By
Luca
on 2021-06-01
03:31:11
| Re: Let’s JoyTest! :)
...or simply take Anykey here too, archived here in the same time
|
|
Posted By
GeTE
on 2021-06-01
03:10:57
| Re: Let’s JoyTest! :)
Well, some user may have ended up here searching for a simple joystick test (and are confused), others may test first their hardware if the TED might be wrong. Therfore I recommend "AnyKey" first to test the system.
https://csdb.dk/release/?id=198424
|
|
Posted By
Luca
on 2021-06-01
02:07:04
| Re: Let’s JoyTest! :)
This is far more interesting, and a precious case study which could open the doors to a more advanced knowledge of the behavior of the TED chip along the 264 production line!
What isn't clear yet to me is: which failure? What happens to the joysticks if you have that kind of failure? What are we specifically searching for? Are we seeking for the POS ERR message with no other symptoms than "feeling strange" the joystick handling of the machine?
Have two Plus/4s regularly mounted here (actually, there's no room here without a ready real Plus/4, maybe the bathroom, but I could improve it ) and I gonna test'em, hoping all the other users would do the same.
|
|
Posted By
Chronos
on 2021-05-30
15:05:10
 | Re: Let’s JoyTest! :)
Imádom ezeket a "pici" kis sztorijaidat! ki is fogom próbálni az errefelé lakó gépeken, bár emlékeim szerint a tesztgépeimben hálistennek nem hibás a TED.. még..
--
Love your "lil" stories! I'll try with all my resident machines, but if i recall correctly none of them has a defective TED.. yet...
|
|
Posted By
BSZ
on 2024-08-24
05:10:51
| Let’s JoyTest! :)
A „Let’s Play” mintájára indítanék egy ilyen szálat is! Van a kedvenc gépünk mindenesének, a TED-nek egy ismert problémája: a Joy-portok kezelése időnként tönkremegy bennük. Ami azért furcsa, mert a Joy-ok ugyanazon vonalakon keresztül vannak kezelve, mint a billentyűzet, utóbbi viszont továbbra is normálisan működik.
Egy ilyen módon elromlott TED, illetve némi levelezés hatására TLC nekiállt kitesztelni ezt az állapotot, aminek lett is némi eredménye. Hogy mi miatt tud tönkremenni, az továbbra is rejtély, viszont az, hogy ilyenkor milyen módon működik az elromlott TED, arról már többet tudni. Ezen kísérletezésnek hála lett egy elképzelése, hogy az ilyen módon hibás TED-del is lehetséges lehet a Joy-ok vizsgálata, ehhez készített is pár „proof-of-concept” kódot, amik működőképesnek tűnnek.
Van egy régebben készült billentyűzet / Joy tesztelő programom, abba beépítettem az egyik kitalált algoritmust. Ezt TLC megnézte, a hibás TED-jével pontosan az elvártaknak megfelelően működik, illetve – nyilván – én is teszteltem egy (kölcsön) Joy hibás TED-del, itt is ugyanúgy „jól” megy. Ez eddig kettőből kettő, de érdemes lenne ezt több példánnyal is letesztelni. Ha az derül ki, hogy – teszem azt – 10-ből is csak ez a 2 működik így, akkor nincs értelme foglalkozni a dologgal. De ha a „pont így elromlás” a jellemző, akkor esetleg lehet rá valami támogatást írni.
Na de miről is van szó? Akinek van olyan gépe, amiben ilyen módon hibás TED van, azokat kérném, hogy teszteljék le ezzel a programmal is:
HIDtest264-1.1
A tesztprogram eddig három képernyőből állt, ezt egészítettem ki egy negyedikkel. (A RESET megnyomásával vált át a következőre.) Itt csak a Joy-ok vannak lekérdezve, de a tesztek eredményeit figyelembe vevő algoritmussal. Egy „jó” TED-nél a következőt várnánk:
A gépen 2 db. Joy port van, de a logika alapján lehetne 8 is, a program le is kérdezi mindet. A kép felső felén akkor lesz aktív Joy-nál jelzés, ha „jó” a TED, az alsó felén viszont akkor, ha „rossz”. Viszont nekünk most az az érdekes, ha „rossz” a TED, ezt bármelyik előző oldalon egy billentyű lenyomásakor jelzi is a program:
Ha a Joy „érzésre” hibásnak tűnik, de a fenti felirat nem jelenik meg, attól még érdemes lehet megnézni a negyedik oldalt:
Ha valamelyik port valamelyik irányát (vagy a tűzgombot) érzékeli a program, azt jelöli piros háttérrel, zölddel csak azt, ami egyedül volt aktív. „Valódi” irány érzékelésekor jelenik meg a „POS DET” felirat, ha mindkét port összes jele jó volt, ez cserélődik „ALL DET” feliratra.
A fentieken túl, abban az esetben, ha olyan pozícióban érzékel aktivitást, ahol egyébként nem lenne szabad, akkor a „POS ERR” felirat is megjelenik, illetve az adott pozíciót bejelöli a képen a fent látható módon. A Joy-ok jelei egymástól el vannak különítve, de a billentyűzet a lekérdezésbe bele tud szólni, így a teszt közben gombokat ne nyomogasson senki! (A fenti képet is így csináltam, a Joy mellett a megfelelő billentyűket is le kellett nyomni.) Illetve a Joy esetleges „AutoFire” üzemmódját se próbálgassa senki! (Az sincs kizárva, hogy előidézheti a port „halálát” az is, a részleteket most inkább kihagyom.)
Az „elvárt” működés az lenne, hogy egyrészt ne legyen érzékelés hibás pozícióban (csak a Joy-t mozgatva), másrészt az irányt fixen érzékelje, ne legyen benne bizonytalanság. (Például a kart folyamatosan egy irányba húzva a képernyőn se „villogjon” az aktív jelzés.) És mindezt vagy csak felül („jó” TED esetén) vagy csak alul („rossz” TED-nél).
Tehát akinek van ilyen TED-je, azt kérném, tesztelje le! Amennyiben kiderül, hogy az „így elromlás” a jellemző, akkor elmesélem (vagy TLC meséli), hogy hogyan is működik az algoritmus. Maga a programkód nem bonyolult, beépíthető szinte bárhova, de a mögötte levő logika eléggé hardveres, emiatt lesz mit magyarázni. Illetve a tesztprogramban én direkt szedtem külön a „jó” / „rossz” lekérdezést, a valóságban könnyű olyan kombinált kódot írni, ami mindkét állapotban jól működik. Na de „jól működik”?
| (no topic)
Following the footsteps of "Let's Play", I'd like to start such a thread. There is a well known problem of the do-all of our favourite machines called TED: joy port handling sometimes beaks in them. Which is quite peculiar as those are handles through the same inputs as keyboard, yet the latter still works normally.
Because of such a broken TED and some additional correspondence, TLC started testing that failure mode resulting in some observations. The cause of the breakdowns is still a mystery, but how the broken TED keeps working is a bit better known. Running these experiments gave him an idea that testing joysticks would be still possible with TEDs suffering this failure. He made a number of proof-of-concept code that seem to be working.
I have a keyboard/joystick test programme I made a while ago, into which I built one of the invented algorithms. TLC checked that with his broken TED and it worked as it was expected. Furthermore, I did some tests on a borrowed TED with joystick failure and found it to be working OK, too. That's two out of two, but it would be worth testing on more specimens. If it turns out that let's say only these 2 works out of 10 tested pieces then there's no sense in spending time on it. However, if this exact failure mode is characteristic then maybe some software workaround can be created.
So what are we talking about? I'd like to ask those of you who have machines exhibiting this kind of failure to test it with this programme:
HIDtest264-1.1
The test program consisted of three screens so far. I complemented it with a fourth. (Pressing RESET makes is switching to the next screen.) Here are only the joysticks queried but with an algorithm that takes into account the results of the experiments. A sound TED is expected to produce the following result:
The machine has 2 joystick ports but the scheme would allow up to 8 all of which the programme will query. If TED has no flaw then the top part of the screen will have feedback on the active joystick. In case of a broken TED, feedback on active joystick will come in the bottom part of the screen. For now, we are interested in the cases of broken TEDs which the programme will signal at the press of any button in any of the previous screens:
If the joystick "feels" somehow wrong without the appearance of the caption above it is still worth checking the fourth screen:
If the programme senses any direction or the fire button on any ports it flags that with red background. Green background means the signal was active without interference of other lines. Sensing a direction without miss-detections makes the caption POS DET appear which will be replaced with ALL DET if all signals of both ports proves good.
Detecting activity in positions where it should not sense any will make the caption POS ERR appear and the given position will be marked as it can be seen in the picture above. The joysticks are separated from each other but the keyboard can interfere with the querying therefore no keys should be pressed during testing. (The picture above was made that way too, by pressing the corresponding keys.) Furthermore, optionally available AutoFire modes of the joysticks should not be tested either. (That may even cause the "death" of the port the details of which I skip this time.)
Expected operation would be no detection in erroneous positions all the while detection should have no uncertainty using only the joystick. E.g. pulling the stick continuously in a given direction shouldn't cause the active signal flashing. And all this should happen only at the top or the bottom for good or bad TEDs.
Thus, I'd like to ask people having such TEDs to test them. If it turns out that this failure is characteristic then I or TLC will tell a tale about the operation of the algorithm. The programme code is not complicated itself and can be built in almost anywhere but the logic behind it is deeply rooted in hardware, so there will be a lot of things to explain. I intentionally separated the query of failure free and broken cases, but it is quite easy to write a combined code that works well in both cases. But does it really work well?
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
