6502.org

Just found "NAND FLash" in Digikey.
$15 for 64GB, and decent speeds.
Looking at the datasheet, interfacing will be very easy to my support AVR.

The best thing... IO is not "committee" designed! just basic digital IO.
I figured out why my SD failed on most newer cards.
Seems, there are many new standards, and none are SPI friendly...

https://kb.sandisk.com/app/answers/deta ... patibility

I think this forces crossroads was a good thing. I like the idea of a PCB mounted "SSD" for A65.
My proposed filesystem supports up to 2TB of addressing, so I won't have issues as the memory tech. evolves.

A65 does have a USB <-> PC link for backing up and transferring media assets, so there is no need for removable storage.
Ok, back to OS design using my current SD card interface for now.

Brad

(Just to note, and not to invalidate your decision, but the SD card solutions for Acorn's BBC Micro are OK with SD cards of all capacities, and bit-bang the protocol without the assistance of any complex chips, needing only a 6522 and level conversion - see for example MMFS [Edit - see below - I'm wrong! There's at least one newer and larger type of SD card which doesn't play nice.])

Thanks, I will certainly check that out.
It would be a seriously impressive feat after what I just read about the newer SD cards.
Signing a proprietary license agreement, and paying a fortune just to get the spec alone!
I did some digging at did not find a single example of an XC card working on a hobby project.
Look forward to seeing how he pulled it off.

Brad

Well, I went right to the MMFS build forum to read with great interest...

http://stardot.org.uk/forums/viewtopic.php?f=3&t=10621

The author has done great work on the project for sure.
But... he made it as far as I did today with the hardware limitations.

I also managed 8GB using SPI.
The issue is that 8 of my 10 cards do NOT have SPI support.
In fact, SPI support is no longer even part of the standard.
None of my XC or better cards would switch to SPI mode.
The newest SD that worked was a 2010 Sandisk 8GB "Micro SD" model.

So I am going to drop SD, as I don't want to end up with "find it on ebay" parts in my system.
My goal was to use state of the art support hardware to give a real 6502 new life.

I will most likely use a fast 6GB NAND flash, and just call it an SSD.

Thanks for the link though. It is amazing how far he made it with FAT support on the BBC.

Brad

Ah, OK, thanks - that's interesting and not too encouraging! I have HC cards, as it turns out.

My homebrew uses a bit-banged SPI interface controlled through a 6522. Currently it is 'tuned' for my 1GB sandisk card, but most of the code does not care about the size. I am only supporting FAT16, no folders and only 8.3 filenames.

However, all of the above in less than 2 kilobytes, and for what I needed, serves my needs - it may be a little too basic for some needs, but the code is freely available and you may be able to adapt it as required.

https://hackaday.io/project/5789-6502-h ... -interface

Nice project, thanks.
I remember looking at that one when I considered using FAT16.

Currently, my SD Card code lives in the support AVR, and works with ant SPI enabled SD Card.
The 6502 can select any block in the 4GB space, and then read data, 512 bytes at a time.
A65 is now booting and running code from the SD Card.

The AVR can also run in "Link" mode, which simulates the same memory space by linking to the PC via USB.
I write a program I call "A65 CrossTalk" that allows dumping of data directly through the USB port to A65.
This helps in these early stages of development, since I do not yet have an IDE.
Once I can develop code right from the BMOS IDE, CrossTalk will be just a backup utility.

Cross talk creates a giant binary image, and then interacts with the SD Card in RAW mode (no file system).
Getting that to work on Win7 was a real challenge! Admin policy changes, reg hacks, ack!

Anyhow, SD is just a stepping stone for me at this point, as it is all I have available.
I don't want to focus on the support technologies too much. They are just here to serve the 6502.
The only thing set in stone in this entire design is the real 6502... all other parts do not matter.

I am going to order one of these, and drop it right on my board.
Perhaps I will have the world/s only 6502 based computer with an SSD??...

http://www.mouser.com/ProductDetail/Tos ... b%2fM5k%3d

Tonight when I come in from my yard work, I will be white-boarding my file system (BMFS... Bare Metal File System).
It will be compatible with whatever mass storage flavor of the month is most affordable.

I will post a video of A65 booting from SD and running some graphics Demos soon.
It's damn cool to see this coming alive already! I can even type in new source code and run it directly.
The assembler has a long way to go though. This is a learning curve for me.

Radical Brad

BMFS (Bare Metal File System) - Entry #1

I am going to detail the creation of my file system here, and will number each entry as development evolves into something that actually works.

