80486 emulator with SVGA in BASIC!!!!!

[jepalza]

(Sorry for the English, I use Google to translate, i'm spanish, don't speak english).

Some time ago I raised a challenge: make a PC emulator 80486 in Basic !!!

To achieve this, I used a very old version of PCEM, with the help of "FreeBasic", starting from PCEM-V4.1, about six months ago, I managed to make it work, in 80286 mode only. Then I went little by little adding functionalities of the following versions, until arriving at the V8 (not completely, but if great part). Due to the complexity and lack of speed in BASIC, I have only converted the modules that have interested me the most, eliminating many unnecessary ones, so I have managed to reach an 80486-DX2-66mhz with FPU, 16mb of RAM and VGA TSENG of 2mb.
I have removed many non-necessary modules, such as the sound (it does not have any sound), the LPT port, the PS2 port, the FDC unit and more.
It has many faults, but in general they work VERY well, and it is capable of running "WINDOWS 3.11", "Deluxe Paint", "Wolfstein 3D" and many other programs.
It can reach a resolution of 800x600 to 16 colors, but it moves better in 640x480 16 colors.
The keyboard fails, all the keys do not work, and neither EMM386.EXE nor EXPANDED memory can be used, because it fails and becomes very slow.
It works in both protected mode and real mode, but when entering protected mode, the PC becomes slow.

Note: Keyboard cursors may be disabled the first time. Maybe when pressing "NumLock" they work again.









Algo en Español:
Emulador de PC 80486 en Freebasic !!!!
Esta basado en el emulador PCEM, version V4.1 pero con muchas partes independientes de posteriores versiones, hasta llegar a la V8.0
Con este código podemos llegar a ejecutar un "80486-DX2-66mhz con FPU (Coprocesador matemático), 16mb de RAM y VGA TSENG de 2mb (res. hasta 800x600)"
No es mucho, pero es suficiente para mover con soltura MSDOS622 , y jugar a juegos como el Wolfstein3D o programas como DeluxePaint.
Fallan muchas cosas, por ejemplo, no tiene sonido, ni emulador de Disco Flexible, y el teclado tiene varios fallos, uno de ellos, el mas importante, es que
no detecta bien la primera vez los cursores, y debemos pulsar "BloqNum" para que se de cuenta de ello, y se habiliten.




Enlace a GDRIVE (12-ABR-20):
https://drive.google.com/file/d/11zXcsn ... sp=sharing

[jepalza]

Download from my GDRIVE: (source CODE GPL included, if anybody take best performance, please, publish it)
https://drive.google.com/open?id=1es3Ut ... -Fx8fg9FQN

You need BIOS from "ali1429g.bin", CMOS from "ali1429g.nvr" (included, don't delete or modify it), video from TSENG "ET4K_W32.BIN".
And you need to create virtual HDD (IMG) with name "MSDOS622.IMG" with 63 sectors, and 16 heads.

Sorry, forget two details: F11 to exit, F12 to DEBUG mode (slow, very slow)

[Mysoft]

nice project... but, you have lot of places where you are using "dim shared" instead of "static shared" for globals... that reduce considerable... as those end being "dynamic allocations" forcing an extra indirection....

should use 'screenres' instead of screen with number... as that make it look like a qbasic program or so...

also you should make sure the code compile with -gen gcc, to get optimizations....
you should add = any to all local variables to avoid them being initialized (like it was on C) that will attain extra speed
it would be faster, to have the the small functions to be replaced by macros, that will also speed up them somehow,
using select case as const, for just 3 entries, is actually slower than not using "as const"
using for loops to fill arrays byte by byte is way slower than using pointers and filling them using integers

careful with string usage (altough so far you have them alright, because they are slower than zstring)
also you have some string*xx on arrays, those are 1 byte bigger than they would be on C, so careful when you use that, as C would use a zstring*x), not to mention those string*xxx may be space filled, so if thats still the case, using them may not be nice

(using gen gcc may auto optimize some of those, but overall is better be safe than sorry)

[Mike C]

That's pretty awesome. I wrote a FreeBASIC 80186 PC emulator in 2011 that worked really well. It ran most old games, Windows 3.0 and MINIX, etc. A few years later, I ported it to VB6 for fun.

It took 8 years, but I've been officially beaten now with a 486 emulator. Good work! :)

