wolhess

Hello, the CALL PEEK(8198,A,B) is: 170,85 but the CALL PEEK(9456,A,B) is: 131,160 The MegaMenu program was compiled with the runtime routines in low memory and loads with 32K loader as a large program. It shows 6944 Bytes left and low memory 15366 - 16383 free. The program is fully working and I usually don't break the program. If I run a XB program from the menu it works with the normal color and font. And here are the result of your second message about call peek(9436,....) If I run the program from the XB prompt and from the screen above the color changes to Black on Cyan. So a second run and any further run shows Black on Cyan. I have no custom font configured. I use the default files as provided. Only at the magenta screen I use CALL LOAD(9456,23,2) to get a better readable screen:

This is working. After RUN I see the strange screens and the message: If I break the program I get the color and font I assume: If I autoload my Mega Menu program in XB 2.8 I see this: It is correct! If I break the program the color and the font is changing to this: If I run XB 2.8 without autoload I get this font from the beginning: I think this is not the default font, but I will try to patch the bin file with my default color/font.

No, blind typing width 40 doesn't work in my system. I have no AUTOCMD file in DSK1. and I see no disk access after loading FC. With v1.1 I see the disk access and I get the FC prompt after loading.

@BeeryMiller, the fileCreator version 4 is working without an error. The BBS Library files are all correct. Only the file ALLFILES is not correct in the header. The value of level 3 is still >3F XX but this causes no errors.

I will check it tomorrow. Thank you. I wanted to ask for the 80 character support. But I thought I could get it to run normally first. In version FC v1.1, entering width 80 results in the message that is not supported. I will contact you when I have tried this with v1.8.

I have another quirk too: I used two different FG99 cartridges in my tipi system and both are working fine. Without any error. I checked TI XB and XB 2.8 G.E.M switch to FC1.8 and back. AUTOCMD.zip But if I use one of these FG99 in my none tipi system I get after some disk access only a blue screen. My none tipi system configuration: TI EU console prepaired with a snug REPL99 card FG99 with XB 2.8 G.E.M. and FC PEB with snug EVPC2 (V9938) RGB output, 32KB memory expansion CorComp Floppy Disk Controller DSDD 3 x 3.5 "DS40DD, 1 x 5.25" DS40DD floppy drive RAVE99 with speech card P-Code Card FC v1.1 is working with this system!

Oh, you are fast !!!! I will make a test. EDIT: It is working now! Thank you.

It seems it works but I get some flaky screens before the XB 2.8 and TML prompt. I started with XB 2.8 and run the first part (I named it TEST1) Then I did the CALL TML, OLD TEST2 and RUN The following screens I see every time I run the program:

Hello @jedimatt42, in my script for FC the command readkey is no longer working. In v0.M and in v1.1 it works as I expect. In v1.5 and in V1.7 the TI hangs with bad sound after a readkey. AUTOCMD.zip I have stripped down my script to test readkey at the command line. The working v1.1 The TI stops with continuous sound after a key is pressed The TI stops with continuous honk sound after a key is pressed This is the system I was testing: TI EU console FG99 with FC Speech synthesizer PEB with TIPI, SAMS 1Mb (incl.32KB) HRD4000B, TI Disk Controller with 80 Track mod. 1 x 5.25 "DS80SD, 1 x 3.5" DS80SD, 1x5.25 "SS40SD floppy drives

Hello Harry, With the XB 2.8 G.E.M you have created an excellent Super Extended Basic! I just started my Mega Menu program (normal XB compiled with Isabella) from a normal disk system and everything works as it should. Then I did the same with my TIPI system and everything works as it should. Now it's time to look a little more intensively with the new possibilities. I tested on the following two systems: System 1: TI EU console FG99 with XB 2.8 G.E.M. Speech synthesizer PEB with TIPI, SAMS 1Mb (incl.32KB) HRD4000B, TI Disk Controller with 80 Track mod. 1 x 5.25 "DS80SD, 1 x 3.5" DS80SD, 1x5.25 "SS40SD floppy drives System 2: TI EU console prepaired with a snug REPL99 card FG99 with XB 2.8 G.E.M. PEB with snug EVPC2 (V9938) RGB output, 32KB memory expansion CorComp Floppy Disk Controller DSDD 3 x 3.5 "DS40DD, 1 x 5.25" DS40DD floppy drive RAVE99 with speech card P-Code Card Thank you for this new Extended Basic! Wolfgang

