Add NEC PC-98 support to ELKS

[ghaerr]

This issue is being opened to discuss porting issues and merging the development @tyama501 is doing into master.

This continues the discussion started in #1040.

I will produce a more detailed list of discussion items shortly.

[tyama501]

Hello @ghaerr ,

From #1040

you're booting from 1232K floppy which use 1K sectors, correct?

Correct.

It seems the FAT filesystem driver may still be assuming 512 byte sectors when it reports 616K disk in fat12 format.

Yes, we need to fix the message.

Do all PC-98 systems support 4 floppies? I notice that you've added FD2 and FD3 support, but don't see them in the picture.

Most of older PC-9801 can add 2 more Floppy Drives through the interface connector at the back of the PC. I use 3 Floppy Drives with PC-9801RX21. I didn't know how to get real drive count so I fix it to 4 drives. Since I haven't supported hard drives so more than 2 is better.

With regards to the CPU being identified as V20, actually I do not trust the current CPU detection code,

I see. But I might did something wrong with setup.S. I remember when I started to modify setup.S at the very beginning it was identified as V30.

I look forward to getting your enhancements and machine support merged into master.

Me too. Thanks.

[ghaerr]

Hello @tyama501,

(reposted from incorrect thread...)

For the first round of merges, I'm thinking of moving most I/O port addresses into ports.h, and grouping all the PC-98 ports together, vs IBM PC. For example, PIC_xxx in irq-8259.c, and then defining a PIC_EOI (end of interrupt, for instance 00h instead of 20h, etc) that can be used from ports.h in irqtab.S.

Q: In irq-8259.c, I notice inb_p can't be used, is that because the OUT %al,$0x80 write to port 80h is not allowed on PC-98? I am thinking how to best handle this without ifdefs. We might be ab le to redefine inb_p in arch/io.h if PC-98 never needs delays, for instance.

Q: Can you give more information on the two floppy formats, 1232K vs 1440K? Are they both 1K sectors? Or is 1440K compatible with the IBM 1440k format? I am thinking we should probably have a seperate define for ELKS to be built using 1K sectors, although this might be able to be contained completely at the driver level. I will need to look at this more.

All of the early_putchar etc routines should be moved out of crt0.S and put into a new .S file, just for PC-98. These should probably be moved to the char drivers directory and be renamed as part of the headless console (conio-pc98-asm.S) for PC-98.

Also, CONFIG_CONSOLE_DIRECT should not be defined and thus not need ifdefing out which was possibly done early in your porting. You may want to create your own console-headless-pc98.c entirely with all your tvram and ESC sequence processing, at least in the beginning. Likewise kbd-poll.c ifdefs can be made better by using a custom conio-pc98.c We can then make changes to the Makefile to include the appropriate files when CONFIG_ARCH_PC98 is defined. This will keep all the console stuff seperate. Another later approach would be to integrate the PC-98 console underneath the BIOS console, but we'll talk about that later.

I can put together the first PR to show you some of these ideas, and then you could follow up with additional PRs based on discussion. Or you could do them all, which would you prefer? We could do this with a series of small PRs so that you don't have to work too much to keep a working PC-98 version in sync on your repo.

Thank you!

[tyama501]

@ghaerr Thank you for explaining.

Q: In irq-8259.c, I notice inb_p can't be used, is that because the OUT %al,$0x80 write to port 80h is not allowed on PC-98?

I think there is no device ( or different device ) at port 80h.

Q: Can you give more information on the two floppy formats, 1232K vs 1440K? Are they both 1K sectors? Or is 1440K compatible with the IBM 1440k format?

1440K is 512Bytes per sector which (I think) compatible with IBM PC but it can only be used with newer PC in 90's which I don't have. I can only test with emulator like Neko Project 21/W.

All of the early_putchar etc routines should be moved out of crt0.S and put into a new .S file, just for PC-98.

Yes, I wanted to do this but somehow I couldn't build at another file.

