• Please review our updated Terms and Rules here

Tiny 'XT-class' machine

A bit of curiosity here--how closely is the original XT hardware emulated? Can I, for example, vary the memory refresh interval by reprogramming the 8254 (and is there a refresh flag that's readable?). Do you emulate the 3237 and 8259 chips? If I were to pass you the image of the Landmark XT POST ROM, would it run successfully?

Or is this more a matter of supporting XT functionality at the BIOS level?
 
carlsson said:
Well, let's say you are building a 8088 emulating system, not an XT emulating system. I'm sure a skilled engineer can interface almost anything to a 8088, not only limited to the hardware available and chosen at the time of the XT was defined.
Click to expand...

Correct. This was what i was originally thinking, yes.
Well, for that vision to be fully realized, this thing is going to need some form of expansion, which could be ISA (full or LPC) or PCMCIA or (last resort) 'other', if users are to get the most out of this little workhorse.. This will depend completely on what extras I can cram into the firmware..

And no I don't think the COM port is an expansion bus :lol:


Regards,
Valentin
 
Last edited:
Chuck(G) said:
A bit of curiosity here--how closely is the original XT hardware emulated? Can I, for example, vary the memory refresh interval by reprogramming the 8254 (and is there a refresh flag that's readable?).
Click to expand...

Due to (very tight) firmware constraints, some key mainstream aspects of the architecture have been retained, whilst other parts have been 'simplified'. I guess you could think of this as a 'lean' implementation :)

Your example would not work on this hardware, as any read from Port 41h would have no effect and writes to the same would be ignored..

Merely curious, but why would you want to vary the refresh interval anyway? Everything I've read about the memory refresh timing indicates that it is probably best left alone?


Chuck(G) said:
Do you emulate the 3237 and 8259 chips?
Click to expand...
If by 3237 you mean 8237 DMA then no, well at least not at this time.
Currently testing the 8259 PIC functionallity at present.


Chuck(G) said:
If I were to pass you the image of the Landmark XT POST ROM, would it run successfully?
Click to expand...
It would probably fail, due to lack of (any kind of) support for the FDC hardware (but it does fail with 'drive not ready' error when anything other than drive 80h is accessed via INT 13h), among other things..

You see, the supported ROM BIOS functions are in fact serviced via native algorithm(s) (including non-standard INT 33h!). This provides two fairly major advantages:
1.) From the users point-of-view: Enables accelerated BIOS function execution.
2.) From my point-of-view: Allows more efficient use of the available firmware capacity.


Chuck(G) said:
Or is this more a matter of supporting XT functionality at the BIOS level?
Click to expand...
While there is a strong emphasis on the BIOS-level functionality, there is also at least reasonable support at the I/O register level i.e. port 60h read keystroke etc

I have a partly-compiled list of supported BIOS/registers, though it is a work-in-progress. Will try to clean this up and post it when I have free time.


Regards,
Valentin
 
Last edited:
basman74 said:
Tell me, why would you want to vary the refresh interval anyway? Everything I've read about the memory refresh timing indicates that it is probably best left alone.. Please explain.
Click to expand...

Not particularly to vary the refresh interval, but to monitor the refresh flag in I/O port 6. It toggles about every 50 microseconds even on the latest PCs. It's used by some programs for very short timing intervals. Saves one the necessity of fooling with timers or CPU loops for sub-100 microsecond delays.

And yes, my typo--I meant 8237. The point was that there is a lot of old 5150-era software that plays with hardware resources directly (I wrote some of it). Nowadays, programs tend to be better behaved. I was curious as to what extent you've accommodated the hardware register-twiddlers.

If you would like, I can forward an image of the Landmark POST ROM for testing. Simply replace your BIOS ROM image with it. Floppy and hard disks are not needed to run it.
 
Chuck(G) said:
Not particularly to vary the refresh interval, but to monitor the refresh flag in I/O port 6. It toggles about every 50 microseconds even on the latest PCs. It's used by some programs for very short timing intervals. Saves one the necessity of fooling with timers or CPU loops for sub-100 microsecond delays.
Click to expand...

Now that I can understand! Yes (you jogged my volatile memory about this), this was given some consideration to at the beginning (one of several, which relate to the 8253 among other things).

One very important comment I will make about this: Many of the compromises that were made around this implementation mainly stem from the desire to integrate a 6845 CRTC and also the 8042 KB-controller into this design, thus eliminating the need for a separate video and keyboard chip!

The arrangement decided upon was this: Execution is divided into 3 separate time-slices per video frame - 25-30% for the 8088 and 65-70% for the 6845+everything else etc.

Now you probably wouldn't expect this setup to work at all (I didn't), but it does surprisingly well indeed (and I feel like a happy little kid again playing games like conquest and digger :lol:).

