OSDev.org

This time I kept the original font of your BIOS
I developed a new filesystem for smile so I wrote a new bootloader with some new features.
You can try it on bochs and virtualbox. It doesn't work on real hardware, or it will work sometimes because there are some functions I have to rewrite.
Please report bugs, corrections or new ideas ^_^

PAKTC means Press a Key to Continue

Last version

Hi Carlo,

I'd like to try it/them (why are there two versions?), but I can't work out how to. When I open the zipped files I find a single file inside each (which VLC media player instantly claims are video files) and I can't find any way to change them to .img files so that Bochs can find them.

[All I've ever done with Bochs is run floppy images which either start out as .img or can be turned into .img immediately after bringing them in through rawwrite, so I've never needed to do anything more complex to get them working in Bochs.]

Please provide a few instructions to help me find the way in.

Sorry, I take for granted too many things
image.zip is the old version with a BIG bug in the fs routines. I keep it just because there are two sample of the text editor inside.
image0.1.zip is the newest version, even if tomorrow I'll update an other with files, a working fs and serial support.

The extension is img because my version of virtualbox can't read the .bin files.
The img file is a floppy image you can load from BOCHS. I suggest you also to increment the IPS value because at the very beginning of the execution there is some slow code to check the speed of the current system

It works on my own FS. It is loaded in memory by the stage0 from 0x10000 to 0x20000. Than it tries to find an autoexec.bat file. If not it will run the built-in-realmode-console. Follow the tips on the screen, you should understand (I hope) what to do

Okay, I've found a file in the second zipped folder, and by copying it from there to somewhere else I've been able to rename it to give it a .img filetype, though I'm not sure if that's sufficient - see photo (still don't know why VLC's so keen on it). I've also managed to get Bochs to see it and to try running it, but the result was "Panic, No bootable device, Kill simulation". What am I doing wrong?

Ok I included the bochs script inside. You have just to edit it (right click, contextual menu) substituting "C:\Programs\Bochs-2.4.6\" with the directory of your current version of bochs.

It should work in this way

In this version of the loader I added the serial support to load external file from a serial port

DavidCooper wrote:Okay, I've found a file in the second zipped folder, and by copying it from there to somewhere else I've been able to rename it to give it a .img filetype, though I'm not sure if that's sufficient - see photo (still don't know why VLC's so keen on it). I've also managed to get Bochs to see it and to try running it, but the result was "Panic, No bootable device, Kill simulation". What am I doing wrong?

Windows explorer has been hiding file extensions for years. So, all you've really done is rename the file to final2.img.bin.

So either force Windows to stop hiding extensions, or, rename it using the Windows command interpreter?

BTW, if you specify the full name to the emulator, it can have any name at all.. regardless of extension, obviously.

Brynet-Inc wrote:Windows explorer has been hiding file extensions for years. So, all you've really done is rename the file to final2.img.bin.

Number one of two things any developer should set in a windows installation: show extensions and show hidden folders. Typical thing to do in the time IE is downloading something a more sane replacement.

Hi Carlo.

That made it a bit easier and I've managed to get it to run. I've also managed to get the previous version to run - I failed to tick a little box and that's why it didn't work before, but having it available as a normal .img file does save a step and makes it easier.

One of the commands needs a spelling correction: receive, not recive.

Other than that, I don't know which parts of it you most want to be tested. I've created a couple of files using names such as "new test.txt", after which the "dir" function looked more interesting. I've also used "write test.txt to write a file with what appears to be a text editor. Once in the text editor, every key press made the whole screen flash (though that might be the fault of Bochs), and when I tried to save a file (using "q" as directed) a message claimed it was saved, but it then got stuck, refusing to exit after pressing "u" - each press of "u" leads to a message saying "Do you want to save your work?" (even though it's already been saved), and pressing "y" takes it back to the list of available commands offering "u" as a way to exit (which again leads back to the same question "Do you want to save your work"). Pressing reset in Bochs to start from scratch reveals that the text files I created were saved to the disk, and the one I actually wrote to with the text editor contained 138 bytes. Using "write test.txt" again enabled me to modify it further, up to 267 bytes (as revealed after doing another reset to get out of the exit trap). The cursor in the text editor behaved in a strange way on one line, lagging one place behind the current print position.

I also tried deleting one of my test files and everything froze. After another reset to escape from this I found that it had been successfully deleted. I tried another delete and exactly the same thing happened.

I didn't dare testing "format" - wouldn't it just wipe out the whole bootloader and everything else on the disk?

There don't appear to be any other files on the disk to play with. Do you have anything available for it to load which would show off more of the things it can do?

If I type in the command "basic" it says "The BASIC ROM has not been found" - is this some old piece of ROM found only on ancient machines?

I'm happy to explore it further, so if you have any suggestions about more of the things I should be trying out, please let me know and I'll give it a go. The new font is fine, by the way - very easy to read.

David.