I can put together the first PR to show you some of these ideas, and then you could follow up with additional PRs based on discussion.

It would be very nice if you can do this to understand your idea better.

I only have worked at configuration in elks/sample_pc98/autoconf_pc98.h and config_pc98. CONFIG_CONSOLE_DIRECT is not set. Right now both CONFIG_ARCH_IBMPC and CONFIG_ARCH_PC98 are needed. This should be resolved.

[ghaerr]

It would be very nice if you can do this to understand your idea better.

Ok, I'll post something to start the process. Hopefully we can keep your version running during this process.

All of the early_putchar etc routines should be moved out of crt0.S and put into a new .S file, just for PC-98. Yes, I wanted to do this but somehow I couldn't build at another file.

The easiest way to start would be to copy crt0.S to conio-pc98-asm.S, then delete all crt0.S code, leaving just your new code. Move this to arch/i86/drivers/char and change the Makefile in that directory to include that file for CONFIG_ARCH_PC98. I advise you also rename console-headless.c to console-headless-pc98.c since there are so many changes.

I'm thinking perhaps a good split of initial work would be for you to get the console I/O changed into its own set of .c/.S files, based on the above, and working, which will mostly seperate any ifdefs to the other console drivers. You can then submit a PR for that for discussion. The files would he console-headless-pc98.c, conio-pc98.c and conio-asm-pc98.S.

I will work on other internals as discussed above. This should hopefully allow you to pull from upstream into your repo without much work, and we will continue discussing while minimizing the repo differences, keeping both operational during the process.

I only have worked at configuration in elks/sample_pc98/autoconf_pc98.h and config_pc98.

That's fine for now, We will soon add a config.in setting for CONFIG_ARCH_PC98, and then you can create/move your custom configuration to a new checked-in file 'pc98.config', which will be used to copy to .config for testing and auto-create of autoconf.h.

CONFIG_CONSOLE_DIRECT is not set.

Good, go ahead and remove the ifndefs you have in your tree around them. (see kernel/timer.c etc). You won't need the guard around rs_pump either in that file since CONFIG_FAST_IRQx won't be set.

Right now both CONFIG_ARCH_IBMPC and CONFIG_ARCH_PC98 are needed. This should be resolved.

Yes, that's a problem. Let me look more into that. For the time being, we might just create a pc98.config that can be copied into .config, that automatically creates autoconf.h with 'make'. If that works, you can submit pc98.config along with your console changes.

[ghaerr]

I think there is no device ( or different device ) at port 80h.

Does that mean inb_p fails? I am trying to understand whether we can use it unmodified or not. On the PC, there is nothing at 80h, it just creates a delay.

1440K is 512Bytes per sector which (I think) compatible with IBM PC but it can only be used with newer PC in 90's which I don't have.

Lets assume it is compatible. In that case, the tests for CONFIG_IMG_1440 in bios16.S and elsewhere should be reversed - test for CONFIG_IMG_1232 and leave the default code unchanged.

After a little more discussion, we can decide on specific files that are OK to merge with a PR from you or myself. I am currently using 'diff -urN' between our cloned source trees for rapid comparison. We're not too far apart!

[tyama501]

@ghaerr 80h seems to have reserved for hard drives. I'm not sure it fails or not for invalid access. http://radioc.web.fc2.com/column/pc98bas/pc98ioic.htm

We cannot use int16 even for 1440. I modified to use int1B instead. INT 1Bh (DISK BIOS) http://radioc.web.fc2.com/column/pc98bas/bios/disk.htm So the file name is not good.

It's almost morning in JST-9. I'm gonna sleep. Thank you!

[tyama501]

Hello @ghaerr ,

The easiest way to start would be to copy crt0.S to conio-pc98-asm.S, then delete all crt0.S code, leaving just your new code. >Move this to arch/i86/drivers/char and change the Makefile in that directory to include that file for CONFIG_ARCH_PC98. I >advise you also rename console-headless.c to console-headless-pc98.c since there are so many changes.

