dbgmon - understanding the environment - questions about romwbw

[wwarthen]

Sounds good Phillip.

There is no specific schedule for producing release binaries. I just do it when it feels like things are fairly stable. I will produce a new pre-release with binaries in the next couple days.

-Wayne

[wwarthen]

I think the questions that were brought up in this discussion have all been answered or addressed, so I am going to mark it closed. Please do not hesitate to ask additional questions.

[wwarthen]

Wayne,

trying to unwrap your quite complicated system, but I think I've gathered some facts that I'd like to test for correctness, and some questions about things that I don't fully understand.

Probably too complicated! :-)

After booting into the dbgmon (M at boot), it is running from 0xC000?
And, its formal size is 0x1000 so finishing at 0xCFFF ?

Correct.

It looks like it is finished by 0xC960 or thereabouts, with the rest slack space?

Correct.

Is the CP/M CCP/BDOS/BIOS pre-loaded from 0xD000?

No. After HBIOS initializes it's stub at 0xFE00-0xFFFF, it runs the romldr module. At that point, neither CP/M nor dbgmon are loaded. The romldr will load either CP/M or dbgmon (or any of the other options) depending on your selection. Many years ago when dbgmon was first created, it was intended that it could be loaded at the same time as CP/M which is indeed why it loads at 0xC000 to avoid overlapping with CP/M CCP/BDOS/CBIOS. However, there is no longer such a scenario.

Is the ROM switched out when the dbgmon is running, and therefore the code from 0x000 to 0x8000 is a RAM copy of HBIOS?

Short answer: yes. Long answer: During HBIOS initialization (prior to dbgmon or anything else running), the HBIOS code is copied from a fixed image in ROM into a dedicated page of RAM. HBIOS cannot run directly from ROM because it has embedded variables. At the end of HBIOS initialization, the bottom 32K bank is switched to the dedicated application bank (TPA in CP/M terminology). So, at the point that dbgmon gets control, it has from 0x0100 to 0xBFFF as working RAM. The HBIOS code is only switched into the bottom 32K by the high memory proxy when an HBIOS API call is made.

Or, is it something else, like a number of applications NASCOM BASIC, TASTYBASIC, EASTER EGG (Mandelbrot), or CAMEL FORTH?

dbgmon works exactly the same as these applications. As far as HBIOS is concerned, dbgmon is just another application/OS.

Is it certain that the code from 0x0100 to 0xBFFF not used from the dbgmon?

Correct. dbgmon uses only 0xC000-0xCFFF. Although, it does rely on the HBIOS proxy at 0xFE00-0xFFFF.

On application exit assuming dbgmon is still existing, is the best thing to do to jump to MON_LOC+3 where JP UART_ENTRY is found?

Hmmm... actually, it would be more appropriate for dbgmon to set up a restart vector at 0x0000 so that any application running under dbgmon could use JP 0 or RST 0 to restart. I will implement that very shortly.

If dbgmon is overwritten, is it simply best to set to bank 0 and RST 0 for exit?
Or, is there something nicer?

If dbgmon is overwritten, that would be the only possible way to exit.

IF RAM is already switched in, and the Page0 is correctly loaded, things are pretty straightforward. For the "app" startup model for z88dk, I am planning to use 0x0100 as the origin, and through to 0xBFFF for the combined binary/data sections. If the monitor is finished by 0xD000 I could leave a hole in the allocation and continue through to 0xFDFF when the HBIOS shim starts, but I don't see a need to get fancy right now.

The above is exactly correct. I am contemplating relocating dbgmon to 0xF000-oxFDFF which would provide even more application space. Not sure yet.

Or, I could just have the data/bss sections start at 0xD000 through to the shim.

You could do that, but better if I just relocate dbgmon and then you would have the entire 0x0100-0xEFFF memory space.

When triggered by the dbgmon to run at 0x0100 the "app" would decompress its data sections, and reset the bss sections, and would run using the hbios function call at RST08 or 0xFFF0.

Yes.

Using additional banks would be on the "to do" list for later.

OK

IF ROM is still switched in and the dbg monitor is running while looking at ROM up to 0x8000, then somehow I'd have to get the RAM switched in, before the Hexload program could function to load the lower addresses (but I don't think this is the case).

Above is not the situation, so I guess it doesn't apply.

Great questions. Let me know if you have any more.

Thanks,

Wayne

[feilipu]

Wayne,

thanks.

I've got the basic support in place now, through PR #1324. This works for the two serial ports. Now you've got #54 in place, I'll add timing shortly. Also, connecting to the ROMWBW disk drivers is a to do shortly.

I had some serial port overflow problems with the dbgmon hex loader, so I might look at how to speed it up, or make it more robust too. The CPM implementation doesn't seem to have the same issue, so it is not coming from HBIOS. Another thought to do.

How / when you produce release binaries for platforms?

Cheers, Phillip

[feilipu]

I'll have a bash at the RC2014 standard platform too, and add a subtype romwbw to that z88dk target once this work is done. I don't have a CF interface card, so might have to rely on a bit of guesswork with respect to the CF interface. But if it works for SCZ180 HBIOS drivers for SD cards, then there's no reason why it wouldn't for RC2014 on CF.