Vorticon

The disk controller is at 1100 and TIPI is at 1000. Weird... And I don't honestly remember is it was working previously or not after I got the TIPI. Why would this be isolated to the EA option 5 though??? It works with EA option 3, XB, DM2K etc... A real head scratcher...

Yes, but did you try using a real disk drive with an EA5 program on a diskette and loading it from the EA module directly?

I was wondering if someone could do a quick check for me. With the TIPI-PEB in place, can you access the PHYSICAL drives (DSK1-3) from the EA module option #5? This is not working for me although option #3 does work. No issues with XB either. The only way to load an option #5 program (memory image) from the physical drives on a diskette is to use the LOAD command from within FC... If I take out the TIPI, then everything goes back to normal.

There definitely seems to be an issue with SAMSTESTER when it comes to detecting the size of the RAM on the SAMS card. Both Matt's Expansion Memory Tester and AMSR4 are reporting 512K, whereas SAMSTESTER is seeing 1024K.

The 688 is one of the chips not in my programmer's library, so I was not able to test it. Best replace it as well I suppose with the 25LS2521.

Do you happen to have a built cart image by any chance?

Great program! You've got to love Forth! I am seeing some inconsistencies however: AMSR4 reports only 512K of RAM (after I reflowed the solder joints, the RAM size went from 1024 to 512 irrespective of the position of the SRAM chips), but SAMSTESTER seems to see all of the memory. The REGTEST passes. SAMSTESTER goes only to segment #15. Shouldn't there be a segment #16 to account for 1024K? It starts at segment #1, not #0. AMSR4 is locking up at random memory pages. Not so with SAMSTESTER I think the problem lies with the 612 memory mapper. I have managed to test almost all of the support chips and they pass. I think one of the SRAM modules is bad as well but I am getting inconsistent results with the testing (swapping the SRAM chips sometimes gives an error, and sometimes not). I'm just going to order replacements for the 612 and SRAMs and see if that solves the issue.

Ideally the code gets optimized in order to allow use of all functions, although I am OK selectively switching off functions depending on need.

Thanks that did it. Of note is that there are 2 sections that have these INCLUDE statements and both have to be commented out.

Seems to but I have to test that more extensively.

The error message is very vague unfortunately, so it could be anything. I'm working on testing all the chips I can test, then order replacements for the rest although it might actually be cheaper to just buy one of the new SAMS cards from Jim... That said, I just hate throwing away a fixable piece of equipment, particularly since all the chips are socketed. We'll see how far I get.

I get an error during compilation stating that the sketch is too big for my Uno... Anything I can trim out?

I used an extender and checked the output of the 7805 and it's a steady 5V. So that's not it. That would have been too easy, wouldn't it 😁

I have a TL866CS programmer, and the 6840008 SRAM is not on the list of supported chips unfortunately. Is there an equivalent chip I could use?

Welp I cleaned all the contacts with 91% IPA, re-seated all the chips after spraying Deoxit on the machined sockets, and also deoxidized the PEB slots, but unfortunately with no change. I think I have a bad chip somewhere and the trick is to figure out which one... I wish there was a SAMS testing program which pinpointed the bad chip. Any suggestions for a testing strategy would be much appreciated. I have all the likely needed testing equipment.

Hi. My original 1M SAMS card from 1995 is acting up. Here's the result of the memory check. Any suggestions where the fault might lie?

So this translated to: 100 GOSUB 210 110 CALL KEY(0,K,S) :: B=B+(K=65)/4-(K=76)/4 :: B1=B-INT(B) :: Q=Q-(B1=.75)+(B1=.25) :: W=W-(B1=.5)+(B1=0) 120 CALL GCHAR(Q,W,E) :: SC=SC+1 :: CALL VCHAR(Q,W,130) 130 IF NOT (e<>32) THEN GOTO 110 140 CALL SAY("GAMES OVER") 150 DISPLAY AT(24,2):"GAME OVER SCORE :";SC 160 IF NOT (S=0) THEN GOTO 190 170 CALL KEY(0,K,S) 180 GOTO 160 190 IF NOT (K=78) THEN GOTO 100 200 END 210 CALL CHAR(130,"") 220 Q=23 :: W=16 :: B=100.25 :: SC=0 230 CALL CLEAR :: CALL VCHAR(1,1,130,23) :: CALL VCHAR(1,32,130,23) :: CALL HCHAR(1,1,130,32) :: CALL HCHAR(23,1,130,32) 240 FOR I=6 TO 18 STEP 6 :: CALL VCHAR(I,10,130) :: CALL VCHAR(I,17,130) :: CALL VCHAR(I,24,130) :: NEXT I 250 CALL CHAR(130,"FFFFFFFFFFFFFFFF") 260 RETURN Not bad at all. I really like that project. Everything in one place and super easy to use. Even includes a character definition utility! Well done. I will definitely be using this.

Here's a simple SD drive enclosure I made in OpenScad. The screw mounts are best suited for M1.7 5mm self-tapping screws. Works well. CC40 SD drive enclosure.zip CC40 SD drive enclosure STL files.zip

I took a break from this project a couple of months ago as I kept hitting a wall with the evaluation function and the computer play was laughable. I may have to rethink a few algorithms...

On a whim, I replaced my original SAMS card from 1995 with a standard 32K expansion card and all the problems disappeared, including the FC instability. Would that make sense? It seems to work fine with the TIPI-PEB out of the system, but then I really don't use any software currently that requires the full SAMS capabilities, just 32K. When I am back home tonight, I will run diagnostics on the SAMS card and see if it passes.

In my system, the TIPI is at 1000, the disk controller is at 1100 and the RS232 is at 1300/1500. I cannot see why there would be a CRU conflict. The whole thing is acting up, including FC issues, so I still think it's the TIPI-PEB card at the bottom of it. Taking TIPI out completely restores all functionality... I'll play with it some more later today and see...

Thanks for checking. Appreciate it.

Yes. I have had no issue with the XB command with my older FC version.

Now that I got my TIPI-PEB to work again and with FC version 1.8 running, other issues are cropping up. Both my standard TI RS232 card (@1300) and my HDX-modified RS232 card (@1500) seem to lock up FC after just a few seconds. I believe this was the root cause of my previously reported problem with version 1.8. Pulling them out and replacing them with a Myarc RS232 card solves the issue. Found that out by essentially via a process of elimination. This was not an issue with my previous FC versions and frankly it would be odd to have both cards fail at the same time. The XB command locks up the system. I have my system setup for RXB2015 and nothing has changed there. Running XB programs on the TIPI directly from XB works. Has anybody tried that command with version 1.8?

Turned out a couple of the cables on the PI harness were a bit loose. Note to self: try not to pull the harness connector by the wires... 😁 So now my system boots up fine. But my tribulations were not over unfortunately. The most glaring problem is that the physical disk drives were no longer accessible from the EA cartridge option 5. Works fine with option 3 or from XB or from within FC with the LOAD command. Totally weird...