I agree this but original printk.c in kernel uses early_putchar. How do we handle this with out making changes to crt0.S?

[ghaerr]

How do we handle this with out making changes to crt0.S?

One of the reasons I am interested in your porting project is that it illuminates more areas where ELKS has functionality dependent on BIOS (and hardware), but in source files not adapted for portability. In this case, early_putchar was stuffed into crt0.S likely because it was a short routine using BIOS int 10h. It doesn't belong in crt0.S, but somewhere in the console routines in elks/arch/i86/drivers/char.

Your input is helping us see all the issues involved, even those before we start. Thank you! Let's keep talking about PC-98 issues and I will plan on making the initial more major moves of getting the source more adapted to facilitating your PC-98 port.

We cannot use int16 even for 1440. I modified to use int1B instead. INT 1Bh (DISK BIOS) http://radioc.web.fc2.com/column/pc98bas/bios/disk.htm

Thank you for the INT 1B BIOS routine page, that helps seeing the bigger picture.

So the file name is not good.

Agreed. I'm thinking your entire call_bios routine for int 1Bh should probably go into it's own file named bios1B.S.

Given that there are so many issues like this, it is just as well we continue discussing points before starting to change things too quickly.

[ghaerr]

Hello @tyama501,

Other issues I see coming up:

• Boot code: BIOS-specific routines may have to be moved out of boot_sect.S to another .S file, including int 12h get memory size, int 16h keyboard wait, _putc, _puts, drive_num, etc. Since there are so many changes, and the fact that the IBM PC boot code is very tight, it might be a better idea for PC-98 to have it's own boot code source file. We will have to think about this.
• Same issue for setup.S, where we will definitely want to move BIOS-specific code to another file, including int 12h get mem size, putc, and likely VGA and CPU detection out. Unlike the boot sector, we don't want to keep separate versions of setup.S, and instead try to keep setup.S system-independent as possible.
• Thinking about using a CONFIG_1K_SECTORS instead of CONFIG_IMG_1232 to indicate 1K sector size, to uncouple the sector size from a single floppy setting.
• For bioshd.c, we'll likely keep most of the changes, with some possible slight reorganization of the fixed-format drive types, instead of probing for PC-98.
• For config.h, we'll probably keep the changes but arrange them as a duplicate section for the time being, with all PC-98 settings grouped together.
• For the 1K sector size issues, probably a few more defines for sector size issues showing up in msdos/misc.c and ll_rw_blk.c.

This may take a bit to get organized around, but it will be worth it! I still plan on putting together the first PRs, thank you!

[tyama501]

@ghaerr

Thank you for the reply and ideas. OK, let's think the best way we can do for the portability.

On the other hand, may I share some known issue for PC-98? (1) A20 Memory error occurs with reboot command (PC-9801RX21, intel286) There is a hardware memory check when power on and usually like this.

But when reboot command is used it say like this. I'm not sure why this happen.

(2) cannot use arrow keys I have not implemented to move cursors.

(3) vi (elvis?) is not working properly It can run but not working properly. I have not implemented to handle sequence of vi.

[ghaerr]

(1) A20 Memory error occurs with reboot command (PC-9801RX21, intel286)

Using reboot command, this ends up calling hard_reset_now() in the kernel which is the following:

void hard_reset_now(void)
{
#ifdef __ia16__
    asm("mov $0x40,%ax\n\t"
        "mov %ax,%ds\n\t"
        "movw $0x1234,0x72\n\t"
        "ljmp $0xFFFF,$0\n\t"
        );
#endif
}

This code loads 1234h into BIOS data area 40:0072, then jumps to FFFF:0000, which is a hard reboot on the IBM PC. Apparently this is not implemented in PC-98.

cannot use arrow keys I have not implemented to move cursors. I have not implemented to handle sequence of vi.