Anvil-6502 has 4MB of fast working SRAM that is used as a frame buffer, media storage, operating system, executable sandbox, and an IDE with assembler. Of course, program code and media such as sounds and graphics must come from someplace, so A65 will need access to a good amount of non-volatile mass storage.

I have decided to support any kind of mass storage available, from a simple 128MB serial Prom right up to multi Gigabyte flash memory. I have also decided to make my own files system for several reasons...

- It will make loading as fast as possible.
- I like to design things.
- Isolation form modern technology.

By isolation form modern technology, I mean that I don't want it to be easy to link A65 to a PC. I am building this 6502 super computer to become my main programming platform, and I intend it to be a fully stand alone unit. Using something like FAT16 on an SD card would make it all too tempting to start cross-platform developing. A65 is coming alive to defy the current sad state of technology, and not to embrace it.

Internally, the path from mass storage to 6502 looks like this...

- An AVR connects directly to the mass storage hardware (whatever it may be).
- The 6502 can make calls to the AVR driver to set addresses and read / write data.
- The FPGA chipset monitors bus access and plays traffic cop.

Currently, I have everything running from an old 2GB SD Card running in SPI mode.
During power on, the AVR just hurls a 4MB binary image to the SRAM.
This image contains the OS, the IDE, Assembler, and a test program with graphics.
There is no addressing or further calling of mass storage at this point.

So now I am going to start on BMFS so that I can read from the mass storage properly.
Here is what I am going to try for BMFS Version One...

BMFS File System Description

Disk Information Block (128 Bytes at Address Zero)
- Disk Name (32 Bytes)
- Block Size (32 Bytes)
- Total Blocks (32 Bytes)
- Free Blocks (32 Bytes)
- Padding (Up to Block End)

TOC Entry (128 Bytes at Next Block Address) x 8191
- File Name (32 Bytes)
- Start Block (32 Bytes)
- Bytes Length (32 Bytes)
- File Info (32 Bytes)
- Padding (Up to Block End)

The File Info segment in the TOC entry will contain flags to set the current status of the file, such as Valid, Erased, Version, Type, etc. there will be 8191 concurrent TOC entries before the start of actual data. I can't imagine a 6502 computer needing more than 8000 file handles!

When writing a new file, the BMFS driver will search all of the TOC entries to find the most suitable space to write the new file (least amount of empty space).

If no such space is found in the current TOC, then a new TOC entry will be made. This will be a crude wear leveling and anti-fragmenting technique.

Since I will probably end up using a multi gigabyte NAND flash as a kind of SSD, the wear leveling and anti-fragmenting offered by simply looking for the "next best fit" will probably work just fine.

Only the first block in the mass storage will not have any wear leveling, but since code is worked on directly in the 4MB SRAM and only saved once and a while, this should not be an issue. With a conservative life cycle rating of 100k writes, this will be a goodly long time.

I also plan to socket the "SSD", so that it can be upgraded or replaced if required.
I may even add a port so that mass storage can be connected externally.

Ok, so that's my file system plan so far.
It almost seems too easy, but that's not a bad thing at all.

Cheers!
Radical Brad

Sounds like an interesting new journey - worth a new thread?

The journey has been fun so far.
I would like to keep everything related to this build right here, so that this thread reads like a build log... the good, the bad, and the magic smoke!

This file system is really just a small segment of this entire project, and relatively simple compared to the magic that happens inside the FPGA right now.
Once everything is completed, I will post the inner workings in much greater detail as well.

Brad

BMFS (Bare Metal File System) - Entry #2

I have also come up with a tentative BMFS Command Set...

BMFS File System Command Set (IDE Only)

Read TOC : Read entire TOC into SRAM @ Location SRAM_DATA
- SRAM filled as TOC Tree : Container Name, File Name + Version
- SRAM max space required depends on number of entries
- Reading TOC erases source code in memory. Need to reload after

Load Source Code: Loads Source Code File to SRAM for IDE
- SRAM is written starting at segment SRAM_DATA
- SRAM max space required depends on length of code
- Option 1 : File Name
- Option 2 : Container Name

Create Data File: Create an Empty Data File for EXE to RW
- Option 1 : File Name
- Option 2 : Length of File
- Option 3 : Destination Container

Rename File : Rename File in the Specified Container
- Option 1 : Original File Name
- Option 2 : New File Name
- Option 3 : Specified Container

Delete File : Delete File in the Specified Container
- Option 1 : File Name
- Option 2 : Specified Container

