Joined: 11/27/2017
Posts: 86
Location: United Kingdom
This core is extremely inaccurate and probably only about 50% finished. I would not get your hopes up too much.
I need to try and find time in the next 12 months to re-write the CRTC chip emulation and make the tape loading work properly.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
I think it has it's own software and adds a border around the screen for position detection. Perhaps it will just work out of the box with bizhawk and act as a mouse device?
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
cambalinho wrote:
my real problem is only the loading game.. needs more than 5 minutes... and i need avoid it :(
You will need to get a *.dsk image of the game (if it exists) and run this under the +3 model. That is the only.way (apart from speeding up the emulation) to get games loading quicker. Well, other than using another emulator.
One day we might get accelarated tape loading and generic snapshot loading implemented. But if/when that happens it will strictly non-deterministic and for casual use only.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
Fortranm wrote:
Link to video
Trying to load Kong Strikes Back by Ocean Software ends up in a reboot, as shown around the 2:40 mark of the video. This happens on both 2.3.0 and the newest developer build as of now.
The re-release by Zafi Chip can be loaded, however.
This is now fixed in the latest dev. But will probably cause desyncs with earlier movies.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
Sonia wrote:
I'm thinking what's causing it is the fact I don't have the right hash for bios_test:
it's the only one that's missing out of the five. None of the bioses you shared above matches it. Could you upload a .zip containing only the right bios_test and nothing else?
I don't see the SHA1 hash (B398CFCB94C9F7E808E0FECE54813CFDFB96F8D0) for this test bios anywhere in TOSEC and a google search returns no results. Perhaps a typo still in the dev branch?
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
DrD2k9 wrote:
For others who may be curious. I've already completed a TAS of this, but there's something wrong with ZX emulation in BizHawk that results in the game's music not playing...I'm delaying submission until this problem is solved (a bug report has already been submitted).
This should now be resolved in the master branch (dev build). With any luck the changes wont have caused any desyncs, but that all depends on whether the game is trying to read from the AY register on the same (some might say non-standard) port that it is trying to write to. This seems unlikely, but check for desyncs anyway.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
TheGreatHadoken wrote:
I just want to know what the default method of pressing play on the virtual tape is, for the C64 core. Thanks.
I believe the emulated tape 'drive' motor is emulated as well. It should automatically 'play' when you type the right commands:
http://tasvideos.org/Bizhawk/C64.html#Tape
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
Warp wrote:
I believe it's achieving this by estimating when the cathode ray is on either side of that central area, and then it just changes the colors for that horizontal row of color blocks. This essentially makes that central area consist of 8x1 color blocks.
There is no need for the game to estimate where the the beam position within each frame. It is always in the same place from a Z80 T-State perspective each frame (although this differs between the various spectrum models). There are quite a few games and scene demos that makes use of this timing knowledge to achieve cool stuff. Removing colour clash etc. The 8x1 attribute stuff has been known for a while:
https://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes#%228x1%22_attributes
On other Spectrum models, this effect can be replicated by exploiting the fact that the ULA re-reads the attribute information on every pixel row when generating the video output; it is possible to write a new value to the relevant memory location in between successive lines, and thus cause a different pair of colours to be shown. However, the Spectrum's processor is not fast enough to write to an entire row of attribute bytes in one scanline, so 8×1 attributes can only be achieved over 18 columns. This technique is variously known as Hicolour, Multicolour, FLI or Rainbow Processor mode.
Details:
Pixels: 256 × 192
Attributes: 32 × 192 (limited to a 18x192 area)
Colors: 15
This would explain the 'thin' display for the game, although they have really done something special to get scrolling working as they have.
The author gives some insight into the engine he wrote to achieve this:
https://spectrumcomputing.co.uk/forums/viewtopic.php?t=1079
It's an 8x1 multicolor + pixels scorll :) So a camera can move with any speed, even with 1 vertical pixel without any clashing.
It's my own engine and it works on 48k,128k and pentagon.
- Do you scroll the attributes by jumping into the middle of the drawing loop at different offsets?
Nope, attributes drawed from linear buffer and all an "engine" it's unrolled ..... pop hl: ld (addr),hl ..... mostly :) The multicolor zone not a big, just an 12 cells width, tower walls drawed without multiclor but gives an illusion of 14 cells width. In a top border we draw a top 110 lines of pixels from previous frame before beam. During a multicolor loop tower walls drawed + multicolor. After multicolor we draw an new frame for 50 botom pixel lines after beam so in a next frame we have a picture.
Its *very* well done.
In fact, its this sort of thing that caused the development of ZXHawk (and the associated Z80 accuracy fixes) to take so long. We had to get it writing to the screen buffer at exactly the same cycle in a frame as on real hardware. This is also why ZXHawk is a bit more resource heavy than many of the other cores.
Its nice to see that a game like this, that is so intrinsically tied to real hardware timing, plays correctly in Bizhawk :)
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
EZGames69 wrote:
I just dislike how most ZXS movies are going to be 60% loading time. But ohwell, that’s just how the system works.
There are some pretty good commercial +3 games on disk. But most of them are movie tie-in/coin-op conversions that don't stack up that well against other systems of the time.
Its pretty easy for homebrew makers to release games in disk image formats as well these days (see spectral interlude). There is just no reason for them to go the extra mile. Every other emulator implements instant tape image loading by pulling the tape data directly into the CPU registers and memory (thereby bypassing the actual tape loading mechanisms).
I do eventually plan to work this out and implement in bizhawk. But obviously this is certainly a non-deterministic thing and wouldnt be any good (in fact would be automatically verboten) for TASes anywhoo.
Would certainly be of benefit to casual play though.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
EZGames69 wrote:
Do any of these versions contain less loading time for bootup? I wonder if it’s worth using them for this tas simply for convience of the viewers.
Its a standard tap file, so I could probably shunt it into a +3 disk image (*.dsk). However, this involves modifying the loading routines in the code so it knows to load from disk rather than tape.
A potentially murky area maybe.
The game supports multiplayer for 2 players, which is less than on Arcade version, on same screen both in cooperative mode and competitive one.
To play competitive mode, just select "Versus" mode. The game will be played in few rounds, arenas changing slightly. Each player has a health bar and much lower rate of fire than in normal game, while a bird periodically coming in to drop extra items. Players have to shoot each other down in this mode.
To play cooperative mode you can either select "2 Players" mode or start the "1 Player" game and press Start on controller of the second player. Though the first method is preferable, as it doesn't take away a continue point. There is no friendly fire and continue points are shared.
However, due to bug, if both players have Six Button Control Pad then "Versus" and "2 Players" modes will not be selectable, despite being higlighted in menu. Another player can still join during "1 Player" mode play. Hold Mode button when booting up the system to switch to 3 button mode and fix this issue.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
I think those panels can be resized.
Make the TAStudio window bigger, then mouse around until the cursor turns into the resize cursor and try to make them bigger.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
Yeah, thats not gonna work. Your bin is compressed as ECM. There a tool available somewhere on the internet called Unecm.
You need to download that tool, and drag your bin file onto it. This will extract the bin file to its uncompressed format.
You then need to edit the cue file in notepad and make sure the first line is referencing the name of the newly extracted bin file.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
Is the referenced bin file inside the cue file (it is just a text file you can open in notepad) named exactly the same as the actual bin file? Maybe post the filename of your bin file, along with the contents of your cue.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
Fortranm wrote:
Trying to load Kong Strikes Back by Ocean Software ends up in a reboot, as shown around the 2:40 mark of the video. This happens on both 2.3.0 and the newest developer build as of now.
The re-release by Zafi Chip can be loaded, however.
I'm still trying to work on this. Speedlock 1 can be pretty temperamental as a tape encoding scheme, so there is probably just one pulse level that is inverted or something.
It's gonna take a while though, the datacorder code is a mess and I should probably redo/refactor it to better understand the bug.
Joined: 11/27/2017
Posts: 86
Location: United Kingdom
phoenix1291 wrote:
Try to laod Santa's Xmas Caper +3 disks (The version from World Of Spectrum (2 sides)).
Thats a tape master disk(s) so probably in a propriety format (as the exception message suggests) that ZXHawk doesnt support (yet).
Also, if you could get that disk to work, it probably only contains routines to write the data to tape.
it's the only one that's missing out of the five. None of the bioses you shared above matches it. Could you upload a .zip containing only the right bios_test and nothing else?