Baremetal Amiga Emulator

[hooverphonique]

Is your chipset emulation indicating the chipset version correctly to the kickstart (ocs, ecs, aga) ?

Note I don't know if it actually would use aga features on the bootscreen in case of aga.

Your screenshot looks like too much bitplane data is fetched each scanline.

[bloodline]

Thanks to @paraj for a clearer explanation of the playfield generation, I have rewritten the code. Now the fetch code fills an internal buffer based on the DFFSTRT and DFFSTOP values, and the display is drawn from the buffer using the DIWSTRT and DIWSTOP values, which means the horizontal position is now double the resolution of the DMA.

This is more involved, but now the sprites and bitplanes match up to the same horizontal position… most of the time

My Kickstart 3.0 display issue (again pointed out by paraj) is actually caused by the scroll setting in BPLCON1, which I don’t emulate… yet!

[bloodline]

Originally Posted by hooverphonique

Is your chipset emulation indicating the chipset version correctly to the kickstart (ocs, ecs, aga) ?

Note I don't know if it actually would use aga features on the bootscreen in case of aga.

Your screenshot looks like too much bitplane data is fetched each scanline.

I have tried to make sure the DENISEID register reports back OCS, and KS3.0 doesn’t seem to be trying to set any ECS/AGA fetch modes.

It seems I need to emulate BPLCON1 properly. I guess that’s my next task!

[bloodline]

paraj pointed out to me that the BPLMODx registers are signed, so with that small change (previously They were treated as unsigned, so adding around 65530 bytes to each line...) and manually adjusting the fetch cycles (since I just want to see how close I am)... I get this (Yes, the disk animation is working too).

Now I need to work out how to do this properly!

-Edit- FYI KS3.1 seems to get stuck in a loop during the booting process at the moment, so it can't boot disks.
-Edit2- Actually more manually mashing in fetch numbers, and it seems it is booting fine, but it is trying to do something weird with the display, so not giving a useful image... My display model is still not quite right...

[bloodline]

Ok, so my understanding of the Bitplane fetch cycle was slightly wrong.

It isn't entirely clear in the HRM (though it does strongly allude to it), Lores and Hires DMA fetch blocks are both 8 cycles long, it's just that Hires fetches 32pixels per block, and Lores fetches 16pixels per block. So that kinda seems to suggest all Hires bitmaps must be some multiple of 32pixels... I never knew that in all 25 or so years of programming Amigas...

