johanberntsson / ozmoo Goto Github PK

Would it be possible to add 80-column support on the C64 using software techniques similar to https://www.pagetable.com/?p=901 or detecting when such existing software or hardware (like https://biosrhythm.com/?p=1860) exists and taking advantage of it.

Of course, it may require an REU and may be too slow to make it worthwhile. But, I think it would be an interesting idea at least worth exploring.

In ClairsysOzmoo-Regular-DE.fnt, 0x5B is Ö, but 0xDB is for some reason Ë.

Other German fonts don't have that feature.

Hello,
there's something weird going on with @set_colour in my code. There's a line break after the parentheses when there shouldn't be. But it only happens on the tenth line.
If I comment out and disable the @set_colour instructions, everything is fine.

Without @set_colour:
9) Quam ob rem cave Catoni anteponas ne istum quidem ipsum, quem Apollo, ut ais, sapientissimum iudicavit.
10) Quam ob rem cave Catoni anteponas ne istum quidem ipsum, quem Apollo, ut ais, sapientissimum iudicavit.

With @set_colour :
9) Quam ob rem cave Catoni anteponas ne istum quidem ipsum, quem Apollo, ut ais, sapientissimum iudicavit.
10)
Quam ob rem cave Catoni anteponas ne istum quidem ipsum, quem Apollo, ut ais, sapientissimum iudicavit.

Constant CLR_DEFAULT 1;
Constant CLR_BLUE 6;
[ Main   key i msg;
   msg = "Quam ob rem cave Catoni anteponas ne istum quidem ipsum, quem Apollo, 
   ut ais, sapientissimum iudicavit.";
   for (i=1 : i<15 : i++) {
      new_line;
      @set_colour CLR_BLUE CLR_DEFAULT;
      print i, ")";
      @set_colour CLR_DEFAULT CLR_DEFAULT;
      print " ", (string) msg; 
   }
   @read_char 1 ->key;
];

