Boot Sector Size Competition

[Benjamin David Lunt]

Hi everyone,

I am sure that most of you have been following along, but it the
SmallerC thread, Rod came up with the idea of a competition to see
who could write the smallest (smallest in byte count) 1st stage
boot sector. Or at least he commented it and I became interested :-)

Anyway, with a fixed margin text of rules (Hi Bernhard), I have
come up with a rough draft.

http://www.fysnet.net/aod_compo.htm

Please see what you think, and post your comments, additions,
changes etc.

If we can scrape up enough interest, I think this would be an
interesting competition, a byte at a time.

Thanks,
Ben

[Benjamin David Lunt]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:m361ms$aon$2...@speranza.aioe.org...

Hi guys,

I created a test suite that would test your code. However, it doesn't
look like there is much interest in this compo, probably because it
is more toward x86 assembly coding than OS developing. :-)

Anyway, the test suite is written in such a way, that it is a good
test of your FAT12/16 code as far as booting is concerned. At the
link above, I have included the .zip file for download, including
source, image files, readme.txt file, and instructions.

Again, if there is no interest in this competition, at least the
boottest.c/.h code could be used to test your FAT boot sectors.
(granted your fat boot sectors won't have a Partition Entry Table
in them (smile) )

I haven't tested it thoroughly, nor even written a boot file to
test it, though it should be sound. If there is more interest
in this compo, a more thorough test will be done.

Anyway, below is the readme.txt file.

Ben


--readme.txt ---------------------------------------------------------
This package is intended to be used with a (possible) competition on
alt.os.development, to write a very small FAT boot sector.

Since there may be little or no interest, I also wrote this package
to be used to test your FAT boot code.

When executed,

C:\>BOOTTEST targfile.img part.img

the BOOTTEST.EXE file will create a target file named 'targfile.img" and
place an empty MBR in the first sector. It will then load four partitions
of your choice, named 'partX.img' each, where the X is '0', '1', '2', and
'3'
respectively.

It will place these partition entries in a random order just after the
first sector. However, for an extra test, it will place a random amount
of sectors, filled with random bytes, in between the partitions.

Once this is completed, it will copy at most, the first 446 bytes of
a file "hard coded" as "ENTRY.BIN" and place it in the first 446 bytes
of the MBR.

Therefore, if you write a FAT boot record and name it "ENTRY.COM", and
run this app, you can test your code.

Each time you run this app, it will randomly place these partition entries
within the image, at different places and at different partition entry
sequences. For example, the first time you run it, it may place the
entries as:

55 filler sectors
PART0.IMG
10 filler sectors
PART3.IMG
17 filler sectors
PART1.IMG (Set to active)
33 filler sectors
PART2.IMG
X filler sectors to a cylinder boundary

but the next time, it may be

11 filler sectors
PART3.IMG (Set to active)
4 filler sectors
PART1.IMG
62 filler sectors
PART2.IMG
51 filler sectors
PART0.IMG
X filler sectors to a cylinder boundary

Each partition may or may not be on a cylinder/head boundary. This is
by design so that your code can be tested for this. Each of the four
partitions have differently formatted FAT12 or FAT16 file formats installed
with a few files each, with these files in random order.

The Partition images (PARTX.IMG) are not set to any specific size. You
may use any sized partition that you want, as long as the last sector
of the last partition is within a 32-bit LBA range.

To test your FAT code, find the active partition in the MBR, then
using that partition, find the 'loader.sys' file, load it to a
set address and jump to it. If you did this correctly, it will
display a string saying so.

If you have any questions, please feel free to let me know.

fys [at] fysnet [dot] net

http://www.fysnet.net


files:
readme.txt - this file.
boottest.cpp - The source code to this app (compiled with VS2008 for
Windows,
boottest.h - but should be 100% portable with little or no change)
boottest.exe - WindowsXP executable version (DOS session)
loader.asm - The source to the loader.sys file already on each
partX.img file
part0.img - The four partition files
part1.img - (each having the same files on them, but in different
order)
part2.img - (each using FAT-12 or -16, with various differences in
format)
part3.img - (different Cluster Sizes, FATs, etc.)
targfile.img - Included for those who don't want to build the source.
entry.img - An empty Boot. Simply prints "I am an empty boot
sector..."
imgcpy.exe - Utility to copy a file to an image (by Alex F.)


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's

Batteries not included, some Assembly required.

[wolfgang kern]

Hi Ben,

Fine so far and I think to take on the challenge, even just to
prove my memory about FAT...

A few questions about your rules:

* I assume you mean INT10_0E by '0E' ?
* do we really need to clear the high 16 bits of SP ?
* can we assume that LOADER.SYS isn't fragmented ?
* you know, I type code in hex and there is no 'source' available.
will your disassembler be able to show what it does ? :)
__
wolfgang

________
Moved my reply from smallerC to here:

Benjamin David Lunt wrote:
...
>> I think there isn't much to optimize on REP MOVS(D/W/B) :)

> If you followed the Hugi Compos those many years ago, you would
> think different. ...
> http://www.hugi.scene.org/compo/compoold.htm#compo1

Yeah, I remember this.

>>> - using a filesystem, FAT16 for example, find the s[p]ecified
>>> loader file, given by an ASCIIZ file name

>> Here you lost me, my OS bootloader assumes a FAT-less volume.
>> Even it installs a 'FATsHIT' import/export module later in the game,
>> it uses only LBA- (if INT1342) or CHS-(if only 1302) for all system
>> modules and all these havent got a 'name' at all.

> The volume must have some sort of file system on it, doesn't it?
> If it does not, how are files found?

No need to search for system-'files', the installer knew where he
put it and stored this info as LBA-nr in my MBR ... see below on
how my OS treats system-modules.

>> ________________________________
>> My current first stage bootcode loader is fully within the 1.sector
>> of a volume, and this sector contains, beside the partition entries,
>> all data (which other OS may have 63 sectors apart as 'BR') and
>> several (error-)message text lines.
>> So there are only the first 256 bytes available for code, but even
>> here I use 80 bytes for two INT13_42 structs and a few support flags.

> Does this include a minimal file system routine to extract the 2nd
> stage loader?

No, not required in my world ...
my system-modules aren't part of the (user definable) filesystem.

>> Now I got only 176 code-bytes (where 12 remain unused yet) for:
>> - find the system partition
>> (as all the system files (incl. 2nd stage loader) can reside on
>> any partition this must be checked first).

> Reside on any partition as a set location and size of files, or from
> a file system?

...I combined all MBR and BR information in the first sector of any
KESYS-volume. This is recognised by my own partition-type (0x4B 'K').
And this 80 byte 'BR'-info contain LBA-numbers for all main system
modules and the start-LBA of the user-directories, created by format,
install or updates.

>> - check if my 'BR' tells that this is a SYS-container or just data.
>> - check and remember on INT13_42 support or use INT13_02 instead.
>> - LOAD second stage to memory (according to 'BR-info')
>> - check for valid signature and version of the loaded part.
>> - the mandatory 'print'-routine.
>> - jump to next stage or:
>> - if any error: print msg, wait for key and reboot after.

> Sounds like I know who will be on top of the list, at least at first :-)

It may sound like, but my OS doesn't detour with FAT, so your quest
will add many bytes to it and only a few of the current can be saved.

>> Not sure if I can make this shorter by more than a one or two bytes.
> ahhh, but that's where the whole intention of these kind of compos come
> in. I can remember one of the tasks, I said this same thing, and before
> I knew it, I had eliminated 10 bytes.

my preference was/is always 'short and fast', but for a bootsector compo
I may forget about 'fast' yet.

>> Such things are always interesting for me as long I'm not bound to
>> weird behaving environments like windoze, loonix or DOS ;)

> I don't believe that the rules I have included (see another post)
> include these weird behaviors...

Ok, even I think that FAT is quite a weird FS-solution, it is widely
in use and so I take on the quest.

__
wolfgang

[Benjamin David Lunt]

"wolfgang kern" <now...@never.at> wrote in message
news:m3a8p8$5m7$1...@newsreader2.utanet.at...

>
> Hi Ben,
>
>> I am sure that most of you have been following along, but it the
>> SmallerC thread, Rod came up with the idea of a competition to see
>> who could write the smallest (smallest in byte count) 1st stage
>> boot sector. Or at least he commented it and I became interested :-)
>
>> Anyway, with a fixed margin text of rules (Hi Bernhard), I have
>> come up with a rough draft.
>>
>> http://www.fysnet.net/aod_compo.htm
>>
>> Please see what you think, and post your comments, additions,
>> changes etc.
>>
>> If we can scrape up enough interest, I think this would be an
>> interesting competition, a byte at a time.
>
> Fine so far and I think to take on the challenge, even just to
> prove my memory about FAT...
>
> A few questions about your rules:
>
> * I assume you mean INT10_0E by '0E' ?

Yes.

> * do we really need to clear the high 16 bits of SP ?

No. But it is just one more thing to optimize.

> * can we assume that LOADER.SYS isn't fragmented ?

No. I will add it to the rules. Thank you. The file itself is
less than a cluster size could be (< 512 bytes), but your code must
look for the end of cluster flag.

> * you know, I type code in hex and there is no 'source' available.
> will your disassembler be able to show what it does ? :)

Absolutely. This is fine.

Thanks,
Ben

[wolfgang kern]

Hi Ben,

>> * can we assume that LOADER.SYS isn't fragmented ?

> No. I will add it to the rules. Thank you. The file itself is
> less than a cluster size could be (< 512 bytes), but your code must
> look for the end of cluster flag.

would a check of file-size against cluster-size do it as well ?

* about rule 'O' (the letter not 'zero'):
what would you see on screen with bx=0000 ?
I'd suggest to use any other than Black on Black variant, my
preference is (like BIOS std) bx=0007 Gray on Black to show text.

one more question is which way of determining FAT12 or FAT16 is
allowed (strict M$'s FATspec or any possible easy hack) ?

and I really hope that I'm not the only one who try to compete :)
__
wolfgang

[Benjamin David Lunt]

----- Original Message -----
From: "wolfgang kern" <now...@never.at>
Newsgroups: alt.os.development
Sent: Friday, November 07, 2014 2:37 PM
Subject: Re: Boot Sector Size Competition


> Hi Ben,
>
>>> * can we assume that LOADER.SYS isn't fragmented ?
>
>> No. I will add it to the rules. Thank you. The file itself is
>> less than a cluster size could be (< 512 bytes), but your code must
>> look for the end of cluster flag.
>
> would a check of file-size against cluster-size do it as well ?

I would say not, for the following reason. Simply to make sure
your code checks for the correct EOF value. If you are mounting
a FAT16 volume but check for 0xFF8, you will surely be in error.

> * about rule 'O' (the letter not 'zero'):
> what would you see on screen with bx=0000 ?
> I'd suggest to use any other than Black on Black variant, my
> preference is (like BIOS std) bx=0007 Gray on Black to show text.

BL is used in graphics mode only. In text mode, BL is ignored,
but we must make sure BH is set to zero. It is just as many
bytes to clear BH than it is to clear BX, unless you use some
form of trick (hint, hint).

> one more question is which way of determining FAT12 or FAT16 is
> allowed (strict M$'s FATspec or any possible easy hack) ?

I have to admit, I didn't even think of this one. I was thinking
of the fact that your boot sector would already know what is on
the volume. However, with the test suite, this is not the case.

For an actual boot code, yes, you should use the MS way. However,
for the purpose of this task, let's just use the FS_TYPE field.
Is this okay? Simply check to see if the 5th byte is a '2' or
a '6'.

> and I really hope that I'm not the only one who try to compete :)

Me too.

Thanks,
Ben

[Benjamin David Lunt]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:m361ms$aon$2...@speranza.aioe.org...

Okay everyone, I have two entries submitted. Best has a size
of 315 bytes. I dare anyone to beat that.

Also note, that if you downloaded the test suite before yesterday,
the FAT16 partitions were in error. The utility I used to make them
created them correctly, though the utility I used to copy files to
them "correctly" calculated the fat size as FAT12 instead of FAT16.
The utility wasn't at error, it correctly calculated the FAT size,
I just didn't realize it calculated it as FAT12 instead of FAT16.

Please download the latest test suite. Currently, part2.img and
part3.img are identical. As soon as I get some time, I will create
two more detailed, totally different 16-bit FAT partitions.

Anyway, see if you can beat my 315. Wolfgang sent in an entry,
but has been working on a new one. I bet the next one he sends
will even beat my 315 bytes...

Thanks,
Ben

[wolfgang kern]

Hello Ben,

> Okay everyone, I have two entries submitted. Best has a size
> of 315 bytes. I dare anyone to beat that.

> Also note, that if you downloaded the test suite before yesterday,
> the FAT16 partitions were in error. The utility I used to make them
> created them correctly, though the utility I used to copy files to
> them "correctly" calculated the fat size as FAT12 instead of FAT16.
> The utility wasn't at error, it correctly calculated the FAT size,
> I just didn't realize it calculated it as FAT12 instead of FAT16.

> Please download the latest test suite. Currently, part2.img and
> part3.img are identical. As soon as I get some time, I will create
> two more detailed, totally different 16-bit FAT partitions.

> Anyway, see if you can beat my 315. Wolfgang sent in an entry,
> but has been working on a new one. I bet the next one he sends
> will even beat my 315 bytes...

this 315 bytes made think a while... hard to beat, but not impossible :)
I came down from 365 to 340 last week and down to 318 this morning.
But I have to check everything with care and figure where I could shave
off a few bytes before I send it.
__
wolfgang

[Benjamin David Lunt]

"wolfgang kern" <now...@never.at> wrote in message

news:m4q66r$p0c$1...@newsreader2.utanet.at...

You better work a little more, I'm down to 296 bytes. :-)

Anyone else????

--
Ben

[Rod Pemberton]

On Sat, 22 Nov 2014 12:37:42 -0500, Benjamin David Lunt <zf...@fysnet.net>
wrote:

> Anyone else????
>

You guys already started? I haven't started yet.
Although I kicked this idea off, I'm not sure if
I'll be joining in. If I ever do and come up with
something smaller, I'll post it. One of the last
compo's, I made one costly mistake which kept me
away from the lead.


Rod Pemberton

[Alexei A. Frounze]

Just shared this @ http://forum.osdev.org/. Thought you might enjoy extra company. :)

Alex

[michael....@gmail.com]

I'm working on a boot sector, too.
I just started so my first version will be available at earliest tomorrow. I really like those competitions :)

