• Please review our updated Terms and Rules here

Trixter's latest magic... Holy how-in-the-hell!!!???

dr.zeissler said:
perhaps we will see the ultimate EGA demo too...sometimes.
Click to expand...

EGA certainly is an interesting graphics standard. And coupled with a 286 it makes an interesting platform (sadly, if we keep it period-correct, it would be 1984ish, so there would be no audio hardware).
I already explored it a bit with 1991 Donut.

But we're just starting to get the hang of this 8088+CGA stuff, so I don't think we'll be moving to 286+EGA anytime soon.
I am still working on my code, still plenty of ideas that didn't make it into 8088 MPH, and am thinking of porting some stuff over to PCjr/Tandy.
 
Scali said:
Perhaps the video card in the ETV260 is not compatible enough to support this tweakmode.
Click to expand...

I think so, same for Olivetti M19, where the ETV 260 PC hardware is based on (same mainboard). I hope to be able to test on M24 next. But first I have to fix my M380XP1 that I am able to transfer data from more modern PC to those oldies.
 
Scali said:
Hum, 8086 at 10 MHz, quite high-end... Probably too fast :)
Click to expand...

My 8088 is 9.54 Mhz - doesn't feel too fast most days....

But I will second the motion for more Tandy demos but please keep it to RGBI output because - my Tandy doesn't have a composite output.
 
chjmartin2 said:
My 8088 is 9.54 Mhz - doesn't feel too fast most days....
Click to expand...

An 8086 is considerably faster though. The 8088 is starved by the 8-bit bus, and has trouble just fetching its instructions. Having twice as much bandwidth makes things a lot less painful.
I would guess that an 8086 is easily 50% faster than an 8088 with most code.
In fact, the difference probably only becomes larger as the clockspeed goes up, because memory speeds generally did not scale with CPU speeds.
 
Scali said:
I would guess that an 8086 is easily 50% faster than an 8088 with most code.
Click to expand...

Not at the same clock speed, according to TOPBENCH. The difference is much less, from 12.5% to 37.5% when memory cooperates:

NameScoreusecMemTestusecOpcodesusecMemEAusec3DGamesCPUMHz
XT clone (TurboXT)8194594610011074Intel 80888
AT&T 6300 PC821438381115925Intel 80868
IBM PS/2 Model 25/25L91889740976839Intel 80868
Vendex Headstart II81851882970935Intel 80889.54
Tandy 1000 RL111581615811698Intel 80869.54
Commodore PC10-III81851882970926Intel 808810
AT&T 6300 WGS101657651856711Intel 808610

View attachment DATABASE.ZIP CSV attached for reference.

Edit: That Tandy 1000 RL memory score looks like it was typed by hand with a typo.. I don't trust it. I'll ask for someone to resubmit. But the observation still holds.
 
Last edited:
Totally ignorant comment: Isn't a fairly major bottleneck for both the 8086 and the 8088 the need to do effective address calculation using the shared ALU hardware? I *think* the hit varies depending on the addressing mode of the individual instruction being executed but my impression was that in the worser-case instances the need to do the second bus cycle on the 8088 adds only marginally to the total cost of memory operations, which means while there may be a "50% improvement" with certain types of code in a random instruction mix the improvement is going to be substantially less?

