InsaneMultitasker

Nice sleuthing. PINLOAD is built upon EXEC code. You are looking at the external master DSR interrupt handler for the emulated /4A environment. During gameplay, memory from 0x4000-0x5fff is used to simulate the ROM cart. This means the master DSR page >07 is no longer visible at the expected address, which in turn means the interrupt linkage is invalid. Naughty. Are you able to determine which device caused the interrupt condition? Can the speech card or speech interface generate an interrupt? If so, the master DSR would not know how to clear it or service it. I suppose the right approach is to page in the master DSR and allow it to service the interrupt, but I don't know if this is a valid interrupt situation. Gameplay shouldnt generate external bus interrupts. Or maybe I am missing some application here. NCSS LWPI >82E0 Check ext interrupt CLR R12 TB >01 JEQ NOINT * * 7..28.94 INTERRUPT HANDLER... * DOINT1000 LI R12,>1000 MDOS Master DSR Interrupt MOV @>400C,R11 this is simple... JEQ NOINT MOV @2(R11),R11 JEQ NOINT BL *R11 do it! NOP NOINT LWPI >83E0 restore GPLWS B *R12 return to level 1 interrupt routine

The below routine is how ABASIC sets up prior to executing a speech call. By comparison in GPL mode, page >03 is mapped and page >BC is never mapped. Does this imply for /4a mode, the gate array always propagates the speech ports to/from the external bus? I -think- the /4a mode bit (1EF4) inhibits external bus access for video, gram, and sound, but I've never confirmed this. The Memex DIP switch can block out >BA but doesn't block >BC, to my knowledge. I would guess that speech access 'corrupts' Memex page >BC, at the speech port addresses. Maybe @FarmerPotato has poked at some of this with Geneve2020. TI994 LIMI 0 MOVB @MAP98,@PAGE8S SAVE THE CURRENT PAGES MOVB @MAP9C,@PAGECS MOVB @CBHBC,@MAP98 NOW MAP IN THE >BC PAGE TO >8000 MOVB @CBH03,@MAP9C AND >03 TO >C000 PAGE LI R12,>1EF4 NOW GO INTO 4A MODE SBZ 0 LI R12,>1EFE SBZ 0 RT

Is the Memex incorrectly blocking (or unblocking) one or more pages, based on slot precedence?

I removed 'Ignored' from the warning and shared the source file with 9640News, for testing purposes. We haven't talked much about how to leverage Github or how to address changes like this that could be released for testing, in advance of a formal release. My PFM device is loaded with v7.40 and after using the modified CD routine for a few days, I realize that I now miss the feature for the reason you cited.

Here is v1.5 of @Asmusr pinball, modified to work on the Geneve. ZIP includes the modified source files and the TIFILES headered files. Simple execution instructions are included. PINBALL 1.5 Geneve 15 July 2023 Final.zip

Thank you for sharing that 3rd byte idea. That would certainly make it simple. though my concern echos yours: modifying the /4A-style Pab could open up some unintended consequences for LOAD/SAVE; even the Geneve does not extend these opcodes while emulating the /4A. For the limited use case that is the Geneve native DSR mode, my initial thinking was to leverage the direct read/write routines in a different way, thus mimicking the SAVE/LOAD opcodes. An alternative might be two new Python opcodes that mirror load/save, but allow for the third byte in some currently-undefined location. All Geneve-based TIPI operations occur in 256-byte increments due to how the DSR is structured, incuding load/save/direct read/direct write. Direct read/write iterate over the number of 256-byte blocks presented, which is why we can copy and perform other operations, and only now realized the limitation with save/load because the OS presents three bytes, whereas the /4a PAB only affords us two.

Makes sense to me. What is peculiar to me is that the TIPI log has no record of the attempted operation and no OS error is generated. The file's byte size is >22000, so masking the high byte should yield a >2000 byte file. The MDOS DSR's error trap looks for a zero byte file and jumps to an error routine, but the error code is not set. Some follow-up is needed on these MDOS opcodes. It's rare that anyone wants to save or load a 0-byte file. I suppose there is a way around the /4a PAB limitation but I'm not sure that I want to go down the path. The MDOS version of the TIPI load/save opcodes could be re-written as 2-part BREAD and BWRITE operations. The first to read/write the file attributes and the second to read/write the file.