[Benjamin David Lunt]

<michael....@gmail.com> wrote in message
news:c34511fe-cf79-4161...@googlegroups.com...

> I'm working on a boot sector, too.
> I just started so my first version will be available at earliest tomorrow.
> I really like those competitions :)

Looking forward to seeing it.

[Benjamin David Lunt]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:m361ms$aon$2...@speranza.aioe.org...

> Hi everyone,
>
> I am sure that most of you have been following along, but it the
> SmallerC thread, Rod came up with the idea of a competition to see
> who could write the smallest (smallest in byte count) 1st stage
> boot sector. Or at least he commented it and I became interested :-)
>
> Anyway, with a fixed margin text of rules (Hi Bernhard), I have
> come up with a rough draft.
>
> http://www.fysnet.net/aod_compo.htm

Just a quick note to say that I have only received an entry from
wolfgang, a 276 byte entry in fact. I couldn't find how to get
my entry from 296 down any more and he has beat me by 20 bytes...

Anyway, if anyone has interest in sending an entry, you have a
few days left.

If it isn't close to wolfgang's 276 byte entry, or my 296 entry,
you can still submit. No one here is going to mock you for not
having a small entry. This is how I learned. If you look at
http://www.hugi.scene.org/compo/compoold.htm
my entry, for the first compo, was 46th place (Sniper), and
coincidentally, 46th for compo #2 also. 16th, second to last
for #5 and dead last for #7. :-)

However, starting with #9 (15th) and then #10 (6th), I started
getting the hang of it. (Though, don't look at #11, I was dead
last again)

I even wrote an assembler for #14, though like an idiot, didn't
release it until after the compo was over. Don't know why, just
didn't.

In fact, that compo led me to write an article in DDJ.
http://www.ddj.com/embedded/210601643?pgno=1

Those were fun days. Memories I will hold on to for a long time.

Anyway, if you have an entry, please send it in. I will test
it and post the results.

If wolfgang doesn't mind, I will post the source code to his and
anyone else's as long as they don't mind (after the 1st of Jan).

Thanks,
Ben

[Kerr Mudd-John]

On Sat, 27 Dec 2014 00:12:26 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

>
> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
> news:m361ms$aon$2...@speranza.aioe.org...
>> Hi everyone,
>>
>> I am sure that most of you have been following along, but it the
>> SmallerC thread, Rod came up with the idea of a competition to see
>> who could write the smallest (smallest in byte count) 1st stage
>> boot sector. Or at least he commented it and I became interested :-)
>>
>> Anyway, with a fixed margin text of rules (Hi Bernhard), I have
>> come up with a rough draft.
>>
>> http://www.fysnet.net/aod_compo.htm
>
> Just a quick note to say that I have only received an entry from
> wolfgang, a 276 byte entry in fact. I couldn't find how to get
> my entry from 296 down any more and he has beat me by 20 bytes...
>
> Anyway, if anyone has interest in sending an entry, you have a
> few days left.
>

I got c. 400 bytes, and am not sure it will even work!

> If it isn't close to wolfgang's 276 byte entry, or my 296 entry,
> you can still submit. No one here is going to mock you for not
> having a small entry. This is how I learned. If you look at
> http://www.hugi.scene.org/compo/compoold.htm
> my entry, for the first compo, was 46th place (Sniper), and
> coincidentally, 46th for compo #2 also. 16th, second to last
> for #5 and dead last for #7. :-)
>
> However, starting with #9 (15th) and then #10 (6th), I started
> getting the hang of it. (Though, don't look at #11, I was dead
> last again)
>
> I even wrote an assembler for #14, though like an idiot, didn't
> release it until after the compo was over. Don't know why, just
> didn't.
>
> In fact, that compo led me to write an article in DDJ.
> http://www.ddj.com/embedded/210601643?pgno=1
>
> Those were fun days. Memories I will hold on to for a long time.
>
> Anyway, if you have an entry, please send it in. I will test
> it and post the results.
>
> If wolfgang doesn't mind, I will post the source code to his and
> anyone else's as long as they don't mind (after the 1st of Jan).
>

That would be very instructive!

> Thanks,
> Ben
>
>


--
Bah, and indeed, Humbug

[James Harris]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:m361ms$aon$2...@speranza.aioe.org...

> Hi everyone,
>
> I am sure that most of you have been following along, but it the
> SmallerC thread, Rod came up with the idea of a competition to see
> who could write the smallest (smallest in byte count) 1st stage
> boot sector. Or at least he commented it and I became interested :-)
>
> Anyway, with a fixed margin text of rules (Hi Bernhard), I have
> come up with a rough draft.
>
> http://www.fysnet.net/aod_compo.htm
>
> Please see what you think, and post your comments, additions,
> changes etc.

Just catching up with things I took a look at the above rules. Am I right
that they are proposing that the MBR of a hard disk has code to load
"loader.sys" from within a FAT partition? If so wouldn't that render any
non-FAT partition on the disk unbootable? The MBR would not know how to deal
with it. Why did you choose to make the boot happen that way?

And the MBR code has to be able to look in the partition and interpret both
FAT12 and FAT16 structures. That's quite a challenge!

I can see you put a lot of work into defining the rules and setting up a
test environment. Well done! Even though I don't intend to submit an entry
I'll be interested to see the resulting code. It seems impossible to fit all
the needed code into the space that you and Wolfgang have.

James

[Benjamin David Lunt]

"James Harris" <james.h...@gmail.com> wrote in message
news:m7ml46$i67$1...@dont-email.me...

The point is not that it is a MBR which loads a loader.sys file.
The point is that you get from point A to point B in the least
amount of x86 assembly code bytes as possible.

The MBR to 'loader.sys' content is simply because this newsgroup
has interest in this kind of stuff.

I created this compo with the whole intent of simply doing a size
coding competition. Who can get from point A to point B in the
least amount of bytes as possible, following the rules given.
The product or outcome is irrelevant.

I could have created something like, decompress this .zip file
to the original source file using the least amount of assembly
code bytes.

I do admit though that I am trying to get more interest into
this newsgroup. Whether I helped or not, I am glad to see that
we have gotten quite a bit more traffic lately.

Ben

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
news:op.xrixl7hvmsr2db@dell3100...

> On Sat, 27 Dec 2014 00:12:26 -0000, Benjamin David Lunt <zf...@fysnet.net>
> wrote:
>>
>> Anyway, if anyone has interest in sending an entry, you have a
>> few days left.
>>
> I got c. 400 bytes, and am not sure it will even work!

The enjoyment is that 400 bytes can be cut to 300 quite quickly.
It is when you get to 290, and you find 2 bytes. That is tough,
but very satisfying.

> That would be very instructive!

If Wolfgang doesn't object, and he hasn't yet, I will be sure
to release his code along with mine.

Thanks,
Ben

[wolfgang kern]

Benjamin David Lunt wrote:

>>> Anyway, if anyone has interest in sending an entry, you have a
>>> few days left.

>> I got c. 400 bytes, and am not sure it will even work!

> The enjoyment is that 400 bytes can be cut to 300 quite quickly.
> It is when you get to 290, and you find 2 bytes. That is tough,
> but very satisfying.

>> That would be very instructive!

> If Wolfgang doesn't object, and he hasn't yet, I will be sure
> to release his code along with mine.

Of course we should discuss it in public ...
and I already work on a verbose commented source for my HEX-code.

I have to confess that I was cheating with my 276 byte version
by breaking a rule. So my final entry.bin will be 281 bytes.
__
wolfgang

[James Harris]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message

news:m7n955$ve6$1...@speranza.aioe.org...

>
> "James Harris" <james.h...@gmail.com> wrote in message
> news:m7ml46$i67$1...@dont-email.me...

...

>> I can see you put a lot of work into defining the rules and setting up a
>> test environment. Well done! Even though I don't intend to submit an
>> entry I'll be interested to see the resulting code. It seems impossible
>> to fit all the needed code into the space that you and Wolfgang have.
>
> The point is not that it is a MBR which loads a loader.sys file.
> The point is that you get from point A to point B in the least
> amount of x86 assembly code bytes as possible.
>
> The MBR to 'loader.sys' content is simply because this newsgroup
> has interest in this kind of stuff.
>
> I created this compo with the whole intent of simply doing a size
> coding competition. Who can get from point A to point B in the
> least amount of bytes as possible, following the rules given.
> The product or outcome is irrelevant.
>
> I could have created something like, decompress this .zip file
> to the original source file using the least amount of assembly
> code bytes.
>
> I do admit though that I am trying to get more interest into
> this newsgroup. Whether I helped or not, I am glad to see that
> we have gotten quite a bit more traffic lately.

Understood. I don't know your frame of mind after running this one but it
occurs to me that if you are thinking to run any more competitions it might
be worth including some with easier tasks ... much easier! Even for those
who have been doing stuff like this for years this MBR-2FAT-boot task would
be a big challenge and it seems to have been a lot of work for you too
(which is appreciated; thanks for your efforts on it). A simpler and shorter
task may seem less daunting and encourage more folk to enter while still
providing the same element of challenge.

James

[Benjamin David Lunt]

"James Harris" <james.h...@gmail.com> wrote in message

news:m7nk0h$35h$1...@dont-email.me...

>
> Understood. I don't know your frame of mind after running this one but it
> occurs to me that if you are thinking to run any more competitions it
> might be worth including some with easier tasks ... much easier! Even for
> those who have been doing stuff like this for years this MBR-2FAT-boot
> task would be a big challenge and it seems to have been a lot of work for
> you too (which is appreciated; thanks for your efforts on it). A simpler
> and shorter task may seem less daunting and encourage more folk to enter
> while still providing the same element of challenge.

I totally agree and will be happy to host one, as long as there is
interest in it.

With the hugi compo's, we discussed the rules before hand, allowed
all to comment, add, change, etc., on the rules before the compo
started.

The hugi compo that I always remember is the one where you have
to print to the screen a list of text. If I remember correctly,
it was #2. Given a text file, you had to print the same text
to the screen using as few bytes as possible. The trick was
the text had to be in your .com file so that the following
could be the test:

entry > entry.txt
fc test.txt entry.txt /b

The text was somewhere around 700 bytes and the smallest entry
was around 500 bytes, if memory serves.

Anyway, if there is enough interest, I am sure Adok (the host of
the Hugi Compo) won't mind if we host another compo.

Any ideas?

[Benjamin David Lunt]

Okay. Here are the results of the compo.

Thank you wolfgang for your entry. It is quite interesting
to see how you did some parts. I will have to spend some
more time studying it to see what you did.

Thanks.

Original rules:
http://www.fysnet.net/aod_compo.htm

results and source code:
http://www.fysnet.net/temp/aod_compo.zip

Ben

[wolfgang kern]

Benjamin David Lunt wrote:

> Okay. Here are the results of the compo.

...

I started with 365 byte and Ben found it didn't even pass the test.
so I removed one bug and some bytes too and came up with 318 byte.
this version passed the test even it had another silly bug.
After fixing this one I had only 295 byte.
Then I adapted my code to the test and cheated with 276 bytes.

Ok, here is my final variant with a few more comments.
It's written in pure hex and exported to a FAT-file.
disassembled with NASM (mine show my personal syntax),
and I tried to not produce linewraps with comments here.
feel free to ask any question or just pick on it :)

__
wolfgang

M:\DIV_TOOL\NASM9838>ndisasmw d:com\entry.bin (281 byte)

000 FC cld
001 666A00 o32 push byte +0x0 ;push four Zero bytes
004 1F pop ds
005 17 pop ss
006 8CDC mov sp,ds ;ds=ss=sp=0
008 1E push ds ;esp=0_fffe, [sp]=0
009 BBAA55 mov bx,0x55aa
00C B441 mov ah,0x41
00E CD13 int 0x13
010 BEEE7C mov si,0x7cf3 ;error text and my base
013 7206 jc 0x1b
015 81FB55AA cmp bx,0xaa55 ;'NOT BX' trick isn't shorter
019 740C jz 0x27

01B 5B pop bx ;zero as demanded
01C AC lodsb
01D 3C4C cmp al,0x4c ;who said ASCII-Z?
01F 74FC jz 0x1d ;freeze on the "L"
021 B40E mov ah,0xe
023 CD10 int 0x10
025 EBF5 jmp short 0x1c

027 BBBE7D mov bx,0x7dbe ;find active partition
02A 0A27 or ah,[bx] ;AH was 0x41 from above
02C 7805 js 0x33
02E 80C310 add bl,0x10
031 EBF7 jmp short 0x2a

033 8B4708 mov ax,[bx+0x8] ;volume-start LBA
036 1E push ds ;
037 50 push ax ;prepared for popad: eax
038 6668EFBEADDE push dword 0xdeadbeef ;ecx
03E B600 mov dh,0x0
040 1E push ds
041 52 push dx ;edx
042 666804030201 push dword 0x1020304 ;ebx
048 8854F6 mov [si-0xa],dl ;[7cf3-0a=7ce9] BIOS Drv#
04B E88300 call 0xd6 ;load sectors AX..to 0:7e00

