Denise bugfixes and improvements

[PiCiJi]

I was wondering if Denise supports portable mode? (some other emulators expect an empty file named portable to be created)

copy the global_settings.ini and Amiga_settings.ini to emu folder.

settings priority:
1. command line parameter
2. in emu UI specified custom settings
3. emu folder
4. home folder

[Toni Wilen]

Originally Posted by PiCiJi

Some tests that didn't work in Denise, I tested in WinUAE and some failed like DIVS2, DIVU2, CHK1

I've worked with FX68k quite a bit. All tested opcodes with the typical IPL sampling during the prefetch cycle have the interrupt serviced after current instruction, if IPL line is changed no later than 1 CPU cycle before the prefetch cycle.

DIVU2 is identical if I remove Paula low to high being slower than Paula hight to low IPL pin behavior emulation (due to pullup resistor making it harder to pull it down than high). So either it isn't that simple (but without this my cputester tests would fail regularly and the difference is obvious in logic analyzer) or it is slightly "random" or there is some bug.

Didn't test others because I hate almost empty adfs. Executables only.

I used my own cputester IPL mode to confirm IPL behavior last year. UAE 68000 IPL should be perfect

[amilo3438]

Seems today's nightly fixed some more demos titled (probably wrongly) in the post #20 as: 13) Blitter problem!

[amilo3438]

Originally Posted by PiCiJi

copy the global_settings.ini and Amiga_settings.ini to emu folder.

settings priority:
1. command line parameter
2. in emu UI specified custom settings
3. emu folder
4. home folder