I do not recommend you re-code the escape sequence processing by hand in headless-console.c. Instead, almost all ESC sequence processing is shared in drivers/char/console.c. This file is included in both the direct console and BIOS console drivers. Depending on the architecture of PC-98, you might reconsider and use a modified version of either of these consoles for PC-98. If the screen is memory-mapped, then direct console, otherwise BIOS console. The BIOS console sits on top of a group of BIOS functions that write to the actual PC console. These could be rewritten for PC-98, using something similar to console-bios-asm.S or possibly and console-bios.c. See the file console-bios.c for details. We can talk more about this as you tell me what PC-98 real console is handled programmatically.

[ghaerr]

@tyama501,

Looking further at some of your code, it seems that PC-98 has video ram at segment A000. This probably means that we should think about using direct console rather than the headless console with hand-coded ESC processing. The following code in drivers/char/console-direct.c does the initialization, which would have to change:

void console_init(void)
{
    register Console *C;
    register int i;
    unsigned PageSizeW;
    unsigned VideoSeg;

    MaxCol = (Width = peekb(0x4a, 0x40)) - 1;  /* BIOS data segment */ <-- max columns at 40:4A

    /* Trust this. Cga does not support peeking at 0x40:0x84. */
    MaxRow = (Height = 25) - 1;
    CCBase = (void *) peekw(0x63, 0x40); <-- base "page" for multiple page support
    PageSizeW = ((unsigned int)peekw(0x4C, 0x40) >> 1);

    VideoSeg = 0xb800; <- EGA video segment
    if (peekb(0x49, 0x40) == 7) { 
        VideoSeg = 0xB000; <- MDA (mono) video segment
        NumConsoles = 1;
    }

I have indicated some of the changes necessary; the IBMPC version uses the BIOS Data Area (BDA) at segment 40h to get some initial video parameters. All this would likely have to change, as well as the base video memory segment.

The file console-direct.c would likely have to be copied to another file console-pc89.c (and include console.c). The current ELKS direct console programs the IBM PC 6845 CRTC controller, (for cursor), which you will likely need to change.

This could possibly be integrated with early_putchar and the boot _putc code by using the BDA to store the cursor information, for instance, but that's more to think about. For now, you might consider whether moving to direct console could be a good idea for you to support all the cursor-based programs like vi.

[tyama501]

Hello @ghaerr , Thank you for the great information!

PC-98 has text vram and graphic vram. The text vram starts from address A0000h and it is double byte for Japanese kanji character ROM. Now I only focus on English so I use only LS byte.

I wanted to use direct-console but I got trouble ( which I forgot what was ) and start using headless console. It is great if I can use it so I will reconsider!

In that case there will be console-headless-pc98 and console-direct-pc98 and the formar specification will be as is.

[ghaerr]

The text vram starts from address A0000h and it is double byte for Japanese kanji character ROM. Now I only focus on English so I use only LS byte.

I see, so if the MS byte is 0 then LS byte = ASCII? And no attribute byte, always white on black? Otherwise format is EUCJP or JISX0213 in DBCS format?

It is great if I can use it so I will reconsider!

Yes, we will want to use direct console with modifications initially discussed above.

In that case there will be console-headless-pc98 and console-direct-pc98 and the formar specification will be as is.

You can choose whether you want to port your existing work on headless console for now (first), or get direct console working on your repo first instead, and only port that. I can help with the direct console and either should be selectable dependent on CONFIG_CONSOLE_DIRECT vs CONFIG_CONSOLE_HEADLESS.

[tyama501]

@ghaerr

I think LS byte is ASCII and JIS for double bytes but I don't know what kind of JIS. It can change color since I see different color with dos applications but I don't know how to do that yet.

I would like to port headless console first since it will take time to work direct-console.

[tyama501]

Hello @ghaerr ,

I separated code from crt0.S and created conio-pc98-asm.S, console-headless-pc98.c experimentally but I couldn't build as before. I pushed these files to merge_pc98 branch of my repository. Only ifndef CONFIG_ARCH_PC98 to delete early_putchar for IBM PC are remained in crt0.S.

I couldn't assemble conio-pc98-asm. Which part of Makefile should I put these files?

This didn't work. ifeq ($(CONFIG_ARCH_PC98), y) CONIO = pc98-asm SERIAL = 8250 OBJS += lp.o endif ... ifdef CONFIG_CONSOLE_HEADLESS ifdef CONFIG_ARCH_PC98 OBJS += console-headless-pc98.o conio-pc98-asm.o else OBJS += console-headless.o endif endif

[ghaerr]

I separated code from crt0.S and created conio-pc98-asm.S, console-headless-pc98.c

Sounds good!

I couldn't assemble conio-pc98-asm

What is the error produced? I can't quite tell what is happening. Perhaps for now ifdef your code entirely with ifdef CONFIG_ARCH_PC98 and 'else' everything else to help debug. We can sort out the exact proper Makefile later.

Only ifndef CONFIG_ARCH_PC98 to delete early_putchar for IBM PC are remained in crt0.S.

Great. I plan on moving that code out just as you're doing for PC-98.

[tyama501]

Hello @ghaerr ,

It seems I can't use CONFIG_ARCH_PC98 in Makefile so I just comment out and modified as follows for now. I could make image and it is working at least NekoProject 21/w emulator. Thanks.

ifdef CONFIG_CONSOLE_HEADLESS

OBJS += console-headless.o

OBJS += console-headless-pc98.o conio-pc98-asm.o endif

ifdef CONFIG_KEYBOARD_SCANCODE OBJS += kbd-scancode.o else

OBJS += kbd-poll.o conio-$(CONIO).o

OBJS += kbd-poll.o conio-pc98-asm.o endif endif

[ghaerr]

It seems I can't use CONFIG_ARCH_PC98 in Makefile so I just comment out and modified as follows for now.

I think this is because your .config is not setting CONFIG_ARCH_PC98=y perhaps? And you are using a checked-in autoconf.h. I need to add CONFIG_ARCH_PC98 into elks/config.in, and then have you generate a working .config using make menuconfig. You will then be able to test CONFIG_ARCH_PC98 in all Makefiles. We will then want to have you submit your working .config as pc98.config so that we can both test your build by using cp pc98.config .config; make.

You mentioned other problems with having to have both CONFIG_ARCH_IBMPC and CONFIG_ARCH_PC98 defined. We need to work on that next, as only one can be defined. Can you state where the remaining problems are?

I could make image and it is working at least NekoProject 21/w emulator.

Great! I have still been a bit delayed getting the first changes ready for you as I have been traveling, but will soon!

[tyama501]

Hello @ghaerr,

Thank you for your updates!

I did grep to find CONFIG_ARCH_IBMPC in my repository. The only file I haven't added "|| defined(CONFIG_ARCH_PC98)" was kernel/irqtab.S and you added it in your PR. So maybe no more problems. I will look your PR farther.

[tyama501]

Just for information.

Neko Project 21/W emulator can be downloaded from here. BIOS is emulated by the host so you don't need any bios rom data from the real PC. (You can use bios rom data too.) https://simk98.github.io/np21w/ https://simk98.github.io/np21w/download.html

It is based on open source so there is Linux ver. Neko Project II kai. https://github.com/AZO234/NP2kai

[ghaerr]

Hello @tyama501,

Neko Project 21/W emulator can be downloaded from here.

Thank you, I was going to look for that. I develop on macOS so I will hope it will be an easy port, otherwise I can setup a Linux VM with some more work. For now, I will still depend on you for testing, thank you!

[ghaerr]

Hello @tyama501,

PR #1055 is the last kernel code change I think we needed to make to bring our repositories in sync. After that is tested, I think we can start with having you submit PRs directly. After you get your (first) version of the headless console working, with the changes discussed above, please go ahead and submit a PR for that.

And go ahead and separately submit a PR for the clock.c port, I have reviewed that and it looks fine.

There are a few small changes I'll be making to help you for when you decide to move a direct console for PC-98, which I shall make shortly.

I plan on installing the Neko Project 21/W emulator to play with PC-98, but have not had time yet.

Let's keep this issue open for continued discussions on any further issues with your PC98 port of ELKS.

Thank you!

[tyama501]

My conio-pc98-asm.c still needs customized kbd-poll so now I am trying to modify. I will change API name to use common kbd-poll. After optimization I am planning to create PR.

[tyama501]

Hello @ghaerr ,

Thank you for updating boot code! I could boot PC-9801RX21 from the second drive with 5.25 inch floppy disk. I was surprised that booting got much much faster than before!

I wanted to make PR for clock command but I got one more trouble. When I used clock -w or clock -u -w to write RTC, it seems screen is messed up and hangs. I think it was working before. Do you have any ideas what changed?

[tyama501]

@ghaerr ,

Oops I think my merge messed up clock.c I will try again later.

[ghaerr]

I could boot PC-9801RX21 from the second drive with 5.25 inch floppy disk.

Great, thanks for the testing. As you may have noticed, the problem was that the config.h settings for PC-98 had a hard-coded value for SETUP_ROOT_DEV, rather than reading the INITSEG value saved from boot_sect.S.

I was surprised that booting got much much faster than before!

LOL, so am I! Almost all of my modifications were oriented around removing ifdefs and integration with ELKS, and I tried not actually rewriting your boot code at all. So I'm not sure what caused this good thing!

When I used clock -w or clock -u -w to write RTC, it seems screen is messed up and hangs. I think it was working before. Do you have any ideas what changed? Oops I think my merge messed up clock.c

Here's my patch for your work on clock.c: tyama.txt

[ghaerr]

Hello @tyama501,

Oops I think my merge messed up clock.c

Other than your clock.c fix, I think you should now be able to boot and run from master branch, and not need your merge branch anymore, except for future enhancements you may have been working on. All of your work, except for clock.c enhancement, should now be included in master. Let me know if that is not the case.

This might make it easier to stay in sync, thank you!

[tyama501]

OK. clock command worked.

Yes, I could build from the master.

All things are merged for now.

Thank you!

[tyama501]

1068

[tyama501]

Hello @ghaerr ,

I experimentally added code for PC-98 to console-direct.c and it seems working except for cursor which I haven't written code yet. May be I still use BIOS call for the cursor. (The bell-8254.c is not included for now since it conflicted with conio_pc98.c )

Should I separate code like console-direct-pc98.c ?

https://github.com/tyama501/elks/commit/ad193074d2c758f6cb40ebe4ba65724f465aa469#diff-1e9be1f33b7c775c5628674e8b1ae7f3849a8cda900d6a11bcc8cb0d21634611

vi also worked! Thank you for your advice to use direct console.

[ghaerr]

I experimentally added code for PC-98 to console-direct.c and it seems working except for cursor which I haven't written code yet.

That's great news, and also that vi and all the other screen programs should work fine!

May be I still use BIOS call for the cursor.

Yes, or you can program the cursor directly inside the revised console-direct-pc98.c code.

Should I separate code like console-direct-pc98.c ?

Yes. You can leave the previous headless console in, and selectable either one via CONFIG_CONSOLE_DIRECT, or CONFIG_CONSOLE_HEADLESS, both underneath a CONFIG_ARCH_PC98 section in Makefile.

What I would prefer you do, looking at your branch, is to copy console-direct.c to console-direct-pc98.c, and remove all PC98 ifdefs/ifndefs. We will then have a seperate basic console driver for PC98, which is similar to, but not shared with, IBM PC direct console console-direct.c. Also make appropriate changes to Makefile, in PC98 section only.

(The bell-8254.c is not included for now since it conflicted with conio_pc98.c )

That's fine. Do what you need to do to get bell to work (or not). I realize now we need to handle bell() slightly differently since it should not be included in console-headless-*.c either. Perhaps bell() needs to go into CONIO API. We can figure that out later.

Your screenshots look great. Perhaps use a shared location for initial tvram_x (in low memory?) or set tvram_x in console driver so that we can still see boot loading code. That allows for easier debugging, for instance when you port MINIX boot :)

