Re: Just the CP/M file system
- From: no.spam@xxxxxxxxxxxxxxxxxxxxxxx
- Date: Sat, 17 Nov 2007 19:18:21 GMT
On Sat, 17 Nov 2007 12:12:19 GMT,
Dave.Dunfield@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (Dave Dunfield)
wrote:
I don't want the overhead of CP/M just to load a binary image in/out
of memory. The 3.7k monitor from Dave Dunfield I am using has memory
The 3.7K is a lot already.
You really think thats big - in 3.8k he gets:
Memory dump, Memory edit, Memory copy, Memory fill, Memory
disassemble, Memory test, Load (Intel or Motorola format
records), Input from port, Output to port, Go, Single-Step
(with text instruction display, switchable instruction by
instruction register display, and an option to step over or
through CALLs), Register display, Change register, Breakpoint
set/display, Loop read, Loop write, Loop input, Loop output,
and the ability to manage and redirect the 8080 interrupt
vectors so that the monitor does not have to live at 0000.
;) Dave you gave me a copy. I know.
Thats not saying it's bad, if anything it's finally something
decent. If the rom monitor is not simple jumping off point
that is fairly minmal and transient then yours is a hugely
better tool and worth the small increase in size.
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.
Plus, nearly 1k is devoted to help text - by removeing the
help, and trimming some of the more verbose text, you can
easily get the monitor in < 3k.
CPM with bios would be around 8k and DDT
another 8 but then you have debugger, disassembler, mini assembler
and all the usual stuff and the ability to load and store. 16k sounds
fat buit thats a lot of capability thats reuseable.
But I think the whole point is that he's looking for a way to boostrap
multiple system images, so CP/M would be one of the things he's
loading.
Understood.
What you want is a the NS* style tag and bag directory and files.
Your better off rolling that from scratch and it can be expected to
be small. Basically its a database of name, location and size.
Doesn't come any simpler or easier. The L command then
becomes L filename maybe with a load address or offset.
I agree, this is the simplest solution - you could look at my DMF
operating system source code which has a very similar (and
simple) file system - in fact DMF has a NorthStar emulator which
allows N* applications to run and see the file system as N*.
I looked it's a bit easier to sort out than the NS* driver which
has a nice twisty quality about it.
The only "wrinkle" is that if you plan to be able to save/load
variable sized images, you must either reserve max image
size for each one in the flash (not too bad since you will have
bags of flash), or provide a "compress" utility so that you can
reclaim space lost when smaller is replaced with bigger.
This gets one step more complicated if you need to deal with
bad blocks in the flash (those can't move).
Oen would hope they are all good at least initially.
Side note, why S records or intel hex why not straight binary?
The files will be smaller then by quite a bit.
Agreed - My monitor uses ASCII download format because it
downloads it's data from a host computer which in many cases
cannot handle a binary stream correctly. If you are storing the
images in flash, use raw binary - saves space and less work
to load/save.
Big time. most hex record format are at least 2x larger. Great for
serial transfer but eats bulk storage.
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.
Allison
Dave
.
- Follow-Ups:
- Re: Just the CP/M file system
- From: Dave Dunfield
- Re: Just the CP/M file system
- References:
- Just the CP/M file system
- From: Grant Stockly
- Re: Just the CP/M file system
- From: Herb Johnson
- Re: Just the CP/M file system
- From: Grant Stockly
- Re: Just the CP/M file system
- From: no . spam
- Re: Just the CP/M file system
- From: Dave Dunfield
- Just the CP/M file system
- Prev by Date: Re: Z80 or 8080 tester program
- Next by Date: Re: Z80 or 8080 tester program
- Previous by thread: Re: Just the CP/M file system
- Next by thread: Re: Just the CP/M file system
- Index(es):
Relevant Pages
|