Hyperion Entertainment Message Boards

I think most of us have experienced system freezes that require pressing the reset button. Most of the freezes I've experienced actually appear to be I/O freezes since things like clocks continue to work. Are there any pins on the X1000 motherboard where I could connect a switch that could be monitored by a background daemon and start a soft reboot if the switch is pressed??

Xena has plenty of unassigned I/O, And a fair bit that is connected to the fast localbus.
But joining them would require loading code into Xena, and then monitoring some specific addresses from the system side.
I have done it, but it's not at all a "simple" solution.

There is another bit that might help, but describing the details may get a bit tricky here... If what I am writing does not make sense, please keep asking questions until I am clear.

The bit has a 20 ma constant current driver already wired to it. So it is _intended_ to be an output.
When the system is booted up without any unusual code, the bit is configured as an Input. This is not unusual, as input is the safer default choice.

You can monitor this bit by simply adding an LED, or even moving your "Power" LED to this set of pins.
Software is available to enable, set, and reset the output from any script, and there are also includes so you can easily do so from any C program.

My own X1000 user startup includes the following line:
work:userC/LED_p31 ON

Which sets the bit as an output and turns it on.. making my power LED stay on, just like "normal"..
But I can turn it off from any script or program, and that gets useful some times.

But it's not quite what you asked for.


Follow Up: Page 10 of the tech ref manual says there are two jumpers on the Nemo board that are available for users.
They are on the LV side, so I wouldn't extend them outside of the case without some isolation.

Just fit a momentary pushbutton to a suitable header and plug it in. You can then read the GPIO for results.

Have Fun!

xenic wrote:Are there any pins on the X1000 motherboard where I could connect a switch that could be monitored by a background daemon and start a soft reboot if the switch is pressed??

Is it likely that the said daemon would still be running?

I get the occasional "lockup" on my X-1000 (which is admittedly not running an up-to-date system). In my case the machine freezes solid (once a week or so) while I am moving a scroll bar, dragging a window, doing something on the screen. Never when I am just typing in a window. I suspect it is an Intuition lockup, but it is so rare that I can't possibly go looking for it. I've had it happen in various apps, so it's not just the one that I use most often.

These days I just make sure to save documents frequently. The only recourse is to hit the case reset, as USB has died as well. There is no serial output.

Just thinking would it be same issue here or not.
On Amigans.net we have discussed Vice C64 emulator problems, I have random freeze problems.
The situation when I get totally freeze (randomly) is when I press right mouse button to change settings etc.
Any ideas, maybe this is Vice problem or could it be OS problem?

LyleHaze wrote:Follow Up: Page 10 of the tech ref manual says there are two jumpers on the Nemo board that are available for users.
They are on the LV side, so I wouldn't extend them outside of the case without some isolation.

Just fit a momentary pushbutton to a suitable header and plug it in. You can then read the GPIO for results.

Have Fun!

My manual doesn't say anything about user pins but I can guess that it's JP1/JP2. Is there a system function for reading the GPIO pins or do I need a register address for reading them? This seemed like a good idea when I first considered it but if a system freeze is an indication that the Kickstart memory has been compromised, a soft reboot may not be a good idea. I might first try running come code in the background on a delay to see it a program will actually work after I cause a system freeze.

tonyw wrote:Is it likely that the said daemon would still be running?

Most of the system freezes I've encountered leave the clock (digital) running on my Workbench, so some programs apparently continue to run after some system freezes. I've found an Intuition function call that I can use to intentionally cause a freeze and am going to write a small program with some sort of I/O to see if it also continues to run. As I mentioned to LyleHaze, I'm having second thoughts about finding a way to cause a soft reboot after a freeze because the freeze might indicate that the Kickstart memory has been corrupted.

xenic wrote:.... I can guess that it's JP1/JP2. Is there a system function for reading the GPIO pins or do I need a register address for reading them?

It's register addresses and bitmap masking. Not difficult but not system friendly either.

xenic wrote: like a good idea when I first considered it but if a system freeze is an indication that the Kickstart memory has been compromised, a soft reboot may not be a good idea. I might first try running come code in the background on a delay to see it a program will actually work after I cause a system freeze.

I am always a fan of erring on the side of caution. Especially when I am developing, I need a "rock-solid" base system, so I can be sure all my problems are truly my own creation.

I don't have the registers and masks handy, but if/when I put them together I'll try to copy them back here as well.

LyleHaze wrote: I don't have the registers and masks handy, but if/when I put them together I'll try to copy them back here as well.

Years ago I wrote 68k assembler routines to read data from a parallel port digitizer on a classic Amiga but the CIA registers were well documented for a classic Amiga. I don't want to go poking around in the X1000 registers unless I'm positive about what I'm doing.

I did run a test to see if a program would continue running after a freeze. I compiled a small program that writes some words to a shell window once per second. When I caused a freeze by sending a NULL pointer to an Intuition function, the program kept printing to the shell window until it reached the bottom and the scrollbar needed updating. Apparently the freeze had disabled Intuition but not the entire system. Maybe some system freezes could be avoided if the system libraries did more NULL pointer checks and out-of-range checks instead of just failing.

I think Intuition semaphores should have a timeout to allow other applications to continue to run after a short while (1-2-10 seconds?) in case an app enters an intuition function and crashes (which is very common).

That would also allow the Grim Reaper to show up (which needs lots of intuition support). This tiniest-intuition-mistake-causes-deadlock is quite lame, especially when a quick soft-reset is never possible in this situation either due to its reset hooks that also hang.

If the machine could be kept running to allow saving work and possibly allowing a soft-reset instead of a 1-minute button-reboot it would be a big step forward in AmigaOS!