Thanks! (I'll check)

EDIT:
Checked, but it does not work as a real portable should!
From a portable mode I would expect to not use "users" folder than saves everything into an emu folder!
I wondering is it possible to create some empty file called "portable" inside of emu folder and than Denise create and use all config files from there instead of default "C:Users/PC/AppData/Roaming/denise"?!

[PiCiJi]

Originally Posted by Toni Wilen

low to high being slower than Paula hight to low IPL pin behavior emulation (due to pullup resistor making it harder to pull it down than high).

How much extra time is needed for this?
IPL: 3 -> 1 instead of 1 -> 3

Originally Posted by amilo3438

Seems today's nightly fixed some more demos titled (probably wrongly) in the post #20 as: 13) Blitter problem!

all Blitter linedraw stuff should work better

[PiCiJi]

Originally Posted by amilo3438

Thanks! (I'll check)

EDIT:
Checked, but it does not work as a real portable should!
From a portable mode I would expect to not use "users" folder than saves everything into an emu folder!
I wondering is it possible to create some empty file called "portable" inside of emu folder and than Denise create and use all config files from there instead of default "C:Users/PC/AppData/Roaming/denise"?!

I don't understand. If you copy the settings files to the Emu folder and then save them from Emu UI [Options->save preferences], it is portable. You don't need to use the UI under Configuration/Settings.
If you copy the Emu folder somewhere else, the settings are retained.

[amilo3438]

Originally Posted by PiCiJi

I don't understand. If you copy the settings files to the Emu folder and then save them from Emu UI [Options->save preferences], it is portable. You don't need to use the UI under Configuration/Settings.
If you copy the Emu folder somewhere else, the settings are retained.

"and then save them from Emu UI [Options->save preferences], it is portable"

Thanks, I didn't know for this! (I know now)

[Toni Wilen]

Originally Posted by PiCiJi

How much extra time is needed for this?
IPL: 3 -> 1 instead of 1 -> 3

It is ~1.5 CPU clocks (~3/4 CCK) IPL pin(s) state change delay. My cputester IPL test (which uses serial receive interrupt as a "timer interrupt") with IPL lines requiring high->low transitions only works if this delay is implemented. If this condition is hit, interrupt is delayed by 2 CPU clocks.

DIVU2 test also triggers this condition but interrupt isn't delayed. Probably something interrupt being "external" or not. But at least direct INTREQ write caused interrupt has always wrong timing (whole DIVU2 is totally wrong) if it is any faster or slower than currently.

Or maybe there are some "special" oldIPL->newIPL state changes that work differently. Need new tests to confirm it. (I can't do 1->6 IPL change test with cputester)

EDIT: I just checked using logic analyzer that both "external" interrupt (RBF) has exact same timing as writing 0x8800 to INTREQ. IPL change timing is identical in both cases. If for example if IPL was 3 before IPL 6 change, IPL2 changed immediately but IPL1 had ~3/4 CCK delay. Same with 0x8004 -> 0xa000 like the test codes.

EDIT2: during those ~3/4 CCKs, IPL is 7 (All pins zero in hardware level), which happens in non-working DIVU2 line. Is it possible CPU does some special case handling (like NMI being level triggered) when it sees level 7 interrupt which would explain "early" start? I did check fx68 last year but I don't remember any details and not that interested to recheck..

EDIT3: It might be side-effect caused by aca500plus. Delay seems to be gone when it is disconnected.. Need to do more tests..

Hopefully final edit: it seems to depend on how much IPL lines are loaded (and probably also PSU stability/voltage level etc). If I have logic analyzer probes connected, IPL delay happens. But I am quite sure it did happen even without nothing connected so perhaps it also depends on temperature or something.

[PiCiJi]

Originally Posted by Toni Wilen

It is ~1.5 CPU clocks (~3/4 CCK) IPL pin(s) state change delay. My cputester IPL test (which uses serial receive interrupt as a "timer interrupt") with IPL lines requiring high->low transitions only works if this delay is implemented. If this condition is hit, interrupt is delayed by 2 CPU clocks.

Can I use cputester meaningful without harddisk emulation? or can you send me tests, which presumably depends on interrupt delaying when changing certain IPL?
At least the IPL tests of vAmigaTS don't seem to depend on it and it includes all kinds of combinations of IPL changes.
edit: It may not be visible because IPL changes to these tests are not close enough to the critical limit within the opcode.

nightly: fixed collision detection of Archon.

[amilo3438]

I have checked Denise tickets reports about amiga:

#28 The Nature of Magic by New Generation Crew fails to load (Amiga Demo)
Already reported in post #20! as: 07) Stops at loading!

#29 City Demo (Demo) by Scrapers glitchy graphics
Garbage confirmed in problematic demos thread: https://eab.abime.net/showpost.php?p...&postcount=454

#30 COOL FRIDGE by UPFRONT glitchy graphics
Already reported in post #20 as: 08) Syncronize_CPU_to_display problem!

#31 Artificial Dreams (1988)(Prism Leisure) nothing but black screen with music and sound fx playing as the title says tried both A500 settings
Tested on last nightly to work fine! (A500 1.3 ECS 512+512)

#32 Demolition (1987)(Kingsoft)(DE)(en)[cr HQC] fails to load
Tested on last nightly to work fine! (A500 1.3 ECS 512+512)

[pixie]

I've downloaded the latest denise on sourceforge and dos andromeda now runs fast like crazy!

[amilo3438]

Originally Posted by pixie

I've downloaded the latest denise on sourceforge and dos andromeda now runs fast like crazy!

No problem here! (maybe better delete your current config and check again with default one)

Ps. Config files are in: "C:Users/PC/AppData/Roaming/denise" for Win PCs!


EDIT: Latest denise on sourceforge is 2.0 version! (you need latest nightly 2.1 version)

Nightly (or beta) build can be found in: https://ci.appveyor.com/project/piciji/denise/history
(click on "Current build", choose your OS under Job name, click on tab "Artifacts", download)


EDIT1: Checking other thread "Denise 2.0 released!" ( https://eab.abime.net/showthread.php?t=114351&page=6 ) I see that you already know for nightly versions! (So why latest denise on sourceforge? Isn't that trolling?)

[PiCiJi]

ok build cputester.
It's going through right now. I have everything up to 68010 loop enabled in cputestgen.ini

[pixie]

Originally Posted by amilo3438

No problem here! (maybe better delete your current config and check again with default one)

Ps. Config files are in: "C:Users/PC/AppData/Roaming/denise" for Win PCs!


EDIT: Latest denise on sourceforge is 2.0 version! (you need latest nightly 2.1 version)

Nightly (or beta) build can be found in: https://ci.appveyor.com/project/piciji/denise/history
(click on "Current build", choose your OS under Job name, click on tab "Artifacts", download)

Thanks I did not knew

Originally Posted by amilo3438

EDIT1: Checking other thread "Denise 2.0 released!" ( https://eab.abime.net/showthread.php?t=114351&page=6 ) I see that you already know for nightly versions! (So why latest denise on sourceforge? Isn't that trolling?)

I don't know how do you know what I know or not, I told you what happened. I've heard of nightly builds yes, but didn't knew where to get them from, I went to sourceforge expecting to be there, and download the only thing I could. As it behaved differently as of before I assumed to be different, which it wasn't as it now runs normal.

The only thing I can tell is that at the time I was on a teams call and Denise didn't have any sound, the counter which usually is at 50, at the time was at 250. Trolling, for which porpose?

[amilo3438]

Originally Posted by pixie

Trolling, for which porpose?

Come on, please, don't. I also read you on some other threads, you do it very perfidiously.

Just don't continue trolling here anymore, please!

[pixie]

Originally Posted by amilo3438

Come on, please, don't. I also read you on some other threads, you do it very perfidiously.

Just don't continue trolling here anymore, please!

perfidious • \per-FID-ee-us\ • adjective. : of, relating to, or characterized by faithlessness or disloyalty : treacherous. OTHER WORDS FOR perfidious. false, disloyal; unfaithful, traitorous.

You clearly have some issues...

[amilo3438]

@pixie

And what are you doing right now but trolling! (FYI, you will be ignored here, at least from me)

Btw. correct answer is: treacherous.

[Toni Wilen]

Originally Posted by PiCiJi

ok build cputester.
It's going through right now. I have everything up to 68010 loop enabled in cputestgen.ini

Remember to add -cycles to cputester Amiga program to also include cycle count checks. Cycle counts are always generated if 68000/010 but not checked by default.

Possibly late answers..

Can I use cputester meaningful without harddisk emulation?

Yes, data files are now by default compressed and "single-filed". Previously there were dozens of small files that make copying slow..

IPL "delay" can be ignored, it really seems to be as simple as something having too heavy load on Paula IPL lines, causing them to change state slower than normally.

[pixie]

Originally Posted by amilo3438

EDIT1: Checking other thread "Denise 2.0 released!" ( https://eab.abime.net/showthread.php?t=114351&page=6 ) I see that you already know for nightly versions! (So why latest denise on sourceforge? Isn't that trolling?)

It seem that it was this post where you got the idea from...

Originally Posted by amilo3438

I checked on this version: http://janeway.exotica.org.uk/release.php?id=397

No problem on A500 ECS 1.3 512 +512 configuration using only DF0: drive!
(except some glitches on vector objects as reported for some other demos)

So you think because you posted this message I somehow went there and check this version which accordingly to you had no problem? What I acknowledge at the time is since it was working fine for you the issue must be somehow related to my lcd monitor... not did I clicked this link there, today when I finally get there had to get back and forth to get to the exe (which when it runs appears as running Denise 2.0 and not 2.1).

Originally Posted by amilo3438

@pixie

And what are you doing right now but trolling! (FYI, you will be ignored here, at least from me)

Btw. correct answer is: treacherous.

You seem to be quite young and naive, first you don't seem to have the idea what troll actually is and its intent, because if you had you'd knew that "Just don't continue trolling here anymore, please!" is what a troll mostly like to hear.

Originally Posted by amilo3438

Come on, please, don't. I also read you on some other threads, you do it very perfidiously.

I would dear you to give me ONE example

[PiCiJi]

I compiled cputestgen on Windows and built the Amiga program "cputest" on Linux.
Now I have written some basic tests on an ADF to see if it works in general. It does.

now the IPL tests
here are some parameters I use in cputestgen.ini

cpu=68000
cpu_address_space=68020
feature_gzip=3
max_file_size=100

test_high_memory_start=0x00ff8000
test_high_memory_end=0x01000000

test_memory_start=0x00460000
test_memory_size=0xa0000

opcode_memory_start=0x87ffa0

test_rounds=2
feature_flags_mode=1
feature_interrupts=2

;The rest is set to 0 or nothing, in any case unchanged.

; interrupt timing test with waitstates
[test=WIPL]
cpu=68000-68010
enabled=1
verbose=0
feature_undefined_ccr=1
feature_interrupts=2
feature_waitstates=2
#feature_addressing_modes_src=dreg
feature_condition_codes=
# wait state mode requires use of chip ram
test_memory_start=0xd0000
test_memory_size=0x20000
rnd_seed=10
mode=AND,DIVU,DIVS

; interrupt timing test
[test=IPL]
cpu=68000-68010
enabled=1
verbose=0
feature_undefined_ccr=1
feature_interrupts=2
feature_sr_mask=0x2000
#feature_addressing_modes_dst=apdi
feature_condition_codes=pl
rnd_seed=10
mode=AND,DIVU,DIVS

the sh script to build the ADF

#!/bin/bash
echo "ADF $1"

rm $1.adf
echo "cputest -cycles IPL/$1" > startup-sequence

xdftool $1.adf format "$1"
xdftool $1.adf makedir s
xdftool $1.adf write startup-sequence s
xdftool $1.adf makedir data
xdftool $1.adf makedir data/0_IPL
xdftool $1.adf write $1 data/0_IPL/
xdftool $1.adf write tmem.daz data/0_IPL/
xdftool $1.adf write hmem.daz data/0_IPL/
xdftool $1.adf write ../cputest
xdftool $1.adf boot install
rm startup-sequence

xdftool $1.adf list

in WinUAE: ECS Agnus, cycle accurate, kick 1.3, chip 0.5, slow:0, fast: 8MB, Serial Port: loopback

all IPL tests throw errors: e.g. AND.B: memory byte write: address ffff8197, expected 14 but got a0
What am I missing here?

edit: can not test it in my emu at the moment, because serial emulation is not complete enough

Are there some defaults to prevent tmem, hmem ... because of the limited ADF size

edit2: When reading the posting, I immediately notice a possible problem. I'll have to create IPL separately from WIPL dats, because otherwise "feature_waitstates=2" will apply to IPL too ?