print_vm_map in vmem.asm does:

	lda vmap_z_h,y ; zmachine mem offset ($0 - 
	and #%11100000
	jsr print_byte_as_hex
	jsr space
	jsr dollar
	lda vmap_z_h,y ; zmachine mem offset ($0 - 
	and #%00011111
	jsr printa

I'm not sure those hard-coded ANDs are correct; wouldn't it be better to do something like:

	lda vmap_z_h,y ; zmachine mem offset ($0 - 
	and #$ff xor vmem_highbyte_mask
	jsr print_byte_as_hex
	jsr space
	jsr dollar
	lda vmap_z_h,y ; zmachine mem offset ($0 - 
	and #vmem_highbyte_mask
	jsr printa

In passing, I note that none of the tracing appears to shift the vmap_z_[hl] bytes one bit to the left to give the "true" Z-address high/mid bytes. Is this deliberate? I could see an argument for not worrying about this - it's debug code, perhaps best to keep it simple - but I thought I'd ask.

Hello! I have some smooth-scrolling code which I've been working on integrating into Ozmoo. If there is interest, I can submit a PR for review. Currently it supports c64 only, though I would probably plan to try to use the same code for c128 40-column mode next.

In zmachine.asm for the non-SLOW case, .read_global_var does approximately:

    cmp #128
    bcs .read_high_global_var
    asl
    xxx
.read_high_global_var
    asl
    yyy

That can be rewritten:

    asl
    bcs .read_high_global_var
    xxx
.read_high_global_var
    yyy

saving three bytes and two cycles.

To make the SLOW case work I think it's enough to add 'ror' just before 'jsr z_get_low_global_variable_value', or it would be possible to play further conditional assembly games to retain the existing code as-is in the SLOW case.

If it weren't for SLOW I'd suggest this is a small but worthwhile improvement - a small size/speed gain and no real loss in readability. With the SLOW case to be handled I'm not too sure, so I thought I'd raise this issue and see what you thought.

I tried to use ozmoo.online to create a two-disk version of Milliways for C64 but the interpreter says disk error. I can't guarantee that it isn't a VICE emulator issue. It worked well with VICE C128 mode and a d71-file.

Hello,
I'm trying to compile a zcode file with the online tool available on microheaven.com.
There's no problem with the default system font (english), but selecting the "French / French system font" (or another one), it throws an error :

ERROR: Custom fonts are currently not supported for this target platform.

The behavior is the same with z3 and z5 files.

I've already used this tool few months ago, and it was working properly, so I think things have changed.
Do I need to do something special to enable custom fonts?

Thanks!

It would be nice if there was a way to display colored PETSCII inline. For instance have an embedded keyword which will be interpreted to load a file (like those created by PETSCII-Editor by Fieserwolf) from disk, rather than be displayed by the intetpreter.

That way you could embed something like {PETSCII:filename} in your inform output, and when Ozmoo renders it, it will load the file inline.

This would bring relatively cheap graphics of any size to your adventure games. Bonus if text could flow around a smaller petscii image, to create stylized starting letters, etc. Maybe add a style to the command like {PETSCII:filename:flow}.

Similarly this could be used to load SID files for music and sound effects?

Maybe utilize REU support to speed this up further if available.

The 8-bit Guy (https://www.the8bitguy.com/) has released his supercharged dream C64 clone, the Commander X16. Have any of you thought of getting one of those machines and/or adding that machine as a build target?

With the French system font in v5, Ozmoo displays a '↑' character instead of a line break:

Congratulations on the release of 7.0!

I think I've found a small bug in the history code. In add_line_to_history:

	stx .history_last
	lda #0
	dex
	sta history_start,x

if X is 0, the dex will cause it to wrap round to 255 and we'll scribble past the end of the history buffer (unless of course it is a 256 byte buffer).

This doesn't happen very often, and it's quite sensitive to the precise size of the history buffer and the commands entered. (I noticed this because seemingly harmless code changes were breaking one particular version of my Acorn port, and making tiny code changes to debug it would make the problem go away. The history buffer was being dynamically sized to take up spare space below the stack and so the code changes would alter the history buffer size.)

You should be able to reproduce this by forcing history_size to be exactly $CE and running the benchmark with history support; the DEX will then wrap round from 0 to 255 on move 178. (I tested this by adding "CPX #$FF:HANG:BEQ HANG" immediately after the DEX and confirming it did hang in a C64 emulator.)

I think the fix is simply to check for wrapping here and make sure we wrap to the history buffer size not 255.

In "Fonts" (page 18) of the pdf, "german" is said twice, the second time for the spanish font

This may be an issue of bad practice (I'm very new to this), but I've tried formatting my output by doing the following:

Object Forest "^  FOREST"
    with ...

This does work the way I want it to in WinFrotz, but when running it in a C64 emulator, it seems to get stuck after printing the title, description and ">". The status bar isn't drawn and input doesn't work anymore. There's no error or anything, it's just frozen.

Removing the "^" makes it work again and I was able to have my line break by putting it into the short_name instead, but perhaps the status bar could somehow ignore the character to prevent crashing?

I added this as an experimental option to the Acorn port a while ago, and you can see the code (which is probably portable) around line 1891 in text.asm. I think this improves the playability of games like Hollywood Hijinx which don't natively support it.

(It's possible - probably even likely - my implementation is sub-optimal, let me know if you have any suggestions.)

I'm writing an adventure in Italian but I see that the fonts don't display all the accented characters like à and ù for example.
So what tools are necessary to create my own .fnt fonts? I would like to add the missing characters.

I think you can save a few bytes by conditionally omitting zmachine.asm's z_get_low_global_variable_value subroutine (line 650-ish) from some builds. I believe this is only needed (making up my own syntax, which is hopefully fairly obvious) if "ndef(Z4PLUS) or (ndef(COMPLEX_MEMORY) and def(SLOW))". The ndef(Z4PLUS) condition accounts for needing it to draw the status line on Z1/2/3 games and the remaining condition accounts for the use in zmachine.asm's .read_global_var.

I have been doing this on the Acorn port for a while, although COMPLEX_MEMORY is never defined on Acorn so I haven't had to express the full condition as described above, which is why I haven't sent a pull request for this. I haven't noticed any problems, and I think it's fairly obviously safe to do this because omitting that code when it's needed would cause a failure at assembly time.

When you first save or restore, Ozmoo lets you select a drive. It remembers this drive selection, which is good, but unfortunately also if you selected the wrong drive there are no "do overs" that I can see. No way to change the drive for future saves or restores.

Maybe allow save/restore to explicitly set a default file/drive, like 'save to drive 9 with comment "my new save"' or "restore file 5 from drive 11", etc., and do that again next time save or restore is called on its own with simple Y/N verification?

I don't know if it would also be feasible to skip drive selection if only one drive is detected available.

There are two copies of the following code sequence in screen.asm:

	jsr z_get_low_global_variable_value
	stx z_operand_value_low_arr
	sta z_operand_value_high_arr
	jsr z_ins_print_num

By moving the first three instructions to immediately before z_ins_print_num (so they can fall through into it), seven bytes can be saved. If the sequence is labelled something like "print_low_global_variable_value" I don't think this even harms readability.

@0ldSkull reported a problem with characters missing or coming our garbled in Beyond Zork on 80 column display on C128. I think this is related to my optimization of the 80 column routines. Vice's emulation of the VDC is incomplete, and I don't have a C128 to test on.

Could you make a video of the 80 column text problems in Beyond Zork on real hardware? Alternately, describe it more. Does it happen on the first screenful of intro text in Beyond Zork, or only when text starts to scroll?

It would also be interesting to know if it happens with a z5 title which doesn't use colours, e.g. Curses, and with a z3 title.

You can reach me at fredrik dot ramsberg at gmail dot com if there's something you'd prefer to send by mail.

You can see this in the attached screenshot of Hollywood Hijinx; I did "LOOK" (which has scrolled off the screen) and then just pressed RETURN (the "empty" prompt about 1/3 of the way down the screen) and it was interpreted as a "LOOK" instead of giving a "[Beg pardon?]" message as it used to.

I think this may be something to do with the commented out code just after .parsing_done in text.asm, but I haven't dug too deeply into this.

(I am seeing this with commit 183b8e9.)

Just a small tweak, if I haven't got confused...

In text.asm's .find_word_in_unordered_dictionary, the whole subroutine is wrapped in "!ifdef Z5PLUS {" but at line 945 there's a test for "!ifdef Z4PLUS {", which I think must always be true.

With commit 7b59ac8, the benchmark seems to be broken. It works fairly well but then goes wrong around move 410, as shown in the attached screenshot.

I noticed this while porting the recent changes to the Acorn, but I've done what I believe is a clean build of the commit mentioned above and run it under VICE and it seems to exhibit a similar problem. Please double check this before trusting this bug report though!

I love ozmoo, and am very happy that it works on the C64 and C16 (with 64K upgrade).

Would it be feasible to make a VIC20 port as well? Given e.g. a 32K or 35K RAM expansion? Or is that not enough for the interpreter to run? I think the Penultimate+ Cartridge provides 35K of RAM for a total of 40K, most of which should be available.

Thank you for your great effort anyway, even if it is not possible. I know that bitshifter's Z machine interpreter can target the VIC20, but I haven't tried it yet and am not sure if it is limited to certain games.

These should be prevented from being typed, like in the later Infocom C64 interpreter.

Incidentally, in the original Infocom C64 interpreter, you can actually type them, and it'll say something to the effect of "I don't understand the word so-and-so," where so-and-so is a character the Z Machine is not supposed to be able to input or output; and yet it does! How on Earth that happens is beyond me.

I think parse_terminating_characters is only called once during initialisation, so 48 bytes can be saved for Z5+ games by moving it into the Z-machine stack. I've just done this on the Acorn port and it seems to work fine after five minutes' testing and I don't see any obvious reason this wouldn't work on the Commodore either. Maybe I've overlooked something, but this seems a nice little saving if I haven't...

This subroutine does:

	jsr read_next_byte ; size of property block (# data | property number)
	beq .end_pf_property_list

It looks to me like the beq is intended to reflect the value returned in A by read_next_byte. But read_next byte always returns by doing:

+   ldy z_address_temp
	rts

so the beq in calculate_property_length_number will always be based on the value which happened to be in Y.

I think we need a 'cmp #0' between the two quoted lines of calculate_property_length_number.

This is easier to replicate on VICE (and indeed may be demonstrating flaw[s] with VICE's SCPU emulation) but there is also some evidence that it happens on real hardware as well:

While investigating a recent Dialog port I spotted an issue with Ozmoo + SuperCPU + REU preload.

On VICE, attempting to load the game will either produce an Ozmoo FATAL ERROR 8, or hard-crash (it forcibly quits) the emulator (every time, for me, MacOS latest public build r37694).

Testers with real hardware report that the game sometimes loads and plays correctly, but at least one FATAL ERROR 8 has occurred, as well as some silent failures during load where the system simply freezes.

I do have an SCPU plus real REUs and am willing to dig them out if you wish to pursue this bug. Am also happy to join you in a bug report to the VICE team.

Recipe:

xscpu64
Machine: NTSC 64C
Enable 512k REU
Boot attached Ozmoo .d64
Answer Y when asked about REU

craverly_dialz5.d64.zip

I think num_default_properties (in objecttable.asm) is no longer used and can be removed.

asm/text.asm mentions a "blinking cursor" but the cursor does not blink.

It looks like the current timer is only for Z4PLUS, and I'm not sure what it's actually used for.

I imagine adding a blinking cursor that works for Z3 will require adding another timer to count jiffies and a means to track the current cursor blink state. Looks like $CD is a sensible place to count down jiffies and $CF is a sensible place to track current cursor blink state according to https://gist.github.com/cbmeeks/4287745eab43e246ddc6bcbe96a48c19 And when toggling cursor blink state I'll just call our own turn_on_cursor and turn_off_cursor.

Does that seem sensible or am I way off track?

Apologies this is not an issue - more a request

Could Ozmoo support the ultimate 64 turbo mode to allow playing inform 6 and 7 games?

Here is a link https://1541u-documentation.readthedocs.io/en/latest/config/turbo_mode.html

As there are a lot of those boards out is this possible?

thanks

Shifters

The command line options for setting colors give an "Unknown option: " response if the color is outside the range of the Z-code palette. I made the mistake of using C64 color indices instead of the Z-code numbers and was confused by "Unknown option: -sc:15", because it gave me the idea that the option "-sc" is wrong. A feedback like "Color index for -sc is out of range, please be sure to use the Z-code palette" would be more helpful.

In revision 88 of Zork 1 for C64, the one with the grey background and white foreground and black status bar, the cursor is a black underscore. Is it possible to easily recreate that black underscore cursor in ozmoo's output?

I'm ignorant of C64 programming in general, but I've found some arcane references for low-level cursor handling. My guess is that the system-provided cursor is not displayed, but its location is tracked and a custom character is displayed in that screen location instead.

Hi,

Just want to let you guys know that recently I've expanded the Clairsys fonts to support more languages, both in Regular and Bold weights. You can download them from:
www.type-invaders.com/sinclair/clairsys/data/20210306-ClairsysOzmoo-complete.zip

The package contains the following font files:

clairsys.license.txt
ClairsysOzmoo-Bold-DA.fnt
ClairsysOzmoo-Bold-DE.fnt
ClairsysOzmoo-Bold-ES.fnt
ClairsysOzmoo-Bold-FR.fnt
ClairsysOzmoo-Bold-IT.fnt
ClairsysOzmoo-Bold-SV.fnt
ClairsysOzmoo-Bold-US.fnt
ClairsysOzmoo-Regular-DA.fnt
ClairsysOzmoo-Regular-DE.fnt
ClairsysOzmoo-Regular-ES.fnt
ClairsysOzmoo-Regular-FR.fnt
ClairsysOzmoo-Regular-IT.fnt
ClairsysOzmoo-Regular-SV.fnt
ClairsysOzmoo-Regular-US.fnt

I have a 32K 40 column PET (upgraded 3016) with another 8K at 9000-AFFF, making a total of 40K of available RAM. I have a patched version of Bit Shifter's Z3 interpreter that uses the top 8K as a cache, which is great. However I wonder if the extra 8K would make ozmoo feasible on this platform, too? Obviously adjustments for the Kernal (BASIC 4.0) and IEEE488 disk routines might need to be done.

The Inform 5 (!) game Enemies crashes early on in Ozmoo with a FATAL ERROR 10.

Recipe to replicate:

• Run Enemies from a 1581. (error will occur with or without REU use, so pick your poison--REU or warp mode recommended because despite being I5, Enemies runs slowly from disk!)
• Z until the cyclist appears. Examine cyclist. Z until the phone rings.
• Answer phone
• Experience FATAL ERROR: 10.

enemies_ozmoo.zip

File: picloader.asm
Line: 331
should be: !source "file-name.asm"
currently is: !source "file_name.asm"

I see you had to replace a beq with a jmp in 387de0f to avoid out-of-range branches. (I got hit by this on the Acorn port the other day too.) If you want, you can instead do:

	cmp #'.'
.beq_look_for_x
	beq .look_for_x
	cmp #','
	beq .beq_look_for_x
	bne -

since performance isn't really a concern here.

When changing color back to the "default colour" (1) with @set_colour in dark mode, it reverts colors to what they are set to in normal/light mode, rather than the current color mode.

This makes dark mode difficult/impossible to use in a game that employs different colors.