Video: Skynet ? on Pentium 166 from 1997 ?

https://www.youtube.com/watch?v=28Qff1jYxNc&feature=youtu.be

I may require your ASM expertise to turn some of the ASM of mario into turbo pascal.

If you are interested in helping out to convert an old mario game from the dos age into the modern age into Delphi write me a reply to let me know you are slightly interested and perhaps I will reach out to you to work together to get it done.

You can also already investigate via google and find the mario code yourself and look at the asm to see if you are able to tell what it does.

If multiple ASM programmers help at converting as much ASM to Pascal as possible it would go a whole lot easier.

Then ofcourse some logic might have to be changed because of the page flipping mechanic, not yet sure how mario exactly works.

Anyway back on topic to skynet:

I think I can manage to investigate this further, but if you have any other ideas how to convert this corruption into instructions, perhaps an asm loader or something let me know.

Also let me know if you ever had any freak corruption accident like this ;)

Alternatively these files could be renamed to *.exe or *.com just to see what would happen =D

I hope you enjoy the story and also there is a little lesson/warning to be learned from it.

Especially for programmers working in large data centers ! ;) =D

Bye for now,
  Skybuck.

Hi,

On Monday, December 30, 2019 at 11:07:03 PM UTC-6, skybu...@hotmail.com wrote:

Video: Skynet ? on Pentium 166 from 1997 ?

https://www.youtube.com/watch?v=28Qff1jYxNc&feature=youtu.be

I may require your ASM expertise to turn some of the ASM of mario
into turbo pascal.

Convert inline asm into HLL Pascal code? TP does have mem[] and port[]
and "absolute" and whatever else.

If you are interested in helping out to convert an old mario game
from the dos age into the modern age into Delphi write me a reply
to let me know you are slightly interested and perhaps I will
reach out to you to work together to get it done.

It has two versions, one for TP6 (inline asm) and one for older TP 5.5
(which is freeware).

