chris36

Attached is my interpretation of the 32K Expansion memory checker given in http://ftp.whtech.com/user groups/Kankakee/K3-1988-05.pdf You will need the drawing on page 6 of that PDF to interpret the results. As the PDF states, this is meant to be run from BASIC (not Extended BASIC) with the MiniMemory cartridge. The PDF gives information on how to disable the 32K Memory if no MiniMemory is available and you are loading with Extended BASIC. My 32K expansion card passed, so I don't have it tested for showing a bad result. It does show all bad on the second pass with the 32K expansion removed (PEB turned off, in my case). Interestingly, the first pass shows ok with no 32K expansion, zero in, zero read. I suppose that check is for "stuck bits" situation that is mentioned in the PDF. memtest.bas

You might be punishing the wrong villain. According to this, it was written by someone else. https://en.wikipedia.org/wiki/Pyramid_of_Doom

If it's one or the other, that implies I would need to recable the PEB. Something I was trying to avoid.

Just to be clear, did you mean "external cable and internal"? i.e. one drive can be on each?

Apologies for necroing this thread. But it's the first result of a search for 32K memory test. So do each of the individual 4116 chips represent a single bit of a byte? And each row of 8, together, form a byte? If so, then line 240 IN=2^I ("eye") not ("one"), in the xBasic version, seems to make sense. I ("eye") goes from 0 to 7. So 2^I (eye) would step through a byte setting each bit on ON. This in turn would step through each chip and set it ON via the LOAD/PEEK statements. The improved BASIC program has the same typo, or bad copy, but at line 420. I would assume it is 2^I ("eye") for the same reason, but as a "second pass". "first pass" seems to just write all zero/OFF bits to the chip 8 times. Thoughts? Am I off base in my assumption of how the memory works?

I have a PEB with PHP 1240 Disk Memory System controller and a full height floppy drive installed in the PEB. I have a gotek drive SFR1M44-U100LQD that I want to use as DSK2 outside the PEB. The 1240 instructions address a single drive install (internal) and multiple drive installs (external), but doesn't talk about an internal + external configuration. Is it as simple as changing the drive id jumper on the gotek and connecting to the connector on the back side of the controller? Do resister packs need to be messed with on the internal floppy? Or does the internal floppy need to be connected to the same cable as the gotek? Thanks for any hints or tips anyone can provide.

I extracted the section of the disk file that appears to be assembly. It's attached as ringdest_assembly.bin. I used the disassembler, xda99, found at https://github.com/endlos99/xdt99. The resulting file, ringdest_disassembly.txt, is also attached. There are multiple subroutines in there. From the xBasic code, RINGDEST_xBasic_ASSEMBLY.txt, there are two LINK statements for subroutines "A" and "B". The LOAD statement at line 210 sets up the Routine Name Table. Routine "A" is always at address >a200. Routine "B" can change locations, depending on the values in variables X and Y. I think this is about where I'm dropping out on this topic. ringdest_assembly.bin ringdest_disassembly.txt RINGDEST_xBasic_ASSEMBLY.txt

I think that the machine code, or assembly, is at the end of the ASSEMBLY Extended Basic program. The xBASIC code uses INIT, PEEK, LOAD, and LINK statements to handle running the machine language parts of the program. Using hexdump on RINGDEST.DSK shows the following. Note all values hexadecimal. File offset 0x2300 is the start of the ASSEMBLY xBASIC content. The header shows: Length?: 0xf825 (anyone have details on this?) VDP Address of BASIC Code: 0x14d3 VDP Address of Line Pointers: 0x1308 VDP Address of end of Code: 0x37d7 This is followed by a block of line number pointers at file offset 0x2308. This is followed by the start of the xBASIC code at file offset 0x24d4. The xBASIC code appears to end at file offset 0x3832. However, there is still content that appears in the rest of this file which ends at file offset 0x47ff. It doesn’t look like xBASIC. I suspect this is the machine code that the LINK statements are executing.

