Re: Just the CP/M file system

The 3.7K is a lot already.
It is big by most S100 monitor standards most being the
1 and a few 2k size range. Even the one I use most is
under 2K including the built in disk IO code but I don't
pretend it's do all though it's easily added to.

If you want small, I can give you a 512 byte 8080 monitor that
doesn't use ANY RAM! - Or a 1K monitor with basic memory
dump/edit, Load and Go - most of the S100 monitors I've
seen are in this catagory - Just simple command processors.

The monitor we are talking about was designed as a software
debug tool, not a "minimal front panel". Among other things It
has a full disassembler, breakpoint capability, and an instruction
emulator which allows you to single-step not only through RAM,
but through ROM as well (Very handy on a machine which makes
ROM BIOS calls etc.) These things take space, and IIRC it was
a fair bit of work to stuff it into 3K of code (I wrote it more than 20
years ago).

The version I gave Grant is the one I have installed in the SSM
CPU card of my Vector 1+ - this card has a 4K ROM socket,
and 2K of RAM - I have it positioned up above the NorthStar
controller, so it does not take up usable space. I also added
the memory test and loop read/write for hardware diagnostics.
The monitor itself runs with stack/local storage in the static
RAM on the SSM CPU, which makes it real nice for testing
memory (it works even when main system RAM doesn't)


This gets one step more complicated if you need to deal with
bad blocks in the flash (those can't move).

One would hope they are all good at least initially.

I've had a fair bit of correspondance with Grant on this board,
and he is planning to use bulk NAND flash as the secondary
storage (the one with the file system). Unlike parallel direct
access memory, these devices have a published error rate
specification, and often have bad blocks from the get-go.
This is the kind of memory used in storage cards, USB
sticks etc. You really need to think of it more like a disk
drive than as memory.

A properly implemented file system in NAND flash will also
use a low-level ECC algorithm to detect and correct errors.
Use of ECC is recommended in the data sheets. I've already
given Grant the ECC code he needs. But the possibility of
unrecoverable bad blocks remains something that should
be dealt with. Flash file systems take some care to get
right...


Minior point while S record is a good format the 8080/z80 world is
mostly (not completely) Intel Hex biased. CP/M is however
completely Intel Hex biased.

I've done a lot of work with Motorola as well, so all of my monitors
will work in either format - in the case of download, they automatically
detect which record type it is, so you can fire either format at them
and it will "just work".

Dave


--
dave06a@ Low-cost firmware development tools: www.dunfield.com
dunfield. Classic computer collection: www.classiccmp.org/dunfield
com Some stuff I have for sale: www.dunfield.com/sale

.