Questions about gamedev in an emulator...

[Cheez26]

Okay, I got some questions about making a game within Fuse Emulator:

1. When I save a snapshot of a WIP project, do I use *.z80 or *.sna?
2. If I do finish making the game, how do I export it to *.tap?

These questions might apply to any game creation tool running in any emulator as well.

[ParadigmShifter]

Either should be fine I guess?

If what you are using just outputs raw binary file though (so an assembler, or a compiled language that outputs pure machine code output) I just save it as a .bin file and use the load binary file of the emulator to load it at the correct address. So I assemble my source, and I know the ORG address (lets call it orgaddr) so I then

CLEAR orgaddr - 1

in basic

Then I load the binary file to address orgaddr (one of the menu options for the emulator)

Then I

RANDOMIZE USR orgaddr to run it.

I nearly always use orgaddr of #8000 = 32768 until I run out of memory then I switch to #6000 = 24576. Code runs faster and data access is faster at addresses >= 32768.

You don't really need to worry about making a TAP file until you want to get people to test it. Most assemblers will make one if you use the correct command line options though.

Depends on what tools/assembler you are using I expect.

EDIT: Bear in mind if you use a snapshot (or z80 file, I think those are similar?) if your game has random number generation then the seed will be the same every time you load the snapshot.

That can be useful for debugging of course since if you know how to repeat something that causes a bug you can just do the same thing over and over.

But when you want to randomise the RNG a bit you have a couple of options:

I always seed the RNG with the R register on start up which only has a range of 0-127 I think but it's better than nothing. EDIT: But using a snapshot I have already done that since I only do it once (although nothing to stop you doing it more than once and adding R to the seed e.g. when a new game starts). R register is used to count instructions executed by the CPU (sorta - it's more complicated than that but the implementation only matters to emulator writers really) so is basically random after a while.

Then every time I am waiting for user input in a title screen or menu I throw away a random number.

In SJOE I also throw away a random number every time no input it recognises is pressed (I figure the time saved from not processing the input is going to be more than time taken generating a random number).

I can turn off those features via an assembly option though (via an IF/ENDIF) so if I want to stay deterministic for debugging I can do that.

[AndyC]

For purely development, it doesn't really matter. As to creating a .tap when you're done, then it's a matter of saving the data from your tool (and knowing how to get your emulator to record that as a tape file).

But, honestly, this is why I'd strongly recommend against doing any kind of development with tools that run on the actual Spectrum if you aren't using actual hardware (and even then I recommend against it). It will just add a heap of unnecessary pain to the whole process and doesn't really give you any benefits.

We did it that way back in the day because it was the only option. Cross development was adopted quickly by anyone who had any kind of choice in the matter.

[ParadigmShifter]

Yup Amen to that. Do as little as possible in the emulator except test and debug (debugging is only really possible if you program in ASM or are very familiar with the tools you use to produce the program - which usually means you wrote the tool yourself in ASM). Debugging ZX BASIC using a debugger is too complicated to even bother learning really.

That's one of the big advantages of coding in ASM really what you see in the debugger is exactly what you wrote. You lose that with compiled languages really unless they also come with better debugging tools. (You really want source level "step 1 line of code" debug availability and the ability to inspect variables in a format that you can make sense of easily).

Unless your tool of choice only runs on the speccy I guess (GAC/Quill or something?). AGD is a speccy program too I think? (never used it myself). There may be PC tools which produce the same data though?

EDIT: Too much "really" in that post really. At least I am weaning myself off of too much "though" though. Although I just ruined that though.

[Cheez26]

Cross development was adopted quickly by anyone who had any kind of choice in the matter.

Yeah, that seems about right, though I do still wish there are more cross-development suites for Linux. That way, I could use Wine less for this context.

[Timmy]

sna files are from a very old design, and I would not suggest people to use them if possible in 2024. (Unless you have no other choice, like I sometimes have to, in some of my own projects.)

But at least it's a simple looking* format.

[ParadigmShifter]

.tzx files are great also you can record some gameplay and play it back... I often think I have spotted bugs and when looking at the playback I can check whether they were actually bugs or if I was wrong about it being a bug.

And if it is a bug it's not that* hard to step into the debugger just before the bug occurs and see what is going on.

* ok it is quite hard doing that you probably need to know the exact frame the bug occurred (and probably the function which it occurs in too) but it can be very useful to debug really hard to find cases which only crop up occasionally. But looking at what happened you can probably work out a simpler case which will reproduce the bug 100% of the time (deterministic RNG helps a lot there too). Once you know a case that always reproduces a bug it's usually not hard to fix.

[Cheez26]

sna files are from a very old design, and I would not suggest people to use them if possible in 2024. (Unless you have no other choice, like I sometimes have to, in some of my own projects.)

But at least it's a simple looking* format.

So, do I use *.z80 for snapshots instead?

[ParadigmShifter]

I don't think snapshot format will affect anything unless you do weird stuff like changing interrupt modes a lot or are trying to accurately simulate peripherals for say timing purposes.

Don't worry about it.

Probably go with what was recommended (.z80).

EDIT: I do detect a slight case of the "revision timetable" syndrome going on though where you constantly planning what to do next week rather than doing stuff this week . Just get stuck in now! Make regular backups of any source though so you can rebuild your executables if things go wrong (someone will know how to prevent what went wrong going wrong in future though).

Procrastination is the thief of time as someone once said.

[Timmy]

So, do I use *.z80 for snapshots instead?

I haven't do that much testing with z80 files, because I still prefer the simple format of sna files. And perhaps for gamedev purposes, sna files could just be fine too.

If you have to generate a file yourself, then sna is easier. If you let an emulator to generate a file for you, z80 is safer.

