I've done an initial port of EhBasic over to my C02 Pocket SBC, but I've had to change much of the Page zero memory locations. My BIOS/Monitor uses from $B0-$FF and I don't want those areas being clobbered by EhBasic. While I can claim to have EhBasic running fairly well, meaning I've been running a small Basic program (Mike Barry posted initially) for almost 300K iterations flawlessly. I've also been able to run Bill O's fractal Basic program endlessly for days without issue.

However, doing a Ctrl-C usually breaks the program execution but rarely (if ever) can a RUN make it go again. In general I have to do a Cold start of EhBasic and reload the program. Doing a Warm start of EhBasic is useless, as I can LIST an existing program, but nothing more... it crashes if I attempt to RUN it. Worse still, I have found that doing a Cold start of Basic, in some cases, simply doesn't work... I either have to cold start the SBC itself or clear out all of Page zero (sans my BIOS/Monitor usage area) before starting EhBasic. This leads me to think that EhBasic is using more locations than claimed in the Page zero definitions. I've also noticed that the Stack page gets a lot of locations written to it, and in a couple cases, I had to zero those locations before EhBasic would successfully Cold start.

Is there a definitive list of ALL Page zero and Stack page locations that EhBasic fiddles about with? I really don't want to spend a ton of time going through the entire source code looking for all possible memory usage

_________________
Regards, KM
https://github.com/floobydust

For page 0 locations you may want to take a look at viewtopic.php?f=5&t=5036
There is no use of the stack below the stack pointer ($100-(SP)). However, there is some hardcoded stack resets and EhBASIC may destroy anything left on the stack by the monitor. Just look for TXS in basic.asm.

If you can't find the leak beween your monitor and EhBASIC you should consider saving and restoring zero-page and stack including stack pointer when switching from one to the other.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Thanks Klaus,

I've looked at that list extensively (thanks for posting that earlier). Oddly, it's quite rare that my BIOS/Monitor gets corrupted as I can generally recover from an EhBasic crash either by sending a Break from the terminal program or using the NMI Panic switch.

It seems odd that EhBasic doesn't completely initialize it's own variables from a Cold Start, which makes me think that it's using some other locations, either in Page zero or the Stack page that aren't initialized by a Cold Start, yet can cause it to not work. I'm also wondering what the Warm Start option is supposed to do... as at best I can only LIST what program is there but nothing else.

_________________
Regards, KM
https://github.com/floobydust

A cold start should initialize all the required zero page locations and vectors if entered through min-mon.asm. It should never be necessary to zero out any of the zero page locations or the stack. If it can't initialize itself properly it usually means that EhBASIC itself is corrupted (do you load to RAM?) or some interrupt routine is trashing a location in zero page or stack.

A warm start does not initialize the program pointers (as you can do a LIST) but you should also be able to RUN a program. If you can't RUN see above.

How do you start or restart EhBASIC? Do you use RES_vec?

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Interesting topic. I have had some issues using the space from $DE to $EE, which is listed as 'unused' just below the declaration of IrqBase:



So it seems there is some contradictory information given in the commenting of the source. It may be a worthwhile exercise to manually determine the actual usage, and possibly even defragment the page 0 free space. A project for the next Canadian winter - maybe???

_________________
Bill

It is obvious that $DE - $E1 is used by the interrupt handlers and Lee just forgot to remove the "unused" comments. $E2 up to $EE is actually unused. There is no magic access in EhBASIC to any location in zeropage RAM that is not declared!

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I'm not saying they are undeclared, or that Lee did anything nasty, just that the declarations are a little contradictory. If what you say is true, then it should be fairly easy to defragment the unused space and put it either at the top or the bottom of the page to make it more useful. As I go through the whole list (both your listing and the original code) there 'seems' to be a few singe or double spaces in there too along with the two large sections. It may or may not be appropriate to eliminate those spaces or to adjust them for future consideration.

_________________
Bill

So far, it would appear that EhBasic is not clobbering any of the page zero space I use for my Monitor/BIOS, which is $B0 - $FF. I'm not using any of the IRQ/NMI code within EhBasic (that I know of) but I've also moved those declarations as well to lower memory locations.