04E B108 mov cl,0x8 ;prepare for popad (CH=0 from call)
050 1E push ds ;ebp,(esp),esi,edi all zero.
051 E2FD loop 0x50

053 03470E add ax,[bx+0xe] ;add boot-sectors
056 8EE0 mov fs,ax ;FS aka FAT-Start here
058 807F3A36 cmp byte [bx+0x3a],0x36 ;FAT12 or 16
05C 7407 jz 0x65 ;skip if 16
05E FE4CA8 dec byte [si-0x58] ;[7cf3-58=7c9b]
;=nibbles per entry
061 C644B60F mov byte [si-0x4a],0xf ;[7cf3-4a=7ca9]
;=EOC-mask highbyte

065 8A4F0D mov cl,[bx+0xd] ;sectors per cluster
068 884CC3 mov [si-0x3d],cl ;[7cf3-3d=7cb6]

06B 034716 add ax,[bx+0x16] ;sectors per FAT
06E FE4F10 dec byte [bx+0x10] ;add as many as reported
071 75F8 jnz 0x6b

073 8BE8 mov bp,ax ;BP = AX = rootstart
075 8B7F11 mov di,[bx+11] ;root-entries
078 C1EF04 shr di,0x4 ;root-size (sectors)
07B 03EF add bp,di ;BP = BR+FATs+Root = Datastart
;----------------------------
;before I had something like:
;
;075 mov cx,[bx+11]
;078 test cl,0xf
;07B jz 0x80
;07D add cx,0x10
;080 shr cx,0x4
;083 add bp,cx
;
;but I never saw any nonzero low-nibble values for root-entries.
;
;and I cheated in the 276 byte version with:
;075 add bp,0x0e ;figured as Ben's root-size standard :)
;----------------------------
07D 56 push si
07E E85500 call 0xd6 ;load root sectors to 0:7e00

081 8BFB mov di,bx ;instead of push/pop di, see 0C2
083 BE097D mov si,0x7d0e ;ptr to: "LOADER .SYS"
086 B10B mov cl,0xb ;CH=0 from above
088 F3A6 repe cmpsb ;find entry
08A 7405 jz 0x91
08c 83C320 add bx,byte +0x20
08F EBF0 jmp short 0x81

091 5E pop si

092 8B471A mov ax,[bx+0x1a] ;get cluster (ignore size)
095 8904 mov [si],ax ;save a copy
097 31DB xor bx,bx ;init destination-ptr

;LOOP:
099 6BF804 imul di,ax,byte +0x4 ;[7c9b] become 3 if FAT12
09C 8CE0 mov ax,fs ;ax=FAT-start, di=nibble_offset
;-------------------------------
;in previous trials I had:;
;
;099 B504 mov ch,0x4 ;CL=0 from above and below
; 6BC004 imul ax,ax,byte +0x4 ;3 or 4 [nibbles/entry]
; 31D2 xor dx,dx
; F7F1 div cx ;(1024 nibbles/sector)
; 8BFA mov di,dx ;di= nibble offset
; 8CE2 mov dx,fs ;
; 03C2 add ax,dx ;ax=FATsector+FATstart
;
;but then found that this isn't required and
:I can keep DX as EOC-mark within the loop.
;-------------------------------
09E 53 push bx
09F E83400 call 0xd6 ;load FAT-sectors to 0:7e00
0A2 D1EF shr di,1 ;nibble to byte, remember Carry
0A4 8B01 mov ax,[bx+di] ;get FAT-entry
0A6 5B pop bx
;------
; you may ask why I have the call above within the loop.
; the FAT-import from my OS loads only a few FAT-sectors
; at a time and calculate the LBA from Cluster-Nr.
; This way I avoid to load the whole FAT into RAM which
; would be required for far distant fragments.
; All because a whole FAT32 copy will be quite large.
;------
0A7 BAFFFF mov dx,0xffff ;[7ca9] EOC become '0FFF' if FAT12
0AA 7303 jnc 0xaf ;odd? (never odd if FAT16)
0AC C1E804 shr ax,0x4 ;
0AF 21D0 and ax,dx ;mask it
0B1 8704 xchg ax,[si] ;save entry, get cluster

0B3 48 dec ax ; cluster-Nr.
0B4 48 dec ax ; -2
0B5 B101 mov cl,0x1 ; * [7cb6] sectors per cluster
0B7 F6E1 mul cl ;
0B9 03C5 add ax,bp ; + 1st_data

0BB 680030 push word 0x3000
0BE 07 pop es ;es=3000
0BF E81C00 call 0xde ;load one cluster to ES:BX

0C2 80C702 add bh,0x2 ;adjust for next cluster
0C5 E2FB loop 0xc2 ;add di,0200 was one byte more
;so I swapped bx and di usage
0C7 8B04 mov ax,[si] ;get recent FATentry
0C9 3BC2 cmp ax,dx ;cmp with EOC
0CB 72CC jc 0x99 ;repeat if <EOC

0CD 6661 popad ;set all regs as demanded
0CF 06 push es ;is 0x3000 from last call
0D0 1F pop ds
0D1 06 push es
0D2 17 pop ss
0D3 06 push es
0D4 57 push di ;di became 0 from popad
0D5 CB retf

0D6 B90200 mov cx,0x4 ;load 2K to 0:7e00
;-----
; I could have used 0x007f instead of 4, but my always
; present concern about speed and my maniac needs for
; avoiding redundant actions made it even pass the test
; with a 2 here.
;-----
0D9 BB007E mov bx,0x7e00
0DC 1E push ds
0DD 07 pop es ;es=0
0DE 60 pusha ;load CL-sectors to ES:BX
0DF 1E push ds ;0
0E0 1E push ds ;0
0E1 1E push ds ;0
0E2 50 push ax ;LBA
0E3 06 push es ;seg
0E4 53 push bx ;offset
0E5 51 push cx ;count (CH must be 0)
0E6 6A10 push byte +0x10 ;size of struct
0E8 B280 mov dl,0x80 ;[7ce9] BIOS drv-Nr.
0EA 8BF4 mov si,sp ;works because SS=DS=0
0EC B442 mov ah,0x42
0EE CD13 int 0x13
0F0 61 popa ;add SP,16
0F1 61 popa ;restore all
0F2 C3 ret
;text data:
0F3 4E 6F 20 44 69 73 6B 20 53 65 72 76 69
100 63 65 73 20 41 76 61 69 6C 61 62 6C 65 2E
10E 4C 4F
110 41 44 45 52 20 20 53 59 53
119 ...free
---------------

[Benjamin David Lunt]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message

news:m829i3$k12$1...@speranza.aioe.org...

Wolfgang pointed out an error in my entry.

In the read_sectors procedure at the end of the file I have the
comment

add sp,16 ; 3 (wish we could do a popa (1 byte) but it will modify sp)
popa ; 1 ( which will mess up the next popa...)

I never looked into or realized that (e)sp is not modified (restored)
other than the decrement (or increment depending on how you look at it).

It makes sense not too. I just never thought of it. Never needed
to worry about it. Don't use the popa(d) instruction much, so didn't
even think of it.

Thanks wolfgang for pointing this out. I learn something new each
day.

Happy New Year to all.

Thanks,

[Kerr Mudd-John]

On Thu, 01 Jan 2015 11:27:23 -0000, wolfgang kern <now...@never.at> wrote:

>
> Benjamin David Lunt wrote:
>
>> Okay. Here are the results of the compo.
> ...
>
> I started with 365 byte and Ben found it didn't even pass the test.
> so I removed one bug and some bytes too and came up with 318 byte.
> this version passed the test even it had another silly bug.
> After fixing this one I had only 295 byte.
> Then I adapted my code to the test and cheated with 276 bytes.
>
> Ok, here is my final variant with a few more comments.
> It's written in pure hex and exported to a FAT-file.
> disassembled with NASM (mine show my personal syntax),
> and I tried to not produce linewraps with comments here.
> feel free to ask any question or just pick on it :)

> __

dash dash, not underscore!

> wolfgang
>
> M:\DIV_TOOL\NASM9838>ndisasmw d:com\entry.bin (281 byte)
>
> 000 FC cld
> 001 666A00 o32 push byte +0x0 ;push four Zero bytes
> 004 1F pop ds
> 005 17 pop ss
> 006 8CDC mov sp,ds ;ds=ss=sp=0
> 008 1E push ds ;esp=0_fffe, [sp]=0

> 009 BBAA55 mov bx,0x55aa
> 00C B441 mov ah,0x41
> 00E CD13 int 0x13
> 010 BEEE7C mov si,0x7cf3 ;error text and my base
> 013 7206 jc 0x1b
> 015 81FB55AA cmp bx,0xaa55 ;'NOT BX' trick isn't
> shorter

I had hopes of swapping the aa and 55 but no good. e.g.
mov bx,0x55AA
mov cx,bx
int 13
jc print_errmsg
xchg ch,cl
cmp bx,cx

> 019 740C jz 0x27
>
> 01B 5B pop bx ;zero as demanded
> 01C AC lodsb
> 01D 3C4C cmp al,0x4c ;who said ASCII-Z?

I had that!

; cl=1, dx=0, ax=ax but why?

> 0B9 03C5 add ax,bp ; + 1st_data
>
> 0BB 680030 push word 0x3000
> 0BE 07 pop es ;es=3000
> 0BF E81C00 call 0xde ;load one cluster to ES:BX
>
> 0C2 80C702 add bh,0x2 ;adjust for next cluster
> 0C5 E2FB loop 0xc2 ;add di,0200 was one byte more
> ;so I swapped bx and di usage
> 0C7 8B04 mov ax,[si] ;get recent FATentry
> 0C9 3BC2 cmp ax,dx ;cmp with EOC
> 0CB 72CC jc 0x99 ;repeat if <EOC
>

; might it be possible to tuck away the required values elsewhere and
finish on a popa retf?

> 0CD 6661 popad ;set all regs as demanded
> 0CF 06 push es ;is 0x3000 from last call
> 0D0 1F pop ds
> 0D1 06 push es
> 0D2 17 pop ss
> 0D3 06 push es
> 0D4 57 push di ;di became 0 from popad
> 0D5 CB retf
>

sometimes one can avoid a few bytes by falling into a rtn. maybe not here

I presume it's cheaper to use the stack than setup a structure for the
read?

Nice work. Personally I prefer source code with labels, but I appreciate
that you are closer to the raw code.

[wolfgang kern]

Kerr Mudd-John wrote:

...

>> __
> dash dash, not underscore!
>> wolfgang

Yeah I know, and add four lines after, but your advice come
35 years too late :)

[...]

>> 009 BBAA55 mov bx,0x55aa
>> 00C B441 mov ah,0x41
>> 00E CD13 int 0x13
>> 010 BEEE7C mov si,0x7cf3 ;error text and my base
>> 013 7206 jc 0x1b
>> 015 81FB55AA cmp bx,0xaa55 ;'NOT BX' trick isn't
>> shorter

> I had hopes of swapping the aa and 55 but no good. e.g.
> mov bx,0x55AA
> mov cx,bx
> int 13
> jc print_errmsg
> xchg ch,cl
> cmp bx,cx

INT13_41 modifies CX, but DI can be used: (same size as my code)

1.
3 mov di,0x55aa
2 mov bx,di
2 int13
2 jc ...
2 not bx ;NOT 55AA == AA55
2 cmp bx,di

2.
3 mov di,0x7dfe
2 mov bx,[di]
2 not bx
2 int13
2 jc ...
2 cmp bx,[di]

I would have used the latter if [DI-d8] could point to my variables,
but my code became too short for this.

>> 019 740C jz 0x27
>>
>> 01B 5B pop bx ;zero as demanded
>> 01C AC lodsb
>> 01D 3C4C cmp al,0x4c ;who said ASCII-Z?

I had that!

good.

>> 01F 74FC jz 0x1d ;freeze on the "L"

[...]

>> 0B3 48 dec ax ; cluster-Nr.
>> 0B4 48 dec ax ; -2
>> 0B5 B101 mov cl,0x1 ; * [7cb6] sectors per cluster
>> 0B7 F6E1 mul cl ;

> ; cl=1, dx=0, ax=ax but why?

This 01 is modified to become any of 1,2,4,8 ...
and dx isn't involved here.

>> 0B9 03C5 add ax,bp ; + 1st_data
>>
>> 0BB 680030 push word 0x3000
>> 0BE 07 pop es ;es=3000
>> 0BF E81C00 call 0xde ;load one cluster to ES:BX
>>
>> 0C2 80C702 add bh,0x2 ;adjust for next cluster
>> 0C5 E2FB loop 0xc2 ;add di,0200 was one byte more
>> ;so I swapped bx and di usage
>> 0C7 8B04 mov ax,[si] ;get recent FATentry
>> 0C9 3BC2 cmp ax,dx ;cmp with EOC
>> 0CB 72CC jc 0x99 ;repeat if <EOC

> ; might it be possible to tuck away the required values elsewhere and
> finish on a popa retf?

No, because stack changes (SS=3000 instead of 0 then)

>> 0CD 6661 popad ;set all regs as demanded
>> 0CF 06 push es ;is 0x3000 from last call
>> 0D0 1F pop ds
>> 0D1 06 push es
>> 0D2 17 pop ss
>> 0D3 06 push es
>> 0D4 57 push di ;di became 0 from popad
>> 0D5 CB retf
>>

> sometimes one can avoid a few bytes by falling into a rtn. maybe not here

> I presume it's cheaper to use the stack than setup a structure for the
> read?

Just count the bytes from 0DF..0E7, they create 16 bytes on stack.

...

> Nice work. Personally I prefer source code with labels, but I appreciate
> that you are closer to the raw code.

thanks,
my labels are the hex-values of the relative address :)
__
wolfgang

[Kerr Mudd-John]

