Marking the bootloader as dirty and having the cache controller handle it was genius! :)
@CompuSAR8 ай бұрын
THANK YOU! I was _so_ proud of this trick, and it got absolutely zero reaction.
@m1geo8 ай бұрын
@@CompuSAR nah, I was watching like "oh, how's he getting out of this one." and then you pulled this off, and I was like "woah, magic!" 🤣 genuinely excellent! Excited for more! Keep up the series, please! 😍
@vincentvoillot63656 ай бұрын
Very interesting idea, very crafty. An other solution is to read the EEPROM thoughts SPI, it must have at least few MB available to be map as read only.
@CompuSAR6 ай бұрын
@vincentvoillot6365 There's no shortage of space on the flash. Getting it to the CPU is another matter. That would require dedicated hardware that runs counter to what we're trying to do here: minimize the hardware requirements of the design. My solution is 100% free, in that all of the hardware it requires is used anyways.
@vincentvoillot63656 ай бұрын
@@CompuSAR Yes, there would be an hardware overhead, but that much ? After all the SPI interface with the flash is already hardwired. I know i'm late to the party and you have done a really amazing job with the DDR controller. But didn't you cross path with the LiteX framework during your research ?
@PedroAngelini5 ай бұрын
Amazing solution! I'm imagining the cpu waking up, checking it's task list (program) and going "hold on, how the hell did this get to memory before we had power? *Shrugs* Well might as well get processing" and goes on with it's life. Meanwhile the cache has an apron and a broom and is going "how the hell all of this got so dirty so quickly?!"
@CompuSAR5 ай бұрын
My mental picture is almost reverse. We have a the FPGA frantically working to get the house ready for the guests, just so when they arrive to wipe the last strands of sweat, pretend to be bored, and say, "oh, if I'd known you'd come I'd have cleaned up".
@LordDecapo11 ай бұрын
such a consise cache explainer. Gonna use this as my goto link when talking about caches with new people lol.
@AlanCanon2222 Жыл бұрын
Brilliant. I notice the 65C816 has a couple of output lines that can be used to separate cache operations for program data and program instructions. VDA and VPA. I wonder if they were thinking of a way to signal the bus controller to pull program code from an underlying EPROM, yet seamlessly make that address space available as RAM.
@CompuSAR Жыл бұрын
While it can be used this way, I don't know of any implementation that does. Giving the instruction and data buses different values *on the same address* is very rare (though VPB on the W65c02 is designed for, pretty much, precisely this). It's more about having different caches for both. If you're going to have a fast enough (i.e. zero wait) EEPROM, you wouldn't bother putting a cache between it and the CPU. Why would you? It's zero wait state. But if you execute from DRAM, your instruction fetches behave quite differently than data fetches. This means that a single cache will be less effective, with the data and instruction invalidating each other's accesses. Having separate caches for both would make sense. For CompuSAR I did something a little different. The iBus and dBus are completely separate on the RiscV. The dBus goes through an address router that directs it wherever, with the DDR being one option. The iBus *only* goes to the DDR (at the same addresses), but has one more layer of cache. So the dBus goes through a 16KB cache to the DDR, while the iBus goes through a 4KB cache to the same 16KB cache the dBus uses. Without it things worked, but the FPGA would heat to the point where memory actually started coming back incorrectly (bit flips as per kzbin.info/www/bejne/j2PVpIGum7CNZ6s). With the two layers cache things work quite nicely. Since the iBus never writes, I don't need to handle complicated cache invalidation cases. This breaks on self-modifying code, but who cares?
@AlanCanon2222 Жыл бұрын
@@CompuSAR I've been thinking of using VPB in the 65816 to choose among irq vectors. I'm thinking of dual 65816s, and I want them each to have independent access to the various IRQ generating devices in the design (UARTS, VIAs). There appear to be a contiguous 7 vectors worth reserved from FFEE to FFEC. So if I can force rewrite the last four bits of the vector as read by the 65816, then I can have each device choose its own handler.
@CompuSAR Жыл бұрын
@@AlanCanon2222 I'm not sure what your setup is. Having different CPUs get different interrupt vectors is an interesting idea. The selection logic is a little big for that. Are you building the computer out of discrete 74xx logic chips?
@CompuSAR Жыл бұрын
Also, bear in mind that on the w65c02s, at least, the MLB signal can't be relied on to signal read-modify-write operations correctly. For all "legacy" operations it is only low for the last two, not three, cycles of the command. So the "read" part is done with the memory not locked. I've never touched the 65c816, so I don't know whether that's also the case there. Funny story: when I first reported this, WDC didn't believe me. Since then they amended the datasheet to record this bug, at least on the 65c02.