Go ahead and submit a PR when you are happy with the results. We can accept now, and add cursor code later, or all at once, whichever you prefer.

Thank you!

[tyama501]

Add console-direct-pc98 #1078

[tyama501]

Thank you @ghaerr ,

The cursor worked and also the boot loading messages are shown.

[ghaerr]

The cursor worked and also the boot loading messages are shown.

Looks great, thanks for the screenshot!

What's next, can colors or reverse video be supported? Adding wide-character support might be a lot of work for applications, but the kernel path to direct console could possibly be modified so that DBCS output works. Or perhaps instead move to MINIX boot?

Thank you for your work, it is helping reorganize ELKS for better portability to additional systems!

[tyama501]

@ghaerr ,

I will findout how to color the text.

There are 4 plane graphic vram for 16 colors out of 4096 colors but I think the text is colored in different way.

I might try reading SCSI hard drive. I am using SCSI emulated hardware device ArdSCSIno-stm32 with PC-9801RX21. It has DOS partition in SD card.

https://github.com/ztto/ArdSCSino-stm32#ardscsino-stm32

It seems int1B call also has address for SCSI.

[ghaerr]

I will findout how to color the text.

If it is possible, the kilo editor, shown below, is useful for testing colors. It doesn't work well with large files, but here it is running with a few lines of C code:

