My new emulator

[PokeMon]

Most of the reason I started the project is that I want to gain a better understanding of how things operate at the electrical level, the corollary being that I'll probably make many missteps along the way.

Why don't you buy an oscilloscope or a logic analyzer to see what's going on ? So you are now working only in a virtual world.
Anyway, have fun.

By the way, do you simulate what happens with signals when adding probably unwanted but existing capacitors, what happens when output current increases and much more ? Or what happens in timing errors or electrical delays in circuit design. Would be interesting but more complex. If you understand this you are welcome in the real world of electronics.

[Thommy]

Why don't you buy an oscilloscope or a logic analyzer to see what's going on ? So you are now working only in a virtual world.
Anyway, have fun.

It wasn't the sole reason and the only 'simple' machine I physically own is a SAM Coupe. I'm also unwilling to buy anything much at the minute — especially in this area — since I'm likely emigrating soon, to a country with an incompatible television standard.

By the way, do you simulate what happens with signals when adding probably unwanted but existing capacitors, what happens when output current increases and much more ? Or what happens in timing errors or electrical delays in circuit design. Would be interesting but more complex. If you understand this you are welcome in the real world of electronics.

I explicitly don't.

[Thommy]

Progress:

• I've added ZX81 emulation;
• I think I have the test for resetting the line counter (and possibly for when the directly programmatic 'vertical' sync is output) wrong but some other timing error may be at play;
• I've added a fast loading option for software that uses the ROM routine — it should work with any file format I add support for, including TZX;
• I've supplied a new YouTube video: http://www.youtube.com/watch?v=2Jl27YorYTc, showing a tiny bit of ZX80 BASIC, some normal ZX81 loading segueing into a fast load to show one of Wilf Rigter's demos — if anyone can confirm or deny that the 'graphics' part of the display should be slightly to the right of the 'text' part then I'll better know how well my test for asserting the wait line is working and whether I have the Z80's NMI response working reasonably.

A new OS X build is attached. I've installed Visual Studio and am finding Windows Forms and C++/CLI to be quite a lot better than I feared based on bad MFC memories, though I've nothing to show yet. I've bought hosting for the emulator, so I do have a plan to stop posting these tedious little messages and do distribution properly. In the meantime, thanks for humouring me and for any feedback or advice.

The immediate next plan is to implement TZX support.

[sirmorris]

Unless you're aiming at spectrum emulation I would be inclined to forget about TZH. IMHO this is a bloated, unnecessarily complex format for storing ZX80/81 data.

C

[Thommy]

Unless you're aiming at spectrum emulation I would be inclined to forget about TZH. IMHO this is a bloated, unnecessarily complex format for storing ZX80/81 data.

C

The problem is that the structure of the emulator doesn't currently allow any route from the internals to the filing system, and I think it can't without a lot of hacking around the built-in infrastructure, in OS X at least. Apple's built-in document classes are predicated on you not necessarily knowing where data is coming from or going to (whether the local filing system, some distant networked filing system, via a browser download to an unspecified temporary local place, etc), but knowing how to present and/or edit it when supplied.

That's not a problem 99.99% of the time, but obviously anything with multiple files doesn't really work with the .p/.81 type file format because — at a most generous description — they strip the filename from the start of files and leave gaps implicit.

The old emulators that glue directly onto the filing system seem to hack past that by trapping LOAD "whatever" and then looking to open whatever.p or whatever.81 from disk, but that's not really an option here, and in any case feels hacky.

I was therefore thinking that TZX would at least give me something I can suggest in response when the occasional problem surfaces. So far all I've found is one of the high-res games, but since I haven't found that in TZX you're probably right that it isn't actually a solution to anything.

[sirmorris]

There are - as far as I know - no ZX80 multi-loaders. There are three or four on the ZX81 that I'm aware of.

