View Full Version : Better (perhaps) A500 compatibility
Toni Wilen
03 August 2007, 21:12
More information later :)
keropi
03 August 2007, 21:17
oooooooooooooohhhhhhhhhhhhh :bowdown
DamienD
03 August 2007, 21:23
Nice one Toni :great
bippym
03 August 2007, 21:46
that does what exactly?
Zetr0
03 August 2007, 22:00
@bippym
The WinUAE master, is attempting to probe the far reaches of the known and unknown universe that is the A500.
Armed with what seems a nice usb reporting logic probe / analyser may lead the intrepid emu-guru to greater knowledge upon how the *undocumented* features of the A500 work.
I am hoping, that Toni's endevor provides fruitfull, and bares fruit in the form of improved emulation of a500 features :D
*pssst.... it looks to me like Toni is investigating something to do with the video timing perhaps.... but i could be wrong (and most likely am its been way to long since i use an a500 let alone a logic analyser / probe thingy) :)
Ironclaw
03 August 2007, 22:01
Can the a500 emulation really be any better? :). Seems perfect to me already :). Well, remember some stuff now.. ok 99% perfect I would say :).
Zetr0
03 August 2007, 22:07
@Ironclaw
For some perfection is about not about obtaining anything, but the process of improvement.
Ironclaw
03 August 2007, 22:11
Uhm... like coding stuff better, maybe requiring less cpu power in the future thanks to the findings of this device?... if not, I don't understand what you said :P.
Zetr0
03 August 2007, 22:19
@Ironclaw,
not sure if reduction of cpu would really a benefit, after all a500 emulation is quite tight. i feel at this point it would be more about stability as well as offering some of the lesser and unknown features for the emulator to exploit.
maybe in a small way there it is possible to reduce a fractional computational overhead, but with WinUAE being what it is.... its all about the improved perfomance me thinks...
the thing is, the more thats known, the closer we get ( i say we, I mean Toni and others way more technical than I *this does include the milkman btw lol* )to a better and more complete knowledge of the interaction of the A500. and hence...
(small fan faire) badaba badaaaaa!
A500 on a chip :D now that would be something! (yes i know about the minimig its that sort of thing really just better performance over all) I would love to see how the minimig runs demos. that would be awsome.
anyway i am digressing away from toni's topic. sorry about that...
Ironclaw
03 August 2007, 22:21
Oki, ZetrO... I knew that...... anyway.......don't get me wrong or anything... but I like my new cd display case.
Retro-Nerd
03 August 2007, 22:23
Your Logicport Analyzer looks very important, Tony. Should be good for anything, i assume. ;) :D
whitegiant89
06 August 2007, 01:15
Nice toy you got there Toni :great
Toni Wilen
06 August 2007, 16:54
Blitter linedraw cycle "secret" found (more later..)
Same line draw (1,0) to (30,20)
With singledot: BLTCON1 SING-bit set
Without singledot: BLTCON1 SING-bit cleared (only one pixel/horizontal line, used when area needs to be filled)
line 1: vsync
line 2: hsync
line 3: chip ram dma access
line 4: chip ram read/write access
As the diagram shows, only drawn pixels are written back (bus is free for other uses when no pixel drawn) I thought blitter always writes data back, even if there is no pixel drawn..
I think this explains problems with demos with vector objects because WinUAE's linedraw uses too many cycles depending on line type.. (testing soon)
killergorilla
06 August 2007, 17:48
I haven't got a fecking clue what the hell you are on about but if it helps WinUAE achieve better A500 compatibility it sounds awesome.
Keep up the confusing/good work :D
musashi5150
06 August 2007, 19:47
That's very interesting Toni. Like you I assumed the Blitter always wrote back what it read in through a source channel - even if the data was unchanged.
Looks like it was quite a clever little tike ;)
dlfrsilver
08 August 2007, 01:28
Would did system works on a 1200 too ?
Since Commodore never gave anything about hardware info, would be excellent ^^ !
Toni Wilen
08 August 2007, 09:01
Would did system works on a 1200 too ?
Since Commodore never gave anything about hardware info, would be excellent ^^ !
Of course it is possible but surface mount chips suck.
But the question is: why? AGA is basically hacked ECS, afaik there is no big secrets. Chip memory bandwith was increased but only for bitplanes and sprites. Copper, blitter, audio etc.. haven't been changed, horizontal scanline cycle diagram should be exact same (except when using 2x/4x bandwidth display modes but there is nothing special there either)
Problem with AGA emulation is not unknown chipset features but CPU (this is becoming really popular faq..)
Zetr0
08 August 2007, 13:18
@Toni
.... (this is becoming really popular faq..)
I blame you for posting cool pics and discovering stuff ;) :)
viddi
08 August 2007, 13:23
Your Logicport Analyzer looks very important, Tony. Should be good for anything, i assume. ;) :D
Yo! :D
Thanks Toni. The real C= man! ;)
Hungry Horace
08 August 2007, 15:44
Can the a500 emulation really be any better? :). Seems perfect to me already :). .
somewhat naive comments from a self-proclaimed "genius" :lol
Toni: your work is hardcore, and we all appriciate it!
demoniac
08 August 2007, 20:29
Excellent findings. To me this is one step closer to recreating the Amiga prototype with breadboards.
Toni Wilen
21 May 2008, 16:39
New logic analyzer findings (it has been too long..)
I finally decided to snoop RGA (custom register address bus) bus. Should have done this ages ago but I was stupid and too lazy :)
RGA = custom address accessed, WE = write enable, INT3 = Agnus int3 pin, DMAL = Paula DMAL pin (not used yet), IPL = CPU interrupt level.
Guess whats happening in these images? :) (hint in image names)
Apparently every custom chip number is directly available in RGA bus, even if it is Agnus internal register. (RGA is used to transfer data to/from Denise and Paula, for example Agnus bitplane DMA puts BPLxDAT to RGA and does DMA from chipram)
This means blitter line mode cycle diagram mystery will be finally solved in few days.
EDIT: delay between bltsize and first DMA transfer looks interesting and is quite long..
toni u are a god! thk for your time, patience and devotion about "I think this explains problems with demos with vector objects because WinUAE's linedraw uses too many cycles depending on line type.. (testing soon)", you think that can be a solution for this probleme for exemple demos of virtual dream in the middle we can see that (the rest work like a charm):
Toni Wilen
23 May 2008, 16:09
Line draw mode was boring, didn't find anything interesting :(
It is -C-D-C-D-C-D except write is free cycle when in onedot mode and no pixel needs to be drawn. (nothing new here)
3 free cycles between write to BLTSIZE and first blit cycle are also free (this isn't exactly emulated yet) but this can't fix above demo either..
ADDED: I guess copper and blitter cycles don't align properly causing lost cycles (demo writes blitter registers using copper)
oki thk for this info , like i'm a a500 maniak , please continue your work about the 500 :)
boing_1000
15 July 2008, 03:05
Toni you work some mysterious magic:laughing
A logic analyzer, though...haha I admire your dedication.
vBulletin® v3.7.0, Copyright ©2000-2013, Jelsoft Enterprises Ltd.