Trekboer by Microdeal

Use this forum to submit new files for the download section of the archive. I will check each submission and upload it to the archive on a regular basis.
Post Reply
User avatar
robcfg
Posts: 1533
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Trekboer by Microdeal

Post by robcfg »

I didn't knew that there were that many nice adventures for the Dragon, so I'm pleased to bring you the perfect dump of Trekboer.

The dump in the archive is missing the Microdeal Software screen, which is not a great loss, but makes the dump not perfect.

I updated the game's wiki page, and you can find my dump from the original tape, fully tested on Xroar and a real Dragon attached to this post.

Have fun!
Attachments
Trekboer (1985)(Microdeal)[!].zip
(17.69 KiB) Downloaded 204 times
Sarah
Posts: 177
Joined: Wed Apr 13, 2011 3:36 pm
Contact:

Re: Trekboer by Microdeal

Post by Sarah »

Just thought I'd mention - if you're new to this game, it's worthwhile trying it with artifacting enabled. It's one of those graphic adventures that looks much better with NTSC colour, as it appears to have been designed with that in mind. Just a pity the text is less clear in that mode though - in an ideal world, an emulator could have split-screen artifacting for games like this, so that both the pictures and text can look their best!
User avatar
snarkhunter
Posts: 241
Joined: Fri Apr 03, 2009 7:16 pm
Location: France

Re: Trekboer by Microdeal

Post by snarkhunter »

Then we would need someone to issue an Amiga port of this game, since an Amiga is the only personal computer that I know of, that had a video hardware with an actual ability to simultaneously display "screens" with different resolutions / modes (there used to be famous demos doing so, back in the late 80's)... Thanks to a bit of electronic wizardry - and programming technology that really was ahead of its time.
Alastair
Posts: 669
Joined: Fri Jul 18, 2008 11:33 pm

Re: Trekboer by Microdeal

Post by Alastair »

snarkhunter wrote:Then we would need someone to issue an Amiga port of this game, since an Amiga is the only personal computer that I know of, that had a video hardware with an actual ability to simultaneously display "screens" with different resolutions / modes (there used to be famous demos doing so, back in the late 80's)... Thanks to a bit of electronic wizardry - and programming technology that really was ahead of its time.
Not so, as what Sarah is describing is having an emulator artifacting part of the screen rather than all of the screen. As far as the 'Dragon within the emulator' is concerned all it's doing is producing a black and white image of the same resolution and colour depth (naturally) from top to bottom. Real Apple II computers, or at least some versions, can do something similar with artifact-like colour for most of the screen and four lines of monochrome text at the bottom, see http://en.wikipedia.org/wiki/Apple_II_graphics.

The Amiga's ability of being able to show several screens of differing resolutions and colour depth simultaneously on the same monitor was apparently not unique. I have read that some graphics card manufactures for the PC created cards with this ability but Microsoft never supported this feature in Windows so the card manufacturers stopped making such cards.
Julian
Posts: 51
Joined: Mon Nov 21, 2011 1:06 pm

Re: Trekboer by Microdeal

Post by Julian »

The big advantage with the Amiga is that it was easy to achieve thanks to a dedicated video processor and most importantly a blitter chip that in a fair number of circumstances was more powerful than the 68000 the computer used. The real beauty was they worked in parallel using shared memory so you could set the whole thing on a timed trigger that didn't upset your main program cycle. Something that we are very familiar with now thanks to dedicated graphics cards in home computers but in the mid/late-80s it was fairly revolutionary and to include it in a "cheap" home computer was very impressive. At this time in the PC's history the PC industry was pretty primitive, producing little more than an expensive 8089 based computer that had the foresight to include a modular expansion system, disk drives as standard and professional server/client communications. At a time when your 8-bit home computer weighed in at around the £100 mark a PC would set you back £2000 (at least). By the time the Amiga came along the PC was still in it's infancy and was still painfully expensive. The 16-bit 68k series processors stole a hefty march on the Intel based PCs but never made a big enough impact on business to get properly entrenched. We only just started to see 80286 based PCs about the time the Amiga was dying off in popularity and it wasn't until the 386 PCs came along that suddenly we had a home PC market. The graphics cards available up to this point were fairly primitive and only the very expensive industry dedicated cards were doing anything special *but* the manufacturers were putting plenty of features in the cards that could only be accessed through dedicated drivers and the lack of consistency between them was the problem. if you take a look at the video standards in that era it had gone mad. I don't believe Microsoft had much to do with any lack of support. Windows was very, very primitive - painfully so even compared to Windows 3 which is the first most people would have experienced. Any scenario that would require a mode switch partway through a vertical refresh would most likely be based in a program that didn't use Windows to start with.

The same trick has been performed in 8 bit computers for some time - a classic example is Elite on the BBC which split the screen in two, high-res monochrome for the top "3d view" and mid-res 4-colour for the lower "instruments" part of the screen. Any computer with a vertical sync interrupt can be made to do the same trick provided the mode switch happens quickly and reliably. The downside is that you end up creating a carefully timed loop to achieve this and waste a fair chunk of your processing waiting for something to happen without doing anything otherwise useful. The problem is made worse if the split is towards the lower part of the screen.

In an adventure game though it would be a fairly trivial matter, by and large they don't actually do much from a programming perspective and more importantly don't tend to be time critical so if it takes 3 screen refreshes to interpret and process a command instead of just 1 the game player isn't going to feel too hard done-by.
Post Reply