I can image it nowadays, using emulators and cross-compilers, but how
it was done ten years ago ?
-- Wojtek
| Wojtek Wasilewski | This message represents my own |
| Bydgoszcz, POLAND | opinion and is independent of |
| wwa...@hvsag01.ns-nl.att.com | the opinion of my employer, AT&T |
: I can image it nowadays, using emulators and cross-compilers, but how
: it was done ten years ago ?
I'm not sure exactly, but I'm certain that if they did use Spectrums (some
were of course written on other machines, eg Manic Miner on the TRS80), they'd
use pretty well the same method as we do today.
Many assemblers have a pseudo opcode which enables files to be assembled from
disc/microdrive, eg the assembler I use enables me to produce abt 25k of
code which should be sufficient for almost any program - my programs rarely
go above 5K.
The game I'm writing at the moment is totally modular, pretty well almost
every routine can be used independently or slotted into another program
etc (call me lazy if you like, but what is the point of writing the smae
routine for different programs (apart from maybe speed))
As for debugging it, well, start with a few of the screens, test if they work
then add in the others and pray! If you have a multiface with a disassembler
(yes you can get some that work with an MF3) then life is made much easier..
Other than that, enormous amounts of paper, tea and patience..
Hmmm, haven't really answered the question that well...Nevermind..
Dominic - who'll be at Filderstadt tomorrow DB permitting...
--
"I saw two shooting stars last night,
I wished on them, but they were only satellites,
Is it wrong to wish on space hardware?" - Billy Bragg
As far as I remember, the assembler source for Rockfall (1) fits into the
machine all at once. Although the game is quite large, most of that is
data and so it isn't a problem. We define levels individually and then
eventually collect them together to form the huge code file for the game.
The code for Rockfall 2 is larger, but by then I had a +3 and assembling
from disk isn't so bad - only one cup of coffee required. :-)
Ian Collier - i...@comlab.ox.ac.uk - WWW Home Page (including Spectrum section):
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html
New to this group? Answers to frequently-asked questions can be had from
http://www.nvg.unit.no/spectrum/ .
Sam Coupé FAQ: http://whirligig.ecs.soton.ac.uk/~tsp93/Coupe/FAQ.txt
>I was always curious about how the programmer's workshop looked like.
>How it was possible to write and debug say 40 k game on standard 48k
>Speccy with tape recorder or even microdrive ?
>I can image it nowadays, using emulators and cross-compilers, but how
>it was done ten years ago ?
Can't speak for the pros, but...
Firstly, emulators and cross-compilers aren't new inventions. However,
given the high proportion of bedroom programmers around at the time, I'm sure
many games were actually written entirely on Spectrums.
Bear in mind that the actual code for a game often wouldn't be that big - the
bulk of a 40K game would be game data (graphics, screen layouts etc.) You
could do most of the writing and debugging with only small parts of the data
in place.
Finally, it was possible to extend the Spectrum beyond 48K - mine was 80K.
______________________________________________________paul....@liffe.com
<Emergency backup .sig.>
I have a copy of crash with a Design Design interview. They used a Spectrum
hybrid monster that they had hacked together themselves (being electronics
students). I don't remember the exact specs, but I seem to remember it having a
hard disk, clocked processor and bucket loads of memory (probably about 256k or
something :))
Zargwog...
>I was always curious about how the programmer's workshop looked like.
>How it was possible to write and debug say 40 k game on standard 48k
>Speccy with tape recorder or even microdrive ?
>I can image it nowadays, using emulators and cross-compilers, but how
>it was done ten years ago ?
Hi there Wotjek,
I still have a half written platform game sitting on a Microdrive
cartridge right now. I wrote it in many segments, with different
routines for designing, compressing and displaying a screen.
I have one main program "trunk" or loop that runs during the actual
game-play. This takes care of movement and collision detection; it
also makes calls to other routines for sounds and scoring. The main
loop is not very big and can easily be run in conjunction with an
assembler and the one screen that is used for testing the game-play.
This was pre-Jet Set Willy and I remember I was very proud to have
designed a compression system that would allow over a hundred screens
to be used in the game. Hey, Manic Miner only had - was it 20?
Then I moved out from home and never again had the time to sit around
and waste endless hours in front of the Spectrum, besides, JSW came
out and made my thing look a bit silly:-(
I remember always reading how the bigger companies used "real"
computers to write Spectrum code and seeing as you probably have a
Spectrum emulator on your PC right now, it can't have been that
difficult to do it back then.
Tell you what though; I think PC's have never lived up to their
promise of bigger and faster games and graphics. I remember playing
Elite in a few hundred Kb on an XT and thinking, well this is no
improvement on the Spectrum. And now? If games were as well written as
they were on 8-bit computers, Doom would probably run on a 286. I
could be well off the mark here, but every time I see another 600k
Solitaire, I cringe. Remember Speccy Scrabble? - wasn't that 32Kb? -
it was less than 40Kb anyway. Now I have 8000Kb and silly old Wordpad
takes longer to load from the hard disk than Tasword3 did from
Microdrive and only looks prettier - that's all :-(
Had a look at my Microdrive today - only a couple of millimeters of
dust; and that Sega Master Keyboard, what a mess;-o
My old amber monitor is all rusty too - I remember when my Brother
HR-5 thermal printer leaked its batteries all over it.
But what do you do with a few hundred ten minute tapes now that it all
fits in a little folder on the PC?
Oh well... must do some work.
Everybody have a rant :-)
L8r
--
Cya, Robert Axford
ro...@actrix.gen.nz
PDS - nasty system, stopped far too many programmers learning how to
debug as the debugger was next to useless - it could single step but not
breakpoint so to step through a bit of code in situ you would have to
single step though the entire game until you got there. In addition it
worked with a fixed number of source files (up to 16) and each source
file could only be 32k (crazy on a PC) - this meant that adding a bit of
source to the start of a file could mean having to remove some other
source and find a new home for it. Saying all that it was the only buy
off the shelf system available - At the time I used Microsofts Macro80
assembler and linker (running on a CPM machine) then uploaded it to the
target machine via a serial link and a home grown monitor/debugger that
could use the symbol table generated by the linker.
When I first wrote the GLAM development system and gave RARE some copies
there were people there that would still stare at a print out rather than
use all the sophisticated source level debugging and conditional breaks
(you could even write your own watch commands). RARE are still using GLAM
for programming all their SNES stuff.
Jon
> PDS - nasty system, stopped far too many programmers learning how to
> debug as the debugger was next to useless - it could single step but not
> breakpoint so to step through a bit of code in situ you would have to
> single step though the entire game until you got there. In addition it
> worked with a fixed number of source files (up to 16) and each source
> file could only be 32k (crazy on a PC) - this meant that adding a bit of
> source to the start of a file could mean having to remove some other
> source and find a new home for it. Saying all that it was the only buy
By todays standards I would say that it sucked :-)
> off the shelf system available - At the time I used Microsofts Macro80
> assembler and linker (running on a CPM machine) then uploaded it to the
> target machine via a serial link and a home grown monitor/debugger that
> could use the symbol table generated by the linker.
That sounded better! I read comp.os.cpm from time to time, and the people
in there seem to still think that M80 is the best piece of Micro$oft
software ever - and I guess I might agree :-) You know, Amstrad too used
this approach, at least the assembly programming examples in the +3
manual was written with M80.
> When I first wrote the GLAM development system and gave RARE some copies
> there were people there that would still stare at a print out rather than
> use all the sophisticated source level debugging and conditional breaks
> (you could even write your own watch commands). RARE are still using GLAM
> for programming all their SNES stuff.
Cool! What kind of CPU is used in the SNES?
---- Torvald B. Bringsvor ------------------- Student at College of
- Owner of Spectrum 16k & 128k+3, QL, XT, P90 - Aalesund, Norway.
----------------------------------------------- -> email: tb...@stud.hials.no
True or False? I can't honestly remember?
Seamus.
> Tell you what though; I think PC's have never lived up to their
> promise of bigger and faster games and graphics. I remember playing
> Elite in a few hundred Kb on an XT and thinking, well this is no
> improvement on the Spectrum. And now? If games were as well written as
> they were on 8-bit computers, Doom would probably run on a 286. I
> could be well off the mark here, but every time I see another 600k
> Solitaire, I cringe. Remember Speccy Scrabble? - wasn't that 32Kb? -
> it was less than 40Kb anyway. Now I have 8000Kb and silly old Wordpad
> takes longer to load from the hard disk than Tasword3 did from
> Microdrive and only looks prettier - that's all :-(
>
I always suspected a lot of those early pc games to be merely spectrum
games with some emulation wrapped about it, Elite, the Great Escape and
some others were almost identical. At the time I guessed the companies
had picked the spectrum versions because the pc and spectrum sound
capabilities were exactly the same.
Does anyone know whether this is actually true?
+---------------------------------------------------------------------------+
| Digital Databank BBS: +44-1707-323531 (300-28.8k/V42/42b) 24 hours |
| FidoNet: 2:257/501.0 Sysop: jsto...@digibank.demon.co.uk |
| (Acorn Information at your Fingertips) |
+---------------------------------------------------------------------------+
: True or False? I can't honestly remember?
True. I think it was Ocean.
G.
: > off the shelf system available - At the time I used Microsofts Macro80
: > assembler and linker (running on a CPM machine) then uploaded it to the
: > target machine via a serial link and a home grown monitor/debugger that
: > could use the symbol table generated by the linker.
: That sounded better! I read comp.os.cpm from time to time, and the people
: in there seem to still think that M80 is the best piece of Micro$oft
: software ever - and I guess I might agree :-) You know, Amstrad too used
: this approach, at least the assembly programming examples in the +3
: manual was written with M80.
That's what I use to write my +3 programs (and that's why they look like
CP/M ports :-) ). I keep libraries of common functions as object modules,
and use DR's linker to create the final program. I do it on a PCW8512 so
getting the files to the +3 is just a matter of disk swapping.
It's a pity Microsoft are being so nasty about M80 (they won't sell it
and won't make it freeware). It's certainly the best Z80 assembler I've used.
---------------------------
John Elliott | \o_ ~'~ _o
CHAOS in a sig... | | ==@ \|/ |\
--------------------------- /| //\\ /|\ A
65c816 - a sort of 16 bit 6502 (with a 8 bit bus)
Jon
Jon Ritman
It's true, and it was PSION.
PSION started using TRS80's with what was called a 'black box' ... basically
some clever electrics that enabled RAM to be shared i.e. we could assemble
and link on the TRS80 to the blackbox RAM, flip a switch and run the game
instantly on the speccy.
As I remember, not all PSION's games were developed on the VAX (a VAX 11/750 to
be precise), I think we switched round about the time of Scrabble on the speccy.
The VAX system Psion used was way, way ahead of it's time and, given some
reservations (It got pretty damn slow when the QL suite was being developed)
it worked *very* well.
STEVE KELLY
-----------
>> From the dim and distant past, I seem to remember somebody telling me
>> about a syustem based on Vax's.
>It's true, and it was PSION.
>The VAX system Psion used was way, way ahead of it's time and, given some
>reservations (It got pretty damn slow when the QL suite was being developed)
>it worked *very* well.
Does the VAX in question still exist ? Or does the source code for the
Xchange program still exist ?
In the QL / QDOS community there would be a certain interest in
gaining access to these. I have personally been involved in improving
Xchange, by simply hacking the binary. Things would be a lot easier if
I had the sources, even just for reference.
Now you're asking ;
The last I heard (and that was about two years ago) the VAX was being used as
a method of making backups (It had a few removable hard-disks) for the PC
network they now use.
At a guess, I would say the PC version of Xchange is probably archived
somewhere but as for the QL??? Even if it exists, my guess is that it would be
in a bit of a state. The first release for the QL was mainly written in C, but
as this ran soooooo slow (partly because of an appauling C compiler),
the entire company was put on hand optimization of the 68k source ('The worst
job I ever had ...' !!!). I'm not to sure if following versions went through
the same treatment.
STEVE KELLY
-----------