Page 2 of 2

Re: XRoar and Dragon32 emulation?

Posted: Sat Nov 17, 2018 10:53 am
by sixxie
pser1 wrote:
sixxie wrote: Released!
I have downloaded v35.1 and tested the same program I was using without changes ...
The result is the same, $c000 gets modified and so the compare finds equal values
wich should not happen on real hardware.
Hmm. My (untested in the case of cartridge ROM space) guess is that this will happen on real hardware, so long as no ROM cartridge is inserted (your store to $C000 in map type 1 should have ended up at $4000). But XRoar still isn't handling the case where there's actually a ROM at $c000, meaning your actual data makes it to RAM instead of the ROM contents. Fixing that is a bit more intrusive.

The logic: in an unexpanded Dragon 32, the top bit of RAM addressing is ignored, meaning that in map type 1, writes to high "RAM" (which doesn't exist) end up going to low RAM (which does).

Additionally, the ROM select values from the SAM's S output are not inhibited for writes, yet in map type 1, S has the same values when writing as they would in map type 0 (either reading or writing). Therefore the ROM gets selected (if present), and the value at that position in ROM gets written to low RAM.

As an example, try writing anything to addresses $8400-$85ff in map type 1 and see what happens to the text screen. Now try that on a real Dragon 32. (Of course this is where we find that the various board variations act differently and I'm suspected of being an idiot ;) - but honest, this behaviour was identified on here some years ago.)

Re: XRoar and Dragon32 emulation?

Posted: Sat Nov 17, 2018 12:09 pm
by pser1
Hi Ciaran,
thanks one more time for your explanation.
I will try writting to $8400 on ... it's a very clever idea!
I will need more time to test it in a real Dragon32 as on my desk there are a D64 and a Tano for testing purposes ... but will be done.

It is not that important for the project I am working on, just got surprised when emulating the D32 the program didn't do what I was expecting ...
Anyway, I will search among my very old project folders because I am sure that at some point in the past I created a few utilities that allow
the user to know the amount of memory, type of CPU and even the MAP you weere working on ...
And trying to switch from one to another was detected and if not possible a warning message appeared ... time flies too fast!

Anyway I will tell you the results of my tests.
Have a nice weekend

Re: XRoar and Dragon32 emulation?

Posted: Sat Nov 17, 2018 1:31 pm
by pser1
Hi Ciaran,
I tested your idea ... and this is the result:
Test_Result.jpg (28.12 KiB) Viewed 2340 times
The code used is this one:

Code: Select all

; ---------------------------------------------------------------------
			org   $3300
			put   $3300
; ---------------------------------------------------------------------
			orcc  #$50							; disable interrupts
			sta	$ffdf							; switch to MAP1
			ldu   #$8400						; point to this ROM area
			ldx	#ErrMsg						; point to error message
			bsr	ShowMsg
			sta	$ffde

			ldu   #$0480						; point to this SCREEN area
			ldx	#ErrMsg						; point to error message
			bsr	ShowMsg
			andcc	#$af							; enable interrupts
			rts									; return
; ---------------------------------------------------------------------
ShowMsg	lda	,x+							; get a byte
			beq	EndShow						; end flag? exit
			ora	#64							; avoid inverted cars
			sta	,u+							; put on screen
			bra	ShowMsg						; go for next char
EndShow	rts									; return
; ---------------------------------------------------------------------
			fcn   /ON 64K MACHINES/
; ---------------------------------------------------------------------
EndPgm	equ	*
So it seems that the first loop makes a special effect, every byte from the ROM seems to be copied into
the corresponding screen byte.
You can see that the first two blocks have been POKEd by the program, the second already in MAP0
Finally the third block is created in Basic by POKing to screen the contents of the ROM from $8400 onwards
Well, now it is just a matter of discovering what the real hardware will do ...

Re: XRoar and Dragon32 emulation?

Posted: Sat Nov 17, 2018 1:40 pm
by pser1
HI Ciaran,
I forgot to say that this last test is a clear demonstration that the write commands don't get their goal,
instead the lower RAM is modified copying there the pre-existing value from the pointed byte of ROM.
But then, when the program 'reads' the ROM still in MAP1, the data it receives is not the one from ROM
(already copied to RAM) but the one I had tried to POKE ... But that seems strange, so compares to equal!
Shouldn't I get back the ROM value instead? from RAM of course but the ROM contents.
This is going to end with a terrible headache ;-)

Re: XRoar and Dragon32 emulation?

Posted: Tue Nov 27, 2018 9:03 pm
by sixxie
Ok I'm not sure I understand the last point... Unless your re-read tests were performed in cartridge space (in which case the code to put cartridge ROM data on the bus wasn't there yet).

0.35.2 fixes a reported bug with 5.1 audio, but also addes the cartridge area code...

Re: XRoar and Dragon32 emulation?

Posted: Sun Dec 02, 2018 8:13 pm
by pser1
Hi Ciaran,
sorry for getting back so late :-(
Finally I got one unexpanded Dragon32 and put it on the desk.
Using the CoCo-SDC I have loaded an VDK that contains a program
that verifies if the machine has RAM in the area $C000-C001 and in case the written word doesn't match the contents
of these two bytes, shows an error message ... and this is exactly what has happened
The screen shows:
So it is ok for me. Users will be warned, despite they *should* not try this with a 32K machine ...
But the same program in an emulated Dragon 32 on XRoar hangs instead of showing the error message.
Again, no problem because as it hangs the user will have to remind that (s)he was trying to use the game
in a not supported machine.
I am using XRoar 0.35.2