Not working with some devices

[ffxx68]

Sometimes, board doesn't properly respond to commands.

[dlachieze]

I’ve received the drive emulator. I’ve tested it with my Sharp PC-1403 : when I write a program with SAVE it works correctly and I can see the .BAS file on the SD card, but when I try to read it with LOAD it doesn’t work, I just get an ERROR 8. Is there any specific requirement for the SD card? Size, speed, format …?

[ffxx68]

SD should be FAT-formatted. I know of people using even a 32Gb. Can you see any file on the SD (attached to a windows PC), after a SAVE? Also, what is the output of the command 'DSKF 1' on the Sharp PC?

[dlachieze]

I’ve tested with two SD cards, a 8Gb and a 32Gb, both FAT32-formatted. Sometimes ‘DSKF 1’ returns 8 and SAVE and LOAD return an ERROR 8 message , nothing is written on the SD card. Sometimes ‘DSKF 1’ returns 16392 and SAVE is working correctly, the .BAS file is written on the SD card and on a Windows PC I can see the file and the program inside, but LOAD still returns ERROR 8. So far I’ve not been able to load a file correctly.

[ffxx68]

I'm afraid it's not a problem with the SD-card, but with the PCB, or firmware. This isn't clear to me yet. DSKF 1 should return 20488. If it doesn't, it means the Nucleo-to-Sharp communication is broken, somehow. SAVE succeeds because it is (mostly) a Sharp-to-Nucleo communication.

[ffxx68]

ce140f-tests.zip Attached some logs from tests by a user (thanks Joel!). In general, the board sometimes looks very erratic. In any case, Sharp showing a value of DSKF 1 other than 20488 are not working properly.

[ffxx68]

Measuring a level converter behaviour alone, with a detached Nucleo and a test firmware. Setting the input pin mode "pull none":

in_D_OUT.mode(PullNone);

Then, setting the output pin:

out_D_OUT = 0 --> 0.00 V
out_D_OUT = 1 --> 3.76 V

Output should be about 4.3 V is actually about 3.7 instead. I suspect this voltage could be not enough, for some Sharp PCs, to be recognized as a "high" level, since they use 5V CMOS logic.

Irrespective of how I set in_D_OUT.mode ( PullNone, PullUp, PullDown ), I still get out 3.76 V high level. If I physically UNPLUG the input pin, I get the expected levels:

out_D_OUT = 0 --> 0.0V
out_D_OUT = 1 --> 4.33V

I thought "PullNone" mode to be equivalent to unplug...

I was just "lucky" that my PC-1403 worked as expected, by correctly sensing the 3.76 levels as high. That could not be the case for other models, or maybe because of low-level batteries?

[ffxx68]

The above update refers to this schematics: where voltage is measured at CONV_OUT.

[dlachieze]

Thanks for the explanations. Could this be fixed on the current boards?

Note: my PC-1403 has brand new batteries.

[ffxx68]

Hard to tell right now. I'm scratching my head for a solution...

Il Gio 4 Mag 2023, 22:53 dlachieze @.***> ha scritto:

Thanks for the explanations. Could this be fixed on the current boards?

— Reply to this email directly, view it on GitHub https://github.com/ffxx68/Sharp_ce140f_emul/issues/4#issuecomment-1535396797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFBAZNDOI77GS3QV7APNW3XEQJMNANCNFSM6AAAAAAXR5FFHU . You are receiving this because you authored the thread.Message ID: @.***>

[ffxx68]

Hi,

after some investigation, I've compiled a new version which I hope would fix the unreliability issues, with some sharp devices. Since I don't have a Sharp where the issue is reproduced, I rely on your tests to verify it. Could you please test this one?

thanks Fabio

Il giorno ven 5 mag 2023 alle ore 18:00 Fabio Fumi @.***> ha scritto:

Hard to tell right now. I'm scratching my head for a solution...

Il Gio 4 Mag 2023, 22:53 dlachieze @.***> ha scritto:

Thanks for the explanations. Could this be fixed on the current boards?

— Reply to this email directly, view it on GitHub https://github.com/ffxx68/Sharp_ce140f_emul/issues/4#issuecomment-1535396797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFBAZNDOI77GS3QV7APNW3XEQJMNANCNFSM6AAAAAAXR5FFHU . You are receiving this because you authored the thread.Message ID: @.***>

[dlachieze]

Great ! I can test it surely. Where do I find the new version and how can I install it on the Nucleo board?

[ffxx68]