While looking to see how the Assembly was done, I noticed that the high score file $A, on the WHTECH file, was length 1 (x256 bytes) which seems right. The $A file on the IUC floppy is length 15 (yikes!). The first 256 bytes look like high scores shown in game, The other 14 sectors contain BASIC code. This code contains these strings: TEXWARE ASSOCIATES 350 FIRST NORTH STREET WELLINGTON, IL 60973 (C) COPYRIGHT 1983 BY: MARK L. GREEN HERE COMES OH NO HERE COMES ROUND ABOUT HERE COMES MEAN SQUARE HOW DO THEY GET ME HELP ME TO PLAY WELL SOMEONE DOES NOT LIKE ME TO PLAY THEY WILL NOT LET ME PLAY Looks like another game mixed in here. Floppy had old content and reused? But then why does the high score file length include this? Weird. Anyone recognize this other game?

Summary of Extended Basic Files: Note: Parenthesis contain my nomenclature which is explained later. WHTECH: RINGDEST.DSK and RING_ERR.DSK from WHTECH are the same except they have different byte fill pattern at the end of the file. WHTECH: RINGDEST.DSK has files: LOAD (loader v2), EXTBASIC (xbasic v2), ASSEMBLY (assembly v2) IUC Floppy: RingD_disk.dsk has files: #RING-B (assembly v2), ASSEMBLY (assembly v2), EXTBASIC (xbasic v2), LOAD (loader v2), #RING-A (loader v1) IUC XB32: RINGDEXB32.dsk has files: LOAD (loader v2), ASSEMBLY (assembly v1) IUC XB: WAV File + RingDest-X.dsk has files: LOAD (xbasic v1) I did not include the CREDITS file as that was added by IUC and not original TI file. Also didn't include high score file. We are missing the ASSEMBLY version from cassette on WHTECH/IUC. Cassette should have extended basic version as one "file", followed by the assembly version as one "file". It would have been nice to have the assembly as WAV file for this comparison. The WHTECH RINGDEST.DSK LOAD file has BASIC starting with line number 8980. The last line is IF Q THEN RUN "DSK1.ASSEMBLY" ELSE RUN "DSK1.EXTBASIC". This code block is what I'm calling "loader v2". In addition to testing for 32K memory, it also prints some title information to the screen. The DSK1.EXTBASIC code starts at line 10 and I'm calling it "xbasic v2". So the startup sequence for Extended Basic version is "loader v2" + "xbasic v2", or "loader v2" + "assembly v2". Compare this with IUC XB ZIP/folder. Since this is the only folder that includes a WAV file, I'm making the assumption that the WAV file is the primary source and that the DSK file was obtained from the WAV file. The RingDest-X.dsk has one file LOAD which I am calling "xbasic v1". This "xbasic v1" combines mostly the same BASIC as "xbasic v2", but it adds a slightly modified "loader" code block at the end. This makes sense for tape loading since only one version is being loaded and run, either the extended BASIC or the Assembly. So I infer that "xbasic v1" is meant for standalone running, while "xbasic v2" needs "loader v2" to start it. The IUC XB32 ZIP/folder, appears to be an Assembly only DSK. It has a "loader v2" (same as WHTECH Disk), and "assembly v1". I haven't looked into the assembly yet. But the ASSEMBLY files are BASIC instructions that probably load and run the assembly code. Both versions of assembly are the same except for the first line, "1 ON WARNING NEXT" (assembly v1), or "1 ON BREAK NEXT :: ON WARNING NEXT" (assembly v2). Finally, we get to the IUC Floppy ZIP/folder. For auto loading, it starts with file LOAD (loader v2), the same as the WHTECH disk. That loads the same files, either EXBASIC (xbasic v2) or ASSEMBLY (assembly v2). This is the same as the WHTECH disk. However, this floppy also has two extra files, #RING-B (repeat of assembly v2), #RING-A (a different loader v1). This loader v1 is different from loader v2 in that it starts with low line numbers and ends with IF Q THEN RUN "DSK1.#RING-B" ELSE RUN "DSK1.LOAD". Note that #RING-B is assembly. So this says, run either assembly or run the other loader. Then the other load says run assembly or extended basic. ??? Not sure what "feature" this is providing. Bottom line: It appears both disks are equivalent as far as Extended Basic operation goes. At first glance, Assembly BASIC startup looks the same. Also of note, you can copy/paste the xbasic code from the "txt" folder inside IUC XB ZIP/Folder into classic99 emulator and it runs. So it doesn't appear that the code is loading anything hidden. So that's a good start to modify if interested in standalone Extended Basic version.

