Quantcast
Channel: stardot.org.uk
Viewing all articles
Browse latest Browse all 3406

32-bit acorn hardware • Re: Arm610 in an A3000/etc

$
0
0
This is very cool, Ian! =D>

Do you plan to look at patching RISC OS to turn on the cache? In the past I had a look at what would be involved, as ARM610 cards seem to be readily available whereas ARM3s are like gold dust. It might be doable:
  • ARM6 would run in 26/26 config (unlike RPC where it's mainly in a 26-bit mode in a 32-bit config, hence a mess with aborts)
  • To enable the cache and write buffer, the MMU has to be enabled
  • The MMU would do all the address translation instead of MEMC, so all memory access via MEMC is to a physical address (TRANS deasserted)
  • RISC OS needs to be patched to replace the MEMC hardware CAM mapping (not used) with the MMU L1/L2 page tables (about 100kB in RAM) - could be copied from the RO3.6 source, but affects kernel workspace etc.
  • Whenever RISC OS reprograms the CAM mapping (BangCAMUpdate), do the appropriate MMU page table update instead (compare MEMC and ARM600 source in the RO3.6/3.7 source for the equivalent routines)
  • The main impact is in the RO3.1 ChangeDynamic memory allocation (required for the Wimp to work as well as general memory movement)
  • Could assume a fixed memory size (4MB) and fixed allocations for RAM disc, sprite area, font cache, RMA, screen
  • Replacement routines could be patched over the POST code (there's also some spare space at the end of the ROM), with branches from the original routines bodged in
  • There are some useful descriptions of the MMU and memory mapping changes from RO3.1 to RO3.5 in the RO3.6/3.7 source (ARM600 and docs)
  • I don't understand what's going on with SEQ - MEMC1 can (does) start a new access in the previous (internal) cycle so I think SEQ is only needed (deasserted) if the ARM does a non-sequential access in the middle of an existing access, when MEMC then needs more time... with ARM600 all external accesses are supposedly sequential...
Is it possible? I think it would essentially be recreating the RISC OS build for the Vicky development machine, which seems to have been an A540 with the ARM600 card, using the MMU for memory management and MEMC for hardware access (see Export.Hdr.Global.Machine.Vicky where MEMM_Type is "ARM600" and MEMC_Type is "MEMC1a", along with various workspace changes). I don't know how feasible it is to patch the kernel without really being able to build it (and without the actual sources, only the later ones). Sounds like a challenge (but it may be too easy for some on here!) :D

Statistics: Posted by timw — Tue May 27, 2025 6:44 pm



Viewing all articles
Browse latest Browse all 3406

Trending Articles