With the 65SPI project nearing some sort of completion ( ), I've been having a bit of a look at SPI-bus peripherals.

Out of curiosity, is anyone (else) going to try using the 65SPI chip with a BBC Micro (rather than a home-brew kit)? If so, perhaps they'd like to get in touch with me - if for no other reason than not duplicating effort.

(Also, I've got a couple of ideas in mind, and want to try running them past someone else - just in case they're "dumb".)

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

Debug box. LCD display or to another PC to probe registers and memory locations as well as single step....

_________________
"My biggest dream in life? Building black plywood Habitrails"

One idea I'm mulling over is a variant of the "ROM filing system" - attaching SPI EEPROMs (pre-)programmed with useful (!) stuff; any interest?

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

Martin's Library of Programming Memories

_________________
"My biggest dream in life? Building black plywood Habitrails"

Maybe - but I see the main use of a "ROM filing system" is to allow someone who's put together a SBC to drop an SPI EEPROM into said system, and have assorted handy utilities avalable "at the drop of a hat".

(Admittedly, the code I'd produce - which I'd go and submit to the 6502.org code library - would contain a lot of BBC Micro-specific "features", but the file storage format and read algorithms would be easily adaptable.)

--Martin

(And, before someone says "Why not use FAT16?" - this would be perfectly fine for a more sophisticated SBC, but a more minimalist - or first - SBC may benefit from a "simpler" storage format.)

_________________
Martin Penny

.sig in beta - full release to follow.

Like I said, Martin's Library of Programming Memories.

_________________
"My biggest dream in life? Building black plywood Habitrails"

Even the more sophisticated systems will benefit from a more compact representation to. FAT exists to manage a malleable storage medium. ROM is perfectly fixed -- the need to manage placement of data in the ROM simply doesn't exist, as ROM is essentially immutable (yes, I'm aware of the exceptions: EPROM, lightning strikes, etc.). With this constraint removed, loading a file from a ROM filesystem amounts to a simple block-copy operation. Finding a file amounts to just walking an array of (filename, starting-address) tuples in the simplest cases, and maybe a skiplist or B-tree in the most complex (if you have to rapidly find files for whatever reason).

Lee Davison designed a simple ROM filesystem with some corresponding 6502 code at:

http://www.themotionstore.com/leeedavis ... index.html

There's some good ideas there, even if you decide to go in a slightly different direction.