we need more programming discussion

[Mike Chambers]

come on, are mr. brutman and i the only programmers here? can't be!

anybody else here working on any cool vintage programming projects? the best thing ppl can do with old machines is write new software that lets them communicate with all the newer services and stuff on the internet. it keeps them somewhat useful!

even though i generally program for DOS in quickbasic 4.5, it is still a viable language for old machines. especially when you incorporate ASM.

btw, if anybody is curious how to do that... you would go about it like this: (roughly)

DIM asmStringData AS STRING
asmStringData = blahblahblah pre-compiled ASM code here, make sure you add a RET opcode at the end

DEF SEG = VARSEG(asmStringData)
CALL ABSOLUTE (SADD(asmStringData))

you can even do some "compiling" within your qb code, for things like pointers to strings or other variable you need to ASM code to use.

if you wanna just try this out for kicks, load up a pre-existing .BIN/.COM file (compiled code) into that asm string and call it

it's great it combines the simplicity of QB coding with the power and speed of ASM for parts where the QB code for the same thing would otherwise take forever on an 8088 or 286 or what have you

 

[chuckcmagee]

All my "programming" of late has been fixing bugs with downloaded open source operating system packages. Finding a missing "include" in a ".c" file, patching this or that for the correct PCI ID, figuring out why the current set of libraries are messed up, etc. I do hours and hours of compiling but it's to rebuild linux kernels, build new modules for my hardware setup, or compiling "portage" packages in Gentoo or FreeBSD. I haven't done any real "get this project done soon" programming since 1999 and that was always work related.

 

[Mike Chambers]

yeah i know what you mean, "get this project done soon" programming as you call it.. pretty time consuming. not good if you have a job or a family hehe.

 

[IBMMuseum]

come on, are mr. brutman and i the only programmers here? can't be!

anybody else here working on any cool vintage programming projects? the best thing ppl can do with old machines is write new software that lets them communicate with all the newer services and stuff on the internet. it keeps them somewhat useful!

Not just Internet connectivity, but code to keep up functionality. Typically I play with the (PC) hardware level more, but that gives me the background to understand how the software is working too. Not as much "tinker time" as I would want these days however.

even though i generally program for DOS in quickbasic 4.5, it is still a viable language for old machines. especially when you incorporate ASM.

btw, if anybody is curious how to do that... you would go about it like this: (roughly)

DIM asmStringData AS STRING * howeverlongitis
asmStringData = blahblahblah pre-compiled ASM code here, make sure you add a RET opcode at the end

DEF SEG
CALL ABSOLUTE (VARPTR(asmStringData))

you can even do some "compiling" within your qb code, for things like pointers to strings or other variable you need to ASM code to use. from my experience, the string containing the ASM code HAS to be a fixed-length string in QB's memory otherwise call absolute kinda goes "WTF?" and nothing tends to happen.

if you wanna just try this out for kicks, load up a pre-existing .BIN file (compiled code) into that asm string and call it

it's great it combines the simplicity of QB coding with the power and speed of ASM for parts where the QB code for the same thing would otherwise take forever on an 8088 or 286 or what have you

I am self-taught on x86 assembler. Also I like BASICs back even to the ROM level. Linking them up is a little bit harder than QuickBASIC.

The projects I am looking at are specifically tied to microchannel PS/2s (Models 50 to 95), so someone without such a model would not be able to give much input. But generally I would welcome any help, even to the level of getting them set up with a microchannel system. A few (small) things I have done are at http://www.IBMMuseum.com/Routines/ (ask questions if you need).

For those out there that don't know, microchannel was one of the first implementations of "Plug & Play". The adapters required description files (or "ADF"s) to be initialized by the system for the resources they used. Really it is fascinating what could have been on the PC forefront if things had been different (also I welcome people to visit the comp.sys.ibm.ps2.hardware newsgroup).

At the basic microchannel PC level the systems started with VGA, usually a mouse, and BASIC built into ROM (just like the original PC). An idea of mine was to replace the specific "Reference Diskettes" with a generic version for several PS/2s, using the VGA & mouse capabilities in their setup programs. And when I talk about the possibility of the tokenized BASIC op codes being on diskette to save space, being used by the ROM interpreter it gets real interesting!

 

