fuzix, caching, and emulated 6502 on an 8-pin ARM
Posted: Sun Jan 11, 2015 3:51 pm
Shane Gough has recently been publishing about his emulated 6502 system: it's both large and small, in that he's chosen an 8-pin ARM device to emulate the CPU and system, and hooked it up with SPI to a single large RAM and a single large ROM. He's had to do something inventive to connect both these up and an SPI extender for some bit-bangable I/O, because of have so few pins to work with.
But it works! And with only a small and single layer PCB. And he's written a small monitor for it, in C.
Repo: https://github.com/thegaragelab/tgl6502
Blog: https://blog.thegaragelab.com/tag/tgl6502/
Performance is low, despite the 30MHz ARM, because it takes some 32 SPI bit periods to do a memory transaction, and potentially another 24 bit periods to select the device and another 24 to deselect afterwards.
The ARM chip has only 4k of flash, which limits the amount of cleverness that can be applied to improve things. And only 1k of RAM.
Nonetheless, Alan Cox has had a go at porting his new Unix-like OS Fuzix to the system, with some signs of success, and has had a look into the possible advantage of a minimal cache, perhaps a byte-wide direct-mapped cache with 8 or 32 entries [Edit: probably not a single buffer of several consecutive bytes aligned on a natural boundary]. He says:
Another enhancement under consideration is to map zero page directly into ARM RAM. Maybe also the stack.
You can follow progress and discussions here:
https://plus.google.com/u/0/s/tgl6502%20OR%20tgl-6502 [dead link sorry]
But it works! And with only a small and single layer PCB. And he's written a small monitor for it, in C.
Repo: https://github.com/thegaragelab/tgl6502
Blog: https://blog.thegaragelab.com/tag/tgl6502/
Performance is low, despite the 30MHz ARM, because it takes some 32 SPI bit periods to do a memory transaction, and potentially another 24 bit periods to select the device and another 24 to deselect afterwards.
The ARM chip has only 4k of flash, which limits the amount of cleverness that can be applied to improve things. And only 1k of RAM.
Nonetheless, Alan Cox has had a go at porting his new Unix-like OS Fuzix to the system, with some signs of success, and has had a look into the possible advantage of a minimal cache, perhaps a byte-wide direct-mapped cache with 8 or 32 entries [Edit: probably not a single buffer of several consecutive bytes aligned on a natural boundary]. He says:
Quote:
Taking fuzix from boot to the bootdev prompt the fetch scores with an 8 byte direct mapped cache and also spotting next byte cases comes in at
Nextbyte: 154408 (transactions that would be a single SPI cycle)
Cached: 91982 (transactions that never hit the bus, this also btw happens to help nextbyte a lot, you do I suspect need both)
Misses: 162363 (reads that missed the cache + writeouts from the cache)
which drops memory access to 43% of the original
Going to a whopping 32byte direct mapped cache takes us down to 89036 actual fetches in that sequence. Adding a one liner to not mark a clean cache line dirty if we write the value it had before takes us down to 87926.
Nextbyte: 154408 (transactions that would be a single SPI cycle)
Cached: 91982 (transactions that never hit the bus, this also btw happens to help nextbyte a lot, you do I suspect need both)
Misses: 162363 (reads that missed the cache + writeouts from the cache)
which drops memory access to 43% of the original
Going to a whopping 32byte direct mapped cache takes us down to 89036 actual fetches in that sequence. Adding a one liner to not mark a clean cache line dirty if we write the value it had before takes us down to 87926.
You can follow progress and discussions here:
https://plus.google.com/u/0/s/tgl6502%20OR%20tgl-6502 [dead link sorry]
6502.org wrote:
Image no longer available: https://blog.thegaragelab.com/content/i ... ystem3.png
