Thanks for clarifying.
I figured out what was going on now. I did a new routine to use the chip erase feature of the flash, that is insanely fast by the way! Then when programming the bank, it booted from flash just fine. So it was the erase routine which was at fault. The first problem was that because it used high bits only for sector erasing (A18-A12) I had actually counted from A0 12 times, which left me on bit 11 not bit 12
So basically it was only erasing half the flash. I then later realised that I also needed to double the address as well.
So my first erase routine was technically only erasing quarter of the flash bank, after I fixed the A12 issue, it was actually erasing half of the flash, now I fixed the bit rotations, it now erases the full bank properly. I have booted successfully TOS104 & TOS206. Icky also confirmed its working and hes also tried EMUTOS. so basically we now have under control RTC & FLASH
At the moment each flash bank selected on board by a jumper link. This will be controlled via a software register, so flash banks can be selected by software. The spanner in the works in all this is there is a separate jumper which selects either motherboard ROMs, or flash ROM to boot from. This jumper also doubles up as a write enable for the flash...
The issue is that the motherboard ROMs have to be booted from because flash is not programmed yet, and the NVRAM registers have not been set up yet either.So if the ROM jumper was done in the register, machine would likely try and boot from flash which has not been programmed yet, so the machine would not boot up. So the only way to force the machine to use on-board ROM is, is via a jumper link or a switch. Basically whenever the flash is programmed, it would have to be booted off the motherboard ROMs.
Technically it should be possible to boot from one flash bank, and programme another flash bank, but then it creates more problems that if someone tried to program the same flash bank as they booted from, it will trash the OS and likely crash. I think monster gets around this by disabling interrupts. There is of course possible issues where someone managed to corrupt the NVRAM, it would again prevent the machine from booting up. Overall it just seems to get over complicated and messy to do something which should be simple.
There is of course a slight advantage in having a switch as well, as you could actually still use the motherboard ROM's as well. The flash can hold 4 TOS versions, so with the MB ROM's, its actually 5 ROM's which can actually be selected. but I do think having a physical switch to force booting from motherboard ROMs is probably a good idea anyway. Technically it could be possible to use a DUALTOS board and control that from the PLD for 6 TOS versions. But I'm don't really see the point in having more than 4 TOS versions anyway.
So the pencilled in idea is basically that the motherboard ROMs will just be used to Initially boot from, and set up the flash and RTC. Once it has been set up, the jumper is moved and it disables the motherboard ROM, and boots from the flash instead. Of course if at any point something does get "bricked" user can always select the motherboard ROM's and re-initialise the RTC & Flash.
So in terms of how this will likely work.. Is that there will be a shadow register in the PLD, which will mirror the last address in the NVRAM. So when the register is set up ( written to ) it will programme the register in the NVRAM, and also program the shadow register in the PLD. The PLD will then control the four flash banks. So each flash bank will be selectable via software. When a read happens to that register, it will of course be read from the NVRAM.
The problem with all this is that the register in the NVRAM needs to be read when the machine is powered up, as it needs to select the correct flash bank. I have been giving this a lot of thought today.. Basically the PLD will have some " bit bang logic" which will access the register in the NVRAM on boot up. Because the RTC bus is multiplexed, we actually have to select the address first, and then we get the data.. Driving the databus isn't so simple from a PLD. but I thought the address it will have from boot up is going to be $FF anyway. so it just makes life a lot easier to use that address in the NVRAM. The NVRAM only actually goes up to $7F (7 bits not 8) but this isn't a problem anyway.
So the boot sequence would actually be that the machine comes out of reset as normal, but the reset signal is rooted via the PLD. The PLD will then toggle the CS lines etc on the RTC and force the CPU to keep in reset while all this happens. The first cycle will latch the data bus which will be of course $FF anyway, so the second cycle will have the RTC dump the data from register $7F onto the databus. the PLD will then latch the state into its internal registers, which will then of course translate into selecting one of the flash banks to boot from. Once that has happened, the PLD will release reset to the CPU, and the machine should boot as normal.
So basically what happens is, whichever flash bank you select, it'll save it in the NVRAM, and it would automatically select your saved bank
when the machine is booted up. Incidentally, this type of "system" will ultimately be used in the boosters.. Where the booster on/off will also be software controlled in the future.. But that is probably a long way off yet.
Meanwhile, Icky is making up a couple more of the current boards, as we need testers, and software programmers to finish off some software things. At some point we will start updating the design to include what is mentioned above in the next version.