I'm impressed.

[jepalza]

The variables "dim shared" did was changing some by "static", but I was doing it as needed. I will try to change all of them to see what happens.
The use of "screenres" I have not seen it important, because the idea is not to make a "nice" code, or modern, but "useful and functional".
Think on it: I am a programmer since old time of QBasic, and I still have old habits, difficult to change, such as the use of "GOTO".

I did not know the use of "-gen gcc", I'll try to see if it shows something (I had also thought about the use of "-fpmode fast" to speed things up a bit, because you do not need precision.

using select case as const, for just 3 entries, is actually slower than not using "as const"

Sure? Well, I'll look at those too.

I will try all those options that it says, to see if I can accelerate a bit the emulator, because in protected mode it is a bit slow in an I7

Anyway, you think about this: this emulator is a port from PCEM, direct from "C", with same format and use. 80% of code is exactly how PCEM V8.1
This is why many functions are similar to how they would be done in "C", because it was the fastest way to write the code without going into details. Now that it works, is when you have to go debugging, to gain speed, and that is why I have published it, so that anyone who wants to, can help with contributions or ideas.My idea is not to make a contest program, but an "emulator that works", which is the interesting part.

[jepalza]

That's pretty awesome. I wrote a FreeBASIC 80186 PC emulator in 2011 that worked really well. It ran most old games, Windows 3.0 and MINIX, etc. A few years later, I ported it to VB6 for fun.

It took 8 years, but I've been officially beaten now with a 486 emulator. Good work! :)

I'm impressed.

I know!!! I know your emulator for years !!! ;-) I followed your work, and it was my inspiration to get to this emulator. I spent a lot of time working on improving your emulator to try to get an 80286, but I did not get it, especially because of the privileged modes. In the end "throw in the towel" and decided to start from scratch, and after six months of hard work, this is the result.

I invite you to do the best, if you look capable and have time, because there are still many things to do, for example, when it enters protected mode, the emulator loses a lot of speed, because it needs to execute much more code than in real mode , and then, access to memory in protected mode with the "EMM386" does not work well, you have to locate the fault !!!

I am also a programmer of emulators, I have participated in MAME and in MESS, and I understand a lot of emulation.

[Mike C]

I know!!! I know your emulator for years !!! ;-) I followed your work, and it was my inspiration to get to this emulator. I spent a lot of time working on improving your emulator to try to get an 80286, but I did not get it, especially because of the privileged modes. In the end "throw in the towel" and decided to start from scratch, and after six months of hard work, this is the result.

I invite you to do the best, if you look capable and have time, because there are still many things to do, for example, when it enters protected mode, the emulator loses a lot of speed, because it needs to execute much more code than in real mode , and then, access to memory in protected mode with the "EMM386" does not work well, you have to locate the fault !!!

I am also a programmer of emulators, I have participated in MAME and in MESS, and I understand a lot of emulation.

I'm glad you liked it! I've always been meaning to extend it to 386 or 486, but never got around to it because it seemed like so much work.

I've been experimenting with yours a lot for a few days, and it's awesome to see this working with BASIC code. I see what you mean about the protected mode speed though. It takes about 15-20 minutes for Debian 4.0 to boot to the login prompt even on an i7-8700K! But it works!!! That's amazing.

[counting_pine]

I will probably never get a chance to delve into this code, sadly, but I just want to say I'm very impressed - projects like this must take a lot of work.

Mike C, VB is still pretty much my favourite language for debugging in, so I'm particularly impressed you managed to get a full working emulator there!
Sadly the dependencies gave me too much trouble to get your project working for the moment..

[jepalza]

there are a few failures that I can not fix, and that prevent some programs from running, such as "EMM386" or WIN95. For example, WIN95 works (the installer), but when the installation completes, it gives a serious error and is terminated. I have tried to get more speed by changing some options, but the improvement is not very appreciable.

Maybe we should wait for a "future I8" >8-D

MikeC: my code is difficult to read, but if you compare it with the C language versions of the PCEM (V8), you will see that there is not much difference. Maybe you can locate a fault that escapes me.
After 6 months with this job, I only see numbers in my head, I do not see any code and I do not find my own faults 8'-(

I will probably never get a chance to delve into this code, sadly, but I just want to say I'm very impressed

