Re: LZ:83 ASM
[Prev][Next][Index][Thread]
Re: LZ:83 ASM
On Thu, 29 Aug 1996, Rob Taylor wrote:
> > A shell will make it transparent to the user. They can just run
> > the program and not have to think about compressing and decompressing.
> > Also, I think there'll be some other advantages to a shell. While
> > playing around with the little program I'm working on I thought of
> > a couple of things. I haven't had a chance to touch it for a couple
> > of weeks so I don't remember what they are now.
>
> problem with a shell.. you'd have exacly the same problems as zshell
> as for _where_you run teh programs from... (as far as i know, theres
> no way fro an assembelr program to call anotehr assembelr program,
> and you can't copy to the start of memory for thousands of obvios
> reasons..
Not at all. The shell can be a valid 83 assembly program, which
can reserve space for work area, up to available memory. That work
area will always be contiguous and will start at the end of the 83
asm program so the program always knows where it is. That can be
the starting point for the program it loads.
As for transfer of control, the shell can use a call to the starting
address of the program it loads, and the program can return control
to the shell with a ret. This part is very simple on the 83.
If you don't have an 83 yet, the format for a prorgram is all the
hex codes in ASCII, followed by the word End followed by a 4 digit
memory size for work space allocation (4 hex digits), followed by
the word End again. The allocated workspace begins after the last
byte of the program. The program knows it's starting address and
can calculate it's length to get the starting address of the
allocated space. That number wont ever change until the program
changes.
Since the program here is the shell, it can be padded to include all
possible expansion and all applications can be written to load in
the resulting address, which will never change.
The padded area could be fairly small since this shell isn't
likely to grow a lot.
> > There are all kinds of ways to do it. A shell isn't essential. But
> > I think it'll be a good approach. And this should be a pretty small
> > shell. It'll need to manage the files and compress and decompress.
> > RLL compression is pretty simple and doesn't need a lot of code.
> > Huffman encoding would be better but take more code. It just might
> > save more space than it needs, though. I've never written a Huffman
> > routine, but I think I know where there some Z80 source for one. If
> > anyone is interested in it, let me know and I'll see if I can locate
> > it.
> >
> > By the way, for the code thiefs among us (such as me) is everyone
> > aware that there is a huge collection of CP/M Z80 and 8080 source
> > code on oak.oakland.edu in (I think) /pub/cpm? If you haven't
> > seen it you'll be amazed at how much there is. Most of the programs
> > wouldn't be worth porting to the TI, but some might be. But there
> > are all sorts of routines there that can be used, such as the
> > compression routines and graphic algorithms for 3d animation, etc.
> > It's worth looking at.
>
> i'll certainly take a look.. I think i've got soem code for an
> assemberl from there, but I don't think I'll have time for a while..
I've just found source for a monitor that would be pretty easy to
port to the 83 or the 85. It's not in electronic form. It's in an
old book on 8080/Z80 programming. It's printed in both 8080 and Z80
code.
I was planning to turn my hex viewer into a monitor, but I might take
a look at porting this thing instead. Even if I do write my own I'm
going to steal a lot of code from this. It has some excellent ideas.
Barry
References: