A decent Speccy 48k/Zeddy emulator for plain OCS/68k?

[trixster]

@eastrayk that’s a super impressive video the speed is remarkable

[commie1974]

Originally Posted by jotd

But Atari ST doesn't have custom chips (like blitter and all) and hence no chipmem slowdown when writing to screen. Those custom chips are rarely useful in emulators (except if we wanted to emulate Sega Genesis tiles...), but writing to video memory at a better speed is certainly an advantage. An advanced paula audio chip isn't much use too.

Just wild guesses here. The atari (like the PC) is even more generalist than the amiga, so better at emulation...

Wot??? Atari wins???
NO WAY!!!


BTW, really impressive emulator!
OK, 16MHz is more than twice as fast as a 7-ish MHz 500 but still I reckon that THIS is how a speccy emulator should look on such machines!
Thanks to our friend from Spain for the nice video!!

[commie1974]

...and, hey, does this run on a stock 520ST?
We could try it then through Amtari/Medusa/Chamaeleon on our 500s, hahaha!!

[jotd]

We could try it then through Amtari/Medusa/Chamaeleon on our 500s, hahaha!!

worth a try, as those emulators have a low overhead since 68k code isn't emulated. And this speccy emulator seems to be system friendly.

but the video update will be an issue for sure. Getting the source code and porting it would be the best way.

[AmigaHope]

You could probably get a pretty good emulation going if you had the emulated CPU just write to a monochrome bitmap and completely ignored the Speccy's color map. I don't know what happens if you tell OCS that your horizontal width is smaller than 320 though. If you can't have a 256-pixel wide bitmap in OCS, you could feed it the 256-wide bitmap to a 320-pixel wide display and get around this by having the copper reset the display to the correct position every scanline and use sprites to cover the garbage on the side of the screen.

EDIT: Obviously either way the pixel clock/aspect will be wrong, but you can just fix that with the dials on your monitor.

[jotd]

amigahope that could be perfect for those isometric games that can't change colors except in status bar, so playfield is monochrome anyway.

maybe copper could be used to emulate colors. I don't know the speccy, I had this idea for the Oric but wasn't doable in all cases because copper cannot switch colors fast enough

[AmigaHope]

Actually, on further thought, you would have to do copper tricks anyway because the Speccy's bitmap layout is weird (scanlines are staggered in memory).

...but thinking even further, there could be bit-endianness problems. It *shouldn't* be a problem because emulation code usually converts endianness in bitwise operations so that bytewise operations can be emulated faster (same with word-endianness)

Copper color-change idea wouldn't work because you can change one color register every 8 pixels, but emulating speccy colormap would require two register changes every 8 pixels. Plus the overhead of modifying the copperlist in horizontal blank.

I guess it would work for games where the background color stays the same and only the foreground color changes.

[jotd]

ironic that those 8 bits machines could switch colors faster than the copper can, with 1 bitplane.

[Estrayk]

Originally Posted by trixster

@eastrayk that’s a super impressive video the speed is remarkable

The ST spectrum emulator that I have showed in the video is system friendly, it works in monochrome and color at the same speed. Years ago I tried it on my STe at 8Mhz and it worked slower than on the MegaSTE at 16Mhz but if I disable the sound, it gained a lot and I could assure that it worked at 80% speed of a real spectrum. (without sound)

If we really think about it, it is curious that this ST emulator from 1990 works perfectly with 16Mhz and nowaways we need a minimum of 1000Mhz to be able to emulate any machine. Either things were very well optimized before or now we do them very badly?

This is a hidden video, in response to a user of a Spanish forum where he was laughing at the alleged multitasking that did not exist in the Atari ST operating system. To show him that there were other alternative operating systems on ST, I made a video where I run a fully assembly operating system called MagiC for ST. Multitask and displaying some applications running at the same time, like the spectrum emulator. The video is in Spanish but what matters is that you see that it also works at the same speed in monochrome. 640x400. Atari MegaSTE 16Mhz.

[ Show youtube player ]

[jotd]

nowadays 8-bit emulators are often written in C for portability. They also perform full screen refresh, with pixel by pixel computation, double buffering, also in C.

