On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
> On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
>
> > Okay. I am trying to make sure I don't offend you here,
> > but
> > you do know that the OBJ file contains more than the
> > executable code and that even the code it contains
> > may not be in binary format,
> > RIGHT?
> Yes, I know that, but it's mostly binary code and
> here is the fat code in the PDOS/86 kernel:
>
> fat_TEXT CODE AUTO 33f2:0000 0000b222
>
> 45602 bytes. Compiled with Open Watcom.
>
> I checked the disassembly - it is all legitimate code.
>
> It could be the price of the huge memory model, which I
> wouldn't encounter on the 8080.
>
> BFN. Paul.

Last I checked 45602 is still less than 64K (65536).
Did you misread a decimal place?

But that doesn't mean all of that code needs to be in memory all the time.
(As pointed out by others in this conversation). In the old days of small
machines these were called overlays. It is more formally called virtual memory.

On small machines if slows things down but these are hardware solutions.

TTFN
Ed

On Monday, August 14, 2023 at 4:47:21 AM UTC+8, Ed Prochak wrote:
> On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
> > On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
> >
> > > Okay. I am trying to make sure I don't offend you here,
> > > but
> > > you do know that the OBJ file contains more than the
> > > executable code and that even the code it contains
> > > may not be in binary format,
> > > RIGHT?
> > Yes, I know that, but it's mostly binary code and
> > here is the fat code in the PDOS/86 kernel:
> >
> > fat_TEXT CODE AUTO 33f2:0000 0000b222
> >
> > 45602 bytes. Compiled with Open Watcom.
> >
> > I checked the disassembly - it is all legitimate code.
> >
> > It could be the price of the huge memory model, which I
> > wouldn't encounter on the 8080.
> >
> > BFN. Paul.

> Last I checked 45602 is still less than 64K (65536).
> Did you misread a decimal place?

Here is what I originally reported:

this 8086 object code:

2023-07-29 08:22 56,783 fat.obj

almost blowing away the entire 64k possible

Note the word "almost".

> But that doesn't mean all of that code needs to be in memory all the time..
> (As pointed out by others in this conversation). In the old days of small
> machines these were called overlays. It is more formally called virtual memory.
>
> On small machines if slows things down but these are hardware solutions.

Well - is that how CP/M managed to pull off the feat with PL/M?

PL/M does automatic overlays? Or were they manually done?

I guess dropping LFN and FAT32 would save space.

And as I mentioned - this is using the huge memory model.
Although I would have thought that the 8080 with 8-bit
registers and 16-bit addresses would be the equivalent of
huge memory model also.

Although that in itself is another design choice I made - I
wanted my code to be C90-compliant instead of having
"near" and "far" and "huge" keywords everywhere, so I
just chose to blanketly compile in true huge memory model
(all pointers huge). And if that doesn't leave enough room
for apps on an 8086 then upgrade to either a Turbo 186 or
an 80286 or above. Rather than change the OS source code.

I should be able to get another 64k on the Book 8088 by
using the region A0000-AFFFF and simply not use graphics,
but I haven't tried that yet. I'm not sure if I will find RAM or
a hole at B0000-B7FFF. If there is RAM there then I could
switch to using a VT100 terminal and get B0000-BFFFF.
Or fragmented memory would be OK too. But I won't bother
doing that until I have started reusing the kernel's C library
instead of each application having their own.

I think there's a ROM at C0000-FFFFF, without backing RAM
(on the Book 8088), even if it was possible to bank it out.

(note that this was just unrelated comments about the 8086
design - the original question is about 8080 - I'm just not
sure what's going to happen when I take the 8086 and 80386
design and try to implement it on the 8080 - or what the design
should be).

BFN. Paul.

Paul Edwards ha scritto:
> On Monday, August 14, 2023 at 4:47:21 AM UTC+8, Ed Prochak wrote:
>> On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
>>> On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
>>>
>>>> Okay. I am trying to make sure I don't offend you here,
>>>> but
>>>> you do know that the OBJ file contains more than the
>>>> executable code and that even the code it contains
>>>> may not be in binary format,
>>>> RIGHT?
>>> Yes, I know that, but it's mostly binary code and
>>> here is the fat code in the PDOS/86 kernel:
>>>
>>> fat_TEXT CODE AUTO 33f2:0000 0000b222
>>>
>>> 45602 bytes. Compiled with Open Watcom.
>>>
>>> I checked the disassembly - it is all legitimate code.
>>>
>>> It could be the price of the huge memory model, which I
>>> wouldn't encounter on the 8080.
>>>
>>> BFN. Paul.
>
>> Last I checked 45602 is still less than 64K (65536).
>> Did you misread a decimal place?
>
> Here is what I originally reported:
>
> this 8086 object code:
>
> 2023-07-29 08:22 56,783 fat.obj
>
> almost blowing away the entire 64k possible
>
>
> Note the word "almost".
>
>> But that doesn't mean all of that code needs to be in memory all the time.
>> (As pointed out by others in this conversation). In the old days of small
>> machines these were called overlays. It is more formally called virtual memory.
>>
>> On small machines if slows things down but these are hardware solutions.
>
> Well - is that how CP/M managed to pull off the feat with PL/M?
>
> PL/M does automatic overlays? Or were they manually done?
>
> I guess dropping LFN and FAT32 would save space.
>
> And as I mentioned - this is using the huge memory model.
> Although I would have thought that the 8080 with 8-bit
> registers and 16-bit addresses would be the equivalent of
> huge memory model also.
>
> Although that in itself is another design choice I made - I
> wanted my code to be C90-compliant instead of having
> "near" and "far" and "huge" keywords everywhere, so I
> just chose to blanketly compile in true huge memory model
> (all pointers huge). And if that doesn't leave enough room
> for apps on an 8086 then upgrade to either a Turbo 186 or
> an 80286 or above. Rather than change the OS source code.
>
> I should be able to get another 64k on the Book 8088 by
> using the region A0000-AFFFF and simply not use graphics,
> but I haven't tried that yet. I'm not sure if I will find RAM or
> a hole at B0000-B7FFF. If there is RAM there then I could
> switch to using a VT100 terminal and get B0000-BFFFF.
> Or fragmented memory would be OK too. But I won't bother
> doing that until I have started reusing the kernel's C library
> instead of each application having their own.
>
> I think there's a ROM at C0000-FFFFF, without backing RAM
> (on the Book 8088), even if it was possible to bank it out.
>

