Artificially added Z80 instructions to control emulation
Gregory L Fox
This is just an idea for any emulator programmers or anyone clever enough
to modify the source to any of the existing ones:
What I reckon we need is some extra opcodes (there are spare ones such as a
combo EDCB or something, can't remember the details but I know it's
possible) artificially added to the 'real world' ones.
ie. we're emulating a Z80A but it has opcodes not present on a real one.
These opcodes would perform operations on the state of the emulator itself,
for example turning on and off
throttling. (VERY useful, like the ZX81 'FAST' mode, but far more powerful -
7000% on a modern celeron or 16000% on a new 1Ghz Athlon perhaps.)
Another option would be a choice of palettes, or more precise
speed-settings, even things like new scrolling functions (in straight
assembly so that they're instant).
The possibilities are there, just need someone very clever to put it into
practice.
I'm SURE it could be added to an emulator like Z80 from the source code, but
I'm just too thick to do it.
There must be a variable in the source which controls the speed of
emulation. One opcode could just set that to 10000% and one set it back to
what it was before.
Sound simple? It probably would be to someone who knew their way around the
code.
Just a thought...
You see the point of it though? Could open up new potential for programmers
to write new games for the speccy which don't have to be so anal about speed
optimisation. (Bit like a modern games writer using a 3D graphics card
instead of optimised assembly.) (Or of course using both! Imagine, you could
translate 'Quake' for the spectrum. I mean, 320x200 isn't that far off
256x191 for graphics!!!!)
Anyway, all the best,
Greg
x
Tomaz Cedilnik
> You see the point of it though? Could open up new potential for programmers
> to write new games for the speccy which don't have to be so anal about speed
> optimisation. (Bit like a modern games writer using a 3D graphics card
> instead of optimised assembly.) (Or of course using both! Imagine, you could
> translate 'Quake' for the spectrum. I mean, 320x200 isn't that far off
Hahaha! Good one. But I'd prefer Doom.
Now How are you going to squeeze one level information in Speccy's
memory? If you can't squeeze them all, you can load each one from the
tape or microdrive when it's time, but you must get at least one into
the memory. Plus all shapes that are used in the level currently about
to play. Just all sound effects would probably take at least 48K. ;-)
> 256x191 for graphics!!!!)
256x192
Tom
Nathan Wain
On Sat, 6 May 2000, Tomaz Cedilnik wrote:
> > 256x191 for graphics!!!!)
>
> 256x192
Oh c'mon! You know we need that bar for the cool little energy bar
thingy! (Anything more would be extravagant... and probably run
us over memory.) :)
Nathan.
--
nat...@caverock.net homepages.caverock.net.nz/~nathan
"I have a degree in architecture, but I've never used it except as a
bookmark or a drink coaster." -- "Weird Al" Yankovic.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Gregory L Fox
monster, all of which can be saved as UDGs on the 128K ramdisk, the
graphic textures would obviously have to go because of the colour
limitations, the levels aren't really that big, and the sounds would also
almost all have to go.
I reckon it could be done. The only problem with the 'Doom' conversion is
that it's designed for a spectrum running at the normal speed. If you used
the awesome power of a mere 200Mhz machine you could optimise your
programming for about 2000% of the original speed, thus enabling higher
complexity.
Yep, I reckon it could be done.
Maybe even Quake2. *Maybe* even Duke Nukem 3D(!).
But back to this 'extra opcodes' thing - anyone out there have the skill to
implement any of it? (The 'throttle/de-throttle' command being the most
important...)
Cheers,
Greg
x
Equin0x
> What I reckon we need is some extra opcodes (there are spare ones such as a
> combo EDCB or something, can't remember the details but I know it's
> possible) artificially added to the 'real world' ones.
The spare ones do things, don't they? They're used in some horrible code
to confuse hackers IIRC.
Eq.
--
http://chasingtornados.com/equin0x
Gregory L Fox
> to confuse hackers IIRC.
>
> Eq.
Yes, that's true. A physical Z80A is just a mechanical object, so the
'undocumented' opcodes just do things which aren't very 'useful' to
programmers. At a 'bit' level there are fixed behaviours, which is why
certain patterns appear for the different registers' sets of commands, eg.
16h is LD D,n and 26h is LD H,n and so on.
But none of that matters very much when emulating it, because it's not a
real Z80A.
So basically we have a few 8-bit codes reserved as prefixes for 16-bit
instructions. The most used are probably CBh and EDh, but also DD and FD.
Now some of the more obscure opcodes are 24-bit, in the form of a 32-bit
instruction with the third byte being the data, for example DDCBXX06, which
is RLC(IX+d) - 'd' is the third byte (XX) and it basically does a 'rotate
left with carry' on the index register pair 'IX'. So the idea of combining
prefixes DD and CB is already established.
Now what if we use a really convoluted instruction, something like
FDEDDDCBXX to control the emulator functions? We would have 256 instructions
to play with. Obviously there would need to be an element of testing for
compatibility, just in case any 'advanced' programmers had used these
far-fetched opcodes in games and the like, plus of course you would have the
option to turn this support on and off, so that it would only be on for new
software which uses it, not for old software which wouldn't benefit from it
anyway.
So the idea is that codes like F3 and FB (Disable Interrupts and Enable
Interrupts) could be turned into throttle commands, ie:
FDEDDDCBF3 Disable Throttling
FDEDDDCBFB Enable Throttling
That way, the code is fairly logical, but does the job. I mean, we're not
talking about REALLY altering a Z80A processor in ways which couldn't
physically be realised, just transferring some of the control of the
software emulating the thing to the actual thing, which is fairly radical.
Any ideas on this subject would be more than welcome.
Equin0x
> [spare opcodes]
> Obviously there would need to be an element of testing for
> compatibility, just in case any 'advanced' programmers had used these
> far-fetched opcodes in games and the like, plus of course you would have the
> option to turn this support on and off ...
Or, since we're emulating, perhaps the support could be toggled by writing
values to the (virtual) ROM. (I know the Spectrum itself tries to do this
sometimes, but presumably there are 'safe' areas common to all the
models.) Okay, it's not very elegant, but this way the program or snapshot
would be able to request the emulation control support.
Do you have a list of proposed features? I'm just thinking that it
would be essential to agree on some kind of standard: the worst that could
happen would be for the writers of different emulators to implement
different control options.
Eq.
--
http://chasingtornados.com/equin0x
Equin0x
> Or, since we're emulating, perhaps the support could be toggled by writing
> values to the (virtual) ROM.
Actually, this would be rather pointless, assuming that the special
opcodes weren't used in any regular (physical Z80) way. Oops :)
Eq.
--
http://chasingtornados.com/equin0x
Gregory L Fox
the new 'virtual' opcodes:
FDEDDDCBF3 Disable Throttling
FDEDDDCBFB Enable Throttling
FDEDDDCBC0 Standard Palette
FDEDDDCBC1 50% Darker
FDEDDDCBC2 25% Darker
FDEDDDCBC3 25% Lighter
FDEDDDCBC4 50% Lighter
FDEDDDCBC5 25% Blue-er
FDEDDDCBC6 25% Red-er
FDEDDDCBC7 25% Green-er
FDEDDDCBC8 All reds
FDEDDDCBC9 All blues
FDEDDDCBCA All greens
FDEDDDCBCC Oranges, pinks and purples
FDEDDDCBCD Browns, greys and greens
FDEDDDCBCE Pastels
FDEDDDCBCF Harsh+vivid
(nb. all of the above would be read from external files, and thus editable
in PSP, Photoshop or whatever.)
FDEDDDCBD0 PUSH Screen to external cache
FDEDDDCBD1 POP Screen from external cache
FDEDDDCBD2 PUSH UDGs to external cache
FDEDDDCBD3 POP UDGs from external cache
FDEDDDCBD4 PUSH 40000-65535 RAM area to cache
FDEDDDCBD5 POP as above
(and any other permutations for the rest of the Ds)
The external cache would be a virtual stack in the emulator, and basically
extending the memory of the spectrum to that of your PC for the new
software.
This would need to be saved when snapshots are saved with the 'new
enhancements' switched on.
FDEDDDCB80 Scroll one pixel left
FDEDDDCB81 as above, right
FDEDDDCB82 down
FDEDDDCB83 up
FDEDDDCB84 Two pixels left
FDEDDDCB85 right
FDEDDDCB86 down
FDEDDDCB87 up
FDEDDDCB88 Four pixels left
FDEDDDCB89 right
FDEDDDCB8A down
FDEDDDCB8B up
FDEDDDCB8C Eight pixels (ie. character square) left
FDEDDDCB8D right
FDEDDDCB8E down
FDEDDDCB8F up
(Hardware graphics acceleration!!)
FDEDDDCB6s Little macros, things like screen-clear
effects, invert screen, flip, mirror, negative image, all that kind of thing
(graphics utilities, more acceleration).
FDEDDDCB00-1F Tape functions: re-wind tape to start,
skip tape entry, back one entry, re-load last entry,
that sort of thing.
Well I hope this is sparking off thoughts with all the programmers reading
this. I know it's not a 'purist' approach to the spectrum, but it does have
a lot of potential for writing new games. I mean, with hardware acceleration
and throttling, it would be possible to write new arcade-style games in
BASIC and they would actually be GOOD!!!
Also, I'm sure a clever hacker could 'improve' a lot of the older games,
especially the ones which didn't take up the whole 48K. Imagine Jetpac with
palette-change effects and the like. I suppose this project would be a bit
like Spec256, only with a slightly different approach.
Any ideas, feel free to email gr...@nospam.fox10050.freeserve.co.uk
(take out the "nospam." first)
ESPECIALLY if anyone can find how to change speed in the source-code for
'Z80' 4.0. (Yes I am a registered user.)
Gregory L Fox
of proposed 'standard' additions.
I think the throttling's the most useful, but the 'hardware' acceleration of
scrolling and the like would be pretty nifty.
That's an excellent idea you had about turning the enhanced mode on and off
from an address in ROM memory. That's a must. Keeps the spectrum 'pure' for
the normal software.
Well thanks for your feedback, keep on posting any new ideas you have about
it, because I really think if someone with the right abilities as a
programmer got hold of it, we could see some exciting new spectrum software.
All the best,
Greg
PS. I'm off down the pub now, hope to read more from you later.
Cheers,
GF
Gregory L Fox
virtual device and use an output channel instead.
You know how the AY chip can be programmed using OUT commands in BASIC, well
that could apply to our new hardware.
Again, a system variable (there are a few unused ones) could determine its
status, plus there should be an option in the emulator to 'hard' turn it
off.
Then basically if this sysvar is set, an output port (not sure which one -
it's 16-bit, so some expert somewhere will know of one which won't clash
with anything) could control the instructions. Again, there would be 256 new
operations to play with.
Equin0x
> Again, a system variable (there are a few unused ones) ...
But most of the 'unused' ones are actually used by some piece or hardware
or other. I think it was 23768 that was documented as unused in the user
manual but actually stored an important +D disc system variable. That
caused many a headache with old software.
Eq.
--
http://chasingtornados.com/equin0x
John Elliott
>Actually, this would be rather pointless, assuming that the special
>opcodes weren't used in any regular (physical Z80) way. Oops :)
You wouldn't necessarily need a massively long opcode. Just take a short
one and pass parameters in the registers. For example, my PCW emulator
(JOYCE.EXE) obeys the following opcodes:
ED FD: What it does depends on where it's called from. The Spectrum
equivalent would be putting ED FD at 04C2h and 0556h (save-bytes
and load-bytes) and when it's executed, do a .TAP save/load.
ED FE: What it does depends on what's in the A register:
A = 0: Test for emulator presence. If A is still 0 after the ED FE,
then the emulator doesn't understand what's going on.
Otherwise it returns a "compatibility level" (currently 0FFh)
in A, and a version number in HL.
A = 1: Emulate the PCW's boot ROM (which is not included in JOYCE).
A = 2: Set the screen colours. BCD = foreground RGB,
EHL = background RGB.
A = 3-7: Emulated hard drive functions (read/write a sector, etc.)
A = 8: Save emulator settings.
A = 9: Set LPT port to use for emulated Centronics printer - number
is in DE. Returns previous port number in HL. Use DE = 0FFFFh
to get current port number.
A = 10: Access the host computer's filesystem. C = subfunction
(open/close/read/write/expand wildcards)
A = 11: Access the host computer's screen. C = subfunction
C = 0: switch to PCW mode
C = 1: switch to 800x600x256 mode
C = 2: Output character in E
C = 3: Output system message character in E
C = 4: Emulate the GSX graphics API
C = 6: Get video capabilities bitmap in HL.
A = 12: Redefine the keyboard.
A = 13: Access to the serial port (read/write character,
set speed, etc.)
A = 14: Expand a disc error message.
A = 15: Emulate the LOGO graphics API.
A = 16: Read an entry from the BOOT.CFG file.
A = 0FCh: Emulate a CP/M disc call using the host filesystem.
A = 0FEh: Set / get timing parameters.
Both of these opcodes do absolutely nothing on a real Z80.
You may notice that a lot of these options are present so that functions
such as screen and printer access can be done by native code, rather than
by the operating system within the emulator.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Gregory L Fox
for the emulated machine.
That's the point. So you say just EDFD and EDFE would do. That's pretty
interesting. Of course all of this would require a fair bit of testing with
software, but it ought to be fairly easy to add these features to existing
emulators which come with source, eg. Z80 registered (as an update just for
registered users perhaps) or X128 perhaps. Could be cool. Either of those
support fast emulation, and that's the real point of this - to add punchy
new power to enable some really complex programming - 3d stuff and the like.
Cheers, comments much appreciated.
Gregory L Fox
seem to remember a lot of different ports could be used to grab joystick
input, not just IN31.
Yeah, scrap that, we'll just use the 16-bit prefix instructions as a useful
way into extending the processor with new 'virtual' commands.
I think the throttling and graphics acceleration have to be pretty central,
but the rest is optional.
As John Elliott says above, we could use shortish opcodes such as FDEDXX and
even tie it to the contents of the A register at the time. Pretty nifty
idea, that one. Maybe just use one or two new opcodes which are GUARANTEED
not to do anything, and then use the A register.
That's great, it's what this newsgroup is all about. I can see a year from
now this little add-in functionality being supported by at least one
emulator, if not several.
The new software made possible would make it worthwhile.
I mean, I was fairly serious about Quake, but even just some totally new
rendered 3d games and the option to write decent scrollers in BASIC, that's
reason enough to go ahead with it.
Any coders out there who know their way around the source for Z80 or X128?
Thanks to everyone so far who has put in highly constructive and innovative
suggestions.
G
Gregory L Fox
Just visited your site - pretty impressive stuff if you don't mind me
saying. Great idea to emulate the PCW.
So you modified Marat Fayzullin's Z80 core to do that. Is there any chance
of posting the source with annotations as to where to insert the new
opcodes, or even better where the speed control is?
Cheers,
Greg
John Elliott
I control speed by adjusting the number of CPU cycles between screen
repaints (see the top of LoopZ80() in Joyce.c). The ED FE opcode is
built-in to Marat's core, and calls PatchZ80() (also in Joyce.c).
The ED FD is implemented in BIOSZ80() and requires you to add a line to
CodesED.h - see the top 2 lines of code.
kio (Günter Woigk)
> Also, to anyone interested, here's my humble attempt at a list of ideas for
> the new 'virtual' opcodes:
>
[list deleted]
> (Hardware graphics acceleration!!)
Hi!
what you are looking for are no new z80 instructions.
what you are looking for is an external add-on for this-or-that
acceleration and e.g. graphics extension.
it would probably be better to define a peripherial device instead of
trapping 'unused' z80 opcodes.
define an external device which includes 2 new graphics modes and a set
of graphics accelerator functions and you're done.
... kio !
--
http://www.kio.myokay.net
http://www.kio.myokay.net/zx_spectrum.html
k...@myokay.net (private)
Geoff Wearmouth
<gre...@hotmail.com> writes
>Again, a system variable (there are a few unused ones) could determine its
>status, plus there should be an option in the emulator to 'hard' turn it
>off.
There are no unused system variables on the 48K Spectrum.
See the true list of System Variables on my Web Page.
http://www.wearmouth.demon.co.uk/sv.htm
--
Geoff Wearmouth.
Spectrum ROM Assembly File: http://www.wearmouth.demon.co.uk
Alvin Albrecht
> Any ideas on this subject would be more than welcome.
First off, Warajevo already has some sort of x86
escape code sequence.
Secondly, what is the point of doing this if it
can't be run on the real Spectrum?
Alvin
Alvin Albrecht
Oops, sorry. Didn't mean to sound so negative.
But I'm not sure why one would add all these
features unless you could add them to a real
Spectrum. If you wanted to program a PC wouldn't
you just program the PC and not an emulator?
Alvin
John Elliott
>Oops, sorry. Didn't mean to sound so negative.
>But I'm not sure why one would add all these
>features unless you could add them to a real
>Spectrum. If you wanted to program a PC wouldn't
>you just program the PC and not an emulator?
When I put them in JOYCE, it was because JOYCE emulates a PCW. And PCWs
run CP/M, which allows:
* Invocation of programs from the command-line. So a lot of what (on a
Spectrum emulator) would be done from menus can be done by command-line
programs.
* Device drivers. PCW CP/M abstracts the concept of a "disk device", so I
can add an emulated hard drive and write a device driver for it that
uses native code. Yes, I could probably emulate a GIDE interface or
similar instead, but that just adds layers of complexity each side of
an I/O port.
+3DOS is well enough written that you could probably get a device
driver into that to do the same thing.
* Interception of system calls. I can load a module that looks at
system calls and decides whether they should be handled by the emulator
or by the emulated OS. The programs themselves don't care.
Spectrum +3s also run CP/M, so those arguments would apply for it as
well. What I'd like to see extra opcodes doing on Spectrums running
the original ROM BASIC is:
* Palette reassignment - games that used it would still work fine on a
real Spectrum, you just wouldn't get the different colours.
* Access the host filesystem. Currently we have tools like TAPCAT/TAPSPLIT
to get native files in/out of TAP files, and we have CPCFS to do the same
to disc images. But when I'm doing JSW128 development, what I'd prefer to
do is something like
LOAD # "c:\rooms.js1" CODE 16384
(since LOAD * is used by microdrives and LOAD ! by the 128k silicon
disc).
Nathan Wain
On Sat, 6 May 2000, Gregory L Fox wrote:
> So the idea is that codes like F3 and FB (Disable Interrupts and Enable
> Interrupts) could be turned into throttle commands, ie:
>
> FDEDDDCBFB Enable Throttling
>
> Any ideas on this subject would be more than welcome.
Since a disabled-throttling emulation would accellerate *all* processes
of the emulation, we're not going to have any way to test just how fast
our un-throttled system is, are we? (Or would the virtual screen
refreshes be kept constant so we can use raster timing?)
If we have no way of telling how fast we're going, we'd either have to:
1) Do an "enter game-speed" prompt at some point (no ideal IMHO)
2) Have a command to set the emulation speed to a _specific_ speed.
3) Have a command to use to measure the unthrottled speed.
Of course, 2 and 3 needn't be mutually exclusive. 2 might be useful if
using up all of your real-PC's CPU time isn't an attractive idea; 3 gives
the emulated machine the greatest possibilities in what it can do.
Gregory L Fox
> Spectrum.
Sorry Geoff, didn't realise that. You're quite right of course. We should
stick to using 'new' opcodes instead of output ports. Just a wrong turn
really.
Gregory L Fox
of view.
It's certainly analagous to extra hardware when it's used for graphics
acceleration.
But the throttling thing is really imitating a hardware speed-up in the
processor.
The best way to implement this has to surely be via opcodes.
Nathan Wain
On Sat, 6 May 2000, Gregory L Fox wrote:
> Also, to anyone interested, here's my humble attempt at a list of ideas for
> the new 'virtual' opcodes:
>
> FDEDDDCBF3 Disable Throttling
> FDEDDDCBFB Enable Throttling
Can we have a command to return the current emulation-speed? Unthrottled
emulation isn't that good if we don't know how fast we're going.
> FDEDDDCBC0 Standard Palette
> FDEDDDCBC1 50% Darker
> FDEDDDCBC2 25% Darker
> FDEDDDCBC3 25% Lighter
> FDEDDDCBC4 50% Lighter
> FDEDDDCBC5 25% Blue-er
> FDEDDDCBC6 25% Red-er
> FDEDDDCBC7 25% Green-er
> FDEDDDCBC8 All reds
> FDEDDDCBC9 All blues
> FDEDDDCBCA All greens
> FDEDDDCBCC Oranges, pinks and purples
> FDEDDDCBCD Browns, greys and greens
> FDEDDDCBCE Pastels
> FDEDDDCBCF Harsh+vivid
>
> (nb. all of the above would be read from external files, and thus editable
> in PSP, Photoshop or whatever.)
If they would be from external files stored locally for that game, then
this is (IMHO) a good idea. But it would be infinitely more-flexible if
a specific palette can be specified - either internally with a specified
memory-address of an array of 16 RGB values (is it possible to use dark-
black?), or externally as a specific palette-file.
Sorry but the above palette suggestion, though very useful, is far too
inflexible and inextensable. (It's already imposing a limit of 15 different
palettes.)
IMHO, everything else sounds really cool though.
Nathan.
Gregory L Fox
Now that is a truly GREAT innovation. The only slight worry there is that it
would involve a modified ROM as well as extra opcodes, but it's still a
great idea.
I mean the graphics implications of being able to page in an unlimited
amount of saved screens from hard drive are endless. Animation, generally
better graphics for games, etc. etc.
I suppose the on/off status of the extra opcodes (we could call them
something reminiscent of MMX, perhaps "ZXX"?) could also patch the ROM at
the same time.
(In the emulator, that is - ie. hit SHIFT+F9(for example) and the ROM gets
patched and the opcodes enabled, hit it again and the ROM gets unpatched and
the opcodes are disabled.)
Wow, that "LOAD/SAVE #" standard just HAS to be included.
Superb. I always loved the LOAD! command in 128 basic - it allows so many
neat tricks from BASIC without having to do everything in assembly.
(For example in my game 'The Satan Crystals' - available at the binaries
newsgroup if anyone wants it. There the UDGs are saved and loaded for each
monster from the silicon disk. Saves a lot of hassle and meant I could do
the whole thing in BASIC.)
This LOAD# command would mean even greater freedom - imagine: 100MB spectrum
games!!!
John Elliott
>Since a disabled-throttling emulation would accellerate *all* processes
>of the emulation, we're not going to have any way to test just how fast
>our un-throttled system is, are we? (Or would the virtual screen
>refreshes be kept constant so we can use raster timing?)
JOYCE (or rather its timing program TIMINGS.COM) uses clock seconds here.
It sits in a tight loop for a "minute" (measured using interrupts, which
vary with emulation speed). It then compares the length of that "minute" to
the length of a minute as measured by the host operating system.
Gregory L Fox
the point", but for these purposes it's a case of realising the potential
the spectrum would have had if it packed a little more punch processor-wise,
without fundamentally changing the spectrum.
The graphics extensions are really incidental - they only do things the
spectrum could do normally, just at a 'hardware' (ie. instantaneous) level -
exactly like DirectX-compatible graphics cards. They're not like Voodoo
cards in the sense of looking different to 'normal' video cards, they just
do it with the hardware.
That's how these "ZXX" (or whatever) extensions would behave. A little bit
of oomph for the BASIC programmer wanting to use simple things like
side-scrolling.
Have you ever seen BASIC games which try to do this?
Even with a machine-code scroller (such as David Webb's routines) it's still
pretty slow because all the variables and stuff are handled by BASIC and the
processing time needed for the machine-code routines adds up to crapness.
If that was removed, the BASIC stuff alone would add up to about the level
of performance you get from pure machine-code games.
(That's the theory anyway.)
So really the only point is to write true spectrum games, but take advantage
of the good points of modern PCs.
Without going the whole hog and using VGA graphics and the like.
Gregory L Fox
> If we have no way of telling how fast we're going, we'd either have to:
> 1) Do an "enter game-speed" prompt at some point (no ideal IMHO)
> 2) Have a command to set the emulation speed to a _specific_ speed.
> 3) Have a command to use to measure the unthrottled speed.
>
> Of course, 2 and 3 needn't be mutually exclusive. 2 might be useful if
> using up all of your real-PC's CPU time isn't an attractive idea; 3 gives
> the emulated machine the greatest possibilities in what it can do.
>
That's a fair point. Thing is the technology already exists.
All you need to do is try a speed like 9999% in Gerton Lunter's 'Z80' - it
takes it back to the maximum your PC can handle - typically between 1000 and
8000 percent.
My Celeron gets about 7500%, and of course this is pointless for most games.
I play "War in Middle Earth" and have to keep boosting it to maximum for the
battle scenes and then switching back afterwards.
With the new extensions it would be possible to write a similar game but
have the emulator automatically go into turbo mode for the 'boring bits' or
anything which needs time to calculate.
Like all those games which generate random maps and stuff like that. Or
anything with artificial intelligence routines - chess, that kind of thing -
chess would perform much better if the spectrum player could go into turbo
mode of about 5000% to think and then return to normal for the interfacing
parts.
I do take your point though, that it might be an issue. After all the new
software might be written on one machine which gives only around 1000% (like
maybe a P75 or something) and the message displayed like "please wait" would
disappear too soon on a new Athlon 1Ghz running around 12000%.
I think overall it wouldn't matter that much. In fact, if there were
display-related issues you could suspend the display altogether like on the
ZX81. I really don't think there would be a refresh issue, because all of
the emulation would be unthrottled, but you never know. As the point is to
speed up things which take too long on a normal spectrum, it might not be
too important to keep the display updated regularly anyway.
(Except for the Quake conversion perhaps.)
Nah, actually thinking about it there wouldn't be an issue with the display.
There isn't under Z80 or X128 when you boost them to the top - it would just
be a matter of telling the emulator to try for 50000% and then seeing what
it managed to whittle it down to.
Gregory L Fox
established in an eminent Z80 core like Marat's. That's surely a brilliant
help for turning this idea into a reality.
I suppose the next really important step is getting permission from either
Gerton Lunter or James MacKay to produce an unofficial build of their
emulators, or maybe even write a whole new emulator.(Nah.)
Thanks for the tips on speed. They should be central to the final result.
Gregory L Fox
It was a valid concern though. It wouldn't do to have things go badly wrong
and just crash the program.
Good news though. Sounds as though this little concept might end up working
in the field as it were.
Gregory L Fox
and that throttling returns you to whatever speed you were at before you
dethrottled.
Palette-changing is in, possibly with a long data-based instruction or
possibly with seperate opcodes for each colour used by the system. (Could be
better as the light and dim 'dark blue's are virtually the same and you
could just use the redundant 'light dark blue' as all your custom colours
without worrying about the rest.
External loading and saving is in, possibly also using a ROM patch to enable
BASIC commands like
LOAD#"c:\mydir\myfile.ext" CODE USR"A"
And the groundwork is done already by the great Marat, so the coding
wouldn't be too hard.
So hey, can anybody make an alpha of this?
Gregory L Fox
there have been a lot of new emulators since the last update.
I know the Z80 source is available to registered users.
The X128 and VBSpec sources are available freely.
Are there any more? (Especially ZX32 or JPP?)
It must be easier to add instructions to one of these than the rest, it's
just a matter of finding which one!!
My gut instincts say Z80, but it's commercial software, so the finished
product would not be distributable outside the registered user pool, if even
that.
If X128 is the easiest to do, that would be cool.
Those two are the most attractive, as they have the highest speeds of
emulation!
Gregory L Fox
> > FDEDDDCBFB Enable Throttling
>
> Can we have a command to return the current emulation-speed? Unthrottled
> emulation isn't that good if we don't know how fast we're going.
That's right - that's what the 'enable throttling' command would do - return
you to the prior setting. In reality the speed setting would be PUSHed to
some sort of storage variable when throttling's turned off and then POPed
back when it's turned back on. A bit like in the great megadrive emulator
'Genecyst', or in MAME for that matter. (Except that here they both default
to normal speed, whereas with this it would default to whatever you set it
by hand - being based on the model of Z80 and X128, both of which allow
speedier spectrums anyway.)
You're absolutely right. I don't personally tend towards specifying the
whole palette because we're probably talking about 16x3 bytes = 48 bytes at
a time. Still, if the other ideas about external hard drive access and
stacks and stuff are implemented, memory wouldn't be a problem, so yes
you're right.
Certainly a more flexible palette-changing system would be more useful.
Or maybe a seperate opcode for each colour in the palette? That might work
too. Then we'd be talking just the prefix (whether it's FDED or the longer
FDEDDDCB) followed by one more byte for the command and one more for the
data. Not so far away from spectrum-length opcodes as having a 51-byte
(408-bit) opcode.
Equin0x
> Palette-changing is in, possibly with a long data-based instruction or
> possibly with seperate opcodes for each colour used by the system. (Could be
> better as the light and dim 'dark blue's are virtually the same and you
> could just use the redundant 'light dark blue' as all your custom colours
> without worrying about the rest.
The two blacks are identical. The blues look fairly different.
Eq.
--
http://chasingtornados.com/equin0x
Gregory L Fox
> >
> > Now that is a truly GREAT innovation. The only slight worry there is
> > that it would involve a modified ROM as well as extra opcodes, but
> > it's still a great idea.
> > I mean the graphics implications of being able to page in an unlimited
> > amount of saved screens from hard drive are endless.
> > This LOAD# command would mean even greater freedom - imagine: 100MB
> > spectrum games!!!
>
> you'd want to set a standard that could be replicated in other emus for
> different OSes? So LOAD # "c:\ etc... wouldn't really be ideal. Perhaps
> it would be better to limit it to loading from the current directory?
>
Why's that mate? Clearly as an optional usage that would have its benefits -
ie. a filename like "filename.ext" would default to the same directory as
the last loaded snap or the program's own directory, but for full paths,
it's the emulator itself rather than the spectrum which would handle the
processing, so there wouldn't be a major problem.
I see what you mean to a certain extent though, inasmuch as there wouldn't
be many occasions where anyone needed to use more than one directory, so
maybe it would be easier.
Not sure.
Any thoughts, anyone?
Gregory L Fox
That could be pretty useful. It's probably still best to have opcodes for
the full 16 to be changed (individually and in bulk) but that one, colour 0
or whatever, could have priority in the same way as the 'A' register - ie. a
few more convoluted instructions just for that colour.
Tomaz Cedilnik
> > different OSes? So LOAD # "c:\ etc... wouldn't really be ideal. Perhaps
> > it would be better to limit it to loading from the current directory?
...
> the last loaded snap or the program's own directory, but for full paths,
> it's the emulator itself rather than the spectrum which would handle the
> processing, so there wouldn't be a major problem.
>
> I see what you mean to a certain extent though, inasmuch as there wouldn't
> be many occasions where anyone needed to use more than one directory, so
> maybe it would be easier.
> Not sure.
>
> Any thoughts, anyone?
Well, I think it would be a good idea to limit it, not using the full
path, otherwise some nasy new-Z80 program might do some nasty things in
system directories...
We might choose some directories and the the emulator can use trees with
those roots...
By the way, would you also add "CAT" command which would display the
directory's contents? Like:
CAT # "dir\subdir"
would show the contents of given directory... The problem is CAT's
syntax which already uses '#' - instead of
CAT whatever
you can type
CAT #n;whatever
So we should then make sure that we interpret '#' correctly. I guess it
would just matter whether it's a number or a string that follows...
Tom
Gregory L Fox
Perhaps some other symbol than '#' - maybe '&' or '|'.
Actually all this stuff relates to a hacked ROM so that the new
functionality can be interfaced via BASIC.
The real details are what to put in the new Z80 opcodes for hard drive
access. That's the tough one. In reality the ROM side of things can be
re-done afterwards.
It might even be possible to write a patch which explicitly asks the user
which token to use as 'hard drive access' before patching the ROM.
Do you think it's worth scrapping the whole free access thing for virus
reasons and using a virtual hard disk instead, like when you emulate an
Amiga?
(I suppose it's really a matter of using a big TAP file which can optionally
over-write files with the same filename.)
In fact, that's a much more sensible way of doing it.
What do you reckon?
Philip Kendall
> Anyone know the full answer to this? I suppose it's probably in the FAQ, but
> there have been a lot of new emulators since the last update.
Whoa. Someone hasn't been telling me things again...
Phil (who posted the updated FAQ 5 days ago....)
--
/ Philip Kendall <p...@ast.cam.ac.uk> \
| http://www.kendalls.demon.co.uk/pak21/index.html |
\ Spread css-auth: http://www.ast.cam.ac.uk/~pak/decss.html /
John Elliott
>reasons and using a virtual hard disk instead, like when you emulate an
>Amiga?
If it bothers you, only let it access directories designated by the
emulator.
>In fact, that's a much more sensible way of doing it.
>What do you reckon?
No; I want to be able to use native programs and emulated programs on
the same set of files, without jumping through hoops.
Tomaz Cedilnik
> No; I want to be able to use native programs and emulated programs on
> the same set of files, without jumping through hoops.
That can be done if you choose a directory A and the emulator would use
a tree with root A.
So even if there would be some viruses or similar things, you would know
that they are all localized and safe in a "cage" (a pre-set tree).
No need for virtual hard drive though...
Tom
spi...@freenet.co.uk
> Well, I think it would be a good idea to limit it, not using the full
> path, otherwise some nasy new-Z80 program might do some nasty things in
> system directories...
Not to forget the fact that ONLY M$ based OSes have C: as a path.
Most other OSen have a sensible disk naming scheme.
--
______________________________________________________________________________
| spi...@freenet.co.uk | |
| Andrew Halliwell BSc | "The day Microsoft makes something that doesn't |
| in | suck is probably the day they start making |
| Computer science | vacuum cleaners" - Ernst Jan Plugge |
------------------------------------------------------------------------------
|GCv3.12 GCS>$ d-(dpu) s+/- a C++ US++ P L/L+ E-- W+ N++ o+ K PS+ w-- M+/++ |
|PS+++ PE- Y t+ 5++ X+/X++ R+ tv+ b+ DI+ D+ G e++ h/h+ !r!| Space for hire |
------------------------------------------------------------------------------
Leslie Ayling
Gregory L Fox <gre...@hotmail.com> wrote in message
news:8evmie$lqj$1...@newsg4.svr.pol.co.uk...
> Hello everyone,
> This is just an idea for any emulator programmers or anyone clever
enough
> to modify the source to any of the existing ones:
>
> What I reckon we need is some extra opcodes (there are spare ones such as
a
> combo EDCB or something, can't remember the details but I know it's
> possible) artificially added to the 'real world' ones.
> ie. we're emulating a Z80A but it has opcodes not present on a real one.
>
> These opcodes would perform operations on the state of the emulator
itself,
> for example turning on and off
> throttling. (VERY useful, like the ZX81 'FAST' mode, but far more
powerful -
> 7000% on a modern celeron or 16000% on a new 1Ghz Athlon perhaps.)
>
> Another option would be a choice of palettes, or more precise
> speed-settings, even things like new scrolling functions (in straight
> assembly so that they're instant).
>
> The possibilities are there, just need someone very clever to put it into
> practice.
> I'm SURE it could be added to an emulator like Z80 from the source code,
but
> I'm just too thick to do it.
> There must be a variable in the source which controls the speed of
> emulation. One opcode could just set that to 10000% and one set it back to
> what it was before.
> Sound simple? It probably would be to someone who knew their way around
the
> code.
>
> Just a thought...
>
> You see the point of it though? Could open up new potential for
programmers
> to write new games for the speccy which don't have to be so anal about
speed
> optimisation. (Bit like a modern games writer using a 3D graphics card
> instead of optimised assembly.) (Or of course using both! Imagine, you
could
> translate 'Quake' for the spectrum. I mean, 320x200 isn't that far off
> 256x191 for graphics!!!!)
>
>
> Anyway, all the best,
> Greg
> x
>
Hi Greg,
Although this is not exactly a Sinclair related post,
I have previously used the technique you have described in an AMIGA based
TRS-80 Model1 emulator that I wrote some years ago.
I used three unused opcodes for the purpose of writing cassette files out
to AMIGAdos.
The program and source code are on any AMINET site in the misc/emu dir
under the name AmiTRS80.lha if you are interested.
cheers,
Leslie
Gregory L Fox
one simple TAP file, although John has a point about being able to use files
made on a PC such as bitmaps, waves, that sort of thing, and maybe even
write full-scale utilities on the spectrum for use with the PC.
It's not something I'm personally terribly worried about, as I think the
throttling, palette-changing and screen-effects are more important, but
certainly the issue of getting the spectrum to be able to change TAP files
or use the hard drive in a real way is going to be something which needs to
be sorted out before this little idea enters the coding stage.
I'll try and put some of my thoughts on it up at my website. The URL will be
http://www.fox10050.freeserve.co.uk/ZXX.html but it's not ready today.
Hopefully by tonight.
Of course I'm not claiming to have all the answers or the definitive plans,
but it would be one possible way of doing things. Then other people could
improve upon it at their sites and maybe we could start coding pretty soon.
Gregory L Fox
I'll go and read your FAQ update straight away.
Sorry about that.
Gregory L Fox
solved.
I'll go check that out immediately.
All the best,
G
kio (Günter Woigk)
i dislike doing that all with new opcodes because this means that we not
even can imagine to build it up in real hardware.
opcode patches were used to patch system routines ą la tape_in and
tape_out so that they still worked on an emulator. typically they did
not enhance the original thing.
if we handle all wanted improvements by thinking of added hardware and
define what it does and how it is controlled, we could rescue the idea
that there is still a spectrum running. if we define modifications which
are nearly impossible to build like new opcodes, it's more like you are
going to build a complete new purely virtual thing which is incidently
able to run some specci stuff.
yes, i see it a little from the oop point of view. a z80 cpu is an item,
the rom is an item, the ula is an item. change one of these and you have
to re-engineer the whole thing if you want to build it up in real.
though i'm pretty shure that we never build up any enhanced specci in
real (except perhaps modified rom versions; e.g. Andrew Owen's) i would
like the idea, that it still would be possible.
let the specci remain a specci. build some cute new hardware to plug in.
off course you can do it as you like; it's just my opinion.
... kio !
--
http://www.kio.myokay.net
http://www.kio.myokay.net/zx_spectrum.html
k...@myokay.net (private)
Gregory L Fox
isn't a physical object.
It's purely for emulated spectrums, not real ones. There won't be a real Z80
processor running at 70 times whatever the old one ran at (7 Mhz was it?) -
the idea is that as everyone's running spectrums through their PCs, why not
take advantage of some of that power without changing the nature of the
spectrum.
If you're a purist, which is absolutely fair enough, then there's no reason
to use the new virtual opcodes - this modified emulator would run normal
software quite normally.
Gregory L Fox
Thanks for all the brilliant feedback so far.
I've posted my version of the specification, based on the ideas discussed
here, at the following address:
http://www.fox10050.freeserve.co.uk/ZXX.html
This is absolutely not a definitive version, it's just my take on it. If
anyone has an alternative specification please publish on the web. This is
an interesting project. I'm pleased so many people are interested in it, and
I hope one day pretty soon it will become reality.
Then we can start writing brilliant new software.
CSS 2000 could be something completely new and different!!!
All the best,
Greg Fox
Chris Thomson
laugh, No reason why it would not be backwards compatible...
Chris
Tomaz Cedilnik
>
> I don't see any reason why we should not do a 64bit spectrum just for a
> laugh, No reason why it would not be backwards compatible...
Real mode backwards compatible, and protected mode. ;-)
Tom
Equin0x
> I'll try and put some of my thoughts on it up at my website. The URL will be
> http://www.fox10050.freeserve.co.uk/ZXX.html ...
How about a version of the 8-pixel scroll that also scrolls the colours?
Or, alternatively, separate attribute scrolling routines.
Eq.
--
http://chasingtornados.com/equin0x
Equin0x
> I hope one day pretty soon it will become reality.
> Then we can start writing brilliant new software.
> CSS 2000 could be something completely new and different!!!
But the Crap Games Competition would be even harder to win :)
Eq.
--
http://chasingtornados.com/equin0x
Alvin Albrecht
>
> I see where you're coming from, mate, but the whole point of this is that it
> isn't a physical object.
> It's purely for emulated spectrums, not real ones. There won't be a real Z80
> processor running at 70 times whatever the old one ran at (7 Mhz was it?) -
Actually, they do exist :-)
> the idea is that as everyone's running spectrums through their PCs, why not
> take advantage of some of that power without changing the nature of the
> spectrum.
> If you're a purist, which is absolutely fair enough, then there's no reason
> to use the new virtual opcodes - this modified emulator would run normal
> software quite normally.
I like to think things are realizable too and I think
there is a way to do it.
Instead of having a whole list of long opcodes
that have to be trapped which can take up a lot
of space in logic, how about extending the SLT
opcode? The SLT opcode is "NOPD": ED/FB which
is treated by the z80 as a NOP and is used as
a signal to the emulator to do something. The
registers could hold the function id and any
parameters. On a real machine, external logic
would generate an NMI when the ED/FB sequence
is recognized and the z80 would perform the
function based on the function id passed, perhaps
with hardware assist.
Instead of the 40k-64k
block load I'd like to see 8K or 16K boundaries (so 56k-64k
or 48k-64k, etc.) or perhaps you'd like a bankswitcher that
can replace any 8k block and mark it as read only or
read/writeable?
Alvin
Gregory L Fox
Gregory L Fox
<spi...@freenet.co.uk> wrote in message
news:7m04f8...@ridcully.freenet.co.uk...
> Gregory L Fox <gre...@hotmail.com> did eloquently scribble:
> > True.
>
> What's true... Ever heard of quoting relevant material?
> That way people might have a clue what you're responding TO.
Sorry dude. If you're using Outlook Express try grouping messages by
conversation. I was trying to save people money downloading the original
text every time they get the new message, but I take your point that not
everyone does this the same way, so I'll preserve the last message from now
on.
Sorry.
Gregory L Fox
> > processor running at 70 times whatever the old one ran at (7 Mhz was
it?) -
>
> Actually, they do exist :-)
Wow! Pretty cool. What are they used for? I know engineering departments in
colleges still use Z80s, but what are the fast ones used in?
> Instead of having a whole list of long opcodes
> that have to be trapped which can take up a lot
> of space in logic, how about extending the SLT
> opcode? The SLT opcode is "NOPD": ED/FB which
> is treated by the z80 as a NOP and is used as
> a signal to the emulator to do something. The
> registers could hold the function id and any
> parameters. On a real machine, external logic
> would generate an NMI when the ED/FB sequence
> is recognized and the z80 would perform the
> function based on the function id passed, perhaps
> with hardware assist.
That's a little beyond my technical know-how at present, but I'll do some
tests on the spectrum tonight to find out the ins and outs of SLT
instructions.
This idea about the registers being read by the emulator in the situation
when the extensions are called seems to crop up from time to time. What
worries me a little is that it would be the spectrum filling them up with
data, thus slowing everything down, but it's true to say that it would
artificially create many instructions from few.
Please feel free to elaborate further, as this is pretty interesting stuff.
> Instead of the 40k-64k
> block load I'd like to see 8K or 16K boundaries (so 56k-64k
> or 48k-64k, etc.) or perhaps you'd like a bankswitcher that
> can replace any 8k block and mark it as read only or
> read/writeable?
You mean the PC-memory based 'stack' for storing screens, udgs and fonts?
Sure, it would be a great idea to have instructions for storing each 8K
block of the whole spectrum RAM. Definately a winner. Extends the
possibilities greatly.
My first draft of the specification is up at
http://www.fox10050.freeserve.co.uk/ZXX.html but I'm 100% sure there will be
a million updates over the coming few days until everyone agrees on the core
ideas.
Of course if anyone wants to do another version of the specs, all the
better. I'm no genius, and my version will probably be full of flaws and
weaknesses.
Of course when it comes to the coding I doubt if I'll get beyond just the
throttling instructions, so I'll look forward to seeing what everyone else
does with this idea.
spi...@freenet.co.uk
> isn't a physical object.
> processor running at 70 times whatever the old one ran at (7 Mhz was it?) -
We WISH! Try half that.
Duncan Snowden
> Gregory L Fox wrote:
>
>> > different OSes? So LOAD # "c:\ etc... wouldn't really be ideal.
>> > Perhaps it would be better to limit it to loading from the current
>> > directory?
> ....
>> the last loaded snap or the program's own directory, but for full
>> paths, it's the emulator itself rather than the spectrum which would
>> handle the processing, so there wouldn't be a major problem.
>>
>> I see what you mean to a certain extent though, inasmuch as there
>> wouldn't be many occasions where anyone needed to use more than one
>> directory, so maybe it would be easier. Not sure.
>>
>> Any thoughts, anyone?
>
> Well, I think it would be a good idea to limit it, not using the full
> path, otherwise some nasy new-Z80 program might do some nasty things
> in system directories...
I hadn't thought of that, but it's certainly a concern.
> We might choose some directories and the the emulator can use trees
> with those roots...
On reflection, I think that's possibly what Gregory was actually
proposing. What set my alarm bells ringing was that, for example, "C:"
on a DOS/Win PC is usually the main drive, but in AmigaOS, it's the
directory where CLI commands are kept. Could cause confusion, that. But
if these names were only used within the emulation, and assigned to
their real locations by the user, that would make more sense.
--
Duncan Snowden.
M RAMTOP no good, 1220:3
spi...@freenet.co.uk
> <spi...@freenet.co.uk> wrote in message
> news:7m04f8...@ridcully.freenet.co.uk...
>> Gregory L Fox <gre...@hotmail.com> did eloquently scribble:
>> > True.
>>
>> What's true... Ever heard of quoting relevant material?
>> That way people might have a clue what you're responding TO.
> Sorry dude. If you're using Outlook Express try grouping messages by
> conversation.
UUUUURGH! What do you think I am? A masocistic moron?
> I was trying to save people money downloading the original
> text every time they get the new message, but I take your point that not
> everyone does this the same way, so I'll preserve the last message from now
> on.
But remember... Not *all* of it. Just the bits you're responding to.
Standard usenet ettequette, dontchaknow.
--
______________________________________________________________________________
| spi...@freenet.co.uk | "I'm alive!!! I can touch! I can taste! |
| Andrew Halliwell BSc | I can SMELL!!! KRYTEN!!! Unpack Rachel and |
| in | get out the puncture repair kit!" |
| Computer Science | Arnold Judas Rimmer- Red Dwarf |
Jeff Braine
On Sat, 6 May 2000, Gregory L Fox wrote:
> Yeah, good point.Some of them seem to behave like they're really 8-bit - I
> seem to remember a lot of different ports could be used to grab joystick
> input, not just IN31.
This is *great* :)
Basically the sorts of things I was looking at with the 'loki' project
(I opted for a more complicated method, yours is much more elegent - both
suggestions I've seen so far!)
> Any coders out there who know their way around the source for Z80 or X128?
No, but Philip Kendall's "FUSE" is GPL...
> Thanks to everyone so far who has put in highly constructive and innovative
> suggestions.
This is great stuff. Considering I currently have no time to work on
SpecOS/Loki, it's heartening to see that others have started looking
in similar directions as I was - my idea was more of a replacement
PC OS based on Linux, its core being Linux running an emulator similar
to the one you're talking about - it would boot straight into Loki mode
sorta thing.
One thing you might wantt to look at is being able to switch the ULA
address to just being 0 rather than the myriad of addresses it usually
answers to - simulated disk drives, video adaptors, sound cards or
whatever would then be a lot easier to find addresses for! It needs
to be switchable though (to allow keyboard routines to still work, and
I'm sure some software uses addresses other than 0 to talk to the ULA)
It *is* 0 isn't it... I'm very tired at the moment, so if it's 254,
don't flame me <g> Whatever the *documented* address is...
--
Jeff Braine
ICQ: 26626491
RetroSpec remakes team: http://www.retrospec.co.uk/
Loki Project: http://www.uq.net.au/~zzjbrain/SpecOS.html
Jeff Braine
> That's how these "ZXX" (or whatever) extensions would behave. A little bit
> of oomph for the BASIC programmer wanting to use simple things like
> side-scrolling.
And of course, "real" Speccy games could be patched to take advantage
of the new commands - imagine some of the scrolling games using "hardware"
scrolling rather than big chunks of code - or fade-ins and palette
swaps.
You might want to think about some form of (emulator specific of course)
patching format to make this easier - legally, those games which are
allowed to be distributed *usually* include the 'unaltered' status as part
of the permission...
> So really the only point is to write true spectrum games, but take advantage
> of the good points of modern PCs.
> Without going the whole hog and using VGA graphics and the like.
It's a great idea - and if you could get this emulator running
at boot time instead of windows, you'd have a 'superspectrum' on your
desk rather than a PC 8)
Jeff Braine
> I see what you mean to a certain extent though, inasmuch as there wouldn't
> be many occasions where anyone needed to use more than one directory, so
> maybe it would be easier.
> Not sure.
>
> Any thoughts, anyone?
Enforce a standard and a default "root" directory:
"/" = C:/Windows/ProgramFiles/SpeccyEmulator/diskroot
(basically the 'diskroot' directory in the directory
the emulator was run from)
Make a standard - either forward slash or back slash to split up
directory paths - the emulator then handles the calls to the OS, so you
just make any alterations you need (/ vs \ etc etc)
Easy peasy!
Tomaz Cedilnik
> Enforce a standard and a default "root" directory:
>
> "/" = C:/Windows/ProgramFiles/SpeccyEmulator/diskroot
> (basically the 'diskroot' directory in the directory
> the emulator was run from)
Not necessarily. I think a user should be able to choose where he wants
the root (in .ini file, for example) but the Z80 program (of course)
can't change those settings (unless you are stupid enough to set it in
the emulator's directory).
I have set the directory with Speccy programs separate from X128
directory, not in one of subdirectories. Actually I did so because I
have another emulator (R80) and taper...
Maybe I would want:
root = F:\users/tom\speccy
> Make a standard - either forward slash or back slash to split up
> directory paths - the emulator then handles the calls to the OS, so you
> just make any alterations you need (/ vs \ etc etc)
It's a good idea to allow both, even to mix them as in the example
above. The emulator then translates them all into the one that is
apropriate for the OS where it's running, as you said...
Tom
Tomaz Cedilnik
>
> On Sun, 7 May 2000, Gregory L Fox wrote:
>
> > of oomph for the BASIC programmer wanting to use simple things like
> > side-scrolling.
>
> And of course, "real" Speccy games could be patched to take advantage
> of the new commands - imagine some of the scrolling games using "hardware"
> scrolling rather than big chunks of code - or fade-ins and palette
> swaps.
What about panning / split screen? 2D and 3D acceleration? Mouse
pointer? :-)
Panning and split screen would be like this: you can cut the screen into
some areas (maybe we shouldn't even demand that they are rectangular)
and on each of them would be like a window to Speccy's screen image.
Like you could cut like this:
+------+-----+
| | |
| | |
| | |
| | |
+------+-----+
The left part is from 0 to 98, the right part is from 99 to 255. The
left part has 0,0 in it's upper left corner, the right part has 1,3 in
it's upper left corner (in that case you run out of picture on the
bottom, so you put the top again. The right side would then look funny
because the attributes would match with the picture and wouldn't be
aligned same as on the left side therefore. The separating line would be
then even funnier because you would then see attributes cut to 3 pixel
column on the left and 7 pixel on the right, and the right ones would be
5 pixels lower. Like this: :-)
88 96 99 105
---+---------------+-----+-------------+---------------+--- top
| | | | |
| | | | |
| | | | |
| | | | |
| | +-------------+---------------+---
| | | | |
| | | | |
---+---------------+-----+ | |
| | | | |
| | | | |
| | | | |
| | | | |
| | +-------------+---------------+---
| | | | |
| | | | |
---+---------------+-----+ | |
| | | | |
| 8 pixels wide | 3 | 7 | 8 |
Another fun thing would be to have (instead of window to screen image)
image from somewhere else in the memory (without actually copying it
into the screen image memory). Also it would be fun not just to split
screen but also to put an image (either a window to screen image or an
image from somewhere else) anywhere over the screen (again, without
poking the screen image and even without changing the separation
setting, like it would all be behind the image we just put). Each such
area would of course have it's own attribute alignment...
Moving these things would only be a simple operation - just change the
position setting.
About mouse pointer (or any other pointer) - it would be usually a
little image which would be somewhere in memory where each pixel would
have it's own colour and it would (again) be on screen "on top" of
everything (so placing a pointer somewhere wouldn't affect anything of
speccy's screen image memory or splitting screen).
Miner Willy or whoever could then be defined as an image which we could
place it when he would move and we would also keep setting which out of
4 images is used instead of drawing him every time. That would also
eliminate the problems with attributes. Which reminds me, instead of
wanting to have 4 other (mirror) images of Willy, we could have a
setting to place a pointer or an attributed image (see above) mirrored
horizontally / vertically. Or rotate it. And transparent parts would be
nice sometimes, too (otherwise the shape definition might be complicated
sometimes).
Hmm... do I want too much? If not, I'll start suggesting different
screen size (the way I defined splitting screen and panning, it wouldn't
matter anymore how big the actuall screen that we are cutting is) and
that some areas are shown resized up or down (attrobutes would have to
scale properly, too, even if the resizing factor is not "nice"),
different (not 8x8) attribute size of non-scaled image that would be
from somewhere in the memory, not a Speccy screen image window. Plus,
rotations by angles other than 0/90/180/270 degrees (and slanted
attributes then :-)
What else would we want from Speccys?
How does memory paging work in Speccy 128? How much addressable space
does it actually have? The emulated Speccy could have as much as you
could address. Does Speccy 48K support paging and therefore addressing
more memory?
Tom
Derek Jolly
<Pine.OSF.4.05.100050...@cpca4.uea.ac.uk>, wrote
>On Sun, 7 May 2000, Gregory L Fox wrote:
>
>> I hope one day pretty soon it will become reality.
>> Then we can start writing brilliant new software.
>> CSS 2000 could be something completely new and different!!!
>
>But the Crap Games Competition would be even harder to win :)
Speaking of which, I'd better get writing some stuff for this year's
compo. I've only got one so far.
--
* Derek Jolly (jol...@xsagetetra.com) (Remove the 'x' for e-mail) *
* UGVP FAQ: http://www.beatbawx.f9.co.uk/stuff/ugvp/ *
* *** My homepage has moved! Please update any links you may have. *
* It's now at: http://www.redrival.com/rivet *
Equin0x
> [7MHz Z80]
> Wow! Pretty cool. What are they used for? I know engineering departments in
> colleges still use Z80s, but what are the fast ones used in?
Washing machines? :D
(Yes, I'm a Spectrum fan too...)
Eq.
--
http://chasingtornados.com/equin0x
Equin0x
> And of course, "real" Speccy games could be patched to take advantage
> of the new commands - imagine some of the scrolling games using "hardware"
> scrolling rather than big chunks of code - or fade-ins and palette
> swaps.
We could have a Speccy port of Fantastic Dizzy!!!
*buried under a sudden hail of bricks*
Eq.
--
http://chasingtornados.com/equin0x
Nathan Cross
>
> John Elliott wrote:
>
> > No; I want to be able to use native programs and emulated programs on
> > the same set of files, without jumping through hoops.
>
> That can be done if you choose a directory A and the emulator would use
> a tree with root A.
>
> So even if there would be some viruses or similar things, you would know
> that they are all localized and safe in a "cage" (a pre-set tree).
>
> No need for virtual hard drive though...
How about giving the emulator an .ini file with settings like these...
<example ini>
#File system settings
Fulldiskaccess=0; # Set to 1 for full access to hard drive
Rootdir="c:\dir\subdir" # 'Root' for emu if above is zero
Protdir="c:\windows;c:\mystuff;c:\dos" # Directories inaccessible to
the emulator
</example ini>
That'd fix everybody's problems, wouldn't it? Default to something like
the above for safety, but let mad people who don't care about the
possible Speccy-based virus risk (like John and myself) to set full disk
access to on.
Nathan
--
YS3 - It's not that bad, really.
http://www.ys3.co.uk/
Nathan Wain
On Sun, 7 May 2000, Gregory L Fox wrote:
> > Can we have a command to return the current emulation-speed?
> > Unthrottled emulation isn't that good if we don't know how fast
>
> That's right - that's what the 'enable throttling' command would do - return
> you to the prior setting. In reality the speed setting would be PUSHed to
> some sort of storage variable when throttling's turned off and then POPed
> back when it's turned back on.
Okay, I understand what you mean with the situations for which over-speed
emulation is good with a simple {unthrottle, do-complex-stuff, throttle}
routine. If the time taken to do 'complex-stuff' is virtually instant,
or isn't important anyway, this is a good solution. (I hadn't really been
thinking of that at all.) :)
...But what if one of us were to try, say, a quake-engine? The time
taken to render a frame on an emulated spectrum surely wouldn't be instant.
Ideally I think we'd want to:
- Render the frame unthrottled
- Splat it to screen. (Splat being the technical term.) :)
- Find out how much real-world time the above two steps have taken
- Advanced the game-time based on real-world time given
- Loop
Since frames are going to take a significant time to calculate and render,
and that time will vary from frame to frame (depending on the complexity
of the view) ...we really need to be able to find out just how much 'real
world' time has passed.
I was thinking either:
1) Return, in one of the registers, the current emulation speed. (460%
or whatever...)
2) Return, again in one of the registers, the time since the last time
reading.
Option 1) could actually be really great to do simple patches to already
existing games like "Tau Ceti" or "Fatworm Blows a Sparky." To patch it,
all you really want to know is how much faster you've rendered the frame
than the original game would have done it, and adjust the internal timing
accordingly. ...Real-world time doesn't matter so much - just how much
faster we've gone than the game time already programmed by the game author.
Now option 2) would be the real cool one though. It's just a simple
timer - the action of reading it also clears it, so only one command is
needed. So you can:
- read timer (just to clear it - ignore the value)
- render scene
- read timer (to find out how long it took)
- adjust time accordingly, and loop to the "render scene" step.
...Maybe it would be better to have a timer that could be checked without
it automatically being cleared. :/ Considering the huge speeds that real
machine CPU could be going at in the future, it might be able to do a
whole lotta work before the timer increments significantly, eh? :) (Maybe
a silly thought, but now's the best time to future-proof these ideas.)
...Basically I'm thinking along the lines of just how cool this emlation
could be if it's permanently un-throttled. 100Hz screen-refresh rates
anyone? (With character animation that makes full use of it?) <grin>
> > [Palette] a good idea. But it would be infinitely more-flexible if
> > a specific palette can be specified - either internally with a specified
> > memory-address of an array of 16 RGB values (is it possible to use dark-
> > black?), or externally as a specific palette-file.
>
> You're absolutely right. I don't personally tend towards specifying the
> whole palette because we're probably talking about 16x3 bytes = 48 bytes
> at a time. Still, if the other ideas about external hard drive access and
> stacks and stuff are implemented, memory wouldn't be a problem, so yes
> you're right.
Okay, specifying individual palette RGB values is probably all we really
need. With 500% CPU speed, mucking around with palette entries one at a
time isn't reall that bad, eh? :) I don't envisage doom-like full palette
changes taking all that long.
Okay, I'll stop now. ...I've said a lot in a rather too rambling fashion.
:) And I've sounded far too on-topic. I know you guys hate that. :)
Nathan.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Andrew Owen
Well I've read throuhg the whole thread now so here are my observations.
> Adding new Z80 op-codes.
This is not necessary, and kills any compatibility with the original
machine. If you want to expand the Spectrum it's better to do it using
harware, which you can then emulate. I'll explain as I go along.
> turning on and off throttling.
If you use a Z80B (like the Scorpion) you can wire it up so an OUT will
signal it to go into 7.08Mhz mode while it will default to 3.54Mhz and can
be switched back and forth with the same OUT.
> 7000% on a modern celeron
What do you want to do on it, real-time 3D rendering? If the aim is to add a
bit more punch to the original machine then 7.08Mhz should be fine.
> Another option would be a choice of palettes
I came up with a way of doing this ages ago that keeps 100% compatibilty
with original software. Basically, if you change the way the screen is made
up all the old games will fail, but if you only change the way it is
displayed there should be no problem. It involves building a replacement for
the ULA that defaults to the standard 16 colour (bright and normal) palette
but can be redefined via OUTs.
> more precise speed-settings
I always thought it would be nice to have a proper on-board clock.
> new scrolling functions (in straight assembly so that they're instant).
If you're trying to come up with a system that people will use to create
great new Spectrum games then forget it. I tried with the VSGC project (a
complete replacement ROM for the original Spectrum hardware with built in
scrolling, sprites etc.) It never got off the ground because only one person
ever got in touch with me to help create it. Frankly, if you want a simple
but flexible environment to write games in you're far better off developing
for GameBoy Color.
> You see the point of it though? Could open up new potential for programmers
> to write new games for the speccy which don't have to be so anal about speed
> optimisation.
See above. I haven't given up on Sonic ZX just yet but it is proving to be
very difficult.
>>> and some other people added their own comments including a call for a new
file system.
Well, we all know MS-DOS sucks but it is possible to read a DOS formatted
disk on almost any machine (I'm not talking about Windows here ok). That
means we're going to have to use the A-Z/8.3 file naming convention. Ok, so
you can get filenames up to 32 characters on the original Mac but you can
only get 32 characters across the screen on the Spectrum. Probably the best
solution is to include a resource fork for each file containing stuff like
custom icons, long filename, file-type etc. As for access, the easiest way
to get stuff to work is to intercept the Spectrum's original commands, much
as the MB02+ disk interface does, and extend existing commands, This gives
you the commands:
Load, Save, Erase, Cat, Move, Copy, Format, Verify and so on.
Careful design could redirect calls to disk interfaces and microdrives to
the new file system.
>>> more memory and connecting the emulated spectrum to the hard-disk.
The Spectrum is a fairly slow machine so using the hard-disk as 'virtual
memory' should not result in a slowdown. Surely the easiest way to give the
Spectrum Gigs of memory is to patch a folder on the hard-disk into the
SILICON DISC (ram disk) of the Spectrum 128 an +2.
And what about the things no-one seems to have mentioned this time round?
Get better sound from the 128 by pluging a GM-MIDI card into the MIDI out
(the commands are already there in BASIC)
>> When will they do a nice GUI for the Spectrum/when will MS-DOORS be released
and translated etc.
I have designed a fully functional Spectrum GUI that gives you the
equivalent real-estate of a 512x384 screen at the Spectrum's standard
resolution and can be used with any file system.
>> Lets build a new Spectrum
I have finally heard of a project that I think may see the light of day.
Until it does I'm making my software open ended but continuing to write for
emulated machines.
And finally I'd like to make the point, shouldn't we fix the original
machine's bugs before we start adding new features? I still need help on my
debugged ROMS for the 128 although I'm glad to say I've squashed all of the
nastiest ones already.
-Andrew
Equin0x
> How about giving the emulator an .ini file with settings like these...
> [...]
> Protdir="c:\windows;c:\mystuff;c:\dos" # Directories inaccessible to
> the emulator
Yeah, as long as the INI file isn't in a place where the emulator can
modify it, huh?
Eq.
--
http://chasingtornados.com/equin0x
William McBrine
> I was trying to save people money downloading the original text every
> time they get the new message, but I take your point that not everyone
> does this the same way, so I'll preserve the last message from now on.
It's not all-or-nothing. You can quote the original message, but edit it
down to the relevant bits -- as you see I've done, above.
--
///\oo/\\\ Bugs? What bugs? ///\oo/\\\ ///\oo/\\\
Gregory L Fox
If you get the time, could you try and make a version of the specification?
I've published one at my website
(http://www.fox10050.freeserve.co.uk/VXX.html ) but I'd be happy to post
yours to the same site.
Reason being, if+when someone (possibly me, possibly you, possibly an
established emu author) gets around to coding and implementing these ideas,
it would be good for them to have several reference documents and find the
very best solutions from them.
Mine's already looking a bit out-of-date and I'll re-do it hopefully
tomorrow night after work, but it would be cool to have a wide variety of
specifications so that people can see everything clearly laid out all
together.
(By specification I mean in this case the proposed opcode set, either with
codes+mnemonics or just a list of features and their detail.)
Only if you get the time though. Email me with it in TXT or HTML and I'll
gladly host it at my site.
All the best,
Greg
Gregory L Fox
switch inside the emulator, like turning sound on or off, only in this case
turning the "ZXX Technology" (or whatever it ends up being called) on or
off.
The INI file would be a great way of choosing the options you want and don't
want.
Purists could disable the palette changes so that the colours always look
like the Spectrum.
Take your point about INI files being re-written though. Lots of emulators
re-write them every time at shutdown. (I think MEKA does that, and possibly
even MAME.)
This is where choosing exactly which emulator to add this to becomes an
issue.
I just re-read the Warajevo docs, and that emulator already supports speed
changes of the emulator controlled by the Spectrum. You can tell it to
interpret machine-code as X86 assembly. An example of speed-change is
already at their website (Linked from WOS). I might splash out and buy the
source-code for Warajevo!
Anyway, that's a digression.
It is true we'd have to beware of INI files and how they actually behave in
the field.
Actually the project seems to diverge into two parts - the specification of
the new functionality, and the interface which accesses it (patched ROMs,
INI files, etc.).
If any of you great minds out there have ideas you'd like to post in a more
permanent manner, I'd gladly host your pages on my website. I've posted my
feature-set (which is already looking buggered) and I'd be glad to post
specifications and ideas on the interface. Just email me
(gr...@fox10050.freeserve.co.uk) with finished TXT or HTML files and I'll
gladly post them. This idea needs a website to focus all the sub-threads
together.
Gregory L Fox
Wow Tom, that's an ambitious version. Why not make an official 'Tom Cedilnik
Specification' and I'll gladly post it at my website.
I personally think a lot of those graphics extensions are getting a bit far
away from Spectrum aesthetics, but I'm sure you could write some amazing
software that way.
You could always use those new capabilities sparingly so that the old 'feel'
is preserved.
Sounds a bit complex, but I'm sure if you make it into a mini instruction
set, everyone will understand fully.
> How does memory paging work in Speccy 128? How much addressable space
> does it actually have? The emulated Speccy could have as much as you
> could address. Does Speccy 48K support paging and therefore addressing
> more memory?
Memory paging is a bastard in machine-code on the 128. It's always a
compromise, because it can only directly address 64K with a flat memory
model.
I'm not exactly sure how you go about swapping the pages in machine-code.
From BASIC, however, it's dead simple, just use the virtual 'silicon disk'
as if it were a little 70K hard drive.
Speccy 48K doesn't support paging at all.
That's why the new ZXX (or whatever) extensions will need to have a stack
which uses PC memory to store spectrum memory images.
So far the consensus seems to be that it would be useful to be able to PUSH
and POP (store and retrieve) the whole of the RAM, 8K segments of RAM, the
screen, the UDGs (graphics 'A', etc.) and the current font.
That way you could use a flat memory model (sort of) all the time without
worrying about paging at all.
Simply PUSH any data you want to page out, do the new stuff you want to do,
then POP the old data back again.
This is limited, so we'll also have EX instructions (exchange) so that the
screen, total RAM, 8k segments, etc.etc. can be temporarily stored there
also.
Of course the benefit of the 'stack' model is that you could PUSH the first
8K segment of RAM and then POP it back as the fourth segment, thus doing a
big LDIR style shift. The difference between really using LDIR and using
this new stack is that you can PUSH every segment onto the stack and then
POP them where you want them. (Not sure how practical this really is though
in the field.)
Anyway, the above is getting a little bit obscure if you're not an assembly
programmer (and I'm not really, I must say.)
Basically the idea is that ZXX (or whatever) would eliminate the need to
worry about paging, and provide megabytes of memory for the spectrum to use
in quite a free manner.
(Of course the best way of extending the spectrum's 'memory' potential on a
PC is simply to use TAP files effectively - the load-times are not much
slower than memory anyway, especially if you use them for levels, graphics
and the like.)
Gregory L Fox
We're all eagerly waiting for Sonic ZX; please don't give up on it, as it
should kick arse bigtime.
I think what the people who fancy the extensions project are attracted to is
the idea that the spectrum could control its emulator (and thus its whole
environment), and do a whole lot of other cool stuff, without losing any
compatibility.
We're actually (most of us) not proposing any new ways of making the display
work, or anything anywhere near so radical as that.
The palette effect would just change the colours displayed - they would
still be the same 16 colours, stored as an array of 8x8 squares with BRIGHT,
FLASH and all the rest - it's just that the *emulator* would be
re-programmed on the fly by the Spectrum itself.
As to the speed, Warajevo have already got there first, so it's not a new
idea. It would be so cool though to have AI games which can think like their
modern PC equivalents.
I think 7000% or more (I mean, 2Ghz machines aren't that far off) would give
a totally new dimension to the spectrum's thinking power, without changing
its aesthetics at all.
As to the memory issue, it's certainly true that a lot can be achieved just
by using TAP files. (Single TAP file mode in Z80 or X128 provides gigs of
space for the speccy which can be used as if it's memory.)
The graphics accelerator functions and virtual stack for screens (etc.) are
really just frills, but they might come in handy, especially for BASIC
programmers (CSS CGC writers, etc.) who have ambition.
Fair enough if you think it's pointless - it probably is, and it's certainly
not compatible with a purist interpretation that everything must also be
possible on real machines.
Something about this thing appeals to me though.
Anyway, all the best with your own projects. They do sound extremely cool
(Mr. Kipling).
Gregory L Fox
Z80
> > processor running at 70 times whatever the old one ran at (7 Mhz was
it?) -
>
> We WISH! Try half that.
>
Yeah, sorry mate, I'm ignorant. Knew it was less than 10 but wasn't sure
exactly.
Still not bad for its day - IBMs weren't a lot quicker back then.
Gregory L Fox
(sniff, sniff)
Vaggelis Kapartzianis
>> LOAD # "c:\rooms.js1" CODE 16384
>
> Now that is a truly GREAT innovation. The only slight worry there is that it
> would involve a modified ROM as well as extra opcodes, but it's still a
> great idea.
There's an ultra-simple way to achieve the same thing in any Speccy
emulator and it has already been done in CPC emulators. A file
directory on the host OS gets treated as a sort of tape file, and
that's it. Any emulator that supports TAP files can be modified to
provide this kind of support very very easily.
> This LOAD# command would mean even greater freedom - imagine: 100MB spectrum
> games!!!
Well, you could always create an 100MB TAP file and loading would still
be instantaneous in any emulator. I guess too many people got over-
excited with ideas in this thread ;)
--
Vaggelis
Gregory L Fox
> be instantaneous in any emulator. I guess too many people got over-
> excited with ideas in this thread ;)
You are absolutely correct. TAP files are a great un-tapped resource
(sorry!!!), and we ought to make better use of them.
This is why I'm trying to get people to draw up their own personal
specification for this 'extension' project.
I think the throttling, palette-changing and hardware scrolling should stay.
I personally favour a PC-memory 'stack', and an alternate screen, UDG and
font feature which would work like the 'EX' functions. Beyond that, I think
the hard drive extensions are unneccessary and any further graphics
deviation would move too far from the original aesthetic. Even the
palette-changing is 'pushing it'.
My specification is up at http://www.fox10050.freeserve.co.uk/ZXX.html but
I'm eager for other people to send me their specs in TXT or HTML format and
I'll gladly post them at the site, so that anyone trying to put these ideas
into practice has clear concise plans from several sources with subtly
different takes on the whole thing.
If you fancy doing one, my email is gr...@fox10050.freeserve.co.uk
All the best,
Greg
Matthew Wilson
<gre...@hotmail.com> wrote:
>Anyone know the full answer to this? I suppose it's probably in the FAQ, but
>there have been a lot of new emulators since the last update.
>I know the Z80 source is available to registered users.
>The X128 and VBSpec sources are available freely.
>Are there any more? (Especially ZX32 or JPP?)
If you look at the Vintage Gaming Network
http://www.vintagegaming.com/
there are recent news items about MESS (a MAME offshot), which
apparently includes Spectrum and SAM support, and Speccyal, which now
has the source code released. I haven't tried either of them though.
Apparently the latest MESS betas support the Spectrum +4, a 48K
machine - at least according to the news items - what's that all about
then?
Matthew
Tomaz Cedilnik
>
> On Mon, 8 May 2000, Nathan Cross wrote:
>
> > How about giving the emulator an .ini file with settings like these...
> > [...]
> > Protdir="c:\windows;c:\mystuff;c:\dos" # Directories inaccessible to
> > the emulator
>
> Yeah, as long as the INI file isn't in a place where the emulator can
> modify it, huh?
Hehe, good one. I've had exactly same thought. :-)
Suppose the directory containing .ini file would be accessible and the
new-Z80 program changes it - will the change become active immediately?
Or will you have to re-run the emulator?
What if some nasty program changes the emulator itself? ;-)
Tom
Tomaz Cedilnik
> > This LOAD# command would mean even greater freedom - imagine: 100MB spectrum
> > games!!!
>
> Well, you could always create an 100MB TAP file and loading would still
> be instantaneous in any emulator. I guess too many people got over-
> excited with ideas in this thread ;)
Well... the problem is that Z80 code can only read TAP as a sequence,
not rewind / seek (you can seek manually using tape browser). So if you
have a 100 MB game, then it takes quite a while till all not-wanted
parts are skipped so the the wanted part is loaded. Unless we add some
kind of tape-seek command into the emulator...
Tom
kio (Günter Woigk)
> > 7000% on a modern celeron
> What do you want to do on it, real-time 3D rendering? If the aim is to add a
> bit more punch to the original machine then 7.08Mhz should be fine.
i'm afraid he even want's to go beyond that. hunt for quake and doom in
this thread. X-|
i'm curiously watching the going on. B-)
... kio !
--
http://www.kio.myokay.net
http://www.kio.myokay.net/zx_spectrum.html
k...@myokay.net (private)
kio (Günter Woigk)
Nathan Wain <nat...@caverock.net.nz> wrote:
> Since frames are going to take a significant time to calculate and render,
> and that time will vary from frame to frame (depending on the complexity
> of the view) ...we really need to be able to find out just how much 'real
> world' time has passed.
>
> I was thinking either:
> 1) Return, in one of the registers, the current emulation speed. (460%
> or whatever...)
> 2) Return, again in one of the registers, the time since the last time
> reading.
simply keep the interrupt frequency stable at 50 Hz, only speed up the
cpu. then the program running on your specci can determin on it's own
when it is time to draw the next screen (or whether it has missed one).
no enhancement needed.
Tomaz Cedilnik
>
> Wow Tom, that's an ambitious version. Why not make an official 'Tom Cedilnik
Would be fun to name it "tea strainer command set" since my last name
means "strainer". And everybody woould wonder why such name. ;-)
> I personally think a lot of those graphics extensions are getting a bit far
> away from Spectrum aesthetics, but I'm sure you could write some amazing
> software that way.
> You could always use those new capabilities sparingly so that the old 'feel'
> is preserved.
> Sounds a bit complex, but I'm sure if you make it into a mini instruction
> set, everyone will understand fully.
Well, without setting these things it would be default way - screen
image from 16384 on whole screen without rolling.
But it could be like these: there are 256 "windows". Each of them has
parameters. However, many parameters are fixed for window 0.
All windows are inactive by default. But windows 1-255 are not visible
when inactive. Window 0 is always visible. However, if it's set inactive
then all its settings are default.
Now you need these commands (and their variations):
set specification address of window n
read specification address of window n
enable window n
disable window n
check whether window n is enabled (result in zero or carry flag)
If window n is inactive then specification address has no meanning and
window is invisible if n>0. If it's active then the specifications have
meannings like these:
3 bits for shape:
000 - rectangle (parameters: x, y, w, h)
001 - rotated rectangle (parameters: x, y, w, h, angle)
010 - elypse (x, y, a, b)
011 - rotated elypse (x, y, a, b, angle)
... - ?
111 - polygon (x, y, dx1, dy1, dx2, dy2, ...)
4 (5?) bits for picture type:
0000 - a piece of screen image window
(parameters: x, y coords of upper left corner)
0001 - a piece of screen image window with tranparency mask
0010 - custom screen; lines follow each other, not every 8th;
then there are attributes (parameters: addr)
0011 - custom screen with transparency mask
.... - 2-colour palette image; every pixel is 1-bit, no attr
.... - 2-colour image; 1 colour is transparent, other is palette
.... - 4-colour palette image; every pixel is 2-bit, no attr
.... - 4-colour image; 1 colour is transparent, other 3 are palette
.... - 16-colour no-palette image; every pixel is 4 bits
(each colour is 4-bit: 3 RGB bits + brighness bit)
.... - 16-colour no-palette image with transparency mask
don't know how to put flashing into non-attr picture types...
Will think of the rest later... sleepy now
> > How does memory paging work in Speccy 128? How much addressable space
> > does it actually have? The emulated Speccy could have as much as you
> > could address. Does Speccy 48K support paging and therefore addressing
> > more memory?
>
> Memory paging is a bastard in machine-code on the 128. It's always a
> compromise, because it can only directly address 64K with a flat memory
> model.
But the way paging is defined, how much memory can it address? So that
we would expand it to the maximum...
> So far the consensus seems to be that it would be useful to be able to PUSH
> and POP (store and retrieve) the whole of the RAM, 8K segments of RAM, the
...
> Anyway, the above is getting a little bit obscure if you're not an assembly
> programmer (and I'm not really, I must say.)
Well, I don't like your PUSH/POP idea, it seems like less efficient
paging.
> (Of course the best way of extending the spectrum's 'memory' potential on a
> PC is simply to use TAP files effectively - the load-times are not much
> slower than memory anyway, especially if you use them for levels, graphics
> and the like.)
As I've said before, there would be a big problem using seek. Plus, it
would look like 100 MB of custom ROM and 48 kB of RAM.
Tom
Vaggelis Kapartzianis
> Well... the problem is that Z80 code can only read TAP as a sequence,
> not rewind / seek (you can seek manually using tape browser). So if you
> have a 100 MB game, then it takes quite a while till all not-wanted
> parts are skipped so the the wanted part is loaded. Unless we add some
> kind of tape-seek command into the emulator...
As noted in my previous post, it's actually quite easy for an emulator
to trap LOAD"program.bas" commands and skip to "program.bas" in the
tape image file or even load the file from a directory in the host OS
that is treated as a sort of random-seek tape.
You can also use DSK files for true random access. MultiMB disk formats
are, in theory, supported by +3DOS (that supports the same range of
disk formats the Amstrad PCWs did).
--
Vaggelis
AndyC
On Tue, 9 May 2000, Tomaz Cedilnik wrote:
> > Memory paging is a bastard in machine-code on the 128. It's always a
> > compromise, because it can only directly address 64K with a flat memory
> > model.
>
> But the way paging is defined, how much memory can it address? So that
> we would expand it to the maximum...
The way it is defined can support up to (yes you guessed it) 128K
(ignoring ROMS). It's basically a bit of a hack which bears an uncanny
resemblence to the way paging is done on the CPC. Only less so...
> As I've said before, there would be a big problem using seek. Plus, it
> would look like 100 MB of custom ROM and 48 kB of RAM.
Lots of ROM and a little RAM always seemed to work for consoles...
AndyC
AndyC
On Sun, 7 May 2000, Gregory L Fox wrote:
> > LOAD # "c:\rooms.js1" CODE 16384
>
> Now that is a truly GREAT innovation. The only slight worry there is that it
> would involve a modified ROM as well as extra opcodes, but it's still a
> great idea.
IIRC +3DOS supports pretty large drives. Why not just make it mount a PC
directory as B: or something. You could probably patch it with some sort
of directory support as well. Probably...
> Wow, that "LOAD/SAVE #" standard just HAS to be included.
> Superb. I always loved the LOAD! command in 128 basic - it allows so many
> neat tricks from BASIC without having to do everything in assembly.
<excessive 128 bashing mode>
The LOAD! command is pretty fecking crap IMNSHO. There were much better
ways of incorporating the Ramdisk into the Speccy (Streams using OPEN#
and CLOSE# being one way). At least +3DOS was a bit more sensible.
</excessive 128 bashing mode>
AndyC
Tomaz Cedilnik
> > Adding new Z80 op-codes.
>
> This is not necessary, and kills any compatibility with the original
> machine. If you want to expand the Spectrum it's better to do it using
> harware, which you can then emulate. I'll explain as I go along.
Well, haven't you seen strange op-codes with no effect? Are old programs
written so that they use those op-codes? I don't think so. So we can
decide that those op-codes will have an effect in the emulator. And
we'll lose no compatibility therefore.
> > Another option would be a choice of palettes
> I came up with a way of doing this ages ago that keeps 100% compatibilty
> with original software. Basically, if you change the way the screen is made
> up all the old games will fail, but if you only change the way it is
> displayed there should be no problem. It involves building a replacement for
> the ULA that defaults to the standard 16 colour (bright and normal) palette
> but can be redefined via OUTs.
The way I defined the way screen acts would be 100% compatible because
the default setting would be the old way. Unless the program uses
strange op-codes (and old programs don't) the screen will remain that
way, however, those strange op-codes may help you do some very
interesting effects.
> The Spectrum is a fairly slow machine so using the hard-disk as 'virtual
> memory' should not result in a slowdown.
Would if we speed it up enormously.
> Get better sound from the 128 by pluging a GM-MIDI card into the MIDI out
> (the commands are already there in BASIC)
What if you want wave?
Tom
Equin0x
> Suppose the directory containing .ini file would be accessible and the
> new-Z80 program changes it - will the change become active immediately?
> Or will you have to re-run the emulator?
Two ideas to make it a little safer:
(1) Shouldn't be able to use wildcards.
(To avoid evil tricks like ERASE #"*")
(2) Shouldn't be able to get a directory listing.
(It's not as though you'd need one anyway.)
Eq.
--
http://chasingtornados.com/equin0x
Equin0x
> The LOAD! command is pretty fecking crap IMNSHO. There were much better
> ways of incorporating the Ramdisk into the Speccy (Streams using OPEN#
> and CLOSE# being one way). At least +3DOS was a bit more sensible.
Whoever came up with the lovely keyword combo IN SPECTRUM FORMAT deserves
a prize.
Eq.
--
http://chasingtornados.com/equin0x
AndyC
On Tue, 9 May 2000, Equin0x wrote:
> On Tue, 9 May 2000, AndyC wrote:
>
> > The LOAD! command is pretty fecking crap IMNSHO. There were much better
> > ways of incorporating the Ramdisk into the Speccy (Streams using OPEN#
> > and CLOSE# being one way). At least +3DOS was a bit more sensible.
>
> Whoever came up with the lovely keyword combo IN SPECTRUM FORMAT deserves
> a prize.
Shirley it was COPY TO SPECTRUM FORMAT? Or were you thinking of something
else?
T'was very cool though. :-)
AndyC
Gregory L Fox
It wouldn't be possible using spectrum RAM, as each one would be 7K, eating
up more than the available memory.
However, if you used commands like the COPY commands of old MSX BASIC or
QBASIC, (except as opcodes) then it would work.
Example:
COPY SCR1, SCR2
LD ACTIVESCREENS, XX
In the above, the COPY command can copy to and from the screens, which are
held in PC RAM.
To put anything in there, you would need to load it into spectrum RAM and
then do a COPY, as above.
Then change the spectrum RAM and do another COPY. (This could all finally be
saved in the Z80/SNA file as normal.)
The ACTIVESCREENS part is a new register (you could call it K or something
like that) which would hold the pattern of screens active, one bit for each
screen. I mean, you'd only really need 16 at most. 8 would probably do.
Each could have its own palette, and all the rest, just like you were
saying.
Then if the K register held zero, it would mean 'normal speccy mode', and
any other value would enable your extensions.
It's pretty exciting.
Gregory L Fox
MESS is very slow, which is still a worthwhile payoff for its
mega-compatibility.
Looks like Z80 and X128 are still the best two for speed.
/|ndy |<avanagh
May 2000 09:28:18 +0100), sefini jorgo geanyet des mani yeof do
comp.sys.sinclair, yawatina tan reek esk AndyC fornis do marikano es bono
tan el:
>Lots of ROM and a little RAM always seemed to work for consoles...
Except the Playstation, o'course. Pile of shite as a result - ever played a
2D fighting game on it? MK3 is so laughable.
/|ndy|<
--
Creator of alt.binaries.comp.sinclair
and alt.binaries.emulators.gameboy.color
-- /|ndy's Lo-Fi Gaming --
ABCS FAQ * Emu Newbies * Museum * Pocket Review * Speccy
-- http://andyk.spedia.net/ | Last update: 06/05/00 --
Fave game this week: Tekken Card Fighters - WONDERSWAN
"Holy black hole!... I feel like a wet noodle!"
"í'm GÖNnA TH®Öw ýÖú ÎnTÖ NE×t tUë§dâý, HElLúVA Fâ$t!"
Gregory L Fox
>
> Except the Playstation, o'course. Pile of shite as a result - ever played
a
> 2D fighting game on it? MK3 is so laughable.
That is perfectly true. Too much stuff being standardised can have an
unfortunate impact on any software not having the same goals as the
automated stuff.
Maybe a back-to-basics approach is required. Just the speed, scrolling,
palette and extra video memory pages. (NOT a restructuring, before anyone
thinks it might be.)
Also, what about a page-in / page-out function for the 128k silicon disk as
a whole? Even just a 'swap' facility for it, doubling its power, that would
go a long way.
That way, TAP files could be used purely for sequencial data, and
regularly-used things could ALL end up on the 128k disk. (Or 70k disk if you
will.)(Doubled to 140k.)