Jump to content
IGNORED

Geneve OS development discussion


Recommended Posts

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. 

  • Thanks 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.  

image.png.4469c7cf684b4cfec98fe703d78db8f5.png

 

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

 

image.thumb.png.57be25538fab9cce258699d327d50a87.png

 

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 

 

 

  • Like 2
Link to comment
Share on other sites

@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)

 

image.thumb.png.1a54f40e7a60d3b39a5163be9d30cbe1.png

 

image.thumb.png.3e8785ff6700eaa9d12d6fe1146fab45.png

Link to comment
Share on other sites

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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. 

 

Link to comment
Share on other sites

@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.    

image.png.33b94b6c5b2461b9d22111a181e3a072.png

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.

image.thumb.png.f483430bae613071ed0c93ca76f57641.png

 

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. 

 

 

  • Like 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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)

image.png.8ae4217cd90aa2329ed9d4c8ed3832fc.png

  • Like 2
Link to comment
Share on other sites

@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. 

 

 

  • Like 1
Link to comment
Share on other sites

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

image.png.2d16d2a233df4f9a542453b43450f95c.png

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.

 

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

The LOAD-IDE and LOAD-SCS programs are locked to the CRU addresses defined in the MDOS 7.30 release.  We will be updating the loaders to look for the IDE1. and SCS1. devices, respectively, and to set the CRU accordingly.  We will also check the TIPI loader and update it in a similar fashion, if necessary.

 

The IDE and SCSI loaders contain OS CRC validation routines.  As far as I know, the last few builds have been distributed with the validation flag set to 'disabled'.  The code isn't hurting anything and I suppose I could retain it, but I feel like now is a good time to simplify and do some spring cleaning. 

  • Like 4
Link to comment
Share on other sites

  • 4 weeks later...

Any chance of getting the old load-sys versions upload to github?

 

I was looking at 9640news.com and the forth github is no longer private, but I'm unsure of how to get the files in to mame and or on a Geneve so that they run?

 

It looks like the version of Forth is from McCann. Did Bill Sullivan ever release his forth for the Geneve or was it just in the development stage?

Link to comment
Share on other sites

Posted (edited)

It was "Dragon Forth" - exists just like Dragons exist. The were 11 orders for it but only 10 were delivered. The bulk of the code for FORTH+ was done by McCann Software and Mark Wills (in his pre-TurboForth days). I am not aware of anyone who has a working copy. 

Edited by atrax27407
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 4 weeks later...
2 hours ago, dhe said:

Just checking, as I'm doing some updates, and locked inside by 95 degree temps, is 7.40 still the current release of Geneve OS (that's whats current on 9640news).

 

The first post of this thread will typically indicate the current version and link to the related post.  
 

@9640News posted the 7.45 packet in April of this year, but I haven’t linked to that post as we were going to create a single Geneve OS/MDOS support topic for all future releases and support questions, similar to the TIPI support topic.  

  • Like 2
Link to comment
Share on other sites

Has this been fixed (quote from you):

Quote

@9640News  the latest LOAD-SCS needs to be updated.  The loader address has not been patched from >2000 to >A000.  It appears that the IDE and SCSI versions in the 7.45 ZIP have the same issue.  The TIPI and MFM loaders are OK.

 

  • Like 1
Link to comment
Share on other sites

17 hours ago, mizapf said:

Has this been fixed (quote from you):

the latest LOAD-SCS needs to be updated.  The loader address has not been patched from >2000 to >A000.  It appears that the IDE and SCSI versions in the 7.45 ZIP have the same issue.  The TIPI and MFM loaders are OK.

Fixed, yes.  Released?  I am not for certain.  I sent some feedback to @9640News this weekend.  (He had sent me some files about a month ago).  Both he and I have been quite busy, so I'm sure he'll review when time permits.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...