autostart and ramdisk

[john]

I am trying to enter a FORTH autostart vector that will
set the correct variables for a ramdisk. This is on an
x0020 hc11 board with 8k of NVRAM at 8000.

I define the two following words:

: UR 2000 50 ! 17FC 4E ! 7C00 72 ! EMPTY-BUFFERS
." RAMDISK " ;
EEWORD
: UR2 UR 1 LOAD ABORT ;
EEWORD

This code works fine when run by hand after a powerup or reset.
It works fine if I do B63F EXECUTE after a powerup.
It works fine if I have an autostart vector at, say
1000h and do a COLD.
It stops after printing "RAMDISK" if I create an autostart
vector and put it at B600 and turn the power off and back
on.

I am obviously missing some setting that needs to be made
during initialization. What is it?

[nmitech]

Do you have a 32Kbyte Sram on U2 socket, and jumpers set accordingly for 32K device? I just currious because you have a 8K NVRam at 8000 which is not standard for jumper setting of a 8K device and a 32k device mixed.

[john]

Originally posted by nmitech
Do you have a 32Kbyte Sram on U2 socket, and jumpers set accordingly for 32K device? I just currious because you have a 8K NVRam at 8000 which is not standard for jumper setting of a 8K device and a 32k device mixed.


I have tried this with several configurations. I have tried
this with 32k in U2 and the NVRAM at 8000 in U4 (32k
setting), and with 8K in U2 and NVRAM at 8000 in U3 (16k
setting), and 8k RAM in U2 with NVRAM at 8000 in U3 (8k
setting). The last setting is the intended target, since
it matches the memory size I am actually using.

What setting am I missing to get this to work?

[nmitech]

John,

What data do you expect after RAMDISK? All i got is about 8 garble characters after RAMDISK when i tried to run those two words. It looked the same if i run autostart in the internal eeprom or external ram. I just added the following 2 lines to put an autostart pattern in the internal eeprom.

HEX 1F0 AUTOSTART UR2
1F0 B600 4 EEMOVE

[john]

nmitech:

> What data do you expect after RAMDISK?

If I execute the word UR, I expect an OK prompt and the
ability to access the ramdisk. If I execute the word UR2
I expect the compiler to start loading the code found on
screen 1 of the ramdisk, after configuring same. That is
what happens when I do a non-power-off reset.

I do not expect the system to lock up solid, which is
what it does, if I try running these words from an eeprom
autostart at power-up.

>HEX 1F0 AUTOSTART UR2
>1F0 B600 4 EEMOVE

I stopped doing this when it became clear that the code
I have does not accomplish from a power-off start what
it accomplishes from a power-on restart.

Perhaps you get a different result because you do not
have NVRAM as ramdisk, and there is nothing to load?

As a side question, I am at a loss to understand why I need
an ABORT at the end of UR2 -- but if I leave it off, the
result is repeated execution of the autostart word at
the next reset.

This perhaps points to the problem: is it possible that
FORTH is not bothering to set up the stack pointers prior
to executing the autostart word? That for whatever reason
the stack points to invalid opcodes and I am getting
repeated invalid opcode interrupts?

[nmitech]

HEX

: UR 2000 50 ! 17FC 4E ! 7C00 72 ! EMPTY-BUFFERS
." RAMDISK " ;
EEWORD

: UR2 UR 1 LOAD ABORT ;
EEWORD

: RESTORE-DP B700 6 6A CMOVE ;
EEWORD

: MAIN
RESTORE-DP
UR2
;
EEWORD

6 B700 6A EEMOVE

' MAIN CFA
DUP >< B602 EEC!
B603 EEC!
A5 B600 EEC!
5A B601 EEC!

--------------

Couple more things you may take it in consideration,

7C00 72 !
Expecting your base address of the ram disk is 7C00

NVRam timing problem. Some parts may have slower timing to protect its data on power up. So if you did not get the correct data from your NVRam, you may add a short delay loop at the first thing in your program. The delay purpose is provided enough time for the NVRam power to stablize before you cen get the correct data out of it.

For a quick fix on the locking up problem, you need to restore the user area as indicated on the bold text above.

Also, You need ABORT if you don't want your program continous run in a loop.

[john]

>: RESTORE-DP B700 6 6A CMOVE ;
>EEWORD

Actually, I spent a few minutes with the docs and doing
things like dumping low memory after and during autostart,
and came up with a much shorter list of variables to set.
CONTEXT, CURRENT, and STATE (6A for 6 bytes) seem to have
solved the problem. Most of the rest are already set
properly by the initialization prior to autostart.

I'm also hesitant to use extra EEPROM since I have interrupt
handlers that need to go there, too.

>7C00 72 !
>Expecting your base address of the ram disk is 7C00

Yes, this puts screen 1 at 8000. Screen 0 is limited in
use, since you cannot load it -- 0 is a flag in BLK which
says input is coming from keyboard. At least, when I tried
loading 0 it didn't go very well at all.

>Also, You need ABORT if you don't want your >program continous run in a loop.

Isn't that the purpose of the ; at the end of the
definition? Doesn't that return control to the interpreter,
or in an autostart case, to the code that found the
autostart word and started its interpretation? Why
does it loop?

[nmitech]

That's correct! ABORT will return control to the interpreter.

Isn't that the purpose of the ; at the end of the
definition?

If it terminates with a ";" for high level words or a JMP NEXT for code definitions, the system again returns control to the beginning of the third autostart attempt. In this case, the same word will be found and autostarted again and again.

Maybe you should use the second autostart attempt for a temporary autostart pattern, $A44A if you don't want to use the ABORT word.

The AUTOSTARTING appnote can be downloaded here,
http://www.newmicros.com/store/product_manual/forth/autostarting.pdf