d802tap: when direntry and clusterchain file lengths do not match use
- check timestamp of input file and if it is changed, reload the file
tap2d80: fill name of newly created image on a right place, not to be
optimization to fix delay of attribute highlighting on slower machines with big scale (e.g. -scale 5)
bin2tap: new option "-n <name>" to have possibility to define a spectrum
workaround for an incorrectly terminated clusterchain by 0xE00 instead of 0xC00
highlight also black colour (at least a bit)
safety change to prevent off-by-one bugs
fixed bug of overwriting screen
make im2 keyboard routine a bit smaller
updated copyright messages
added possibility to choose serial port and communication speed
mikezt's improvement on keyboard reading
tap2d80: added switches -l, -i and -a
Silence two warnings when building with clang.
patch applied in rev. r58, thanks
patch applied in rev. r58
Silence two warnings when building with clang.
lstrd cleanup:
ticket #11: Silence two warnings when building with clang.
fix for images with smaller fat than 4 sectors
Hi, thanks for the test. Now I've found there is also break of the execution loop in case of rzx end of frame. Here is changed patch (also with comments we discussed earlier removed). To me with this patch, Arithmetic Tutor works.
hi, if you are ok with the patch (the way how the issue is fixed) then i would maybe leave there just one comment, which is describing purpose of the return value. so to remove: +//static libspectrum_byte opcode2 = 0x00; +// libspectrum_byte opcode2 = 0x00; +// opcode_delay: +// run_opcode: leave in code: + return 1; //to exit execution loop in z80_do_opcodes() do you want me to create new patch or it is enough to describe it like this?
small modification of previous patch, I forgot that from "evenm1" check should be possible to exit execution loop and with previous patch it would only exit from "evenm1" check and execution will continue.
I've made second patch, which should work for every device This patch works as I wrote at the end of the ticket description just with a small change. Instead of having 2 functions I've put it to one with parameter describing which part should run.
incomplete emulation of /M1 of CPU
fix for ticket #5 "False error message in d802tap".
ok, after a lurking into a gtk sources, i've created a new patch. I agree that changing order of buttons on widget is not a good idea. You wrote that OK button is set as default button. But for me it seems it is not so as there is no gtk_widget_set_can_default() call at all. After applying this patch enter works as I would expect it to work.. when Cancel button is selected, enter will cancel the dialog, when OK button is selected, enter will accept the dialog and when none of buttons is selected...
but then fuse is not respecting default behaviour of GTK application (cancel the action, when "cancel" button is selected on enter pressed). exactly what original poster wrote
I'm not sure what is expected behaviour of Enter in GTK+ applications, because for example Gimp respects selected button when Enter is pressed. At least in "Layer->New Layer" menu. I've opened it and then kept pressing TAB until "Cancel" was selected. Then I pressed enter... no new layer was created... Maybe 'OK' is default action when Enter is pressed, but not when 'Cancel' button is selected.
I have two things to consider.. I would maybe also change the order of "Cancel" and "OK" buttons to make "OK" selected by default (in SDL it is also like that) Second thing is, that later I have found that using this patch will make Machine->Select menu less intuitive. After selecting machine it is needed to press TAB to activate 'OK' and only then is possible to press enter to select new machine type (which would be then different to SDL ui, where there are no Cancel and OK buttons and choosing...
fixed few misleading indented printf
cleanup:
0tobin shorten output name
for long filenames is needed to use -l switch
dirtap crash
dirtap crash
thanks, fixed in rev. 30
fixed double fclose() in dirtap.c (ticket #2)
tap2mbd not 64-bit safe
tap2mbd not 64-bit safe
thanks, fixed in rev. 29 (also for tap2mbhdd)
fixed tap2mbhdd on 64bit machines (ticket #4)
fixed tap2mbd on 64bit machines (ticket #4)
maybe that difference of 416 tstates is also caused by some typo (once I got 516 tstates difference for non-accelerated load) because routine (without contention) should take 475T (and with contention it could be more, but not less). I got quite different Tstates length of the subroutine in one loading. I got also 475T for non-accelerated load and also I got bigger difference than 475 for accelerated load (if subroutine was called when value of tstates was small, routine took 475, but when tstates...
Hi, I've also tried this: diff --git a/loader.c b/loader.c index aca6f5dd..1f8a5de3 100644 --- a/loader.c +++ b/loader.c @@ -72,6 +72,8 @@ loader_tape_stop( void ) static void do_acceleration( void ) { + static int expected_state = 0; + if( length_known1 ) { int set_b_high = length_long1; set_b_high ^= ( acceleration_mode == ACCELERATION_MODE_DECREASING ); @@ -84,10 +86,13 @@ do_acceleration( void ) z80.pc.b.l = readbyte_internal( z80.sp.w ); z80.sp.w++; z80.pc.b.h = readbyte_internal( z80.sp.w );...
I've analyzed it little bit more and it seems to me, that there are some edges "lost" when acceleration is on. it seems to me they are "consumed" by standard event being fired, not by accelerator code (maybe the reason is that routine to animate eyes, which takes more than 470 Tstates). so I tried this change: diff --git a/loader.c b/loader.c index aca6f5dd..e2f8b7c8 100644 --- a/loader.c +++ b/loader.c @@ -85,7 +85,7 @@ do_acceleration( void ) z80.pc.b.h = readbyte_internal( z80.sp.w ); z80.sp.w++;...
the loader used in the game is quite standard rom loader with the same constants and only a few differences to rom loader: 1) different colors of stripes (so some constants are different, but these are not that important) 2) bits loaded to memory are ordered in opposite direction (so if on tape is byte 0x3A then to memory is stored 0x5C) 3) every now and then is executed some routine stored at 0xFED3 - this I expect is to animate eyes while game is loading points 1 and 2 are not that crucial, but...
libspectrum rzx write header: minor version is missing in output when using GCRYPT.
I'm not sure whether this is bug or feature. Enter acts as hotkey for "OK" and Escape for "Cancel". Not just on reset (F5) dialog but also on exit (F10). in any case, feel free to use this patch.
ok.. knowing nothing about tc2068 i thought it is similar to 128k, as there are two roms. but i missed that second rom is only 8k. when i noticed it i run debugger to localize loader routine. then i disassembled it and found out that there is the same bug as in 48k routine. I also tested loading tape with zero sized block without having loading traps on and i got 'R Tape loading error'.
Back to you earlier question regarding other zx clones. I checked out some older revision from svn, when there were still 128p and 256s roms: $ svn co svn://svn.code.sf.net/p/fuse-emulator/code/trunk/fuse/roms -r 4325 $ for i in roms/*.rom; do dd if=$i bs=1 skip=$(( 0x4c2 )) count=$(( 0x9a1-0x4c2 )) 2>/dev/null | md5sum | tr '\n' ' '; echo $i; done | sort [...] ee4f4a30db9dde33f64e77f2d78284dc - roms/128-1.rom ee4f4a30db9dde33f64e77f2d78284dc - roms/128p-1.rom ee4f4a30db9dde33f64e77f2d78284dc - roms/256s-1.rom...
aha. so then the question if to check the whole loader to emulate bug is quite valid (and maybe not just to emulate bug but also to use trap) as maybe it is not enough to check just entry point instruction. the tape trap function sets also registers to specific values (depending on the tape content and registers on entry) and also returns through specific loader return routine.
well.. if we want to be that precise, then we need to think about different question: shoud we use tape traps if there is custom (unknown) rom loaded? tape trap code is written to emulate loading by original rom and if you have some custom rom, there might be completely different routine on the tape entry point. so maybe in the case of custom rom tape traps should be disabled completely (or after checksumming loader or so). and so, if tape traps are disabled, bug is not needed to be emulated (anyway,...
I checked roms in spectrum-roms package in debian. first of all I tried to get list of 48k parts from different romsets. i did it by comparing first 16 bytes of roms: $ for i in /usr/share/spectrum-roms/*; do dd if=$i bs=16 count=1 2>/dev/null | hexdump -Cv 2>/dev/null | head -n 1 | tr '\n' ' '; echo $i; done 00000000 f3 01 2b 69 0b 78 b1 20 fb c3 c7 00 00 00 00 00 |..+i.x. ........| /usr/share/spectrum-roms/128-0.rom 00000000 f3 af 11 ff ff c3 cb 11 2a 5d 5c 22 5f 5c 18 43 |........*]\"_\.C| /usr/share/spectrum-roms/128-1.rom...
Incorrect emulation of tape loader routine for zero sized block
added possibility to pad parameters by spaces (...
fix: final message printed length of 0 bytes ev...
bin2tap: added -x switch to manpage
new utilities: lstrd createtrd hobeta2trd
added possibility to set third address in bytes...
Alberto, it is not a bug that you cannot load the tape. The bug is if you can load...
Alberto, it is not a bug that you cannot load the tape. The bug is if you can load...
Answer for tap file is here: 0xFDB4 DD 21 1C FB LD IX,0xFB1C 0xFDB8 21 15 00 LD HL,0x0015...
Answer is here: 0xFDB4 DD 21 1C FB LD IX,0xFB1C 0xFDB8 21 15 00 LD HL,0x0015 0xFDBB...
Answer is here: ` 0xFDB4 DD 21 1C FB LD IX,0xFB1C 0xFDB8 21 15 00 LD HL,0x0015 0xFDBB...
Fix for tzxlist "Total tape duration"
src/tap2d80.cpp: fix: wrongly set length of dir...
This problem is present also on trdos 5.03 http://cygnus.speccy.cz/download/romky/trdos503.zip...
Broken trdos emulation when using TR-DOS_5_05.rom
tape hooks to check CARRY flag
just a cosmetic change to diff.i8255_01c.patch. i'd change ret = joystick_kempston_read(...
why is there "if( settings_current.joy_kempston )" in case of reading from port C...
I don't have D40/80, but I have interface with 8255 on the same ports (schematic...
Hi, just for more completeness, I analyzed this "issue" more as I thought it is a...
ok, successfully crosscompiled fuse for windows just small change to patch (new patch...
joystick buttons cleanups
added /invite command