Gracias!!!

[caseih]

Think on it: I am a programmer since old time of QBasic, and I still have old habits, difficult to change, such as the use of "GOTO".

There's absolutely nothing inherently wrong with using GOTO. In fact for projects like this, it probably is often the best and fastest way to do certain things.

[Mike C]

there are a few failures that I can not fix, and that prevent some programs from running, such as "EMM386" or WIN95. For example, WIN95 works (the installer), but when the installation completes, it gives a serious error and is terminated. I have tried to get more speed by changing some options, but the improvement is not very appreciable.

Maybe we should wait for a "future I8" >8-D

MikeC: my code is difficult to read, but if you compare it with the C language versions of the PCEM (V8), you will see that there is not much difference. Maybe you can locate a fault that escapes me.
After 6 months with this job, I only see numbers in my head, I do not see any code and I do not find my own faults 8'-(

I'll see what I can do, but I've never considered myself an expert on optimization.

The first thing I want to do is see if I can fix whatever is wrong with the IDE controller code. There are occasional errors in Linux where it has to retry disk reads, and Windows NT 4.0 refuses to boot because of what it thinks is a disk hardware error.

Bugs aside, I am seriously blown away by this port!

[Mike C]

Think on it: I am a programmer since old time of QBasic, and I still have old habits, difficult to change, such as the use of "GOTO".

There's absolutely nothing inherently wrong with using GOTO. In fact for projects like this, it probably is often the best and fastest way to do certain things.

Agreed. GOTO is just another tool. You always should use the right tool for the job, and occasionally that tool is GOTO!

Not using GOTO is like taking JMP away from an assembly programmer. :)

[jepalza]

Did found one method (thanks to FreeBasic Help) for draw screen more fast than using traditional PSET command, using direct write to screenbuffer.

Thanks to this method, games like "Time Machine" (with VGA RES 640x480) are more playables in my I7 3.5ghz.

Only change this lines at first of main program:

Code: Select all

  ' pantalla grafica  
  ScreenRes 800,600,32,2
  ScreenSet 1,0
  Static Shared As any Ptr scrbuffer 
  Static Shared As ulong Ptr pixel
  scrbuffer = ScreenPtr()

And then, change SUB "SVGA_DOBLIT" with this:

Code: Select all

' mostramos en pantalla la imagen creada en el "vga_buffer"
Sub svga_doblit(y1 As Integer , y2 As Integer ) 
   Dim As Integer a,b
	
   If y1>=y2 Then 
   	Return ' vuelve sin hacer nada
   EndIf
  
	ScreenLock
		For a=y1 To y2-1 'y1=inicio de linea, y2 fin de linea (menos uno)
			For b=32 To wx-1  +32 ' hay que compensar los bordes con este "+32"
				'PSet (b-32,a),vga_buffer(a,b) ' metodo tradicional mas lento
				' segun SCREENINFO , PITCH=3200 y BYTE-PER-PYXEL=4 (para DEPTH=32)
				 pixel= scrbuffer + (a * 3200) + ((b-32) Shl 2) '(b SHL 2) es como usar (b*4)
				 *pixel=vga_buffer(a,b)
			Next
		Next
	ScreenUnLock
	ScreenCopy 
End Sub

[jepalza]

Agreed. GOTO is just another tool. You always should use the right tool for the job, and occasionally that tool is GOTO!
Not using GOTO is like taking JMP away from an assembly programmer. :)

It's right for me, but nobody says the same thing. The "C" programmers do not say anything good about it.

[counting_pine]

I think many (but not all) kinds of programs are just structured in such a way that they don't benefit much from goto..

I see the vga_buffer() 2D array in video.bas is declared with dimensions of 2001. It might get a little bit of extra speed if you are able to increase that to 2048, which should enable a power-of-two optimisation on indexing.

Code: Select all

Dim Shared As ULong vga_buffer(0 to 2047, 0 to 2047)

EDIT: Actually, I see in general you're declaring arrays in a ([0 to] N) fashion. In C, this would get you an array with N elements (from 0 to N-1), but in FreeBASIC you specify the (lower and) upper bounds, not the number of elements. So things like 'dim a(256)' are best written 'dim a(0 to 255)'.
(The '0 to' is optional, as you know, but it makes intentions a lot clearer.)