Enhanced ZX Speccy Emulator

[Dobsa007]

I've thought about this for years, I'm sure many have, but never seen anything done.
Why not have a fast Speccy (alike) emulated with good graphics on our 3.5 GHz CPU's ?
Use the source code for the eZ80 emulator, 24 Bit Z80 code compatible,
Display - 1920x1080x16 bit, The underlying CPU does that, just write the buffer in sequence
There's a lot to play with

[SamC]

Above all, better graphics means improving the simple video system and addressing the huge memory requirements, all with an eye on digital-video connectivity. So far the only capable hardware I know is the HGFX of the eLeMeNt ZX platform, which allows to exceed 256 pixels in height and offers 512*384 and 720*546 resolutions, while still supporting the ZX screen.

The simple solution is to buy a raspberry pi and run something like this: https://github.com/ZXDunny/SpecBAS/releases

[Ralf]

If I understand correctly, you'd like to have an "emulator" of some unexisting machine which you call "enhanced Zx Spectrum". Yet it has modern graphic resolution, colour depth and is probably free of attribute limitations.

Am I missing something or are you trying basically to emulate a modern PC on a modern PC?

Also at first it would have zero software. And I'm not sure if someone would like to write it.
A system is as good as the software written for it.

[SamC]

I'm not sure if someone would like to write it

The zx-scene is big enough to try different approaches.
ZX-Uno, Chloe/SE, ATM 2/3, ZX-Poly, TS-Conf, Sprinter, ULAX...

[Cheez26]

Above all, better graphics means improving the simple video system and addressing the huge memory requirements, all with an eye on digital-video connectivity. So far the only capable hardware I know is the HGFX of the eLeMeNt ZX platform, which allows to exceed 256 pixels in height and offers 512*384 and 720*546 resolutions, while still supporting the ZX screen.

The simple solution is to buy a raspberry pi and run something like this: https://github.com/ZXDunny/SpecBAS/releases

ngl, SpecBAS looks rather handy, but how do I get this running on Raspberry Pi OS instead of Windows?

[PeterJ]

Welcome @Cheez26,

Nice to have you here. For the benefit of people on mobile phone with small screens, could I ask that when quoting that you only quote the salient points. Just makes it easier for us oldies and reduces the amount of scrolling.

I look forward to your contributions! It's nice that the Speccy gets some US love!

Peter

PS. I'm a Linux fan like you, but I believe SpecBas is Windows only. You could possibly run it under Wine?

[Cheez26]

[*]

Nice to have you here. For the benefit of people on mobile phone with small screens, could I ask that when quoting that you only quote the salient points. Just makes it easier for us oldies and reduces the amount of scrolling.

Thanks for the heads-up. I honestly forgot about the importance of mobile-friendliness for some people.

Anyhow, I've edited the image out in the quote thing of my previous post. You're welcome.

EDIT: I saw the PS and yeah, I figured it might be Windows only.

[spider]

Would not a Sam Coupe (or a modern FPGA implementation of such) provide a slightly better graphical output (no clash in one speccy mode) for your needs ?

And by using a 48K rom/emulator within most 48K games should run, in theory.

[SamC]

You could possibly run it under Wine?

It works fine in the Wine. The picture was taken in my desktop of the MX Linux XFCE

[ketmar]

one of the funniest things in "retro-programming" is working with the machine limitations in mind, i believe. otherwise we could simply write software for modern computers, and don't bother with attr clashes, counting ticks, and so on.

using cross-development systems is not a cheat, though, because many software houses did that back then. ;-) but the final result should still work on the original hardware.

Spoiler

that's why i'm not developing for ZX Next, for example. it is a great machine… but it's not Speccy anymore for me. it spawned it's own scene, though, and it's great. i like to play some ZX Next releases on the emulator. ;-)

[Dobsa007]

@Ralf
Why the negativity, the downness, It's just talk, calm yourself
There is no hardware, it's non existent, all done in code, I didn't say it clearly
Software on PC/ Linux, Speccy emulator with 'enhanced mode'
HD resolution, or lower for speed, 8 bit colour, eZ80 CPU, 16 MB or more memory
I'm not a modern programmer, barely remember Z80 assembly !,
But someone experienced in C could do this easily, The eZ80 emulation source is out there
An OS less system, progs do everything, screen, I/O, all
Simple to implement
Call it the Sinclair eZ80 Spectra