On Wed, 07 Jan 2015 00:09:11 -0000, wolfgang kern <now...@never.at> wrote:

>
> Kerr Mudd-John wrote:
>
> ...
[]

>
> 2.
> 3 mov di,0x7dfe
> 2 mov bx,[di]
> 2 not bx
> 2 int13
> 2 jc ...
> 2 cmp bx,[di]
>
> I would have used the latter if [DI-d8] could point to my variables,
> but my code became too short for this.

I don't suppose setting sp to 0x7DFE and popping it to bx is worth the
trickery?
the SP can then be shifted to safer ground with a pushad.

you might even then search backwards for an active ptn!
>
[print error section]

>>> 01B 5B pop bx ;zero as demanded

Isn't this printing black on black?

>
>>> 0B3 48 dec ax ; cluster-Nr.
>>> 0B4 48 dec ax ; -2
>>> 0B5 B101 mov cl,0x1 ; * [7cb6] sectors per cluster
>>> 0B7 F6E1 mul cl ;
>
>> ; cl=1, dx=0, ax=ax but why?
>
> This 01 is modified to become any of 1,2,4,8 ... and dx isn't involved
> here.
>

OK sorry, I hadn't understood the fat12/16 change

>> I presume it's cheaper to use the stack than setup a structure for the
>> read?
>
> Just count the bytes from 0DF..0E7, they create 16 bytes on stack.
>

Sure. though a lot are 0.



> __
> wolfgang

[Kerr Mudd-John]

On Sun, 04 Jan 2015 18:29:17 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

Given the spare space that is evident in the MBR, can anyone here see if
it would be possible to create a "select a partition to boot from" one,
with, and here's the rub, mouse input?
I've seen menu select using cursor keys, but any others have relied on
later boot stages to give a graphical interface, the code for which is way
too big to fit in a MBR.
Any pointers (see what I did there?) welcome.

[Kerr Mudd-John]

On Wed, 07 Jan 2015 00:09:11 -0000, wolfgang kern <now...@never.at> wrote:


>
> 1.
> 3 mov di,0x55aa
> 2 mov bx,di
> 2 int13
> 2 jc ...
> 2 not bx ;NOT 55AA == AA55
> 2 cmp bx,di
>

would this work?

3 mov di,0x55AA

2 mov bx,di
2 int13

2 jc bad
2 or bx,di ; (AA55-->FFFF)
1 inc bx
jz good
bad:

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xr3fb6ztmsr2db@dell3100...

>
> Given the spare space that is evident in the MBR, can anyone here see if
> it would be possible to create a "select a partition to boot from" one,
> with, and here's the rub, mouse input?
> I've seen menu select using cursor keys, but any others have relied on
> later boot stages to give a graphical interface, the code for which is way
> too big to fit in a MBR.
> Any pointers (see what I did there?) welcome.

Within the initial 512 bytes, *and* parse, load, and boot the selected
partition, now that would be a trick.

The BIOS has little or no support for the mouse, so you would have to
load a driver or write one yourself to fit within this space. That
alone could take a hundred bytes.

However, most partition techniques start the first partition on the second
track (head 1), so there are 63 sectors available for the boot. This 63
times 512 bytes would be plenty to do so.

If I was to spend that much time and effort, I would not want to be
restricted to the current MBR partition scheme.

A while back I created (for the fun of it), the eMBR, where it
allows for much larger drives, and the kicker is, it has a scrollable
display list of the partitions. No mouse input, but it could be
easily added since the technique allows for (mostly) an unlimited
amount of code space to boot the eMBR.

http://www.fysnet.net/fysos_embr.htm

with the .pdf file at
http://www.fysnet.net/docs/embr.pdf

The actual technique to display to the partitions is not specified
in the above specification, however I have documented and included
assembly source code in my book
http://www.fysnet.net/the_system_core.htm

Page 3-7 shows a slightly out of date screen shot. I have since added
support for the scrollbar at the right.
http://www.fysnet.net/temp/embr_list.pdf

Adding mouse support shouldn't be to difficult.

Just my thoughts anyway.

Here is one more, the Intel EFI boot doesn't include source code
or binary code to boot it. The boot code is in the BIOS or other
form of boot device. If your machine doesn't know about this time
of "MBR", it isn't going to boot.

[wolfgang kern]

Kerr Mudd-John wrote:

...
> []
>> 2.
>> 3 mov di,0x7dfe
>> 2 mov bx,[di]
>> 2 not bx
>> 2 int13
>> 2 jc ...
>> 2 cmp bx,[di]
>>
>> I would have used the latter if [DI-d8] could point to my variables,
>> but my code became too short for this.


> I don't suppose setting sp to 0x7DFE and popping it to bx is worth the
> trickery?
> the SP can then be shifted to safer ground with a pushad.

See it youself:
3 mov sp,0x7dfe
1 pop bx
2 not bx
2 pushad ;sp is now 0x7dfe+2-0x20 = 0x7de0
;but it should finally be 0x0_fffe.
2 int0x13
2 jc ..
4 cmp,0x55aa ;cant reference the long gone [sp]

> you might even then search backwards for an active ptn!

Yes, Ben used a backward search for this.

> [print error section]
>
>>>> 01B 5B pop bx ;zero as demanded

> Isn't this printing black on black?

Yes, on all my machines, but Ben wanted for a Zero here :)

>>>> 0B3 48 dec ax ; cluster-Nr.
>>>> 0B4 48 dec ax ; -2
>>>> 0B5 B101 mov cl,0x1 ; * [7cb6] sectors per cluster
>>>> 0B7 F6E1 mul cl ;
>>
>>> ; cl=1, dx=0, ax=ax but why?
>>
>> This 01 is modified to become any of 1,2,4,8 ...
>> and dx isn't involved here.

> OK sorry, I hadn't understood the fat12/16 change

the byte at [0B5] were my 'sector per cluster'-"varable".

__
wolfgang

[wolfgang kern]

Kerr Mudd-John wrote:

>> 1.
>> 3 mov di,0x55aa
>> 2 mov bx,di
>> 2 int13
>> 2 jc ...
>> 2 not bx ;NOT 55AA == AA55
>> 2 cmp bx,di

> would this work?
>
> 3 mov di,0x55AA
> 2 mov bx,di
> 2 int13
> 2 jc bad
> 2 or bx,di ; (AA55-->FFFF)
> 1 inc bx
> jz good
> bad:

yes, also this would work, but it too break compo-rules:

3 mov bx,0x55A

2 int13
2 jc bad

1 cmc
2 adc bl,bh ; (55 or AA --> FF +1 --> 00)
jz good

And both of the above cant make sure that BX=AA55.


in my OS boot-code I just check for Carry and ignore the
returned BX. But I check on CX for more support-details.

__
wolfgang

[Kerr Mudd-John]

On Wed, 07 Jan 2015 19:02:14 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

>

> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
> news:op.xr3fb6ztmsr2db@dell3100...
>>
>> Given the spare space that is evident in the MBR, can anyone here see if
>> it would be possible to create a "select a partition to boot from" one,
>> with, and here's the rub, mouse input?
>> I've seen menu select using cursor keys, but any others have relied on
>> later boot stages to give a graphical interface, the code for which is
>> way
>> too big to fit in a MBR.
>> Any pointers (see what I did there?) welcome.
>
> Within the initial 512 bytes, *and* parse, load, and boot the selected
> partition, now that would be a trick.
>

ITYM 446 bytes, allowing for the 4 ptn tables and 55AA sig!
Here's something:
http://mbldr.sourceforge.net/
this seems to be similar, if not the same
http://svnweb.freebsd.org/base/stable/8/sys/boot/i386/boot0/boot0.S?view=co

but not a great user interface.

I've seen that the MBR merely has to move out the way, and find & load up
the active partition boot track. And maybe not even move, with a dastardly
load & return trick I saw um somewhere earlier.

> The BIOS has little or no support for the mouse, so you would have to
> load a driver or write one yourself to fit within this space. That
> alone could take a hundred bytes.

None that I'm aware of but I think USB mice are pretty standard these days.

ctmouse takes 1k, but I'm hoping I'd need far less for just a scroll up
down, click to select highlighted item. I'd not bother with serial (or
even PS/2?) mouse support.
Urgh, I'm drowning in the code!
http://cutemouse.sourceforge.net/

it doesn't mention USB mice!

> However, most partition techniques start the first partition on the
> second
> track (head 1), so there are 63 sectors available for the boot. This 63
> times 512 bytes would be plenty to do so.
>

maybe; that sounds much less of a challenge!

> If I was to spend that much time and effort, I would not want to be
> restricted to the current MBR partition scheme.
>
> A while back I created (for the fun of it), the eMBR, where it
> allows for much larger drives, and the kicker is, it has a scrollable
> display list of the partitions. No mouse input, but it could be
> easily added since the technique allows for (mostly) an unlimited
> amount of code space to boot the eMBR.
>
> http://www.fysnet.net/fysos_embr.htm
>
> with the .pdf file at
> http://www.fysnet.net/docs/embr.pdf

OK, I see the spec!

>
> The actual technique to display to the partitions is not specified
> in the above specification, however I have documented and included
> assembly source code in my book
> http://www.fysnet.net/the_system_core.htm
>
> Page 3-7 shows a slightly out of date screen shot. I have since added
> support for the scrollbar at the right.
> http://www.fysnet.net/temp/embr_list.pdf
>
> Adding mouse support shouldn't be to difficult.
>

It'd depend; mouse driven stuff I recall from early days just went through
a mouse driver on int 33h.

> Just my thoughts anyway.
>
> Here is one more, the Intel EFI boot doesn't include source code
> or binary code to boot it. The boot code is in the BIOS or other
> form of boot device. If your machine doesn't know about this time
> of "MBR", it isn't going to boot.
>

I'll avoid them then!

> Ben

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xr311stemsr2db@dell3100...

>> The actual technique to display to the partitions is not specified
>> in the above specification, however I have documented and included
>> assembly source code in my book
>> http://www.fysnet.net/the_system_core.htm
>>
>> Page 3-7 shows a slightly out of date screen shot. I have since added
>> support for the scrollbar at the right.
>> http://www.fysnet.net/temp/embr_list.pdf
>>
>> Adding mouse support shouldn't be to difficult.
>>
> It'd depend; mouse driven stuff I recall from early days just went through
> a mouse driver on int 33h.

Indeed, but at the time of the MBR, this driver is not loaded, hence
no int 33h support. You have to write your own.

You would have to write:
1. the actual detection of the mouse. Finding the mouse would be the first
thing to do.
2. the communications part, noting that USB mice emulate as PS2 mice,
so no need for USB protocols (yet).
3. the cursor display, usually a block, though it isn't a block, it is
an inverse of the color scheme for that char position. For example,
if you have white text on black background, you would make for black
text on white background for that character position only. Hence,
the look of a block.
4. the button click code including the conversion from screen coordinates
to keypress or other action.

Along with other items of the mouse.

If the (current) user interface uses key presses for all access, you could
write your mouse code to "simulate" a key press. For example, check to
see if the click was on a down arrow. If so, send a "down arrow key" to
either the user interface or the actual keyboard.

Anyway, interesting stuff.

Thanks,
Ben

[Kerr Mudd-John]

On Wed, 07 Jan 2015 20:21:14 -0000, wolfgang kern <now...@never.at> wrote:

>
> Kerr Mudd-John wrote:
>
>>> 1.
>>> 3 mov di,0x55aa
>>> 2 mov bx,di
>>> 2 int13
>>> 2 jc ...
>>> 2 not bx ;NOT 55AA == AA55
>>> 2 cmp bx,di
>
>> would this work?
>> 3 mov di,0x55AA
>> 2 mov bx,di
>> 2 int13
>> 2 jc bad
>> 2 or bx,di ; (AA55-->FFFF)
>> 1 inc bx
>> jz good
>> bad:
>

Sorry, should have been xor!

> yes, also this would work, but it too break compo-rules:
>
> 3 mov bx,0x55A
> 2 int13
> 2 jc bad
> 1 cmc
> 2 adc bl,bh ; (55 or AA --> FF +1 --> 00)
> jz good
>
> And both of the above cant make sure that BX=AA55.
>

xor should be guaranteed! 55AA is the only complement of AA55.

>
> in my OS boot-code I just check for Carry and ignore the returned BX.
> But I check on CX for more support-details.

I agree, jc should be enough.

In your next section:

027 BBBE7D mov bx,0x7dbe ;find active partition
02A 0A27 or ah,[bx] ;AH was 0x41 from above
02C 7805 js 0x33
02E 80C310 add bl,0x10
031 EBF7 jmp short 0x2a

033 8B4708 mov ax,[bx+0x8] ;volume-start LBA

I think can be shortened by starting at the 0th entry:
027 BBAE7D mov bx,0x7DBE-10 ; 0th entry
02A 80C310 add bl,0x10 ; increment before test
02D 0A27 or ah,[bx]
02F 79F9 jns 0x2A

; have a boot ptn entry , no jmp needed
031 8B4708 mov ax,[bx+0x8] ;volume-start LBA


grdb is handy for getting the hex!

> __
> wolfgang

[Kerr Mudd-John]

On Wed, 07 Jan 2015 21:34:45 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

>

> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
> news:op.xr311stemsr2db@dell3100...
>
>>> The actual technique to display to the partitions is not specified
>>> in the above specification, however I have documented and included
>>> assembly source code in my book
>>> http://www.fysnet.net/the_system_core.htm
>>>
>>> Page 3-7 shows a slightly out of date screen shot. I have since added
>>> support for the scrollbar at the right.
>>> http://www.fysnet.net/temp/embr_list.pdf
>>>
>>> Adding mouse support shouldn't be to difficult.
>>>
>> It'd depend; mouse driven stuff I recall from early days just went
>> through
>> a mouse driver on int 33h.
>
> Indeed, but at the time of the MBR, this driver is not loaded, hence
> no int 33h support. You have to write your own.
>