The only problem however, comes when you want to do more advanced programming (like polling a pin on Port 06h toggling @ 50 usec) the inclusion of the 6845 / 8042 combo are not an advantage, but a hindrance.


Chuck(G) said:
And yes, my typo--I meant 8237. The point was that there is a lot of old 5150-era software that plays with hardware resources directly (I wrote some of it). Nowadays, programs tend to be better behaved. I was curious as to what extent you've accommodated the hardware register-twiddlers.
Click to expand...

This is accommodated to a degree, subject to the limitation noted above.


Chuck(G) said:
If you would like, I can forward an image of the Landmark POST ROM for testing. Simply replace your BIOS ROM image with it. Floppy and hard disks are not needed to run it.
Click to expand...

Would like to try it, but then I realized I cannot even load the POST image (insufficient free space in the firmware) even if I remove my 'BIOS ROM' handler. As previously stated, there is no 'BIOS ROM' in the conventional sense - the 'BIOS ROM' functions are emulated natively (along with several register-level devices, hence the code-space efficiency boost).


Regards,
Valentin
 
Last edited:
Hello all,

Just a quick update on this project:

Well so far the 8259 PIC basic functionality is nearly fully tested/debugged and is now working correctly. As a result of this fix, around 77 out of the eighty tested game programs now load, with around 70 of the loaded games now playable. Prior to this, only around 25 games were playable, so a big improvement there..

I suspect the reason why the other ten-odd games do not work may have to do with the fact that I'm handling the BIOS ROM functions natively rather than using a real BIOS ROM image. Will look into this further..


I have also compiled some Dhrystone v1.1 benchmarks on this platform:

-------------------------------------------------------------------------------------
PC chipset + 6845 CRTC emulation enabled: 230 Dhrystones/sec

PC chipset emulation only: 1015 Dhrystones/sec


On the graphics front: Apart from cleaning up some INT 10h functions, I am still looking at the extended screen resolutions, though in my opinion at 230 Dhrystones, anything better than say 320x200 16-color tandy/pc-jr mode might not be useful in this case?

On external bus design: I may consider adding an external ISA bus on the next PCB revision if I successfully substitute the 6845 CRTC module for an ISA bus interface module. Of course this still leaves us with the supply level problem (i.e. for the legacy stuff), but the surprising thing I found here is that you can actually buy most (new) legacy ISA-based peripheral devices in 3.3V-only as well! :eh:


Regards,

Valentin
 
Progress update for 'Tiny-XT' machine

Progress update for 'Tiny-XT' machine

Hi All,

Well, after wrestling with the bit-plane requirements of the EGA memory map, I decided to look at an easier alternative for access 320x200 16-colors - the 'PC-Jr/Tandy 1000 compatible' screen modes (BIOS video mode 09h). After around a week or so of solid coding, I had some success :cool:

Only one single page of 32K video RAM, located at B800:0000 is available at the moment, so any games requiring video 'page buffers' for animation will have to wait. However, I did find an early demonstration version of SimCity that would indeed run on a single video page in this mode.

Image 1: Overall system image
Image 2: Closeup screen shot

In addition, managed to bump up the speed of the CPU emulation (video enabled) by around 80-100%, to take advantage of the improved graphics. Dhrystone 1.1 benchmark (video out enabled) now stands at around 500 Dhrystones/second.

Due to the emulator kernel re-write, the 8088 CPU now has better access to the virtual timers in the 8253 - to the point that the 'squeals' made by the flying pigs in Conquest now sound quite close to how I remember them.. This also means polling a DRAM refresh bit toggling at 50usecs should now be no problem at all ;)


Cheers,
Valentin
 
Last edited:
FWIW, here's a PC/PCjr capable game with source code:
http://www.oldskool.org/pc/jumpman

It uses video mode 8 though, but will use 3 voice sound and 16 colors if the machine byte is set to be a PCjr.

I've found your project to be fascinating. I have a thing for tiny computers, especially ones that are silent too. Very much unlike the IBM AT. ;)
 
@hargle

Thanks for the link. Managed to get that game running once I re-enabled the 'POP CS' instruction in the CPU module.. Funny thing about Jumpman is that I didn't have to resort to adding BIOS Video mode 08h, as the game appears to play well in CGA composite mode (see below). As yet, I do not have the 3-voice sound capability of the PC-Jr/Tandy, only have PC speaker support, though this is running through a single-channel DAC, so it should be possible to implement more complex sound circuits..


Image1: Overall system
Image2: Screen close up

While the game is indeed playable (and also quite challenging - never played this game before until now) , there appears to be an issue with the high score table: high score fields appear to be filled with random ASCII characters(!), will have to look into that a little further..


Cheers,
Valentin
 