Very neat work you have here. Will you be making the source code of the bootloader available, perhaps as a reference implementation for those who wish to write their own Smile FS driver? I'd like to see if I can port the FS to an existing project.

Having an autoexec.bat file causes the bootloader to freeze up.

Will you be writing any utilities to modify Smile FS disk images?

@David: It seems that "format" just erases all the files while keeping the bootloader intact.

Thank you very much to DavidCooper and Blacklight

@Blacklight

Blacklight wrote:Very neat work you have here. Will you be making the source code of the bootloader available, perhaps as a reference implementation for those who wish to write their own Smile FS driver? I'd like to see if I can port the FS to an existing project.

Smile FS specifications will be made partly readable to allow this. However some other parts will not because Smile FS provides a layer of protection with cryptography that should be left reserved. The bootloader code will be provided only in the form needed to understand some internals . I'm writing the specifications in these days, I hope to upload them early.

Blacklight wrote: Having an autoexec.bat file causes the bootloader to freeze up.

It's true The file isn't read because I have to port the parser of the old version to this (the commands are the same)

Blacklight wrote: Will you be writing any utilities to modify Smile FS disk images?

I had. Before writing the bootloader I wrote a windows application to read and write files.... well than when I wrote the bootloader I changed all so it isn't any more useful.
However with the recive command (that now I'm going to change with receive, thank you David) and an utility I can upload, you are able to send file you edited on your computer.

Blacklight wrote: @David: It seems that "format" just erases all the files while keeping the bootloader intact.

It' so, because the Smile FS starts only after a region of space reserved by the MBR in order to contains.

@DavidCooper

DavidCooper wrote: One of the commands needs a spelling correction: receive, not recive.

Fixed

DavidCooper wrote: Other than that, I don't know which parts of it you most want to be tested. I've created a couple of files using names such as "new test.txt", after which the "dir" function looked more interesting. I've also used "write test.txt to write a file with what appears to be a text editor. Once in the text editor, every key press made the whole screen flash (though that might be the fault of Bochs)

It's ok, the content is refreshed every char you add or delete, and bochs isn't so fast. You could also try some keys like del, ins to see if everythink is ok.

DavidCooper wrote: and when I tried to save a file (using "q" as directed) a message claimed it was saved, but it then got stuck, refusing to exit after pressing "u" - each press of "u" leads to a message saying "Do you want to save your work?" (even though it's already been saved), and pressing "y" takes it back to the list of available commands offering "u" as a way to exit (which again leads back to the same question "Do you want to save your work").

It asks you because there isn't any control on the changed status of the file. The exit is a bit bugged, you should press esc to go out after you pressed u and [y/n].

DavidCooper wrote: Pressing reset in Bochs to start from scratch reveals that the text files I created were saved to the disk, and the one I actually wrote to with the text editor contained 138 bytes. Using "write test.txt" again enabled me to modify it further, up to 267 bytes (as revealed after doing another reset to get out of the exit trap). The cursor in the text editor behaved in a strange way on one line, lagging one place behind the current print position.

This is a feature that let you know you are writing on a long line which is more than 80 characters . If it's not useful I can delete it

DavidCooper wrote: I also tried deleting one of my test files and everything froze. After another reset to escape from this I found that it had been successfully deleted. I tried another delete and exactly the same thing happened.

Whaaaat? Can you upload you image so that I can see the problem?

DavidCooper wrote: There don't appear to be any other files on the disk to play with. Do you have anything available for it to load which would show off more of the things it can do?

Not yet but if you save a file like something.bas and you try to edit it you will see the editor highlighting commands numbers and so on.

DavidCooper wrote: If I type in the command "basic" it says "The BASIC ROM has not been found" - is this some old piece of ROM found only on ancient machines?

No it is the loader of the BASIC interpreter used if you don't have any operating system to load. I'm writing it ... by now I could add the mikeos one.

Thank you very much for the time spent with my project

If anyone has found an error, he can uploads the image downloaded so that I can understand and fix the bug ^_^
I'm sorry for mistakes this has been a very long post which tested my English so hard XD If you want you can also report them so I fix

Hi Carlo,

Karlosoft wrote:It's ok, the content is refreshed every char you add or delete, and bochs isn't so fast. You could also try some keys like del, ins to see if everythink is ok.

Deletes and ins seem to be fine. Holding the cursor-right key down on one occasion for about five seconds caused the cursor to jump to the end of the text followed by a freeze, but I haven't managed to get it to repeat that trick. It's just possible I hit the cursor-down key as well, so that might account for it jumping to the end, but that doesn't explain the freeze.

It asks you because there isn't any control on the changed status of the file. The exit is a bit bugged, you should press esc to go out after you pressed u and [y/n].

That does work now, so I don't understand why it didn't work yesterday - I would have thought that I must have pressed Esc every time to get rid of the menu, so it should have worked. I'll let you know if it happens again.

This is a feature that lets you know you are writing on a long line which is more than 80 characters . If it's not useful I can delete it

On a test paragraph spread over three lines, the cursor only lags behind the print position on the third of those lines. It doesn't seem useful and feels like a bug. If you feel the need to change the way the cursor behaves on long lines, it would be better to change the cursor colour.

Whaaaat? Can you upload your image so that I can see the problem?

I've tried it again and discovered that it only freezes when deleting an empty file - if you create a file with "new" and then delete it straight away it should freeze. If the file contains so much as a single byte, it deletes fine without a freeze.

Not yet but if you save a file like something.bas and you try to edit it you will see the editor highlighting commands numbers and so on.

I've just created a .bas file using "new" and tried typing in a program. On the first line I typed "10 if" (without the " parts). The "10" turned yellow and the "if" turned magenta. I haven't used Basic for over a decade so I couldn't think what to put after the "if". On the next line I tried "20 print" - the "20" turned yellow and the "print" turned magenta. I then tried to type a " sign and got a primitive @ sign instead (I think that's what it was), so I then tried other shifted number keys to try to find a ", but that resulted in a freeze.

I've now tried the shifted number keys again, both with a .bas file and a .txt file - in both cases this can lead to a freeze, though different keys cause the freeze depending on whether it's .bas or .txt.

On another issue, you might want to do something about the dropped initial command letter problem - when I type in "dir" after creating a new file I get "ir" instead because you require a key to be pressed after some commands (for no good reason) just to recover the command prompt. Wherever possible, the command prompt should reappear without having to press a key.

Edit: I forgot to ask: what would I need to do to test "send" and "receive"? I've tried "recive file.txt" (even though I wasn't sending a file in - I don't know how to), and the result was that it got stuck waiting for the non-existent file with no way to escape from there - it appears to go on waiting for an answer forever.

On a test paragraph spread over three lines, the cursor only lags behind the print position on the third of those lines. It doesn't seem useful and feels like a bug. If you feel the need to change the way the cursor behaves on long lines, it would be better to change the cursor colour.

Ok I'll apply a different color

I've tried it again and discovered that it only freezes when deleting an empty file - if you create a file with "new" and then delete it straight away it should freeze. If the file contains so much as a single byte, it deletes fine without a freeze.

Fixed

I've just created a .bas file using "new" and tried typing in a program. On the first line I typed "10 if" (without the " parts). The "10" turned yellow and the "if" turned magenta. I haven't used Basic for over a decade so I couldn't think what to put after the "if". On the next line I tried "20 print" - the "20" turned yellow and the "print" turned magenta. I then tried to type a " sign and got a primitive @ sign instead (I think that's what it was), so I then tried other shifted number keys to try to find a ", but that resulted in a freeze.

