Here is what happens when the electrons begin to flow in the Anvil-6502 system...
1) The FPGA boots and begins a 2 second delay... it counts to 80,000,000!
2) During this delay, the FPGA is holding the 6502 in reset, and off the bus.
3) By this time, the FPGA id done counting, the AVR has started up, and is waiting in a loop.
4) The FPGA now asks the AVR to reach out to external storage and send 64K of data (The OS).
5) THE FPGA now streams the BMOS data into the OS segment in the SRAM.
6) Since the OS is a 64k binary image, this puts all zeros in the Zero Page memory.
7) Once the OS data is transfered, the FPGA puts the 6502 through a reset sequence.
8) During this reset sequence, the FPGA hands out the reset vectors (location 768 in this case).
9) The FPGA then unresets the 6502 and sand boxes it to it's own 64K OS memory segment.
10) The 6502 BMOS now checks ZP location 255. If it is zero, it writes 255, then continues.
11) If the 6502 reads the value of 255, it knows it just came back from a bank swap.
So in my system, there can be no random value in the 6502 segment.
During an "Assemble and Run", the program is executed in its own sand boxed 64K segment.
So this OS segment is fully protected from any tom foolery by the executing program.
If you are into FPGA design, then you may ask... how does the FPGA get its reset values?
Well, here is a bit of info that many experts may argue... "Initial Begin" DOES synthesize for real.
At least in a Xilinx Spartan or better it does. So the FPGA is at a know state after power up.
I even initialize my built in IDE fonts and VGA palette in the Initial Block.
Here is my memory map inside the 4MB of SRAM...
Code: Select all
----------------------------------------------------------------------------------------------
NAME BASE SRAM ADR BMOS + 305,536 PROG + 371,072
----------------------------------------------------------------------------------------------
SRAM_VIDA 0,000,000 NA NA
SRAM_VIDB 0,120,000 NA NA
SRAM_BMOS 0,240,000 NA NA
SRAM_ASEM 0,305,536 0,000,000 NA
SRAM_PROG 0,371,072 0,065,536 0,000,000
SRAM_DATA 0,436,608 0,131,072 0,065,536
SRAM_LAST 4,194,303 3,888,768 3,823,231
The second two columns show how BMOS and the Assembled Program see the segments differently.
Notice how BMOS cannot write to the VGA Buffer frame memory or its own memory segment.
The Assembled Program can however, read and write its own segment.
This is how I intend to "LeapFrog" code if I need a program larger than 64K running!
Here is a description of each segment in the SRAM...
Code: Select all
SRAM_VIDA VGA Buffer A
SRAM_VIDB VGA Buffer B
SRAM_BMOS 6502 OS Segment
SRAM_ASEM Assembler Scratch Memory for Labels and Equas
SRAM_PROG Assembled code ends up here
SRAM_DATA Data for Sprites, Images, Sounds, Code, etc
SRAM_LAST Last location in SRAM
Cheers,
Radical Brad
That's the nice thing about my OS being dumped into SRAM on startup... no random memory locations in the OS or EXE segment.
On first power up, every memory location below 768 is guaranteed to be zero.
Well, that would be true once the OS kernel has been loaded. What about prior to the load? The "magic" (flag) location could conceivably be loaded with the flag value at power-on.