I know. I've not seen any mouse support code, other than in ctmouse!

> You would have to write:
> 1. the actual detection of the mouse. Finding the mouse would be the
> first
> thing to do.
> 2. the communications part, noting that USB mice emulate as PS2 mice,
> so no need for USB protocols (yet).
> 3. the cursor display, usually a block, though it isn't a block, it is
> an inverse of the color scheme for that char position. For example,
> if you have white text on black background, you would make for black
> text on white background for that character position only. Hence,
> the look of a block.
> 4. the button click code including the conversion from screen coordinates
> to keypress or other action.

I was thinking of making it purely support (emulate) Enter/Click to
select, and cursor/mouse up (move highlight bar up), and same for down,
not full screen character support.

>
> Along with other items of the mouse.
>
> If the (current) user interface uses key presses for all access, you
> could
> write your mouse code to "simulate" a key press. For example, check to
> see if the click was on a down arrow. If so, send a "down arrow key" to
> either the user interface or the actual keyboard.
>
> Anyway, interesting stuff.
>
> Thanks,
> Ben
>
>

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xr34i1bvmsr2db@dell3100...

> On Wed, 07 Jan 2015 21:34:45 -0000, Benjamin David Lunt <zf...@fysnet.net>
> wrote:
>
>
> I was thinking of making it purely support (emulate) Enter/Click to
> select, and cursor/mouse up (move highlight bar up), and same for down,
> not full screen character support.
>

Yes, this would be much easier.
Mouse move up = up arrow key
Mouse move down = down arrow key
Button Click = enter key

"Push" those keys into the keyboard, or simply call the same
routine that gets called by the keyboard entry.

As for the BIOS supporting a mouse, the VESA BIOS has a little
support for a Virtual Cursor Interface (VCI), however, there are
some BIOS' that support INT 15h/Services C2xxh.

I have not tried them myself, nor do I know which or if any do
support it, though they might all support it, I haven't tried.

Something I might have to do, just to see. :-)

Ben

[wolfgang kern]

yes. this would have saved me one byte.

>> in my OS boot-code I just check for Carry and ignore the returned BX.
>> But I check on CX for more support-details.
> I agree, jc should be enough.

> In your next section:

> 027 BBBE7D mov bx,0x7dbe ;find active partition
> 02A 0A27 or ah,[bx] ;AH was 0x41 from above
> 02C 7805 js 0x33
> 02E 80C310 add bl,0x10
> 031 EBF7 jmp short 0x2a
>
> 033 8B4708 mov ax,[bx+0x8] ;volume-start LBA


> I think can be shortened by starting at the 0th entry:
> 027 BBAE7D mov bx,0x7DBE-10 ; 0th entry
> 02A 80C310 add bl,0x10 ; increment before test
> 02D 0A27 or ah,[bx]
> 02F 79F9 jns 0x2A
>
> ; have a boot ptn entry , no jmp needed
> 031 8B4708 mov ax,[bx+0x8] ;volume-start LBA

Good, even too late now :)
Ben used a similar branch-saver here.

> grdb is handy for getting the hex!

dunno grdb, I use my brain instead.

__
wolfgang

[Kerr Mudd-John]

On Wed, 07 Jan 2015 23:30:32 -0000, Benjamin David Lunt <zf...@fysnet.net>

wrote:

>
> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
> news:op.xr34i1bvmsr2db@dell3100...
>> On Wed, 07 Jan 2015 21:34:45 -0000, Benjamin David Lunt
>> <zf...@fysnet.net>
>> wrote:
>>
>>
>> I was thinking of making it purely support (emulate) Enter/Click to
>> select, and cursor/mouse up (move highlight bar up), and same for down,
>> not full screen character support.
>>
>
> Yes, this would be much easier.
> Mouse move up = up arrow key
> Mouse move down = down arrow key
> Button Click = enter key
>
> "Push" those keys into the keyboard, or simply call the same
> routine that gets called by the keyboard entry.
>
> As for the BIOS supporting a mouse, the VESA BIOS has a little
> support for a Virtual Cursor Interface (VCI), however, there are
> some BIOS' that support INT 15h/Services C2xxh.
>
> I have not tried them myself, nor do I know which or if any do
> support it, though they might all support it, I haven't tried.
>
> Something I might have to do, just to see. :-)
>

Cheers!

I have hacked together some asm code for the menu of partitions; seems
promising so far at
13A bytes, so still have c. 100 bytes for the mouse!
I'll get a test environment up & iron out the bugs.

[Kerr Mudd-John]

Just trying to be helpful!

I've just searched on the read & boot trick that was posted in December
(seems not by you) and found instead some old posts by you; I didn't
realise you were in health trouble from 2008. Sorry to find that.

> Ben used a similar branch-saver here.
>> grdb is handy for getting the hex!
>
> dunno grdb, I use my brain instead.
>

I don't know all the hex codes off by heart, sorry!

[Benjamin David Lunt]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:m8kfjc$u52$1...@speranza.aioe.org...

>
> As for the BIOS supporting a mouse, the VESA BIOS has a little
> support for a Virtual Cursor Interface (VCI), however, there are
> some BIOS' that support INT 15h/Services C2xxh.
>
> I have not tried them myself, nor do I know which or if any do
> support it, though they might all support it, I haven't tried.
>
> Something I might have to do, just to see. :-)

I spent a little time today looking at service(s) C2xx of Interrupt 15h.
It seems pretty straight forward and got a somewhat working example.
However, Bochs does not report the data correctly.

So, I went to see what other machines, actual machines I have to
try it on. The first two I checked don't support service(s) C2xx
at all. Since these two machines are my main test machines, I
stopped trying. :-)

Maybe some day I will look at the Bochs code and fix it. Maybe...

As for adding mouse support to my eMBR code, it will have to be
hard coded into the boot code. I will have to check for PS2 and
serial style mice. Most USB mice will be emulated as a PS2 at
boot time.

Thanks,

[wolfgang kern]

Benjamin David Lunt wrote:

>> As for the BIOS supporting a mouse, the VESA BIOS has a little
>> support for a Virtual Cursor Interface (VCI), however, there are
>> some BIOS' that support INT 15h/Services C2xxh.
>>
>> I have not tried them myself, nor do I know which or if any do
>> support it, though they might all support it, I haven't tried.
>>
>> Something I might have to do, just to see. :-)
>
> I spent a little time today looking at service(s) C2xx of Interrupt 15h.
> It seems pretty straight forward and got a somewhat working example.
> However, Bochs does not report the data correctly.
>
> So, I went to see what other machines, actual machines I have to
> try it on. The first two I checked don't support service(s) C2xx
> at all. Since these two machines are my main test machines, I
> stopped trying. :-)

> Maybe some day I will look at the Bochs code and fix it. Maybe...

> As for adding mouse support to my eMBR code, it will have to be
> hard coded into the boot code. I will have to check for PS2 and
> serial style mice. Most USB mice will be emulated as a PS2 at
> boot time.

My BIOS wont emulate an USB-mouse as PS/2 by default.
After setting INT15_C207 to a dummy and enable by INT15_C200,
I could have used this RM-interface what I never did.

But after my OS entered PM32 and controls all IRQs/etc....
I found that the mouse just acts as it would be an PS/2-device
(IRQ12 and port 0x60).

So this saved me (for a while) to write an USB-driver for it.
Nevertheless I got your book about USB and hope to once figure
all required details for USB-support.

btw: my PS/2 mouse module (aka IRQ12-handler) is 64 bytes large,
it handles three buttons and it remembers x/y-positions on press
and release in an additional 32 byte struct.

one more btw:
after this COMPO I checked on my old boot-code and immediate removed
30 bytes even just to be used for more verbose messages yet.

And me too use LBA sectors 1..62 for the second loader stage where all
RM/BIOS info is gathered before the final HMA loaded PM32 code starts.
__
wolfgang

[James Harris]

"wolfgang kern" <now...@never.at> wrote in message
news:m8pf7k$f3g$1...@speranza.aioe.org...

>
> Benjamin David Lunt wrote:

...

>> As for adding mouse support to my eMBR code, it will have to be
>> hard coded into the boot code. I will have to check for PS2 and
>> serial style mice. Most USB mice will be emulated as a PS2 at
>> boot time.
>
> My BIOS wont emulate an USB-mouse as PS/2 by default.

Most BIOSes have a setting called "Enable legacy USB" or similar. AIUI if
that is set then USB keyboard and mouse will initially be presented to
programs as if they were legacy PS/2 devices, i.e. on the normal port
addresses. If that setting is disabled then they will only be available by
USB protocols.

...

> But after my OS entered PM32 and controls all IRQs/etc.... I found that
> the mouse just acts as it would be an PS/2-device
> (IRQ12 and port 0x60).

Sounds as though you have legacy support enabled.

James

[wolfgang kern]

James Harris wrote:

> ...

>>> As for adding mouse support to my eMBR code, it will have to be
>>> hard coded into the boot code. I will have to check for PS2 and
>>> serial style mice. Most USB mice will be emulated as a PS2 at
>>> boot time.

>> My BIOS wont emulate an USB-mouse as PS/2 by default.

> Most BIOSes have a setting called "Enable legacy USB" or similar. AIUI if
> that is set then USB keyboard and mouse will initially be presented to
> programs as if they were legacy PS/2 devices, i.e. on the normal port
> addresses. If that setting is disabled then they will only be available by
> USB protocols.

My Bios doesn't show that option.
and my search for this bits in the south bridge is still in progress.

> ...

>> But after my OS entered PM32 and controls all IRQs/etc.... I found that
>> the mouse just acts as it would be an PS/2-device
>> (IRQ12 and port 0x60).

> Sounds as though you have legacy support enabled.

Yes, but only if initialised by INT15_C2xx before the OS enters PM32.
perhaps because my keyboards are still PS/2 types.

__
wolfgang

[Kerr Mudd-John]

On Thu, 08 Jan 2015 20:27:28 -0000, Kerr Mudd-John <ad...@127.0.0.1> wrote:

> On Wed, 07 Jan 2015 23:30:32 -0000, Benjamin David Lunt
> <zf...@fysnet.net> wrote:
>
>>
>> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
>> news:op.xr34i1bvmsr2db@dell3100...
>>> On Wed, 07 Jan 2015 21:34:45 -0000, Benjamin David Lunt
>>> <zf...@fysnet.net>
>>> wrote:
>>>
>>>
>>> I was thinking of making it purely support (emulate) Enter/Click to
>>> select, and cursor/mouse up (move highlight bar up), and same for down,
>>> not full screen character support.
>>>
>>
>> Yes, this would be much easier.
>> Mouse move up = up arrow key
>> Mouse move down = down arrow key
>> Button Click = enter key
>>

I have refined my (keyboard only) menubar program - now 87 bytes purely
for that part:

Here's the "spec" if anyone wants to compete!

select an area of screen at topline, startcol, lth, depth
allow hilite colour, standard colour (pass parms later)
initially highlight the top line
allow scroll of bar up/dn using csr keys,
set exit code of line selected on Enter, 0xFF on Esc.
assume text mode 3 (colour screen 25*80)
use int 16 for keyboard input.

[Benjamin David Lunt]

"wolfgang kern" <now...@never.at> wrote in message

news:m90625$alh$1...@speranza.aioe.org...

>
>> Most BIOSes have a setting called "Enable legacy USB" or similar. AIUI if
>> that is set then USB keyboard and mouse will initially be presented to
>> programs as if they were legacy PS/2 devices, i.e. on the normal port
>> addresses. If that setting is disabled then they will only be available
>> by USB protocols.
>
> My Bios doesn't show that option.
> and my search for this bits in the south bridge is still in progress.

These bits you are asking about are on the USB card, not the motherboard.

The USB card has the capability of sensing when data is sent from the
mouse our keyboard and then trigger a SMI so that the BIOS can take that
data and send it to the 8042 controller. However, this assumes the BIOS
is USB compliant. Also, any data from the 8042 controller must be sent
to the USB keyboard or mouse.

See page 44, part 5, of the uhci specs:
ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf

This feature can be turned on or off via the USB card and is usually
activated by the BIOS at startup. However, the BIOS does not deactivate
this feature, by default. The loaded OS has that decision. The
"Enable legacy USB" option in the CMOS or BIOS setup screen is to
tell the BIOS to leave this feature active, or turn it off after it
is done.

This feature is also used to "catch" the A20 line change when using the
8042 controller.

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xscibounmsr2db@dell3100...

>
> I have refined my (keyboard only) menubar program - now 87 bytes purely
> for that part:
>
> Here's the "spec" if anyone wants to compete!
>
> select an area of screen at topline, startcol, lth, depth
> allow hilite colour, standard colour (pass parms later)
> initially highlight the top line
> allow scroll of bar up/dn using csr keys,
> set exit code of line selected on Enter, 0xFF on Esc.
> assume text mode 3 (colour screen 25*80)
> use int 16 for keyboard input.

I'm afraid you will have to be more specific.
Please explain a little more.

Ben

[James Harris]

"wolfgang kern" <now...@never.at> wrote in message

news:m90625$alh$1...@speranza.aioe.org...

So you use PS/2 keyboards and USB mice and only get port-based mouse access
if you initialise via INT15_C2xx? Interesting. I would have thought that if
the BIOS was going to make USB devices appear as PS/2 devices that it would
do so consistenty but maybe that depends on the BIOS.

James

[wolfgang kern]

Benjamin David Lunt wrote:

>>> Most BIOSes have a setting called "Enable legacy USB" or similar. AIUI
>>> if >>> that is set then USB keyboard and mouse will initially be
>>> presented to programs as if they were legacy PS/2 devices, i.e. on the
>>> normal port addresses. If that setting is disabled then they will only
>>> be available by USB protocols.