Hello @Hugo Cervantes that is exactly what I would like to recreate for my TI-74. Thank you

@Beery, The DSR issue for the three categories CAT13, CAT17 and CAT30 is still there. The correct "total number of sectors" is now written in the file header, but the value of level 3 is still >3F and this causes the DSR error. If I correct the level 3 value it is working: The Gameshelf files that I have added are missing from your EXCEL sheet V3. I've pasted all of my changes into your FileCreator Version 3 file. So you can make further changes with this file. I changed the name to "FileCreator Version 3a" and included the BBS folder with all the library files. BBS-V3.zip

@Beery, no, I didn't update the excel sheet. It's the same as in post #243.

No hurry, the files are corrected and if I will make a new run to add some files now I know what i have to do.

Hello, Even with the last TIPI update, the "DSR ERROR" problem in the DATA LIBRARY with certain files is not eliminated. I looked at the files today and found that the file sector number was incorrect. In the case of faulty files, >3F is always the total number of sectors in the file. I corrected the number of sectors and now the files are working in the BBS system. Here are the corrected files for exchange in the BBS system. Simply copy the files to the BBS folder. T61T07, T81T07, TE1T07; Data library: TI – Application – Music (CAT13) T63T02, T83T02, TE3T02; Data library: TI – Programming – Extended Basic (CAT30) T63T03, T83T03, TE3T03; Data library: TI – Programming – Assembly (CAT17) and the File: ALLFILES BBS-OK.zip The faulty files are generated directly by the Excel script. It only affects files with approx. 33kb to 39kb and the ALLFILES file. For comparison, here are the defective files: BBS-WRONG.zip An example of my changes The File T83T02 from the excel script: I corrected the value >3F to >99 TIDIR displays the files without any problems, but a conversion to PC files leads to smaller files of >3F sector length. The defective files cannot be imported into the TIIMAGE tool either. After the correction, importing into the TIIMAGE tool also works:

Today I tested my video converter again with a new set of cable and now it is working without flickering. So @arcadeshopper was right. In my case it was a contact problem.

Yes mine was from china!

I run it with my FG99.

I bought the same a view weeks ago and tried it yesterday and today again. Yesterday it does function without a flicker. But today I saw the screen flickers from start on. After time it was not so often. Today I was using a 19“ VGA Monitor, yesterday I used a Samsung LCD TV and a Sony LCD TV. I will check it again tomorrow.

Thank you @F.G. Kaal for adding the 40 and 80 column debugger into Editor/Assembler V. This EA .bin file is a very smart development environment for doing assembly on the real TI-99/4a. And for your information the Guy who was creating a dot directory on the IDE I think that was me too. It was my mistake, so sorry for the additional work.

Hi @adamantyr, For me, the box with the disk labels is enough. But when the cartridge version is available I will buy it too. Wolfgang

@InsaneMultitasker, Yes, in step 6 I could complete the assembly without an error. In the pdf document you will see it in details.