Move File : Move File from one Container to Another
- Option 1 : File Name
- Option 2 : Original Container
- Option 3 : Destination Container

Create Container : Create new Container
- Option 1 : Container Name

Rename Container : Rename the Specified Container
- Option 1 : Original Container Name
- Option 2 : New Container name

Delete Container :Delete the Specified Container
- Option 1 : Container Name

Import External File : Import File from External Device
- Option 1 : Original File Name on External Device
- Option 2 : new File Name
- Option 3 : Destination Container

BMFS File System Command Set (IDE and EXE)

Load Local File : Load a Local File into SRAM
- Option 1 : local File Name
- Option 2 : Destination SRAM Address

Load External File : Load an External File into SRAM
- Option 1 : External File Name
- Option 2 : Destination SRAM Address

Write to Data File: Write Byte to Data File
- Option 1 : local Data File Name
- Option 2 : local Container Name
- Option 3 : Byte to Write

I have separated IDE from EXE commands, since the running EXE file has limited requirements.
The only writing the EXE can do is into an already created "Data File".
This way, the EXE cannot mess up the contents of the disk.
To further protect the file system, the Data File has to have proper "attributes", and is of fixed size.
The Data File is basically an EEPROM in the storage device that the EXE file can use.
The EXE may only need to save high scores, or small amounts of data anyhow.

I have added more to my PC program called "CrossTalk", which allows importing of data.
CrossTalk simulates a second mass storage device, giving A65 access to files in a certain directory.
The goal is to allow importing of media such as sprites and sounds.

BMFS will most likely evolve, but this is probably a good start.
I will report on progress as it happens.

Cheers!
Radical Brad

Writing a filesystem from scratch is a bit of a task!
... more than a day's worth of coding anyhow.
But things are looking good. I can now ask for SD sectors and get data.

Here is something very interesting I have discovered while optimizing my FPGA code...
SRAM can be completely controlled using ONLY the WE pin.
Yeah... I now have CE and OE tied low permanently in all my SRAM!

Crazy? Well, not in an FPGA design. Here is why this is working...

Inside the SRAM, WE overrides OE, so if WE is low, OE is ignored.
This is not "common knowledge", but works on all 5 different SRAM types I have used.
I also tie CE low in all my designs by default, so now I only have the WE pin controlled.

This works in an FPGA because both the data and address buses can be changed synchronously, and at a speed much greater than the setup or hold times of the SRAM. In fact, I only change WE along with the address or data lines, and never toggle it.

So let's say the SRAM is currently in write mode (WE=0), and the last data that was written is still on the address and data bus. To immediately do a read, the FPGA sends the new address, and WE=1 all at the same time. The data is then read on the next cycle. If I need another read, I just keep sending new address and then read on the next cycle. To go to a write from here, the FPGA sends the new address, the data to be written, and WE=0 all at the same time. I can do the next write on the very next cycle.

Using this method, I am now achieving SRAM bandwidth of 40MHz, which is great!
My Sprite generator speed just doubled, which is a HUGE performance boost.

Of course, this SRAM accessing method would never work on a micro-controller because you have to set address and data in sequence and then change the control lines, but in the "everything happens all at once" world of FPGAs, these kinds of tricks are possible.

Anyhow, I just thought that was a cool discovery.
I hope to have a minimal functioning File System up and running the next time I have a full day in the lab.

Cheers,
Brad

Just don't forget you've done this, if you find later that you have mysterious corruption or crashing...

Yes, the SRAM's timing specs are undoubtedly being violated, and while it may luckily work under the current conditions, problems may crop up when something (even temperature) changes.

I considered that as well, but.... are they?

The datasheet does not consider the instantaneous change of all 3 ports (ADR, DAT, WE).
By the time the SRAM figures out what to do (when WE changes), all address and data info is true.
The faster the SRAM, the more chance of this failing, but I am already using 10ns SRAM.
I also buffer all my SRAM IO, and change all data on an FPGA clock cycle.

I also bumped up the clock from 40Mhz to 50MHz and then 60MHz, and it fails as expected.
By expected, I mean based on what I calculated looking a setup, hold, and propagation values.
At 50MHz, I am right on the edge, and by adding small capacitance to the ADR bus, I can glitch things.
At 60MHz, the FPGA sees the SRAM data a clock cycle 2 late.... "one in the pipe" kind of issue.

My 8 chip SRAM stack is also made up of 512K SRAMs from 3 different manufacturers!

Brad