Using VIA2 and ISR to "auto-reset" system after N seconds

[voidstar]

NOTE: for the emulator, you have to run it with the "-via2" command line argument to enable VIA #2.

So an idea occurred to me: suppose I want to demo software on the X16 "non-interactively." That is, suppose I want to rotate between a set of sample titles every few minutes (and suppose that software is just some demo-thing that doesn't require keyboard input). And I want to then rotate/load in another software automatically after the first one finishes, and do so automatically. Sort of like in-store running demos that cycle between software, but without impacting the build of those software titles.

One way I thought to do that is to install an ISR that uses the VIA#2 counter to increment a value in memory every second. When that value reaches my desired wait-time (say 10 seconds), then just invoke a system reset (and then the autoboot.x16 of the system would manage RNG selecting a program and loading it, etc).

So attached is an example that does exactly that, using BASLOAD to set it up. You could BLOAD the asm blobs yourself and not involve BASIC, but the example here is intended where the BASIC MAIN_LOOP would be replaced by the menu-selection or program-choice code if desired.

Basically set $0404 (in golden RAM region not used by BASIC or System ROM) to the number of seconds to wait until the ISR forces a reset. This example is setup to only use a single byte, so max is 255 seconds or a little over 4 minutes.

The code to "install the ISR" (add it into the ISR address chain) is at $0500 (also in Golden RAM). This setup also involves configure the VIA#2 to initiate a 1-second counter (independent of whatever else the system is doing).

The ISR itself is set at $0600 (also in Golden RAM), which monitors the VIA#2 counter to determine if the specified number of seconds has elapsed - and if so, then issue the reset.


NOTE: The following example, just BASLOAD "RNDRESET.BASL.TXT" (don't need to rename it to .BASL but you can), then just RUN it. It shows how to proceed with an interactive BASIC program while it is running. The default demo will automatically reset the system in 10 seconds after running it. Note, despite the name, this isn't really "random" yet - the idea was the value written into $0404 would be a random number of seconds, but I just set it to 10 seconds in this sample.

NOTE: When using on hardware - the VIA#2 hardware has to actually be installed! When I first tested this on hardware, it wasn't working - and turns out it happened to the one X16 that I didn't put the 2MB and VIA#2 chips in! Ha! But it does work on hardware.

[voidstar]

Obviously this falls apart if the demo-program you're loading stomps over golden RAM or makes use of the VIA#2 for itself. But at the moment I'm not sure if anything does.

But a "polite" program should add it to the ISR-chain if it does define its own ISR - so that shouldn't be an issue. Aside from that, then it's just finding regions in the Golden RAM that don't interfere with those programs that are being loaded. There are a few small set of addresses in the zeropage that could be used, or maybe use a different RAM BANK.


Another note: you can get "more time" by changing the increment time on the VIA#2. I found that a VIA count of $7B7B equated to about 1 second of Jiffies. You could double that to $F6F6, so that each increment of MEM[$0404] takes 2 seconds instead of 1 second. That would then mean $FF in mem $0404 would equate to about 8.5 minutes, so you can give up to that much time between resets (within a single byte).

[ahenry3068]

Obviously this falls apart if the demo-program you're loading stomps over golden RAM or makes use of the VIA#2 for itself. But at the moment I'm not sure if anything does.

But a "polite" program should add it to the ISR-chain if it does define its own ISR - so that shouldn't be an issue. Aside from that, then it's just finding regions in the Golden RAM that don't interfere with those programs that are being loaded. There are a few small set of addresses in the zeropage that could be used, or maybe use a different RAM BANK.


Another note: you can get "more time" by changing the increment time on the VIA#2. I found that a VIA count of $7B7B equated to about 1 second of Jiffies. You could double that to $F6F6, so that each increment of MEM[$0404] takes 2 seconds instead of 1 second. That would then mean $FF in mem $0404 would equate to about 8.5 minutes, so you can give up to that much time between resets (within a single byte).

I've found that it's quite doable to store machine code in a Basic array. Just dim the array big enough to hold your ML routine at the beginning of the program (so BASIC doesn't move it around). It doesn't even matter what Data type (though INT is the easiest math to figure array size) .. Just get the address of the array with POINTER(MYVAR(0)). Then load your Machine code there. As long as your code doesn't do anything else with the array variable then it will stay there just fine.

[voidstar]

Hmm, that could help for the littler ISR-loader - but that loader is only needed once and can get blown away once the VIA is initialized and the ISR address is inserted.

It's the actual ISR itself that needs to persist even after someone has done a NEW (and a few bytes of memory that it uses).

[ahenry3068]

Hmm, that could help for the littler ISR-loader - but that loader is only needed once and can get blown away once the VIA is initialized and the ISR address is inserted.

It's the actual ISR itself that needs to persist even after someone has done a NEW (and a few bytes of memory that it uses).

Well if it needs to live past your program then the array method won't quite work .. You could do it like ZSMKIT is setup. Lower MEMTOP by however much you need to fit your ISR and then put it there just above BASIC Ram.

[voidstar]

So, the concept works (attached is an example of a simple 'program selector" that could go into the root AUTOBOOT.X16)

Before loading the selected program, POKE into the address reserved for how many seconds you want to allow that program to run before the RESET is issued.

It works with nearly all of ahenry3068 BASIC programs - except those that make use of ZSMKIT. Not a fault of the ZSMKIT itself - I tried moving my ISR "blob" to a few different addresses. In the attached example here, I'm using "the other end" of Golden RAM (addresses between $07A0 and $07FF) for both the ISR code and its data.

So some interesting results:

Works well for
- monomania
- mystify2.xc2 (the earlier one with no inputs at startup)
- matrix.prg (of prog8)
- globe3 (yea with r47)
- slideshow (but I have to disable use of zsmkit in the INI)
- chess.prg

Sort of works for:
- Sonic demo (the audio sounds ok, but a bit of the background is messed up, and seems you can feel it when the ISR hits)
- x16-tribute (it loads and runs fine, even with 512KB RAM only, but it doesn't actually reset on the timer)
- butterfly VERA FX (same as above: it loads and runs, but doesn't honor the reset timer)
- KEFRENBARS.PRG (it loads and actually does run, but visually looks corrupted)

Won't load at all:
- Kg3D (just a bit of the intro screen)
- WHEEL (locks up early)
- MANDELO.PRG (locks up early, not sure why)

That's all "as expected" - the more intense ML programs just need the address space. OR, they aren't nicely inserting into the ISR vector and are just overriding it entirely?

So it's hit or miss if the program loaded will need the ~30 bytes in the address space that this ISR needs. The concept is working, the 6 examples above - one of those is randomly selected on startup, and plays for the configured amount of time (20-120 seconds) then the resets and picks different one. But it's not as general-purpose as I had hoped.


This is a trial using just "self running" programs that I could find. It may work with other interactive software - in those cases, it could be an approach to limit Play Time intentionally (like for competition?). It would slow down the ISR, but something like to issue a BEEP in the last few seconds of the reset counterdown could alert users.

[ahenry3068]

KefrenBARS,
The color wheel

and those others all use Raster interrupt tricks to do their magic. So it's almost certain that your ISR is the issue with those programs.