I might try reading SCSI hard drive. I am using SCSI emulated hardware device ArdSCSIno-stm32 with PC-9801RX21. It has DOS partition in SD card.

Nice, that may just work with changing the BIOS drive ID in the INT 1Bh calls...

[ghaerr]

Nice, that may just work with changing the BIOS drive ID in the INT 1Bh calls...

The ELKS hard disk driver will require that the sector offset ("sect_offset" in sect_boot_fat.h) be preset properly in both the MBR and partition boot sector. This is done for hd32mbr-fat in images/Makefile using setboot hd32mbr-fat.bin -P63,16,63 -Sf $(HD_MBR_BOOT) (elks/tools/setboot/setboot.c). That is, the partition start is calculated the same way fdisk (disk_utils/fdisk.c) uses, and the '-Sf' option writes sect_offset in the partition boot sector. You don't have to use setboot to do all this, and external fdisk should work, providing the partition table entry and boot sector sect_offsets match.

[tyama501]

Hello @ghaerr ,

Thank you for the information.

I tested with real PC-9801RX21. The console and vi worked also. One more thing I noticed is that I still cannot use arrow keys. I need to figure out why but it is not big problem for now so may be I will try the color text and the hard disk first.

[ghaerr]

Hello @tyama501,

One more thing I noticed is that I still cannot use arrow keys.

