MY SBC 6502/65802

[AlexeyM82]

Good afternoon everyone.
I've recently become interested in the 6502. As a result, I've created this SBC, also assembled an HDD interface, an i2c interface board, and an spi interface board. I've written a display driver that supports CSI, adapted EhBasic and Wozmon and Krusader. I've implemented the ability to load files in HEX format from a PC. I've created a video card based on the PPU NES and written a display driver that supports CSI. I'm currently trying my hand at writing a DOS and a file system, but these are just the initial steps. I am glad to join your community. I will be happy to share my experience and learn from you.

[BigEd]

Welcome! Sounds great, and looks good too! It'd be great to hear more about it, and more about your adventures in designing and building it.

[Dr Jefyll]

Welcome, AlexeyM82... and nice work on the project!

Pure nostalgia on my part, but the vintage Rockwell chips are like old friends to me... with many a mile traveled and many a lesson learned. And even now I prefer them in some ways to the modern WDC product.

More concretely interesting is your memory array. I see no ROM there, so can I assume that the ROM function is fulfilled by one of the battery-backup RAMs? For updates, I guess you'd want a bootloader of some kind (rather than yanking the chip out of its socket every time)...

-- Jeff

[AlexeyM82]

Good afternoon, friends. Thank you for your interest in my design.
This is my first project.
In general, it was conceived as a small standalone desktop device that does not take up much space on the table, without the need to connect an external display, for experiments with connecting various programmable interface chips for their study, testing, debugging, with the ability to write and run programs on the device itself
Now, let's talk about the project in order:
Specifications and hardware:
Processor - currently a 65802 running at 4 MHz. So, my little guy is 16-bit.
Memory:
ROM - 32K. I installed non-volatile RAM while debugging the software, but it turned out to be very convenient, so I'm using it for now.
I made it writeable by setting a jumper. Some software can be overwritten.
I created a PC HEX file loader via the RS232. It's called by the non-maskable interrupt button and is immediately ready to load a file.
32K of RAM is also implemented on a non-volatile chip.

Memory distribution: the first 32K is RAM, then 256 bytes are for internal I/O ports, and 256 bytes are I/O ports for devices connected via an external connector.
The remaining space is ROM.
There is a real time clock chip on the board DS1286.
Display:
The 4-inch 256x160 LCD graphic display on the ST75256 chip with a 6x8 font provides 42 characters per line (20 lines).
It features hardware vertical scrolling. It is connected via a parallel interface directly to the processor bus.
Keyboard:
PS/2 or USB keyboards without an internal hub are supported. The controller is based on a PIC16F684 chip.
Input/Output:
2 VIA R65P22 - one for connecting a keyboard and a free port (reserved for internal use or connecting an ASCII display) plus the ability to generate internal interrupts using a timer. The second VIA has all ports routed to an external connector for connecting external devices.
1 8255 chip - all three ports routed to an external connector.
1 ACIA MC68B50 for RS232
expansion connector for connecting external devices.
software in ROM:
WozMon
Krussader 1.3
EhBasic
Hex Loader - for load soft in RAM from PC.
Expansion boards that I was able to create and launch:
HDD IDE interface Lee Davison's http://retro.hansotten.nl/6502-sbc/lee- ... e-circuit/ - It's simple and works great. I slightly modified the GAL firmware to suit my project.
SPI and I2C board:
I2C on PCF8584
SPI on ATF1504 based on materials Daryl's Rictor https://sbc.rictor.org/65spi2.html - It's simple and works great.

Display card with TV-out:
made on a chip PPU for NES
I made a text video driver with csi support and hardware scrolling, but I didn't like the image quality, low resolution, and the need to update the screen in 256 byte blocks, one per interrupt, so I put it off for now.
It works quite well, though.
PS/2 mouse interface:
The interface is based on a simple Kempston mouse interface circuit on an Attiny 2313. I used it on a ZX Spectrum, and it worked well with the 6502.

I'm currently looking to create a file system for storing files and a small disk operating system. I've even started writing my own very simple command line interface. But I'm still unsure. Should I use FAT as the file system or create my own, more suited to modest resources? I have some ideas. It could be something similar to FAT, but with some limitations and modifications (for example, file names 8 characters long including the extension, single-sector directory file table stored separately from descriptions for quick searching, etc.)...

[drogon]

AlexeyM82 wrote:

