6 ms·
Throwing a cache into a system that never had a cache before can be quite tricky. You could have these kinds of memory pages: * Fixed ROM bank * Bankswitchab
by Dwedit 3y ago
Throwing a cache into a system that never had a cache before can be quite tricky.
You could have these kinds of memory pages:
* Fixed ROM bank
* Bankswitchable ROM bank
* Fixed RAM bank
* Bankswtichable RAM bank
* IO memory
* RAM that's read by external devices
* RAM that's written to by external devices (basically just IO)
Caching is trivially easy for fixed a ROM or RAM bank which are not used by other devices. Caching a bankswitchable bank requires either invalidating on bankswitch, or knowing the bank switching well enough to just cache everything. Pure IO memory is simple, no caching for that at all. For RAM that's read by other devices, Write-Through caching would work.
- rbanffy 3y agoThe article mentions the bank-switching issues and that the FPGA only has 64K, which limits emulation of higher memory configs - it’d not emulate a //e with 80-column display (which requires 128K).
- bpye 3y agoYou could plausibly make bank switching work, but it’d take some effort. You’d want your block RAM to act as a write back cache, and then any bank switch must be intercepted and delayed until you can flush the full contents of the cache to memory. Or if bank switching is fast and occurs too frequently for that to be viable, you could avoid the flush across a bank switch, but then you may need to perform a bank switch for an eviction.
- rbanffy 3y agoIt’d be easier to get an FPGA with more RAM or connect some external SRAM. It’s probably hard to get one with less than the maximum addressable memory of an Apple II anyway.
- masfuerte 3y agoThe BBC Master had an even funkier mode. The RAM bank accessed could depend on the current program counter. Imagine a video display taking 16K of RAM. This would be situated between addresses 0x4000 and 0x8000. This same memory range also included non-video RAM. The hardware transparently selected the video or non-video RAM depending on which code was accessing it. Specifically, if the program counter was at 0xC000 or above (i.e. code in the OS ROM was running) then accesses to the video range would go to the video RAM. But if the program counter was elsewhere (i.e. running user code or an application ROM) then accesses to the video range would go to user RAM, not video RAM. Additionally, there was a hardware register controlling this so that user code could choose to directly access the video RAM, and OS code could access the user RAM.
- forinti 3y agoI've been looking for a detailed explanation on this, because I would like to know how they read the PC. The New Advanced User's Manual describes the flag at &FE34 on the Master and B+ and I've read this thing about using the PC from a few places but I haven't found any specifics. Could you clarify? How do you know from the outside what's in the PC?
- flohofwoe 3y agoThere were also 8-bit home computers (like the Amstrad CPC and C64) where a different memory bank would be accessed depending on whether the CPU would do a read or write access, e.g. a read would access a ROM bank, but a write would access a RAM bank at the same address (usually called 'shadow ROM').
- rjeli 3y ago
- okl 3y agoA minimum solution could be an instruction fetch buffer that memorizes the last N instructions (maybe even after decoding?) to alleviate pipeline bubbles and when jumping back.
- hkgjjgjfjfjfjf 3y ago[dead]
- deleted 3y ago[deleted]