ZX Spin 0.4 available for Download.

edited December 2002 in Emulators
Standard Cut-n-Paste from the CSS post:

If all goes well, I'll upload it to WOS on monday.


Okay, it's that time again when we decide that SPIN is ready for a new release.

Get it from

http://homepage.ntlworld.com/paul.dunn4/Spin.zip

This one is in fact a bit of a test - we're particularly interested in how SPIN performs in full screen mode using the new DirectDraw code. Anyway, a big thanks to Andrew Owen for providing the seBasic ROM for inclusion into SPIN - simply check the "use SEBasic Rom" box in the hardware options, and away it goes.

He needs feedback, so let him know what you think!

In other news, here's a list of what else is new:

v0.4 - OpenGL and Seriously fast tapes

Added OpenGL (fullscreen/Windowed mode) support - way cool, check it out. Might need a fast PC though.
Altered the functionality of the toolbar - rightclick some buttons to get more options, ie - you can right click the reset button and then choose a normal reset or a Usr0.
Fixed a possible startup Bug.
Fixed a bug with ULA Snow and a reset - also demos such as Yolka97 work properly now :)
Fixed a last used folder bug with zip files - it now opens the folder the last zip came from, rather than the temporary folder it extracted to.
Added the ability to load snaps with shift held down to avoid switching hardware, which is usefule for loading snaps made in 128k/+2 mode in a +2 emulation.
Fixed a bug regarding pauses and B increments which prevented Doomsday.tzx from loading.
Fixed a small bug that didn't list zip files in the disk manager
Added undetected loaders to the speedloader detection list - Indiana Jones and the Last Crusade's level loader, and Kentucky Racing. (Both Alcatraz).
Added Marko's 10h Acceleration to the speedloader - it's quite possibly the fastest non-flashloading system in any emulator :)
Fixed a bug in the tape browser that can cause lockups and BSODs on 9x machines.
Fixed more small bugs in the tzx editor to do with view positions and menus and such.
Added Sinclair InfoSeek pasting ability to the ArchiveInfo Block editor
Fixed an interrupt table overwrite bug in the z80 core
Fixes to the auto tape controls - might be better now, needs testing, but seems to stop when it should.
Now detects Windows NT in order to overcome certain slowdowns in windows GDI
Added Interface II Rom support (*.rom)
Added ZXPrinter output - save those listings to disk :) Normal slow printing for compatibility, and a ROM trap for added speed in LLISTing. Use F1 (fullspeed) mode to speed up normal prints.
Added Kempston Mouse support.
Removed most of the old GDI graphics code, and added DirectDraw support.

Cheers,
and feedback to the usual place,

Dunny.

[ This Message was edited by: Dunny on 2002-12-01 16:46 ]
Post edited by Dunny on

