Geneve OS development discussion

[+InsaneMultitasker]

15 hours ago, InsaneMultitasker said:

The error reporting is a bit more complicated and may be similar to what I found in the floppy write routines.

@9640News I checked the low-level hard drive (scsi, ide, ramdisk) sector IO routines and the error return routines. The error code seems to be consistently returned via R0msbyte which is ultimately passed to the DSR error reporting routine.  I have no further actions for the TOPFCB bug.  The Delete, Close, and SAVE opcodes all seem ok now, based on code review and general testing.  There are probably other oddball unrelated boundary conditions and error reporting to be found but I'm done looking for problems today.  Thanks for putting the release packet together; I will review it today. 

[+mizapf]

On 4/13/2024 at 5:26 PM, InsaneMultitasker said:

Oh, that reminds me.  I encountered - during soft and hard resets - times when the TIPI web socket was not yet 'connected' before I accessed the TIPI, which in turn caused the OS to hang indefinitely. I am not yet sure if this is related to a change in MDOS and/or something that needs to be reviewed in MAME's  emulation, so I will do some more testing and review.

If you run the emulation with -oslog (or -log), do you see some message like "giving up" related to the TIPI client?

[+InsaneMultitasker]

1 hour ago, mizapf said:

If you run the emulation with -oslog (or -log), do you see some message like "giving up" related to the TIPI client?

@mizapfIs this the log you refer to? (see screenshot below).  I am testing with MAME .258; I track your MAME topic so I know I'm behind a few point revisions but nothing that seemed necessary for me to update. I can update today if you want me to. Anyway, here is a more in-depth description of the problem.  I wonder if what I am seeing could explain any of @arcadeshopper's  freezes while loading cartridges, since GPL also executes the same powerup as the Geneve OS.

------

When the Geneve starts the OS, it executes a powerup of all peripherals.  The OS then processes the AUTOEXEC file.  If the AUTOEXEC contains any file or directory accesses to the TIPI, the DSR waits for the RPI indefinitely, even after the RPI connection is established.  If I place a PAUSE statement in my AUTOEXEC and wait for the RPI connection to establish, all subsequent TIPI access works as expected. It is reproduced more easily (for me) by booting the OS from the ramdisk with an autoexec on ramdisk DSK6.  

 

To summarize: 

1. EPROM boots OS from Ramdisk

2. OS executes powerup for all peripherals

3. OS starts the command line interpreter

4. OS starts processing the AUTOEXEC from DSK6. (ramdisk)

5. If a TIPI file or directory is accessed prior to "Connection established", the TIPI DSR gets stuck waiting for a response from the RPI.

 

My guess is that the command bytes sent to the TIPI - prior to establishing the connection to the RPI- are never sent to the RPI after connection is established; thus the RPI has no knowledge of the pending request and so there is nothing to acknowledge. Meanwhile, the TIPI DSR patiently waits for a response.

 

Here is the code and associated screenshot (below) of where the TIPI DSR is trying to receive the response:

File: SCS2.MDOS.TIPI.XOPS  Page: 20  Date:04-17-23 @ 23:39:57

       LI   R2,TSRB      ;yes, good to go
       MOVB R2,@TCOUT  ;0xdffd

RM2    MOVB @RCIN,R3   ;0xdff9
       CB   R2,R3
       JNE  RM2

 

 

This is the TIPI powerup sequence in the Geneve DSR.  I am fairly certain this was enabled starting in the 7.4x revisions. MDOS 7.30 probably won't exhibit this lockup issue. 

TCOUT  EQU  >5FFD
TDOUT  EQU  >5FFF
RDIN   EQU  >5FFB
RCIN   EQU  >5FF9

       SBO  0            Enable TIPI
       CLR  @TDOUT       tipi data output
       CLR  @TCOUT       control output
       SBO  1            trigger reset signal to RPI
;;     LI   R1,>0200*6   play safe with timeout
       LI   R1,>2000*6   
TIPUL1 DEC  R1
       JNE  TIPUL1
       SBZ  1            turn off reset signal

       SBZ  0            ;7.23.2022, turn off card only if 

 

 

[+InsaneMultitasker]

@9640News Found a few updates for the Video XOP reference manual. Screenshots are from the manual on the 9640News site.

 

Opcode >27 

The control sequence to set the row/column should be documented as >20+row and >20+column. 

To set Row 23, column 0: 

>1B, >3D, >20+23,>20+0 which is >1B,>3D,>37,>20

 

Opcode >28

