[Coco] Portal-9 info

[Robert Gault]

Roger Taylor wrote:

> I've been in touch with the author of HLA about my techniques for 
> handling object-oriented programming in assembly, and much to my 
> surprise, he totally agreed with several things I am doing from the 
> assembler to help support this type of concept.  It's really just basic 
> stuff to most people, but I have never done structure support in 
> assembly, so I had some questions to him about my approach on things.
> 
> CCASM allows structures to be created where you can later access the 
> fields as:
> 1) direct addresses
> 2) offsets
> 
> shape   struct
> width   rmb     2
> height  rmb     2
>         endstruct
> 
> This creates a simple data structure.  It sort of mimicks the namespace 
> directive in that you can access the fields by using:
> ldd     shape.width
> or
> ldd     shape.height
> 
> Only, CCASM uses : instead of . for the separator.
> 
> If you have copies of the structures in memory, or objects, you can 
> access the same fields using the indexed instructions, like:
> 
> ldu     object1
> ldx     {shape}:width,u
> ldy     {shape}:height,u
> 
> ldu     object2
> ldx     {shape}:width,u
> ldy     {shape}:height,u
> 
> Ofcourse, the above is not even close to being what I would call real 
> OOP.  When I started on the object-oriented programming stuff and 
> allowed Classes to be created, I basically just added some more fields 
> above the data fields, which are pointers to procedures and methods for 
> that object.  I am now updating CCASM to automatically allow a structure 
> to be created based on another structure type, like:
> 
> circle  struct  shape
> box     struct  shape
> 
> This will clone the original structure and give the same fields to the 
> new type, whether it's a simple data type or a Class type.
> 
> This is leading up to a "class" psuedo-op which is on the way.  It will 
> work just like struct only it will do some automatic stuff that 
> currently is being done by brute force in my OOP example.
> 
> This is getting fun and I am already creating classes you'll be able to 
> include into your programs like:
>         include graphics_class.asm (invoke any mode, clear screen, plot 
> pixels, peek @ pixels, draw objects, etc.)
>         stdio_class.asm (keyboard, serial, joystick?)
>         console_class.asm (printing to the text screens, etc)
> 
> With these and CCASM's upcoming "call" command which pushes it's 
> parameters to the stack before calling the address, good things are on 
> the way.
> 
> It just keeps getting easier and easier to write assembly language 
> programs.
> ------------------------------------------------------------------------
> /Roger Taylor
> 
> 
> /
> 
> 
> ------------------------------------------------------------------------
> 
> 
The structures you describe are present in Disk EDTASM but are called 
macros. In fact, the EDTASM macros will take variables so that the same 
structure, block of code, whatever you want to call it, can have 
different values every time it is called.