(Full disclosure: I've only *barely* touched assembly language for the x86 family, and it was a *long* time ago, so I could be completely talking out my rear here.)
 
Eudimorphodon said:
Totally ignorant comment: Isn't a fairly major bottleneck for both the 8086 and the 8088 the need to do effective address calculation using the shared ALU hardware? I *think* the hit varies depending on the addressing mode of the individual instruction being executed but my impression was that in the worser-case instances the need to do the second bus cycle on the 8088 adds only marginally to the total cost of memory operations, which means while there may be a "50% improvement" with certain types of code in a random instruction mix the improvement is going to be substantially less?
Click to expand...

8086 adds delay when accessing data starting on odd memory locations, which is that 50% in question.
 
Well, my assumption was that the code mix was in fact not 'random' (as it probably is in something like TOPBENCH), but something carefully crafted to make the most of the abilities of the 8088/8086.
So, you would avoid unaligned accesses, and you would avoid complex instructions and slow addressing modes, and instead just plough through memory with the fastest/shortest instructions available (lods/stos/movs/xlat/push/pop are your friends).
In that case, not only will the 8086 shave quite some time off each memory access, both for instructions and for data, but also, it has a longer prefetch buffer and more bandwidth to keep that buffer filled, so as an extra 'bonus', you might run code from the prefetch buffer more often.

Running 'optimal' code for an 8088 on an 8086 or vice versa is not optimal, and not what I meant.
For example, the sprite compiler in 8088 MPH is specifically written for the 8088, and it does not pay attention to alignment with word reads, since the 8088 doesn't care.
An 8086 can read aligned words twice as fast as unaligned words, so it might make sense to access words only on aligned addresses, and emit byte-fetches to align the code here and there.
So hypothetically I would design a different compiler for 8086 MPH.
 
Hi,
first of off, VERY IMPRESSIVE for it's time.

Second, I want to run this on my IBM 5140 with RCA Expansion. It's basically a CGA Card modified for it's expansion bus, but like all other later IBM CGA cards, it uses a different chip, and mine happens to be the HD46505RP instead of the MC6845. Somewhere on the comments of this demo, one of you guys said the code can be tweaked for the HD6845.

Are there any minor and major differences between the HD46505RP and the HD6845?
 
Kazblox said:
Are there any minor and major differences between the HD46505RP and the HD6845?
Click to expand...

Nothing as far as I know. I think the HD46505 will be sufficiently compatible to run the final version (which is coming soon!) There is just one MC6845-specific quirk that we used in the party version (using hsync width 0 which the MC6845 interprets as width 16 but other CRTC's interpret as turning off hsync altogether). In the final version the hsync width is user configurable. Everything else we did should be compatible with other CRTCs with the possible exception of the lockstep code (but the consequences of that not working should be minor).
 
reenigne said:
There is just one MC6845-specific quirk that we used in the party version (using hsync width 0 which the MC6845 interprets as width 16 but other CRTC's interpret as turning off hsync altogether).
Click to expand...

The interesting thing is that the Motorola documentation actually seems wrong: http://www.classiccmp.org/dunfield/r/6845.pdf
It says that value 0 means no HS is provided.
So it looks like the clones follow the information in the datasheet.

But the way the MC6845 actually works, makes more sense. Turning off HS seems to have no practical use. Setting the width to 16 does, however.
The PIT does the same for example, a countdown value of 0 is interpreted as 65536.
So in my opinion it's the clones that don't reinterpret 0 as 16 which are the quirky ones.
Then again, they just follow Motorola's specs, unlike Motorola's own chips :)
 
Okay I received my latest CGA card, which is a full length one, feature complete with CGA snow \o/

longcga.jpg


Also, this one runs 8088MPH all the way to the end. But what about these questionable parts? :) Screen was rolling+flickering like crazy. Those two RCA ports didn't give any picture not even with King's Quest, so I wonder what's up with that.

https://gabucino.hu/tmp/IMG_3891.JPG
https://gabucino.hu/tmp/IMG_3892.JPG
https://gabucino.hu/tmp/IMG_3893.JPG
https://gabucino.hu/tmp/IMG_3897.JPG
https://gabucino.hu/tmp/IMG_3898.JPG
 
Gabucino said:
Okay I received my latest CGA card, which is a full length one, feature complete with CGA snow \o/
Click to expand...

Interesting.
I figured there'd be Taiwanese-made clones that are pretty much a 1:1 copy of the real IBM. But so far the only CGA-compatible chips I've encountered in clone PCs were made by ATi or Paradise.

Screen was rolling+flickering like crazy.
Click to expand...

Yes, if you would replace the UM6845 chip with a Motorola 6845, that would fix it :)
Alternatively, we can release a patch that doesn't use hsych width 0, which avoids this problem on clones.
The Kefrens part does not look correct either (I take it you used a real 8088 CPU at 4.77 MHz?). In fact, it looks similar to what I got on the ATi and Paradise cards. For some reason they don't display any bars at the top part of the screen.
I wonder if this is also the UM6845's doing, or if there's something else that affects that.
The Hitachi-made HD6845 found on some real IBM CGA cards does not have this problem at least.

Those two RCA ports didn't give any picture not even with King's Quest, so I wonder what's up with that.
Click to expand...

I wonder why there are two ports in the first place. Perhaps they aren't composite output, but something else?
Looking at the circuitry though, it looks like there should be a composite circuit on there. If you look at the headers in the top-right corner, there should also be a composite signal on those. You could try tapping into that.
On real IBM CGA cards, this is where you can attach a TV modulator. The IBM 5155 uses it to connect the internal monochrome monitor.
The headers on this card look the same, so I suppose they also have a composite signal on there.
 
Last edited:
Gabucino said:
Also, this one runs 8088MPH all the way to the end. But what about these questionable parts? :) Screen was rolling+flickering like crazy. Those two RCA ports didn't give any picture not even with King's Quest, so I wonder what's up with that.
Click to expand...
I've got the same monitor matched up to a EGA card on my XT clone desktop.
 

Attachments

  • IMAG0022.JPG
    IMAG0022.JPG
    82.8 KB · Views: 2
That was very-very interesting to watch. Is it even possible to bitbang more out of that hardware? Your team warped the computers physics barriers at PhD levels.

I have a question though. On old consoles, hackers often use unused i/o registers for scratchpad memory storage + squeeze some extra cycles sometimes. Or even safely run code off the sram of a SMS cartridge. Is there any benefit / possibility to do this on a legacy pc?
 
You must log in or register to reply here.
Back
Top