My main concern is that EhBasic is dependent on some undeclared locations, as a Cold start may not actually work, if some page zero locations have some bits set that EhBasic doesn't like. While I can take the approach of zeroing out the page zero space from $00 - $AF before doing a Cold start, it would be nice to figure out what's causing EhBasic to not run properly after a Cold start in some cases.

Still a work in progress for me to get it fully integrated into my little SBC...

_________________
Regards, KM
https://github.com/floobydust

Could you please attach a listing of EhBASIC with your changes? If you don't use min-mon.asm you should also include the equivalent part of your own monitor.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Well the hot tip if you think that EHBasic is stomping on places it shouldn't be is to stick it in a simulator, and trap those addresses to see what fires from where.

Well, I will have some time to work on this code further this week... brought a couple Pocket SBC boards with me (northern house) and a couple extra EEPROMs with my BIOS/Monitor code.

My BIOS supports an interrupt service routine to service the UART, which is IRQ driven for transmit and receive, plus a 100ms jiffy clock based on the timer. It also handles a "send break" to the UART via interrupt. As a result, I'm guessing that EhBasic can likely hose up the stack. Is there any easy way to prevent this?

I've added some code to the Monitor to launch EhBasic, but in general I call LAB_COLD to init EhBasic. Currently I'm not setting up the IRQ/NMI vectors for EhBasic... but I'm also not using the IRQ/NMI functions. Do you have to set them up for some functioning code if the functions are never used in a program??

I'm making some changes to the code tonight and will post a listing file once I get everything working. Thanks again for the great support on this... I would like to get EhBasic fully functional on my Pocket SBC. I also want to have an EhBasic command to exit back to the Monitor as well, but one thing at a time.

_________________
Regards, KM
https://github.com/floobydust

EhBASIC will trash any bytes left on the stack by the monitor. So you cannot use RTS from EhBASIC to exit back to your monitor. You should adjust EhBASIC's stack floor protection at LAB_1212. Just add the maximum number of bytes you expect interrupts to occupy on the stack. However, you would need a lot of nested FOR, GOSUB or DO statements before the stack is in danger of wrapping arround.
You must make sure that the I/O and load/save vectors are copied before jumping to LAB_COLD. NmiBase and IrqBase are initialized with $00 by LAB_COLD and must stay that way if you are not using interrupts in EhBASIC. Those two locations cannot be used for other purposes even when you're not using any interrupt related BASIC commands.

You could use CALL <addr.> for now where addr. is your monitor's start address. Just make sure to discard the stack (SP=$FF) in your monitor. After that you should be able to jump to LAB_WARM to get back into EhBASIC.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

It's been a while since I looked at this but,
I wanted this feature as well, so I defined an EXIT keyword which executes the following:

It leaves a return value in the accumulator.
V_EXIT just jumps to code that just jumps directly back to the monitor program. The stack pointer is reset in the monitor program.

_________________
http://www.finitron.ca

Well, some good news... which is nice. I found another EhBasic version 2.23 by J.G.Harston. The Page Zero definitions are better organized, IMHO, for making changes to the locations used, i.e., you make one or two changes instead of multiples. I also placed the BIOS calls for input/output, etc., into the main Basic.asm as well. So I replaced the Page zero definitions, added Klaus' stack floor patch and cleaned up the source quite a bit.

Good news, it appears be stable and working well. Cold start and Warm start work properly, CONT works and I can LIST and RUN an existing program from a Warm start. I've also managed to update the code quite a bit for using the CMOS opcodes and some addressing modes to get the code size down a bit and likely a tad bit quicker in some cases. I can also use the CALL function to use routines in my Monitor code which are also working.

My Monitor simply sets up the Cold or Warm prompt and calls the appropriate address to start EhBasic. As I'm not using the IRQ or NMI functions, I'm not actually calling any routines that are in min_mon.asm. Granted, I haven't done any extensive testing yet, but I am attaching the listing file here. As a side note, I cobbled the startup routine down quite a bit... as in removing the user prompt for memory size and associated routines. I just invoke the memory test and setup the pointers and goto READY.

I do want to add an EXIT function to the code which will invoke the Monitor code... need to look into that (thanks Rob). And of course, thanks Klaus for all of your input and info... great support.

_________________
Regards, KM
https://github.com/floobydust

Do you have a link to that version?

_________________
Bill