[Lethargeek]

hi @Dobsa007

there are a few "enhanced" emulators but none (that i'm aware of) of them has FullHD or eZ80
(btw i think even 50MHz eZ80 would be way too slow for even for 720p with 8bit colour depth)

as mentioned above, the main problem is the lack of software and enough people willing to make it
so using eZ80 or incompatible video buffer arrangement seems pointless to me
add the risk of fragmenting the community even more

the older Spec256 concept used planar gfx for 8bit colour in the same 256x192 ZX$ window
ZX-Poly is 4bit but also has a mode for quad resolution in the same window instead (with colour clash)
for existing games both require the original gfx to be located and repainted manually but no coding skills

or you may check my own emulator here as it's probably closer to what you're asking
it emulates a standard Spectrum connected to the peripheral device compatible with a generic Z80 based computer
aiming to provide full PAL resolution (the whole screen is accessible including the border area) with 15bit colour depth
but the main project goal was the easier and faster improvement of standard existing and future 128K ZX software
even though it requires some (dis)assembler knowledge it's more flexible and much faster than the Spec256 way
(the current number of improved modern and classic era games is about 150 right now)

[Lee Bee]

Aside from CPU speed, I don't think you can improve on the Speccy

[Mcoder2]

In what language would you like to program such a virtual machine?
Should it have a Spectrum-style editing environment (if you're going for BASIC)?
It is possible to set Pygame to Spectrum-colors and -fonts (which is what I've attempted here).
Pygame is not that fast, someone has recreated Skool Daze in Pygame though, so it's not that bad.
Would be faster by accessing DSL2 directly in C/C++.
My goal would be the mentioned editing environment with an integrated BASIC interpreter, so programs run directly (just as they used to). Plus additional commands for sprites and sound. And all of that realized in C/DSL2. It's probably way too much for me, but I'd love to see that one day.

You could then write BASIC programs in such an environment (or load in external text-files) on the PC, and they would probably run as fast as assembly programs on the Spectrum back then (or faster), while looking exactly the same. That's the idea.

Thing is, I'm also able to write in Pygame (once recreated the first level of Manic Miner with it - can't publish it unfortunately, you know, the copyright issues). So I could write a Spectrum style game on the PC already, if I wanted to, using whatever resolution I wanted. It's still quite an amount of work though.

[Dobsa007]

mcoder2
I haven't thought about any of that
Just the prog is cycle accurate Speccy emulator
With Enhanced mode, better graphics, PC speed
It can be anything, code can make anything possible

[Dobsa007]

Sorry mate, I'm not downplaying your ideas there, I'm a bit skewwhiff all the best mate

[+3code]

Aside from CPU speed, I don't think you can improve on the Speccy

I would give a vote for the ulaplus too, but that's all. Seems it would have been made with the technology of the time with a somehow double sized and more expensive ula, but it's simply a palette changer, retains the loved 2 colors limitation for each 8x8 cell, so not really legit but I fell it very "Spectrum taste".

[ParadigmShifter]

If you up the CPU speed you may as well improve the CPU too though really.

Z80 is the nicest (and easiest IMO) 8-bit CPU to code for in ASM though I think, but Z80 has some issues.

* Non orthogonal instruction set i.e. you can't do same with all registers. You'd want an ADD B, C instead of only being able to add to A.
* Wants a barrel shifter so you can shift and roll more than 1 bit at a time so SRL B, 2 to shift B down by 2. Also you want 16 bit shifts and rolls.
* You may as well throw in 8 and 16 bit multiply (probably have to make those non orthogonal of course since not many registers). And then you may as well add in a DIV as well as a MUL
* I know Ketmar wants EX SP, SP' which makes sense too
* I'd want PowerPC style instructions where you don't have to set the flags if you don't want
* Register autoincrement and decrement option (don't really need SP then either, can use any register as a stack), like 68000 had. Don't need LDI either then. Handle LDIR with a REPT prefix code like x86 maybe?
* Ability to load flags register with whatever you want to help out with stack abuse 16 bit reads/writes
* Hardware breakpoint instruction
* Obviously the default interrupt vector should be writable too (like on Amstrad I think?) so you aren't stuck with the ROM default IRQ.
* Multiple PUSH/POP maybe like ARM does? ARM allows you to push/pop several registers at once with one instruction.
* Atomic exchange any 8 or 16 bit register with another.

Then you may as well add in an instruction pipeline so instructions can overlap. And then you may as well add in an FPU stack too for floating point (it would probably want to be 32 bit floats rather than 40 bit floats Speccy uses though). If you are very bold allow floating point and integer instructions to be interleaved so it can do 2 instructions simultaneously if you do one of each (Pentium did that).

Add some cache memory that is faster to access than normal memory either with a global page register (256 bytes of 256 byte aligned memory anywhere) or like what 6502 does with its zero page addressing.

[AndyC]

Adding that many variations of instructions soon leads to the problem of needing excessive amounts of instruction encodings and thus slower instructions overall. The Z80 already suffers in that regard, with the Indexed instructions rarely being worth the cost.

The Gameboy CPU did it better in many regards, stick mostly to the core 8080 instruction set, forget adding lots of additional slow instructions and focus instead on a few very quick to execute ones. And it did the zero page thing with 256 bytes of fast memory at the top of the address range too.

There are other areas a Z80 alike could obviously improve on, such as avoiding the penalty for re-reading block instructions like LDIR etc.

[Dobsa007]

All these comments are great, my proposal for an enhanced system is what it is
no compatibility with zx software, new mode, totally programmed in the prog, no OS code to call on, do it yourself, write the screen by hand, etc, bare Ez80 programming, or, TI eZ80 basic adapted to the new system

[ParadigmShifter]

Adding that many variations of instructions soon leads to the problem of needing excessive amounts of instruction encodings and thus slower instructions overall. The Z80 already suffers in that regard, with the Indexed instructions rarely being worth the cost.

The Gameboy CPU did it better in many regards, stick mostly to the core 8080 instruction set, forget adding lots of additional slow instructions and focus instead on a few very quick to execute ones. And it did the zero page thing with 256 bytes of fast memory at the top of the address range too.

There are other areas a Z80 alike could obviously improve on, such as avoiding the penalty for re-reading block instructions like LDIR etc.

Well yeah. May as well drop compatibility with old instruction set and make all instructions 16-bit which would be ok with a pipeline. Thumb mode on ARM does that? But that doesn't have some of the full ARM instructions. If you had an instruction cache of 256 bytes as well (wouldn't want instructions to cross 256 byte boundaries, but if all instructions 16 bits you wouldn't have to) so the page PC was pointing at was accessed faster may not even need a pipeline.

Only problem with that is doing a 16 bit load immediate would need 2 instructions (PS1 CPU had similar issue with all instructions were 32 bits, you couldn't do a 32 bit load with one instruction, the assembler has pseudo opcodes to turn LD REG, ######## into 2 instructions (it would load upper immediate which zeroed out the low 16 bits then OR in the lower bits with another instruction).

A hardwired zero register would be nice too like on the PS1.

[+3code]

Seems somebody started loooong ago with a somehow related idea, https://rk-internet.com/eZXSparky/specs.html
But I would say it's totally dead, so it's in your hands, go on with it.

[Dobsa007]

I'm talking stupid, I know

[Dobsa007]

Seems somebody started loooong ago with a somehow related idea, https://rk-internet.com/eZXSparky/specs.html
But I would say it's totally dead, so it's in your hands, go on with it.

Mate I read everything about eZXSparky, loved it. you should make it an emulator, at least we have the experience in software

[+3code]

you should make it an emulator, at least we have the experience in software

I have no idea of programming, sorry; and I'm not really interested in that machine; as curiosy, ok, but I would find more interesting to see in the emulators avaliable some of the freak and marginal hardware designs published in some electronics magazines of the time. Too, no sense, no software, but as curiosity, more interesting to my eyes. In any case, no skills. I think SpecBAS, cited above, could fit some of your expectations.