Rob, you are so productive in you microprocessor designs! I don't know how you can keep multiple ones going.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

A lot of block copying, practice, and learning from prior mistakes (experience).

This problem has me stumped good. The system hangs only if an attempt is made to invoke EnhBASIC, otherwise the system runs smoothly. I traced a problem to the system’s OutChar() routine which is run when EnhBASIC tries to display the startup message.
In the OutChar routine below, storing the acc to the LEDs shows an incorrect value and the system hangs.

However, storing acc to LEDs one instruction sooner displays the correct value and the system still hangs.

It looks to me like the LDX instruction might have some sort of side-effect. If .X were to be corrupted somehow then the following indexed indirect jump wouldn’t work properly. But the problem is only present when EnhBASIC is invoked. I can’t see any errors in the Verilog code. LDX # is pretty straightforward.

I had to slow down access to the BASIC rom to get rid of the bit error. (ROMs are begin accessed at only an 8MHz rate with wait states inserted). The core is using a cache however and runs at 33MHz.

_________________
http://www.finitron.ca

I do appreciate seeing your progress, including the obstacles you find - it's always interesting and often instructive! You have the boldness to proceed, break, and then fix.

Wouldn't it be saver to push X,Y first then do REP?

Yes, I switched it around.

Progress. EnhBASIC now outputs the string “h@@@@@@@@@@@@?” instead of the memory size prompt. Printing individual characters from BASIC works as the CR,LF and ? characters come out correctly. It’s just the printing of strings that is screwy. The “ahah” moment was realizing that BASIC is running in an eight bit virtual machine, and it was calling a routine that expected to be running in a 16 bit virtual machine. The eight bit VM doesn’t know about the ‘M’ and ‘X’ bits of the status register. Using context switching call and return instructions (JCR, RTC) fixed that issue. JCR works like JSR except that it switches to the VM of the called routine. It has an extra operand which is the context number to switch to. RTC works like RTS restoring the original context. What gets saved on the stack is the previous context number instead of the return address.
Now to get keyboard input to work, getting a keyboard character hangs the machine when done from someplace other than the BIOS.

_________________
http://www.finitron.ca

Input routine: most likely that there is a similar mismatch between VM8 <=> VM16 during character fetching. Sometimes these 'M' and 'X' flags causes more frustration than delight.

I fixed the input routine the same time as the output routine. You are likely correct however, it's likely still a bug transitioning between VM's.

The message string display from BASIC is now corrected. It was a problem in the BASIC with a zero page pointer, due to I think my playing at one point trying to have strings displayed from anywhere in a 32 bit memory space.

Getting characters in Supermon is working but that's going between VM16 <=> VM16, however it disables interrupts somehow. Interrupts are restored upon exiting Supermon.

_________________
http://www.finitron.ca

Not knowing the details I can only guess what may happen.

Assuming you did already check the transitions from/to VM8/16 I would check whether PHP, PLP, REP, and SEP really do what they ought to do. Perhaps either during save/load to/from stack or the P register itself may get corrupted. As you can probably stop your machine at any state it should take no much time to verify whats going on.

Their may also a silly omission during any interrupt service routine that is in use during your tests.

Good luck!


edit(1): This is obviously nonsense as you stated its VM16 <=> VM16. Sorry. Nevertheless there might something like 8/16 bit accumulator size. Indexregister size as well, although it's rare to use 8 bit size index registers. I hope it's not the D flag for some weird circumstances

Which version of Supermon are you using?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Supermon832 1.0.0 (Supermon816 1.0.0 with a small number of hacks).
I modified the character get, put subroutine calls so that they could switch to the BIOS context. As follows (jsr replace with jcr):

Just looking at it now I realize I could probably have the assembler recognize a context call when there's an extra parameter to jsr. It'd reduce the number of mnemonics.
I also modified the register dump to display additional registers, 32 bit contents.
I'm using a combination of my own monitor and Supermon to do memory dumps, disassemble code. It needs a large number of modifications yet. I have to add new instructions and modify the flimflag to support 32 bits, and ...

_________________
http://www.finitron.ca

What happens when the CPU has to do a JCR context call? Elsewhere you said A, X, Y, and flags are not saved.

JCR works like a subroutine call except:
- the entire state of the current context is saved in it's context register
- this includes the (CS,DS,SS,PB,PC,SP,A,X,Y,flags,DB,DP)
- A,X,Y, flags are effectively not saved since they will be overwritten when the routine executes
- the segment registers (CS,DS,SS) are loaded from the target context including looking up descriptor info
- the program counter is loaded with the address in the instruction
- the SP, DP, DB are loaded from the target context
- A,X,Y, flags remain the same as from the calling context (to allow parameter passing)
- the mode bits are set to the target's mode (816/832)
- the calling context number is saved on the target's stack

(JCL similar to JCR can also copy stack parameters between stacks of the caller and called contexts).

_________________
http://www.finitron.ca

I don't see anything that might disturb the flags. So probably the issue of disable interrupts may have other reasons but context switching.

EhBASIC is now running in a VM on the FT832 test system ! The first test program displaying the numbers from 1 to 10 works.


The BASIC is running the address range $10000 to $20000 (bank1) but it's faked out to think it's running in bank zero. It's all done with the magic of segment registers (invisible to EhBASIC).

One modification to the BASIC was to have the BASIC character fetch routine executed directly from ROM rather than from a copy in zero page. This saves some valuable zero page storage space. The problem with executing the routine from zero page is that it’s self-modifying code and so it requires a cache line invalidate to occur after the pointer address is updated. Adding this extra code would be present in zero page consuming valuable space and it also isn’t any faster than running the routine from ROM. All that was required for mods was to use an indirect fetch rather than a direct one, and change the LAB_GBYT, LAB_IGBY labels to point to the ROM code.

Another fix to 2.22 code was in the CPY under LAB_2DB6. The CPY should be comparing the high byte.

_________________
http://www.finitron.ca

FT832 interrupts are not working correctly. Somehow the interrupt mask flag is being set causing them to be ignored. But it only happens when switching between certain tasks. If task#0 (the BIOS monitor) is the running task then interrupts are always enabled and work properly. However if any other task is the running task (task #7 BASIC, task#8 Supermon, task#252 BIOS calls) then interrupts become masked. All of these tasks have their interrupt mask bit cleared at startup and never set it (There’s no SEI instruction). In BASIC if a CLI instruction is placed in the V_INPT or V_OUTP routine then the system hangs. However, interrupts can be enabled by performing an ON IRQ command in BASIC which does a CLI. So by including an IRQ handler in BASIC interrupts are pseudo working.
The following EhBASIC program shows interrupts happening by displaying an “I” on screen when an interrupt occurs.

This is great if a program is running, but when back in direct mode interrupts aren’t enabled.
It’s strange because there’s only a handful of places in the Verilog code where the interrupt mask flag is set. These being from the task context register when the task is switched, from an RTI or PLP instruction when the status register is loaded from the stack, or by the SEI instruction, or when an interrupts occurs.
And, it was working at one point, and I’ve checked the code very carefully, and done some experimentation to try and verify the code.
One thing which may be causing a problem is that there is a three cycle delay before a CLI instruction becomes active. This is to prevent the core from hanging on a single instruction if interrupt overrun occurs.

_________________
http://www.finitron.ca