Both R1 and R2 are used. The values are flags that instruct the XOP to reset the characters and/or sprite definitions.

* RestoreCharSpritePat
*
* R1x = Restore Chars?   (0=No)
* R2x = Restore Sprites? (0=No)

 

 

[+mizapf]

This is an interesting point with the TIPI. Have a look here:

https://github.com/mamedev/mame/blob/master/src/devices/bus/ti99/peb/tipi.cpp

 

lines 280 ff. and 465 ff. Notice the role of the member m_connected: If there is no active connection, sending is ignored.

 

The problem is that I don't actually terminate the connection in MAME, it is the Raspberry side which receives the RESET command. Line 270 shows that I send "RESET", nothing else (no explicit closing of the connection). I don't have the TIPI here, will have to check next Friday, but this is what I can imagine.

 

I think that on the bottomline, this can only be fixed when the Raspberry side can be configured not to break up the connection on RESET.

[+InsaneMultitasker]

4 minutes ago, mizapf said:

lines 280 ff. and 465 ff. Notice the role of the member m_connected: If there is no active connection, sending is ignored

Thank you.  Instead of ignoring the send, can you hold the send until the connection is established?  Or is that a silly question within the context of an emulated machine.  The scenario might be something to ask @ jedimatt42 about, after you check into it.  I'll review the GPL file loading and other reset-related scenarios sometime this week and report what I find. 

 

[+InsaneMultitasker]

@mizapf for your testing reference.  The one problem was fruitful and multiplied into three opportunities. 

 

1. Using the ampersand to execute a batch file performs a soft reboot, which also resets the peripherals; you do not need to hard reset the Geneve.  The log shows the memory check (for available pages), TIPI closes the connection, the RS232 ports are reset, and a second or two later, the TIPI attempts to connect to the RPI and succeeds.    

2. With GPL 7.30, the RS232 UART and HFDC see activity.  When I press ENTER, the same two activities repeat. If I attempt to load a file from TIP1, the TIPI connection is closed and then restarted, and GPL locks up in the DSR and never returns. 

3. GPL 7.40 and EXEC 2.8 follow the same pattern as 7.30.  Which makes sense: they are all using the same powerup.

4. If I load a file via EXEC, exit the program, then try to access TIP1, MDOS locks up.  I see the connection close and reconnect. the OS gets stuck in the DSR.

 

There may be two issues:  a MAME reconnect problem and a GPL/EXEC powerup mistake.  I'll review GPL/EXEC this week, as the MAME log does not show what I expected to see. 

 

5. Since we can never have too many problems:  when I start the emulated Geneve from a hard reset, MDOS loads from the ramdisk.  If I press SHIFT-SHIFT-CONTROL, the geneve boots from the MFM drive.  I noticed this because MDOS 7.44 is on the MFM drive and MDOS 7.45 is on the ramdisk.  (After a S-S-C the TIPI connection is closed and then reopened.) To rule out the TIPI, I removed the TIPI device from the PEB and tried again: no change.  After a S-S-C, the EPROM will only boot from the hard drive.  After the third attempt, I cataloged the ramdisk then pressed S-S-C, and the OS booted from the ramdisk.   @9640News mentioning you for thoughts. This occurs with both EPROM 0.98 and EPROM 2.00. The symptoms suggest either MAME or the EPROM are not resetting the Ramdisk to a known state. I cannot test with real hardware at this time. 

 

 

[+arcadeshopper]

7 hours ago, InsaneMultitasker said:

Thank you.  Instead of ignoring the send, can you hold the send until the connection is established?  Or is that a silly question within the context of an emulated machine.  The scenario might be something to ask @ jedimatt42 about, after you check into it.  I'll review the GPL file loading and other reset-related scenarios sometime this week and report what I find. 

 

this is how the hardware works.. any sending to the pi hangs until a response

[+InsaneMultitasker]

On 2/27/2024 at 6:51 PM, 9640News said:

I believe back 2+ years ago, I posted the wrong source files and the wrong LOAD-xxx files for SCSI and IDE.  Check these updates out:

LOAD-IDE 2.92 kB · 6 downloads LOAD-SCS 2.92 kB · 7 downloads

@Shift838 try this scsi loader and see if it works.  

[+InsaneMultitasker]