This is strange, it doesn't happen with any key. I'll try again tomorrow. Some char could been mapped in a different way from your keyboard.

On another issue, you might want to do something about the dropped initial command letter problem - when I type in "dir" after creating a new file I get "ir" instead because you require a key to be pressed after some commands (for no good reason) just to recover the command prompt. Wherever possible, the command prompt should reappear without having to press a key.

I'll fix it in the next version

Edit: I forgot to ask: what would I need to do to test "send" and "receive"? I've tried "recive file.txt" (even though I wasn't sending a file in - I don't know how to), and the result was that it got stuck waiting for the non-existent file with no way to escape from there - it appears to go on waiting for an answer forever.

They are used with a serial connection. I'll post the program to send file soon
I will also provide a way to force the bootloader to ends the task

Karlosoft wrote:This is strange, it doesn't happen with any key. I'll try again tomorrow. Some char could been mapped in a different way from your keyboard.

Could other people try this please. Use the command "new test.bas" (without the " signs) to create a file, then use "write test.bas" to edit its content, and then try out the shifted number keys. I find that shifted 2, 5, 8 and the key two places to the right of 0 all result in a freeze. I'm using a UK keyboard layout, so those translate to typing ", %, * and +. Typing the hyphen key (unshifted - the key to the right of 0) also causes a freeze, and so does typing / (the key three places to the right of the m key). Now repeat the experiment with a test.txt file. When I do this, only shifted 5 (%) causes a freeze - the rest work fine.

They are used with a serial connection. I'll post the program to send file soon
I will also provide a way to force the bootloader to ends the task

Does it require a physical serial port, and if so will a USB to serial port converter work?



There's obviously quite a bit of work going on under the surface when it colours a Basic program - that must have been fun to write. The jpeg below is too compressed to look attractive, but the real thing's nice.

Sorry I was trying it on an older version of the editor. You are right, I'm going to find the cause of this strange thing. It requires a real serial port, two on the same computer if you are testing it from the same where you send the file. It should work but it depends from windows and the drivers installed
Yes it has been fun. I'm improving the speed of the "rendering" so that it will not flash even on bochs.

I'll give it a go then when I find my USB-to-serial-port cable (I think I know where it is, but I'll have to shift a lot of junk to get to it) - I'll try to send in a file from a Psion 5mx. I'm running out of working machines to test things on, so I'm now limited to recent laptops and couple of old Psion organisers.