Image Map Image Map
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 37

Thread: FLEX for the 6502 or building a compatible operating system...

  1. #11

    Default

    Quote Originally Posted by resman View Post
    I didn't know anything about FLEX, so I looked it up. The first thing that jumped out at me was that the company, Technical Systems Consultants, was from my home town. So it *must* be good.
    Would that be West Lafayette or Chapel Hill. They moved during their time.

    Quote Originally Posted by resman View Post
    As for dispatch, everything is going to be a compromise. Having up a jump table in low memory is probably going to chew up some memory used for something in the system. Low memory is used for so many things in 6502 designs. Using a single entry point, whether BRK or vector, relieves a lot of pressure, regardless on how you implement the kernel. How you pass parameters is an interesting design decision. A pointer to a parameter block or inlining parameters both have pluses and minuses.

    Another thought, are programs re-locatable or is there a fixed address where they run? Again, because 6502 designs use low memory for so many things.
    The FLEX binary file format contains load addresses. They are not like CP/M .COM files which are nothing but a flat array of bytes to be loaded at 100h. But they are not relocatable either; absolute addresses are determined when the file is created.

    By low memory, I am talking about page 2 and up for the purpose of having things in the same place on every system regardless of how much RAM is installed. On the 680x, the zero page is merely fast memory. On the 6502, there are essential things which can only be done with zero page locations. One thing I really like about FLEX on the 680x is that the zero page is left for programs to use; the system does not claim it. The 6502 zero page is too precious to waste for most system variables or jump tables. Since FLEX is usually dealing with slow disks or an even slower human, it does not really need the added speed of zero page. The only need is to dereference a pointer and FLEX only needs a few of those.

  2. #12

    Default

    Quote Originally Posted by commodorejohn View Post
    Yeah, that would work. It might be nice to have add-in routines fill down from the top of memory so you could have an arbitrary number of them while the program resides at a fixed address, but then you'd need a relocating loader for them anyway...the 6502 is not great for position-independent code...
    There is a trick I learned while working on CP/M system software: build the code ORGed at two different locations and compare them. The bytes which differ are the ones needing adjustment when the code is relocated. Store that information in a bitmap as input to the relocator. That is how things like MOVCPM works.

  3. #13

    Default

    Quote Originally Posted by BillGee View Post
    Would that be West Lafayette or Chapel Hill. They moved during their time.
    West Lafayette. Purdue EE grads. Can't really blame them for relocating, though. I left as soon as I could, too. I like to say: "Indiana is a great place to be from".

    Quote Originally Posted by BillGee View Post
    The FLEX binary file format contains load addresses. They are not like CP/M .COM files which are nothing but a flat array of bytes to be loaded at 100h. But they are not relocatable either; absolute addresses are determined when the file is created.

    By low memory, I am talking about page 2 and up for the purpose of having things in the same place on every system regardless of how much RAM is installed.
    Case in point: page 2 is used for the input buffer on a lot of machines (assuming you want to take advantage of existing ROM routines). Memory mapped video likes to live around page 4 on many, if that is a concern.
    Quote Originally Posted by BillGee View Post
    On the 680x, the zero page is merely fast memory. On the 6502, there are essential things which can only be done with zero page locations. One thing I really like about FLEX on the 680x is that the zero page is left for programs to use; the system does not claim it. The 6502 zero page is too precious to waste for most system variables or jump tables. Since FLEX is usually dealing with slow disks or an even slower human, it does not really need the added speed of zero page. The only need is to dereference a pointer and FLEX only needs a few of those.
    Good. Looking for available holes in ZP is always a pain. A proper OS would leave it to the app, saving and restoring those it uses.

  4. #14

    Default

    Quote Originally Posted by resman View Post
    Case in point: page 2 is used for the input buffer on a lot of machines (assuming you want to take advantage of existing ROM routines). Memory mapped video likes to live around page 4 on many, if that is a concern.
    For greatest portability, I am staying away from functionality in various ROMs.

    FLEX for the 680x allocates 128 bytes for the input buffer and another 128 bytes for the stack.

    It looks like a natural to me for them to share page 1. With the buffer growing up from $100 and the stack down from $1FF, the chance of a collision is very low. Only a program run wild is likely to cause that.

  5. #15
    Join Date
    Dec 2011
    Location
    Dallas, TX
    Posts
    335

    Default

    Quote Originally Posted by BillGee View Post
    There is a trick I learned while working on CP/M system software: build the code ORGed at two different locations and compare them. The bytes which differ are the ones needing adjustment when the code is relocated. Store that information in a bitmap as input to the relocator. That is how things like MOVCPM works.
    That's a great idea.

    Instead of a bitmap, you could store an offset to the first relocatable address. That address would contain a pointer to the next address, and so on, like a linked list. That takes up much less space than a bitmap, and the code is much simpler as well.

  6. #16

    Default

    You don't even really need a linked-list structure, just a flat table of addresses and offsets (or separate tables thereof) and an entry count.
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

  7. #17
    Join Date
    Dec 2011
    Location
    Dallas, TX
    Posts
    335

    Default

    Quote Originally Posted by commodorejohn View Post
    You don't even really need a linked-list structure, just a flat table of addresses and offsets (or separate tables thereof) and an entry count.
    The advantage of the linked list is that it doesn't take up any extra space (except the 2-byte pointer to the first relocatable address). A bitmap or a table take up a lot of space. And the code to relocate from the linked list is simpler as well.

  8. #18

    Default

    Quote Originally Posted by dfnr2 View Post
    The advantage of the linked list is that it doesn't take up any extra space (except the 2-byte pointer to the first relocatable address). A bitmap or a table take up a lot of space. And the code to relocate from the linked list is simpler as well.
    I have encountered the linked list idea in some object code file formats. The problem is that the links leave no room for the original contents of the item to be adjusted, so to what do I add the load offset? The 16-bit Windows (NE executable) format has a list for the references to each system entry point, such as CreateBitmap. Each NE file has to list all of its imports anyway, so that is not a problem.

    Consider a 6502 example:

    Code:
        lda #1
        jsr DoA
        lda #2
        jsr DoB
    If you link the address of the first jsr to the address of the second; and the address of the second one is 0 to signify the end of the list.

    When is is time to relocate the code, how do you know which one referenced DoA?

  9. Default

    Quote Originally Posted by dfnr2 View Post
    The advantage of the linked list is that it doesn't take up any extra space (except the 2-byte pointer to the first relocatable address). A bitmap or a table take up a lot of space. And the code to relocate from the linked list is simpler as well.
    Not sure I understand this plan, how would you know what address to patch into each location?

    Human68K executables have one of most compact relocation tables that I've seen. There is a pointer to the first location, then an array of 16-bit words (at the end of the binary) that encode the distance from one relocation to the next. There's a special case for distances greater than 64KB, a '1' will appear followed by a 32-bit word. For each relocation the loader simply goes through and adds the load address to the value already existing in the binary.

    For doing relocations on a 6502 system, maybe it would be wise to always load on a 256-byte boundary, and then only the high byte of each address would need to be patched. And maybe the code is relatively small enough that it would be worth changing the Human68K array of 16-bit distances to an array of 8-bit distances (with a special case for longer ones).

  10. #20
    Join Date
    Dec 2011
    Location
    Dallas, TX
    Posts
    335

    Default

    Quote Originally Posted by BillGee View Post
    I have encountered the linked list idea in some object code file formats. The problem is that the links leave no room for the original contents of the item to be adjusted, so to what do I add the load offset? The 16-bit Windows (NE executable) format has a list for the references to each system entry point, such as CreateBitmap. Each NE file has to list all of its imports anyway, so that is not a problem.

    Consider a 6502 example:

    Code:
        lda #1
        jsr DoA
        lda #2
        jsr DoB
    If you link the address of the first jsr to the address of the second; and the address of the second one is 0 to signify the end of the list.

    When is is time to relocate the code, how do you know which one referenced DoA?
    Yes, you are right. That is why I should not be posting before I've had my coffiee

    I do love the idea of assembling twice and comparing the outputs to create a relocatable format. I've never seen that trick before.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •