Menu
▾
▴
#2 16K GrfDrv Discussion
On Aug 23, 2007, at 10:50 AM, Robert Gault wrote:
Boisy Pitre wrote:
Robert,
I've made further analysis available via the bug tracker. Please read my findings re: F$FreeHB. There's still a question, but there's no doubt that the F$FreeHB system call itself is working correctly.
I'm close to marking this bug as closed. In short, this 16K grfdrv in 6809 appears to be a problem with bootfiles passed a certain size.
You have found ways to monitor the OS that I have not. Let's get to common ground so I can confirm what you have found and agree on certain data.
Starting with grfdrv, how are you defining it's size? The level2 6309 version is 8164 bytes (decimal) while the 6809 version is 9021 bytes (decimal). Is 16K meant to mean that the 6809 version requires 2 MMU blocks as it is more than 8192 bytes?
Yes. "16K GrfDrv" simply means that GrfDrv is > 8192 byes, and thus requires two 8K MMU blocks to accomodate it.
Are you using MESS exclusively for debugging or some modules within OS-9? Using MESS, I find it almost impossible to find any module in memory. I can't find a way to Poke the MMU (or any other memory byte) to change the 64K which the MESS memory map will display.
When you say you have placed breakpoints in cowin or grfdrv, how are you doing it.
I am using the debug version of MESS exclusively; no other method. Here's how I do it, for example, in cowin:
1. I assemble cowin on the command line, adding the -l option, and look at the instruction offset in the output. So lets say I want to break at cowin's Init routine. Here's the relevant output:
00179 *
00180 * Initialization routine
00181 00F9 3460 Init pshs u,y Preserve r
00182 00FB FC106E ldd >WGlobal+G.GrfEnt Grfdrv the
As you can see, Init is $F9 bytes from the start of the CoWin module.
2. I then boot into NitrOS-9 to discover the offset of CoWin relative to the block it is loaded in. mdir -e gives me the output:
1 55F9 1F56 C1 0 r 0 CoWIn
So CoWin resides in MMU block 1 with an offset of $55F9
3. Lastly, I use pmap to see which segment of the system's 64K address space that block 1 resides in. Pmap shows that the segment is '67', or $6000-$7FFF
4. I do the math as follows:
$6000 + $55F9 + $F9 = $B5F9 + $F9 = $B6F2
5. I restart MESS and type the following in the debugger:
bpset b6f2
g
The first line sets the breakpoint, the other line tells to debugger to GO and the virtual machine starts.
As you can see, this is a bit of a long winded way to do things. A simpler way is just to insert the following pseudo-instruction into the source code at the desired point you want to break at:
emubrk
This generates a special opcode that the MESS debugger recognizes, and the debugger is invoked when it encounters it. mamou understands this pseudo-opcode and generates the appropriate bytes for it.
===========
Using your patched files, I have created boot disks with padded os9boot files so that they are the same length for 6809/6309 and over the 7902 byte limit. The 6309 will start a window from a term32 screen while the 6809 will respond with error 237. Both use shell i=/w7& to attempt to start the window, an 80 column hardware text. It does not matter whether grfdrv is preloaded into memory.
Changing the routine in grfdrv to mark <$8D-$8E with $333E or with "the DAT image of myself" (see source code) does not cause any change in behavior for the 6809 version.
It may be that I have not adjusted this code in grfdrv correctly by not correctly interpreting the 16K issue. Perhaps because grfdrv is >8192 bytes, the source code should be
IFNE H6309
ldd a,y Get the DAT image of myself
std <$8B Save it to new task
ELSE
leay a,y
ldd ,y++
std <$8B
ldd ,y get next two bytes if 16K
std <$8D
ENDC
rather than having the last two lines commented out. But as I've said, it does not seem to matter when running NitrOS-9.
That is correct. Because of the additional MMU block that the 6809 grfdrv requires, the additional two lines are necessary.
========
Are you implying that the 6809 version of grfdrv must be decreased in size to be <8192 bytes?
I'll get to that in your next email.
--
Boisy G. Pitre
Email: boisy@boisypitre.com
Web: http://www.boisypitre.com/
Phone: 337-781-3570
Discussion
Anonymous
Logged In: YES
user_id=42881
Originator: YES
On Aug 23, 2007, at 11:05 AM, Robert Gault wrote:
I should have added with my last question:
"Are you implying that the 6809 version of grfdrv must be decreased in size to be <8192 bytes?"
No, I am not implying that. That's not possible without some major optimizations. The reason for the size discrepancy vs. the 6309, I believe, is because the same amount of things are being done in the 6309 version with less code. A threshold has been crossed (8192 bytes) for the 6809 version that is not the case with the 6309 version.
There has been talk for sometime about having a grfdrv that would reach beyond the traditional 8192 byte limit. Such a larger grfdrv could do a lot more in terms of window resizing, vector fonts, etc. However, we run into some limitations like what we're seeing here. There may be ways to work around these limits, or better design approaches that can be taken to get around these limits.
But for now we have this issue. GrfDrv for 6809 is > 8192 bytes and is probably not easily scrunched down below that. If we can find a way to prevent the linking of grfdrv from occurring, then the error #237 will go away. Right now, the only reason for linking grfdrv in is to call its init/term routines from cowin/cogrf. Other than that, it appears that control to grfdrv happens through Flip0/Flip1 routines in the kernel, which give grfdrv its own address space and DAT map.
Logged In: YES
user_id=859353
Originator: NO
First, I've added some comments to the bug on starting windows from a vdg term. To my way of thinking, there is clearly more than just the os9boot file size as a problem because using a boot disk identical to one which has the window opening bug and changing nothing more than term from term32 to term80, makes the bug go away. The 16K grfdrv issue brought this to our attention but it seems to me there may be two root causes to this problem one the os9boot file size, the other as yet unidentified.
Keeping cowin from linking to grfdrv (I think that's what you meant, Boisy) is interesting and I have not yet given it any thought. Would that really enable the system to find room for grfdrv regardless of it's size? Reducing the size of grfdrv below 16K (6809 code) may not be that difficult (see my recent comments in the bug report) but that seems like a stop-gap measure.
I think an interesting test would be to see what if any os9boot file size limitation is present when booting into a term80 window. That should indicate whether work on reducing grfdrv or addressing the linking issue is worth following up.
Logged In: YES
user_id=42881
Originator: YES
First, I've addressed your concerns about the bug not being fixed in the VDG bug report.
I think looking for ways to reduce GrfDrv may be a futile effort, especially in light of efforts to eventually bring more functionality to the windowing system. At some point, it would be great to explore the movable, resizable windows that the Upgrade has, and bring those features into NitrOS-9. I would suspect those features alone would push 6309 grfdrv above the 8192 byte limit.
As for somehow reengineering grfdrv so that it doesn't have to be linked, I'm not sure how we can avoid it. The reason grfdrv is linked into the system map initially is so that CoWin can jsr into the grfdrv init routine. That requires grfdrv to be in the same address space as cowin. Once that initialization is completed, it appears to me that grfdrv never has to be F$Linked (i.e. mapped into system ram) again, as it is called via the Flip0/Flip1 vectored routines in krn.
Surely, a lot to think about!
Logged In: YES
user_id=859353
Originator: NO
I think I follow your reasoning on grfdrv vs system space, but why is there still not a space issue? Is it because the other modules that have been loaded as part of os9boot have not been used for anything? If that is true, then the 237 error seen with grfdrv may turn up with some other module when its turn to be used comes up.
Logged In: YES
user_id=42881
Originator: YES
Early on in the boot process, other modules haven't had a chance to "come alive" and start taking up system memory. Think about what has happened once the shell prompt appears on your screen. Paths have been opened and closed multiple times, drivers have come alive, all of these activities are allocating and reserving system RAM. If grfdrv is given a chance to load and link into the system map well before all of this has occurred, it has a better chance of finding 64 free contiguous pages than if you wait until you're sitting at a shell prompt and typing iniz /w1.
Other than grfdrv, I cannot really think of any other module that gets loaded AFTER bootup and gets mapped into the system space, so I think grfdrv is the only module we have to consider here. (Well, there is the case where you may want to load and use a driver and descriptor after the system has booted. This isn't recommended for long-term use since it does waste precious system space.)
Keep in mind that we would hit this limit with an 8K grfdrv if we made our bootfile 40K+. There's only so much system RAM available, and the more you use up for the bootfile, the less there is for everything else. Still, changes made to thinks like the boot module over the last day or so has given us back a couple of extra pages, and there's probably even more optimizations that can be done.
Logged In: YES
user_id=859353
Originator: NO
Let me propose this "wild" idea. Why don't we force NitrOS-9 to reserve 64 contiguous pages of system memory so that it is available for grfdrv.
For example, you start from term32 with the system reserving 64 contiguous pages. These pages would not be released until the end of the Startup file by a special command (which we would need to write). Users that will not start any grfdrv windows will never notice the difference because the reserved memory will have been release. Users that want a term32 but also want 40/80 column windows would remove the Release command from the Startup file, start a shell in a window, and therebye have access to the contiguous pages.
This is just a concept and I've made no attempt to think out how it could be made to work. It sounds as though it could solve this issue of the 16k grfdrv.
Of course the above is not the only work-around. I posted to the Coco list some time ago the following suggestion. Boot into term40/80, start a new 40/80 column window with a shell, kill the shell in term, switch to the new window, and deiniz term. Then use xmode to convert term to 40/80 columns, and start a new shell in the converted term. This route can be put in a script and also gets around the problem of having a term32 for old programs while still having access to windows.
Logged In: YES
user_id=859353
Originator: NO
Here is a "solution" that does not solve but bypasses the problem of how to have a term32 and still use grfdrv/windows regardless of the size of the os9boot file (or at least reasonable limits.) There is no reason why a user must boot into term!!!
I just changed init (the brute force way, ded on os9boot) so that /TERM was altered to be /W7. I then added a line to the startup file, shell i=/term&. The system then happily booted into /w7, a default 80 column window, having a term32, and an os9boot file of $7B9C bytes.
This seems to be the simplest method for eating your cake and having it too.
Following up on this same thread, I was bitten by this problem again when making DriveWire boot disks for 6809l2, which was failing. It turns out that the i2xot*j message that the kernel was putting out was misleading to a degree, so I modified level2/modules/kernel/krpn2.asm to simply crash on failure to open the /Term device, and not attempt to F$Boot again. WIth this change, the I$Open in krnp2.asm failed and I could see that the error code was *m (Error #237 - RAM Full). This triggered in my mind the 16K grfdrv problem.
The solution was to remove covdg.io from the DW3 bootfile and the machine booted fine.
I'm going to leave krnp2.asm to crash on failure of opening the /Term device. I don't see any reason for a second attempt at F$Boot currently.
Wow, this subject is old enough that I've completely forgotten it. I won't try to answer most of this because I'm not sure what is still relevant. Debugging in MESS is the easiest approach and is fairly simple, even without using emubrk. As I frequently update MESS, emubrk would need to be added to each revision.
Well, my procedure is to make an educated guess at the source of a problem in OS-9. Then I just insert a new line, ex. loop bra loop , into the OS-9 code, compile the project, and use the new disk for testing. With the MESS debugger active, I start whatever OS-9 process is giving a problem and reenter the MESS debugger after OS-9 stalls out.
I will immediately see where the loop bra loop is located and can use that location for a break point in MESS for future monitoring of normal code without the loop.
By opening a memory window in the debugger, I can easily find the start of the module. If it is a os9boot file module, it will never move so you know where to set MESS debugger break points.