fujinet Memory buffer placement for N: handler.

[tschak909]

Hey guys,

 

Sorry, slightly stumped.

 

Thanks to @flashjazzcat's excellent ultd example, I was able to make the N: handler self-relocatable, without the need of a separate loader segment. This has allowed the N: handler to now work under disk-based SpartaDOS, and other CP's that do not exactly follow the binary loader behavior in the DOS 2 mini-DUP. 

 

However, the relocation seems to have slipped the alignment of the 256 bytes used for both the RX/TX buffer (split down the middle at 128 bytes), and I'm not sure why.

 

At the end of the day, I just need to load the handler in, and adjust memlo by driver end + one page, so that the buffer sits after the driver code.

 

While I can use e.g. (ptr),Y in the init code, I can't reliably use it in the CIO handler code itself, so am not 100% sure how I can fix the relocation of the RBUF and TBUF labels, so that they sit exactly at $00 and $80 offsets within the target page.

 

(pardon if there is something obvious, again, I do not write assembler all the time, and literally have been guessing and questioning my way through writing this whole thing, and it's almost ready.)

 

The current handler code is here:

https://github.com/FujiNetWIFI/fujinet-nhandler/blob/relocate-try-6/handler/src/ndev.s#L116

 

While I am indeed curious as to why my page alignment is being shifted, I'm honestly more interested to see how I can just side-step the problem..

 

-Thom

[phaeron]

1 hour ago, tschak909 said:

While I am indeed curious as to why my page alignment is being shifted, I'm honestly more interested to see how I can just side-step the problem..

I'm not sure what you would think would preserve the page alignment. The assembler's ALIGN directive only causes it to insert padding to hit the required alignment based on the current assembly location. If you then relocate the code at runtime in a way not compliant with that alignment, it can't be preserved.

 

The pure way to solve this is to separate out RBUF and TBUF into a separate segment, which is allocated with the requested alignment. The relocation routine then needs to keep track of two base addresses and use the appropriate one when relocating the references to those symbols. The easiest way to do this is to use a second relocation list.

 

However, if you think about it, there's really no point. In order to align RBUF/TBUF you need to allocate additional bytes from MEMLO. Instead of placing that padding between RBUF/TBUF and the rest of the code, you could place it at the beginning of the entire module. This means that there is no advantage to treating those buffers separately over just using page alignment for the entire module -- the same amount of alignment padding is wasted regardless. The easiest way to solve this is therefore just to round up MEMLO to the nearest page boundary before beginning relocation. You would also no longer need word relocations as only the high byte would need adjustment.

 

Looking at the code, I'm not sure why these buffers need page alignment anyway. If the worry is page crossings, there's no need for both to be page aligned, as 128 byte alignment with a split between them would be fine. Furthermore, misaligning the buffers only costs one cycle on an indexed load -- there is no additional penalty for a page-crossing indexed store.

 

[tschak909]

ok, so that must mean that something else is causing my subtle problems when getting/putting bytes. urgh.

 

-Thom

[_The Doctor__]

@tschak909

 

placing the combined buffer at the begining sounds right, and splitting the buffer does seem unnecessary a full 128 bytes for each buffer correct? not short a byte by sharing one (I've seen this happen)

 

If what you are saying is true... this works fully when aligned within a boundary but is failing when it crosses, as in you've observed this.

 

The Sparta crew do a good job of keeping alignment and management within a bank and boundary, I'd tap one of them to look it over.

 

try to pad the buffer with 64bytes before as well as 64 bytes after, move the buffer and padding to the beginning and don't split it apart. That's how I'm thinking, I'm not sure why but I keep thinking about something I ran into with Sparta, Express, Action working together with relocatable code. Can't hurt to try it. If it works you could try smaller padding bytes until it breaks. I doubt it would need more.

 

don't change any of the buffer pushing or pulling code to make it aware of the extra bytes in that you would leave access starting after the first 64 bytes in

Edited July 8, 2020 by _The Doctor__

[tschak909]

days like this, I wish I could use the cassette or the FP line buffer ($0580) ....

 

-Thom