pouët.net

Assembly Summer oldskool compo rules

category: parties [glöplog]
hail to the P133! \o/ :)
added on the 2016-02-16 10:46:33 by wbcbz7 wbcbz7
Quote:
Amiga AGA 060, Atari Falcon 060


So finally the AMIGA vs ATARI battle can begin :P
added on the 2016-02-16 13:20:37 by tFt tFt
Quote:
you will make a lot of home enthusiasts happy if your demo doesn't require an overclocked 060. :-)


Or if it just runs at more than 20fps in general (:
added on the 2016-02-16 17:33:16 by ___ ___
Quote:
Or if it just runs at more than 20fps in general (:

Let's not get carried away here ;)
added on the 2016-02-16 18:00:03 by britelite britelite
wormsbiysk: it turned out that the mode I got working was almost the same as yours, just with the vertical blank having a different timing offset. Vertical refresh rate was almost the same, 59.93 Hz for your timings, and 60.14 Hz for mine. I measure the rate with a busyloop that waits for vertical retrace bit, and reads time from the PIT.

I had made the wrong correction to the original 120 Hz mode, doubling vertical timings instead of turning on the dotclock rate division-by-2, which wasn't being done due to a bug in the original code (wrong port number, 0x3C4 vs. 0x3D4). Without dotclock rate division it was 31 kHz as usual, and with my modifications it ended up almost the same as your timings. After I fixed the dotclock rate division, my mode went to 30 Hz vertical! When I restored the vertical timings, I got a 60 Hz / 15 kHz mode, but then my TV wouldn't sync to it anymore. :( So, 15 kHz VGA might not be the brightest idea ever.

jmph: I sent you mail.


Anyway. DOS only, woo hoo! It means I can use good old "copper" timer interrupts to change video parameters accurately synced to screen refresh!?!? (if the Pentium is underclocked to 1 MHz, it might even make sense)

So, Pentium... and GUS! So now that we get a nice multichannel sample playback sound card with its own memory, capable of playing MODs and XMs without CPU load, we also get enough CPU power to even stream mp3s. ;)


By the way. 1997 wouldn't feel like a bad theme for an oldskool compo.

Quote from Assembly 1997 invitation
Quote:
We will use the same projector as in ASSEMBLY '96. This means that we
have to load a special driver before showing anything on the screen. This
driver enables the video convertor to work correctly.

Unfortunately it has the side effect of slowing down demos using a specific
timing routine. To counter this the driver will be available from our web
site as soon as possible so you can test your demo or intro with that
driver to see if it affects your code. In ASM '96 only couple of demos
suffered from the timing problem but it is better to be safe than sorry.


What driver are they talking about? Does anyone still have the driver? I wonder if the slowdown meant 60 Hz refresh rate.


Further quotes from the same invitation
Quote:
Competition machines
--------------------

DEMO, 64k INTRO & 4k INTRO

-_Pentium 133 mhz with 16 MB of RAM
-_MS-DOS 7.0
-_The competition machine will be booted up with HIMEM and
EMM386, so make sure your productions runs with them.
-_2 MB PCI SVGA graphics card (a S3 964 accelerated card)
-_Gravis UltraSound with 1 MB of on board memory and / or
Sound Blaster AWE 32 with 1 MB of on board memory
-_550 kb of free base memory
-_highest allowed screen resolution is 640 x 480
All productions have to support 256 color mode but can also use
any high color use ( we will use the best possible mode when
showing the productions)


Quote:
3.4 PC demo compo

Maximum size in executable form is 6144 kb (6 MB).

Maximum showing time is 8 minutes, the demo itself can be longer.

Maximum base memory requirement is 550 kb.

100% VGA register level compatible graphics modes and SVGA modes
up to 640*480 are accepted.

You are free to use any number of colors but the demo has to work also
with only 256 colors.

Pure animation files are not accepted.

Also executables only including an animation and an animation player will
not be accepted, this is not an animation competition.

Gravis Ultrasound (512kb) and SB PRO/SB 16 support required. The
demo has to have also a "no sound" option.


So, you even had to support a half-meg GUS and SoundBlaster... I wonder if those requirements were actually tested, particularly the 512k GUS thing.
added on the 2016-02-16 20:33:45 by yzi yzi
Oh yeah, one more thing. What was said about Amiga in the Asm'97 invitation

Quote:
3.8 Amiga general rules

As the competition machine we will use:

-_a1200
-_2 mb chip memory
-_8 mb fast memory
-_68030 at 50 mhz

We are still considering a Blizzard 68060 turbocard for the
machine and a possibility to use some 24 bit graphics card. If you
have opinions about this, please send us comments.


I wonder if the compo machine was eventually a 030 or 060, but the speed difference is huge.
added on the 2016-02-16 21:13:15 by yzi yzi
If you try to use those 60 Hz modes in Dosbox, you'll quickly notice that Dosbox doesn't give a flying CRTC about your timings, and mode 13h will just be 70 Hz and that's it. BUT if your Dosbox vsyncs to the host, then according to my tests, it will somehow manage to bring that rate over to the guest! A main loop that syncs to port 0x3DA vertical retrace bit will only draw 60 frames a second... even though at the same time mode 13h will be measured as having a vertical retrace time interval of 17045 PIT ticks, i.e. 70 Hz. YMMV, but this is how it works for me. Debian Linux, Dosbox 0.74. Though it's been at 0.74 for ever, and maybe other builds work differently. Maybe there's some kind of heuristics that tries to guess what the code is doing. At least my vbiMeasure() routine measures VGA mode 12h as being 60 Hz and mode 13h as 70Hz. And no matter what garbage you throw at the CRTC timing registers, as long as you've set mode 13h, the measured duration does not change.

Anyway, it doesn't matter. I'm not going to spend any more time figuring out how that particular emulator works. To get timing right, I can just use a timer interrupt at 60 Hz simulating a VBI, without actually syncing to port 0x3DA's vertical retrace bit.

Here's my old VBI routine for Watcom + PMODE/W from 1996-1997. Compile the asm file with "tasm /ml".
http://www.kameli.net/~yzi/vbi.zip

For Dosbox development, turn on the DOSBOX_LAMER mode

Code:#ifdef DOSBOX_LAMER vbiSyncOn = 0; // turn off syncing to port $3DA vertical retrace bit vbiRealTicks = 19906; // hard-code the timer interrupts to about 60 Hz vbiTicks = vbiRealTicks - (vbiSyncOn?400:0); printf("vbiTicks %d\n", vbiTicks); vbiTicks2 = 4500; vbiTicks1 = vbiTicks - vbiTicks2; #else vbiMeasure (); // <-- measure the time between vertical retraces #endif


I'm setting the rate to 60 Hz, because that's what I want it to be on the actual compo machine.

(I think this is at least a little bit related to the oldskool compo rules)
added on the 2016-02-19 22:08:27 by yzi yzi
what about using a DOSBox-X build for development? It does emulate VGA hardware more accurately than regular DOSBox builds so almost every undocumented trick can work there ;)
added on the 2016-02-20 09:32:20 by wbcbz7 wbcbz7
Quote:
What driver are they talking about? Does anyone still have the driver? I wonder if the slowdown meant 60 Hz refresh rate.


It did. It forced 60Hz rates for modes that typically ran at 70Hz so that they'd work connected to the projector of that year. Assembly orgas switched to a Sony DSC-1024 scan converter one or two years after that device was available, which eliminated the need to force specific rates (the device performs line/field/frame averaging to fit any source to broadcast rates).
added on the 2016-02-23 04:59:01 by trixter trixter
Question! What sort of Pentium 133 does the compo machine have? 16 or 32 kB L1 cache, and MMX or not?
If I read this correctly, the MMX model's cache is 32 kB.
https://en.wikipedia.org/wiki/P5_%28microarchitecture%29#P55C

(no, it's not like it will make my entry suck less)
added on the 2016-07-28 19:08:27 by yzi yzi
yzi: Jope can probably give more exact details, but it will be a non-MMX Pentium
added on the 2016-07-28 20:56:50 by britelite britelite
Thanks. I guess the L1 cache is 16 kB then.
added on the 2016-07-28 21:24:07 by yzi yzi
512k cache on the motherboard, non-mmx cpu.

The cpu is an underclocked p200.
added on the 2016-07-29 08:02:38 by Jope Jope
Quote:
The cpu is an underclocked p200.

lol :)

what amount of memory is installed on soundcards? (just to be sure)
added on the 2016-07-29 10:01:58 by wbcbz7 wbcbz7
Seven pages of discussion and only seven demos - that's rather a small output... Was the early deadline a problem?
added on the 2016-08-09 11:42:09 by marlowe marlowe
Ivory demo just barely missed the deadline. Wbc\\bz7 said no b-state demo this time either but there was clearly going to be, so i'm guessing not enough time also.

There has been now some discussion between me and visy that we should build a some kind of simple engine for everyone to use and make the process more stream lined to rise the presentation and overall quality of productions. No promises but stay tuned I guess. I already had a quite wonky GNU rocket setup for the ivory demo.

I'd prefer the rules stay like they are now, I maybe be open for lowering the pentiums specs a little at best to a fast 486 or 60mhz pentium for example.
added on the 2016-08-09 11:59:46 by MuffinHop MuffinHop
If you make a simple engine with a nice ready-made environment, I promise to make a demo for asm17.
added on the 2016-08-09 12:16:12 by Preacher Preacher
I hope the compo rules stay same at least for few next years. Many ppl developed their tech for this year compo, quite many of them didn't make it to the compo (deadline, irl blockade, too much good weather, etc) but they still have it and prefer to releaase it at Assembly next year.
added on the 2016-08-09 12:29:35 by mikron mikron
And of course there are other parties as well..
added on the 2016-08-09 12:55:30 by Preacher Preacher
I agree with Mikron that the rules and platforms should stay the same. If it changes every year, then we'll only get the "how does this work again, lolwut" type demos. And the audience won't have any clue about what the platform actually is like.

Preacher: what other parties have Pentium 133 as an announced spec?

I like the 1997 style PC, because that's just before accelerated 3D and Windows and that sort of crap. Keep the hardware the same, let it settle and let people do stuff with it. AND all of my time allocated for this year went to setting up the development environment and re-learning things.
added on the 2016-08-09 14:39:18 by yzi yzi
yzi: there are always wild compos. I don't see any reason why a DOS demo wouldn't be applicable for let's say Revision or Evoke.

Quote:
all of my time allocated for this year went to setting up the development environment and re-learning things.

This. I remember my mode13h pretty well and I even have some old source code stashed somewhere, but getting it all to build/compile is way too much of a hassle. Something with a plasma or a starfield or something as a template, with music playing (MIDAS would be fine) and pmode handling that compiles from the press of a button would be _awesome_.
added on the 2016-08-09 14:51:07 by Preacher Preacher
I talk about wanting a compo with a settled-down fixed oldskool PC specification that is the same for all entries, and not only one year, but year after year... and you suggest wild compos? Nothing could be further away.

If you want, I can send you my Watcom setup for Dosbox, contact me on irc.
added on the 2016-08-09 15:34:32 by yzi yzi
Preacher, With that logic we should put everything into wild compos. No more amiga demo compo at Revision, all the amiga demos can go to the wild compo, riiiiiight? Assembly's real wild is already quite a mess, and then it would be extremely hard to figure out how led screen compares to pentium 133, amiga or c64. Then anyone who puts a lot of effort into a ms-dos pentium demo cannot be guaranteed that they don't lose to a very odd hacked platform. Not that there's anything wrong with either one from the get go but you just cannot compare apples and oranges.

With the current rule set you have roughly similar platforms. And they are platforms for which people want to see more stuff on and they are platforms that there is people who are interested making for. But with MS-DOS there is quite a lack of modern and lean software to work with and some of the engines are really old or you have to start from scratch. So yeah there were people saying that the compo wasn't good enough. Well duh if most of the entries had a shitty toolset and were done from (near) scratch.

There are amiga groups that have been building their engines for years and most of the MS-DOS entries at Assembly 2016 were done from scratch so you'd expect at least a bit lower quality and people missing the deadline from the PC guys. No?

That's why I think it's a good idea to build a open development chain that is something fairly common and easy to setup to lower some of the barriers of getting MS-DOS scene back to its feet.

I'm ok with the current rules in the compo but honestly Pentium is way too fast compared to an 060 and I wonder if that will lower amiga or falcon guys interest in participating. Especially if some of the pc guys have proper engine up.
added on the 2016-08-09 15:54:05 by MuffinHop MuffinHop
Current unlimited demos belong to "wild", in my opinion.
added on the 2016-08-09 16:28:22 by yzi yzi
I was just saying that if I'd spent a lot of effort making a demo on obscure hardware, I wouldn't have any issues putting it in a compo with other obscure hardware at some other party. They're all fruit in the end and I have hope that people can distinguish between a pristine homegrown apple and a cheapo banana that has gone rotten.
added on the 2016-08-09 16:41:55 by Preacher Preacher

login