If you plug the board to a standard Windows laptop, it should appear as a USB drive, where you can upload the file attached to my previous email. Unfortunately though, others who have already tried this updated firmware haven't found any benefit.

Il giorno mar 9 mag 2023 alle ore 13:04 dlachieze @.***> ha scritto:

Great ! I can test it surely. Where do I find the new version and how can I install it on the Nucleo board?

— Reply to this email directly, view it on GitHub https://github.com/ffxx68/Sharp_ce140f_emul/issues/4#issuecomment-1539967532, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFBAZPX4ECL7KAHB2GIKUTXFIQFNANCNFSM6AAAAAAXR5FFHU . You are receiving this because you authored the thread.Message ID: @.***>

[dlachieze]

Sorry but I didn’t receive any file in your previous mail.

[ht-deko]

If you have not unplugged the jumper cap (D2<->GND) on the Nucleo L432KC, SAVE will succeed but LOAD will fail. In the past, the README.md here has included an image of the jumper cap still plugged in.

[dlachieze]

Thanks but there is no jumper on my Nucleo board.

[ffxx68]

I think only some board-device combinations aren't working. Can't tell why...

So, I've prepared a basic (both in language and functionalities!) test program and firmware, to make at least some comparisons with other devices and boards, with respect to my (working) PC-1403. Let me highlight once more that I do have tested each and every board, before shipping, with my PC-1403.

I hope this would help narrow down and, eventually, solve the issue!

The basic program (the small part in assembler) is for a PC-1403, and needs to be entered in the Sharp manually, of course. First, reserve memory for the assembly code (in PRG mode):

NEW
POKE &FF01,&30,&E8
NEW

Then, enter the program itself:

1 "A":POKE &8048,&CC,&10,&80,&36,&52,&37
2 END
210 "C":PRINT "Test IN B port"
220 CALL&8048
230 B=PEEK&8036
240 PRINT B
250 GOTO 220
290 END
300 "D":PRINT "Test ext data out"
320 POKE 14848,0
330 FOR I=1 TO 10 
340 POKE 14848,15 
360 POKE 14848,0
380 NEXT I
360 END

DEF-A uploads the assembler fragment in Sharp memory DEF-C shows Sharp input port value, reading the value set by the board DEF-D outputs data, from Sharp to the board

On your Nucleo board, upload the firmware attached here (test_bed.NUCLEO_L432KC.bin): https://github.com/ffxx68/test_bed/releases/tag/v1 Note how this would overwrite the CE-140F emulator fw! You can always download the original emulator firmware .bin from here: https://github.com/ffxx68/Sharp_ce140f_emul/releases/tag/PCB_v1_tested

To do your test, first attach the board, still unplugged from USB, to Sharp PC, then turn on Sharp and plug the USB power. If you can, start a serial terminal on the COM-port exposed on the USB by the Nucleo board: standard 9600 baud. Putty, or similar terminal programs would do the job. But that isn't mandatory, at least to run the input test (DEF-C).

The input test (DEF-C) would show either 0 or 128 as the return value, changed by a button press (or any key, over serial terminal).

The output test (DEF-D) would show a number of raise/fall messages, either with 'f' or '0' values, with last two showing '4' instead (see video).

Better than describing how to use it, let me show it with a brief video...

https://youtu.be/3NJVXnl8p5Y