Hmm... might decide to dump the contents and see what the extra is between the disks. As for assembly, I'd be in the same boat as you. I'd have to look for any disassembler's that might exist. I've reversed engineered compiled python code and a java program. Haven't tried TI-99/4A.

I loaded that disk with MAME TI-99/4A/Extended Basic Cartridge/PEB HFDC Floppy and it ran fine.

RINGDEST.ZIP There is a extended basic version and assembly version.

http://ftp.whtech.com/video/Chicago TI Fair 2014 Videos/Chicago TI Faire Disk 2014/SPLIT_VARIOUS_1376/N_O_P_Q_R_17/PROGRAMMING_AIDS_I__1980__T.DS Disk image with the BASIC code. (Yes, the last 'K' is missing from DSK)

I took the MAME square wave and processed through CS1ER which creates a sine like wave as output. See if real hardware reads the attached. k-mart-cs1er.wav.zip

Using a PC with sound card. Others have used MP3 players with output jack.

If you have tapes you can't transfer, consider recording to a sound file. Some members enjoy the challenge of extracting information from noisy data.

Neat! Thanks for the explanation.

I was trying out a method of extracting data from sound file of very distorted tape copy. I was trying my algorithm out on various sound files I found at whtech. I'm not familiar with Tape994a. I assume Record 0 is the first 64 byte record after the zero leader and the message count record. I got a good read and checksum for that record. I did a "diff" on your data (past the 128 byte header) to my extracted binary and the first 768 bytes show some small differences in byte values. But the BASIC program listing I got from your file is identical to the one I get from mine.

Nicer than this one

Sort of what I eventually decided must be happening. Once I got unstuck from seeing only the non-viewable characters, I realized that the same strange variable name was used in the following line. The program ran fine, so the variable name must have been valid.

Necro'ing because it was the only duckduckgo hit for "carscarc2". I tried to convert the sound file at whtech/cassettes to BASIC. Everything looks good except line 30002 toward the end of file. 30000 SUB BXB :: CALL INIT :: CALL LOAD ( 8194 , 37 , 194 , 63 , 240 ) 30001 CALL LOAD ( 16368 , 80 , 79 , 67 , 72 , 65 , 82 , 37 , 58 , 80 , 79 , 75 , 69 , 86 , 32 , 37 , 168 ) 30002 ] [ \ [ ]$ = "<snipped non-ASCII text garbage>" 30003 FOR J = 1 TO 136 :: CALL LOAD ( 9529 + J , ASC ( SEG$ ( ] [ \ [ ]$ , J , 1 ) ) ) :: NEXT J :: SUBEND Both copies of the duplicate records pass the checksum and are identical to each other. So I think it was written to tape this way. Some sort of esoteric method of cramming data into a TI-99/4A?

I note that the final line number is 1340. If a typo was made in the original listing, that could become 1430. If the 1430 is replaced with 1340, would that work? (just like this message was full of typo's).

Just to add more specific detail. The TI in question did show up as color when using an adapter cable to go to an LCD component input. The TI showed black and white when going through the RF modulator to a small CRT TV I have. The same RF modulator worked fine with two other TI's I have on the same CRT TV. So in my case, the crystal swap fixed a black and white via RF modulator to CRT problem.

https://www.pagetable.com/?p=672 I had a TI with the no color issue. I swapped out the crystal as mentioned in the above thread which fixed it. Add this info?