Okay, I worked out what that random ASCII characters problem was in the highscore table for Jumpman - DOS cannot create a new HIGHSCORE.DAT file if writes to the hard disk are disabled at the BIOS level..:roll:

After several distractions, I am posting the supported BIOS functions of the on-chip emulator:

BIOS INT#______SUPPORTED SUB-FUNCTIONS (* = currently under development)
---------------------------------------------------------------------------------------------------
08h____________Supported
09h____________Supported
10h____________00h,02h,03h,06h,07h,08h,09h,0Ah,0Bh,0Fh,10h,1Ah
11h____________Supported
12h____________Supported
13h____________00h,02h,03h*,08h
14h____________00h,,01h,02h,03h (functions written but not yet tested)
15h____________Not supported
16h____________00h,01h,02h*
1Ah____________00h,01h
33h____________00h,01h,02h,03h,04h,05h,07h,08h,0Bh,0Ch
74h____________Supported


I want to point out here that above listing, while not exhaustive is fairly accurate. In addition, some functions are only partially supported at this time - like the vertical scroll function for example - cannot (yet) specify a 'window area' to scroll, only the number of vertical text-lines to scroll etc.
 
Last edited:
basman74 said:
Okay, I worked out what that random ASCII characters problem was in the highscore table for Jumpman - DOS cannot create a new HIGHSCORE.DAT file if writes to the hard disk are disabled at the BIOS level..:roll:
Click to expand...
hah, yeah that would do it. If I were to go back into that soure code someday, I would handle that a bit more gracefully. Since that was never a part of the original game (it was originally a DOS-less booter floppy) that's all my code to handle that file, so bugs are present for sure.
It's super cool to see jumpman in full 16 color glory. Since my PCjr is unplugged at the moment, I'm always stuck with it in CGA.

I think that's an excellent list of supported INTs you've got. Should handle virtually anything. Adding INT 13 fn 1 (get status of last operation) should be super easy to add, as well as verify (fn 4). In all of the int 13 stuff I've done, I just return CY clear for verify without actually doing the disk work at all, as it is mostly a useless function with modern hardware, but lots of old software still uses it. Oh, and Fn 8 is pretty important.
INT 10h is obviously the biggest and ugliest.
Off the top of my head, I can't think of any other BIOS level INTs I've ever really used, other than INT 3.
 
@hargle

If I were to go back into that soure code someday, I would handle that a bit more gracefully. Since that was never a part of the original game (it was originally a DOS-less booter floppy) that's all my code to handle that file, so bugs are present for sure.
Click to expand...
I believe the 'bug' here lay in the fact my BIOS did not allow your code to do what it needed to. Other than that, your code works perfectly. :D


Adding INT 13 fn 1 (get status of last operation) should be super easy to add, as well as verify (fn 4). In all of the int 13 stuff I've done, I just return CY clear for verify without actually doing the disk work at all, as it is mostly a useless function with modern hardware, but lots of old software still uses it.
Click to expand...
These will definitely be added, thanks for the suggestion!


Oh, and Fn 8 is pretty important.
Click to expand...
Agreed. I forgot to mention about the supported hardware interrupts in the BIOS interrupt list (that's fixed now). Hardware interrupts 08h, 09h and 74h are installed by the BIOS (do not have an interrupt handler as yet for the COM port, so only software polling is supported at the moment). When any of the hardware ints are called, they execute a routine native to the host MCU by executing a normally invalid (for any CPU up to a 386) opcode.


INT 10h is obviously the biggest and ugliest.
Click to expand...
..and it just got a little uglier.. today I added/tested the Tandy/PCjr color palette sub-functions AX=1000 and AX=1002!
 
Last edited:
There's a lot to BIOS compatibility and I hope you've addressed it in some fashion.

If it were just a matter of supporting the interrupts, Phoenix Technologies would never have gotten off the ground. Too easy.

Phoenix worked their code so that a program could perform far calls into the BIOS code and all of the BIOS RAM area bit definitions worked--without duplicating the PC BIOS code itself. It was quite an undertaking. IBM ultimately had to do the same thing on the PC AT to retain downward compatibility with the XT. If you look at the code you see unconditional jumps everywhere--and you wonder why.

So, for instance, do you maintain an 8-byte disk parameter table at F000:EFC7? Is your INT 10H entry point at F000:E3FE?

This is something you have to think about if you want to maintain strict PC compatibility. The BIOS guides from Phoenix published by Addison-Wesley back in the late 80's can be very useful--they describe the BIOS interfaces, memory usage and operation in painful detail.
 
Hi Chuck,

There's a lot to BIOS compatibility and I hope you've addressed it in some fashion.
Click to expand...
Probably more than I realise yet, though I believe I have addressed this issue to a fair degree. Currently doing this by way of building default interrupt handlers, data tables and character ROM data etc into specific addresses normally occupied by the BIOS ROM. Also, the BIOS area in this case being in RAM, can be 'enhanced' via update after boot-up. That said, this area of support isn't quite at the level I am happy with currently.

I've an interesting experience to relate on the BIOS issue: Nearly twelve months ago, when I set about designing this emulator 'for a bit of fun', I only had (back then) 512K of system memory accessible to the emulator. Therefore I decided (on some misguided tangent) that if I simply 'wrote a CPU emulator and supported some of the critical BIOS INT functions' I would have a 'PC compatible'! This (very wrong) decision coupled with the fact that I had successfully managed to get going my first game 'crossfire' by sierra on-line (which makes no direct calls to BIOS ROM) effectively set me up for massive 'enlightenment' later on, when I attempted to get other programs working..

Twelve months on, while I still have not yet achieved 100% compatibility at the BIOS level (but something I am working on), those early days are well and truly behind me particularly with respect to games. However, game compatibility does not necessarily extend to all those legacy business applications, with only very limited testing done to-date. Therefore, I have been thinking about recruiting some beta-testers to help out with this little system i.e. handing out a few boards 'free-issue' to interested members etc.


This is something you have to think about if you want to maintain strict PC compatibility. The BIOS guides from Phoenix published by Addison-Wesley back in the late 80's can be very useful--they describe the BIOS interfaces, memory usage and operation in painful detail.
Click to expand...
Many thanks for this suggestion! - will look at obtaining a copy. Ploughing through a 300-odd page reference book is not what I would consider painful compared to some of the other 'alternatives'.. ;)