You are not telling a lot of information here, so I can only guess and give you all the options. I'd rather prefer to just writing a straight answer though.

(Bed time now, for me.)

[Cheez26]

You are not telling a lot of information here, so I can only guess and give you all the options. I'd rather prefer to just writing a straight answer though.

To put it simply I'm trying out some game-making tools for the Speccy as an alternative to the Windows-only MPAGD (which also makes games for the ZX Spectrum.
There's also this Godot-based tool, which is brand new and doesn't even have a beta out yet.

[_dw]

That's one of the big advantages of coding in ASM really what you see in the debugger is exactly what you wrote.

There is certainly at least one exception to this.

When I was interested in the Intel 8087 math coprocessor, I was very confused by the source I found where to insert the FWAIT instruction.

Some sources said that it should be inserted almost everywhere, and other books did not have it in their sample programs.

It was even more interesting when I tried old linkers from that time (which were sold for outrageous amounts) and then looked at the resulting binary.

With every other piece of information I learned, my opinion turned 180 degrees.

In the end, it turned out that they were all right. FWAIT was not written in those instructions because the translator did it automatically before EVERY instruction.

It was important to set for which platform it was translated.

There I understood that not every ASM and BIN is a 1 to 1 translation.

And that one should always be alert. The Z80 has several mnemonic instructions that can be translated in several ways. Some just have different opcodes, some are longer and slower. They can be useful in special cases.

[ParadigmShifter]

That's more to do with coprocessors and pipelining and stuff though which the Z80 does not do.

Nowadays with pipelining, branch prediction, caches and coprocessors it's way too hard to translate instructions into execution time and the compiler is usually better than humans at it anyway.

None of that applies to Z80 which is why I like it (it's easy to see most of the big picture).

[_dw]

That's more to do with coprocessors and pipelining and stuff though which the Z80 does not do.

Nowadays with pipelining, branch prediction, caches and coprocessors it's way too hard to translate instructions into execution time and the compiler is usually better than humans at it anyway.

None of that applies to Z80 which is why I like it (it's easy to see most of the big picture).

And that one should always be alert. The Z80 has several mnemonic instructions that can be translated in several ways. Some just have different opcodes, some are longer and slower. They can be useful in special cases.

[_dw]

The main thing was that my belief that ASM == BIN simply does not apply 100%.

[ParadigmShifter]

You can just usually add up the TStates though and work out which one is faster.

Of course clever optimisations exist but those are based on mathematical identities and stuff. Register allocation is important too obvs since the Z80 is not very orthogonal in terms of instructions (e.g. you can ld (hl) with anything but you can only ld (bc) with a).

The only thing that is a bit variable is relative branches taken/not taken compared to unconditional branches. You can usually do some statistics though to work out which is faster.

Of course contended memory plays a part too but that tends to just slow everything down unless you really need exact timings (e.g. multicolour engines and such). Which is way too hard for me to get my head around, life is too short

Probs a bit off topic though and I'm probs a noob compared to some of the guys on here who really know all about the Z80. It's just a hobby for me

[ParadigmShifter]

The main thing was that my belief that ASM == BIN simply does not apply 100%.

On the Z80 it is though which makes it easier to understand. Obviously macros don't count

Only things that can affect the timing are interrupts and contention I think?

More modern CPUs got way too complicated to understand and you shouldn't compare 80s processors (actually 70s I think?) to them at all.

As soon as pipelining gets involved everything gets a lot more complicated (but potentially faster of course).


EDIT: Anyway that is way too off topic for this thread I think

(Very) basic explanation of pipelining here



Once you add caches as well that adds a whole lot of things that might go wrong affecting the timing.

[AndyC]

And that one should always be alert. The Z80 has several mnemonic instructions that can be translated in several ways. Some just have different opcodes, some are longer and slower. They can be useful in special cases.

There are a couple of occasions where there is an 8080 version of an instruction and then an extended Z80 version. LD A, (HL) being one that springs to mind.

I've never come across an assembler that doesn't generate the shorter, faster, 8080 version. On the rare occasion you need the other encoding (self modified code or for timing purposes) you can always just insert a couple of DEFB instead.

[PeterJ]

@Cheez26,

IMHO Fuse has a very confusing way of creating tap files. It's not intuitive in the slightest. More details here:

viewtopic.php?p=5250&hilit=Fuse#p5250

If you are using the 48k machine, then z80 or sna will be fine for snapshots. If using 128k, I believe you need to use szx, otherwise Fuse throws a warning. I know we had some discussion on this some time back, but I can't recall the outcome. I think I spoke with @Guesser, but I may be mistaken.

[firelord]

I think this might interest you :
There is an AGD version that is in spectrum ROM format. Instead of starting the original ZX Spectrum ROM with your emulator, you start with the modified AGD ROM . This has ready shortcuts to create TAP files (or TZX).

[Bedazzle]

So, do I use *.z80 for snapshots instead?

Why you need to save it as snapshot?

If we are speaking about assembly, then usual workflow is to write text in any editor, compile it, save to sna/tap then test in emulator.
Fast load in emulator merely does not take time to run fresh file.

[Cheez26]

There is an AGD version that is in spectrum ROM format. Instead of starting the original ZX Spectrum ROM with your emulator, you start with the modified AGD ROM . This has ready shortcuts to create TAP files (or TZX).

I looked on the itch.io page and yeah, you're right, there is that. I'll might try it later, but just in case if I want to do it now, how do I load it up?

[ParadigmShifter]

There'll be a "choose ROM" option in the emulator. (Some emulators ship with a replacement ROM instead of the 48K one - I think those are Linux open source ones which don't want to include the now copyright Amstrad ROMs (which they have given permission to distribute) since it is not open source or something) - so there will be an option to choose which ROM you want.