The Z-Machine is an engine designed to play text adventure games. It was originally made for the Zork series which were so popular that many new text adventure games were created for this engine. Interpreters for the game engine were ported to almost every computer, and the Z-Machine is the go-to engine when you want to make or play a text adventure game.
I see that Zork were made available to the CPC through CP/M, but I can't find an interpreted that would take external stories. The closest I've got is an interpreter for the ZX-Spectrum +3 and PCW16: Inform - ZMachine - Interpreters (http://inform-fiction.org/zmachine/amstrad.html) but nothing specifically for the CPC range.
Is there a Z-Machine interpreter for the CPC that I wasn't able to find?
or is it possible to use PC/M PCW code somehow?
Well, it depends what you mean?
I've just been to a site and downloaded the zxzvm system, and yes, the package covers the Spec machines (3 and 3+ ??), the standard PCW range, and the PcW16 (essentially DOS ?).
The same site has an alternative package including the source.
The standard PCW version is pure CP/M, so if your original question was referring to a CPC running CP/M then I would assume this system will work, apart (maybe) from problems with screen size, but maybe the system doesn't make THAT much use of the extra screen size. If you were wondering about all the extra facilities of the CPC range, colour, sound, graphics, etc, then, er, I think NO.
I see in the notes that there are some things that the PCW version does NOT do, i.e. beep ONLY, no special fonts, etc, so it does sound like plain CP/M.
One warning was issued - the prog, on starting up, will wipe your M: drive for it's own use, so make sure you've got nothing important there!! No warning given!! I just did a search for z-machine adventures, and found zxzvm.zip (attached).
Geoff
Yes I saw that one and I tried to make it work, but I just couldn't? Maybe I'm just doing it wrong though.
I moved the files in a .dsk with winape and started CP/M, but the executable told me I wasn't on a PCW and refused to go further.
I don't know what programming tools were available to users in 1984, but I've typed in a few adventure games which were published in Multi-platform Magazines like Home Computing Weekly, Steve Lucas wrote "Castle of desolation" in July '84 which got published in HCW Sept '84, but if you go to the Games Computing (http://www.cpcwiki.eu/index.php/Games_Computing) page, in the October Issue (http://www.cpcwiki.eu/index.php/GC_Oct_1984) is another Adventure game "Death of a Dictator" from Steve Lucas & also dated July '84, though in the November Issue (http://www.cpcwiki.eu/index.php/GC_Nov_1984) there's another Adventure game of his "Visitor From Space" and dated August '84.
It makes my mind boggle just how much was written and these programs aren't exactly on the small side, if something was made to produce a working structure for an Adventure Game, I could accept that, though I haven't seen any programs along those lines & all the Adventure Games books seem to be dated 1985 onwards. Yes I suppose when I look at the code there is a similar structure to it, I can only presume these guys were able to produce a working template and build their game from around that, though July '84 is very early, since the 464 came out in June (unless there was some coders privilege going on there).
Re 'Khaz'
I've just tried the package on my PCW, with a game I picked (from a pretty LONG list).
Sort-of worked. The game started, accessed the game file, and was doing things. But not properly, and VERY slowly. Don't know why. The process does (as per warning in my prev post) attack drive M: for it's own use, so one immed problem could by that your setup does not provide a proper M: drive.
But I had funny things happening with the screen, and when I did start getting game messages, the responses were very odd, so something not working correctly. Maybe the game I downloaded ('across the universe') was broken?
I note the credit within the PCW version of the system refers to John Elliott (ref Joyce emulator), so could ask him about it??
Could still be worth trying to sort out, as there was a PILE of games available.
Geoff
Further to the above,
Just tried another game, with a much smaller story file. The earlier one could well have been too big for drive M:, maybe that was why it went so wrong.
The second game file seemed to work better, but it was still VERY slow. Really TOO slow to be practical. Don't know why it's so slow, probably the structure of the story file, and the data therein, is just seriously inefficient?
While checking up on this, I found a comment in some IF (Interactive Fiction) newsgroup discussing the z-Machine, and that also referred to this version of the z-machine, and again commented that it was 'paiiinfully slow', so it's not just me.
Maybe we need a better version of the system? Maybe need to get the source code, and try to re-write it?
Geoff
It would be actually cool to have a proper Z-Machine interpreter for the CPC, there are tons of great games written for it. Apparently, it is very well documented, but I think that nobody tried to write something from scratch...
Further again to both above.
I've been doing a bit more digging.
Yes, the Inform/z-machine system is very well documented, there are lots of systems for it, there are utilities to do things with the data files, and there are piles of games available.
Problems - there are a number of versions. They seem NOT to be compatible. The zxzvm system, for example, copes with versions 3, 4, 5 and 8 (8 may well be the last/latest). I don't know why not 6 & 7? The zxzvm system is written in z80 code, so is prob the nearest for CPC use (as opposed to running within CP/M), although you'd have a choice of altering the system for CPC, or far fewer changes for CP/M on the CPC?
I've just downloaded the z80 code (source), I'll have a look at it although I'm FAR from an assembly guru, but I do know a bit about data file manipulation, indexing, searching, etc, and my immediate interest is trying to work out why the present prog is so VERY S...L...O...W.
It need NOT be slow.
My investigation has turned up the fact that published Infocom games (CP/M examples include HH Guide and Phoebos Leather Goddess) already include a CP/M z-machine. Both those games (which I have for the PCW) comprise a .COM and a .DAT file. Looking inside the .COM, the two seem to be near identical, apart from the name of the data file to load (i.e. HITCHHIK and LEATHER) and maybe some other numbers near the top. The datestamp inside the file is the same i.e. 2/5/85. I've seen a suggestion that if you take one of these files, and change the name of another game file to match what the prog is looking for, then it will run quite happily. BUT, I understand that these .COM files are fit for v3 of the system ONLY. I know that the two games I have run perfectly OK on the PCW, so the fault is NOT with the system, but with the zxzvm prog (although to be fair, the games I've tried so far have been later versions - v8 - and the later version may be more complex, and therefore slower (but surely not as MUCH slower as they seem to be).
I'll have a look as the source code, see what I can make of it. If anything? I know nothing about the native requirements of the CPC mind you!!
Geoff
More 'further to the above'...
Looking at the source code, I think my comments regarding M: are incorrect.
It looks like the zxzvm system if fact disables/deletes drive M: entirely, even to the point that the system will no longer recognise M as a valid device. The program then, I assume, makes use of the RAM now released for it's own purposes. Then it must re-enable M: as it exits.
The data from the game file must therefore be processed into memory. In some way. In the case of the first game I tried, the game (data) file was over 500k, so I assume it was not reading ALL of it?
By the way, for those interested in Z80 assembly, the .zsm files are all VERY well commented, and should be VERY instructive. I've spotted a few bits well worth further study already! Some of the files are specific to the Spectrum 3, other bits specific to Amstrad (PCW), there are also mentions of CPC within the code, suggesting that CPC compatibility was not completed, but was at least thought of at some stage??
Geoff
Everything is now way over my head. I'm glad that you're saying that the source is well documented, hopefully it should allow for porting without too much trouble.
I do have a tangencial question though: wasn't CP/M code hardware agnostic? As in, if you have CP/M for your computer, then CP/M software should run on it? Or do you need to tweak it, even ever so slightly, so that it can run on specific machines? I keep seeing "CP/M software" online without any specification about which hardware it can run on.
Some of the soft actually runs in different machines, yes, but some other needs to be tweaked a little bit to make it work... I am not a CP/M expert, but that is what was happening back in the day :) .
Yes.
It's always been the case that CP/M software might need the terminal/screen codes changing, for example WordStar and dBase both needed 'installation' for a particular CP/M computer.
Over and above that, there's the fact that the PCW has a larger screen than normal, 90 x 30 char rather than the usual 80 x 24.
Otherwise, yes, a CP/M prog could run on ANY CP/M computer, even if it does mess the screen up!!
Geoff
Quote from: khaz on 17:21, 11 January 16
I do have a tangencial question though: wasn't CP/M code hardware agnostic? As in, if you have CP/M for your computer, then CP/M software should run on it? Or do you need to tweak it, even ever so slightly, so that it can run on specific machines? I keep seeing "CP/M software" online without any specification about which hardware it can run on.
Humm...nice question; not so nice reply. :laugh:
You can write a CP/M program able to run in any machine with CP/M as its OS... :) but only if you don't use any specific machine feature. :o
That includes the screen, the keyboard, the... >:(
Geoff gave you a good example. The screen control codes for the CPC and the PCW are the same (VT52 like). :) But their screens differ in color support and dimension terms. You can run the same program in both machines, but the results will not be good. >:(
The main advantadge of CP/M (simplicity) is sometimes its main drawback.
In order to give your CP/M software good opportunities to run in a variety of machines, you have to include an installation procedure, mainly for screen type, including control codes, color, dimensions, etc.
And, of course, write your program in a way that it can adapt itself to these changes in configuration - not so easy as it sounds. >:( But it's posible. ;)
You could give a look at the source of TE, my small text editor for CP/M (http://www.floppysoftware.es/te.html). I think it's a good example. The way I follow with TE is to adapt the program to the screen type in compilation time.
In this way, I can develop TE for various kind of screen / machines / OS:
Quote
Current CP/M adaptations are:
- Amstrad PCW and CP/M Plus (31x90 VT52 like terminal).
- Amstrad CPC and CP/M Plus (24x80 VT52 like terminal).
- Spectrum +3 and CP/M Plus (23x51 VT52 like terminal).
- K. Murakami's CP/M emulator (25x80 VT100/Ansi).
- Takeda Toshiya's CP/M emulator (25x80 VT100/Ansi).
- Generic 25x80 VT100 and WordStar keys.
- Kaypro II, 4 and 10 (24x80 ADM-3A like terminal), contributed by Stephen S. Mitchell (thanks!).
Adaptations for other OS are:
- Windows 32 bit (25x80), compiled with Pelles C and its 'conio.h' library.
- DOS (25x80), compiled with Turbo C, and its 'conio.h' library.
- GNU/Linux (24x80), compiled with GCC and ncurses.
Quote from: FloppySoftware on 23:27, 11 January 16
In order to give your CP/M software good opportunities to run in a variety of machines, you have to include an installation procedure, mainly for screen type, including control codes, color, dimensions, etc.
And, of course, write your program in a way that it can adapt itself to these changes in configuration - not so easy as it sounds. >:( But it's posible. ;)
I tried this with a Generic version of Turbo Pascal 3 a few times, but never had any luck with it. :o
Windows does it via .ini files, although no need to worry about screen things. Even so, there are things that may need setting, like drive assignments, preferred paths, some user defaults.
Wordstar (and I think dBase) use another method. Coded into the start of the .com file are a group of data items, at pre-defined addresses, in which are stored the various terminal codes, etc. Then there is an installation prog which when run will update all those settings. The main prog, when running, uses whatever codes are set at those addresses. The manual indicates what data is at what addresses, so you can use a hex editor to manipulate the same things if you're so inclined.
You could also use a little .ini type file, and read in the required settings, but that would need doing EVERY time you use the prog, and with floppy disks it's always possible the file may become detached, so I'd say the WordStar method is better. I cannot remember, but I'm sure dbase II did the same. although normal operation of that system involves far fewer screen commands than WS needed.
Geoff
Yet another 'following....'
I've just tried another 'game' for the zxzvm system.
The ones I'd tried before were v8 files. They were both pretty large files, one was 500k+, the other was 200k+.
I was saying how slow they were.
The latest one is a v5 file, and it's less than 100k.
When I tried this one, I got a far more normal opening screen, and everything worked much more smoothly. Still slow-ish, but now just about practical/tolerable.
As far as I can see, the site I was looking at had a lot of v8 games, but there were many v5 as well, and prob some even older variants. So, the prog does work better, much better, with the older system, and also prob the smaller data file helps too.
Geoff
Just got a confirmation back from John Elliott.
His z-engine system cannot viably cope with v8 games. They can contain just too much data, too many options. Even a small one would be too slow. v8 is a more recent format, post Infocom, and you'd need a much more powerful machine to copy.
For the zxzvm CP/M system, you should stick to v5, or even better v3 (which is what the official Infocom games available like HHGTTG and Leather Goddess are). As noted previously, even the v5 game is a little slow, but at least it's playable. The v3 games are reasonably smooth on the PCW, so they are much better.
One link certainly has a lot of games listed, although I don't know what they're all like.
http://ifarchive.org/indexes/if-archiveXgamesXzcode.html (http://www.ifarchive.org/indexes/if-archive/games/zcode.html)
Cannot get the link to work from here. Use Google, search 'if archive zcode' and the above should be top item.
600+ games listed in the English section, but various other languages too, incl French, German, Spanish, Dutch.
Usually, the filename indicates version level, i.e. game.z8 or game.z5.
There don't seem to be any x6 or z7 games - John says that these were attempt to include graphics into the format, but they never really caught on. Prob too machine specific, and too slow.
By the way, the 'if' relates to 'Interactive Fiction', which is the other term to use when searching for such games on the web.
Geoff
Unfortunately the biggest problem is the Inform compiler used by nearly all non-Infocom z-machine games doesn't produce well-optimised code (the authors didn't really bother since everyone was on 'fast' PC's by then), so it's not surprising the later games crawl on old machines. Rather than avoid v8 games specifically, avoid any that are "Inform 7" games (even if they are small enough to be v4 or v5), which will be unplayably slow. Inform 6 games will perform better.
That is happening more and more with modern interpreters. Almost any PC under the sun is able to run incredibly complex text adventures even if it is slow by today´s standards... :(
That's a shame. Would adding RAM help in this specific case?
Sorry, I believe not. It's to do with the size and complexity of the data, and the efficiency of the way it's compiled into the 'game' file. Past a certain point, and it's just too much for the processing power of our humble Z80.
v8 it's way too much, but it tries. v5 it manages, but you can detect the strain. v3 and it's quite happy. As another poster comments, the later versions of the Inform (Z-machine) compiler assumed more powerful computers, and just didn't bother so much with the efficiency of the data. That's the fairer way to see it. Less fair, the older programmers who knew they were working within the capabilities of the Z80 and so many k of RAM were just so much BETTER!
Geoff
I remember Alan Cox had a "scottfree" interpreter that uses its own internal format (the games need to be converted); and it is pretty standard and portable C code (I tried to port it to my humble 8-bit microcomputer).
I should be possible to enable it to load the games from disk, although I don't know how large are those games; it might need 128K.
I'll put this in my TODO. Sounds like a nice weekend project!
Even someone made a scottfree version for tiny computers but I couldn't get it working in CPC or Spectrum: scottzx by Stefano Bodrato.
Index: if-archive/scott-adams/interpreters/scottfree (http://www.ifarchive.org/indexes/if-archiveXscott-adamsXinterpretersXscottfree.html)
Quote from: MiguelSky on 10:52, 15 January 16
Even someone made a scottfree version for tiny computers but I couldn't get it working in CPC or Spectrum: scottzx by Stefano Bodrato.
Index: if-archive/scott-adams/interpreters/scottfree (http://www.ifarchive.org/indexes/if-archiveXscott-adamsXinterpretersXscottfree.html)
I'll try to give it a go this weekend.
IIRC I got the original scottfree it to compile in CC65 for the 6502 (before realising that it was a stupid idea because my microcomputer didn't have enough resources to make it run anyway), and being SDCC is more standard compliant, I guess it should be easier but I could be wrong :D
Don't underestimate the power of the Z80. All it needs is proper memory management. All this math stuff is done quick, what really consumes time is display stuff on screen. And that's always the same for a given system.
In this case one (a person who has TIME) could take the most recent Z system and adapt it for CPC-OS like SymbOS and FutureOS where memory management is given and also a file system for more than 180 KB or so. :) Just my three pennies. :)
Even Zeugma from Linus Akesson (Zeugma (http://linusakesson.net/software/zeugma/index.php), runs on C64) gave up on Z7 and later because they are too slow. It says they should be playable with a SuperCPU (at 20MHz), but the CPC doesn't have anything like that yet. But maybe the desire of CPC people to prove the C64 guys wrong can beat this? :D
Well, we got the CPC Booster (nice math co-cpu if encoded for it) and Albeiro for mass storage and Lenovo-Power-CPU support (see other thread). And since you (I guess) know what you're talking about. Let me ask this: What in your opinion is the most time consuming? (Sorry, I don't quite get it). :)
The problem is actually that the Inform library that basically all the Inform-compiled games use does a LOT of computation . It doesn't matter if you optimise the hell out of your interpreter, there's still a maximum number of (virtual) instructions per second it can execute. If your interpreter does 500000 instructions per second, and the game needs to execute 20 million instructions for every game command, it's going to take 40 seconds no matter what.
The Z-Machine is a virtual machine just like Java for modern computers. There is even a C compiler for it (vbccz (http://cowlark.com/vbcc-z-compiler/)). So, what you get from the game files is a memory image you feed to the interpreter. You can always do some tricks to optimize your interpreter loop to death, but in the end there is still some overhead and you can't really optimize the game opcodes.
You would have to write a JIT that rewrite the game code on the fly to z80. Or, maybe easier for some games, get the Inform sources and write a compiler that targets the z80 directly, bypassing the Z-Machine completely.
Isn't a 16Mhz CPC called PcW16? :D
Quote from: pelrun on 07:59, 16 January 16
The problem is actually that the Inform library that basically all the Inform-compiled games use does a LOT of computation . It doesn't matter if you optimise the hell out of your interpreter, there's still a maximum number of (virtual) instructions per second it can execute. If your interpreter does 500000 instructions per second, and the game needs to execute 20 million instructions for every game command, it's going to take 40 seconds no matter what.
Glad that you don't exaggerate... ;-) Seriously how much virtual instructions can a game step need? It's 'just' and adventure. So per game step you will have about 20 or maybe 100. Real instructions will be way more of course.
Well, I'd guess that the data is just badly organised.
In the earlier systems, there were not so many separate tables, and the tables were not so big. Crude search techniques were OK. v5 maybe has more tables and/or bigger, v8 certainly has MUCH more (the old version 3 files in the Infocom games were just over 100k, the two v8 games I was trying had 200k+ and 500k+). If each 'action' required looking up in one table, with consequent searches in two or more other tables, all searches needed sequential search, that all adds time. I'd guess no indexes, and main files not sorted/fixed length records, so better search methods NOT possible anyway. So no ability to use binary chop search. Keep the data as is, and rather than copy it to memory, create sorted indexes so you CAN do binary chop, would be a massive help.
Just for info, if you need to search a file of 500 'records', you'd need to do an average of 250 reads. With binary chop you'd have a MAXIMUM of 9, but the data MUST be sorted. And readable directly by 'record'. If the data is NOT so tidy, then an index could be created that had regular records, sorted, each recprd having a pointer to the actual data in the main files, so you could access linked data in numerous files/tables in less time the original system could read 1 table.
If this is the case, then a better interpreter could still use the Inform created v8 'story' files??
Geoff
Quote from: TFM on 01:00, 18 January 16
Seriously how much virtual instructions can a game step need? It's 'just' and adventure. So per game step you will have about 20 or maybe 100.
Writing massively inefficient code is easy. When you're three layers up, in a natural-language development environment (which Inform 7 is), it's very hard to tell that you're constantly invoking a bunch of very expensive operations. The tools are focused towards creative people writing adventures without necessarily being software developers, and not towards producing efficient binaries.
Quote from: GeoffB17 on 02:55, 18 January 16
If this is the case, then a better interpreter could still use the Inform created v8 'story' files??
This would require a very smart interpreter. What gets fed to the interpreter is not high level instructions like "search for word in table", but low level stuff like "get data at address", "increment address", etc. So you would need a lot of work to analyze this code, understand what it's trying to do, and replace it with a more efficient version.
If you have the Inform source files (not the generated Z-Machine bytecode), then yes, maybe you can write a new compiler that performs such optimizations. But if you have only the generated bytecode, I doubt there is much to be done from it. Or maybe manually, like some people do for z80 games.
I don't know if that would help, but I found a bunch of non-Infocom games playable on CPC CP/M
Index: if-archive/games/cpm (http://ifarchive.org/indexes/if-archiveXgamesXcpm.html) Here I was able to play Colossal Cave Adventure B03 by copying the files on a disc in Winape and launching adv.com in CP/M. No slowdowns apart from the constant disc accesses, once I figure how to copy files into the RAM-drive it should entirely disappear.
Index: if-archive/games/amstrad (http://ifarchive.org/indexes/if-archiveXgamesXamstrad.html) Here are games specifically for AMSDOS. They are in the form of listings, probably not much could be used to make an interpreter. I haven't tried them as I don't know of an easy way to convert a listing.txt into a .BAS file (And I sure won't type the whole thing.)
The Z-Machine Standards Document (http://inform-fiction.org/zmachine/standards/z1point1/appf.html) All the Infocom v3 stories were ported to the CPC, through a CP/M executable. None of the v4 were, for some reason.
Quote from: khaz on 04:31, 19 January 16I haven't tried them as I don't know of an easy way to convert a listing.txt into a .BAS file (And I sure won't type the whole thing.)
You can load in emulator with the Auto-type feature at WinAPE ana JavaCPC. A faster way is loading as a tape in CPCE, but the file needs be edited to change carriage returns.
Quote from: MiguelSky on 12:23, 19 January 16
You can load in emulator with the Auto-type feature at WinAPE ana JavaCPC. A faster way is loading as a tape in CPCE, but the file needs be edited to change carriage returns.
I tried that, and Winape goes crazy if the system isn't qwerty. the typing is also quite slow.
Another way to do it is to put the txt on a disc (with or without header), load"listing.txt , save"listing.bas . I don't know if it's an added convenience from the emulator or if it works on a real machine, but that's quite neat. And much faster than auto-type. You have to convert your line feed character to CR+LF if you're not using Windows though.
But it doesn't really matter, as the listings are not for the CPC, but for the Amstrad NC notebooks line :laugh:
Quote from: pelrun on 06:28, 18 January 16
Writing massively inefficient code is easy. When you're three layers up,
You got a point there of course. :)
Quote from: khaz on 14:16, 19 January 16You have to convert your line feed character to CR+LF if you're not using Windows though.
Yes, by doing this, you can load the file as a tape directly (and activating Tape Bypass option).
Yes, I noticed, the files are not for CPC.
A bit of a bump, but on this page you can find PASCAL sources for a Z-machine. I'm not sure it's finished or even working on CP/M, the webpage (author?) isn't clear about it. It's a different program than the one previously discussed, so maybe it could be of some help?
Adventures (http://www.z80.eu/adventures.html)
http://www.z80.eu/downloads/INF.ZIP (http://www.z80.eu/downloads/INF.ZIP)
Quote from: khaz on 14:16, 19 January 16
load"listing.txt , save"listing.bas . I don't know if it's an added convenience from the emulator or if it works on a real machine, but that's quite neat.
It works on the real machine as well.
And the reverse conversion as well:
load"listing.bas"
save"listing.txt",a
I took a look at the Pascal from no$cash. Well, my Pascal is lost somehwo :(
So is my C - could C specialist compile FROTZ for CPC (128k?) -> GitHub - DavidGriffith/frotz: Infocom-style interactive fiction player for Unix (https://github.com/DavidGriffith/frotz) maybe ?
*bump*
ZXZVM: Porting (http://www.seasip.info/ZX/zxzvmport.html)
"From time to time, I've seen people discuss the lack of a version 5 Z-code interpreter for CP/M. And inevitable, someone points out that ZXZVM exists on the PCW, and reasons "surely it can't be that hard to port it to the CPC / Kaypro / Osborne / whatever platform we're discussing?""
SO, ASM-specialists that know how to do porting from spectrum to CPC and how to use banked memory - this is your chance :D
QuoteThe PCW front end makes no attempt at portability; it loads the entire story file into the PCW's RAMdisc, using direct hardware access to do so. (It also uses direct hardware access to redefine the font, but that's a less fundamental requirement).
hm
If all else fail, maybe the X-MEM could be used for this purpose. Limited compatibility, but still better than nothing.
BUMP
No one interested and able to port this to CPC ?
I just can't :(
Quote from: SRS on 20:46, 29 May 19
No one interested and able to port this to CPC ?
I just can't :(
It looks like @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) has managed to convert it:
http://www.cpc-power.com/index.php?page=detail&num=16439
I don't recall seeing any announcement about it on this forum - or anywhere else, for that matter - and I haven't tested it with any Inform files myself.
Yes. I saw @SRS (http://www.cpcwiki.eu/forum/index.php?action=profile;u=805) plea and I decided to have a go.
More info about the version and newer version is here:
http://www.cpcwiki.eu/index.php/Z-Machine
Bruno will update cpc-power soon.
I am thinking about making an X-MEM version running under AMSDOS. I did experiment with using extra memory under CPM+ but I couldn't find a free area to put some code in the base 64KB ram :(
Oooh, neat!
It is actually super cool to have something like that, super cool :D
Just before Christmas I released a vew version. There is both a cpm and amsdos version. See the cpcwiki page or my games page cpcrulez or cpc power for the download.
And they work, I can assure you :)
For those who are using CP/M, and do not have any significant expansionns, I've done a significant re-write of zxzvm, adding features like disk cache, and focusing on speed, adding support for the z1/z2/z6*/z7 formats and a few other nice things. It means some of the new enormous games won't fit in memory, however, you can happily play games like Sherlock or even Arthur (without the graphics) at a very pleasant to play speed. The CPC compatible build is done assuming CP/M Plus to take maximum advantage of the platform.
I've called this new version Vezza, and have included more details as well as a CPC build among over 20 versions to cover different platforms/configurations; all on Gitlab (https://gitlab.com/sijnstra1/vezza) - Any feedback welcome.
Main features:
* z1, z2, z3, z4, z5, z6, z7 and z8 games can execute (z6 is partial due to the screen requirements)
* Supports full screen width and multi line status (where terminal allows)
* Named game save and load
* Timed input on CP/M 3 (to support game such as BorderZone)
* Reverse text highlighting, including when selected using colour changing codes
* Accented chatacters are converted to a printable character
* Fast execution of games (even z3 games now execute faster than the original)
* z3 status line supports am/pm time including Cut Throats easter egg
* Banked CP/M version supports up to 37k DynMem (will load Trinity + Beyond Zork)
* 2KB z-machine stack size (over 50 call levels deep)
* Uses standard BDOS calls
Today most of the CPC users have a RAM expansion of 512 KB. Therefore CP/M Plus has the RAM drive C: (or M: in older cases). Why not using the RAM drive for couple of things insead of the RAM? Then bigger games (and GFX) can be used too. :) :) :)
Quote from: sijnstra on 23:48, 26 December 22I've done a significant re-write of zxzvm, adding features like disk cache, and focusing on speed, adding support for the z1/z2/z6*/z7 formats and a few other nice things.
Very nice!
At the beginning of this year Prevtenet released a Z-Machine VM for SymbOS SymShell...
http://www.symbos.de/appinfo.htm?00054
(http://www.symbos.de/gfx/shots/zym1.gif)
...and it will be very interesting to see the differences. I will try your one soon!
Quote from: GUNHED on 14:34, 27 December 22Today most of the CPC users have a RAM expansion of 512 KB.
[
citation needed (https://en.wikipedia.org/wiki/Wikipedia:Citation_needed)]
Quote from: Nich on 21:39, 30 December 22[citation needed (https://en.wikipedia.org/wiki/Wikipedia:Citation_needed)]
Nich on March 9th 2017: "I would be interested in an X-MEM." ;D
Quote from: TotO on 22:20, 30 December 22Nich on March 9th 2017: "I would be interested in an X-MEM." ;D
Expressing an interest in a memory expansion doesn't necessarily mean that I own said device (or indeed, any other one). ;)
While I suspect that a lot of CPCWiki forum readers own some sort of memory expansion, there are probably plenty of other CPC owners beyond the forum who haven't upgraded the RAM on their machines and are happy just to play games.
Quote from: Nich on 23:46, 30 December 22Expressing an interest in a memory expansion doesn't necessarily mean that I own said device (or indeed, any other one). ;)
You have probably not bought it, because it was not available (no parts in stock when asked). :)
Quote from: Nich on 23:46, 30 December 22While I suspect that a lot of CPCWiki forum readers own some sort of memory expansion, there are probably plenty of other CPC owners beyond the forum who haven't upgraded the RAM on their machines and are happy just to play games.
Today, most of the users are on emulators and use extra RAM by default. It is possible to buy a RAM expansion since 1985 on CPC. Only about the X-MEM betwen 2013 and 2017, it was sold around 400 units. Today, others RAM expansions projects are available and people building or asking for them. Sure, some people continue to think that a CPC must be the stock machine and the connectors around it do not exist. It is obvious that is useless to have one to play tape 80s games.
Quote from: Nich on 23:46, 30 December 22While I suspect that a lot of CPCWiki forum readers own some sort of memory expansion, there are probably plenty of other CPC owners beyond the forum who haven't upgraded the RAM on their machines and are happy just to play games.
Right, so they don't use CP/M (most(est)ly of the time) I guess. And my comment was driving at CP/M RAM discs.
Quote from: GUNHED on 15:18, 31 December 22Quote from: Nich on 23:46, 30 December 22While I suspect that a lot of CPCWiki forum readers own some sort of memory expansion, there are probably plenty of other CPC owners beyond the forum who haven't upgraded the RAM on their machines and are happy just to play games.
Right, so they don't use CP/M (most(est)ly of the time) I guess. And my comment was driving at CP/M RAM discs.
Extended RAM configurations is a good question. My goal with the project was to make something as fast as possible, retaining as broad a compatibility as possible. I've used CP/M as a base to run it across many non-upgraded actual hardware platforms as I could find core emulators for (over 20 all up so far); and my code runs faster than the original Infocom code, making games a pleasure to play. Using a RAM drive for paging read/write memory didn't sit well with me performance-wise so I didn't go there, however, if the game file (.z3/.z4/.z5 etc file) is copied there first it should be much faster on the disc access during the game than running off the floppy.
The compromise I made is that not everything will run, but to be honest if the game isn't responsive, my personal take with respect to this project is that it also won't run well enough to want to play. If you're keen on using something more hardware specific, do give zxzvm or other ports a go as per the beginning of this thread.
(post deleted - as I posted stuff already mentioned here ;) )