Lest I forget the lesson I learned today: if you are using TIPI and have not updated your Geneve OS to 7.40, your first order of business should be to update your system. If you aren't sure what OS version you are running, type "VER" at the command line and update accordingly. If your autoexec clears the screen, consider adding a VER statement near the end of the file. Earlier today, I discovered that the PFM in my development Geneve is still loaded with MDOS v7.30. As best I can recall, I updated my test Geneve, got distracted by 'life', and forgot to follow through to update the more important Geneve. Some (though not all) of what I and others have recently experienced can be traced back to the bug that affected the COPY command in v7.30.

It looks like yours stops in the same place as mine. If you inspect !DOIT, you'll see it stops in the L8\ range of files. The remaining assembly and link statements are missing. The TIPI log shows something weird with the direct input file IO in the native_text file folder. The start block is incrementing by one or more, for each subsequent file, until it reaches DSRPASS-S and then $MAKE locks. I can CTRL-C the $MAKE program, so this isn't a TIPI DSR lockup but it may be induced by TIPI (or MDOS DSR) IO. Edit: I am going to assume this is related to MAKE crashing as I cannot yet reproduce it. I created a non-native folder and was able to assemble MDOS properly, from the TIPI, with all TIFILES headered files. I don't have any more time this morning to dig into this, but I'll circle back in the evening. Edit: The OS file was not created. this may be related to a /4a PAB limitation, since the OS program file is 136K. I have some work to do, I'll test more later.

@dhe I kicked off a full assembly of the OS, using the TIPI native_text folder. About 30 seconds into the process, $MAKE tossed its cookies with an error message, "Don't know how to make "ZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZ" (the X was some graphics character). So there is still something it doesn't care for with one or more files, or a difference in how the data is consumed by $MAKE. Not to be dissuaded, I kicked off the batch file that assembles everything; MDOS is so-far successfully grinding through the source files now. I'll report back in this same post whether the resulting OS starts up properly. The $MAKE issue was due to incorrectly (inadvertently) using MDOS 7.30 instead of MDOS 7.40.

In @9640News repo, it seems the "program" files are 2 bytes, so maybe they didn't come across as expected. In my dev folder, I keep the test program and a test batch file in the MDOS root, so I can just type "test" to load the newly-assembled OS.

@dhe it is possible that the git repo doesn't have the program. @9640News will need to confirm. The folder in your screenshot is for the source to TESTH, TESTM, etc, (which are used to set the correct boot device flag during testing) although it seems the program and DF80 object files should be in the folder. I don't think they are part of the MAKE process.