So, for instance, do you maintain an 8-byte disk parameter table at F000:EFC7? Is your INT 10H entry point at F000:E3FE?
Click to expand...
Well, the answers are: yes and no - I thought INT 10h entry point was at F000:f045?

EDIT: Actually, i *think* it's meant to be F000:f065?.. Guess I'd better buy that book!
 
Last edited:
Progress update for 'Tiny-XT' machine

Progress update for 'Tiny-XT' machine

Hi All,


While recovering from the flu, I have managed to put together another video demo:

http://www.youtube.com/watch?v=JDxYVR0bLQk


In addition, after my last post (which clearly demonstrated my lack of knowledge on matters relating to the BIOS), I decided to do more research on the topic, and found various bits of info about BIOS ROM entry points etc. After modifying my emulator to model these exact points, I was encouraged to find certain early games (which appear to rely on direct BIOS ROM calls) that previously crashed now run quite happily! :)

Have since ordered (but not yet received) the Phoenix Tech. BIOS 'bible' reference..

I want to thank Chuck(G) et al. for providing me with a renewed motivation to 'get it right' on the hardware and BIOS compatibility side of my emulator (which admittedly started off as a six-week slap-dash effort just for the fun of it).


Cheers and enjoy!

Valentin
 
Progress update for 'Tiny-XT' machine

Progress update for 'Tiny-XT' machine

Hello all,

Just a quick update on my pet project - I have managed to add 3-voice sound support (i.e. emulated the SN76496 sound gen) to my prototype board:

http://www.youtube.com/watch?v=ZIW-iRq7Tnc

Note: noise effects may be somewhat different from the real thing, since I use a 'Lean' method (oh no, not the 'L' word again.. lol) to generate the noise source. Apart from that.. well I'll let you be the judge! ;)

EDIT: Would like to ask members here if they could run the following (optimized dhrystone 1.1) benchmark on their 8088 (or V20) based machines? I'm curious to see how well it compares with the 500 Drystone rating I got on my prototype. Any feedback would be greatly appreciated. Thanks in advance!

http://members.optuszoo.com.au/pioneer10/DHRY16.zip



Cheers and enjoy!

Valentin
 
Last edited:
Hi Mike

Thanks for your reply. Hooking the board up to the web for chat/email etc would be very cool! Just wanted to get the video/sound hardware emulation going first, progressing to a point where I really should now be looking at other I/O devices i.e. COM/LPT and/or bus expansion options etc.

I would like to try getting your 'leetIRC' program to run though an external serial modem via COM1 and have a question about it: Have searched around for an answer to this, but I am unsure as to what 'packet driver' to use with your IRC client. Any suggestions? Been far too long since I last seen let alone used a serial modem! ;)

(EDIT: I found some PPP drivers to try..
http://www.ibiblio.org/ais/nl-dos.htm )

Also, on your suggestion regarding your RockIRCD server, I did try both running/compiling your rockircd.bas file as suggested (using the QB V4.50 compiler) and in both instances got an 'Expected: GOTO' error @ line 560..


Regards,
Valentin
 
Last edited:
You must log in or register to reply here.
Back
Top