I'm currently looking to create a file system for storing files and a small disk operating system. I've even started writing my own very simple command line interface. But I'm still unsure. Should I use FAT as the file system or create my own, more suited to modest resources? I have some ideas. It could be something similar to FAT, but with some limitations and modifications (for example, file names 8 characters long including the extension, single-sector directory file table stored separately from descriptions for quick searching, etc.)...

Making your own filing system is a good exercise - I've done it a few times for various projects, however my recent ones have all sort of migrated to FAT (VFAT) Mostly for compatibility and ease of data exchange. Using an SPI connected SD card is relatively easy - take it out, put in on your desktop/laptop read/write, swap back again. No more bother than swapping out an EEPROM... Otherwise with your own design you'll need to write something like Z modem for the SBC to help transfer data to and from it - not hard, but it's an extra step.

-Gordon

[AlexeyM82]

drogon wrote:

AlexeyM82 wrote:

I'm currently looking to create a file system for storing files and a small disk operating system. I've even started writing my own very simple command line interface. But I'm still unsure. Should I use FAT as the file system or create my own, more suited to modest resources? I have some ideas. It could be something similar to FAT, but with some limitations and modifications (for example, file names 8 characters long including the extension, single-sector directory file table stored separately from descriptions for quick searching, etc.)...

Making your own filing system is a good exercise - I've done it a few times for various projects, however my recent ones have all sort of migrated to FAT (VFAT) Mostly for compatibility and ease of data exchange. Using an SPI connected SD card is relatively easy - take it out, put in on your desktop/laptop read/write, swap back again. No more bother than swapping out an EEPROM... Otherwise with your own design you'll need to write something like Z modem for the SBC to help transfer data to and from it - not hard, but it's an extra step.

-Gordon

You're right, it's the compatibility issue that's making me want to consider FAT. So, I'm still making a decision. I'm not sure FAT will be comfortable to work with with such modest memory resources, and I still need to get to grips with it. )))). I've mastered the process of writing memory blocks to HDDs and compact flash drives in raw form, now I need to decide which file system to use.

I already wrote that this SBC was created for experimentation and debugging. The project calls for something more serious, either on the 65816 or 65802, but with a 4-megabyte memory manager (I've already designed such a manager, and it works successfully in Proteus). This project will incorporate all the previously tested features, plus a color touchscreen on the PA8875 (I've already connected it to the current project and was very pleased with the result). Therefore, I plan to use the currently selected file system and operating system in the new project as well.

Do you think that it is better and more promising to use FAT?

[drogon]

AlexeyM82 wrote:

drogon wrote:

AlexeyM82 wrote:

I'm currently looking to create a file system for storing files and a small disk operating system. I've even started writing my own very simple command line interface. But I'm still unsure. Should I use FAT as the file system or create my own, more suited to modest resources? I have some ideas. It could be something similar to FAT, but with some limitations and modifications (for example, file names 8 characters long including the extension, single-sector directory file table stored separately from descriptions for quick searching, etc.)...

Making your own filing system is a good exercise - I've done it a few times for various projects, however my recent ones have all sort of migrated to FAT (VFAT) Mostly for compatibility and ease of data exchange. Using an SPI connected SD card is relatively easy - take it out, put in on your desktop/laptop read/write, swap back again. No more bother than swapping out an EEPROM... Otherwise with your own design you'll need to write something like Z modem for the SBC to help transfer data to and from it - not hard, but it's an extra step.

-Gordon

You're right, it's the compatibility issue that's making me want to consider FAT. So, I'm still making a decision. I'm not sure FAT will be comfortable to work with with such modest memory resources, and I still need to get to grips with it. )))). I've mastered the process of writing memory blocks to HDDs and compact flash drives in raw form, now I need to decide which file system to use.

I already wrote that this SBC was created for experimentation and debugging. The project calls for something more serious, either on the 65816 or 65802, but with a 4-megabyte memory manager (I've already designed such a manager, and it works successfully in Proteus). This project will incorporate all the previously tested features, plus a color touchscreen on the PA8875 (I've already connected it to the current SP project and was very pleased with the result). Therefore, I plan to use the currently selected file system and operating system in the new project as well.

Do you think that it is better and more promising to use FAT?

Not really. There's a LOT I don't like about it. Compatibility has the edge though ...

In terms of size/space... I currently use a FAT written in C and it' designed to run on microcontrollers with limited RAM - you can enable/disable various features.

See here: https://elm-chan.org/fsw/ff/