[IBMMuseum]

yeah i know what you mean, "get this project done soon" programming as you call it.. pretty time consuming. not good if you have a job or a family hehe.

"Job" and "family" are not mutually exclusive words either. "Honey Do"s at home, and tasks that aren't put that lightly at work. I would become a better programmer if a won the lottery & didn't have to work to support my family.

 

[Mike Chambers]

Not just Internet connectivity, but code to keep up functionality. Typically I play with the (PC) hardware level more, but that gives me the background to understand how the software is working too. Not as much "tinker time" as I would want these days however.


I am self-taught on x86 assembler. Also I like BASICs back even to the ROM level. Linking them up is a little bit harder than QuickBASIC.

The projects I am looking at are specifically tied to microchannel PS/2s (Models 50 to 95), so someone without such a model would not be able to give much input. But generally I would welcome any help, even to the level of getting them set up with a microchannel system. A few (small) things I have done are at http://www.IBMMuseum.com/Routines/ (ask questions if you need).

For those out there that don't know, microchannel was one of the first implementations of "Plug & Play". The adapters required description files (or "ADF"s) to be initialized by the system for the resources they used. Really it is fascinating what could have been on the PC forefront if things had been different (also I welcome people to visit the comp.sys.ibm.ps2.hardware newsgroup).

At the basic microchannel PC level the systems started with VGA, usually a mouse, and BASIC built into ROM (just like the original PC). An idea of mine was to replace the specific "Reference Diskettes" with a generic version for several PS/2s, using the VGA & mouse capabilities in their setup programs. And when I talk about the possibility of the tokenized BASIC op codes being on diskette to save space, being used by the ROM interpreter it gets real interesting!

i dont have any original PS2 machines, but i will take a look at your projects! sounds interesting.

mostly i have been using ASM within qb to write text data directly to the screen, for example in the IRC client i've been programming. PRINT works fine usually, but when you want to add color using attribute bytes to make the UI look sexier(plus being able to support mIRC color codes)... alternating between PRINT and COLOR commands for every byte in the string takes FOREVER on anything less than a 386. i could use POKE to write directly into the B800 segment, using a FOR loop to go through the string's data but thats not much faster due to the FOR loop's overhead. (thank you, microsoft for writing such an efficient interpreter/compiler )

giving the pointer of a string(already interleaved with the attribute bytes) to a chunk of compiled ASM and having it write it all with MOVs is definately the best way to go... pretty much instant even on an XT.

 

[carlsson]

I started on a VIC-20 game (which already has received a lot of anticipating fans, despite it barely is 1% done yet) a week ago, but currently busy with other work so it'll have to wait a while.

I don't do any network programming for vintage computers though, mostly because I don't own any suitable hardware and that's not where my interests lie.

 

[Mike Chambers]

I started on a VIC-20 game (which already has received a lot of anticipating fans, despite it barely is 1% done yet) a week ago, but currently busy with other work so it'll have to wait a while.

I don't do any network programming for vintage computers though, mostly because I don't own any suitable hardware and that's not where my interests lie.

keep us updated on this! i don't have a vic20 (although i'd like to buy one, they're very cheap on ebay) but i do have an emulator. i'd like to try it

what type of game is this?

 

[Chris2005]

"anybody else here working on any cool vintage programming projects?"

a dude on classiccmp announced last night that he's interested in building a Tandy 2000 emulator. Arguably a vintage project (not meant to run on actual vintage hardware), but I might take a look into that whole emulator conundrum just for fun. Can't imagine myself getting too involved right off, but who knows...

"the best thing ppl can do with old machines is write new software that lets them communicate with all the newer services and stuff on the internet. it keeps them somewhat useful!"

