 |
 |
|
 |
 Posted: Mon Oct 26, 2009 5:21 am |
 |
|
| Message |
|
|
|
Thanks, I looked at basm286, it's a neat idea. I think I'll keep going the way I am. A couple more things to clean up in the dex ver and then off to other os's. It's up on my site if any one wants to look at the work in progress.
_________________
Sadly DexOS is incomplete, it has no blue screen of death. Hummmm guess it's up to me to add one 
|
|
 |
|
|
|
|
|
| Posted: Mon Oct 26, 2009 9:07 am |
|
|
| Message |
|
|
|
Off course Steve, you keep your great work with BASIC macros. My recommendation with BASM286 is to adding more functions to your macros library with modified BASM286 built-in functions.
Since BASM286 able to produce ASM output source code, built-in function ASM source could be retrieve and adapted into DexOS 32 bits macros. You guys had advantages programming the Assembly language, the possibility to
have success conversions into Dex Fasm macros are higher.
Each built-in function documentation also there which is can be used as temporary guideline to use your BASIC macros.
|
|
|
|
|
|
|
|
|
| Posted: Tue Oct 27, 2009 6:43 pm |
|
|
| Message |
|
|
|
| Steve wrote: | | Thanks, I looked at basm286, it's a neat idea. I think I'll keep going the way I am. A couple more things to clean up in the dex ver and then off to other os's. It's up on my site if any one wants to look at the work in progress. |
I will keep checking it out and testing the progress, thanks steve.
_________________
Dex
Craig Bamford. assembly coder.
|
|
|
|
|
|
|
|
|
| Posted: Sat Oct 31, 2009 9:24 pm |
|
|
| Message |
|
|
|
I've got it cleaned up some what and every thing that is there seems to be functional (the string def needs a rewrite)
Guess I'll start the Dos ver, I've never done any windows stuff with out a graphic ide, so figured that would make a better second port...
Not sure if the windows port should be full screen or a window. Oh well off to dos land
_________________
Sadly DexOS is incomplete, it has no blue screen of death. Hummmm guess it's up to me to add one
|
|
|
|
|
|
|
|
|
| Posted: Sun Nov 01, 2009 12:48 am |
|
|
| Message |
|
|
|
(shudders at thought of DOS. Evil segmentations...)
[edit] There will be some work on MacroBASIC shortly, as I didn't really have ,uch done on the rewrite, the fact that I can't find my thumb drive isn't too much of an issue... :-/
|
|
|
|
|
|
|
|
|
| Posted: Sun Nov 01, 2009 1:52 pm |
|
|
| Message |
|
|
|
I remember segmentations  too, if realmode did not use segmentations i would not of started OS Dev and would of been happy to coded Dos progs instead.
@steve, if you can use BIOS or Dos int for a function, it would be good to stick to BIOS (if the chose is there) as it would help with porting to MiniDos and other realmode hobby OS like mikeos http://mikeos.berlios.de/
ps: I notest that they have started work on a basic interpreter.
_________________
Dex
Craig Bamford. assembly coder.
|
|
|
|
|
|
|
|
|
| Posted: Wed Nov 04, 2009 5:34 am |
|
|
| Message |
|
|
|
I guess he didn't like segments either. The OS is designed to be tiny and only run programs that will fit with the OS in the one segment. That's just from a quick look. but interesting. Between what he has there, and some of the stuff in the win libs for fasm, I'll be busy for a while and it's all great stuff. I had played with if statements a little, but the fasm lib for windows already does it. Just need to figure out how to mix the stuff in
_________________
Sadly DexOS is incomplete, it has no blue screen of death. Hummmm guess it's up to me to add one
|
|
|
|
|
|
|
|
|
| Posted: Thu Nov 05, 2009 5:27 pm |
|
|
| Message |
|
|
|
heh, i remember my first attempts with c for dos and that i never understood what those cryptic "modes" was for. tiny, small, medium, large or sth for diffrent segmenation modes.
_________________
http://bos.asmhackers.net/
|
|
|
|
|
|
|
|
|
| Posted: Sun Nov 22, 2009 10:22 pm |
|
|
| Message |
|
|
|
lol yeah, I was scared of programming in anything but BASIC for a while due to that, and Pascal.
Then I found an assembler a lot like FASM but only for 16-bit stuff. Then MenuetOS. Then here I am, lol.
OK, long time no chat, as you all know I've been stewing on how to make a cross-platform BASIC layer for FASM. Well, it involves macros of macros. Hopefully, once all the logic works out, the final result won't be so inefficient as to be worthless. My goal is to make it so you change the PLATFORM directive and you get an executable/binary for that platform. Right now it's only x86, and it's only about 5 commands. I'm kind of feeling it out as I go. Once Solidus is back with us, I'll have him try it out with the VM. I've got some work before that will be possible though. All I can say is using a platform like a VM as target will be interesting, the PLATFORM macros are going to look something like:
| Code: |
macro _PLATFORM_CONSOLE_OUT
{
dw 0xEF23, 0x1234
dw 0xA3E4, 0x2345
}
|
LOL. However, it would be very useful if we could target DexOS, Solidus' VM, and possibly Menuet/Kolibri.
And yes, I know it sounds like a bad C# function call above. Sue me. ;-)
I'm also defining macros for _MOV, _PUSH, _POP, etc. It's a cascading effect. The top level is all BASIC. The middle layer is a psuedo-ASM, then the real ASM/binary is the bottom level. I should have a very unimpressive demo of the x86 working here shortly.
[edit]
I'm going to need Solidus to work on a platform file for the VM so we can see if the intended goal is being met, however it would appear this method may work.
The idea is that there are 3 layers: The BASIC functions, the Abstraction Layer (I'm calling it Cobblestone), and the Platform Layer. The BASIC functions are just that, they use the functionality provided by Cobblestone, which breaks everything down into native routines. This way the BASIC is in no way platform dependent, it is Cobblestone dependent, and Cobblestone is simplistic enough to be easily portable using a set group of platform routines.
The first line of the app is therefore necessarily "include your_platform.inc"
Also, as DexOS doesn't protect itself from it's apps and uses a simple return for exit, I'm saving esp on entry, and restoring it before exit. In case of any oddball stack issues the system can be safe if the app manages to exit.
Likewise I'm going to set aside file handle/buffer area, which will also be cleaned up on prog exit. Some of my first apps to demonstrate file access will be the basic DOS-style functions. It will also have the ability to retarget the standard console I/O to a port or serial device.
The reason for the three layers isn't really apparent on x86 architecture, it looks like I'm greatly overcomplicating things by breaking them down amongst macros before committing to native code, but I think this is best for the eventual compiling of DexOS ARM and various VM projects. I'm toying with the idea of an eventual PIC18 platform file that will spit out a hex file that can be burned to chip and run. I need to get EmbedDEX a bit further along though. It would use UART as it's I/O system obviously.
One thing at a time, right now it prints. I think I have a way of making print much more versatile, although not quite what QBASIC has going on.
_________________
If it's got bits, I'll byte.
|
|
|
|
|
|
Page 5 of 5
|
|
All times are GMT
Goto page Previous 1, 2, 3, 4, 5
|
|
Display posts from previous:
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
| |