>> My Bios doesn't show that option.
>> and my search for this bits in the south bridge is still in progress.

> These bits you are asking about are on the USB card, not the motherboard.

Ok, but I dont have an USB-card :)
all my 9 USB-hosts are part of the chipset and are documented in
the southbridge manual as apart PCI-devices.

> The USB card has the capability of sensing when data is sent from the
> mouse our keyboard and then trigger a SMI so that the BIOS can take that
> data and send it to the 8042 controller. However, this assumes the BIOS
> is USB compliant. Also, any data from the 8042 controller must be sent
> to the USB keyboard or mouse.

> See page 44, part 5, of the uhci specs:
> ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf

> This feature can be turned on or off via the USB card and is usually
> activated by the BIOS at startup. However, the BIOS does not deactivate
> this feature, by default. The loaded OS has that decision. The
> "Enable legacy USB" option in the CMOS or BIOS setup screen is to
> tell the BIOS to leave this feature active, or turn it off after it
> is done.

> This feature is also used to "catch" the A20 line change when using the
> 8042 controller.

Thanks, I'll search for 'the bit' in this one too.
__
wolfgang

[Kerr Mudd-John]

On Mon, 12 Jan 2015 18:51:49 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

>

> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
> news:op.xscibounmsr2db@dell3100...
>>
>> I have refined my (keyboard only) menubar program - now 87 bytes purely
>> for that part:
>>
>> Here's the "spec" if anyone wants to compete!
>>

>> select an area of screen at StartCol, StartRow, lth, depth

>> allow hilite colour, standard colour (pass parms later)
>> initially highlight the top line
>> allow scroll of bar up/dn using csr keys,
>> set exit code of line selected on Enter, 0xFF on Esc.
>> assume text mode 3 (colour screen 25*80)
>> use int 16 for keyboard input.
>
> I'm afraid you will have to be more specific.
> Please explain a little more.
>

OK a picture is easier:
Screen (imagine 80 wide, 25 deep) fixed font reqd!


StartRow
|
StartCol
x
+------------------------------------------+
| |
| <---Width--> |
y| 111111111111 ^ |
| 222222222222 | |
| 333333333333 Depth |
| 444444444444 | |
| 555555555555 v |
| |
| |
| |
+------------------------------------------+

