chue

February 4

1 hour ago, JasonACT said:

Mini Memory - Easy Bug: ("C1100" <enter> "1" <enter> "." "M4000" <enter><space><space><space><space><space>)

These are the values that I get. Note that I haven't reseated the 245s yet.

February 4

29 minutes ago, JasonACT said:

You might have a bad 74LVC245 or a solder issue

I’ll check for continuity between the chip pins and the underside. If everything is good I’ll swap in some other 245s that I have. This may be tomorrow though

February 4

19 minutes ago, JasonACT said:

maybe post a picture here too?

February 4

3 hours ago, JasonACT said:

Does the speech synth work?

Not really, but it does something... This is with the "no wifi" firmware. Sorry about the shaky video and the 4 year old talking in the background:

If you have trouble seeing the video, I type in CALL SAY("ONE") and the audio out is "UH-OH, UH-OH, UH-OH".

"CALL TIPI" still doesn't work with the no-wifi firmware.

3 hours ago, JasonACT said:

your Pi Pico W doesn't appear to be genuine

That's what I get for going cheap. Worst case scenario we chalk it up to bad hardware, and I'll have to buy some real PIs.

3 hours ago, JasonACT said:

You can also try Mini Memory and switch the DSR on and dump the first few bytes at >4000 to check the ROM?

Not really sure what to do here but will give it a go and see.

3 hours ago, JasonACT said:

What's in your autoload.cfg file?

CRU=1
PCODE=0
BAUD=115200

WFCC=AU
WIFI=[MY WIFI]
PASS=[MY PASSWORD]
SNTP=192.168.1.1
TZHR=10
TZMN=0
TMFT=1

;D1MAP=/BLNK.DSK,RO
;D2MAP=/BLNK.DSK,RO
;D3MAP=/BLNK.DSK,RO

;CART=/carts/marioG8.bin

Thanks for the help!

February 3

Thanks @RickyDean I appreciate the help. Hopefully Jason will have some things for me to try.

February 3

Yes it is FAT32.

February 3

Yes I did cut the trace on the PCB that goes to the middle pin of the SD card. I actually have the resistor connected to the trace near the SD card, and not the SD card pin. I checked the resistance between the PSRAM clock pin and the SD card middle pin and it shows 460 ohms.

I do believe that the SD card socket is soldered ok since it behaves correctly when the SD card is inserted (one short led blink on startup) and also when there is no SD card (3 led blinks on startup). I also removed the files on the SD card and then it blinks more than 3 times (either 4 or 5) times.

February 3

I was super excited to build one of these... however, mine doesn't seem to be working. Maybe it's something simple I am missing.