Yes, it looks like we're going to have to create a PC-98-only version of the polling keyboard handler kpd-poll.c. The existing version calls the BIOS every 8/100 seconds to read any keyboard data. This is fine. However, on the IBM PC, this keyboard data (received through conio_poll) returns a two-byte word: either an ASCII character if the low byte is non-zero, or specially-encoded arrow and function keys in the high byte, if the low byte is 0. These are then translated to multi-character ANSI sequences.

It may be that the PC-98 INT 1Bh function AH=05h can return arrow/fn key information, otherwise another BIOS routine would have to be called. I suggest putting all this into a new kpd-poll-pc98.c, with possible ASM changes in conio-pc98-asm.S.

There is another mechanism to receive keyboard data that IBM PC uses: kbd-scsncode.c. This is considerably more complicated, and installs an IRQ 1 interrupt handler which receives keyboard scan code information directly at the time of the keyboard interrupt. I recommend adding this after the more simpler polling method, if at all.

I will go ahead and cleanup some of the IBM PC related files ahead of this, for clarification.

Thank you!

[tyama501]

Thank you @ghaerr ,

Oh, I see.

INT 18h, AH = 05 also returns two-byte but I don't know the specification of the high byte. Instead INT 18h, AX = 0407 has the information for the arrow key.

INT 18h (Keyboard BIOS) https://web.archive.org/web/20051120083002/http://www2.muroran-it.ac.jp/circle/mpc/program/pc98dos/keyboard.html

