Re: ELFos questions
It would not take too much to adapt the Elf/OS kernel to use single
sector (512 byte, or even 256 byte) lumps. All you would have to do
is change the lump calculation routines and the routine that
determines if a read/write crosses a lump boundary. With a 512 byte
sector size, each LAT sector will map 128k (256 entries per LAT sector
* 512 bytes per lump) Going to 256 byte sectors, then each LAT sector
will map 32k (128 entries * 256 byte lumps). This would keep table
overhead pretty small.
The kernel can be almost entirely placed into ROM (current kernel
size is 4686 bytes), the only things that need to be placed into RAM
is variable data, plus the call table should be kept in RAM to
maintain API compatability, but this can be copied from ROM to RAM at
startup. Elf/OS normally uses 2000h up for user programs/data, but by
moving the kernel to upper ROM you could move this boundary lower. if
the kernel is going to be held in ROM, then 16 sectors can now be used
for data, all you would have to do is modify the kernel as to where
the LAT table starts, sector 1 instead of 17.
With this approach using 512 byte sectors and mapping 128k of RAM
and having the kernel in ROM, you need 1 LAT sector, 1 boot sector
(This holds information needed by the kernel, but you could hard code
this stuff in and then you would not need this sector) and 1 sector
for the MFD for 1536 bytes of the RAMdisk for tables. each additional
128k of disk would need one more 512 byte LAT sector.
With 256 byte sectors to map 128k of memory you will need 2 boot
sectors (pointer data is in upper 256 bytes of a 512 byte sector, but
again hard coding the values eliminates the need for this 512 byte
block) 4 LAT sectors (32k mappable per LAT sector) and 1 MFD sector
for a total of 1792 bytes plus 256 bytes per additional 32k in the
If you are interested in pursuing this approach, let me know and I
could probably help you in pointing out what needs to be modified.
--- In firstname.lastname@example.org, "Allison Parent" <kb1gmx@a...> wrote:
> --- In email@example.com, "J.C. Wren" <jcwren@j...> wrote:
> > What are doing that drives these requirements?
> First off nothing commercial or even serious.
> It's just I've had a basic elf and a few limited ram elves
> and they never see much use for lack of any useful application.
> So if I'm building it might as well have a purpose in life.
> The end goal is a compact portable system battery operable
> for at least a decent while (10+ hours). A NON-PC toteable
> of sorts. Display an LCD 80characters a line, 48 lines and old
> monochrome non backit LCD(the latter style Dell used).
> The application I'm doing for it is a small database
> for logging ham radio contacts. The log file for a field day
> stint (24hours) is typically under 500 entries and storage
> requirements is maybe 50Kbytes for data. This is not the only
> use but by far the most interesting.
> The basic 1802 engine is Bob's EELF, the switches and lights
> free version of ELF2k. It's soo tiny. For those that are not
> familiar the 32kb Eprom used on it or the ELF2k has TB,
> Forth, Bob's monitor, Edit/asm, sedt, minimon and BIOS for
> ELFos. With all that there's still more than 6k unused in
> the eprom. Also as a result there are a metric trainload
> of callable routines. It's really sweet.
> Add to the EELF a ELF2k-disk add on board and even with out the
> CF card you add a real UART, TOY clock and Cmos ram for storing
> a few parameter bytes plus the IDE/CF interface thats pretty
> flexible(usable for other things).
> So all I need is not really an OS but a filesystem to do disk
> like operations like open, close read, write, delete, rename
> files on some media. That's a small subset of what ELFos is.
> The rest of the IO is already there to support the rom based
> software. Also the media I'd like to use will be 128kx8 rams
> and 28F010 Flashrom (eeprom) as a fake for a disk. Two of
> each of those is 256k or eeprom and ram, enough for the app,
> utilities and loose storage.
> So if I can pare down the filesystem (kernel) of the ELFos
> and make it romable as well it just might find a home in that
> Eproms 6k hole. I do want a file system thats more than dump
> and tag. So a flat directory big enough for 64 or 128
> 8.3 names plus a scatter/gather allocation scheme is enough.
> I don't care if storage devices over a 1mb are too big for
> it either.
> The other thing I have to do it modify the IDE driver in the
> bios for my bizzare storge use rather than CF. That's
> fairly straight forward task to take out the unneeded
> I forgot to mention before, CP/M with utilities supplied
> was about 160k total apps and the CCP/BDOS/BIOS was
> typically under 8k. The basic command processor could
> TYPE, REName, ERAse, DIRectory, SAVE. If you wanted to
> do other things that was the utilities (ED, Stat, PIP,
> ASM, DDT, LOAD, sysgen, Movecpm, Dump). Of course with
> some 20,000 programs (most all free back when and still are)
> out on the net theres enough to fill most media if that
> your goal.
> > --jc
> > Allison Parent wrote:
> > > Thanks for the info but thats really not quite what I was
> > > looking at. The utilities due to the lump size (granularity)
> > > do eat space but the LAT table if big and other aspects make
> > > for a big footprint on disk and in ram. Elfos is a big os
> > > and I need smaller.
> > >
> > > I'm considering either changing the kernel for a lump size of 1
> > > sector (256 or 512bytes) or starting from bits and peices and
> > > writing a smaller OS without subdirectories and block allocation.
> > >
> > > Humor me. What I'm looking for or may build is an OS that is
> > > flat directory and sized for small "disks" in the 200-800kbyte
> > > range. File structure must allow for scatter/gather space
> > > allocation. The idea around this is that lest wasted "disk"
> > > space as in I dont want to use 4k for a 190byte file. Also
> > > I dont want to allocate more LAT table than needed as that eats
> > > useable device space as well. A ram footprint of around 4-6k
> > > max not including any rommed portions. The os needs only to
> > > let me do block file IO and Character IO to console. The only
> > > utilities I need are minimon, Delete, DIRectory, Type(a text file)
> > > and rename. Anything else like file copy would be transient
> > > loaded program. I need fewer features.
> > >
> > >
> > > Allison
> > [Non-text portions of this message have been removed]
- You made me think about it. So I took some time and did a bit of
research. Some of it in my old project files.
--- In firstname.lastname@example.org, Lee Hart <leeahart@e...> wrote:
> Lee Hart wrote:
> >> I've found that 1802 programs are usually smaller than their
> >> equivalent for other CPUs.
> Allison Parent wrote:
> > Call be sceptic on that. A lot of the code I've been reading is
> > bigger. I have seen TB for 8080 that was quite tiny...
> The smallest 8080 Tiny BASIC I've seen was 1.5k, but took some
> drastic measures such as all math being hexadecimal, no parentheses,
> and no operator precedence. 8080 Tiny BASIC with the same features
> as Pittman's was 2.5k bytes. The 1802 version was 2k bytes.
Found a copy of MINOL, 1.75k 8080 Basic. Interesting beast in that
the largest numbers are 255 (decimal) but it did include an array
with a dual address (H,L). Interesting in the same respect as
Chip-8 as an example of a small language that is still useful.
However, when it come to full featured Tiny Basics the 8080 and 1802
run neck and neck with maybe the 1802 being a few bytes better. One
has to resort to 6502, z80 and 6809 to do better for size or speed.
While I expressed disbelief I'm overall still impressed by 1802. I
looked back at the code I did around 1982 for a smart FDC using 1802
dma (plus2716/2116/765) design and noticed that while the oddball
the instruction set is not as inefficient as originally thought. I
had not looked at it in 20+ years but it's still running. I also did
an 8085 and 8049 version of same and all run about the same size code
for and identical task (it had to fit in a 2716).
> Pittman's opinion was that the 1802 was the most memory-efficient of
>all the contemporary CPUs. I have to agree; I've done a lot of
> assembler for both the 8080 and 1802, and the 1802 wins. My IDIOT
>monitor is just 512 bytes, and that includes a bit-banger software
>UART. 8TH (a version of FORTH) was under 4k bytes.
I'd say it runs par though doing it as 8080 required a real attack
mentality to fit it. Moving to 8085 makes it easier especially if you
use the ever present but "undocumented" instructions. But, they still
> The 1802 certainly loses on speed, however. It takes more clock
>cycles to do most tasks, and given that its clock speed is similar
> to contemporary CPUs (8080, 6800, 6502, etc.), it is always slower.
I looked at it with a eye to 1980 and it was par with 8080(2mhz)
and z80 (1.7mhz TRS80). What didn't happen is unlike the 8085 at
6mhz and z80s (flavors to 33mhz!) the effort to move 1802 to new
CMOS technologies that give us superfact sub 10ns static rams.
An 1802 at a mere 2.5x faster (8mhz crystal) would be faster than
8080 hands down and if current CMOS design were applied there is no
reason why it could not run at 32mhz(instruction rate of 4MIPs!) or
I'd state that I stopped using 8080 in 1976 for three reasons.
Slow, 2mhz wasn't enough. Three voltages and two support parts
needed due to the 12v clocks and multiplexed status on data lines.
This is where the 1802 does well, CMOS low power, easy to use
and it's easy timing. The 8085 and Z80 were much friendlier parts
that had better features. The small differences between the 8085
and 8080 are enough to give the '85 enough advantage to make it a
good part. Better than 1802, in 1980 it's have to say it's only
> The 1802 is more like RISC or microcode; you tend to see certain
>pairs of instructions frequently used to build more powerful
> instructions. If you are trying to build "standard" programs,
>this is a nuisance. But if you can re-think your problem to suit
>the instruction set, you come out ahead.
Agreed. When I put on the RISC hat and apply it it does well. The
big pain of programming it is it's hard to program optimally. For
1980s compilers the code would likely be very poorly optimized but
modern cross platform compiler technology would do better. By hand
it's possible to do well.
The 1802 stands up well over time. It's in the pack with 8085, Z80,
6502 and PDP-8 derivitives. Like the PDP-8 the 1802 has a uniqueness
that makes it worth knowing and understanding.