Here is what happens when I plug it in - I get one short flash of the LED, so the card thinks everything is ok. I did pull out the SD card and tried to boot that way and it complained by blinking more times (I don't remember the exact number). From TI BASIC the card does not respond to "CALL TIPI", from XB (via Finalgrom) "SIZE" does not show expansion ram. When I run the modified JediMatt's RAM tester from this thread, it doesn't see any RAM.

So here is a photo of my board, I've edited and put some notes on it:

I am using APS PSRAM. I purchased the PI Pico from Aliexpress - silkscreened on it are the words "RP2040 Pico W-2023" so it is a relatively recent version. All other components were purchased from either DigiKey or Mouser, except the Pico PEB PCB and edge connector.

I did run the onboard RAM test firmware (memtest2.ino.uf2.zip), and got the expected LED long on and then long off. Same result with the SD card and without.

On the SD card itself I have this:

sd-card.png.7de7f0a49a871e0e185c753c6290b996.png

I should mention I am using the 12ma firmware on the PI. I did try the "32k only" firmware but same results. I did try plugging a USB keyboard into the PI. It is backlit and when plugged in the lights came on; however, I got no output on the TI when typing.

I do get 3.3 volts at Vcc on all of the chips on top and on the PSRAM.

I should note that an actual TI PEB works when plugged into this TI.

Next steps for me are probably trying the Pico PEB on another TI, and or building a second PI PICO. I do dread doing another 470 ohm resistor bodge though. But maybe there's something obvious I missed?

January 26

8 hours ago, khanivore said:

Then I stumbled across the switch -fno-function-cse which happily stops gcc from doing the stupidity above.

The docs seem to say that there are "hacks" in place which sometimes get confused (emphasis mine):

Quote

-fno-function-cse
Do not put function addresses in registers; make each instruction that calls a constant function contain the function's address explicitly.
This option results in less efficient code, but some strange hacks that alter the assembler output may be confused by the optimizations performed when this option is not used.

source: https://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html

January 22

Perhaps some clues here: https://github.com/ChuckyGang/DiagROM/blob/master/DiagRom Codes.txt

Looks to me like chipmem errors, but I could be wrong.

January 18

Definitely clean the heads and clean and lubricate the drive rails. I use a cotton swab and 90% alcohol to clean; light oil on the rails of the drive head.

January 10

1 hour ago, RickyDean said:

Seems like as the unit was heating up, issues got worse.

Maybe you can put a fan on it and see if that makes a difference. A bit of moving air should be fine - if the errors go away, then you know it is the chips running hot.

January 9

The website seemed to have gone offline and so I checked archive.org, and found that it has a new home at whtech:

Quote

This page has a new URL- you will be redirected in a few seconds or click the link below to get there faster.
If you arrived here from a bookmark, please change your bookmark.

If you arrived here from a link on a web page, it would be helpful if you brought the attention of the webmaster to the new URL and ask him to change his link. Many many thanks if you do that!

New URL for this page= http://ftp.whtech.com/Users/stephen/TI.htm

(source: https://web.archive.org/web/20231024143202/http://shawweb.myzen.co.uk/stephen/TI.htm)

January 4

In preparation for the RAM chips arriving in the mail, I desoldered RAM chips U22 and U25. I put some sockets in and then put back the old chips. I ran @Fritz442's chip tester and got an unexpected result. Instead of getting stuck bits "42" or "24" I got "06" instead. It turns out I desoldered the wrong chip (U26). So I went back and socketed U25.

It wasn't easy desoldering the RAM in my unheated garage where the temps were below freezing. In the process I ended up damaging some caps near the sockets, but was able to replace them.

Here's the final result with 3 new caps (a half-sized yellow one, and two brown) and the 3 socketed chips (U22, U25, U26):

According to the schematics, all the small yellow caps near the RAM are 10nF. The Larger blue ones are 10uF, 25V.

Also, as replacements for the two 4116s I used two 4164s. The 4164s require the mod in the following thread:

And here are the RAM test results:

December 19, 2023

On 12/17/2023 at 7:23 PM, Fritz442 said:

Here's a .dsk of it to install on Nano.

I was able to get the disk image on the Nano, and then from there save it to the minimem. When run from the minimem, it seems to confirm the 2 stuck bits. However, I am unsure how to interpret the "Chip Test" results:

December 19, 2023

9 hours ago, khanivore said:

Patch 1.27 has been release

Looks good for me. All my unit tests passed

December 18, 2023

2 hours ago, Fritz442 said:

If you have a Minimem or Finalgrom modules, try this: Run from Minimem module

Hello @Fritz442, thank you. I have both modules, but no disk storage. I think I will not be able to run your application. There may be a way to get the application onto my nanoPEB, and then onto the Minimem. It's been a while since I've used the nano, so I'm unsure if that is possible.

December 18, 2023

I wrote a Mini Memory BASIC program that writes 00 and FF to each of the ranges (2000, A000). It then immediately reads back the value - if the written and read values are different, it prints them to the screen. It does this for 64 bytes at the beginning of each range.

10 DIM NVAL(2)
20 DIM MSTART(2)
30 NVAL(1)=0
40 NVAL(2)=255
50 MSTART(1)=8192
60 MSTART(2)=-24576
70 FOR K=1 TO 2
80 PRINT "TESTING";MSTART(K)
90 FOR I=MSTART(K)TO MSTART(K)+64
100 FOR J=1 TO 2
110 CALL LOAD(I,NVAL(J))
120 CALL PEEK(I,P)
130 IF P=NVAL(J)THEN 150
140 PRINT I;":";NVAL(J);"<> ";P
150 NEXT J
160 NEXT I
170 NEXT K
180 PRINT "DONE"

I ran it several times and got errors when writing "00" to differing addresses, so the errors don't happen consistently. No errors occurred when writing "FF".

At this point I might just start desoldering RAM chips, but will need to order some replacements. I will start by replacing the 3rd chip from the right in the bottom row of chips in the 32k expansion card, hopefully this is bit 3. If that doesn't work I'll replace the 3rd from the left. It's 50-50 at the moment. Finally I'll look at replacing any related buffer chips.

December 17, 2023

12 hours ago, RickyDean said:

If you have an extra 32k card... Then test the buffer chips

Unfortunately I do not have an extra card. However, I do have a nanopeb which I should try running these tests on. It would rule out errors in the TI and in the testing software. I think eventually I will have to test the buffer chips in the cable and in the RAM card. I do think the flex cable is ok. Continuity seems ok on all pins, so I don't think there are breaks in the cable.

11 hours ago, JasonACT said:

only 2 chips should show as faulty

I agree it does seem to show two bits stuck, and only on the even byte. Here's the other half of the test which writes 1s to each bit position:

The other interesting thing is that when I tested with EasyBug, the one stuck bit did not show itself when I wrote to the even byte. It only manifested when I wrote to the odd byte. For example, I would write "00" to A000, and then read back the value - it was zero. Then I wrote "00" to A001. Reading back A001 showed 00, but reading back A000 showed "04". I assume this has something to do with the fact that the processor does not write bytes - it can only write words, so when writing a byte it does a word read, update, and word write.

11 hours ago, JasonACT said:

I'd write another very simple basic program which sets 64 bytes starting at >2000 to 0 (and another loop for >A000) and report back what they read as.

My next step will be to try this and report back, I just have to get some time to do it.

December 17, 2023

I actually found one on AA. It was in BASIC and I manually typed it in. When I ran it it showed 8 bad chips. It’s possible I mistyped something.

Edit: I used this one:

December 17, 2023

On 12/13/2023 at 12:40 AM, JasonACT said:

if Easy Bug shows 0xCXXX different to 0xEXXX

I did do some debugging with EasyBug - I confirmed that Cxxx and Exxx show different data. When I write to one range, it does not show up in the other range.

Additionally, I wrote 00 and FF values to two consecutive bytes in each of these ranges: 2000, C000, A000, and E000:

The FFs were written and read ok, but when writing 00s, there looks like a single bit is stuck on 1 in the 2000 and A000 ranges.

At this point this looks like one bad RAM chip, does that make sense?

December 17, 2023

I have done a little surgery on the flex cable. I actually found 2 cut lines, one on each edge of the flex cable. These were lines for pins 1 (CRU) and 44 (8V). The 8V line was showing continuity previously, because it is also tied to another 8V line (pin 42).

So the good news is that the TI boots now with the RS232 card installed. I will probably test that later on.

The bad news is that this didn't change the RAM issue; this makes sense since the broken lines had nothing to do with any address/ data lines. More on the RAM issue in the following post.

December 15, 2023

All of my unit tests pass with the 1.26 patches.

Here's just comparing the size for one of my test apps:

patch / size

1.25 "A" / 6528 bytes

1.25 "B" / 7552 bytes

1.26 / 6784 bytes

Much better in terms of size with the latest release.

No I don't assume anything in terms of register usage. Normally I save any registers I use, and then restore them afterwards. I thought that the crt0 files might hard code the stack register, but in looking at a couple of mine (crt0.asm, crt0.c) they both use the alias "sp" instead of any register.

December 13, 2023

Thanks. I confirmed it is pin 1. In the schematic, pins 42 and 44 are 8V and are tied together, at least on the PEB side. I checked for continuity on both sides of the cable to see if I could locate pins 42 and 44. Indeed I see continuity on the left side (where I've marked pins 42 and 44 below):

So my next step will be to see if I can fix the wire that goes between the two pin 1's.

December 13, 2023

I did something that I said I would never do, which is purchase a Peripheral Expansion Box. It came with 4 TI branded cards: 32K RAM, RS232, Disk Controller, and Flex Cable card.

Initially the TI would not boot with all 4 cards in the PEB. So I took out the RS232 card and then the TI would boot. I was able to see the 32K RAM in XB; however, when I ran @jedimatt42's 32K RAM tester half the RAM appeared bad.

Here's what I've done since:

- Removed all the cards and cleaned all the contacts on the cards themselves, the PEB, the flex cable, and the TI.

- Measured the voltages in the PEB using the Molex cable. I get these voltages, which seem ok: +5.00, +11.71

- Inserted just the 32K and flex cable card; I reran the RAM diagnostic above and get the same result.

- The flex cable has several small rips (tears) in it and so I took it apart to test for continuity. All lines in the cable show continuity, except one - the yellow arrows below indicate the potentially faulty line:

So my question at the moment is, should this line in the cable show continuity?

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by chue