I asked about the color attribute for the text on twitter. I was told to see the following detailed site. The color attribute region is starting from the segment 0xA200. ( I also didn't know it is so complicated to display two-byte kanji characters! BIg endian, not Shift-jis, need to set 4Bytes... )

Text V-RAM http://software.aufheben.info/contents.html?contents_key=textvram

I will try this.

[tyama501]

Is this same for the IBM-PC?

GRB 000 : Black 001 : Blue 010 : Red 011 : Magenta 100 : Green 101 : Cyan 110 : Yellow 111 : White

[ghaerr]

Is this same for the IBM-PC?

GRB

I think so, except we normally order "GRB" as "RGB" or "BGR". Here's an article on IBM PC EGA colors: https://moddingwiki.shikadi.net/wiki/B800_Text

Perhaps just use the same attribute colors as ELKS for now, then see whether an additional translation is required, using kilo for testing.

The color attribute region is starting from the segment 0xA200.

I see. Looks like you'll have to keep up two seperate regions in direct console, but at least the regions are in the same order and just different by a fixed segment difference.

INT 18h, AH = 05 also returns two-byte but I don't know the specification of the high byte. Instead INT 18h, AX = 0407 has the information for the arrow key.

Look at kpd-poll.c, and you'll see are only F1-10 and six keypad keys for now. If you have additional page VRAM at A000, multiple consoles might be able to be implemented, and which also requires the F1-F3 virtual console switch in kpd-poll.c. The normal method is to use ALT-F1 through ALT-F3, but ALT isn't available through IBM PC BIOS function INT 16h on PC.

[tyama501]

Thank you.

OK, I will try kilo.

These attributes also has bits for the following. Display or non-display Blinking or non-blinking Inverted or non-inverted Under line Vertical line

[ghaerr]

These attributes also has bits for the following.

Following is how IBM PC treats these bits:

Display or non-display - PC has no bit for that, uses same fg and bg color (=black on black = 0) to emulate non-display

Blinking or non-blinking - PC has bit for that, hardware also uses same bit for background color bright/dim, and is usually set for bright/dim (upper 8 "bright" colors on background)

Inverted or non-inverted - no PC bit for that, ELKS console uses reversed fg/bg bits for that. (That is, there are 4 bits for fg and 4 bits for bg on PC. fg bits are 4 bits of low and bright colors (=16 total). bg bits are same except that bright bit is used for blink as previously discussed, normally set for bright on real hardware.

Under line - no PC bit for that

Vertical line - no PC bit for that

[tyama501]

Add color attribute to console-direct-pc98 #1080

[tyama501]

Hello @ghaerr ,

I used re-ordered fg colors. I only used 3bits since pc-98 text has only 8 colors. Although I don't know how much this works but I used bg colors and inverted bit when fg=0.

kilo seems OK with this.

[tyama501]

Well, kilo requires arrow keys...

[ghaerr]

Although I don't know how much this works but I used bg colors and inverted bit when fg=0.

I don't think any special case has to be handled for fg=0. See my comments on #1080. If PC-98 only supports 8 colors and no bright bit, then just translate the 16 background colors to 8 colors, and translate the 16 foreground colors to 8 colors. ELKS already handles reverse video, etc by swapping fg and bg prior to the driver level. Thus, your direct console driver just needs to translates the foreground and background colors directly and quickly. I suggest a lookup table of size either 8 or 16, depending on the technical translation required.

[tyama501]

@ghaerr , Thank you for the comment. I will modify for scrolls and clear. PC-98 attributes does not have foreground color or background color. It only have 3bits color which is assumed foreground.