fuzix, caching, and emulated 6502 on an 8-pin ARM

Let's talk about anything related to the 6502 microprocessor.
Post Reply
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by BigEd »

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:
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.
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]
6502.org wrote:
Last edited by BigEd on Wed Dec 02, 2020 6:09 pm, edited 1 time in total.
User avatar
jac_goudsmit
Posts: 229
Joined: 23 Jun 2011
Location: Rancho Cucamonga, California
Contact:

Re: fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by jac_goudsmit »

Emulating the TGL-6502 on my L-Star is on top of my To Do list. Should be fun to emulate a 6502 emulator with a real 6502 :-)

===Jac
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by BigEd »

You'd bring SPI out of the propeller and add 3 SPI chips?
User avatar
jac_goudsmit
Posts: 229
Joined: 23 Jun 2011
Location: Rancho Cucamonga, California
Contact:

Re: fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by jac_goudsmit »

BigEd wrote:
You'd bring SPI out of the propeller and add 3 SPI chips?
That would be possible but unnecessary. I may not have as much memory available as the TGL-6502 but I don't need to add any hardware, I think.

If I understand correctly, the 6502 in the TGL-6502 communicates with the user via two memory locations; writing to one location sends a byte to the terminal and reading from another location reads a byte from the same serial port. This is pretty easy to emulate (though I'll have to probably deal with the fact that I can't hold the 6502 while the UART is busy sending or receiving). Installing Fuzix should also be a matter of putting the name of the binary into a source file. That's what I was talking about when I said I'd like to emulate this emulator.

===Jac
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by BigEd »

Oh I see, so you emulate just the characteristic I/O environment? For fusix, are there also details of banking which you'd need to emulate?
User avatar
jac_goudsmit
Posts: 229
Joined: 23 Jun 2011
Location: Rancho Cucamonga, California
Contact:

Re: fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by jac_goudsmit »

BigEd wrote:
Oh I see, so you emulate just the characteristic I/O environment? For fusix, are there also details of banking which you'd need to emulate?
L-Star doesn't have enough memory to emulate bank switching (the Apple 1 emulator has 16K, the other 16K in the Propeller is needed for the Propeller firmware). Maybe that means Fuzix is impossible on L-Star. I might still be able to do bank switching on Propeddle though; it has 128KB. The plans are still very vague at this time. I'm very busy at work and I want to get the OSI/UK101 emulator for L-Star done first. And I have some other projects coming up. But let's not hijack this thread any further :-)

===Jac
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: fuzix, caching, and emulated 6502 on an 8-pin ARM

Post by BigEd »

(The Fuzix wiki has several pages which indicate what makes for a more or a less convenient port of the OS to a platform. tgl6502 is the reference platform for 6502; it has 8 slots of 8k to map the 128k of RAM very flexibly, but it seems that Fuzix doubles up these slots - it prefers 16k slots.)
Post Reply