Depending on how your RAM is implemented, the value 255 may not be the most bullet-proof choice to distinguish an initialized location from an uninitialized location, especially if its address is also 255 ... just sayin' ...

Mike B.

Indeed, the SRAM could contain 255 on power up, since its contents are random.

During startup though, the entire 64K program memory is loaded with a binary image containing the OS (BMOS).
All zero page locations are set to zero at this time.

If that was not done, then for sure there may be some chance of the value of 255 already being there.

My Power On Check is very basic at this point, and only sets the cursor position and IDE scroll line...



In the above code, 512 is the location in SRAM where my source code lives (512 * 128) = 65536
I multiply by 128 since each line of code in SRAM occupies a fixed 128 bytes (65 characters and 64 color values).

Thanks for your comments, I always like a sanity check... much of this is new to me!
Tonight was a great night of bug swatting as well. I have many of the problems crossed off my list now.

Brad

The Commodore 128 had cold start/warm start differentiation, which allowed a programmer to set up a warm start vector that would be taken when the reset button was pushed. As that machine used DRAM, there was a 50-50 chance that any given location would power up with $00 or $FF. Hence the differentiation character string, CBM, which was at $01FFF5-$01FFF7, would not be present, and the warm reset vector would not be taken. After a full reset had been done the string was written, telling the kernel that the warm restart vector was valid.

You could likely follow this pattern, but not with a single byte as you are describing, as the flag location would have a 1 in 256 chance of having the flag value following power-on. So you need a more reliable way to tell that a cold reset has been done.

In examining the SRAM in my POC units right after power-on, I've noted that the overall contents are very randomized and that no three consecutive bytes have a pattern in which bit seven is not set in at least one of the bytes. Based upon that observation, I'd write a three character differentiation string from the ASCII upper case range into a location in absolute memory after your reset handler has tested and cleared zero page and the stack. You could then conduct a non-destructive test of absolute memory from $0200 upwards, which will of course preserve your differentiation string. Later on during a subsequent reset, you can examine for the differentiation string to see if the memory test can be skipped.

This is something I will be doing in POC V2.1's reset handler so reset can be called without having to go through the full memory test (which I estimate will take around 18 seconds to complete).

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

Acorn's BBC micro has a separate power on reset to one of the VIAs, so the state of that chip, as to whether or not it is configured, is used subsequently to determine whether a cold start is needed. (Every other chip's reset line is connected to the power on reset and also to the physical reset button.)

I think it's a clever choice: you need a byte of state, but it doesn't have to be a byte in RAM, and putting it in a chip which you have anyway, and which has a reset line, is a neat solution.

I was simply considering have two buttons to handle warm/cold reset. Was debating whether each one would do one or the other, or whether using one as a "shift" key would be better. Haven't put much more thought in to it than that. Seems it would be nice to not have to cycle power.

Yes, I hate power-cycling - it seems like tempting fate.

Interesting you mention that. In the NXP 28L92 DUART, there is a register (register $0C) that is read/write, but has no effect on device operation when the DUART is wired to operate in Intel mode (recommended with 65xx hardware). NXP describes this register as follows:

7.3.13 Interrupt Vector Register (IVR; 68xxx mode) or General Purpose register
(GP; 80xxx mode)

This register stores the Interrupt Vector. It is initialized to 0x0F on hardware reset and is
usually changed from this value during initialization of the SC28L92. The contents of this
register will be placed on the data bus when IACKN is asserted LOW or a read of address
0xC is performed.

When not operating in the 68xxx mode, this register may be used as a general purpose
one byte storage register. A convenient use could be to store a shadow of the contents of
another SC28L92 register (IMR, for example).

Since this register is initialized to a known value following a hard reset it could be used as a flag location to indicate that a cold reset has been performed by writing something other than $0F into it. I may do that in POC V2.1, rather than use a string in RAM. Since V2.1 has two 28L92's I could write a distinct bit pattern into each one just to be redundant about it.

Unfortunately, the 28L91 doesn't have this register, but the 26C92 does have it.

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

Yes, sounds like a good plan!

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.
BMOS then writes 255 to the magic location just to remind itself that it already exists.
Kind of like traveling back in time without being able to bring your memory, just a note written on a match box.

Brad

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.

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

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...



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...



Cheers,
Radical Brad

Oh, yeah... the SRAM_ASEM Segment is new.
This 64K segment will allow the assembler to store labels and values during assemble.
I dropped the "infinite pass" plan, and decided to use 3 or 4 passes max.
Might as well. It's not like 64K carves a huge chunk out of the 4MB of SRAM.

Brad

I have decided on the first real program that will be assembled by A65 when the IDE is working.
For my first assembler test, I am going to make an updated version of MicroChess by Peter Jennings.

https://en.wikipedia.org/wiki/Microchess

My additions will be a 3D ray traced board and some ambient background music.
Should be a fun coding project, and good test for my assembler.

I am still optimizing the FPGA code, and getting a few more commands added.
Work on the final IDE and BMASM (Bare Metal Assembler) will commence very soon.

Radical Brad

Took a few minutes to throw together a concept case in SolidWorks...



This is far from complete, but shows the general idea of a windowed 6502.
The open base allows the box to sit over a monitor base, so it can live in front of the keyboard.



I will also be adding an SD slot and multi-color status LED on the front of the case.
Overall size will be based on the smallest PCB I can make.

Cheers,
Radical Brad

Rainy day today. Messing around with booting the OS from an SD Card.

Wow... SD is finicky, and there are holy wars on what is the correct way to talk to them in SPI mode!
10 million "experts"... 10 million opinions!

I managed to code up a basic SPI mode interface in AVR assembly, and it worked the fist time on my 2GB Micro SD Card.
To test this, I converted a few songs to RAW using Audacity, then dumped them on the card using HxD at sector 0.
My AVR code initialized the card, and then started reading bytyes, sending them to a PWM pin connected to an audio amp.
As expected, I head the music on my speaker, streamed directly form the card.

From here things went downhill.

Of the 10 SD cards I tried, only 2 worked, and those 2 were old 2GB types.
Seems there are different sequences for newer SD, and some don't even do SPI anymore.
3 hours of reading arguments on forums, and I think I will just drop SD support.
Seems that one would need a special IC do do it correctly now.
In that case, I may as well just drop down a Vincullum IC and support USB sticks!

I am now looking for some type of mass storage IC that has a micro-controller friendly interface.
Perhaps there are gigabyte SPI flash memories available? Digikey will tell me soon enough.

My "new" plan is to drop down a high capacity serial flash and call it an "SSD".
My storage memory does not need to be removable since I can link to the PC over USB if I need to.
I was never intending to make my SD card PC compatible anyhow.

For now, I will continue testing with my 2GB SD Card until I have a permanent solution.

Later,
Radical Brad