For other filing systems, and some sort of serial transfer is probably a good idea anyway, Acorns original DFS was implemented in under 8KB of 6502 and required only a few pages of RAM for workspace. Apples DOS 3.2 was a little larger (but it had a command interpreter to cope with), same for ProDOS. You could, at a pinch (and I did this as an experiment) simply create a filing system that used a "best fit" memory allocator algorithm with a linked list. You can't open+append a file and writing a file is OK as long as the writes fit into the contiguous free space, but it can be remarkably fast and with a "compact" command to manage it can be very usable especially on electronic media (ie. not spinning rust)

-Gordon

[AlexeyM82]

drogon wrote:

AlexeyM82 wrote:

drogon wrote:

AlexeyM82 wrote:

I'm currently looking to create a file system for storing files and a small disk operating system. I've even started writing my own very simple command line interface. But I'm still unsure. Should I use FAT as the file system or create my own, more suited to modest resources? I have some ideas. It could be something similar to FAT, but with some limitations and modifications (for example, file names 8 characters long including the extension, single-sector directory file table stored separately from descriptions for quick searching, etc.)...

Making your own filing system is a good exercise - I've done it a few times for various projects, however my recent ones have all sort of migrated to FAT (VFAT) Mostly for compatibility and ease of data exchange. Using an SPI connected SD card is relatively easy - take it out, put in on your desktop/laptop read/write, swap back again. No more bother than swapping out an EEPROM... Otherwise with your own design you'll need to write something like Z modem for the SBC to help transfer data to and from it - not hard, but it's an extra step.

-Gordon

You're right, it's the compatibility issue that's making me want to consider FAT. So, I'm still making a decision. I'm not sure FAT will be comfortable to work with with such modest memory resources, and I still need to get to grips with it. )))). I've mastered the process of writing memory blocks to HDDs and compact flash drives in raw form, now I need to decide which file system to use.

I already wrote that this SBC was created for experimentation and debugging. The project calls for something more serious, either on the 65816 or 65802, but with a 4-megabyte memory manager (I've already designed such a manager, and it works successfully in Proteus). This project will incorporate all the previously tested features, plus a color touchscreen on the PA8875 (I've already connected it to the current SP project and was very pleased with the result). Therefore, I plan to use the currently selected file system and operating system in the new project as well.

Do you think that it is better and more promising to use FAT?

Not really. There's a LOT I don't like about it. Compatibility has the edge though ...

In terms of size/space... I currently use a FAT written in C and it' designed to run on microcontrollers with limited RAM - you can enable/disable various features.

See here: https://elm-chan.org/fsw/ff/

For other filing systems, and some sort of serial transfer is probably a good idea anyway, Acorns original DFS was implemented in under 8KB of 6502 and required only a few pages of RAM for workspace. Apples DOS 3.2 was a little larger (but it had a command interpreter to cope with), same for ProDOS. You could, at a pinch (and I did this as an experiment) simply create a filing system that used a "best fit" memory allocator algorithm with a linked list. You can't open+append a file and writing a file is OK as long as the writes fit into the contiguous free space, but it can be remarkably fast and with a "compact" command to manage it can be very usable especially on electronic media (ie. not spinning rust)

-Gordon

Большое спасибо за ссылку, буду изучать, тема интересная.

[barnacle]

I chose FAT32 simply for the compatibility issues: I can use the laptop to format an CF drive, read and write to it, and so it's easy to transfer data in both directions (or it will be, when I get it finished). The hardware dependency is the ability to read and write sectors to the medium: CF for me, IDE works the same way but is slower, or to an SPI SD card. Once that's done, it's platform agnostic.

Currently I'm at under 3k of assembly. In use for actual files it will need about two and a half, maybe three, pages per open file (of which 2 pages are an active buffer to avoid repeated writes to the file system).

It's understood by _everything_, possibly including toasters, but it is (a) fragile and (b) convoluted.

viewtopic.php?f=2&t=8504 details some of the issues I've had.

Neil

[BigDumbDinosaur]

AlexeyM82 wrote:

Should I use FAT as the file system or create my own, more suited to modest resources?

First off, greetings and welcome to 6502-land.

Although FAT is sort of universal (mostly for historical reasons), it is a convoluted mess, as Neil (barnacle, who posted above) will readily attest.    On the 65C02, it gets cumbersome because you are constantly working with 32-bit quantities (at least with FAT32) and don’t have a lot of address space in which to set up a buffer pool.  Furthermore, due to the amount of disk-thrashing that often occurs with FAT (especially when writing a file and especially if there is no buffer pool), the speed of the medium and its interface becomes important if performance at all matters.

