Activity for Zibri
-
Zibri created ticket #2021
[feature request] GLSL CRT shaders
-
yep.. now the list is full.. seems fixed in 46135. (and includes the pet me fonts)
-
for me it does not change behaviour if I run it multiple times. I installed the font it as you did. it appears in any other application including notepad.exe does not appear in vice list which contains only a few of the many fonts I have. and yes, all fonts are installed for all users but that won't matter since it's the current user that counts.
-
I did the same.. and as per my screenshot only a few fonts show up... (it happens only in vice.. everything is normal in other applications) Microsoft Windows [Version 10.0.19045.4170]
-
Vice windows font selection problem
-
doesn't work for me.. tried everything... I am now using 3.8 r45013 (it works in the version)
-
Monitor copy/paste broken
-
SuperSnapshot v1 and V2 don't work in VICE
-
not sure if a bug or a feature request...
-
Track 42 does *NOT* exist!
-
Track 0.5 exists and does not "bump"
-
Drive speed does not affect writing.
-
update: after further inspection (reconverting the g64 into d64 and comparing with the original) I noticed that the copy is completely wrong even with g64.
-
weird bug in D64
-
Windows MSYS2 compilation error
-
Memory leaks? worth checking...
-
I never said there were "unformatted track patterns according to the drive type" please read better my post. The speculation was about the cause. THE FACT taht the emulator generates random data on a non present track is a fact and not speculation. Please read again befor attacking me as usual.
-
please stop moderating my messages.. it makes it difficult for other people... anyway, I made the patch I wrote in the previous comments and it works. there is NO test needed, the routine rotation_1541_simple(dptr); is just to save cpu time but it breaks compatibility. Also: it's not true that vice ignores densities. And these programs (mine and the other), just read a number of bytes using bvc/clv and then calculates the time. Trust me... do this test: in vice source: sed -i "s/ rotation_1541_simple(dptr);/...
-
correction: this is how it should be: if (dptr->P64_image_loaded) { rotation_1541_p64_cycle(dptr); } else { rotation_1541_gcr_cycle(dptr); } without the "simple" routine.
-
Update: I found the solution: in src/drive/rotation.c just execute always rotation_1541_gcr_cycle(dptr); and it works everything also with D64. if (dptr->complicated_image_loaded) { /* stuff that needs complex and slow emulation */ if (dptr->P64_image_loaded) { rotation_1541_p64_cycle(dptr); } else { rotation_1541_gcr_cycle(dptr); } } else { rotation_1541_simple(dptr); } becomes a single line: rotation_1541_p64_cycle(dptr); and the routine rotation_1541_simple can be deleted.
-
on the u2/u2+ this is handled correctly and there is no difference in the output if ran from a D64 or a G64...
-
Unrealistic handling of unformatted tracks.
-
I agree. I looked at the code and it would be a major rework... Well the idea to use p64 internally could solve a lot of things.
-
Wrong handling of non-present tracks in disk images.
-
Conditional compiling problem
-
D64 density incorrectly managed.
-
it seems that also #$37 causes the same thing a c000 sei lda #$37 sta $1 jmp $c005
-
if you check the program in the first post.. I wait that the last FF is written then I wait the first 5A is written then I wait the second 5A is written then i disable writing. so ** TWO** 5A must be written..
-
the test program is my speed test! is exactly what it does. https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm.prg Please issue: poke 186,0 before running the program. The press F1. Track 36 will be created with all syncs and 2 5A inside. This works on real hardware too. I made a second version that does not trigger the bug: https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpmt.prg This because it writes 3 bytes and in this way it does not trigger U2+ and vice bugs.
-
something weird in 1541 writing...
-
Do you mind explaining to me then why at startup $01 contains #$37 and the tape runs if I press play without issuing any command? Perhaps I am wrong but I wish to know why then.
-
if $1 cotains #$35 the tape does not work.
-
the reason why this fails is that MSYS2 githib actions has a bug and svn/svnversion commands don't work in your comfigure and Makefile. I found a work-around for that. And in my version, both the 7z file both the version in the about menu is correct. The build works fine from windows.. the problem relies in github actions: specifically in: msys2/setup-msys2@v2
-
yep. the version in x64/x64sc is there... it's missing from the file name. I dug into it and I understood that the same compile script that works on my own pc, does not work on github actions because of a number of reasons: one of them is that the latest version of msys2 is flawed. also the one before. but before those they all work (even if updated). another problem is a big mess with paths. I spent a couple of hours studying the problem and I ended up doing something crazy: a nodejs oneliner wrapper...
-
both. usually mine because your compile options don't match my needs. also x64.exe is very useful because at warp speed it goes 3 times faster than x64sc.exe (which is good) If you only included x64.exe (and fix it with the latest x64sc patches, and a stable ffmpeg, than I would have no need to use my build.
-
revision number still missing
-
even x64sc --version gives only x64sc (VICE 3.7.1)
-
Please put back the revision number in the about menu.
-
It is producing perfect pulses with 50% duty cycle. $20 $40 and $60 and a pause at the start of about 2 seconds (the pause is not cycle accurate) the rest is.
-
sources are here anyway: https://github.com/Zibri/TapeTests
-
they are generating 20/40/60 in two ways: one starting putting 05 in $1 and then 0D/05 the other does the opposite. both cycle exact. and both work on a real datasette. nothing to reverse. pretty straight forward.
-
Tape implementation quirks...
-
Suggestion about tape wobbling simulation.
-
the problem seems gone in the latest releases... I saw no audio corruption and my settings are always the same... I didn't even reboot my pc in months.. so I don't know what it was.
-
Wrong default?
-
1) recording audio only is not pointells but can be useful for testing many things. 2) my windows laptop is 10 times more powerful than my linux one. On linux I didn't see this problem. 3) is not my job to fix your code. I would try to do it anyways if you were more kind. But at the moment I am busy with a different project. 4) I didn't make a bug report syaing it does not work right, I am saying the audio in the video is heavily distorted. Probably I overestimated many things or this comment would...
-
and removing things just because you are unable to fix them, says a lot about you :D
-
indeed.
-
so how to record a video from VICE?
-
not my program to fix. nice response. It says a lot about you.
-
Distorted audio when recording video
-
it stopped on LDA $C6 ! which has nothing to do with the watched range!
-
Monitor acts weird
-
so why if I put the emulator to 60hz (and my monitor is 60hz ) I still see it stutter?
-
yes.. sorry for the confusion.. 60hz option. (which stes the speed to 120% too) but I used the option.
-
off by 1 pixel on left border
-
P.S. Even setting VICE to 60hz (120% speed) it still stutters. (but way less) Apparently once every 25/50 frames.
-
P.S. Even setting VICE to 60hz (120% speed) it still stutters. (but way less)
-
P.S. Even setting VICE to 60hz (120% speed) it still stutters.
-
emulator in normal speed. monitor in standard speed (60hz) but AFAIK, 50hz on 60hz can be shown without stuttering. for example by inserting a black frame every 5. But there are other methods too.
-
emulator in normal speed. monitor in standard speed (60hz) but AFAIK, 50hz on 60hz can be shown without stuttering.
-
the scroller in Giana Sisters stutters even on a real C64 :)
-
VICE still stutters...
-
I checked and it seems the time the emulator is on is a factor... just run an instance of x64sc or x64 and leave it there for a few hours (or nighttime) then you will see... it happens constantly
-
please reopen this. this bug affects vice since long time and should be investigated. perhaps is a memory leak somewhere.. perhaps on sid or other things (with demos it happens very often)
-
the bug is present since long time and never resolved... I wantch many demos (sometimes using warp mode) and sometimes I leave the emulator in background (with warp mode on) not only sometimes the bug happens as I said, but other times when exiting windows shows a crash message.
-
just leave it running in the background for a while... then use turbo and reset it... it does not happen often.. only whan I work heavily with monitor and disks..
-
hangs sometims when resetting with turbo on.
-
nevermind... I rechecked.. it seems ok... the only problem I see now is that when issuing: M 0000 the content of locations 0 and 1 don't match the real one. should I open a new ticket for this? (C:$0090) r ADDR A X Y SP 00 01 NV-BDIZC LIN CYC STOPWATCH .;e5d1 00 00 0a f3 2f 37 00100010 301 000 2869083 (C:$0090) m 0 C:0000 bf 00 00 aa b1 91 b3 22 22 00 00 00 00 ff 00 00 ......."".......
-
update: the bug came back in full... no matter the content of $1
-
still messed up in version 3.7.1 r43952M (GTK3 3.24.38, GLib 2.76.3, Cairo 1.17.8, Pango 1.50.14) if in $1 there is #$35 and I go in monitor.. issuing BANK RAM still shows the rom.
-
confirmed... it seems working now...
-
a correction though.. this specific version never worked on the normal vice. I confused the file with another I have which works.
-
sourc e is the 10th anniversary collection on archive.org. iirc this works on WinVice SPS version. As a few other titles work on SPS version but not on the main one.
-
giana sisters original disk does not work anymore
-
monitor: banks messed up.
-
you can close this.
-
nevermind... I noticed this happens sometimes when I don't clean everything before compiling...
-
Closing X64/X64SC window = crash
-
perhaps my brain is off today, but as I recall, pressing PLAY on tape does nothing until the tape motor is started (for example issuing LOAD or SAVE)
-
TAPE motor messed up.
-
Another note: The above is true on RH, but 1C01 contents are different (shifted) depending on the VIA CHIP revision. I am still investigating the details making extensive tests on real hardware.
-
Erata corrige to the OP: ldy #$00 loop: CLV bvc * lda #$1c0f sta ($xx),y iny bne loop I get 256 bytes of raw data. That is wrong. On real hardware you will get always the same byte (the last one read from 1C01. UNLESS, you put $X0 in $1C0B putting 0 in bit#0 of 1C0B disables 1C01 latching.. so 1C0F will reflect in real time the read byte coming from the external shift register. adding LDA #$40 STA $1C0B before the above code, makes it work on real hardware, on vice, 1c0b is just ignored. (appare...
-
Erata corrige to the OP: ldy #$00 loop: CLV bvc * lda #$1c0f sta ($xx),y iny bne loop I get 256 bytes of raw data. That is wrong. On real hardware you will get always the same byte (the last one read from 1C01. UNLESS, you put $X0 in $1C0B putting 0 in bit#0 of 1C0B disables 1C01 latching.. so 1C0F will reflect in real time the read byte coming from the external shift register. adding LDA #$40 STA $1C0B before the above code, makes it work on real hardware, on vice, 1c0b is just ignored. (appare...
-
what I reported is the behaviour I see on a 1541 and 1541 II. that's all. and vice does not match that behaviour.
-
oh.. I forgot! THAT APPPLIES also to $180C and $1801/$180F! (it's the same chip!)
-
the latching mechanism is simple and bits #0 and #1 enable or disabe latching in both port A and B Reference: pages 5 and 8 of 6522 datasheet: https://www.princeton.edu/~mae412/HANDOUTS/Datasheets/6522.pdf
-
when latching is enabled (the default) 1C01 and 1C0F contain the first received byte after the last READ of 1C01. also: with latching enabled, reading 1C0F gets you the same byte in $1C01 but it won't trigger the unlatching. with latching disabled, both addresses will give you the last received byte, no matter if you read it or not. An example: with LATCHING on: I read 1c01 and get a byte... then I distract for a few minutes(!) and read again 1c01. I will get the byte AFTER the one read one minute...
-
VIA PORT LATCHING is wrong.
-
ok.. now I filled all my source with bits(VAR,16) it would be nice to have it as a default (perhaps an option) though...
-
label mix dec and hex
-
also: not all addresses are affected.. you should check a dump of a 1541 or 1541 II memory to be sure.. as soon as I can I will provide one if you need.
-
The reason is that the low byte remains hanging on the address bus and it's so read back (afaik)
-
@ME 0123 should issue "M-E" LO HI like in most cartridges and ML monitors.. Obviusly there are other way to do that, but G 0123 is not the same because it interrupts the dos operations... so every time I have to sitch to basic (if available) and manually issue: print#15,"M-E"+chr$(35)+chr$(1) (calls $123) try for example retroreplay cartridge monitor and you will see...
-
@ME 0123 should issue "M-E" LO HI like in most cartridges and ML monitors.. Obviusly there are other way to do that, but G 0123 is not the same because it interrupts the dos operations... so every time I have to sitch to basic (if available) and manually issue: print#15,"M-E"+chr$(35)+chr$(1) (calls $123)
-
@ME command in monitor does not work and crashes the emulator
-
Not a bug, but the init pattern in vice does not resemble this at all. Perhaps it would be nice to have a startup ram BIN file and an option to randomize it with parameters... About the ram chips, here they are..
-
here we go.. after some trickery I found a way to dump the full 64K or ram before the system starts and after a very cold boot.
1 >