The question's construction is an attempt at making a memory-hard function. This is more difficult than it seems, and the construction proposed has several flaws:
An adversary performing a password dictionary attack needs only a little over half a megabyte of memory per concurrently running process. This is because adversaries are not bound to "put 31,250 copies of the first hash to fill the array"; they can take advantage of the fact that the last copy will not get changed (become different from the but last) until the last of the passes in the process. For large $n$, this allows running nearly $2n$ processes interleaved (that is, with their stages of progress evenly distributed at a given time) using only $n$ megabytes of memory.
Independently, an adversary can save about 1/16 of the hashing effort by noticing that typically, in the step reading "hash the entire array salted with the hash 8 times", the beginning of what's hashed (on average, 0.5 MB out of 8 MB) is identical to what it was in the previous step.
It is hard to rule out that an adversary using an ASIC (or perhaps FPGA) for a password dictionary attack can organize things so that some of the (half-)megabyte of memory needed per process can be in relatively slow/cheap memory such as off-die DRAM, and only very little in fast on-die static RAM or flip-flops.
In a SHA-256 internal block hash, a sizable part of the computational effort goes into the so-called expansion of the 64-byte message block. Because most of the data hashed by the overall algorithm is hashed many times and with the same alignment to 64-byte blocks, it is theoretically possible to cache expanded message blocks and save most of that expansion work. That's quite worthwhile when repeatedly hashing the same data block, which happens nearly half of the time due to flaw 1.
Flaw 1 can be fixed by adding an outer loop performed many times, so that during all except the first of these loops the 32-byte blocks of the memory array have different and arbitrary-like content. However, that exacerbates the risk that flaw 3 becomes serious, and/or that memory even slower/cheaper than DRAM becomes usable.
Flaw 2 can be fixed by incrementing the first word of the first block before starting each hash.
Flaw 3 is the theoretically hardest to repel. Using data-dependent addresses might help, but tends to slow down legitimate use too, and may introduce undesirable side channel leakage.
Flaw 4 becomes merely theoretical after flaw 1 has been fixed: exploiting it requires a lot of extra memory, so that's most likely not worthwhile in practice.
Memory hard functions are like most crypto: anyone, from the most clueless amateur to the best cryptographer, can create one they can't break (Bruce Schneier). Thus the prudent thing is to use the ones that passed scrutiny; or if the objective is learning, study that. The current recognized standard is Argon2. It's worth reading about Balloon, too.