(test source code: https://github.com/ffxx68/test_bed)

[RN-NOMATAN373]

Hello! I have made a case for my CE-140FEMU. I also added a battery so it is working without power from USB. Thanks for making a great device! However, some parts of the operation fail on my pocket computer as well. PC-E500: FILES operation fails. PC-1460: everything fails except the SAVE operation.

DSKF 1 on PC-1460 is 16392. DSKF 1 for PC-E500 is 20488.

Is there anything I can do to help make this project a success?

[ffxx68]

Thanks @RN-NOMATAN373 and let me congratulate for the case you built! At least we're seeing some repeating patterns, over several users, with DSKF for example. Do you have a chance to check the test programs I have posted above?

[RN-NOMATAN373]

I have a pocket computer to which the CF-140F EMU can be connected, PC-E500 PC-1480U PC-1460 PC-1475 These are the four machines. Do I need to modify the assembler code address, etc.? Please let us know and we can accommodate you.

[dlachieze]

@RN-NOMATAN373 beautiful case, how did you make it?

@ffxx68 I've done the test on my PC-1403. After initializing the assembler code with DEF-A:

• The input test (DEF-C) works correctly, it first returns 0 and then after each button press it alternates between 0 and 128
• The output test (DEF-D) seems also to work but the succession of f, 0 and 4 doesn't look as on the video:

[RN-NOMATAN373]

@dlachieze Thanks! It was made with 3D-CAD and a 3D printer.

Case production is recorded on twitter.

Production Continued

[ffxx68]

yes, memory addresses need to be changed, for other models. But I really can't tell exactly how, right now (I should make some research about it, and someone else might be more informed than me, in this respect).

To give a bit of background, these are a couple info I got from a German friend about the IN / OUT ports over the 11-pin connector of the Sharp.

• Internals:
• Connector-port mappings (also for different models):

I'd also like to ask @RN-NOMATAN373 : could you collect the debug output of the SAVE and FILES operations? But for that you need to have USB connected to a standard PC.

[ffxx68]

@dlachieze what is the debug out of DSKF 1 on your failing model?

[Taki-B]

Since the test program would run on a PC-1403, which actually works every time I tried, I invested some time to a have a look at the signals. For this I did a comparison between the signals of an original CE-140F, the emulator, a PC-1403 (where both work) and a PC-1360 (where only the original CE-140F works). As firmware I used fix2 that Fabio sent me a couple of days ago.

I was surprised to see that the the low level is not 0 V but 2 V and I see a difference in timing, too. The mechanical CE-104F takes about 1650 ms to answer to the Pocket PC, while the emulator reacts in only 53 ms. The PC-1403 seems to tolerate a lot.

PC-1403 connected with a real CE-140F and running DSKF 1 (returns 62464). CH1: D_OUT (pin 5) CH2: D_IN (pin 8)

PC-1403 connected with a CE-140F-EMU and running DSKF 1 (returns 20488). CH1: D_OUT (pin 5) CH2: D_IN (pin 8)

PC-1360 connected with a real CE-140F and running DSKF 1 (returns 62464). CH1: D_OUT (pin 5) CH2: D_IN (pin 8)

PC-1360 connected with a CE-140F-EMU and running DSKF 1 (returns 8). CH1: D_OUT (pin 5) CH2: D_IN (pin 8)

I used a small board to connect my oscilloscope easier:

[Taki-B]

@dlachieze Thanks! It was made with 3D-CAD and a 3D printer.

Case production is recorded on twitter.

Production Continued

Great work! I hope you will make the STL files available.

[dlachieze]

@dlachieze what is the debug out of DSKF 1 on your failing model?

When I enter DSKF 1 with the test firmware it returns ERROR 8 on the PC-1403 and the following lines on the terminal: 247378989 in_D_OUT Rise: 4 247457255 in_D_OUT Fall: 0

[RN-NOMATAN373]

Archived records of FILES and SAVE runs on the following pocket computers PC-E500 PC-1480U PC-1460 PC-1475

Neither LOAD nor SAVE worked on PC-1475. SAVE worked for PC-1460. PC-E500 and PC-1480U both SAVE and LOAD worked.

log.zip

[ffxx68]

Great workstation, and great debugging job @Taki-B !

From all the log files, we can see that all devices are receiving data correctly and indeed the board is processing the commands sent by Sharp. The problem arises when the board is sending back data to Sharp. Take 'DSKF 1'. This one always "tries" to send back

20488 = 0101 0000  0000 1000

Note how communication happens over 4-bit "nibbles":

out_SEL_1 = (t&0x01);
out_SEL_2 = ((t&0x02)>>1);
out_D_OUT = ((t&0x04)>>2);
out_D_IN  = ((t&0x08)>>3);

with each byte sent over two consecutive nibbles. Most of the non working Sharps receive either an 8, or (sometimes) a 16392:

8     = 0000 0000  0000 1000
16392 = 0100 0000  0000 1000

Looks like at least the lowest order bit 0001 is missed by the Sharp. I have compiled a fw returning a value of

4680  = 0001 0010  0100 1000

setting also the 0010, to verify that one too: https://github.com/ffxx68/Sharp_ce140f_emul/releases/tag/v1.4 (btw, this version also supports some additional commands).

Note how the suspect missing bits are those connected through the internal transistor switch, controlled by ACK, to the sharp cpu input IB port. Indeed, using the "test bed" I noticed setting high ACK high makes the SEL 1 high level to drop at about 3.3 volt... That could be too close to the minimum high-threshold to be reliable, or detected at all.

Everything in any case points to a signal-level mismatching. I'm now wondering how this could be fixed, without a major rework of the PCB design, or some sort of buffer between the board and the sharp, at least for the SEL1 and SEL2 lines. And it's a real shame I have tested my prototype with such a "tolerant" PC-1403!

@Taki-B - as soon as you have time, could you please probe SEL_1 = pin #11 and SEL_2 = pin #10?

[Taki-B]

as soon as you have time, could you please probe SEL_1 = pin #11 and SEL_2 = pin #10?

I uploaded firmware 1.4 but there's no difference to earlier regarding the function: PC-1403 works, PC-1360 does not. I'm only uploading the screenshots where I connected the emulator.

CH 1 = D_OUT (yellow) CH 2 = D_IN (red) CH 3 = SEL_1 (blue) CH 4 = SEL_2 (green)

PC-1360 connected with a CE-140F-EMU and running DSKF 1:

PC-1360 connected with a CE-140F-EMU and returning 8, where 4680 would be expected:

PC-1403 connected with a CE-140F-EMU and running DSKF 1:

PC-1403 connected with a CE-140F-EMU and returning 4680 as expected:

[ffxx68]

Thanks - I'll take a deeper look but at first glance, there's no great difference, in signal levels, between 1360 and 1403 - both are very dirty though!

[YuuichiAkagawa]

I tested on PC-1360K and PC-1470U. Neither of them work properly.

PC-1360K

• DSKF 1 : 4680
• FILES : ERROR 8
• LOAD : ERROR 8

PC-1470U

• DSKF 1 : 8
• FILES : no result
• LOAD : ERROR 9

I observed the operation of the DSKF in the PC-1470U with an oscilloscope and noticed something. When ACK goes high, the voltages on Dout, IO2 and IO1 drop. If the pocket computer reads the signal at this timing, it decides that it probably cannot recognise it as high. I do not know why the voltage on Din does not drop.

And I made an equivalent board.

• Logic level converter : BSS138
• Diode : 1N4148

After I confirming that DSKF and FILES were not working properly, they were changed to Schottky diodes. Voltage drops were reduced and slightly improved. Results after diode replacement.

PC-1360K

• DSKF 1 : 4680
• FILES : OK
• LOAD : OK

PC-1470U

• DSKF 1 : 4680
• FILES : OK
• LOAD : ERROR 8

In my opinion, it would have been better to use a fixed-direction voltage translator IC instead of a BSS138 as only one directional logic level is performed.

Only Dout was connected with SN74LV134SN74LV1T34 instead of BSS138. There is very little voltage drop.

[ffxx68]

hi @YuuichiAkagawa - thanks for your valuable contribution! Indeed, I noticed that voltage drop as well when ACK goes high. The reason why it doesn't happen on the Din line is because Sharp has an internal transistor switch operated by ACK on the other lines (see https://github.com/ffxx68/Sharp_ce140f_emul/issues/4#issuecomment-1546926607). I'm also trying simulating this behaviour with KiCad+Spice, although I haven't yet found a complete agreement with measurements:

And I definitely agree I should have used a different converter, in place of the BSS138-based one. But, I had tested the prototype and I thought about producing the PCB with exactly the same tested design. I wouldn't ever imagine other Sharp PCs to behave so differently...

[ffxx68]

In the original CE140-F service manual I can see these inverter buffers DTA114YK, on each in-out and the ACK lines:

I'm afraid the only fix is to adopt something like this, but it's a complex fix...

[Taki-B]

How difficult is it to modify the code so that it uses the same pin for in- and output? I could try then how the level converter TXS0108E performs.

[ffxx68]

Not that hard, after all. I was thinking to make such a change too, and I also have a few TXS0108E samples to test. Issue is about reworking the PCB, which has to be re-designed obviously...

[Taki-B]

A suggestion: Let us get the circuitry working on all Pocket PC that support CE-140F and when this is done, we will see if the existing PCB can be reasonably mended with a level converter break-out board or not. I do have three TXS0108E break-out-boards here and could run tests with PC-1403, PC-1475, PC-1360 and PC-E500S (which all are working with my original CE-140F).

[ffxx68]

I'll think about setting something up, to test the code changes.

[ffxx68]

I want to report the results I've got after improving the Kicad+spice simulation. Here's what I get with current design of the level converters:

Then, with the level converters "patched" like this:

This new design emulates the output lines of the original CE140-F schematics. As it's clear, the voltage drop caused by the ACK line is drastically reduced. Unfortunately, this requires either a deep PCB redesign, or a manual patching on each line, removing components and adding the transistors... not easy at all!

So, I'm also pursuing @Taki-B suggestions, to use a bi-directional level converter on the external 11-pin connectors. This is not an easy path either, anyhow. I'm also having troubles using the TXS0108E break-out-board... Not sure why, but even in the most simplified setup, I can't get it convert the 3.3 to 5V!

[RN-NOMATAN373]

Excellent analysis! I don't consider myself a purchaser of a company's product, but a participant in the experiments of my pocket computer user friends. I respect Fabio and his friends for bravely taking on various challenges and using their time and knowledge. I will participate in crowdfunding again when I have a new PCB.

[ffxx68]

Maybe a somewhat simpler fix is also possible ...

Below the simulation with the original "architecture", but with the "problematic" converters having reduced pull-up resistors, from the original 10K, to 3 K. The simulated voltage drop is reduced from the original 4.4-3.65=0.75 V to 4.4-4.0=0.4 V:

Still, some soldering skill is required to replace, or parellel, with (about) 3K-Ohm the resistors marked on PCB as:

R16, R20, R22

This is just from the emulation yet, and needs to be tested on non-working devices!

[Taki-B]

Maybe a somewhat simpler fix is also possible ... ... This is just from the emulation yet, and needs to be tested on non-working devices!

I'll give it a try a soon as possible, Fabio.

[Taki-B]

Replacing the 3 10k resistors with 3k ones seems to be the solution. The signal is still not pretty to look at but all my Pocket PC now recognise what CE-140F-EMU sends them.

I verified that DSKF 1, SAVE, LOAD work as expected with one exception: PC-E500S returns Error I/O when I issue FILES and want to move to the next page with files.

Here are the screenshots of the responce to DISK 1 or DISK (1):

PC-1403

PC-1475

PC-1360

PC-E500S

As I didn't have the needed SMD resistors I used some 3k THT ones. It's not a pretty sight but with the socket for the L432KC installed, there's not much space left to work.

[ffxx68]

great news! at least we have a (relatively) simple workaround... Thank you @Taki-B, to test it out

[ffxx68]

Just for the sake of completeness, I've pushed the KiCad project used for my simulations: https://github.com/ffxx68/Sharp_ce140f_emul/tree/main/level_conv_sim

[RN-NOMATAN373]

The resistor is changed to 3KΩ. PC-1460 works only with SAVE PC-1475 and E500 operate only SAVE and LOAD FILES does not work on all models. PC-1475, which could not even SAVE and LOAD when the resistor was 10kΩ, can now SAVE and LOAD when changed to 3KΩ.

fabio, can I use this transistor? https://akizukidenshi.com/download/ds/unisonic/DTA143E.PDF

[ffxx68]

I think the dta143 would do the job. But the board software should be amended too, as it'd need an inverted output. So, before going the complex route, please try with 1k resistors. And, first of all, please tell what is the outcome of the DSKF 1 command.

[RN-NOMATAN373]

Understood. I will post a log of the 3KΩ before the change. log3k.zip

[RN-NOMATAN373]

Changed to 1KΩ; behavior is the same as with 3KΩ.

PC-1460 DSKF 1

23:09:07.540 -> s11085435 Device 23:09:07.654 -> d 0x41 23:09:07.654 -> 11174944 Device ID 0x41 23:09:07.654 -> 11174984 CE140F 23:09:07.654 -> 11190104 0:1D [1D] 23:09:07.654 -> 11195361 1:01 [1E] 23:09:07.654 -> 11200876 2:1E [3C] 23:09:07.723 -> co 23:09:07.723 -> 11250940 Processing... 23:09:07.723 -> 11250993 in: 3 bytes (first 40 below) 23:09:07.723 -> 11251043 <1D011E> 23:09:07.723 -> 11251137 avg input timing (ms/byte): 8.63 23:09:07.723 -> 11251218 checksum 0x1E vs 0x1E 23:09:07.757 -> 11251289 command 0x1D 23:09:07.757 -> 11251352 DSKF 23:09:07.757 -> 11251404 diskspace 4680 23:09:07.757 -> 11251472 out: 5 bytes (first 40 below) 23:09:07.757 -> 11251550 <004812005A> 23:09:07.757 -> 11266462 send complete 23:09:07.757 -> 11266540 avg output timing (ms/byte): 2.93

[ffxx68]

I see. What is the output on sharp of dskf?

[RN-NOMATAN373]

It is pc-1460. the result of DSKF1 shows 584 on the LCD.