The other alternative in going the FAT route would be FAT16, which is nearly as messy as FAT32, but doesn’t, of course, have the long filename kludges that are part of FAT32.  FAT16, however, is limited in the size of the medium it can handle and I don’t even know if recent versions of Windows even support it anymore.

If you have access to a UNIX or Linux system, you could use the S51K filesystem, which is still supported, despite its age.  S51K is far less messy than FAT in any form, can support larger media than FAT16, and has a much saner directory structure.  It was also from a time when hardware capabilities were more limited, necessitating that filesystem design be conservative in resource utilization.

In my project, I am developing a mass storage scheme using partitions and a native filesystem that is a mashup of S51K, Acer Fast Filesystem and some fresh thinking.  I may eventually devise a read-only FAT32 filesystem driver, but that is not something that is any sort of priority.

[AlexeyM82]

BigDumbDinosaur wrote:

AlexeyM82 wrote:

Should I use FAT as the file system or create my own, more suited to modest resources?

First off, greetings and welcome to 6502-land.

Although FAT is sort of universal (mostly for historical reasons), it is a convoluted mess, as Neil (barnacle, who posted above) will readily attest.    On the 65C02, it gets cumbersome because you are constantly working with 32-bit quantities (at least with FAT32) and don’t have a lot of address space in which to set up a buffer pool.  Furthermore, due to the amount of disk-thrashing that often occurs with FAT (especially when writing a file and especially if there is no buffer pool), the speed of the medium and its interface becomes important if performance at all matters.

The other alternative in going the FAT route would be FAT16, which is nearly as messy as FAT32, but doesn’t, of course, have the long filename kludges that are part of FAT32.  FAT16, however, is limited in the size of the medium it can handle and I don’t think recent versions of Windows even support it anymore.

If you have access to a UNIX or Linux system, you could use the S51K filesystem, which is still supported, despite its age.  S51K is far less messy than FAT in any form, can support larger media than FAT16, and has a much saner directory structure.  It was also from a time when hardware capabilities were more limited, necessitating that filesystem design be conservative in resource utilization.

In my project, I am developing a mass storage scheme using partitions and a native filesystem that is a mashup of S51K, Acer Fast Filesystem and some fresh thinking.  I may eventually devise a read-only FAT32 filesystem driver, but that is not something that is any sort of priority.

Dear friend. Thank you for your interest in my project and for the fresh idea. Yesterday, I tried to find a more or less understandable, in-depth description of the S51K online, but I haven't found one yet. If you have a book or documentation, please share.

[BigDumbDinosaur]

AlexeyM82 wrote:

Yesterday, I tried to find a more or less understandable, in-depth description of the S51K online, but I haven't found one yet. If you have a book or documentation, please share.

Unfortunately, it seems on-line documentation on S51K has gone the way of the dinosaurs.    My familiarity with it stems from long ago, but trying to get you up to speed on it would be something well outside of the scope of this forum.

A good reference might be Maurice Bach’s The Design of the UNIX Operating System, which goes into quite a bit of detail on how the filesystem works, as well as the kernel’s use of disk buffers.  Aside from the filesystem discussion, Bach’s book is a good reference on all aspects of UNIX, and indirectly, on the larger universe of preemptive multitasking as it existed in the mid-1980s.  I bought my copy back in 1990 and have repeatedly referred to it over the years.  It is available in a PDF download (fairly large file), but I find having the actual book (a hardcover) more useful.

[AlexeyM82]

BigDumbDinosaur wrote:

AlexeyM82 wrote:

Yesterday, I tried to find a more or less understandable, in-depth description of the S51K online, but I haven't found one yet. If you have a book or documentation, please share.

Unfortunately, it seems on-line documentation on S51K has gone the way of the dinosaurs.    My familiarity with it stems from long ago, but trying to get you up to speed on it would be something well outside of the scope of this forum.

A good reference might be Maurice Bach’s The Design of the UNIX Operating System, which goes into quite a bit of detail on how the filesystem works, as well as the kernel’s use of disk buffers.  Aside from the filesystem discussion, Bach’s book is a good reference on all aspects of UNIX, and indirectly, on the larger universe of preemptive multitasking as it existed in the mid-1980s.  I bought my copy back in 1990 and have repeatedly referred to it over the years.  It is available in a PDF download (fairly large file), but I find having the actual book (a hardcover) more useful.

Dear friend, thank you very much! I downloaded this useful publication and will study it.

[No True Scotsman]

AlexeyM82 wrote:

I created a PC HEX file loader via the RS232. It's called by the non-maskable interrupt button and is immediately ready to load a file.

May we see it?