Forget about the RAM cause, don't think the disk ram could be the reason.
Sorry this was meant for C64 not Amiga :(
[Feature request] Disable Fast Loader for PRG autostart
Thanks for the link and it works like a charme :D Tested: 1) Configuration with 8 SIDs and "the-tuneful-eight.prg" runs the program after loading the configuration with autostart switch "PRG" active. If there is a disk in drive 8 and / or a tape configured these are ignored as it should be. 2) GEOS configuration with Super CPU + REU and "geos-supercpu.d64" in drive 8 perfectly boots into GEOS after loading the configurarion with autostart switch "Disk" active. If there is a PRG selected and / or...
nightlies Windows Mac
Denise Nightly are only for Linux (flatpak) (?). I would like to test the new feature but I am Windows user.
[Feature request]
[Feature request]
in latest nightly there is a autostart selector in configuration layout
Maybe... maybe not. It depends on many factors, such as the software. It's possible, but it needs to be tested first. Until then, you should be patient.
In addition to my previous comment: if I start the demo in Denise after a reset with a port set to unassigned, the demo keeps running correctly. If I then assign a port in Denise while the demo is already running, the demo immediately detects the newly connected joystick, even without any reset, and exits prematurely. This seems to confirm my conclusion that no reset should be necessary when a port in Denise is changed to unassigned.
The only thing I would still really like to know, from an emulation point of view, is whether a real Amiga detects the removal of a joystick from a port without requiring a reset, and then releases the signals on the POT pins. If that is indeed the case, then this demo should also work after the port has been set to unassigned in Denise. Hopefully, someone can test this on a real Amiga and leave feedback here, so that Denise can provide even more accurate emulation if needed.
Update: I now see that, with other Amiga software, unassigning a port does release the joystick inputs. So please ignore my question. It is clearly a quirk of this particular demo. Sorry for the inconvenience.
I think my question was unclear. I am not asking about the physical location of the pull-up resistors in a real joystick. I am talking about Denise’s behavior when a port is changed to Unassigned. My expectation is that, as soon as a port is set to Unassigned, Denise should immediately remove the emulated joystick input from that port and return the input lines to their disconnected/idle state. No soft reset or hard reset should be necessary. Right now, Denise seems to keep the previous joystick...
does a real Amiga release the pull-up resistors as soon as a joystick is disconnected The resistors are located inside the joystick, and when you unplug it, they are naturally inactive.
does a real Amiga release the pull-up resistors as soon as a joystick is disconnected The resistors are located inside the joystick, and when you unplug it, they are naturally inactive.
My question, @PiCiJi, is this: does a real Amiga release the pull-up resistors as soon as a joystick is disconnected, without requiring a reset? If so, then Denise should also release the pull-up resistors immediately when a port is changed to unassigned.
Connect a 2-button Amiga gamepad or joystick. It must be a 2- button joystick with pull-up resistors, otherwise, the demo will run without problems. You can tell the difference because a normal 2-button joystick won't work with all 2-button games, such as B.C. Kid or Lionheart. The WHDLoad versions of these games may be modified to work with a standard 2-button joystick. Therefore, the ADFs should be tested.
Could you please test this on a real Amiga 500? Connect a 2-button Amiga gamepad or joystick. Then disconnect the gamepad or joystick. Do not reset the Amiga. Run the demo. Does the demo still run correctly on the real Amiga? If not, then the current Denise behavior is correct. If it does run correctly on a real Amiga, then the Denise implementation still needs to be modified so that, after disconnecting the joystick (that is, unassigning Port 2) without resetting the Amiga, the demo also runs normally...
Nice! This is the better solution, in my eyes. Last question - a real Amiga500 machine shows the same behaviour, when this demo is started and a 2button-gamepad is connected, I guess? And disconnecting the gamepad then also solves the problem there? (can not try it by myself at the moment, because my real Amiga is currently broken. Unfortunately). By the way. In this context I remember, that some 2button Amiga-games behaved a bit strangely back then. I had a 2button Amiga-gamepad for my A500 at that...
Yes @Retronic-Design. Denise uses 2 button joysticks with pullup resistors. read here for more info
Yes. Denise uses 2 button joysticks with pullup resistors. read here for more info
I don't believe this behavior is a bug in this demo. Furthermore, it behaves exactly the same way in WinUAE.
Hi! Joystick detection in Turrican 3 works fine in denise_win64_build_dc7362e.zip.
Hy. I've used Denise a lot in the last few months, it's a great emulator. Just one short question, regarding this bugreport here. The disadvantage in some games, which is described above in these 'possible solution 2' for example in the game Turrican 3 (detection is slower) is not currently present in the emulator now, because this solution-path was finally not chosen and this problem was solved in another way then, right? Regards, Retronic-Design
Interesting thing, with this demo. What I ask myself in this context is, how does a real Amiga, for example an Amiga 500, handle this thing, when you're running this demo on it, while a 2-button-gamepad is connected to the A500? Does this gamepad also need to be unplugged then, for this demo to run smoothly? Because if so, then it's no problem, if Denise does it the same way. The users just has to try and figure out the cause of the problem by themselves, with this demo, just like they had to back...
I just created a SourceForge.net account, so I am no longer shown as Anonymous on ticket #141.
Notable behavior: as soon as I reconnect the disconnected joystick and then again disconnect it, the demo still assumes that a joystick is connected and exits prematurely. Apparently, without a reset, Denise does correctly detect when a joystick is connected to any port, but it does not detect when it is disconnected. Only a soft reset or hard reset immediately after disconnecting the joystick causes the demo to display correctly.
Confirmed, bug fixed with denise_win64_build_dc7362e.zip.
in latest nightly it should work when Joystick is unplugged from Control Port 2
Thank you very much for your detailed investigation!
The problem here is the POT emulation for detecting the second button (joystick/mouse). It should work if the joystick is unplugged. Currently, this isn't the case in Denise. [BUG] will fix it soon. Unfortunately, the input detection in this demo is flawed. This causes a joystick with two buttons and pull-up resistors to trigger the problem. Denise emulates such a joystick even if the second button is not configured. possible solutions: If the second button isn't mapped, treat the joystick like a...
The problem here is the POT emulation for detecting the second button (joystick/mouse). It should work if the joystick is unplugged. Currently, this isn't the case in Denise. [BUG] will fix it soon. Unfortunately, the input detection in this demo is flawed. This causes a joystick with two buttons and pull-up resistors to trigger the problem. Denise emulates such a joystick even if the second button is not configured. possible solutions: If the second button isn't mapped, treat the joystick like a...
Correction in descritpion. No crash, demo just exists just before upscrolling lext is supposed to start.
Amiga Demo Space Demo by Mad Monks (1988) crashes after bouncing box
I have tested with latest nightly build, the issue appears to be fixed. The memory display is now consistent across full ranges. Thanks!
Thanks for the quick response! I’ll test it as soon as the next nightly build is available.
should be fixed in latest nightly
Good find, thanks. Something seems to be wrong with the update. I'll fix it.
Debug Monitor shows inconsistent RAM contents compared to actual memory (SMON verification)
Debug Monitor shows inconsistent RAM contents compared to actual memory (SMON verification)
Created by mistake, please ignore.
Created by mistake, please ignore.
Debug Monitor shows inconsistent RAM contents compared to actual memory (SMON verification)
Debug Monitor shows inconsistent RAM contents compared to actual memory (SMON verification)
Debug Monitor shows inconsistent RAM contents compared to actual memory (SMON verification)
Problem with 1581-drive floppy sound
Fire King glitching up
We're talking past each other. It works perfectly fine as I described. If you find "0" confusing, use "c". Then it will match the game's internal labeling. But exactly this, some users wanted to have in this eab.abime thread. Look here, for example: https://eab.abime.net/showpost.php?p=1754735&postcount=578 That's not the intended purpose of the function, but rather a circumstance that has arisen. However, in your previous post, one got the impression that you were reducing the function to that....
Fire King glitching up
We're talking past each other. It works perfectly fine as I described. If you find "0" confusing, use "c". Then it will match the game's internal labeling. This is exactly that nonsense, I wrote about and it seems, that the latest changes in the search-mechanism, was made because of such useless suggestions and because of these latest changes, we now have the problems with bootdisk-software. That's not the intended purpose of the function, but rather a circumstance that has arisen. However, in your...
"""What exactly is your problem? Are you bothered by the file order in File Explorer? It works perfectly fine with Disk "0" or "C" in the filename. We're somehow talking past each other.""" The problem is quite obvious, isn't it? In this "California Games" diskset, the bootdisk is actually the third disk in the set, and the game naturally requires this disk number, in the gameplay. If I name this bootdisk "0," then the disk-number sequence is no longer correct, because it's then the first disk, since...
because then this disk "0" is the first disk of the set in the disksearch-mechanism ("0" is before "a" (and also before 1, if numbers were used)), but it must be the third disk, because normally this disk is disk 3 (or disk c, if you use letters) What exactly is your problem? Are you bothered by the file order in File Explorer? It works perfectly fine with Disk "0" or "C" in the filename. We're somehow talking past each other. Or you're seriously claiming, that it's normal and makes sense for someone,...
because then this disk "0" is the first disk of the set in the disksearch-mechanism ("0" is before "a" (and also before 1, if numbers were used)), but it must be the third disk, because normally this disk is disk 3 (or disk c, if you use letters) What exactly is your problem? Are you bothered by the file order in File Explorer? It works perfectly fine with Disk "0" or "C" in the filename. We're somehow talking past each other. Or you're seriously claiming, that it's normal and makes sense for someone,...
Around 15 games and demos I have, that have a bootdisk. And I think it's very obviously, that it don't work correctly, when you rename one disk of this "California Games" diskset to "California Games - 0", because then this disk "0" is the first disk of the set in the disksearch-mechanism ("0" is before "a" (and also before 1, if numbers were used)), but it must be the third disk, because normally this disk is disk 3 (or disk c, if you use letters). Of course you can switch between all these three...
I already thought about this, at the beginning, before I even reported this problem here. But only replacing '(boot)' with '0' would only work for such bootdisk games (or demos), in which this bootdisk really is the first disk of such a software. But as we already know, there are also games, in which this isn't the case (for example my 'California Games' disks) and here this would not work. Therefore this is also not a real solution. if one is not willing to compromise... How much software with a...
I already thought about this, at the beginning, before I even reported this problem here. But only replacing '(boot)' with '0' would only work for such bootdisk games (or demos), in which this bootdisk really is the first disk of such a software. But as we already know, there are also games, in which this isn't the case (for example my 'California Games' disks) and here this would not work. Therefore this is also not a real solution. if one is not willing to compromise... How much software with a...
One could perhaps do it, by including the information, that the third disk is the bootdisk, in the name of all disks of such a software: California Games (boot from third disk) - 1.d64 California Games (boot from third disk) - 2.d64 California Games (boot from third disk) - 3.d64 At least, this would work, without needing an external txt-file that includes this info. But it looks really stupid, that would be the disadvantage. Best regards, TOM
I already thought about this, at the beginning, before I even reported this problem here. But only replacing '(boot)' with '0' would only work for such bootdisk games (or demos), in which this bootdisk really is the first disk of such a software. But as we already know, there are also games, in which this isn't the case (for example my 'California Games' disks) and here this would not work. Therefore this is also not a real solution. I go on reading in this linked eab.abime.net thread and it's really...
Both topics had to with the same game (Fire King). That was the reason, why this new problem was found. I think in such a case, it's not a problem, to describe also this new problem, when it had todo with the same game.
The best thing to do is replace "boot" with 0. Then it should work. I would advise against further modifications for now, as something else will probably stop working. This is a good application for AI. It could be trained on all naming conventions with the goal of eliminating the need for anyone to rename their files.
Guys, it's strange that no one found it inappropriate for a user to talk about a completely new problem in a topic where a completely different problem has been solved? Shouldn't a new topic be opened in such situations?
Which other useful combinations are working now in the search-mechanism and before (let's say in Denise V2.4 or V2.5) not? Can you give some filename-examples for this? I would really be interested to know, especially when it comes to 'useful' combinations and not things like, mixing together zip-files and d64-files of the same game, that have exactly the same name, in the same folder, because things like that, are definately not useful and I read about such things, in the thread in Forum64 some...
I followed this link and this is an old message from June 2025 and at that time, I am sure it still worked with the word (boot) in the filenames, otherwise I would have noticed it already. And this is also described to work, when having a look at the shortmanuals which are linked in the Wiki area, here on the website. And I followed this description, when I renamed all my hundreds of C64 files back then. I think when it's even described this way in this manuals, that can be downloaded from this website...
Here's what the developer already had to say on the subject, quote from: https://eab.abime.net/showpost.php?p=1750925&postcount=563 "A lot of attempts have been made in the past. Most of the time it ended up solving one problem and without knowing it creating another. If you want to use this feature reliably, you should be prepared to rename some files beforehand. Or we can find an AI that could certainly be used here."
Guys, calm down a bit. In my opinion, this is not a problem at all. So what if it used to work with (boot) in the file name and now it doesn't. The important thing is that it works well with many other combinations now, which wasn't the case before. But let's hear what the developer has to say, I'm really interested. If he has the will to "fix" it, which I doubt, then let him fix it. I wouldn't because there's no need and there's a risk that something else will break in the process, which I doubt...
Why is it considered 'nag' when another user reports a bug? What kind of nonsense is that? And it also doesn't complicate things, if a newly introduced bug will be fixed again. I've seen this a few times here now and I think it's disgusting. In my opinion, answering the reports here, should be left to the developer and not to other users, who don't like some suggestions or bugreports. Cheers, Tobias
Hi. I think, the developer can ask by himself and not any retrofan should do answer the questions here in the bug-area. And why should txt-files be inserted between d64 and prg files now, just to give an info, that could always be inserted directly in the filename before, without a problem? Makes absolutely no sense. If a bug has crept in, as is obviously the case here, then it should be fixed, as is normal.
Hi, I don't think there is any need to complicate and nag the developer about the same because it might cause some other problems which have been solved in the meantime. What I would do in that sense is delete (boot) on the disk itself and create a .txt file with (boot) next to it just in case the first disk is not bootable like for example: Instead of: California Games - c (boot).d64 It would be: California Games - c.d64 California Games - c (boot).txt Regards
Back home again and I tried "Fire King" in the meantime (the version from GameBase64) and now it works, like it should. Also when something is written to the first scenario-disk, the game can load from this disk again afterwards. Problem solved. But while testing this game, I found something else, that has worked in older versions of Denise, but not in the current version and it has todo with the following thing. This "Fire King" game here, has a boot-disk (like some other C64 multi-disk games or...
The latest nightly build includes a graphical debugger for C64 and SuperCPU. floppy CPU is not yet included.
[requested] Shaders.
Contact
CRT file unsupported
How can I switch the emulated 1351-mouse to joystick-mode, in Denise?
Cool! Will try it out, when I am back home again, in some days.
This should be fixed in the current nightly build.
Okay, I'll add residFP to the to-do list.
This is a nasty bug in VIA emulation. The write operation is terminated by switching from CB2 output to input. The pin becomes high-impedance. (don't emulate this) Please do not confirm the write operation until the bug is fixed or the disk is broken.
This is a nasty bug in VIA emulation. The write operation is terminated by switching from CB2 output to input. The pin becomes high-impedance. Please do not confirm the write operation until the bug is fixed or the disk is broken.
With glitch you mean, that it don't accept the next diskside and then don't go on loading, when this diskside is inserted, I assume? At least this is, what I get here, when I tried this game in Denise. It worked one time, with this second diskside (when this disk is new), but then the game seems to save something on this diskside and then, when you start "Fire King" again and the game asks for this second disk, it don't go on loading on this disk finally. When I take a new diskside2, then it works...
For a S.E.U.C.K. game, it's not bad and playing it with a mouse set to joystick-mode, works better for me, than playing it with any of my joysticks, that could be seen on a real C64 machine, where switching to joystick-mode for mice works normally. Only C64 emulators strangly can't do this so far. Furthermore, emulators normally strive, to replicate everything, the original system can do, as accurately as possible and that then includes things like joystick-mode for mice too. Why emulate everything...
Always liked it, that Denise supports different SID filter-types and that the users can choose, what they want. And also here in this case, when it comes to the SID emulation-engines, it would be great, if users could choose in the future, which type they want to use. I wouldn't just drop either of them.
Fire King glitching up