With asm you can directly convert N,Z,V,C flags between processors. In C you have to re-do the computation. That's one of the advantages, but not the only one, of writing an emulator in asm, with tricks for partial refresh and all.

note that Mame4ALL uses some asm cpu cores (arm) for z80 and others. Mame4all works well at 60 fps on very old android/iOS devices.

even in assembly, emulating a speccy with proper speed on a 68000 is a miracle.

[Gorf]

Originally Posted by jotd

Cybernoid by Rafaele Cecco, who then wrote First Samurai

68000/16MHz is twice as fast than a standard A600. But it's still super-impressive to see the speed of this emulator. would be nice to get the source code.

68020/14Mhz of bare A1200 is probably comparable in terms of CPU speed.

But Atari ST doesn't have custom chips (like blitter and all) and hence no chipmem slowdown when writing to screen.

The STE and the MegaSTE do have a Blitter.
Also on the Amiga there is no "slowdown" if you don't use the Blitter.
The speed of memory operations is the same for the ST and the A500 and is limited by the 68k ... the only difference is the clock 8 vs 7 MHz.

With a 16MH/14MHz 68K you would need real fastRAM on the Amiga or some cache (16KB) like the MegaSTE

[jotd]

well, code running from chipmem is super slow regardless if you're using the blitter or not. Data read/writes are following the same rules.

I'd be glad to be wrong

[saimon69]

Originally Posted by AmigaHope

Copper color-change idea wouldn't work because you can change one color register every 8 pixels, but emulating speccy colormap would require two register changes every 8 pixels. Plus the overhead of modifying the copperlist in horizontal blank.

Remember that horizontal resolution of a speccy is 256 pixels, that should help to recover a bit of bandwidth (maybe)

[Gorf]

Originally Posted by jotd

well, code running from chipmem is super slow regardless if you're using the blitter or not. Data read/writes are following the same rules.

I'd be glad to be wrong

It is exactly the same for the ST, since the video chip in the ST fetches the bitplanes from "ST-RAM" the same why Denise fetches them from Chip-RAM.

There is no slowdown for 4-bitplanes (or 2 high res) , speaking 16 colors, since the 68000 needs four clock ticks per memory access anyways.
That allows for the interleaved RAM access on BOTH computers.

only with more colours or Blitter-operations the chipset will block the cpu.

[commie1974]

Originally Posted by AmigaHope

You could probably get a pretty good emulation going if you had the emulated CPU just write to a monochrome bitmap and completely ignored the Speccy's color map.

This sounds perfect for ZX81/80 emulation...

[Nobby_UK]

http://aminet.net/package/misc/emu/Speccylator
http://aminet.net/package/misc/emu/Speccylator-src

[AmigaHope]

Originally Posted by Estrayk

The ST spectrum emulator that I have showed in the video is system friendly, it works in monochrome and color at the same speed. Years ago I tried it on my STe at 8Mhz and it worked slower than on the MegaSTE at 16Mhz but if I disable the sound, it gained a lot and I could assure that it worked at 80% speed of a real spectrum. (without sound)

You could make sound emulation on the ST stupidly fast with a limited form of JIT that just handled sound code and directly translated the AY register banging.

[commie1974]

Originally Posted by Nobby_UK

http://aminet.net/package/misc/emu/Speccylator

Hmmm, I wasn't aware of this one... This seems to be good for A500+ and A600... but would it run on a 1MB A500, soft-kicked with 2.0?
I just wonder, no equipment to test t here...

[britelite]

Originally Posted by Estrayk

If we really think about it, it is curious that this ST emulator from 1990 works perfectly with 16Mhz and nowaways we need a minimum of 1000Mhz to be able to emulate any machine. Either things were very well optimized before or now we do them very badly?

Well, it works "perfectly" by a very loose definition of the word, try running some demos with cycle exact timings and see them fail miserably on that emulator.

Current emulators aim to be 100% accurate, and that requires a lot more CPU power.

[Estrayk]

Originally Posted by britelite

Well, it works "perfectly" by a very loose definition of the word, try running some demos with cycle exact timings and see them fail miserably on that emulator.

Current emulators aim to be 100% accurate, and that requires a lot more CPU power.

You're right. I mean it works perfectly for 95% 80's Spectrum games.