I can use a few calls of srec_cat in the makefile to build a hex file. I have done it, but I hadn't thought of using grep, so I'd coded the addresses to split on into the makefile itself.
My main objection to using binary files was that I'd need to hardcode addresses into the makefile, defeating a large chunk of the purpose of having a makefile in the first place. But if I can use grep to search for labels in the list file, I can extract addresses from that.

Oh, I see - that's quite neat! I think I've used variables in the past, which can be part of the make invocation, but that was solving a slightly different problem.

CA65 feels a bit odd. The need for a long-ish makefile to get a useful output file is irritating, but once it's correct, it doesn't need to be written again.
I don't use high ASCII in my own code, but I include EWOZ and A1-Assembler, which do. EWOZ doesn't mind the relatively superficial conversion I've subjected it to, probably because it uses zero-terminated strings. That works just fine. A1ASM doesn't like it at all, which I did expect. Fixing the zero-page memory reservations felt like I was using a blunt instrument.

CA65 has some interesting-looking options as far as conditional assembly goes, but it's rather less attractive in other areas, and quite strict on its syntax. It does have decent error messages, though i found myself having to do the C thing of checking the line before the indicated one.
I think it's intended more as a tool for CC65 to back onto, than as something for a human to actually use.

Converting Ittiara's firmware over to CA65 was a rather laborious, but interesting and informative exercise. I don't think I'll continue with it, though. CC65 would be the main draw for me, but since I don't understand what they're going on about in the docs regarding retargeting, I can't really use it, so I don't think it's worth it to me at this point.

As far as filesystems go, I'll probably use the propeller to read FAT on an SD card, and interface to that(It's going to be there as the sound device in any event). The EEPROM modules will probably use a simple(read: primitive) filing system. I can't say I've looked all that hard, but it's not seemed easy to find concrete information on the Minix file system. I've seen a few sources that say different things about the superblock in particular, and I'm not sure which to believe.

I do realise I'm copping out here, but writing a filesystem driver seems to be rather more work than I'm willing to put in. Even implementing an existing filesystem is made difficult (in my opinion) by the fact that there doesn't seem to be much information around the internet on them, I've found contradictions in places, and I haven't been sufficiently motivated to verify them for myself. I've also had a bit of a running theme of using and/or adapting pre-existing software in this project. The only vaguely original software in Ittiara is the hardware drivers and the menu.

Speaking of which, I've lost a chunk of motivation for this project, partially over the file system, partially over having mostly finished the low-level stuff, and needing to get on with building an interface.

Building a CLI is something I'd much rather do in C (Ideally C++, but that's not likely to happen at all). Trouble with that is that neither CC65 or WDCs compiler(s) appear to be particularly well documented, and WDCs tools are windows-only, so I can't use it in my existing development environment, which is linux-based. It is an annoying situation.

I hope you can persevere with cc65 - many people have got it working, and you should be able to find help on this forum when you need it.

Motivation is a scarce resource sometimes, I know that!

Filesystems don't have to be difficult.

CP/M's file system is quite simple, pretty well documented, and certainly there's existing code readily available (albeit in 8080/Z80).

