Baremetal Amiga Emulator

[bloodline]

It seems some of my problems might be due to incorrect initial register states.

The CIA registers are now initialised correctly… But the chipset registers are not, having them all start at zero leads to the “insert disk” drawing code just filling up the chipram using the Blitter, having all the registers start at 0xFFFF, mean the code seems to complete its blitting, but still never set up a vaild copper list.

The code must be depending upon some initial value in a register… not one of the read registers as those have always been initialised, and the code seems to set up the Blitter registers correct… so it must be something else

[paraj]

Have you tried KS1.3? KS1.2 has quite of bit off odd stuff, e.g. it will not work unless you emulate BPLCON0.ERSY to some degree (it uses it to detect if genlock is active, quick hack is to just return fixed position for VPOSR/VHPOSR if it's enabled), and IIRC the last part isn't necessary for later versions.

[bloodline]

Originally Posted by paraj

Have you tried KS1.3? KS1.2 has quite of bit off odd stuff, e.g. it will not work unless you emulate BPLCON0.ERSY to some degree (it uses it to detect if genlock is active, quick hack is to just return fixed position for VPOSR/VHPOSR if it's enabled), and IIRC the last part isn't necessary for later versions.

Thats a good shout, I test with 1.2, 1.3, 2.0 and 3.1. My previous version booted 1.2, 1.3 and 2.0... but not 3.1.

Currently, 1.2 and 1.3 behave identically (I can see the blitter activity line drawing and filling the insert disk screen, but never set up the copper list with the correct BLP pointers), and 2.0 and 3.1 both hang during... or just after the floppy detection.

The ERSY bit is set during boot... let me try your hack and hold the V/VHPOS registers.

-Edit- The Kickstart just clears the bit early on and the counters restart... The problem remains

[bloodline]

Originally Posted by hooverphonique

I have never seen a drive implementation which actually cares about the 32 bit count, they just keep clocking out the same pulse train as long as the motor is off. These are often done using a D-flipflop, given the pulse trains are so simple (FFFFFFFF, AAAAAAAA, 55555555). For an alternating stream, the flipflop needs to be set to the correct state when turning off the motor, of course.

So, if I'm following correctly, we just need to set the DSKRDY when a select signal is active and the motor bit is not set, then clear the DSKRDY when the select signal is not active.

[bloodline]

Source code can be found here... This is just a snapshot of the sate as of now and is just for info.

https://github.com/h5n1xp/Omega/tree/master/Omega2

For those playing along at home, this will compile when linked against libSDL2.0

-Edit- The latest DiagROM boots and runs perfectly, except for the "RGB Test", but I have no idea what that is actually supposed to be doing

[bloodline]

Found a bug, BLTFWM was being updated with BLTALWM’s value now the blitting work fine… but copper list still doesn’t have correct Bitplane pointers

-edit- curiously DiagROMs Blitter test doesn’t work correctly now
-edit- no, that’s not the change which broke that.
Tonight’s debugging session is going to be fun…

[hooverphonique]

Originally Posted by bloodline

So, if I'm following correctly, we just need to set the DSKRDY when a select signal is active and the motor bit is not set, then clear the DSKRDY when the select signal is not active.

That sounds reasonable for a 3.5" DD drive, yes..

[bloodline]

Stepping through the kickstart 1.2 code, I'm struggling with this...

A0 = 0xDFF000

E fc6d04: 4df9 00bf d000      : lea     $bfd000.l, A6
E fc6d0a: 022e 007f 0f00      : andi.b  #$7f, ($f00,A6)
E fc6d10: 4280                : clr.l   D0
E fc6d12: 1d40 0a00           : move.b  D0, ($a00,A6)
E fc6d16: 1d40 0900           : move.b  D0, ($900,A6)
E fc6d1a: 1d68 0006 0800      : move.b  ($6,A0), ($800,A6)

It appears that last move.b is writing the highbyte of the VHPOSR register to the CIA_B_TOD_LO register... but the high byte of VHPOSR is the vertical beam position, and the CIA_B_TOD counter is the horizontal beam counter... Shouldn't it be writing to the CIA_A_TOD?

[paraj]

Originally Posted by bloodline

Stepping through the kickstart 1.2 code, I'm struggling with this...

A0 = 0xDFF000

E fc6d04: 4df9 00bf d000      : lea     $bfd000.l, A6
E fc6d0a: 022e 007f 0f00      : andi.b  #$7f, ($f00,A6)
E fc6d10: 4280                : clr.l   D0
E fc6d12: 1d40 0a00           : move.b  D0, ($a00,A6)
E fc6d16: 1d40 0900           : move.b  D0, ($900,A6)
E fc6d1a: 1d68 0006 0800      : move.b  ($6,A0), ($800,A6)

It appears that last move.b is writing the highbyte of the VHPOSR register to the CIA_B_TOD_LO register... but the high byte of VHPOSR is the vertical beam position, and the CIA_B_TOD counter is the horizontal beam counter... Shouldn't it be writing to the CIA_A_TOD?

CIAB TOD is the "horizontal sync event counter", i.e. it counts raster lines. So that code is setting the counter value to (more or less) match the vertical position so a CIAB TOD alarm can be used to match a (more or less) exact vertical position later on.

[bloodline]

Originally Posted by paraj

CIAB TOD is the "horizontal sync event counter", i.e. it counts raster lines. So that code is setting the counter value to (more or less) match the vertical position so a CIAB TOD alarm can be used to match a (more or less) exact vertical position later on.

"i.e. it counts raster lines."

Yep, that was what I was missing, I'm over focusing on this issue so much I'm becoming blind to basic things.

I've put my ADF track to MFM track code into the Emulator now, so at some point* I'll just abandon the hunt for this elusive bug (it's probably a timing issue... though I haven't ruled out a problem with how my CIAs behave) and see what happens if I just let the emulator boot a disk.

*I'm on child care duty this week so, don't have much time for my hobbies.

[bloodline]

So the past two weeks of bug hunting, turned out to be a simple typo. When the COPJMP2 register was strobed, the Copper’s PC was loaded with COP1LOC

Now that’s fixed, the new code all seems to work and Kickstart 1.x can boot floppies fine.

Time to look at Sprites… the original Omega didn’t really bother and just rendered the sprite data on the framebuffer after the screen draw.

This time I want to generate them properly as part of the display.

[bloodline]

It didn't take long to remind me why I don't like sprites...

The SPRxPOS register doesn't seem to be updating.. but the mouse movement is being correctly recorded, DPaint4 works fine, for example...

[hooverphonique]

Originally Posted by bloodline

The SPRxPOS register doesn't seem to be updating.. but the mouse movement is being correctly recorded, DPaint4 works fine, for example...

What did you mean, when you say "not updating"? SPRxPOS is write-only, and only really useful when not using sprite dma (unless you're doing fancy tricks mostly used by demos/games).

[bloodline]

Originally Posted by hooverphonique

What did you mean, when you say "not updating"? SPRxPOS is write-only, and only really useful when not using sprite dma (unless you're doing fancy tricks mostly used by demos/games).

Good catch, I had already realised my mental model of the Sprite hardware was wrong.

I know now that the data structure at SPRxPT is where all sprite information is actually held.

Now I can see the VH positions in the data structure update with the movement of the mouse, and see the sprite image data after them.

Right now I'm trying to figure out how to integrate the Sprite generation into my Bitplane generation.

My current, approach is thus (for each horizontal line):
1. Wait for the Bitplane fetch to finish (checking DFFSTOP).
2. If the Sprite DMA is enabled, check each sprite's VPOS.
3. If the Sprite VPOS equals the display VPOS, then calculate the sprite's x position on the line and draw a line of the sprite in the correct position in the framebuffer (which, by now, will already have Bitplane data in it).
4. Increment the Sprite VPOS, and increment the sprite colour data pointer (to the next line of sprite data).
5. if the VPOS > the sprite VSTOP, then shutdown sprite.
6. Repeat.

It's sort of working, too...

[bloodline]

The BIG problem I have now is that sprites and biplanes are not matching up, horizontal position wise.

Very easy to see when using DPaint as, it has a software generated colour dot that should be at the centre of the Sprite crosshair.

I realises this is due to me completely ignoring the DIWSTRT and DIWSTOP horizontal position, and working out the horizontal display postisition using the DFFSTRT value....

Ok... I guess I need yet another Bitplane generation rewrite...

[bloodline]

Ok, I've temporarily Kludged the problem by Starting the drawing at this DMA position:

Line DrawingStart = (((DWSTRT & 0xFF) >> 1) - DFFSTRT) - 6

Not totally sure why this works, but it means my Bitplane and sprites now match up on the host framebuffer

[bloodline]

First time ever KickStart 3.0 has booted!

Though, my hardcoded DFFSTOP is cleary causing issues...

-Edit- after a little playing, it seems that Kickstart 3.0 is doing something else a bit weird on the boot screen... not really sure what

[Cobe]

I'm out of your league, but I like following your endeavour, such gfx I experienced when I mismatched fetch modes.

[jotd]

booting a kickstart is really not trivial, even with trashed display mode. Well done!

[bloodline]

Originally Posted by jotd

booting a kickstart is really not trivial, even with trashed display mode. Well done!

Cheers! So I’ve had Kickstarts 1.x booting for a while, in fact it’s been DeluxPaint which has been the most useful as I can change resolutions while it’s running I can test various display features; I know my Floppy emulation, Copper, Blitter, Planar to Chunky and sprite generation are all working properly. Sprites being the most important, as the previous version of the Emulator really didn’t bother with sprites.

What I need to do now is properly implement the DFF and DIW relationship, and Kickstart 3.0 seems like a good candidate for testing this.