There was the rom for services. For example, at C800:5 you could find
the low-level formatting program for hard-disks. At the DOS period, to
use it it was sufficient to launch debug.exe and to its prompt to give
the command "G C800: 5" :^)

> (note that this was just unrelated comments about the 8086
> design - the original question is about 8080 - I'm just not
> sure what's going to happen when I take the 8086 and 80386
> design and try to implement it on the 8080 - or what the design
> should be).
>
> BFN. Paul.
>

Paul Edwards ha scritto:
> On Monday, August 14, 2023 at 4:47:21 AM UTC+8, Ed Prochak wrote:
>> On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
>>> On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
>>>
>>>> Okay. I am trying to make sure I don't offend you here,
>>>> but
>>>> you do know that the OBJ file contains more than the
>>>> executable code and that even the code it contains
>>>> may not be in binary format,
>>>> RIGHT?
>>> Yes, I know that, but it's mostly binary code and
>>> here is the fat code in the PDOS/86 kernel:
>>>
>>> fat_TEXT CODE AUTO 33f2:0000 0000b222
>>>
>>> 45602 bytes. Compiled with Open Watcom.
>>>
>>> I checked the disassembly - it is all legitimate code.
>>>
>>> It could be the price of the huge memory model, which I
>>> wouldn't encounter on the 8080.
>>>
>>> BFN. Paul.
>
>> Last I checked 45602 is still less than 64K (65536).
>> Did you misread a decimal place?
>
> Here is what I originally reported:
>
> this 8086 object code:
>
> 2023-07-29 08:22 56,783 fat.obj
>
> almost blowing away the entire 64k possible
>
>
> Note the word "almost".
>
>> But that doesn't mean all of that code needs to be in memory all the time.
>> (As pointed out by others in this conversation). In the old days of small
>> machines these were called overlays. It is more formally called virtual memory.
>>
>> On small machines if slows things down but these are hardware solutions.
>
> Well - is that how CP/M managed to pull off the feat with PL/M?
>
> PL/M does automatic overlays? Or were they manually done?
>
> I guess dropping LFN and FAT32 would save space.
>
> And as I mentioned - this is using the huge memory model.
> Although I would have thought that the 8080 with 8-bit
> registers and 16-bit addresses would be the equivalent of
> huge memory model also.
>
> Although that in itself is another design choice I made - I
> wanted my code to be C90-compliant instead of having
> "near" and "far" and "huge" keywords everywhere, so I
> just chose to blanketly compile in true huge memory model
> (all pointers huge). And if that doesn't leave enough room
> for apps on an 8086 then upgrade to either a Turbo 186 or
> an 80286 or above. Rather than change the OS source code.
>
> I should be able to get another 64k on the Book 8088 by
> using the region A0000-AFFFF and simply not use graphics,
> but I haven't tried that yet. I'm not sure if I will find RAM or
> a hole at B0000-B7FFF. If there is RAM there then I could
> switch to using a VT100 terminal and get B0000-BFFFF.

The memory of the monochromatic graphic cards in text mode is mapped to
the address B0000, as well as at the address B8000 for the color graphic
cards. These memory areas also exist in RAM but are not used (some
memory managers made it available to use them in Dos. The name of the
most famous was Qemm).

> Or fragmented memory would be OK too. But I won't bother
> doing that until I have started reusing the kernel's C library
> instead of each application having their own.
>
> I think there's a ROM at C0000-FFFFF, without backing RAM
> (on the Book 8088), even if it was possible to bank it out.
>
> (note that this was just unrelated comments about the 8086
> design - the original question is about 8080 - I'm just not
> sure what's going to happen when I take the 8086 and 80386
> design and try to implement it on the 8080 - or what the design
> should be).
>
> BFN. Paul.
>