I am relatively close to finish my project of 6502 based computer. Recently I was able to make it run CRT screen with TMS9918 chip and PC AT keyboard with 8242 chip. Now it is nearly fully functional EhBasic computer. Now I just need some solution to save and load programs.
There is CF card socket on my board. I was able to test it superficially, by reading card info and read/write sectors. It appears to work correctly. Now I need some code to link it with SAVE/LOAD subroutines of EhBasic. I do not expect it to support FAT16/FAT32 or any other modern PC file system. In fact I do not even need directories. It would be sufficient if I would be able to save program under some name, list all programs stored on CF card and load one of them.
Maybe there is some existing piece of code I could adapt, without reinventing wheel?
It would be great if it would enable me to load/save both: Basic and machine code programs.

The next step will be to add some solution for loading programs from PC, with RS232 interface and XMODEM for example. Is there any tested and easy to implement solution?

And by the way: is there some tutorial describing adding own commands to EhBasic? I plan to integrate RTC use into it, among some other things.

At the risk of encouraging you to write another 16KB of code, I'd encourage you to put a well known filesystem on the card - namely entry level FAT.

For the main reason of being able to read/write the SD card on another system - PC/Linux/Mac, etc.

In my enthusiasm to increase "goodness" on my Ruby system I built my filesystem from scratch, but based on an existing filesystem, or 2 - it's almost Apple ProDOS with extensions for longer filenames, unlimited files per directory, file attributes that the Acorn/BBC Micro filesystems supported (things like load and execution addresses and some other bits of interest to Acorn/BBC Micro systems) the net result was that I then had to write an 'FTP' programs to get data to/from the system via serial - not the end of the world (and yes, maybe I should have implemented zmodem there too) ...

A small issue with xmodem is that it has fixed size blocks (128 bytes by default) and no notion of a filesize - this is going to be just fine for load/save of BASIC programs though, but introduced garbage at the end of text files (where in the CP/M world a text file ends with Ctrl-Z)

Also, DOS/65? Might be worth a look - seems like all the hard work of what you need has been done there already...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The main problem is that I didn't design my hardware with such features in mind, so there is not enough of EPROM to fit all that code. I just use 16kB of non-paged EPROM, which is just enough for EhBasic + I/O drivers + some LOAD/SAVE routines, but not enough for full, modern FS. I experimented with compiling FatFS under CC65 and I know how much space compiled code takes.
So I am looking for something small and simple: CF card as a solution for local storage and XMODEM as a way of transferring software from/to PC.

FWIW, here's a suggestion that's clunky and wonky but may nevertheless suit your needs.

Use your PC to format the CF, then create and store on it one or more dummy files of a fixed size -- 64K, perhaps. Then determine the absolute sectors at which the dummy files are stored. Each 64K chunk will be in a series of contiguous sectors, as we're using freshly formatted media. The plan is to never alter these locations.

Your SBC can ignore the FAT system but still read and write the absolute sectors, so your need for storage is satisfied. And you can also use the CF to swap the data back and forth with the PC, as long as you're careful to do nothing that'd alter the FAT.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A couple thoughts...

1- I worked on a CMOS version of EhBasic that is a smaller than the original at just under 10KB (10,126 bytes) and uses less Page Zero space. It has Load and Save routines that call the Xmodem routines in my Monitor code. That allows saving Basic programs to your PC via the console UART. If you squeeze it a bit, my BIOS, Monitor and EhBasic will fit in 16KB.

2- I recently completed a port of Richard Leary's DOS/65 based on his Version 3 ROM code. That requires roughly 6.5KB of ROM space. It works withe my BIOS code which supports a Compact Flash Card. The current configuration supports 8 drives at 8MB each.

You might want to see how much of that code you can leverage on your system. I would likely suggest you focus on getting BIOS, Monitor and DOS/65 running in the 16KB of ROM space, as it can easily fit. You can then use EhBasic as a loadable executable from DOS/65. The only bit left for you to do is to modify the existing Load and Save routines to cal DOS/65 and save your programs that way.

You can find all of my code on my GitHub page. Have fun!

_________________
Regards, KM
https://github.com/floobydust

Nice plan Jeff.

It just might be worth a look at hoglet's MMFS code for the Beeb - it has a minimal approach to reading a FAT and just picking out one file.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I used XMODEM on a recent project just because it's well supported by off-the-shelf terminal software, which is also handy regardless of whether you need the checksums and retries.

The original XMODEM also has the disadvantage that you must transfer 128 byte blocks, as I recall; there's no provision to make the last block shorter. (In CP/M binary file length was always a multiple of 128 bytes or sector size, and text files had their end indicated with Ctrl-Z.) So this might be annoying when you want to send something to the board just "underneath" something you don't want to overwrite. Later varients of XMODEM fix this, but of course are more work to implement.

Way back when I was looking through protocols for transfer stuff to microcomputer boards, I thought that Kermit looked like one of the better options. It's far from the speediest, but that's not a huge issue on modern 115 kpbs links, the most basic version is fairly simple to implement, and IIRC it had some good (and well-supported in host programs) options for transfer auto-start on one end so that you could type just one command on either end to send the file, rather than having to type something on each end.

But of course with S records if you make the monitor command to receive them `S` you have more or less the same thing, and also then don't need to deal with addresses in your command lines for programs. But you need to deal with host-side conversions of data for other things (such as a ROM you want to download to burn for another machine) and upload to the host may also be a bit more work.

Regarding error checking, strength of checksums and the like, I recommend including a CRC-16 routine into your monitor that you can run on arbitrary sections of memory. This can not only identify transfer errors but also things like corrupted memory, hardware errors when reading memory, and that sort of thing.


Sure, but off-the-shelf software also generally supports "text" upload, which works fine to send S record files as those use only printable and line ending characters.

_________________
Curt J. Sampson - github.com/0cjs

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I do not understand what you're "clarifying" here. How is this different from "XMODEM transfers 128 byte blocks"?


Of course not. XMODEM, being designed to carry disk sectors, has no fill bytes. Applications at a higher level dealing with files from disk may decide that some bytes are "fill" or not, as they wish; e.g. CP/M programs dealing with what they consider to be "text" files may decide that the file ends when they see ^Z and ignore the remaining data in the file, but those data are still there and CP/M and XMODEM treat them as just as much part of the file as any other bytes.


I wouldn't say it's always completely useless, but I agree with you enough that I did not suggest anybody use CRC to check packets over a serial interface. So either you're again being redundant here or you did not read what I wrote, but instead what you wanted someone who disagrees with you to write.

_________________
Curt J. Sampson - github.com/0cjs

Well, sadly, I'm the oddball on this one. I use XMODEM-CRC and specifically wrote my implementation to use it with the console port (the only UART port). As previously noted, XMODEM is still supported by many current terminal programs. This makes it trivial for me to download and upload data between my SBC and the PC. I later modified the download portion to sense and decode S-Record files, as created by WDC Tools. This allows me to easily download and test code without yanking and reprogramming the EEPROM.

As for CRC being useless in what is basically a direct-attach configuration, I would disagree from experience. I actually had a slightly flaky UART some time ago. In some cases it would transfer data without issue... every once in a while, the transfer would fail. A CRC error actually occurred based on the highly intermittent problem... who knew.

Either way, for the time being, I'm still planning to keep using it. Richard Leary's DOS/65 code also has a XMODEM utility, which I'm also using... this will transfer code to/from via the console port. The only limiting factor is the 512KB maximum file size supported by the filesystem (which is CP/M compatible).

_________________
Regards, KM
https://github.com/floobydust