| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
C64 Emulator Bugs
after stumbling about a bunch of VICE bugs myself in the last couple of days i have decided to compile a list with issues current emulators have. the goals for this are
- make people aware that emulators are by far not perfect (yet?)
- make it easier for emulator authors to improve the emulators, by showing problematic programs and possibly provide simple testcases
- allow c64 coders to implement emulator detection if desired
so well, check this: http://hitmen.c02.at/files/docs/c64/c64_emulator_bugs.txt
help welcomed :)
|
|
... 240 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 896 |
Actually, I think there should be 3 kinds of behaviour when loading a prg.
1) -> turn true drive emu off
-> use the directory on the pc as 'drive'
-> load the file from the 'drive'
-> basically the same as it is now, problem with cartridges (AR6)
2) -> put the .prg into a temporary .d64
-> keep true drive emulation ON
-> load the file from the temporaty .d64
3) -> simply dump the .prg into the memory (no loading!, actually much like CCS64 does it)
-> keep true drive emu on, but there's no disk in the drive.
Actually I would much prefer the 2nd method, since it is just way more close to a real c64 and stops you from having problems with cartridges/etc, which go b0rk with non-true-drive-emulation.
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
files should be dumped into mem, and true drive emu never turned off once the user requested it. the current behaviour is very frustrating. |
| |
WVL
Registered: Mar 2002
Posts: 896 |
Quote: files should be dumped into mem, and true drive emu never turned off once the user requested it. the current behaviour is very frustrating.
that's method 3 then ;)
Anyway, i can see how option 1 is nice for some ppl, but frustrating for others.. Why not have 1,2 and 3? :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
the most frustrating thing imho is that even when you attach a d64, vice will toggle TDE off/on (so it can cheat on loading the first program). so when i run vice with "x64 bla.d64" and then hit "reset" in ar menu, i end up with TDE switched off (although its enabled in the vice config). that sucks hard. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote: the most frustrating thing imho is that even when you attach a d64, vice will toggle TDE off/on (so it can cheat on loading the first program). so when i run vice with "x64 bla.d64" and then hit "reset" in ar menu, i end up with TDE switched off (although its enabled in the vice config). that sucks hard.
Then why don't you disable virtual device traps? |
| |
cba
Registered: Apr 2002
Posts: 935 |
Not working in VICE Vision |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
Quote: Then why don't you disable virtual device traps?
because then ONLY d64s will work as expected. i did this a while ago and then it took me a week to figure out WHY THE HELL autostarting t64 and prg doesnt work anymore. (infact, they would not work anymore at all)
like i said before, leave the autostart setting alone. for fast initial loading, toggle warpmode on/off, that would probably be almost as fast, and has zero compatibility problems.
whatever - what really kills me is that such whacked up behaviour ends up beeing the default, and even more, it can even not be switched off at all!. whoever had the bright idea to do it like this should be slapped left and right and in the middle with an extra punch =P |
| |
cba
Registered: Apr 2002
Posts: 935 |
Block Out
bugging in VICE |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote: Block Out
bugging in VICE
It doesn't work in HOXS v1.0.5.8 either.
But I didn't test on TRM (The Real Machine ;-) ). |
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
Quote: Block Out
bugging in VICE
"1541 CPU: Jam in $1200" is normally caused by a BRK encountered during drive
code execution. The loader at $4c00 does a "M-E" $07c0, but there's NO code here.
Just try OPEN1,8,15,"M-E"+CHR$(192)+CHR$(7) and you'll get the same Vice error.
At $0700-$07ff in drive RAM there should be the current BAM (trk18 sect00) and
the loader assumes that on the slack space after the disk name there is some code,
but this d64 is cleaned from extra bytes.
(8:$07c0) m 700
>8:0700 12 01 41 00 15 ff ff 1f 15 ff ff 1f 15 ff ff 1f ..A.............
>8:0710 15 ff ff 1f 02 00 20 02 00 00 00 00 00 00 00 00 ...... .........
>8:0720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:0730 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:0740 00 00 00 00 00 00 00 00 0f 6c ff 07 00 00 00 00 .........l......
>8:0750 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:0760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:0770 00 00 00 00 00 00 00 00 00 00 00 00 09 55 55 01 .............UU.
>8:0780 11 ff ff 01 11 ff ff 01 11 ff ff 01 11 ff ff 01 ................
>8:0790 54 41 4c 45 4e 54 45 44 20 52 55 4c 45 52 5a 21 TALENTED RULERZ!
>8:07a0 a0 a0 2d 42 4f 44 2d a0 a0 a0 a0 00 00 00 00 00 ..-BOD-.........
>8:07b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:07c0->00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:07d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:07e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>8:07f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
The original code most probably just loaded the rest from the free sectors
in trk18, which are clean too. Recovering this disk is impossible unless the
exact same loader was used and known in another crack.
There are many not working cracks for the same reason, sectors on track 18
carelessly cleaned or even not copied during the dump process. Whole disk
copy on these disks is needed.
|
| Previous - 1 | ... | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 - Next |
