chris36
-
Posts
98 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by chris36
-
-
3 hours ago, Vorticon said:
The game asks to seek the Heart of Iron. Totally unclear as to the relationship to rubies though since they are composed of aluminum and oxygen without carbon. Now it were diamonds, then maybe there might be a relationship with iron, albeit a tiny one. If I ever run across Scott Adams I'm bitch slapping him.
You might be punishing the wrong villain. According to this, it was written by someone else.
-
2
-
-
If it's one or the other, that implies I would need to recable the PEB. Something I was trying to avoid.
-
13 hours ago, arcadeshopper said:
Drive can be on either the external cable or internal they are the same electronically
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
-
5
-
1
-
-
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.
-
1
-
1
-
-
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?
-
3
-
-
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.
-
3
-
-
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.
-
-
3
-
-
4 hours ago, jrhodes said:
@moije2 thanks! I could have swore i seen this in one of the user group newsletters, but i think this is definitely the routine i was thinking of.
Attaching a pdf for others interested.
Disk image with the BASIC code. (Yes, the last 'K' is missing from DSK)
-
3
-
-
19 hours ago, mizapf said:
Ah, I have a mirror of WHTech, but I searched for the file with lowercase letters... OK, found it.
The difference is easy to see with audacity (did that rhyme?):
MAME can read the recordings from a real console. In contrast, its cassette output is a square wave. It can be loaded safely within MAME again, but if things are what you reported, then the square wave is not accepted by the TI console. That's unfortunate. I'm not sure how to fix this, since I was never really involved with the cassette subsystem. And if I try to fix this, I have no means of verification with a real system.
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.
-
2
-
-
Using a PC with sound card. Others have used MP3 players with output jack.
-
2
-
-
On 1/19/2023 at 11:40 PM, senior_falcon said:
I was able to find my old cassettes containing TI BASIC programs from way back in the day, and after some effort, was able to transfer four of them to my "real" computer.
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.
-
2 minutes ago, Torrax said:
You can delete lines 30000-30006 and resave it back to disk/cassette to make it a BASIC only program.
The lines are adding assembly support (32K req.) to extend the CALL CHAR and CALL COLOR for the missing character sets that are not found in XB. You can find several BASIC games/programs that were modified in this manner to run from XB.
Neat! Thanks for the explanation.
-
2 hours ago, SteveB said:
The WAV seems to be a 48000Hz 32 bit Floatingpoint mono AIFF. I converted the WAV to unsigned 8bit mono PCM in order to read it with Tape994a ... but get this error, no matter what I try...
I was able to load the file in Classic99 XB 2.9 though ... with the same result you mentioned ..
Other than line 0 and 30000+ this looks like a pure TI BASIC program, not XB. Who would redefine CALL COLOR and CALL CHAR...? I am slightly irritated ...
Since it actually run I think the string was meant this way.
CARSCARC2 5.13 kB · 2 downloads
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
-
1
-
1
-
-
4 minutes ago, Ksarul said:
Looking at line 30002, several things pop out. First, ][\[]$ is a valid string name. It is followed by =" which is the standard opening for a string--and at the end of the weird stuff, you have a standard " to close the string. It looks like they were using characters from some of the uncommonly used character sets in this string. It looks like it is actually quite normal.
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?
-
4
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Testing 32K Memory Expansion Card
in TI-99/4A Computers
Posted
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