Add a background colour of (I suggest) Blue and Bright attribute to each
character depicted as "1" above.
on keypress of CsrDn, remove the attribute, and highlight the text at
StartCol, for Width on the line below.
if CsrDn from last line, move highlight to top (1's row).
Similarly for CsrUp key, with wrap-around from top line to bottom line (in
this example 5's row)
Esc to exit with rc 255d, Enter to exit with rc of line last highlighted
(relative to StartRow, i.e. 1 for the top!)


In use this routine would have text previously displayed on the screen;
this gives the user a chance to select one of the options in a prettier
user interaction than the old "press 1 for option1, 2 for option 2" etc.
To add mouse support would be a higher goal!


> Ben

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xsdb3dnymsr2db@dell3100...

I see what you are doing. How do you determine the coordinates, width,
and height? Pass them along with the command line or hard code them in?

Ben

[Kerr Mudd-John]

On Tue, 13 Jan 2015 15:46:19 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

ignore all other keys

>>
>> In use this routine would have text previously displayed on the screen;
>> this gives the user a chance to select one of the options in a prettier
>> user interaction than the old "press 1 for option1, 2 for option 2" etc.
>> To add mouse support would be a higher goal!
>
> I see what you are doing. How do you determine the coordinates, width,
> and height? Pass them along with the command line or hard code them in?
>
> Ben
>
>

They're currently hard coded as I envisaged this routine being used in the
boot sector.
Optimising parameter passing isn't of interest here!

Now 84 bytes. I think that's the best I can do.

[Rod Pemberton]

On Mon, 12 Jan 2015 13:50:05 -0500, Benjamin David Lunt <zf...@fysnet.net>
wrote:

> "wolfgang kern" <now...@never.at> wrote in message
> news:m90625$alh$1...@speranza.aioe.org...

>>> Most BIOSes have a setting called "Enable legacy USB" or similar. AIUI
>>> if that is set then USB keyboard and mouse will initially be presented
>>> to programs as if they were legacy PS/2 devices, i.e. on the normal
>>> port
>>> addresses. If that setting is disabled then they will only be available
>>> by USB protocols.
>>
>> My Bios doesn't show that option.
>> and my search for this bits in the south bridge is still in progress.
>
> These bits you are asking about are on the USB card, not the motherboard.
>
> The USB card has the capability of sensing when data is sent from the
> mouse our keyboard and then trigger a SMI so that the BIOS can take that
> data and send it to the 8042 controller. However, this assumes the BIOS
> is USB compliant. Also, any data from the 8042 controller must be sent
> to the USB keyboard or mouse.
>

You cited UHCI below. So, that answer above is for UHCI, yes?

What about for OHCI, EHCI, xHCI? Are they the same as UHCI?

> See page 44, part 5, of the uhci specs:
> ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf

BTW, that's page 38 of the document, but page 44 of the pdf.
I generally cite the document page. I don't know about other people.

> This feature can be turned on or off via the USB card and is usually
> activated by the BIOS at startup. However, the BIOS does not deactivate
> this feature, by default. The loaded OS has that decision. The
> "Enable legacy USB" option in the CMOS or BIOS setup screen is to
> tell the BIOS to leave this feature active, or turn it off after it
> is done.

...

> This feature is also used to "catch" the A20 line change
> when using the 8042 controller.

Does anyone know what situation the A20GATE pass through is for?

The UHCI document has one rather cryptic paragraph mentioning
"one specific case" of "performance degradation" when A20 is
trapped and emulated by SMI. This specific case requires the
A20GATE pass through enable/disable bits and special port sequence.

But ... What *IS* that "one specific case"? I see no mention
of it anywhere. Googling only pulls up UHCI on A20GATE pass
through. It doesn't pull up OHCI, EHCI, or xHCI. Apparently,
they don't need it. Why not?

Since A20Gate pass through requires a special port sequence
to pass through to the keyboard controller directly, someone
must specifically code for the "one specific case". Is this
for the BIOS use, an OS use, or what? I.e., it's not going
to be used for DOS ... So where?

In 2008, H.P. Anvin thought A20Gate the pass through sequence
had something to do with DOS games accessing the HMA, but
he claimed the standardized sequence in UHCI was incorrect.
I'm assuming the documented sequence is correct for the hardware,
since I reported it worked on one machine, but that he meant
the sequence is incorrect from the perspective of the software.

So, when would you need to toggle A20GATE so fast or so
frequently that you'd need to bypass the SMI trapping
and emulation of A20 because it's slow? Once A20 is
enabled, it usually stays enabled.

At the moment, I'm rather confused by this. The only
mentioned situation, i.e., DOS, is unlikely to use that
specific sequence for enabling/disabling A20. And, I'm
not sure it would work on non-UHCI USB controllers ...


Rod Pemberton

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xse85ieimsr2db@dell3100...

> On Tue, 13 Jan 2015 15:46:19 -0000, Benjamin David Lunt <zf...@fysnet.net>
> wrote:
>
>> I see what you are doing. How do you determine the coordinates, width,
>> and height? Pass them along with the command line or hard code them in?
>>
>>

> They're currently hard coded as I envisaged this routine being used in the
> boot sector.
> Optimising parameter passing isn't of interest here!
>
> Now 84 bytes. I think that's the best I can do.

Not my intention to "one up" you, but my current best is 78. I don't
know if I can find any more or not.

The attribute to set the selection to is easily changed with an EQUate,
but I assume the original attribute is 07h, white on black background.
I also use a single 80x386 instruction. Don't know if this is allowed.
I also assume DOS startup register settings:
ax = bx = 0, cx = 0x00FF
(http://www.fysnet.net/yourhelp.htm)

I could save 2 more bytes if you didn't care that I wrote to the
64k block before 0xB8000.

Did anyone else give it a try? I will post my code if no one objects.

Thanks,
Ben

[Benjamin David Lunt]

"Rod Pemberton" <bu...@notnotnontnooatno.cmm> wrote in message
news:op.xsfanbncv6dtjm@localhost...

> On Mon, 12 Jan 2015 13:50:05 -0500, Benjamin David Lunt <zf...@fysnet.net>
> wrote:
>> "wolfgang kern" <now...@never.at> wrote in message
>> news:m90625$alh$1...@speranza.aioe.org...
>
>>>> Most BIOSes have a setting called "Enable legacy USB" or similar. AIUI
>>>> if that is set then USB keyboard and mouse will initially be presented
>>>> to programs as if they were legacy PS/2 devices, i.e. on the normal
>>>> port
>>>> addresses. If that setting is disabled then they will only be available
>>>> by USB protocols.
>>>
>>> My Bios doesn't show that option.
>>> and my search for this bits in the south bridge is still in progress.
>>
>> These bits you are asking about are on the USB card, not the motherboard.
>>
>> The USB card has the capability of sensing when data is sent from the
>> mouse our keyboard and then trigger a SMI so that the BIOS can take that
>> data and send it to the 8042 controller. However, this assumes the BIOS
>> is USB compliant. Also, any data from the 8042 controller must be sent
>> to the USB keyboard or mouse.
>>
>
> You cited UHCI below. So, that answer above is for UHCI, yes?

Yes. OHCI does the same, but is activated slightly different.

> What about for OHCI, EHCI, xHCI? Are they the same as UHCI?

EHCI and xHCI each use the same method to activate or deactive this
feature, though it is different from OHCI or UHCI, and do a much
better job of "playing" with the BIOS when it comes to this type
of thing.

>> See page 44, part 5, of the uhci specs:
>> ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf
>
> BTW, that's page 38 of the document, but page 44 of the pdf.
> I generally cite the document page. I don't know about other people.

Yes, you are correct. The printed number at the bottom of the page
is "38", though the actual physical page is 44. I usually use the
page number "printed" on the same page I am reading, though for some
reason didn't this time.

You got me here. I never looked into it. Don't really care :-)

Ben

[wolfgang kern]

Benjamin David Lunt wrote:

>> Now 84 bytes. I think that's the best I can do.

> Not my intention to "one up" you, but my current best is 78. I don't
> know if I can find any more or not.

I may have missed one or more posts here.

> The attribute to set the selection to is easily changed with an EQUate,
> but I assume the original attribute is 07h, white on black background.
> I also use a single 80x386 instruction. Don't know if this is allowed.

> I also assume DOS startup register settings:
> ax = bx = 0, cx = 0x00FF
> (http://www.fysnet.net/yourhelp.htm)

DOS ? does this mean to create a .com as boot-selector ?

> I could save 2 more bytes if you didn't care that I wrote to the
> 64k block before 0xB8000.

You sure don't mean 0xA8000 ?

> Did anyone else give it a try?

Not yet in the early boot process, but I once added a boot-option
to my tools. It checks on all volumes in all drives, also the ones
in extended partitions before this option is available.
And the selection is already within my GUI [mouse/Kbd] and it wont
show any non bootable items.

> I will post my code if no one objects.

Let's see if we can shorten it down :) ;if it's ASM.
__
wolfgang

[Kerr Mudd-John]

On Wed, 14 Jan 2015 00:17:52 -0000, Benjamin David Lunt <zf...@fysnet.net>

wrote:

>
> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
> news:op.xse85ieimsr2db@dell3100...
>> On Tue, 13 Jan 2015 15:46:19 -0000, Benjamin David Lunt
>> <zf...@fysnet.net>
>> wrote:
>>
>>> I see what you are doing. How do you determine the coordinates, width,
>>> and height? Pass them along with the command line or hard code them
>>> in?
>>>
>>>
>> They're currently hard coded as I envisaged this routine being used in
>> the
>> boot sector.
>> Optimising parameter passing isn't of interest here!
>>
>> Now 84 bytes. I think that's the best I can do.
>
> Not my intention to "one up" you, but my current best is 78. I don't
> know if I can find any more or not.
>

Shorter the better!

> The attribute to set the selection to is easily changed with an EQUate,
> but I assume the original attribute is 07h, white on black background.
> I also use a single 80x386 instruction. Don't know if this is allowed.
> I also assume DOS startup register settings:
> ax = bx = 0, cx = 0x00FF
> (http://www.fysnet.net/yourhelp.htm)
>

Hmm, you didn't let us assume anything for the bootsector comp!

> I could save 2 more bytes if you didn't care that I wrote to the
> 64k block before 0xB8000.

I also "cheat" by going offpage.

>
> Did anyone else give it a try? I will post my code if no one objects.
>

Please do; I'll post mine; I was nearly going to earlier, but I've managed
to improve it a little since.

I don't think there's anyone here but you, me and Wolfgang plus Rod
occasionally. Seems even Rosario's dropped out of the assembler groups.


Anyway, here's mine (83 bytes):

;Nasm x86
CPU 8086
BITS 16


; spec - select area of Screen at line, col, lth, depth (colours?) (pass
parms later)
;hilite top line, allow scroll of bar up/dn using csr keys (int16), return

exit code of line selected on Enter, 0xFF on Esc.

; parms StartCol StartRow BarWidth NumRows; hard code for now

StartCol equ 3 ; <80
StartRow equ 2 ; <25
BarWidth equ 0x28 ; <=80
NumRows equ 3 ; <=25
; all fit in 1 byte

; key constants
KeyEsc equ 0x01
KeyEnter equ 0x1C
KeyCsrUp equ 0x48
KeyCsrDn equ 0x50

;screen constants
Screen equ 0xB800 ; colour screen ;10111000
Blue equ 1
Green equ 2
Red equ 4
Bright equ 8
White equ Blue+Green+Red

ScrTxtWidth equ 0x50 ; text mode 80 cols
ScrWidth equ 2*ScrTxtWidth ; allow for attrib

; calced nums
IndentAmt equ 2*StartCol

; (user def?) Highlight Attribute
BarClr equ 0x10*Blue + Bright ; Blue bgd, Bright text

CodeStart equ $
;; dl=CurrLine 0 to 24
;; bx=NewLine (actually bl)
;; parse parms? later

mov dx,Screen ; also CurrLine=dl=0
push dx
pop es ; es to Screen
mov dl,0x1A ; off screen 1st time 1A= 26 *160 =
4160> 4048

GoTop:
xor bx,bx ; NewLine=0
ReshowBar:

MoveBar: ; IN: dx=currline, bx=newline
; uses: di ; reqs ES=B800
; OUT: cx=0, dx=newline

;; Calc di=(CurrLine{dl}+StartRow)*ScrWidth+IndentAmt+1
mov ax,dx
add al,StartRow ; byte as maxrow=25
mov cl,ScrWidth
mul cl ; 1st time mul with ah=B8, it gets
cleared
add ax,IndentAmt+1 ; word reqd, add 1 for attr
xchg di,ax
;; Show
mov cx,BarWidth ; ensure ch=0 (is ok after 1st pass)
ChgAttr:
xor [es:di],byte BarClr ; add/del bkgd - Ok in 8086? yes
scasw ; di++ to next attr
loop ChgAttr
cmp dx,bx ; if 2nd time don't loop
mov dx,bx ; currline<-NewLine
jne MoveBar ; do 2nd run
;
InKey:
mov ah,0x10
int 0x16 ; getkey - affects ax only
mov al,ah ; because cmp al shorter
;; table lookup longer, so "if not then skip" it is
cmp al,KeyCsrUp
jne NotCU
;DoCU:
dec bl ; keep bh from going -ve
jge ReshowBar
;GoBot:
mov bl,NumRows
jmp ReshowBar

NotCU:
cmp al,KeyCsrDn
jne NotCD
;DoCD:
inc bx
cmp bl,NumRows
jle ReshowBar
jmp GoTop

NotCD:
cmp al,KeyEnter
je DoEnter
cmp al,KeyEsc
; je DoEsc
jne InKey ; ignore any other key
DoEsc:
mov dl,0xFE ; 1 gets added on exit
DoEnter:
mov al,dl ; exit code of selected line num
inc ax ; correct for off by one
Exit:
mov ah,0x4C
int 0x21
; end code

[Benjamin David Lunt]

"wolfgang kern" <now...@never.at> wrote in message

news:m95g88$hlc$2...@speranza.aioe.org...

>
>
> DOS ? does this mean to create a .com as boot-selector ?

No. I think the challenge, currently, is to simply place
a "cursor" on the current screen, a screen full of text that
is already there, and intentionally already there, and allow
the user to, by using the arrow keys, scroll up and down,
given a width, height, x & y coord's, and highlight color.

For example, if you are given (currently hard coded in the
code) an x/y coordinate of 30/15, a width of 10 and a
height of 8, modify the text attribute bytes at coord's
30/5, and 9 more times to the right, with the given attribute.

Then when the user presses the down arrow, restore the
10 bytes you modified above, and "highlight" the next
line down. Being sure to check for out of bounds first.

>> I could save 2 more bytes if you didn't care that I wrote to the
>> 64k block before 0xB8000.
>
> You sure don't mean 0xA8000 ?

Mode 3 Text is at 0xB8000.

>> Did anyone else give it a try?
>
> Not yet in the early boot process, but I once added a boot-option to my
> tools. It checks on all volumes in all drives, also the ones in extended
> partitions before this option is available.
> And the selection is already within my GUI [mouse/Kbd] and it wont show
> any non bootable items.

Look in another reply for my code.

Ben

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xsgac2jrmsr2db@dell3100...

> On Wed, 14 Jan 2015 00:17:52 -0000, Benjamin David Lunt <zf...@fysnet.net>
> wrote:
>

>
> mov dx,Screen ; also CurrLine=dl=0
> push dx
> pop es ; es to Screen

Unless you need the high byte of dx (dh) to be 0xB8, you can
save a few bytes by doing

push Screen
pop es

> mov dl,0x1A ; off screen 1st time 1A= 26 *160 =
> 4160> 4048
>
> GoTop:
> xor bx,bx ; NewLine=0

On entry from DOS, bx = 0. However, in your loop, do you maintain
it to be zero when you loop back to here?

> ReshowBar:
>
> MoveBar: ; IN: dx=currline, bx=newline
> ; uses: di ; reqs ES=B800
> ; OUT: cx=0, dx=newline
>
> ;; Calc di=(CurrLine{dl}+StartRow)*ScrWidth+IndentAmt+1
> mov ax,dx
> add al,StartRow ; byte as maxrow=25
> mov cl,ScrWidth
> mul cl ; 1st time mul with ah=B8, it gets
> cleared

This is where I used

imul ax,dx,ScrWidth


<snipped rest of code>

It looks like you are only allowing 80x86 code though. :-)

Here is my 76 byte version, using 80x386 code and assuming
DOS register startup values.

(please note that your news server may add multiple periods
to .model, .code, .386)

; assembled using nbasm:
; http://www.fysnet.net/newbasic.htm

ROW equ 5
COL equ 20
WIDTH equ 12
DEPTH equ 5

CLRATTR equ 07h
SETATTR equ 5Dh

.model tiny
.code
.386

org 100h

; ax = 0
; cx = 0
; bx = 0

mov ah,0B8h
mov es,ax

loop0: mov bl,ROW

loop1: imul di,bx,160
add di,(COL * 2)

mov cl,WIDTH
mov al,SETATTR
@@: inc di
stosb
loop @b

get_key: xor ah,ah
int 16h
shr ax,8 ; place code in al (clearing ah)

dec ax ; esc == 1
jz short error

cmp al,1Bh ; enter
je short exit

dec bx ; assume up
sub al,47h ; up arrow
jz short @f
inc bx ; restore row
sub al,08h ; assume down
jnz short get_key
inc bx ; was down

; al = 0
; restore the line
; this writes to screen memory before 0xB8000
@@: dec di
mov byte es:[di],CLRATTR
dec di
loop @b

cmp bl,(ROW + DEPTH)
jge short loop0

cmp bl,ROW
jge short loop1

mov bl,(ROW + DEPTH - 1)
jmp short loop1

exit: xchg bx,ax
sub al,(ROW - 1 - 1) ; -1 for the dec below

error: dec ax ; either 0xFF or 1 based ROW number
mov ah,4Ch
int 21h

.end

[Kerr Mudd-John]

On Wed, 14 Jan 2015 23:42:42 -0000, Benjamin David Lunt <zf...@fysnet.net>

wrote:

>
> "Kerr Mudd-John" <ad...@127.0.0.1> wrote in message
> news:op.xsgac2jrmsr2db@dell3100...
>> On Wed, 14 Jan 2015 00:17:52 -0000, Benjamin David Lunt
>> <zf...@fysnet.net>
>> wrote:
>>
>
>>
>> mov dx,Screen ; also CurrLine=dl=0
>> push dx
>> pop es ; es to Screen
>
> Unless you need the high byte of dx (dh) to be 0xB8, you can
> save a few bytes by doing
>
> push Screen
> pop es
>

I'm working on 8086, and at one time wanted dl=0

>
>> mov dl,0x1A ; off screen 1st time 1A= 26
>> *160 =
>> 4160> 4048

but then I had to kludge it.

>>
>> GoTop:
>> xor bx,bx ; NewLine=0
>
> On entry from DOS, bx = 0. However, in your loop, do you maintain
> it to be zero when you loop back to here?

yes it's the reset when going too far down

>
>> ReshowBar:
>>
>> MoveBar: ; IN: dx=currline, bx=newline
>> ; uses: di ; reqs ES=B800
>> ; OUT: cx=0, dx=newline
>>
>> ;; Calc di=(CurrLine{dl}+StartRow)*ScrWidth+IndentAmt+1
>> mov ax,dx
>> add al,StartRow ; byte as maxrow=25
>> mov cl,ScrWidth
>> mul cl ; 1st time mul with ah=B8, it
>> gets
>> cleared
>
> This is where I used
>
> imul ax,dx,ScrWidth
>
>
> <snipped rest of code>
>
> It looks like you are only allowing 80x86 code though. :-)
>

that'd be it!

cx is now 0

> get_key: xor ah,ah
> int 16h
> shr ax,8 ; place code in al (clearing ah)
>
> dec ax ; esc == 1
> jz short error
>
> cmp al,1Bh ; enter
> je short exit
>
> dec bx ; assume up
> sub al,47h ; up arrow
> jz short @f
> inc bx ; restore row
> sub al,08h ; assume down
> jnz short get_key
> inc bx ; was down
>
> ; al = 0
> ; restore the line
> ; this writes to screen memory before 0xB8000

isn't cx 0 still?
I've not tested this

> @@: dec di
> mov byte es:[di],CLRATTR
> dec di
> loop @b
>
> cmp bl,(ROW + DEPTH)
> jge short loop0
>
> cmp bl,ROW
> jge short loop1
>
> mov bl,(ROW + DEPTH - 1)
> jmp short loop1
>
> exit: xchg bx,ax
> sub al,(ROW - 1 - 1) ; -1 for the dec below
>
> error: dec ax ; either 0xFF or 1 based ROW number
> mov ah,4Ch
> int 21h
>
> .end
>
>
>


--

Bah, and indeed, Humbug

[Kerr Mudd-John]

Curses! it's 84 bytes, and the "NumRows" code is Off by One. change it to
NumRows-1

[Benjamin David Lunt]

"Kerr Mudd-John" <ad...@127.0.0.1> wrote in message

news:op.xsh4gsckmsr2db@dell3100...

> On Wed, 14 Jan 2015 23:42:42 -0000, Benjamin David Lunt <zf...@fysnet.net>
> wrote:
>>
>> ; al = 0
>> ; restore the line
>> ; this writes to screen memory before 0xB8000
>
> isn't cx 0 still?
> I've not tested this
>> @@: dec di
>> mov byte es:[di],CLRATTR
>> dec di
>> loop @b
>>

Yes, cx should still be zero. However, my comment above
is wrong. I spend most of my assembly programming with
a flat address space, so when I stated that the above
code would modify the address before 0xB8000 when in fact
it will modify the 64k above 0xB8000.

If CX = zero in the above code, it will place a CLRATTR
in every other byte from 0xB8000 + 0x0FFFF down to
0xB8000. Still okay, since all of that memory is video
memory. However, my comment above is incorrect.

I guess it has been a while since I have spent any
time in real mode. :-)

Ben

[James Harris]

"Rod Pemberton" <bu...@notnotnontnooatno.cmm> wrote in message
news:op.xsfanbncv6dtjm@localhost...

...

>> ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf

...

> Does anyone know what situation the A20GATE pass through is for?

Just for anyone following this thread: I though the topic you brought up
deserved a new thread so have posted with the subject "USB UHCI A20GATE pass
through sequence".


James

[wolfgang kern]

Kerr Mudd-John wrote:

...
> Shorter the better!
...

>> Did anyone else give it a try? I will post my code if no one objects.

> Please do; I'll post mine; I was nearly going to earlier, but I've managed
> to improve it a little since.

> I don't think there's anyone here but you, me and Wolfgang plus Rod
> occasionally. Seems even Rosario's dropped out of the assembler groups.

Ok, now I can see what's the target of all this ..
From your example I see four line-text-items starting at:
row 2 col 3 width 40 with the assumption that there is already
something on screen in textmode 03.


so let me try it as a 'DOS .com':
(even I'm more familiar with hex than text source asm)

ORG 100
push 0xb800
pop es
first:
xor si,si ;row index, zero based
mov bx,0x03 ;bx= max row index
high:
mov al,0x70 ;or whatsoever highlight color is desired
call set_attr ;[ 14 ]
key:
mov ah,0x00 ;get key
int 0X16
mov al,ah
not al
cmp al,0xfe ;not01[ESC]
jz exit
cmp al,0xe3 ;not1c[ENTER]
jz done
cmp al,0xa7 ;not48[UP]
jz incr
cmp al,0xaf ;not50[DN]
jnz key
call un_high ;unhighlight current row
dec si
jnl high ;>=0
mov si,bx ;last item row index
jmp short high ;[ 48 ]
incr:
call un_high
inc si
cmp si,bx ;max row index
jbe high ;<=
jmp short first ;[ 58 ]
done:
xchg ax,si
exit:
inc ax
mov ah,0x4c
int0x21 ;[ 64
;---------
un_high:
mov al,0x07 ;like standard yet
set_attr: ;rel.row in si, col=fixed, forg/back in al
lea di,[si+0x02] ;add start-row (hardcoded to 2 yet)
mov cx,0x28 ;text_width= 40
imul di,di,word 0xA0 ; *80*2
add di,byte 0x6 ; +2*Column (hardcoded to col 3 yet)
L0:
inc di ;attributes only
stosb
loop L0
ret ;[+20 = 84 bytes]
;===============

I might have saved one or two bytes if I'd used BL and BH instead
of SI and BX, and perhaps two or three more by avoiding calls.

my very old textmode3 un/high-light used just color swap:

rol byte [di+1],4 ;swap back,forg

your xor-variant may not work for all desired color combinations
and will depend on attributes already on screen.

but your CMPSW is a neat trick, even assuming CLD.

__
wolfgang
btw: data-labels make me flip pgup/pgdn and search all the time :)

[Kerr Mudd-John]

On Thu, 15 Jan 2015 18:29:06 -0000, wolfgang kern <now...@never.at> wrote:

>
> Kerr Mudd-John wrote:
>
> ...
>> Shorter the better!
> ...

> Ok, now I can see what's the target of all this ..
> From your example I see four line-text-items starting at:
> row 2 col 3 width 40 with the assumption that there is already
> something on screen in textmode 03.
>

yes, the starting point for me was "select a partition to boot from"
then I forgot about the display partition line and concentrated on the
highlight menu code, as this could be used in a batch program.

>
> so let me try it as a 'DOS .com':
> (even I'm more familiar with hex than text source asm)
>
> ORG 100
> push 0xb800
> pop es
> first:
> xor si,si ;row index, zero based
> mov bx,0x03 ;bx= max row index
> high:
> mov al,0x70 ;or whatsoever highlight color is desired
> call set_attr ;[ 14 ]
> key:
> mov ah,0x00 ;get key
> int 0X16
> mov al,ah
> not al

Please tell me why you reverse the test with NOT?

> cmp al,0xfe ;not01[ESC]
> jz exit
> cmp al,0xe3 ;not1c[ENTER]
> jz done
> cmp al,0xa7 ;not48[UP]

I get 0xB7 on testing
> jz incr
Cursor Down to move the bar down I find more intuitive!

great in monochrome!

> your xor-variant may not work for all desired color combinations
> and will depend on attributes already on screen.
>
> but your CMPSW is a neat trick, even assuming CLD.

erm, I used "SCASW" to save an "INC di"!
point taken about CLD

>
> __
> wolfgang
> btw: data-labels make me flip pgup/pgdn and search all the time :)
>

I'd hoped it was neater!

[Kerr Mudd-John]

On Thu, 15 Jan 2015 19:54:14 -0000, Kerr Mudd-John <ad...@127.0.0.1> wrote:

> On Thu, 15 Jan 2015 18:29:06 -0000, wolfgang kern <now...@never.at>
> wrote:
>
>>
>> Kerr Mudd-John wrote:
>>
>> ...

> Please tell me why you reverse the test with NOT?

I see it now, sets return code FF on Escape; ingenious!
[]

>> done:
>> xchg ax,si
>> exit:
>> inc ax
>> mov ah,0x4c
>> int0x21 ;[ 64

[James Harris]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:m7nsps$shd$1...@speranza.aioe.org...
>
> "James Harris" <james.h...@gmail.com> wrote in message
> news:m7nk0h$35h$1...@dont-email.me...

...

>> .... A simpler and shorter task may seem less daunting and encourage more
>> folk to enter while still providing the same element of challenge.

...

> With the hugi compo's, we discussed the rules before hand, allowed
> all to comment, add, change, etc., on the rules before the compo
> started.

...

> Anyway, if there is enough interest, I am sure Adok (the host of
> the Hugi Compo) won't mind if we host another compo.
>
> Any ideas?

It's hard to come up with a good competition idea. To be motivating it needs
to be practical - something relevant to an OS so that it can fit in to this
newsgroup - but also to be verifiable. A size metric may make entries easy
to compare but not something we would use in practice. Readable or fast code
may be better but would be harder to judge. So I cannot think of a good
competition challenge, sorry.

James

[wolfgang kern]

James Harris wrote:

>>> .... A simpler and shorter task may seem less daunting and encourage
>>> more >>> folk to enter while still providing the same element of
>>> challenge.

> ...

>> With the hugi compo's, we discussed the rules before hand, allowed
>> all to comment, add, change, etc., on the rules before the compo
>> started.

> ...

>> Anyway, if there is enough interest, I am sure Adok (the host of
>> the Hugi Compo) won't mind if we host another compo.

>> Any ideas?

> It's hard to come up with a good competition idea. To be motivating it
> needs to be practical - something relevant to an OS so that it can fit in
> to this newsgroup - but also to be verifiable. A size metric may make
> entries easy to compare but not something we would use in practice.
> Readable or fast code may be better but would be harder to judge. So I
> cannot think of a good competition challenge, sorry.

Sorry James, but I'm with Ben on that matter.

if we can wake interest in competitions for basic OS-needs or even
for just trivial functions, then we might see more newbees in this
our group and we could invite CLAX and ALA to participate to learn
and to show how a CPU works at all in deep detail (and we learn too).

It's not for nothing of course, we (the regular readers/posters)
can learn a lot about demands and misunderstanding in how we see a
machine in opposition to what's thought in CS- and similar 'lessons'.
[I replaced the last word in the previous sentence for politness]
__
wolfgang

[Rod Pemberton]

On Fri, 16 Jan 2015 08:16:12 -0500, James Harris
<james.h...@gmail.com> wrote:
> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
> news:m7nsps$shd$1...@speranza.aioe.org...

>> Any ideas?
>
> It's hard to come up with a good competition idea. To be motivating it
> needs to be practical - something relevant to an OS so that it can fit
> in to this newsgroup - but also to be verifiable. A size metric may
> make entries easy to compare but not something we would use in practice.
> Readable or fast code may be better but would be harder to judge. So
> I cannot think of a good competition challenge, sorry.

What? Is there no creativity here? ...

I can come up with ideas, even if I'm unlikely to code them:

smallest 16-bit disassembler
smallest 16-bit debugger with a few required commands
smallest v86 mode monitor that will let DOS and/or BIOS run correctly
smallest one-month text calendar
ASCII string compression routine
fastest 8086 16-bit sequence replacing some later instruction (XLAT, SETcc)
fastest screen clear for a specific video mode - *cannot* use REP MOVS
mini 16-bit to 32-bit binary translator
some type of 16-bit code accelerator ...
smallest useful device driver (an OS would need to be selected...)
ASCII text asteroids game
ASCII text space invaders


Rod Pemberton

[Benjamin David Lunt]

"Rod Pemberton" <bu...@notnotnontnooatno.cmm> wrote in message

news:op.xskzoqbrv6dtjm@localhost...

Hi Rod,

Here are my comments.

> smallest 16-bit disassembler

Easy to test using a text file compare.

entry < test1.bin > test1.asm
fc test1.asm test1.tst

> smallest 16-bit debugger with a few required commands

Not as easy to test.

> smallest v86 mode monitor that will let DOS and/or BIOS run correctly

"run correctly" is a very vague requirement. :-) Very difficult to test.

> smallest one-month text calendar

Easy to test.

entry < 3 > march.txt
fc march.txt march.tst

> ASCII string compression routine

Again, easy to test.

> fastest 8086 16-bit sequence replacing some later instruction (XLAT,
> SETcc)
> fastest screen clear for a specific video mode - *cannot* use REP MOVS

I never thought that the "fastest" competitions were viable. Fastest
for what machine? If you chose a target, how can those who don't have
a similar target platform test to see if their code is faster or not?

> mini 16-bit to 32-bit binary translator
> some type of 16-bit code accelerator ...

Don't know what you are suggesting about those two.

> smallest useful device driver (an OS would need to be selected...)

This would need details and then more details :-)

> ASCII text asteroids game
> ASCII text space invaders

These would be fun. Boreal and a few others in the Hugi Compo
created some test suites to capture the screen on every keypress
to compare the current position with a test position. Could
port one of those tests to test these.

Just my comments. My opinion would be the last two suggestions,
though I would leave it to someone else to port the test suite(s).

Thanks,
Ben

[James Harris]

"wolfgang kern" <now...@never.at> wrote in message

news:m9c4mi$kgt$1...@speranza.aioe.org...

>
> James Harris wrote:
>
>>>> .... A simpler and shorter task may seem less daunting and encourage
>>>> more >>> folk to enter while still providing the same element of
>>>> challenge.
>
>> ...
>
>>> With the hugi compo's, we discussed the rules before hand, allowed
>>> all to comment, add, change, etc., on the rules before the compo
>>> started.
>
>> ...
>
>>> Anyway, if there is enough interest, I am sure Adok (the host of
>>> the Hugi Compo) won't mind if we host another compo.
>
>>> Any ideas?
>
>> It's hard to come up with a good competition idea. To be motivating it
>> needs to be practical - something relevant to an OS so that it can fit in
>> to this newsgroup - but also to be verifiable. A size metric may make
>> entries easy to compare but not something we would use in practice.
>> Readable or fast code may be better but would be harder to judge. So I
>> cannot think of a good competition challenge, sorry.
>
> Sorry James, but I'm with Ben on that matter.

No need for an apology! Differences of opinion are what fuel discussion.

> if we can wake interest in competitions for basic OS-needs or even
> for just trivial functions, then we might see more newbees in this
> our group and we could invite CLAX and ALA to participate to learn
> and to show how a CPU works at all in deep detail (and we learn too).

Whether that is practical or not it seems worth trying if some ideas are
forthcoming. Recent posters have expressed an interest in such things.

> It's not for nothing of course, we (the regular readers/posters)
> can learn a lot about demands and misunderstanding in how we see a
> machine in opposition to what's thought in CS- and similar 'lessons'.
> [I replaced the last word in the previous sentence for politness]

Have you read Inner Loops by Rick Booth? It is one of the most interesting
books I have read in the past 20 years. In one part of it the author talks
about breaking the normal rules in order to achieve speed. I was resistive
to the idea at first but even his rule-breaking assembly code is very easy
to read so I came round to the idea for use when appropriate. It is one of
those books that made me think differently about a number of programming
topics.

James

[Kerr Mudd-John]

On Sat, 17 Jan 2015 03:49:52 -0000, Benjamin David Lunt <zf...@fysnet.net>
wrote:

>
> "Rod Pemberton" <bu...@notnotnontnooatno.cmm> wrote in message
> news:op.xskzoqbrv6dtjm@localhost...

[]
Games:

>> ASCII text asteroids game
>> ASCII text space invaders

ASCII Tetris! I saw a text mode "Game of Life" once. It used the IBM
character set that had
upper block, lower block and filled block; ah, I found a table: DB-DF.

Please, not another rogue-like!

[]

[Steve]

"Kerr Mudd-John" <ad...@127.0.0.1> writes:
>On Sat, 17 Jan 2015 03:49:52 -0000, Benjamin David Lunt <zf...@fysnet.net>
>wrote:
>
>>
>> "Rod Pemberton" <bu...@notnotnontnooatno.cmm> wrote in message
>> news:op.xskzoqbrv6dtjm@localhost...
>[]
>Games:
>>> ASCII text asteroids game
>>> ASCII text space invaders
>
>ASCII Tetris! I saw a text mode "Game of Life" once. It used the IBM
>character set that had
>upper block, lower block and filled block; ah, I found a table: DB-DF.

Hi,

Well I wrote a text mode Tetris a while baack. As it is
at least ten to twenty times larger that some others I have
seen, it is unlikely to be much of a starting point for a
compo. But it was an interesting project.

Regards,

Steve N.

[Kerr Mudd-John]

On Tue, 20 Jan 2015 12:48:54 -0000, Steve <Bo...@embarq.com> wrote:

> "Kerr Mudd-John" <ad...@127.0.0.1> writes:
>> On Sat, 17 Jan 2015 03:49:52 -0000, Benjamin David Lunt
>> <zf...@fysnet.net>
>> wrote:
>>
>>>
>>> "Rod Pemberton" <bu...@notnotnontnooatno.cmm> wrote in message
>>> news:op.xskzoqbrv6dtjm@localhost...
>> []
>> Games:
>>>> ASCII text asteroids game
>>>> ASCII text space invaders
>>
>> ASCII Tetris! I saw a text mode "Game of Life" once. It used the IBM
>> character set that had
>> upper block, lower block and filled block; ah, I found a table: DB-DF.
>

There's an example program for fasm which does "life", I've recently found.

> Hi,
>
> Well I wrote a text mode Tetris a while baack. As it is
> at least ten to twenty times larger that some others I have
> seen, it is unlikely to be much of a starting point for a
> compo. But it was an interesting project.
>

It's all a bit late now, but it seems Tetr^w the falling block game was
done in 2003:
http://www.hugi.scene.org/compo/compoold.htm#compo22

[Kerr Mudd-John]

On Fri, 16 Jan 2015 23:30:16 -0100, Rod Pemberton
<bu...@notnotnontnooatno.cmm> wrote:

> On Fri, 16 Jan 2015 08:16:12 -0500, James Harris
> <james.h...@gmail.com> wrote:
>> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
>> news:m7nsps$shd$1...@speranza.aioe.org...
>
>>> Any ideas?
>>
>> It's hard to come up with a good competition idea. To be motivating it
>> needs to be practical - something relevant to an OS so that it can fit
>> in to this newsgroup - but also to be verifiable. A size metric may
>> make entries easy to compare but not something we would use in practice.
>> Readable or fast code may be better but would be harder to judge. So
>> I cannot think of a good competition challenge, sorry.
>
> What? Is there no creativity here? ...
>
> I can come up with ideas, even if I'm unlikely to code them:
>
> smallest 16-bit disassembler
> smallest 16-bit debugger with a few required commands
> smallest v86 mode monitor that will let DOS and/or BIOS run correctly
> smallest one-month text calendar

I have a "current date" info in 256 bytes

> ASCII string compression routine
> fastest 8086 16-bit sequence replacing some later instruction (XLAT,
> SETcc)
> fastest screen clear for a specific video mode - *cannot* use REP MOVS

> mini 16-bit to 32-bit binary translator

more useful might be 64 to 32 to allow DOS apps under later OS's

> some type of 16-bit code accelerator ...
> smallest useful device driver (an OS would need to be selected...)
> ASCII text asteroids game

tricky, given it's vector nature.
> ASCII text space invaders
I now have (after some jiggling) a 244 version of the 256 byte posted
code for INVaders
by James David Chapman (web site accessed by the archive.org - sadly he
seems out of contact)
the game (as he coded, and mine) lacks a score table, and even any
collision of invaders with the spaceship.
So not really the full game!

>
> Rod Pemberton