You say you want it converted to Delphi (which I don't have). Which version?
Which toolset? (FPC??) Which specific Delphi dialect?

FPC is probably a better bet than Delphi, but you could allegedly use
WDOSX extender with some older 32-bit Delphis (2,3,4). Even Virtual Pascal
(freeware) supported Delphi 2 dialect with inline asm, plus it had some
third-party support for targeting DOS (using WDOSX).

I somewhat wonder if you really want to keep atop DOS at all. I'm
sympathetic to DOS but no genius. FPC has officially had a 16-bit,
8086-msdos cross-target since 2015. It shouldn't be impossibly hard
to convert the code to be built by that.

You can also already investigate via google
and find the mario code yourself and look at the asm
to see if you are able to tell what it does.

Weiring Software. I've seen it before.

If multiple ASM programmers help at converting as much ASM to Pascal
as possible it would go a whole lot easier.

Yes, probably. But if you're not interested in DOS, per se, you're
going to have to use Allegro or just a different game engine entirely
(Game Maker?? I have no idea). Even Allegro 4.x used to work for DJGPP,
so that "probably" would be easier to work with for cross-platform
support, presumably with FPC (Go32v2). The less low-level stuff you
do by hand, it's probably for the better. And yes, the code shouldn't
rely on specific toolsets or versions (especially not proprietary or
abandoned/unsupported).

You might also get more help on news://comp.lang.pascal.borland or
one of the FreeDOS mailing lists. Or even FPC forums??

On Monday, January 27, 2020 at 7:14:23 AM UTC+1, rug...@gmail.com wrote:

Hi,

On Monday, December 30, 2019 at 11:07:03 PM UTC-6, skybu...@hotmail.com wrote:

Video: Skynet ? on Pentium 166 from 1997 ?

https://www.youtube.com/watch?v=28Qff1jYxNc&feature=youtu.be

I may require your ASM expertise to turn some of the ASM of mario
into turbo pascal.

Convert inline asm into HLL Pascal code? TP does have mem[] and port[]
and "absolute" and whatever else.

Yes ASM into PASCAL.

If you are interested in helping out to convert an old mario game
from the dos age into the modern age into Delphi write me a reply
to let me know you are slightly interested and perhaps I will
reach out to you to work together to get it done.

It has two versions, one for TP6 (inline asm) and one for older TP 5.5
(which is freeware).

You say you want it converted to Delphi (which I don't have). Which version?
Which toolset? (FPC??) Which specific Delphi dialect?

Any version will do as long as it's PASCAL/DELPHI/FREE PASCAL :)

FPC is probably a better bet than Delphi, but you could allegedly use
WDOSX extender with some older 32-bit Delphis (2,3,4). Even Virtual Pascal
(freeware) supported Delphi 2 dialect with inline asm, plus it had some
third-party support for targeting DOS (using WDOSX).

No ASM, it has to be converted into Pascal at the very least.

Maybe later convert XMODE stored graphics into a "normal" bitmap format, have not made up my mind about that last part yet.

Keeping the format compatible with old sources could be interesting.

I somewhat wonder if you really want to keep atop DOS at all. I'm
sympathetic to DOS but no genius. FPC has officially had a 16-bit,
8086-msdos cross-target since 2015. It shouldn't be impossibly hard
to convert the code to be built by that.

This could be usefull. Since I have not found a tp7 installation, might have to download those floppy disk somewhere or indeed switch to free pascal to test dos game in dosbox. Using original tp7 would probably be better to avoid any free pascal bugs or short comings or conversion issues.

You can also already investigate via google
and find the mario code yourself and look at the asm
to see if you are able to tell what it does.

Weiring Software. I've seen it before.

If multiple ASM programmers help at converting as much ASM to Pascal
as possible it would go a whole lot easier.

Yes, probably. But if you're not interested in DOS, per se, you're
going to have to use Allegro or just a different game engine entirely
(Game Maker?? I have no idea). Even Allegro 4.x used to work for DJGPP,
so that "probably" would be easier to work with for cross-platform
support, presumably with FPC (Go32v2). The less low-level stuff you
do by hand, it's probably for the better. And yes, the code shouldn't
rely on specific toolsets or versions (especially not proprietary or
abandoned/unsupported).

The idea is to be able to thinker with the low level stuff later, try cuda stuff, opengl stuff, just delphi stuff, anything is possible.

First conversion should just use Delphi and not anything else, this is doable.

You might also get more help on news://comp.lang.pascal.borland or
one of the FreeDOS mailing lists. Or even FPC forums??

Ok thanks for tip, I will try that later.

I am little bit short on time now, cleaning up my storage closests.

Preparing to buy threadripper 3 based system on 7 feb 2019 when new threadripper 3, 64 core system comes out.

Then I may try and render mario on big screen with or without help of cuda/opengl and so forth.

Maybe I have some time to dive into mario the coming week or maybe not.

One think I may try is look at dosbox source code if available and figure out how it supports x-mode. That could be usefull.

Thanks for your reply.

Bye for now,
  Skybuck.

If you want to give turbo pascal a try then download this link:

http://www.retroarchive.org/turbo/ult-trbo.zip

Extract it into a virtual disk image of vmware or virtualbox where ms-dos 6.22 is installed.

(This has runtime error 200 fixed)


This will then give a pretty good turbo pascal installation.

Go to bp\bin folder and then start turbo.exe

Then load mario.pas.

Set build configuration to "disk" instead of "memory'.

Destination/Target something like that... so disk instead of memory.

Then this will "build" mario.exe

It cannot be run inside the IDE, cause it runs out of memory.

The game does run fine outside it though.

One solution for the out of memory problem could be to cut out some levels or so.

At least this gives you a chance to convert ASM to PASCAL and then try it out in the real thing.

My suggestion is "Draw" routines.... and maybe the "star" thing.

Mostly VGA256.pas unit needs to be converted.

I think the game uses some kind of offset to scroll in x-mode this might have to be replicated somehow, not sure yet.

Bye for now,
  Skybuck.

Ok removing levels 2 to 6 works.

Also some demo code needs to be removed.

Tomorrow I will create a github with minimum changes so that people can build this game in turbo pascal and actually run and step through it by removing levels 2 to 6 from the code to make it run and such.

Bye for now,
  Skybuck.

The most important routine is probably DrawImage:

Going to investigate further how the scrolling is done, but might be build into draw image, not sure yet, or maybe via x-mode scrolling dont know yet investigating by disabling things in tp7 ;)

Hello,

Now that I have a turbo pascal IDE working in MS-DOS 6.22 in VMWare I can experiment with mario clone source code (mike wieringa) and can confirm that the following assembler routine is very important, it is responsible for drawing all the sprites/bitmaps, except background shades or so:

Now I already tried and convert it myself a little bit, but I think I missed to include some variables.

Anyway if any of you assembler experts could convert this to pascal then that would be awesome and help any conversion for sure:

(I will include my own down below so you could expand on that)

// Including all variables/constants used just in case:

  const
    VGA_SEGMENT           = $A000;

    WINDOWHEIGHT        = 13 * 14;
    WINDOWWIDTH         = 16 * 20;

    SCREEN_WIDTH        = 320;
    SCREEN_HEIGHT       = 200;

    VIR_SCREEN_WIDTH    = SCREEN_WIDTH + 2 * 20;
    VIR_SCREEN_HEIGHT   = 182;
    BYTES_PER_LINE      = VIR_SCREEN_WIDTH div 4;

    MISC_OUTPUT         = $03C2;
    SC_INDEX            = $03C4;
    GC_INDEX            = $03CE;
    CRTC_INDEX          = $03D4;
    VERT_RESCAN         = $03DA;

    MAP_MASK            = 2;
    MEMORY_MODE         = 4;

    VERT_RETRACE_MASK   = 8;

    MAX_SCAN_LINE       = 9;
    START_ADDRESS_HIGH  = $C;
    START_ADDRESS_LOW   = $D;
    UNDERLINE           = $14;
    MODE_CONTROL        = $17;

    READ_MAP            = 4;
    GRAPHICS_MODE       = 5;
    MISCELLANEOUS       = 6;

    MAX_SCREENS         = 24;
    MAX_PAGE            = 1;
    PAGE_SIZE           = (VIR_SCREEN_HEIGHT + MAX_SCREENS) * BYTES_PER_LINE;
    PAGE_0              = 0;
    PAGE_1              = $8000;

    YBASE               = 9;


  const
    InGraphicsMode: Boolean = FALSE;

// implementation

  var
    OldExitProc: Pointer;
    OldScreenMode: Byte;

  const
    XView: Integer = 0;
    YView: Integer = 0;

    Page: Integer = 0;
    PageOffset: Word = 0;

    YOffset: Integer = 0;

    SAFE = 34 * BYTES_PER_LINE;

    Stack: array[0..MAX_PAGE] of Word       (PAGE_0 + PAGE_SIZE + SAFE,
       PAGE_1 + PAGE_SIZE + SAFE);


  procedure DrawImage (XPos, YPos, Width, Height: Integer; var BitMap);
    { Draw an image on the screen (NULL-bytes are ignored) }
  begin
    asm
        push    ds

        mov     ax, VGA_SEGMENT
        mov     es, ax

        mov     ax, YPos
        cmp     ax, VIR_SCREEN_HEIGHT
        jb      @NotNeg
        jg      @End
        mov     bx, ax
        add     bx, Height
        jnc     @End
  @NotNeg:
        mov     bx, BYTES_PER_LINE
        mul     bx
        mov     di, XPos
        mov     bx, di
        shr     di, 1
        shr     di, 1
        add     di, ax                  { DI = (YPos * 80) + XPos / 4 }
        add     di, PageOffset

        lds     si, BitMap              { Point to bitmap }

        and     bl, 3
        mov     cl, bl
        mov     ah, 1
        shl     ah, cl
        sub     bl, 4
        mov     cx, 4                   { 4 planes }

  @Plane:
        push    bx
        push    cx                      { Planes to go }
        push    ax                      { Mask in AH }

        mov     al, MAP_MASK
        mov     dx, SC_INDEX
        out     dx, ax

        cld
        push    di
        mov     bx, Width
        shr     bx, 1
        shr     bx, 1
        mov     ax, BYTES_PER_LINE
        sub     ax, bx                  { Space before next line }
        mov     dx, Height
  @Line:
        mov     cx, bx
        shr     cx, 1

        push    ax
        pushf

  @Pixel:
        lodsw
        or      al, al
        jz      @Skip1
        seges
        mov     [di], al
  @Skip1:
        inc     di
        or      ah, ah
        jz      @Skip2
        seges
        mov     [di], ah
  @Skip2:
        inc     di
        loop    @Pixel

        popf
        rcl     cx, 1
        jcxz    @Skip3

        lodsb
        or      al, al
        jz      @Odd
        stosb
        jmp     @Skip3
  @Odd: inc     di
  @Skip3:
        pop     ax
        add     di, ax
        dec     dx
        jnz     @Line

        pop     di

        pop     ax
        mov     al, ah
        mov     cl, 4
        shl     al, cl
        or      ah, al                  { Mask for next byte }
        rol     ah, 1                   { Bit mask for next plane }
        pop     cx                      { Planes }
        pop     bx
        inc     bl                      { Still in the same byte? }
        adc     di, 0
        loop    @Plane

    @End:
        pop     ds
    end;
  end;


My conversion so far (probably so palette loading code missing, but gives some idea what this does):

type

TWindowsPixel = packed record
case integer of
0 : (Value : integer );
1 : (Blue,Green,Red,Alpha : byte);

Click here to read the complete article

There is one thing I don't quite understand and that is how the bitmaps are stored in the assembler routines.

It seems to use a different format, I am not sure though.

It seems to be rotated, or encrypted or something.

Once it's loaded into memory it's decrypted or something.

Or I am delirious =D

Bye for now,
  Skybuck.

The most important part will be simulating x-mode in Delphi.

If this could be done then that would make the port a whole lot easier.

Once that is emulated then in a next phase x-mode can be removed and maybe replaced by true color/24/32 bit pixels and big fat memory and so forth and things simplified.

Bye for now,
  Skybuck.

I have decided not to use github/git for now, it's too complex for such a simple project and I want to use my own manual versioning system and I want everybody that knows how to use a webbrowser and zip/winrar to be able to participate and keep things efficient. I consider git very bug prone and inefficient for now.

So I have decided to upload the sources I have so far,  not all of them and not all information yet, but the most important parts that allow you to get started.

To my webdrive to keep it simple for now.

http://www.skybuck.org/Source/Pascal/Games/Mario/

There are two files

MarioTP7.zip
MarioDelphi.zip

The first one is newer and it's source code was created/modified yesterday by using turbo pascal 7 and it compiles with turbo pascal 7.01 and error 200 fixes applied to crt units, using ultra bp7 distro found on internet, search this thread for that link.

MarioTP7 v0003 is capable of running inside TP7 and can be debugged.
Comments have be added be me during reverse engineering attempt to discover functionality and usage of vga/asm functions and such. This is usefull information in this source.

MarioDelphi.zip contains a little bit older source, was not based on MarioTP7.
And this source version compiles in Delphi latest versions like 10.2 and such.

Units have been renamed to avoid conflicts, data files have be moved to other location to keep source tree clean.

Modified Source
Modified Data  (this folder contains a bit misleading description, decided not to rename files to .inc but just keep it as it is for now).

Both projects/zips are usefull for examing mario in it's original form and to see how Delphi handles it.

The delphi version contains different "branches".

NON-VCL
VCL
OpenGL


For now I consider the NON-VCL branch best, it can display some graphics.
VCL branch is little bit less good and too complex with windows form and such.
OpenGL I consider a failed branch cause I forgot how to use opengl rendering contexes properly and it creates a opengl thread and that creates issues with mario... mario should run in a thread, but if opengl and mario run in different threads running gets difficult.

So for now OpenGL branch is considered a fail, might be solved/fixed later.

The main branch is the version 0.01 to version 0.10.

It simply contains the original source code/units/renamed units and has as little changes as possible to compile it in Delphi. All ASM is disabled, except the db stuff, and some of that was changed to dw or dq to match bigger pointer sizes.

For now I do consider version 0.10 and v0003 and non-vcl versions usefull for those that want to give it a try and experiment with it.

You may have to set the modified data path in search path or re-add it to project file so that delphi can find the data/includes and such.

Good luck, let me know if you tried it and what issues you may have run into ! ;)

This might be my first true open source project ;) where I will expect some contributions from others if necessary.

Bye for now,
  Skybuck.