Now KS3.x seems to rely on the "Scroll Hardware", (i.e. BPLCON1) to generate its displays, I think this is so it can implement screens wider than displayable (which scroll when the mouse is at the screen edge)... Even the normal Workbench screen has a BPLMOD of -4 (Which I don't really understand how to interpret...)

My display algorithm was built to be as simple as needed to get a bitmap displayed... so assumed 16 pixel fetches, and really doesn't understand hardware scroll values... So this is going be a challenge to either modify what I've done or (probably more sensibly) think of a new approach...

-Edit- Edit, whoever designed Denise... I really hate him now!

[bloodline]

Ok, So I've decided to rewrite the display generation code completely, but this time instead of using Kickstart 1.3 and Workbench 1.3 as the reference (which only uses simple values), I'm going to use Kickstart 3.1 and my DeluxePaint 4 disk.

This opens a workbench display with:
DIWSTRT: 0x1D7E
DIWSTOP: 0x38BE
DFFSTRT: 0x0038
DFFSTOP: 0x00D8

BPLMOD1: -4
BPLMOD2: -4
BPLCON1: 0x55

Now, I think if I can get my display algorithm to work correctly with this test case I should have a useable generally usable model.

[bloodline]

Just drawing the Fetched data directly to the framebuffer, completely ignoring the DIW Horizontal values.

BPLCON1 is 0 here, so that should make it easier.
First thing to note is the the first 16 pixels, and last 16 pixels are just junk.

Now if I implement DIW horizontal display, This should line up correctly!

[hooverphonique]

Originally Posted by bloodline

Just drawing the Fetched data directly to the framebuffer, completely ignoring the DIW Horizontal values.

BPLCON1 is 0 here, so that should make it easier.
First thing to note is the the first 16 pixels, and last 16 pixels are just junk.
zontal display, This should line up correctly!

this explains why the modulos are -4, they skip the two 16 pixel words of border space in the frame buffer - this space is probably there to accommodate horizontal scrolling, and would be hidden when you get your diw stuff correct.

[malko]

@bloodline : really impressive

[saimon69]

Originally Posted by bloodline

Ok, so my understanding of the Bitplane fetch cycle was slightly wrong.

It isn't entirely clear in the HRM (though it does strongly allude to it), Lores and Hires DMA fetch blocks are both 8 cycles long, it's just that Hires fetches 32pixels per block, and Lores fetches 16pixels per block. So that kinda seems to suggest all Hires bitmaps must be some multiple of 32pixels... I never knew that in all 25 or so years of programming Amigas...

Well, if you remember hi-res non-laced had rectangular VERTICAL pixels that make sense

[bloodline]

I appreciate all the positive comments!

I have totally decoupled the Fetch from the Display now.

I realise that I have had the fetch model correct all along. But I was confused that the fetch cycles could be something like 42 cycles long, and then simply BPLMOD -4 to ensure that a valid line is fetched... Then just use the Display window to clip out the pixels that aren't needed... Not super impressed, as this is difficult to optimise from an emulation view point.

The issue is how Denise actually uses the BLPxDAT data...
Looking at the hires Workbench display we can see that
1. Fetch starts at DMA cycle 56, (up to) 4 bitplane words are now fetched into the BPLxDAT registers and they are ready for use by Denise by cycle 59.
2. But the DIW doesn't start drawing until pixel 129 (DMA Cycle 64.5), so the first fetch is discarded (good because the first 16 pixels of each line are just junk anyway).
3. The next DMA fetch starts on cycle 60, with the BPLxDTA registers being ready for use by cycle 63...
4. But DIW doesn't start drawing until cycle 64.5...
5. The next DMA fetch starts on cycle 64, BLT4DAT now contains the word from the next fetch cycle.
6. Half a cycle later Denise starts drawing the data found the BLTxDAT registers... Now only BLT3DAT, BLT2DAT and BLT1DAT registers are valid.

My solution is to have Denise counters running 2.5 cycles early, So when it uses the BLTxDAT registers they contain the correct data for that fetch cycle...
So far this is working for both KS1.3 and KS3.1 normal Hires and Lowres screens (I've not even attempted BPLCON1 emulation yet), but feels like a horrid kludge which is going to come back and bite me at some point (The HRM does state that there is a 5 cycle delay at the end of the fetch and the first position on screen, but it's unclear if this is a fetching delay or a drawing delay )... Any suggestions?

-Edit- I've also made the decision to split the Hires and Lores code paths completely.

[hooverphonique]

Originally Posted by bloodline

I appreciate all the positive comments!

I have totally decoupled the Fetch from the Display now.

I realise that I have had the fetch model correct all along. But I was confused that the fetch cycles could be something like 42 cycles long, and then simply BPLMOD -4 to ensure that a valid line is fetched... Then just use the Display window to clip out the pixels that aren't needed... Not super impressed, as this is difficult to optimise from and emulation view point.

The issue is how Denise actually uses the BLPxDAT data...
Looking at the hires Workbench display we can see that
1. Fetch starts at DMA cycle 56, (up to) 4 bitplane words are now fetched into the BPLxDAT registers and they are ready for use by Denise by cycle 59.
2. But the DIW doesn't start drawing until pixel 129 (DMA Cycle 64.5), so the first fetch is discarded (good because the first 16 pixels of each line are just junk anyway).
3. The next DMA fetch starts on cycle 60, with the BPLxDTA registers being ready for use by cycle 63...
4. But DIW doesn't start drawing until cycle 64.5...
5. The next DMA fetch starts on cycle 64, BLT4DAT now contains the word from the next fetch cycle.
6. Half a cycle later Denise starts drawing the data found the BLTxDAT registers... Now only BLT3DAT, BLT2DAT and BLT1DAT registers are valid.

My solution is to have Denise counters running 2.5 cycles early, So when it uses the BLTxDAT registers they contain the correct data for that fetch cycle...
So far this is working for both KS1.3 and KS3.1 normal hires screens (I've not even attempted lores for this new display generation yet), but feels like a horrid kludge which is going to come back and bite me at some point (The HRM does state that there is a 5 cycle delay at the end of the fetch and the first position on screen, but it's unclear if this is a fetching delay or a drawing delay )... Any suggestions?

The number of fetched words should match what you set up in your ddf registers (note the formula is different between hires and lores). I don't think the negative modulo is "just" to remove border garbage because of fetch issues, but rather to allow horizontal scroll (because a line will then need to contain/fetch more than 40 words even if only 640 pixels are shown).
You should try to get Ross or Toni to look at this as they know the details

[bloodline]

Originally Posted by hooverphonique

The number of fetched words should match what you set up in your ddf registers (note the formula is different between hires and lores). I don't think the negative modulo is "just" to remove border garbage because of fetch issues, but rather to allow horizontal scroll (because a line will then need to contain/fetch more than 40 words even if only 640 pixels are shown).
You should try to get Ross or Toni to look at this as they know the details

Apologies, I made a very poor choice of words! You are correct the extra fetched words are to allow for hardware scrolling, but since I don’t currently implement BPLCON1 my display generation code only works for displays with a BPLCON1 of 0x0 (where the Display windows clips off the extra words).

My next task, I suppose, is to get hardware scrolling to work.

[bloodline]

Hardware scrolling is easy to implement... Just subtract the value in BPLCON1 from the Display window HPOS values. Works fine...

[ Show youtube player ]

[bloodline]

All hardware scrolling tests seem to work fine except DPaint4... Which does some weird things if it goes too far to the right... I have no idea what's going wrong here

-Edit- Seems a tiny bit glitchy in WinUAE, so perhaps the DPaint guys are not setting the scroll up properly!?

[ Show youtube player ]

[mikeboss]

IMHO it shouldn't be possible to move DeluxePaint horizontally. I just tested this on minimig v1.8: it's only possible to move the window vertically. oh, and BTW: I'm very much looking forward to this baremetal emulator! checking this thread every day for progress ;-)

[bloodline]

Originally Posted by mikeboss

IMHO it shouldn't be possible to move DeluxePaint horizontally. I just tested this on minimig v1.8: it's only possible to move the window vertically. oh, and BTW: I'm very much looking forward to this baremetal emulator! checking this thread every day for progress ;-)

With kickstart 3.1 and whatever grotty version of DPaint4 I found in my ADF collection, horizontal scrolling does happen both in my Emulator and WinUAE… but for some reason my emulator really doesn’t like it! I’m very curious why the lower part of the screen disappears at certain horizontal positions, my guess is a dodgy Copperlist which works fine on the real copper but not on mine where I’ve followed the HRM spec not what actually happens.

Happy to send you the ADF if you want to test it?

It’s fun to be able to get back to work on this after the pandemic!

[mikeboss]

tested again with KS 3.1 (I used KS 1.3 in the first run). KS 3.1 does not work on minimig v1.8

so I tested again with a minimig v1.3, KS 3.1 (40.63). DPaint IV Version 4.1 (size 379732 bytes) and again, I'm unable to move DPaint horizontally, only vertically. sure, I'll test again if the release of DPaint is a different one. e-mail? mb @ n4n0.ch

[mikeboss]

indeed, with your version of Deluxe Paint IV (Version 4.0) it's possible to
move the whole window vertically and horizontally! but I'm not seeing any
strange artifacts or behavior on my minimig...

[bloodline]

Originally Posted by mikeboss

indeed, with your version of Deluxe Paint IV (Version 4.0) it's possible to
move the whole window vertically and horizontally! but I'm not seeing any
strange artifacts or behavior on my minimig...

Make sure you are testing in “medium res” (640x256) mode as that is where the most strange effect happens where the bottom of the display is simply not drawn when the display or fetch happens at too far too the right… and I just can’t figure out why.