Let's agree to disagree. Not at all a bad idea, but I don't believe programming on vintage stuph has to have anything to do with bringing them up to date. What about (and I'm borrowing the term here) an IBM Peecee emulator to run on an actual Tandy 2000 that allows you to pop in *most* any standard peecee ware and watch it run? You could argue that's extending the machines usefulness, but we'd have to spend some time arguing the usefulness of an early 80's DOS machine!

"even though i generally program for DOS in quickbasic 4.5, it is still a viable language for old machines. especially when you incorporate ASM.

btw, if anybody is curious how to do that... you would go about it like this: (roughly)..."

Blah blah blah. NO! The way to do it is POKE individual numerics into memory then transfer control to that point. That's the MAN'S way of incorporating assembler into a BASIC or C proggie. LOL LOL Of course I'm kidding, but it just might be more illustrative of what's going on (fer noobs). Oftentimes, you can't even find assemblers and compilers for some of these things. So yer stuck with either GW-BASIC or an equivalent.
I've thought for some time peeps need to have a place to /store/contribute programming examples, so noobs can cut their teeth.

 

[IBMMuseum]

What about (and I'm borrowing the term here) an IBM Peecee emulator to run on an actual Tandy 2000 that allows you to pop in *most* any standard peecee ware and watch it run? You could argue that's extending the machines usefulness, but we'd have to spend some time arguing the usefulness of an early 80's DOS machine!

Actually I wrote a couple of programs for DOS that would check if they were running in a Windows DOS box. Why? Because they were banging on the hardware & wouldn't function correctly (and could crash some systems) if run from Windows.

When people start talking about emulators it is usually to run older software (or software from another type of system) on a newer system. With some of the resources that process needs it typically means a very new system. You are probably welcome to talk about it here, but that leaves the concept of vintage computers behind (other than in the virtual sense; if I need to test software for the original PC, I would pull out the original system, which is a good use for a "1980's DOS system").

 

[Chris2005]

right, an emulator isn't really necessarily positively vintage programming. But when I said emulator I didn't really mean that, but actually a patch of group of patches that would eh intercept calls meant for a real peecee and process them or whatever so that they'd interact with the actual hardware in a positive fashion (i.e. not crash).
The dude who donated some old 2000 stuph including the original "boot code" apparently the bios source code (the 2000's bios was NOT located in firmware like virtually every other pc, but was loaded from disk - just don't say that around Kelly kbysd cuz he'll tell you yer wrong and fall on the ground and swing his feet LOL LOL LOL) was working on just that. I'll have to dig up the e-mails from him and elaborate further. REALLY groovy stuph IMHO. Maybe just something you'd be inclined to like.

 

[michal]

DIM asmStringData AS STRING
asmStringData = blahblahblah pre-compiled ASM code here, make sure you add a RET opcode at the end

DEF SEG = VARSEG(asmStringData)
CALL ABSOLUTE (SADD(asmStringData))

Right. Even more vintage would be using the PC ROM BASIC instead (as David with his PS/2 code) with the ASM inlines. Having BASIC in ROM is an added benefit of a genuine IBM PC (or PS/2) - too bad IBM didn't update the code so there's the 1981 version in a 1987 computer (with cassette-based commands and CGA graphic modes). But that could be of benefit too - it's brute-forced compatibility .

A question: how to convert asm mnemonics to the "pre-compiled asm code" string for Basic ? I have a program that does it for Turbo Pascal 3/4 - it's called Inline (put version number here, mine's 2.19), takes a file of assembly mnemonics and outputs a string that can be copied directly into TP code. Is there such a thing for Basic?

If not, I'm gonna have to take a two-step approach with 1. a full-blown assembler compiling to .COM file and 2. a script to convert the output byte by byte, OR modify the Inline TP assembler (it comes with TP source) to output Basic-compatible strings... Loading .COM files is not an option (ROM BASIC does just cassettes...).

 

[Mike Chambers]

Right. Even more vintage would be using the PC ROM BASIC instead (as David with his PS/2 code) with the ASM inlines. Having BASIC in ROM is an added benefit of a genuine IBM PC (or PS/2) - too bad IBM didn't update the code so there's the 1981 version in a 1987 computer (with cassette-based commands and CGA graphic modes). But that could be of benefit too - it's brute-forced compatibility .

A question: how to convert asm mnemonics to the "pre-compiled asm code" string for Basic ? I have a program that does it for Turbo Pascal 3/4 - it's called Inline (put version number here, mine's 2.19), takes a file of assembly mnemonics and outputs a string that can be copied directly into TP code. Is there such a thing for Basic?

If not, I'm gonna have to take a two-step approach with 1. a full-blown assembler compiling to .COM file and 2. a script to convert the output byte by byte, OR modify the Inline TP assembler (it comes with TP source) to output Basic-compatible strings... Loading .COM files is not an option (ROM BASIC does just cassettes...).

what i use is emu8086. i compile it as a .bin and it works great

 

[Chris2005]

Hey Mike, what do you know about console apps/virtual-86 mode, and all that rot? If someone was going to build an emulator, let's say a Tandy 2000 emulator, would the api's and mode available on modern processors make it any easier? I suppose Mike Brutman may want to jump in on this one.

 

[Mike Chambers]

Hey Mike, what do you know about console apps/virtual-86 mode, and all that rot? If someone was going to build an emulator, let's say a Tandy 2000 emulator, would the api's and mode available on modern processors make it any easier? I suppose Mike Brutman may want to jump in on this one.

i'm not sure... you mean a windows console box?

i've programmed simple (S*I*M*P*L*E) emulators before, such as one for a college project designed CPU for calucators and ran their supplied BIOS ROM on it... worked just fine. that was like 3 or 4 years ago i cant even remember the name of the CPU.

not as cool as it sounds though... i think there was like 25 or 30 opcodes lol.

 

[mbbrutman]

The 80386 introduced 'virtual 8086' mode. The host OS sets up memory a memory region which looks like classic flat real mode addressing inside of the virtual 8086. However, it can be demand paged virtual memory to the OS, so that it is easy to swap pages in and out.

When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly.

OS/2 had a wonderful virtual 8086 mode. You could literally boot DOS 5 in a window, and it would grind the diskette drive just like the real thing. I don't think the modern Windows support is as liberal, but I've not looked into it.

It's certainly easier to exploit a virtual 8086 than it is to write an emulator, but you need access to the host OS. Linux might be a better bet for trying something like that. The virtual 8086 machine looks just like a process to the host OS, except that you are running some funky old DOS code and you need to catch the hardware interrupts. You also have this little problem of simulating a wide range of old school hardware, which may not even be on the machine hosting the virtual 8086. Come to think of it, you might just want to write the emulator. ;-)

 

[IBMMuseum]

The 80386 introduced 'virtual 8086' mode. The host OS sets up memory a memory region which looks like classic flat real mode addressing inside of the virtual 8086. However, it can be demand paged virtual memory to the OS, so that it is easy to swap pages in and out.

When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly.

OS/2 had a wonderful virtual 8086 mode. You could literally boot DOS 5 in a window, and it would grind the diskette drive just like the real thing. I don't think the modern Windows support is as liberal, but I've not looked into it.

So for a little programming discussion are we ready to see (from me or others) how a little Assembly (it calls interrupts) can be used to detect if your code is running in an OS/2 or Windows DOS box?

BTW, does anybody else know of the bug starting from Windows 95 where the DOS Environment space is 1Kb larger than specified?

 

[Mike Chambers]

So for a little programming discussion are we ready to see (from me or others) how a little Assembly (it calls interrupts) can be used to detect if your code is running in an OS/2 or Windows DOS box?

BTW, does anybody else know of the bug starting from Windows 95 where the DOS Environment space is 1Kb larger than specified?

i think there are minor differences in the emulated real mode memory where you could find a difference in some bytes between a windows and an os/2 box. if you can find something this like you would be able to check those bytes from your program and that would allow you to determine which it is.

maybe im wrong... mbbrutman?

 

[IBMMuseum]

i think there are minor differences in the emulated real mode memory where you could find a difference in some bytes between a windows and an os/2 box. if you can find something this like you would be able to check those bytes from your program and that would allow you to determine which it is.

maybe im wrong... mbbrutman?

No, there are actually interrupt calls designed for that purpose...

 

[Mike Chambers]

No, there are actually interrupt calls designed for that purpose...

i should probably have known that.