@Asmusr - I am almost certain that I found the problem with my code. When I added conditional assembly, I created a new label for an EQUate and the label was missing the trailing colon ":". When I inspected the LST file, I found that the value for the speech bank offset was 0x0000 instead of 0x4000. Adding the colon changed the immediate value to 0x4000. I will ask the tester to try again. This would probably explain why he said it worked in an earlier version. 0031 2000 Geneve_bank_delta equ >2000 ;adjust from >6000 to >4000 bank location 0119 speech_bank_base <- missing colon 0120 4000 equ >6000-Geneve_bank_delta ;added label 7.11, see speech.a99 0021 3902 0220 22 ai r0,speech_bank_base ;conditional equate 6000/4000 3904 0000r -<this should be 0x4000! July 15: Confirmed! Speech now works properly! I will release the package soon. Thank you, @Asmusr, for a great game and for your support of the compatibility port. (As time permits, I'll finish posting Flying Shark source and some notes for possible future use)

I ran a simple test program that creates a new DF80, DV20, IF100, and IV90 file. All four files were created with a TIFILES headered file. I was also able to successfully assemble a native text file into a TIFILES headered DF80 file. Outstanding.

The play-related updates work great. 🙂. However, the tester reported that the speech no longer sounds like anything - it is all garbled. I will review my changes to confirm I didn't miss something. I am wondering - did the speech playback changes in v1.2 and v1.3 increase the speed that the speech data is fed to the synthesizer? I see the updates in the interrupt handler but the purpose eludes me.

Thank you. I updated my source file to reflect v1.5. I removed the rs232 debug stub and the extraneous comments. Later this week I'll assemble it and ask someone to test my changes. If the game works on the Geneve, I'll ZIP up the package and call it done. pinball-Geneve mods.a99

@jedimatt42 I sent @9640News a test program yesterday to compare notes. I chronicled my findings in the Geneve OS dev thread but I'll summarize a few findings here: 1. As 9640News indicated, attempting to create a new DF80 file results in a native file. Inspection of the file shows "trash" in the first 100 or so bytes. I used Beyond Compare and captured a screenshot of the TIFILES versus non-TIFILES file, for reference. 2. Attempting to create Internal file types, i.e., Int/Fix or Int/Var, results in a native file. Writing a record to the newly created native file throws an exception in the TIPI log and requires me to restart the Rpi via the web interface. Powering down the PEB does not resolve the halted condition. 3. Copying TIFILES headered files into the native_text folder allows subsequent, proper access to DF80 files and program files. What is the intended support case for the Internal file type, within the native_text folder?

I like the approach where the file types besides DV work with TIFILES, if possible. It already seems to work this way, otherwise the file copies would have resulted in all of the object files being converted to native files. Even if the decision is to limit the file type, the native folder is really slick for source code….

@9640News Unrelated to the native_text issue... I can confirm that ASM is at fault for incorrectly opening the catalog file. If the list filename parameter is empty, ASM parses the current directory and attempts to open it as OUTPUT, D/V 80. As we all know, the catalog file can't be opened in OUTPUT mode so the Geneve DSR returns an error and ASM continues on its way. It is only thanks to the excellent logging in the TIPI that we see this oddity. ASM is protected by CRC traps and pitfalls so for now, this is noted for awareness. We can only guess as to whether this was an oversight or intentionally ignored.

I sent you a PM with some additional file type tests to confirm whether we are seeing the same results. For example, attempting to write a new Int/Fix 100 file generated an error and required me to restart the TIPI. If I am reading the wiki correctly, only DV80 should be read/written as 'native'.

Seems we are at a similar point, @dhe If I copy an object file (DF80) from my ramdisk to the TIPI native folder, I can assemble the associated source file without an error. I noticed this only because I was able to successfully "MAKE GPL" after I copied all source and object files from my ramdisk to the TIPI native_text folder. I compared the files that I copied from the ramdisk versus those I downloaded from github. The source files matched 100%. The object files are a different story. See screenshot. The file on the left was created on the ramdisk, copied to TIPI, and over-written successfully (during assembly) without errors. The one on the right was created as a new file by the assembler and generates the same error you saw during your attempt. If I am understanding correctly, the newly-created object file (DIS/FIX 80) does not contain a well defined TIFILES header. When I catalog the folder, the file shows up as DV80 file, presumably because TIPI thinks it is a raw text file? It would be good for someone to validate my findings and then post in the support forum for @jedimatt42 to review. (I haven't tracked down why the catalog file is seemingly being opened as "OUTPUT, DISPLAY, VARIABLE" on occasion. This might be related to the ASM bug that we found a year or two ago)

@9640News I attempted to MAKE MDOS from the TIPI using the files on Github. The MAKE program crashes and displays a block of gibberish. ASM is unable to close object files for anything it assembles. When I copy from the native folder to a non-native folder, level 2 works as expected. With this make process, the startblock 48 is very suspicious to me and may be a clue as to why the operation is failing. Interestingly, 48*256=12288 + 128 = 12416 bytes. The file is only 11 records (11 text lines) so why is the start block so high? (Edit: need to validate this with a fresh copy) unit: 0, blocks: 1, filename: HVERSIONS, startblock 48 2023-07-08 20:14:31,107 LevelTwo : INFO getFileBytes reading lines from native file 2023-07-08 20:14:31,108 LevelTwo : INFO found 11 records 2023-07-08 20:14:31,109 LevelTwo : ERROR request exceeds file size: 384, start: 12416, end: 12672 I'm not sure what to make of the inability to open the catalog file. This happened during the assembly process. Maybe it is indicative of what Dan is experiencing with DM. As noted in a later post: If the list filename parameter is empty, ASM parses the current directory and attempts to open it as OUTPUT, D/V 80. As we all know, the catalog file can't be opened in OUTPUT mode so the Geneve DSR returns an error and ASM continues on its way. It is only thanks to the excellent logging in the TIPI that we see this oddity. ASM is protected by CRC traps and pitfalls so for now, this is noted for awareness. 2023-07-09 12:22:46,337 TipiService : INFO Request completed. 2023-07-09 12:22:46,345 TipiDisk : INFO Opcode 0 Open - TIPI.MDOS.CYA. 2023-07-09 12:22:46,346 Pab : INFO opcode: Open, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordN umber: 0 2023-07-09 12:22:46,347 TipiDisk : ERROR responding with error: 2 Traceback (most recent call last): File "/home/tipi/tipi/services/TipiDisk.py", line 93, in handleOpen cat_file = CatalogFile.load(unix_name, pab, devname) File "/home/tipi/tipi/services/ti_files/CatalogFile.py", line 45, in load raise Exception("bad record type") Exception: bad record type 2023-07-09 12:22:46,348 TipiDisk : ERROR failed to open dir - TIPI.MDOS.CYA. Traceback (most recent call last): File "/home/tipi/tipi/services/TipiDisk.py", line 93, in handleOpen cat_file = CatalogFile.load(unix_name, pab, devname) File "/home/tipi/tipi/services/ti_files/CatalogFile.py", line 45, in load raise Exception("bad record type") Exception: bad record type

I don't know if this was a "one time" issue with my system or something that might need to be addressed. I updated from 3.14 to 3.17. I loaded PI.CONFIG into an editor, added a "NATIVE_TEXT_DIRS" entry, and attempted to write PI.CONFIG to the TIPI. My system locked up. I reset the Geneve and TIPI/RPi, then repeated the steps to edit PI.CONFIG. The system locked up again. I checked the TIPI log and it reported the following error: Updated from 3.14 to 3.17. Loaded PI.CONFIG into editor Save PI.CONFIG results in the following: 2023-07-08 19:52:13,129 Pab : INFO opcode: Open, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 0, recordNumber: 0 2023-07-08 19:52:13,140 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0 2023-07-08 19:52:13,153 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 1 2023-07-08 19:52:13,167 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 2 2023-07-08 19:52:13,181 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 3 2023-07-08 19:52:13,194 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 4 2023-07-08 19:52:13,207 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 5 2023-07-08 19:52:13,222 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 6 2023-07-08 19:52:13,234 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 7 2023-07-08 19:52:13,245 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 8 2023-07-08 19:52:13,256 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 9 2023-07-08 19:52:13,267 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 10 2023-07-08 19:52:13,279 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 11 2023-07-08 19:52:13,290 Pab : INFO opcode: Write, fileType: Sequential, mode: Output, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 12 2023-07-08 19:52:13,295 TipiService : ERROR Unhandled exception in main Traceback (most recent call last): File "/home/tipi/tipi/services/./TipiService.py", line 90, in <module> if specialFiles.handle(pab, filename): File "/home/tipi/tipi/services/SpecialFiles.py", line 63, in handle handler.handle(pab, devname) File "/home/tipi/tipi/services/ConfigFile.py", line 32, in handle self.write(pab, devname) File "/home/tipi/tipi/services/ConfigFile.py", line 71, in write value = msg.split('=')[1].strip() IndexError: list index out of range 2023-07-08 19:52:14,075 TipiService : INFO physical mode enabled 2023-07-08 19:52:14,084 TipiService : INFO TIPI Ready Line 12 contained the deprecated line "TIPI_NAME=TIPI". I deleted the line and was able to successfully save PI.CONFIG with no errors. When I reloaded PI.CONFIG, the "TIPI_NAME=TIPI" entry had returned (or was never removed). The good news is that saving PI.CONFIG works and no error is reported.

@9640News I see that Dan is setting "MDOS" as his native text directory. What happens to the files that are not DV80 like the PROGRAM files in the root of the MDOS folder? Will TIPI present these files properly? What about the DF80 object files? Edit: files are presented as expected during copy but there may be an issue with some file types created within the folder. See later post regarding DF80 example.

I wouldn't be too quick to blame DM; the issue noted with DM may be a symptom of the problem (hard lock) seen when trying to build Geneve OS. If "TIPI" is a common denominator for the issues with DM and the OS build process, I would suggest that you copy the files to the HFDC device. If there is a file/directory limitation, you'll find that immediately during the copy. If the OS builds from HFDC, then you can dig deeper into the TIPI setup and why the OS won't build from the TIPI. You could have a corrupt GenProg utility, maybe a file in the native directory is being accessed incorrectly, etc. Isolation is important, IMHO. It would also be wise to use CRCOS to verify whether SYSTEM-SYS has been corrupted. @mizapf might know if the DSR space error messages are issues or warnings. The only real DSR spaces reside on the external bus, as the Geneve OS uses RAM at 0x4000-0x5FFF for its DSR. So it would depend on the reason for the writes and what is executing at the time. That's my $0.02 coming late to the conversation.