I re-enabled the debug output in the OS and reviewed what is happening in the OS. The seemingly delayed "closing connection" and subsequent "connection established" activities are a side effect of the Geneve OS powerup routine.  Instead of immediately resetting the TIPI card during a powerup, the OS sets a flag that forces the TIPI to restart the next time it is accessed.  This does not adversely affect the TIPI nor its operation but it is misleading in the sense that the TIPI powerup can happen seconds or hours later.  The OS delay explains why the MAME error logs do not match what I expected.  Alas, the code does not lie!

 

I do not recall why I encoded it this way, other than it may have been a forgotten precursor to the later cleanup and updates I made to the master DSR and the OS XOP powerup routines.

 

I will think about a way to align the TIPI powerup with the other device powerups. 

 

Per your PM, I enabled the TIPI "Wait for initialization" switch and this seems to have resolved my earlier problem. (edit: related to MAME lockup up during a TIPI access following a powerup)

[+InsaneMultitasker]

@mizapf and @9640News 

 

The reboot problem I described in item #5 (April 14) is precipitated by an ancient piece of 8-bit ramdisk code in the Geneve EPROM.  

 

The early ramdisk addressing was 8-bit wide and the Geneve's EPROM uses low-level CRU access disassembled from JPH's EPROM-based 8-bit ramdisk DSR.  It is for these two reasons that SYSTEM-SYS must reside within the first 1023 sectors of any size ramdisk.

 

When the system is first turned on, I believe that all ramdisk CRU address bits are set to zero (in 8 and 16 bit ramdisks) allowing the Geneve EPROM to find a bootable ramdisk.  If the last sector accessed before a reboot is #1023 or higher, the MSByte in the 16-bit ramdisk CRU address is no longer >00.  Since the EPROM's routine operates on 8 bits, the MSByte is never cleared, sector 0 cannot be found, and the 16-bit ramdisk is "invalid" as a boot device. 

 

There are potential action items for both MAME and the Geneve OS: 

 

1. If a hardware reset and/or card deselect (SBZ 0) is expected to clear the Ramdisk's CRU RACK selection bits, then MAME may be a contributing factor.  Review whether real hardware matches emulation.

2. If a hardware reset and/or card deselect does not clear the Ramdisk's CRU RACK selection bits, then we have a few software changes to consider:

    a. Upon completion of any Geneve OS 16-bit IO, clear the CRU's MSByte before exiting the DSR.

    b. Update the Geneve boot EPROM to clear the MSByte of the CRU address* before selecting the RACK.

    c. Optional:  incorporate the Geneve OS 16-bit routine into the EPROM, to resolve the 8-bit sector limit*

 

*This might require testing the ramdisk hardware to determine if it is 8- or 16-bit. 

 

 

[+InsaneMultitasker]

OK, one last mystery solved for the day.  These three HFDC CRU bit log errors weren't too hard to find. 

The GPL /4a mode powerup starts by setting the CRU to >1100 then clears 8 CRU bits with a LDCR @H00,8 statement.  Could this cause any adverse effects to the cards normally at >1100 (TI FDC, Myarc FDC, CorComp FDC, Myarc HFDC and now TIPI) ?    If the card allows CRU bit changes without an SBO 0, I'd say "maybe"; I don't think many cards besides the RS232s allow this.  I'll look through older GPL releases just in case this line of code was accidentally moved from some other routine.  Regardless, I'll clean this up.

 

[+mizapf]

You're right, the incoming RESET line was never implemented on the emulated Horizon card. I'll add that. The P-box emulation and the parent class of the cards already offer the reset line, so it is just a matter of overriding the empty virtual function.

 

I will send you a newly built MAME executable to try it, maybe today.

[Shift838]

On 4/19/2024 at 9:17 AM, InsaneMultitasker said:

@Shift838 try this scsi loader and see if it works.  

@9640News is the LOAD-SCS in this message the latest: 

 

 

[+9640News]

2 hours ago, Shift838 said:

@9640News is the LOAD-SCS in this message the latest: 

 

 

No, it is not.  The latest was posted up a few messages and I am posting it again here.  I checked github, and the SCSI code was missing the boot tracking line.  Use this file.

 

 

LOAD-SCS

[+InsaneMultitasker]

3 hours ago, mizapf said:

You're right, the incoming RESET line was never implemented on the emulated Horizon card. I'll add that. The P-box emulation and the parent class of the cards already offer the reset line, so it is just a matter of overriding the empty virtual function.

 

I will send you a newly built MAME executable to try it, maybe today.

Thanks.  No rush.  I sent the HFDC CRU fix to 9640News a short while ago.  There is more work to be done across the OS/GPL/EXEC but that is for a later release.