Comments

  • edited December 2002
    Ooooh look Tkrap64, Dunny's written a Spectrum Emulator...

    I wonder if it's brown.
    I wanna tell you a story 'bout a woman I know...
  • edited December 2002
    On 2002-11-30 23:13, Dunny wrote:
    SPIN is ready for a new release.
    Get it from http://homepage.ntlworld.com/paul.dunn4/Spin.zip
    It's sloooooooooooooooooooooooooooooow.
    On my home comp, an AMD K6-2/500MHz, Matrox Millenium 2 video card (PCI).
    Either window or full screen, either video mode.

    Unusable for me. Returned back to previous version, sorry.

    (small bug - the "Okay" and "Cancel" buttons from the options window are truncated down, the're ending outside the window)

    Cristi

    [ This Message was edited by: secarica on 2002-12-01 03:24 ]
  • edited December 2002
    Nice work Dunny - I especially like the ZXPrinter bit and how tap/tzx files load almost as quickly as sna/z80 files!!! Very impressive! :D Many thanks for all your work - this emulator is the best!!!

    Some feedback ...

    [1] No speed problems on my 1.4 Athlon.

    [2] On Win XP Pro, if GDI in selected in the display options, upon restarting the emulator, the following error message occurs and the ... "Access violation at 004BD5EE in module 'ZXSpin.exe'. Read address 00000030". The error pops up each time focus is lost or given to ZXSpin. The only way to shut ZXSpin down is via Windows task manager. This error occurs with the default settings and the video renderer is set to GDI.

    [3] Scanlines don't work in DirectDraw or OpenGL modes on my GeForce 2 card (hardware filtering to blame perhaps?), and the scanlines option is disabled when the GDI rendered is selected. Is it possible to implement scanlines in GDI mode?

    [3] Any chance of adding a 'sharp' video option (as done in MAME) to recover some image clarity/sharpness for people with Nvidia gfx cards? The Gfx card hardware filtering causes the screen to look blurred. (On the other hand, its quite a good 'TV mode' effect!:))
  • edited December 2002
    Spin 0.4 do not work with my video card ATI 3D RAGE PRO. I see empty rectangle in Scpeccy screen.
    Version 0.3 GL5 also unusable, but version GL4 works fine.
    Please return to GL4 version video routine.
    My be problems with video overlay ?
  • edited December 2002
    It appears to work so far for me. I used V2.6 until now (strange numbering). I have the ATI Rage Fury Pro 32MB TV out. The analogue joystick works now, no over sensitive reading like Spectaculator. The screen updating is faster. How about implementing the interrupt as an option at the end of the main picture?

    Anyone got the instructions for Gunfighter by Atlantis? I completed it on the Electron but it did not have much of an ending. Anyone completed the Spectrum version?

    Fraser.
  • edited December 2002
    It initially worked but now I get Access violation at address 4BD5EE, read of address 30.

    Fraser.
  • edited December 2002
    On 2002-12-01 15:27, Fraser wrote:
    It initially worked but now I get Access violation at address 4BD5EE, read of address 30.

    This is fixed - well spotted, and I can reproduce it here. You're using GDI mode graphics, AICMFP :)

    D.
  • edited December 2002
    On 2002-12-01 16:53, Dunny wrote:

    This is fixed - well spotted, and I can reproduce it here. You're using GDI mode graphics, AICMFP :)

    D.
    AICMFP and I can ... ?
    I must have switched to GDI. DirectX speed seemed quite good.

    Fraser.
  • edited December 2002
    How can I change back to DirectDraw? What registry keys is there?

    Fraser.
  • edited December 2002
    On 2002-12-01 19:00, Fraser wrote:
    How can I change back to DirectDraw? What registry keys is there?

    Fraser.

    Load the settings file 'spin.ini' into notepad and look for a section headed [Graphics]. To change back to DirectDraw, set the RenderMode value to Zero. :)
  • edited December 2002
    On 2002-12-01 18:11, Fraser wrote:
    AICMFP and I can ... ?

    AICMFP = And I claim my five pounds :)
  • edited December 2002
    On 2002-12-01 06:07, Refrenz wrote:
    [1] No speed problems on my 1.4 Athlon.

    Well, no :)
    [..] "Access violation at 004BD5EE in module 'ZXSpin.exe'. Read address 00000030". [..] This error occurs with the default settings and the video renderer is set to GDI.

    This should now be fixed in last night's release - hopefully!
    [3] Scanlines don't work in DirectDraw or OpenGL modes on my GeForce 2 card (hardware filtering to blame perhaps?), and the scanlines option is disabled when the GDI rendered is selected. Is it possible to implement scanlines in GDI mode?

    It's possible to replace the scanlines in GDI mode but it's going to slow it down an awful lot again. They haven't yet been implemented into the DirectDraw code but they should work fine in OpenGL. Odd.
    [3] Any chance of adding a 'sharp' video option (as done in MAME) to recover some image clarity/sharpness for people with Nvidia gfx cards? The Gfx card hardware filtering causes the screen to look blurred. (On the other hand, its quite a good 'TV mode' effect!:))

    Do you *really* want the sharp video option? That TV mode effect is well cool! :)
  • edited December 2002
    On 2002-12-01 14:10, Fraser wrote:
    How about implementing the interrupt as an option at the end of the main picture?

    For what purpose?
    I can't see no possible reason for wanting this.
  • edited December 2002
    Many games update the screen at the start of an interrupt servicing routine. The reason is the ULA will not be reading the screen memory again for a large period of the frame. The picture can possibly be updated before the ULA is reading again and has a fully updated screen to read. Without using interrupts there would be a lot of partially updated graphics visible. By shifting the interrupt to the end of the main picture there is more time for a game to update the screen. There must be many games that would benefit particularly those with a lot of screen updating. It should only be a problem to games that do multi-colour special effects.

    As it is the bottom border time period is hard to utilise. I think the comp.sys.sinclair FAQ says that.

    How did the new Spin get a much smaller exe file?

    Fraser.
  • edited December 2002
    On 2002-12-02 17:20, Fraser wrote:
    There must be many games that would benefit particularly those with a lot of screen updating.
    First - Yes, it may be useful, but for old games this is practically useless. Who will modify an existing game to benefit for this ?
    As for new games ... what new games ?

    Second - if the hardware interrupt signal remains at fixed position and fixed field rate, by increasing the CPU clock speed, the result is comparable or better.

    Cristi
  • edited December 2002
    It would be immediately useful on loads of games without any modifying. Increasing the cpu speed would have the same effect but in a crude way. When interrupts are disabled the speed will be much too fast so possibly scrolling messages when not playing etc will be too fast.

    Fraser.
  • edited December 2002
    You could set the CPU speed to 7MHz in the Emulation menu and then fine tune it to the speed you want using the emulation speed slider bar in Options->Hardware.

    Your request could be added later but right now we're trying to tie up a few loose ends in the source prior to releasing it.
  • edited December 2002
    Running Spin 0.41 under Windows 2000 SP2, I get:

    Access Violation at 47ca59 read of address 1149088

    I OK this and another message box then appears in the background. It says:

    Access Violation at 47ca59 read of address 11c3fc0

    If I OK this box, Spin starts up. It does this the first time I ran it after extracting it and on subsequent runs.

    One more thing... Has any one tried the interface with large fonts selected from the Display property sheet - Settings Group - Advanced Button - General Sheet?

    The toolbar at the bottom of the window messes up and a lot of the texts and dialogs overlap and generally don't fit. I think you need to increase the size of your interface resources.

  • edited December 2002
    yes, I agree with secarica. I mean fixed interrupts with faster CPU. Speeding up the emulation is useless. I need a standart spectrum+2 with 28mhz z80 :)

    I always wanted to see this X128 feature on a windows based emulator.
  • edited December 2002
    Anonymous - can you send your SPIN.ini, along with any SPIN.log (in c:\) and also your machine specs? It may help to track the bugs down.

    [Increasing Font Sizes]

    Sorry, but SPIN was designed with normal font sizes in mind, and we won't be accomodating those who choose to run in larger fonts, sorry. Maybe in a later release, but it's not even on the to-do list, let alone far down it.

    D.
  • edited December 2002
    On 2002-12-02 21:29, Arda wrote:
    I always wanted to see this X128 feature on a windows based emulator.

    SPIN does exactly that. The obvious method of accelerating your CPU would be just to have a larger amount of Ts per frame, but you also have to ensure that the ULA doesn't accelerate too - which is a tad harder to manage.

    D.
  • edited December 2002
    On 2002-12-02 18:26, Fraser wrote:
    It would be immediately useful on loads of games without any modifying.
    Hmm ... an example ? I don't see any.
    Increasing the cpu speed would have the same effect but in a crude way. When interrupts are disabled the speed will be much too fast so possibly scrolling messages when not playing etc will be too fast.
    I'm not sure I understand.
    Disabling interrupts ? We are speaking here about moving the hardware interrupt in advance, not disabling it. Your idea about moving the hardware interrupt position has no meaning if the interrupts are disabled.

    Cristi
  • edited December 2002
    How can increasing the cpu speed be useful if a program has interrupts turned off? The speed would be too fast because there is nothing regulating it.

    An example is any game that uses interrupts and has flickery graphics in roughly the top third of the screen.

    It seems that most people are more interested in more T states per frame and hence less partially updated graphics than true emulation of the contended memory and processor wait states/clock halting.

    Fraser.
  • edited December 2002
    On 2002-12-02 14:37, Woody wrote:

    It's possible to replace the scanlines in GDI mode but it's going to slow it down an awful lot again. They haven't yet been implemented into the DirectDraw code but they should work fine in OpenGL. Odd.

    Aha! I was using DirectDraw, hence no scanlines. I swapped to OpenGL but I must have had the intensity level set to the extreme right, hence no scanlines showed!!!
    Scanlines are working fine now I've shoved the intensity slider to the left! :)
Sign In or Register to comment.