On the way to do this there were some errors: First I worked with the fixed files from the disk image RFILE-fixed.dsk, see the following steps and the document with some screen shots. 1. I put the disk image RFILE-fixed.dsk to E:\ti99\TEST 2. I made a new folder on the tipi called TIPI.XB.DEV.FILETEST.ORIG and copied the files to this folder using Ti99Dir. 3. Then I converted the v9t9 files to tifiles using Ti99Dir. 4. With DM2K I copied the files to the HRD DSK9 and did nothing else. 5. I copied the files back to tipi in a different folder TIPI.XB.DEV.FILETEST.TIRDTI 6. Using the TI EA to assemble the source RFILE1-S9. (ASM1, ASM2 and EDIT are on physical drive DSK1. --> I could assemble the program without an error! 7. I tried to load RFILE1-S (not the S9 version) with EDIT but this doesn't work. --> I got * ERROR* and I/O ERROR CODE 7 8. Then I want to check if the RFILE1-S could be assembled, so I copied the files 99DSRLNK-S, 99SUB2-S and 99VDP4-S to my physical. DSK2. to make sure the EA finds the COPY source files. --> The EA could assemble the program without an ERROR 9. I tried again to load the main source file RFILE1-S but got the same error as in item 7. 10. So I used the EA V to load and edit and save the RFILE1-S file and this was working! --> After editing the file with EA V the EOF offset in the file header was >47 and before it was >46. In the pdf I made some screen shots. FILE-COPY-HRD-TEST1.pdf Second I worked with the bad files from the disk image RFILE.dsk 1. Copied the disk image with the none working files from RFILE.dsk to E:\ti99\TEST 2. Open the diskimage in TiDir and copied the files to TIPI.XB.DEV.FILETEST.RFNOW 3. Using TiDir to converted the v9t9 files to tifiles 4. Using Dm2k to copy the files to HRD DSK9. 5. Using TI E/A to assemble the file RFILE1-S9 and check if the problem is there. -> **DSR ERROR:02F4 * ERROR I/O ERROR CODE 0 The problem is there! 6. Edit DSK9.RFILE1-9S from HRD with the editor of TI E/A 1981 does not work! -> * ERROR * I/O ERROR CODE 7 7. Edit DSK9.RFILE1-9S from HRD with editor of Fred Kaal’s EA V and save it to: TIPI.XB.DEV.FILETEST.RFEDIT.RFILE1T-9S 8. Load DSK9.RFILE1-S9 from HRD with EA V and save it to DSK1.RFILE1F-S9 -> * ERROR * I/O ERROR CODE 0 9. Save it to HRD DSK9.RFILE1F-S9 is working! 10. Load DSK9.RFILE1F-S9 from HRD with TI E/A 1981 works now, saved it to DSK1.RFILE1F-S9 does also work. So I saved it to DSK9.RFILE1FF-S 11. Using Dm2k to copy the files from HRD DSK9.RFILE1F-S9 and Floppy DSK1.RFILE1FF-S to the tipi folder. 12. Using Ti99Dir to make a new disk image RFILECPY.dsk and copied the following files to it: RFILE1-S9 The original bad file that doesn’t assemble RFILE1T-S9 The loaded and saved file to TIPI with EA V. RFILE1F-S9 The loaded and couldn’t save to floppy but save to HRD file with EA V RFILE1FF-S The saved file from EA V to HRD, load it again and saved it to floppy DSK1. RFILECPY.dsk On the HRD4000B I have the ROS 814F loaded, so the assembling with file names up to 10 characters is working. If I should do any more testing, please let me know.

I made the disk image with Ti99Dir 7.2a 20200628 and copied the files from the tipi folder direct to the new created dsk image. In the past I had some more file problems with Ti99Dir as I copied a lot of files for my BBS "MYTBOX99". In those cases I used the tiimagetool from Michael Zapf (mizapf) and after loading the bad files with this tool it was corrected and working.

Hi @InsaneMultitasker, I changed the ROS to 814F and now I can assemble the four source files all with a 10 character name. The config shows me a 2000K RAMDISK and a 6184K RAMBO RAM. Is this true? Or is the RAMBO RAM limited to 2000K? In the newer ROS the cofig program shows always a RAMBO RAM of 2000K even I used the complete RAM for the RAM disks. Then I tested the version with the coruppted file and it shows me the DSR ERROR. I corrected the file and tried it again at then it assembles without any error. It seems that my problem was two damaged source files and for the newer ROS the file name length more than 8 characters. Thank You very much for your help. Now I'm happy.