Code freely exists to turn a .O or P into an audio waveform, so that could be a compromise. If you expect users today to endure 6 minute real-time load waits however ... well I don't think you'll have any users. There will have to be some element of hackery. How hacky that is - well that's up to you

C

[Thommy]

There are - as far as I know - no ZX80 multi-loaders. There are three or four on the ZX81 that I'm aware of.

Code freely exists to turn a .O or P into an audio waveform, so that could be a compromise. If you expect users today to endure 6 minute real-time load waits however ... well I don't think you'll have any users. There will have to be some element of hackery. How hacky that is - well that's up to you

C

The current hack — which is entirely optional and merely an alternative to the proper hardware emulation — traps the 'load byte' routines in the ROMs (though just the program loading bit in the ZX81 ROM since the whole thing otherwise looks quite complicated) then looks ahead at the incoming waveform to see if a byte it can discern is there. If so then it forces the PC to the end of the ROM routine, fast forwards the tape to where it thinks that byte ended and shoves the byte in the appropriate place. If not then it does absolutely nothing, leaving the original ROM either to reach a failure condition or to be smarter about byte decoding if I've got the tests or tolerances wrong in some way. Similarly, if some software were to load a ROM portion then to do something custom in its own routines then that should work but with only the ROM part accelerated. And it's a pure PC trap, leaving the memory map otherwise completely unaffected.

Since it's inspecting the incoming waveform without making any assumption about from where the data is coming, it should work equally well with any file format — fast loading of TZX or WAV or whatever else should work identically to fast loading of 80/81/p/o. I think probably the smart thing is to approach normal audio files as an OS-specific thing, since they can all handle that stuff for you and if you wanted to support every hypothetical WAV out there you'd have to write quite a lot of code given that PCM is not the only valid encoding.

[sirmorris]

I don't regard that as a hack - one could theoretically build a board with a big fat CPLD on it and remap discrete sections of ROM code at will. If you formalise your ROM patching fast loader as a hardware add-on you won't feel bad about it ;¬)

[Thommy]

I don't regard that as a hack - one could theoretically build a board with a big fat CPLD on it and remap discrete sections of ROM code at will. If you formalise your ROM patching fast loader as a hardware add-on you won't feel bad about it ;¬)

Well it's implemented as a hack, sitting on top of my Z80's monitor stuff that was added on for debugging purposes. If it were actual hardware then I'd definitely want to implement it differently in the emulator. That said, now that you've made the point, I'm pretty sure there was real hardware for a whole bunch of machines that operated in almost exactly the same way as my hack but spooling the previously tape data from floppy disk — I definitely had one such device for my Acorn Electron.

Attached: a slightly modified build. I've modified some parts that I think were responsible for ongoing incompatibilities with OS X v10.5 (my last modification having been insufficient) and added 64kb RAM pack support, which restricts ROM to the lowest 8kb rather than the lowest 16kb as per my understanding of 64kb RAM packs.

I've noticed that my emulator gets too low a result in the freely distributed clkfreq.81 test program and that the rolling scroller at the bottom of the screen in the 25th Anniversary demo has a smooth pixel scroll on the top line but a character-by-character jump for the following seven (suggesting that it thinks it should be avoiding CPU to horizontal retrace synchronisation, but isn't). Given how simple the wait logic is over on the ZX81 side, I therefore suspect that something is wrong in my halt and/or NMI response stuff — like I've flagged the wrong clock changes to sample the wait line or I'm outputting the wrong signals during a halt or something like that. That's the immediate next thing to investigate.

[Andy Rea]

looking at the youtube vid when doing the loading, see those vertical bars... Well that is classic symtoms of Hsync counter been reset by the Vsync ( which occur albeit very short, but a vsync signal non-the less during loading). re jig your code to reset the Hsync counter on IntAck (M! low and IORQ low) and then The Hsync and NMI occurs 16 clock cycles after IntAck (either M1 or IORQ going high)

See if that cures it.

Regards Andy