• Please review our updated Terms and Rules here

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

reenigne said:
That's similar to what I see for the final part on DOSBox - what CPU are you using? If it's something other than an i8088 (especially if the prefetch queue works differently) that might account for that. Again, lack of RAM is the more likely explanation though.
Click to expand...

IMG_0134.jpg

I use Intel D8088 - 4.77Mhz
 
ok, i added memory expansion board for 640k of memory and all scenes was succesfully displayed. BUT i didnt hear any special music on last scene.
 
The plasma effects, the kefrens bars and the 3-D shapes were the most visually astounding parts of the demo, I feel for anyone not able to enjoy them because they do not have sufficient RAM on their hardware or their hardware is not close enough to the target machines.
 
I dont want to be faultfinder, but...All there is: IBM 1981, yeah yeah this is IBM from 1981. Ok, if its for IBM from 1981 make it for 64k of RAM not for 640k. 640k of RAM was standard on late 80's but not in 1981.. Peace
 
Great demo. If I had been able to watch it back in the eighties I'm sure I would have been even more blown away, because now of course you'll have to think back how it used to be (unless you own one of those and keep using it regularly - I don't).
The only issue I had with the demo is that I could not really read the text (the coloured big text explanations during the demos) - I barely got a few words now and then. Maybe it's just me, unfamiliar with whatever font style was used or something. Or simply because of the colours, I'm not sure - I've only watched the demo once so far.

-Tor
 
romanon said:
I dont want to be faultfinder, but...All there is: IBM 1981, yeah yeah this is IBM from 1981. Ok, if its for IBM from 1981 make it for 64k of RAM not for 640k. 640k of RAM was standard on late 80's but not in 1981.. Peace
Click to expand...

Yeah, we had a bit of debate about this on the mailing list as we were developing the demo. In the end we decided to go with 640kB for a few reasons:
  • It's the memory limit that everybody thinks of when thinking about XT-class (8088/4.77MHz/CGA) machines.
  • It would have been *possible* (albeit expensive) even in 1981 (using a third party memory board). Even if the BIOS doesn't recognize the full 640kB the demo will still be able to use it. As for use of non-IBM parts - IBM didn't make a composite monitor either.
  • Lack of RAM is not the only reason the demo wouldn't have run in 1981 - it requires a 360kB floppy drive for one thing, and DOS 3.0 for another (we initially targeted 2.0 but discovered late that the TP runtime doesn't work with 2.0).
  • We were hoping this demo would inspire others for the same platform, so we were aware that (were were successful) we'd essentially be "defining the platform" for those coming after. Compared to other low-end machines that people often write demos for (the C64 specifically) the machine is weak in a number of areas and having 640kB helps to compensate for that, creating a platform that is both more comparable and amenable to a more distinct range of techniques.
  • Ultimately we were able to make a more visually and aurally impressive demo that way.
 
vwestlife said:
BTW... is Virt the same Virt of T.R.I.A.L who made Galaxy Music Player (GLX)?
Click to expand...

Good catch, but no, our virt is Jake Kaufman. virt's most recent high-profile project was doing all the music for Shovel Knight, and he recently got funding for NUREN. He's just crazy talented.

Galaxy Player was definitely an inspiration, though... I've always wanted to contact that guy to see the source (although stepping through in the DOSBox debugger was very educational!).
 
Scali said:
(sometimes it is faster to process things per word, other times it is faster to process per byte. Not a problem you would have on Z80).
Click to expand...
Actually 16-bit is indeed the fastest for opaque even on the Z80!
Code: 
;set sp to point to end of destination in advance, and of course disable interrupts!

ld de,**
push de

;repeat
That's in worst case 10.5 t-states per byte. If the same word-pattern is being repeated then it's 5.5 t-states per byte (about six times as fast as unrolled ldi)!

I'm reading up on all the blogs atm, very nice stuff!
 
Last edited:
Well done all, very impressive. I can't wait to see the game or a combination of these new methods with 8088 Domination :)

reenigne said:
Yeah, we had a bit of debate about this on the mailing list as we were developing the demo. In the end we decided to go with 640kB for a few reasons:
  • Lack of RAM is not the only reason the demo wouldn't have run in 1981 - it requires a 360kB floppy drive for one thing, and DOS 3.0 for another (we initially targeted 2.0 but discovered late that the TP runtime doesn't work with 2.0).
Click to expand...

Concerning Borland's RTL, from memory it checks the version straight away near the entry point but also in some of the TPU's included in the TPS. For example, I remember CRT does due to extended break checking being brought in version MS-DOS v3.00, likewise OVERLAY.TPU. I noted you are using BPL70N16 which comes with some source, so one option you might have is to use create a separate install of the compiler then use TPUMOVER to bin what you don't need or better still keep the bits of BPL70N16 that are useful and then just bin the rest of the RTL with the aid of D.J. Murdoch's TPU2TPS which although was written for TP6 can be used with TP7/BP7 as follows:

1)copy TPU2TPS.PAS to TPS2TPS2.PAS
2)Find the following line in TPS2TPS2.PAS
Code: 
if file_id <> 'TPU9' then
change the line to be:
Code: 
if file_id <> 'TPUQ' then
3)Compile TPU2TPS2 (note I did very carefully check the above years ago and found it to work fine)
4)TPUMOVE and then TPU2TPS2 as then run both as follows:

Q:\BIN>
Code: 
tpumover turbo.tpl *system[CODE]
[CODE]TPU Mover  Version 7.0  Copyright (c) 1992 Borland International[CODE]

Q:\BIN>[CODE]tpu2tps2 turbo.tpl[CODE]
TPU2TPS - Reads SYSTEM.TPU and extracts SYSTEM.TPS from it.
SYSTEM.TPS created!
Q:\BIN>

5)You then have the SYSTEM.TPS file to play around with for TP7/BP7 as per the documentation included in TPU2TPS.ZIP
On a similar vain is some example code I posted on the DOS Ain't dead forum showing how to abuse TP5/TP6/TP7 to generate tiny COM files, 
e.g. a 1,392 VGA routine using a few for loops and turning that into 97 bytes.   http://www.bttr-software.de/forum/mix_entry.php?id=8224#p8224

I have combined both the SYSTEM.TPS with the COM trick, so effectively I've just used TP as a nice coder generator and ended up with some tight assembler.  I have gone as far as to create test bootsectors directly out of the IDE using a tiny SYSTEM.TPU and this method.  Note; You do not need a TURBO.TPL just SYSTEM.TPU
 
Awesome demo! I tried it on my 5150 with ATI Small Wonder and a Commodore 1902A NTSC monitor but in some screens the monitor can't sync the image (the 1k colour photos or the 256 colour plasma for example) Also the colours displayed in the whole demo are wrong. It's a pity that you chose the first rev CGA, there are only a few in the world compared to the CGA clones.
 
Arjay said:
Well done all, very impressive. I can't wait to see the game or a combination of these new methods with 8088 Domination :)
Click to expand...

Don't get your hopes up; those projects have hit the end of their respective roads.

Concerning Borland's RTL, from memory it checks the version straight away near the entry point but also in some of the TPU's included in the TPS.
Click to expand...

If we release a final version, I'll just NOP out the check or remove the code that needs it.

On a similar vain is some example code I posted on the DOS Ain't dead forum showing how to abuse TP5/TP6/TP7 to generate tiny COM files,
e.g. a 1,392 VGA routine using a few for loops and turning that into 97 bytes. http://www.bttr-software.de/forum/mix_entry.php?id=8224#p8224
Click to expand...

When I read this I thought this was a way to strip things out of TP, but it appears all that is happening in the above post is that the code is copied out of a single code segment and dumped to a .com file with a handful of fixups. This is not really the same thing as using TP to generate .com files, and if you have to write everything inline() to make it work, there is literally no point to this method -- just write in assembler instead.
 
I have clone XT and clone CGA card with B/W 16KHz HSYNC composite output but I'm going to
see this demo in full colors. AFAIK, "multicolor magic" will work for NTSC video only.

1) Can anyone suggest me a good NTSC "modulator" (CGA digital RGBI --> to full color composite NTSC) ?
Wikipedia states the early original IBM CGA produced composite color NTSC with "delay lines".
2) Most of "PCI TV Tuners" (Bt878 ) have NTSC composite mode. Will this work and
was TV tuners affected with NTSC "color fringigng" ?
 
alecv said:
1) Can anyone suggest me a good NTSC "modulator" (CGA digital RGBI --> to full color composite NTSC) ?
Wikipedia states the early original IBM CGA produced composite color NTSC with "delay lines".
Click to expand...

Unfortunately I don't think any such thing exists. If it did, it would probably need to tap into clock signals on the CGA card to fix the color burst phase. I suppose technically it might be possible to derive it from hsync but I would not expect to get very stable colour that way.

Even if the colour did work, the demo still might not run properly on a clone CGA card - some parts rely on CRTC behavior that may vary between different CRTCs, and some parts rely on the precise number of wait-states generated by the CGA card on a video memory access. During development we did find a clone card that had the correct wait-states though, so try it and see.

alecv said:
2) Most of "PCI TV Tuners" (Bt878 ) have NTSC composite mode. Will this work and
was TV tuners affected with NTSC "color fringigng" ?
Click to expand...

That part would be fine. I actually used a Bt878 device (Hauppage ImpactVCB 00166) to make the captures with which I calibrated the colours.
 
I tried it on my Tandy 1000sx, in tv mode with a composite monitor @ 4.77 mode, and the demo ran at the right speed, and the composite screen had a lot of colors, but none were the correct ones from the youtube video.
Also the effect @ 4:37 was complete garbage of flickering lines, but it didn't crash..

But very very impressive work, it actually made me crank up the tandy for the first time this year.

Later,
dabone
 
You must log in or register to reply here.
Back
Top