Accessing CF card

[Atlantis]

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.

[drogon]

Atlantis wrote:

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

[Atlantis]

drogon wrote:

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.

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.

[Dr Jefyll]

Atlantis wrote:

So I am looking for something small and simple

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

[floobydust]

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!

[BigEd]

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.

[GARTHWILSON]

Atlantis wrote:

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?

I haven't tried XMODEM, but one thing I have done, for when the code was assembled on the PC (rather than on my workbench computer which is the usual way), was Intel Hex format, since the assembler produces that anyway. It's in Forth, and I did not bother to optimize it, but you're welcome to it. I have a page on how Intel Hex works, at http://wilsonminesco.com/16bitMathTables/IntelHex.html . Another popular format is Motorola S19. These are plain text files. Each line tells the length of the line, what kind of data it is, the load address, and has a checksum and other minor error-checking. Here's an example, with most of the middle cut out for brevity:

Code: Select all

:10800000A9608D0040A9FF8D1302A2FF9A203AD3E8
:108010002091AC2016A90C30312F30322F3930206E
:1080200055534120DFD22016A90B54455354494ED5
:10803000472052414D48A9208D004068A9AA2043FD
:10804000808023850085018502C500D009C501D047
  <snip, snip>
:10D75000CD0102B0F280EAAD010249C04A4A4A4A0C
:0BD760004A8D010220F0D27AFA6840E6
:00000001FF

[BigDumbDinosaur]

Atlantis wrote:

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.

In a short-haul, hard-wired link, as would be the case with connecting your 6502 unit to a PC, use of XMODEM is pointless. XMODEM and its relatives (mainly, XMODEM-CRC and ZMODEM) were developed to deal with the noisy phone lines and their limited data transmission rates that were the norm in the 1970s before the telcos switched to digital trunks. In a hard-wired TIA-232 hookup spanning only a few feet, or even 50-100 feet, it is high unlikely noise will be a problem—TIA-232 is surprisingly resistance to noise. I transfer data from my Linux software development box over to my POC unit at 115.2 Kbps without error. I use the Motorola S-record format for that purpose.

You would be better served with use of Motorola S-records to transfer code. My preference has always been S-records, due to address flexibility and a better method of catching basic errors via the checksum byte. Also, S-records have a lineage with the 6502. We don't want that Intel stuff polluting our machines.

[GARTHWILSON]

BigDumbDinosaur wrote:

Intel hex could be used as well, as long as all addresses are 8- or 16-bits—S-records can also handle 24- or 32-bit load addresses. My preference has always been S-records, due to address flexibility and a better method of catching basic errors via the checksum byte.

Intel Hex's type-02 record allows for 1MB of addressing, and Intel 32 allows for 32-bit. This is discussed in my page linked above. They have a checksum at the end of each line, but I have not compared the strength of Intel to Mot for that, nor have I ever experienced a communications error on TIA-232 (RS-232).

[BigDumbDinosaur]

GARTHWILSON wrote:

...nor have I ever experienced a communications error on TIA-232 (RS-232).

That's why I said XMODEM was a waste of time. In years past, I've run terminals over hundreds of feet of cable without any problems, even at 115.2 Kbps. The relatively short run that would be used to link a 6502 unit to a PC should pose absolutely no reliability problem.

[gfoot]

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.

[cjs]

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.

gfoot wrote:

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.

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.

[BigDumbDinosaur]

cjs wrote:

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.

Minor clarification: the payload size per XMODEM packet is 128 bytes. There are 3 bytes in the header, followed by the payload, followed by a checksum byte, resulting in a 132-byte packet. That packet size is hard-coded into XMODEM, so making the final packet shorter is not an option. An ASCII <EOT> ($04 or Ctrl-D) is sent to indicate the host is done transmitting.

Another annoyance is XMODEM doesn't tell you how many bytes in a packet's payload are usable data and not fill bytes, which are ASCII <SUB> characters ($1A or Ctrl-Z if typed on a keyboard). With S-records or Intel hex records, each record has a length field that tells the client how much data is in the payload.

Quote:

So this might be annoying when you want to send something to the board just "underneath" something you don't want to overwrite.

Yet another reason to not use XMODEM.

Quote:

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.

CRC-anything is pointless on a short-haul serial interface. Unless the hardware and/or wiring is sheer junk, the likelihood of data corruption, even at high speeds, is zilch.

[cjs]

BigDumbDinosaur wrote:

cjs wrote:

The original XMODEM also has the disadvantage that you must transfer 128 byte blocks...

Minor clarification: the payload size per XMODEM packet is 128 bytes.

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

Quote:

Another annoyance is XMODEM doesn't tell you how many bytes in a packet's payload are usable data and not fill bytes....

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.

Quote:

Quote:

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.

CRC-anything is pointless on a short-haul serial interface.

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.

[floobydust]

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).