spectrum 48k memory map + programming
Fidel Viegas
the Spectrum 48k and I was wondering if anyone does know where I can get
information about the 48k programming model. I have the original 128k
manual, but it covers mostly the 128k.
Anyway, from what I could get from the manual is that the 48k has its
memory mapped as follows:
0000h - 3FFFh ROM
4000h - 5B00h Free RAM (as far as I can tell. No info in the manual)
5B00h - 5C00h Buffer to control the printer
5C00h - 5CB6h System Variables and Routines
5CB6h - FFFFh Free RAM
Now from that mapping we have the (4000h - 5B00h) and the (5C-B6h -
FFFFh) free for us to store our code. The (5B00h - 5C00h) range can be
used as well if we are not working with the printer, right?
Also the stack area usually resides in the area above C000h, right?
Could you guys confirm this or point me to some link that covers
programming the 48k spectrum?
Thanks in advance
Fidel.
Philip Kendall
Fidel Viegas <fidel...@nodomain.com> wrote:
>Hello guys, I just starting cracking my Z80 assembly programming with
>the Spectrum 48k and I was wondering if anyone does know where I can get
>information about the 48k programming model. I have the original 128k
>manual, but it covers mostly the 128k.
As you've discovered, the 128K manual sucks. Get the 48K one from
http://www.madhippy.com/8-bit/index.php?machine=sinclair
>Anyway, from what I could get from the manual is that the 48k has its
>memory mapped as follows:
>
>4000h - 5B00h Free RAM (as far as I can tell. No info in the manual)
That's the screen memory :-) (strictly, 4000h - 5AFFh).
>Also the stack area usually resides in the area above C000h, right?
Not necessarily. It's obviously a bad idea to have the stack above C000h
and then page it out on the 128K machines!
Phil
--
Philip Kendall <pa...@srcf.ucam.org>
http://www.srcf.ucam.org/~pak21/
Geoff Wearmouth
>0000h - 3FFFh ROM
>4000h - 5B00h Free RAM (as far as I can tell. No info in the manual)
>5B00h - 5C00h Buffer to control the printer
>5C00h - 5CB6h System Variables and Routines
>5CB6h - FFFFh Free RAM
>
>Now from that mapping we have the (4000h - 5B00h) and the (5C-B6h -
>FFFFh) free for us to store our code. The (5B00h - 5C00h) range can be
>used as well if we are not working with the printer, right?
with care, write machine code in this area, it is far too easily
overwritten by print output.
Similarly the printer buffer 5B00h - 5BFFh can be used for short
machine-code routines, as it was on the Horizons tape, but this will
be removed by LPRINT and COPY.
The machine stack normally resides below the user-defined graphics
and grows downwards. It is collapsed and rebuilt every time you issue a
GOSUB as that stack grows downwards too.
The recommended place for machine-code is above the stacks and you can
reserve enough room by lowering RAMTOP with a CLEAR statement.
Here it is beyond the reach of the BASIC system and protected from the
NEW command.
The 48K system puts the entire free RAM at the disposal of the BASIC
programmer at the start of each statement. The machine-code programmer
has the entire free RAM available to the machine-stack.
This neat arrangement can be viewed online with Specmap1 available
in the Utilities 'S' section of WOS archive and also from here
http://www.wearmouth.demon.co.uk/jav/sm1.htm
The Orange 48K manual, linked from the World of Spectrum Documentation
section is the place to start.
--
Geoff Wearmouth
The ZX ROM Files http://www.wearmouth.demon.co.uk
Fidel Viegas
Philip Kendall wrote:
> In article <3EC63DF...@nodomain.com>,
> Fidel Viegas <fidel...@nodomain.com> wrote:
>
>>Hello guys, I just starting cracking my Z80 assembly programming with
>>the Spectrum 48k and I was wondering if anyone does know where I can get
>>information about the 48k programming model. I have the original 128k
>>manual, but it covers mostly the 128k.
>
>
> As you've discovered, the 128K manual sucks. Get the 48K one from
> http://www.madhippy.com/8-bit/index.php?machine=sinclair
It sucks a lot. Thanks for the link. I have been looking for that manual
for a very long time. I had found one, but it was in german.
>>Anyway, from what I could get from the manual is that the 48k has its
>>memory mapped as follows:
>>
>>4000h - 5B00h Free RAM (as far as I can tell. No info in the manual)
>
>
> That's the screen memory :-) (strictly, 4000h - 5AFFh).
Ok, now a got it. Sorry, I forgot to put the take 1 from the 5B00h
address. It was a range anyway.
>>Also the stack area usually resides in the area above C000h, right?
>
>
> Not necessarily. It's obviously a bad idea to have the stack above C000h
> and then page it out on the 128K machines!
If we use the CLEAR command it goes below C000h. I'll read the manual
anyway.
Thanks for the pointers.
All the best
Fidel.
Fidel Viegas
Geoff Wearmouth wrote:
> In article <3EC63DF...@nodomain.com>, Fidel Viegas
> <fidel...@nodomain.com> writes
>
>>0000h - 3FFFh ROM
>>4000h - 5B00h Free RAM (as far as I can tell. No info in the manual)
>>5B00h - 5C00h Buffer to control the printer
>>5C00h - 5CB6h System Variables and Routines
>>5CB6h - FFFFh Free RAM
>>
>>Now from that mapping we have the (4000h - 5B00h) and the (5C-B6h -
>>FFFFh) free for us to store our code. The (5B00h - 5C00h) range can be
>>used as well if we are not working with the printer, right?
>
> The 4000h-5AFFh is the display and attribute file and while one can,
> with care, write machine code in this area, it is far too easily
> overwritten by print output.
It's better not to play with it then. Unless I am using poke instead of
the 'print at' command, right?
> Similarly the printer buffer 5B00h - 5BFFh can be used for short
> machine-code routines, as it was on the Horizons tape, but this will
> be removed by LPRINT and COPY.
Cool. But when you are writing a game I don't think you'll be using
those commands, isn't it?
> The machine stack normally resides below the user-defined graphics
> and grows downwards. It is collapsed and rebuilt every time you issue a
> GOSUB as that stack grows downwards too.
Is there a standard address for the user defined graphics, or can we
just place it anywhere we want?
By the way, what is the format for user defined graphics, the resolution
and colour depth?
How do I convert to from a .gif image or pcx for example?
> The recommended place for machine-code is above the stacks and you can
> reserve enough room by lowering RAMTOP with a CLEAR statement.
I'll check that on the manual.
> Here it is beyond the reach of the BASIC system and protected from the
> NEW command.
>
> The 48K system puts the entire free RAM at the disposal of the BASIC
> programmer at the start of each statement. The machine-code programmer
> has the entire free RAM available to the machine-stack.
Which means that I have to set the size of the stack manually, right?
> This neat arrangement can be viewed online with Specmap1 available
> in the Utilities 'S' section of WOS archive and also from here
> http://www.wearmouth.demon.co.uk/jav/sm1.htm
I couldn't get it to work, and it isn't the browser as I have tried to
run it on other browsers. The effect was the same. The screen doesn't
load properly.
Can I get the program to load it on my emulator?
> The Orange 48K manual, linked from the World of Spectrum Documentation
> section is the place to start.
Thanks for the info. I have downloaded loads of stuff from the world of
spectrum and couldn't find the orange 48k manual. What is the link?
Thanks in advance
Fidel.
Philip Kendall
Fidel Viegas <fidel...@nodomain.com> wrote:
>
>By the way, what is the format for user defined graphics, the resolution
>and colour depth?
[ Apologies in advance if I'm making mistaken assumptions here ]
I think people may be talking at slight cross-purposes here: the user
defined graphics referred to here are the 21 (on the 48K machine) 8x8
pixel characters which could be defined by the programmer, and
functioned just as any other character would. The format of these is
incredibly simple, just being 8 consecutive bytes stored in memory.
>How do I convert to from a .gif image or pcx for example?
If you're talking about converting a general image format to that of a
Spectrum screen, it's a distinctly non-trivial problem, due to the
Spectrum's (in)famous colour clash (only two colours could be displayed
in each 8x8 pixel block). If you can reduce your image to that
resolution, it's then trivial, but vaguely tedious due to the
'interesting' way in which the screen memory was arranged:
* Divide the screen into thirds (lines 0-63, 64-127, 128-191)
* Within each third, the line ordering is then 0, 8, 16, 24, 32, 40, 48,
56, 1, 9, 17, 25, 33, 41, 49, 57, 2, 10, ..., 54, 62, 7, 15, 23, 31,
39, 47, 55, 63.
(ie the first line within every eight pixel chunk, then every second
line, then every third line, etc).
* The attributes (the colour information for every 8x8 chunk) then
follows in the obvious order.
That's probably not the clearest explanation of all time. The following
illustrates it pretty well:
10 FOR i = 16384 TO 23295
20 POKE i, 255
30 NEXT i
>Thanks for the info. I have downloaded loads of stuff from the world of
>spectrum and couldn't find the orange 48k manual. What is the link?
The 'orange' manual is the standard 48K manual, which I think (hope!)
you've found from my other post :-)
Hope this helps,
Derek Jolly
@nodomain.com:
>
>
> Geoff Wearmouth wrote:
>> In article <3EC63DF...@nodomain.com>, Fidel Viegas
>> <fidel...@nodomain.com> writes
>>
>> The Orange 48K manual, linked from the World of Spectrum Documentation
>> section is the place to start.
>
> Thanks for the info. I have downloaded loads of stuff from the world of
> spectrum and couldn't find the orange 48k manual. What is the link?
It's under Documentation/The ZX BASIC Manual
Don't be put off by the title, this is the one you need.
That links to here:
http://www.madhippy.com/8-bit/sinclair/zxspecman/index.html
--
Derek Jolly (derek at speccies dot org)
Leaner, cleaner homepage: http://rivet.50megs.com/
comp.sys.sinclair folklore FAQ: http://rivet.50megs.com/cssfolk.html
YASPIC v1.4: http://rivet.50megs.com/speccy.html
Fidel Viegas
Philip Kendall wrote:
> In article <3EC6BDD9...@nodomain.com>,
> Fidel Viegas <fidel...@nodomain.com> wrote:
>
>>By the way, what is the format for user defined graphics, the resolution
>>and colour depth?
>
>
> [ Apologies in advance if I'm making mistaken assumptions here ]
>
> I think people may be talking at slight cross-purposes here: the user
> defined graphics referred to here are the 21 (on the 48K machine) 8x8
> pixel characters which could be defined by the programmer, and
> functioned just as any other character would. The format of these is
> incredibly simple, just being 8 consecutive bytes stored in memory.
I think I misunderstood it. I know what you are talking about.
It is unbelievable how you can forget things. I used to program this
things on my Amstrad CPC 464 and now I don't remember much besides the
basic commands.
> If you're talking about converting a general image format to that of a
> Spectrum screen, it's a distinctly non-trivial problem, due to the
> Spectrum's (in)famous colour clash (only two colours could be displayed
> in each 8x8 pixel block). If you can reduce your image to that
> resolution, it's then trivial, but vaguely tedious due to the
> 'interesting' way in which the screen memory was arranged:
>
> * Divide the screen into thirds (lines 0-63, 64-127, 128-191)
> * Within each third, the line ordering is then 0, 8, 16, 24, 32, 40, 48,
> 56, 1, 9, 17, 25, 33, 41, 49, 57, 2, 10, ..., 54, 62, 7, 15, 23, 31,
> 39, 47, 55, 63.
> (ie the first line within every eight pixel chunk, then every second
> line, then every third line, etc).
> * The attributes (the colour information for every 8x8 chunk) then
> follows in the obvious order.
>
> That's probably not the clearest explanation of all time. The following
> illustrates it pretty well:
>
> 10 FOR i = 16384 TO 23295
> 20 POKE i, 255
> 30 NEXT i
That was pretty clear to me. But the program helped a lot. What a weird
way of displaying the graphics on the screen. I wonder how they came up
with that.
> The 'orange' manual is the standard 48K manual, which I think (hope!)
> you've found from my other post :-)
I got it this time. Thanks a lot.
Fidel.
Fidel Viegas
Derek Jolly wrote:
> Fidel Viegas <fidel...@nodomain.com> wrote in news:3EC6BDD9.3070305
> @nodomain.com:
>
>
>>
>>Geoff Wearmouth wrote:
>>
>>>In article <3EC63DF...@nodomain.com>, Fidel Viegas
>>><fidel...@nodomain.com> writes
>>>
>>>The Orange 48K manual, linked from the World of Spectrum Documentation
>>>section is the place to start.
>>
>>Thanks for the info. I have downloaded loads of stuff from the world of
>>spectrum and couldn't find the orange 48k manual. What is the link?
>
>
> It's under Documentation/The ZX BASIC Manual
> Don't be put off by the title, this is the one you need.
>
> That links to here:
> http://www.madhippy.com/8-bit/sinclair/zxspecman/index.html
Thanks. I managed to find it this time.
All the best
Fidel.
Geoff Wearmouth
<fidel...@nodomain.com> writes
>Geoff Wearmouth wrote:
>> The 48K system puts the entire free RAM at the disposal of the BASIC
>> programmer at the start of each statement. The machine-code programmer
>> has the entire free RAM available to the machine-stack.
>
>Which means that I have to set the size of the stack manually, right?
No. When you reserve space for your machine code using CLEAR <address>
then the machine stack is collapsed into the registers and rebuilt below
your chosen address. It's all taken care of automatically.
My demo has 40K of machine stack space but chooses instead to allow
BASIC to use the area for a GOSUB stack. Its machine stack requirements
are small and you can make out the machine stack below the GOSUB stack.
Most games such as Scrabble make minimal use of the machine stack.
>Can I get the program to load it on my emulator?
Yes. I should have mentioned that it requires Java to be enabled but as
the screen is small, download it from WOS and try it on your emulator or
a real Spectrum.
Cheers,
Cyborg
> the 'print at' command, right?
It's better to simply use the screen memory as screen memory unless
you have a good reason not to.
> Cool. But when you are writing a game I don't think you'll be using
> those commands, isn't it?
If you don't give context you can't expect targeted answers.
> Is there a standard address for the user defined graphics, or can we
> just place it anywhere we want?
It's called 'memory'. Free your mind - you're not in BASIC country
anymore...
> By the way, what is the format for user defined graphics, the resolution
> and colour depth?
Phil answered this well but the question about colour depth does make
me wonder if you've ever USED a spectrum. I think even the most
idiotic users realised that the colours were not per pixel.
> How do I convert to from a .gif image or pcx for example?
I would use BMP2SCR rather than attempt it yourself - he has done it
better.
> I'll check that on the manual.
It doesn't actually matter - you can do what you want. It's
recommended if you actually care about having BASIC in the memory at
the same time.
> Which means that I have to set the size of the stack manually, right?
The stack has no size. It will happily grow downwards in memory quite
happily overwriting anything or not when it gets to the ROM. You have
to ensure that there is adaquate free space.
Alvin
> > That's probably not the clearest explanation of all time. The following
> > illustrates it pretty well:
> >
> > 10 FOR i = 16384 TO 23295
> > 20 POKE i, 255
> > 30 NEXT i
>
> That was pretty clear to me. But the program helped a lot. What a weird
> way of displaying the graphics on the screen. I wonder how they came up
> with that.
It makes character printing very fast.
The display organization isn't so bad once you've stared at the
results of the Basic program above for a little while.
The things to notice are (also pointed out by Phil):
- at the largest scale, the screen is divided into
three "blocks", covering rows 0-7, 8-15 and 16-23
- each "block" consists of 8 character "lines" (the rows)
- each character "line" contains 8 "scan lines" - the 8
vertical pixels of each character square
- each "scan line" is 32 bytes wide covering all 32
horizontal columns.
- each "column" byte in the scan line contains a pixel
mask for 8 horizontal pixels
By noticing what changes the fastest in increasing byte order,
you come up with this construction of a 16-bit display
address:
010BBSSS LLLCCCCC
where
BB = screen "block" 0..2 (which third of display)
SSS = "scan line" 0-7 (vertical pixel within character)
LLL = character "line" 0-7 (vertical row within block)
CCCCC = horizontal "column" byte 0-31
Eg, the screen addresses corresponding to character
positon (row,col)=(10,12) has:
BB = 01 (the second third of display contains row 10)
LLL = 010 (row 10 is the third row in the second third
of the display; the 2nd third contains
rows 8-15)
CCCCC = 01100 (12)
which forms a screen address 01001SSS 01001100.
By selecting SSS for each of the seven vertical bytes
in the character, we get screen addresses:
01001000 01001100 = 18508
01001001 01001100 = 18764
01001010 01001100 = 19020
01001011 01001100 = 19276
01001100 01001100 = 19532
01001101 01001100 = 19788
01001110 01001100 = 20044
01001111 01001100 = 20300
To print a letter 'A' at (10,12), poke the graphic
bytes into these addresses:
POKE 18508,BIN 00000000
POKE 18764,BIN 00111100
POKE 19020,BIN 01000010
POKE 19276,BIN 01000010
POKE 19532,BIN 01111110
POKE 19788,BIN 01000010
POKE 20044,BIN 01000010
POKE 20300,BIN 00000000
A similar thought process generates the format
of an X and Y pixel coordinate:
X: CCCCCTTT
Y: BBLLLSSS
where TTT = bit position within screen byte.
Eg: Pixel coordinate (x,y)=(134,77) in binary
is (1000 0110, 0100 1101) with CCCCC=10000,
TTT=110, BB=01, LLL=001, SSS=101.
Form a screen address from these parameters:
010BBSSS LLLCCCCC = 01001101 00110000 = 19760
Since TTT=110=6, we need to fill in bit 6
of the byte at 19760 to plot the pixel. NOTE:
bit 6 is counted from the left side of the
byte! POKE 19760,BIN 00000010
All this assumes the origin of the display is
at the top left of the screen, which is not
how Spectrum Basic defines things.
With this info, if you store a screen position
as a screen address + (maybe) a bit within the
screen byte for pixel accuracy, you can write
quick and efficient subroutines to modify the
address to move up, down, left or right by pixel
or character amounts.
Back to the original claim: why is character
printing fast? Each scan line is separated
by 256 bytes. If you hold the screen address
of the top of a char in HL, then moving to the
next scan line of the char is a simple matter
of 'inc h'. To move left or right one char,
all that needs to be done is 'dec l' or 'inc l'.
You can't get any faster than that!
I've used the above to write assembly subroutines
that compute screen addresses. If you're interested,
stop by http://justme895.tripod.com/main.htm
and download the latest Sprite Pack. In the
"screenaddress" subdirectory of the zip file
you get, you'll find several handy screen
address subroutines. The code is written for
several display resolutions, not just the Spectrum's,
so you'll need to ignore the stuff inside conditional
compilation statements.
Alvin
Ian Bland
news:3EC74209...@nodomain.com...
<snip>
> That was pretty clear to me. But the program helped a lot. What a weird
> way of displaying the graphics on the screen. I wonder how they came up
> with that.
>
>
It puzzled me for a long time until I realised that it makes it easier and
faster to display print output on the screen, i.e. any 8X8 character placed
on the official 24X32 grid. Suppose you have hl pointing to the address of
the first (top) byte of the character. You only have to inc h to get to the
next one down. I presume that was the reason.
Made it a pain in the neck to display anything else tho :(
Ian
Fidel Viegas
Cyborg wrote:
> It's called 'memory'. Free your mind - you're not in BASIC country
> anymore...
I can't free my mind cause it is pretty full right now.
>>By the way, what is the format for user defined graphics, the resolution
>>and colour depth?
>
>
> Phil answered this well but the question about colour depth does make
> me wonder if you've ever USED a spectrum. I think even the most
> idiotic users realised that the colours were not per pixel.
I don't think you followed the discussion very well, but no I have not
used the Spectrum. I used the Amstrad CPC 464 instead. It is the same
principle as far as I can remember. And I guess I am below those idiots.
It has been quite a while since I programmed the ancient Amstrad. But,
anyway, we can always go back to that.
>>How do I convert to from a .gif image or pcx for example?
> I would use BMP2SCR rather than attempt it yourself - he has done it
> better.
I have seen that program, but it runs on windows/dos only. I am running
a Mac.
> The stack has no size. It will happily grow downwards in memory quite
> happily overwriting anything or not when it gets to the ROM. You have
> to ensure that there is adaquate free space.
I found all that on the manual.
Thanks for the info anyway.
All the best
Fidel.
Fidel Viegas
Thanks for the link and all the info.
All the best
Fidel
Jaime Tejedor Gómez, aka Metalbrain
>
>
>> I would use BMP2SCR rather than attempt it yourself - he has done it
>> better.
>
>
>I have seen that program, but it runs on windows/dos only. I am running
>a Mac.
Only Windows, not DOS. For Mac, you must use Mac2Spec:
ftp://ftp.worldofspectrum.org/pub/sinclair/tools/mac/osx/Mac2Spec.sit
or you may try compiling the source of ZXSee (a viewer program that
can also make conversions). Look at the end of the page, and download
the "Código Fuente":
http://www.speccy.org/horace/archivo/utilidades.php
METALBRAIN
(C) 1977 Tejedor & Gómez Research Ltd.
Dunny
> Cyborg wrote:
>> Phil answered this well but the question about colour depth does make
>> me wonder if you've ever USED a spectrum. I think even the most
>> idiotic users realised that the colours were not per pixel.
> I don't think you followed the discussion very well, but no I have not
> used the Spectrum. I used the Amstrad CPC 464 instead. It is the same
> principle as far as I can remember. And I guess I am below those
> idiots. It has been quite a while since I programmed the ancient
> Amstrad. But, anyway, we can always go back to that.
I think that what he means is that if you haven't *used* a spectrum, you're
going to have quite an uphill struggle (read: total failure at first) to program
anything useful for it. The fact that Amstrad produced the later Spectrums and
that the two machines share a CPU means nothing really - the Spectrum is so
unlike the Amstrad you'd be better off starting with the BASIC manual and
working up to z80 from there - there's a *lot* of things you need to know, and
none of it is relevant to the Amstrad. By all means, use what you've learnt of
the z80, but that's really the only Amstrad knowledge that will be any use. The
screen is different, the memory map is different, the ROM is different, the
hardware ports work differently, and I believe even the keyboard is totally
different.
You've got a *very* large job ahead of you :(
D.
Ian Bland
news:ba92ds$q60rl$1...@ID-106816.news.dfncis.de...
Surely the biggest spanner here is that all the programming challenges on
the Spectrum had been met by 15 years ago. My head used to buzz with z80
(crap at it as I was) but what's the point now? Whatever you try and do,
somebody else has already done it. Probably so long ago that they've
forgotten how...
If I wanted to fight the knotty problems of assembler just for the
challenge, I'd go with x86 in DOS. Loads and *loads* of detail to learn
there, and at least then it may possibly come in useful somehow. I still
have a book on it somewhere...
Ian
Fidel Viegas
I guess I misunderstood what he had said then. Apologies Cyborg!
Back in those days I knew the two machines were different, but didn't
know how different. I managed to port the tennis game at the back of the
zx spectrum + 2 manual to the Amstrad 464. I don't quite remember the
process, but I know I looked for the equivalent commands used in the
Amstrad.
There are a couple of other games that came on some magasines. But at
that time I had no clue how to program my own games nor how they really
worked internally. The only thing I knew was converting programs from
one machine to another. I wish I had those stupid tapes again so that I
could see what I really did there.
Anyway, I have been reading the basic manual and up till now it has been
clear to me. I know I will come to that nightmare part soon.
But as you guys are really nice, I guess I am going to scream for help
over here.
All the best and thanks for all the explanation.
Fidel.
Fidel Viegas
Thanks for the links. Finally a Mac user.
Muchas gracias.
All the best
Fidel.
Fidel Viegas
Ian Bland wrote:
> Surely the biggest spanner here is that all the programming challenges on
> the Spectrum had been met by 15 years ago. My head used to buzz with z80
> (crap at it as I was) but what's the point now? Whatever you try and do,
> somebody else has already done it. Probably so long ago that they've
> forgotten how...
>
> If I wanted to fight the knotty problems of assembler just for the
> challenge, I'd go with x86 in DOS. Loads and *loads* of detail to learn
> there, and at least then it may possibly come in useful somehow. I still
> have a book on it somewhere...
>
My first experience with assembly language programming was on an 386sx
and then I started creating my own projects with the z80 CPU, but never
had the chance to program neither the Amstrad CPC 464 nor the Spetrum in
assembly. So I dib;t think that it is too late to experience what you
guys have 15 years ago. It's not that it's going to be that fun or
something. I just want to know how the damn thing really works.
All the best
Fidel.
Duncan Snowden
Bytes: Sunday
> The display organization isn't so bad once you've stared at the
> results of the Basic program above for a little while.
[sniiiiiiiip]
That is the single clearest explanation of the Speccy's screen layout
I've ever read. And I've stared at the results of similar BASIC programs
over a period of nearly 20 years until my head hurts.
Someone bung Alvin's post into the FAQ verbatim.
--
Duncan Snowden.
8 End of file, 260:3
Ian Bland
I didn't mean to be rude, and in retrospect my post seemed that way.
Apologies.
All the best and I'm sure you'll have bags of fun with it :)
Ian
Jaime Tejedor Gómez, aka Metalbrain
>>
>> ftp://ftp.worldofspectrum.org/pub/sinclair/tools/mac/osx/Mac2Spec.sit
>>
>> or you may try compiling the source of ZXSee (a viewer program that
>> can also make conversions). Look at the end of the page, and download
>> the "Código Fuente":
>>
>> http://www.speccy.org/horace/archivo/utilidades.php
>
>Thanks for the links. Finally a Mac user.
Hehe, I'm not a Mac user (I use Win98 and a bit of Linux Mandrake on
PC), it's just that I'm quite aware of available spectrum utilities (specially
emulators, assemblers and graphic utilities).
>Muchas gracias.
De nada.
Cyborg
No need to apologise - it just seemed apparant from your question that
either you didn't get the Spectrum colour scheme after having used it
and hence you'd have to be pretty dim or you'd never used it and hence
would make the inccrrect assumption about it that it works like most
other colour displays by having each pixel colour mapped to a
different number in screen memory.
Simply put the Spectrum screen area is split between a monchrome bit
map and a colour overlay which is more akin to say, the VGA/CGA/EGA
text modes on a PC than anything else.
Alvin
> That is the single clearest explanation of the Speccy's screen layout
> I've ever read. And I've stared at the results of similar BASIC programs
> over a period of nearly 20 years until my head hurts.
A convert! I always have the display address and Y coordinate
bit patterns in front of me when I write graphics subroutines.
It makes things so easy :-)
Sinclair clearly had in mind quick character printing when
it laid out the display file. The side effect is that pixel
addressing is slowed down somewhat, but not as much as one
would think.
Alvin
Fidel Viegas
Ian Bland wrote:
> "Fidel Viegas" <fidel...@nodomain.com> wrote in message
>
> I didn't mean to be rude, and in retrospect my post seemed that way.
> Apologies.
>
> All the best and I'm sure you'll have bags of fun with it :)
I don't think you were rude, and your post didn't seem that either.
But it seemed as if you think that it is a waste of time programming for
the spectrum after all this years.
All the best
Fidel.
Fidel Viegas
Thanks dude. I can see that the Spectrum doesn't have MODE 0, MODE 1 or
MODE 2 like the Amstrad.
Thanks a lot
Fidel.
Derek Jolly
@nodomain.com:
> Thanks dude. I can see that the Spectrum doesn't have MODE 0, MODE 1 or
> MODE 2 like the Amstrad.
Yep. Just the one mode. A high resolution monochrome display of 256x192
pixels corresponding to memory addresses 16384 to 22527 followed by a low
resolution 32x24 colour overlay corresponding to memory addresses 22528 to
23295, so the Spectrum can only have 2 colours in any 8x8 pixel block.
Ian Bland
news:Xns9381B348ADE45de...@195.92.193.157...
It can also FLASH and BRIGHT in each colour block too.
Ian
Woody
Which doesn't change the original statement that there will only be 2
colours in any 8x8 pixel block at any moment in time :-)
Ian Bland
news:qtpkcvk3p67uhf6ic...@4ax.com...
I wasn't implying that it did :oD
Ian
Lee Prince
> Surely the biggest spanner here is that all the programming challenges on
> the Spectrum had been met by 15 years ago.
Erm, surely the biggest spanner here is Lister?
--
Hey, hey, 16K, what does that get you today?
Robert J Baker
> On 19 May 2003, Ian Bland wrote:
>
> > Surely the biggest spanner here is that all the programming challenges on
> > the Spectrum had been met by 15 years ago.
>
> Erm, surely the biggest spanner here is Lister?
Who's the biggest lister? :-)