The P-System file system is trivial (but has some very not-so-good limitations, which is why it's trivial, but may suit your use case). If nothing else it's a great start on fundamentals of filesystems. Understand that, then understand CP/Ms, then understand FAT.

In the end, a basic file system is a directory (list of files), a Table of contents (typically a bit map, which sectors are in use), and some way of linking the sectors together. You can look at how the Atari did their file system, it's pretty simple. It's just a linked list as I recall. (Detailed here https://www.atariarchives.org/iad/chapter2.php -- really simple.)

Don't hesitate to look at things like the {Free|Open|Net}BSD sources if you want to know more about FAT, or even other file systems that they support, including older versions of the Fast File system from ages ago, and other early Unix filesystems.

Regarding CC65, I have not used it, I know what you mean regarding the assembler, as it was off-putting for me as well. But, that said, I don't think there's a good alternative to CC65 right now, so it may well be worth the effort to get it to work for you.

there is a CP/M like OS for the 6502 with media compatible fileystems from what I gather. Details here: http://www.z80.eu/dos65.html





There are even filesystems that are not even filesystems. The first forth I used simply used disk block numbers - each block corresponded to (very exactly) a page that the Apple II display could show. From what I recall, you had to put a link instruction at the bottom of one page to continue your program to the next page. The directory was literally a block which you hand-edited to show what blocks were used by what files. (It may well have been an early/original Fig Forth - this looks familiar: https://github.com/ForthHub/FIG-Forth/b ... er/fig.fth ) Even some early mainframe computers had nothing much better than that for a while...

And the apple DOS 3.3 source is out there somewhere - replace the RWTS code with a basic block driver for the media and off you go...

-Gordon

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

See here and here for some filesystem design discussion.

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

That's why we don't call them filesystems.

The P-System filesystem is basically just a minor step above the Forth Block system.

It's a block system with a directory.

I've schemed about an idea for what I was calling "block sets" to make managing multiple "chunks" of block storage easier. In the end, it's a simple directory structure pointing to continuous "sets" of blocks. The importance of the block set was that they were a first class concept within the Forth system and, specifically, things like the editor and other utilities worked with them.

The essential use case was "how do I insert a screen of code in to a block of routines" and it goes from there. For this simple use case, you need to know where to start and how long your block set was, so you would know what range of blocks need to move to make space for the new screen. Add on the additional factor of some Forth systems that use "shadow screens" for documentation means that when you insert a new screen, you actually insert TWO screens -- one for the code, one for the shadow. A shadow screen is a screen that's allocated at some fixed offset from the code block. So, if you had a set of 200 screens, the shadow screens would start at block 100. The basic idea is that you could easily swap back and forth between the normal screen and the shadow screen, using the shadow screen for documentation. It actually works pretty well, but it's one more thing you have to keep track of.

Going back to the P-System, it has a simple directory, and contiguous files. Most file systems have some kind of "table of contents" to track which sectors are in use. P-System does not. Since all of the files are contiguous, it "knows" what sectors are free or not simply looking at the directory. If it sees two entries, one starting at sector 100 and 50 long, and the next starting at 200 and 25 long, it knows that sectors 150-199 are not in use. It was a routine process to "K)runch" your drive, which simply means it compacts all of the files and removes free space in order to give you the best chance to have the most contiguous space available when creating a new file.

However, it also limits the system to only allowing a single file to be opened for write at one time. And in the previous scenario, before the compaction, if you tried to write a file that was 51+ sectors long, you'd get a "disk full", since it would start writing the file at the first free sector it found at 150, even though there may well be free sectors later on in the disk.

As I hope you can see, this is just a step up from what Forth offers. It's usable, it's trivial to implement, but does have some limitations. The implementation of a table of contents allows you to create more than one file for write at a time. At the same time, it allows disk fragmentation, which is a different problem.

Another interesting tid bit about the P-System is that beyond creating, reading, and writing files, the runtime didn't offer any routines for file manipulation. It has a "Filer" which does all of the file maintenance. There's no "rename" file system primitive you can call, rather, when you renamed a file, the Filer utility went peeking and poking in to the directory structure itself. The Filer was intimate with the file system details, but these were not published to the system at large. (This may have changed later on in later versions of the P-System.)

I have taken a shot at getting cc65 to compile for Ittiara. It looks like it should work, but for some reason, it doesn't appear to be getting to my C code.
Thankfully, I have a bit of information to go on, because I have the cc65 source available, and I can make use of that with White Flame's interactive disassembler.

With a bit of experimentation in my crt0.s, It looks like it's going off the rails in the zerobss routine, which zeros global variables that aren't explicitly initialised. Trouble is, that is provided by cc65 itself, and the disassembly looks to me like it's not doing anything particularly wrong. It should do nothing, since I'm not using global variables.

Both copydata and zerobss are in their own source files, bearing those names. I can't find initlib's source, though, and that's a problem, because I can't tell what the intent of that code is. It's got a piece of code that copydata puts at $0200, and might run it, but I'm out of time for now. I'll leave off for now, and come back tomorrow.

I've found the source for both initlib and donelib, and it appears that both should also do nothing in the current configuration.
I'll temporarily copy the source for some of the C runtime routines I'm using into crt0.s, so I can instrument them, as I think it's called.

With a bit of tinkering, it appears that it's getting to the end of zerobss just fine, but for some strange reason, it's not going back to where it came from when it hits the RTS.
I smelled a stack problem, so I set the program up to give me the return address using the VIA(I had to do this across two runs, because of the display limitations, so it could be dud.) It seems to be returning to $00F7, which would explain the apparent failure to return.
I have no clue why it's doing this. CC65 works for some people; I have no idea why it's being badly-behaved for me.

What makes this so much more infuriating is that it seems to be inconsistent as to the results.
And I think I killed my 65SPI when I accidentally reversed the power supply. It gets burning hot in very short order now.

It'd probably be helpful if I posted the project files.
I've deliberately left a hole in the .cfg's memory map, so that CC65 won't trample on the IO registers, duart.s only implements channel A(8N1, 115200) for the moment, as I'm still trying to get CC65 to work properly, and the rest are mostly boilerplate. The C program is supposed to spew a stream of "X" out on the DUART.
There is a makefile, and that assumes that the CC65 files are on the path.

It seems to get as far as the end of the first runtime call(zerobss) before it goes off into the weeds. I suspect that something is going wrong with the return value on the stack. I imagine that a few alterations to the program and a bit of getting off my metaphorical butt and wiring up more LEDs to the VIA could be much more diagnostic, and I might do that tomorrow after work.

And that's why power supply circuits should always include a reverse-voltage blocking diode close to the connector. Since that tends to induce a voltage drop in normal operation, combining it with a DC-DC regulator and smoothing capacitors is also sensible.

NOT a good sign! And unfortunately it'll be more difficult to get a replacement, compared with other chips you're using (which are standard, off-the-shelf parts).

Speaking of those other chips, keep in mind that they, too, may have been damaged by the mishap, albeit in ways that are less obvious and dramatic.

The suggestion of a reverse-polarity protection diode is worth considering, and there are two ways it can be done, each with advantages and disadvantages. If it were my own project I'd connect a Schottky diode in parallel with the supply (and close to the connector) to act as a shunt when the supply is reversed (rather than in series, which, as noted, entails a voltage drop during normal operation). It's a simpler arrangement, but be sure to select a diode with a fairly high current rating, as the goal is to shut down the power supply by engaging its over-current limiting. 15SQ100TR and SB1245 are suitable examples.

-- Jeff

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