Anvil-6502 : A Modern Multimedia Computer using a Real 6502

[BigDumbDinosaur]

GARTHWILSON wrote:

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.

Also, that scheme will not reliably work with the 65C816.

[BigDumbDinosaur]

Oneironaut wrote:

Writing a filesystem from scratch is a bit of a task!

Writing a filesystem that is robust and efficient is even more of a task. The robust part is particularly a challenge, as the FS has to be able to behave in a reasonable fashion following a system crash and subsequent restart. That requirement is why journaling filesystems were invented.

[Oneironaut]

It's an FPGA / CPLD only gig.

BigDumbDinosaur wrote:

GARTHWILSON wrote:

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.

Also, that scheme will not reliably work with the 65C816.

[Oneironaut]

I had considered some type of redundancy in my design, and my notepad has 2 possibilities scrawled on it...

1) The TOC is duplicated, and the backup copy is written first. This would allow a "Repair FS option.
2) I run a trickle charged battery, and the system has to unlatch a relay to safely shut down.

Option 2 does not consider FS corruption by the OS, but since I am coding in my native language of assembly, there simply will not be any bugs in the code. If I wanted buggy code, I would let a compiler do the work!

Yeah... I will probably go with the first option and just mirror the TOC.
I also have that PC link option in CrossTalk to make binary images of the mass storage.

Brad

BigDumbDinosaur wrote:

Oneironaut wrote:

Writing a filesystem from scratch is a bit of a task!

Writing a filesystem that is robust and efficient is even more of a task. The robust part is particularly a challenge, as the FS has to be able to behave in a reasonable fashion following a system crash and subsequent restart. That requirement is why journaling filesystems were invented.

[Oneironaut]

I managed to get a few hours in on A65 this week, and things are progressing nicely.
Some of the changes / fixes made...

- SD Card driver now gets 10MHz bandwidth.
- Ability to call a file by name and load using BMFS.
- Start of a CLI (Command Line Interface).
- Perfect bank switching between BMOS and assembled program.
- Ability to load external file by name through serial -> USB link.
- Massive improvements to all GPU functions with new SRAM driver.

I still have some work to do on the file system TOC loader, but that is next.
By next session, I should be able to list files on the SD card and load them by name.

Brad

[Oneironaut]

HxD... a hackers best friend!

https://mh-nexus.de/en/hxd/

This Hex Editor has been very helpful during my file system development.
The ability to open the SD Card in RAW format and dump a binary file is great.

To test my BMFS implementation, I have made a PC program that turns an entire directory into a huge binary file which contains my TOC and all of the files in binary format. This image is then dumped to the SD Card after opening it in RAW mode in the Hex Editor. I then put the card back into the A65 socket, and let it boot.

Eventually, I will only use this PC link to back up SD images, but during development it is a necessity.
So far, my file system prototype is working as expected, and soon I will have file handle read ability in A65.

Brad

[kktos]

do we have any update on this project ?
/kktos

[Oneironaut]

I have focused all of my effort into my Vulcan-74 project for now.
I expect to post the final build in June.

Brad

kktos wrote:

do we have any update on this project ?
/kktos