Jump to content
NRV

Project-M 2.0

Recommended Posts

Unsure if invoking the scanline 240 hires bug would cause DLIs to keep triggering beyond normal display, my guess would be since only PMG can be shown in that area it's a case of probably not for DLIs.

 

Not that I can tell from the schematics. DLI occurs if the delta counter compares equal, that's suppressed in vertical blank, and vertical blank is scanlines 248-7. The hires bug causes ANTIC to send confusing signals to GTIA, but ANTIC itself isn't confused. Similarly, VBI is triggered simply by Y=248, so not much room to go wrong there, either.

 

Sequencing the VBIs with the DLIs is an option but it has to be done exactly right. One extra or missing DLI and you're toast. This includes the first frame, which can be subtly munged if you're not completely studious about clearing every single display state. Testing for the VBI means that at least if you run over somewhere there's a chance the VBI handler will get everything back on track.

 

If you really want to pinch cycles, the STA NMIRES in the VBI handler can go. VBI resets DLI and DLI resets VBI, so it's not normally needed unless you're testing for it in the IRQ routine too.

  • Like 1

Share this post


Link to post
Share on other sites

MCP (XLPaint MAXX) (GR15 interlace, 160x200x16 colors), gfx title: MONSTER_VIDOL

 

original DLI_MCP - 11573 free CPU cycles

 

new IRQ_MCP - 14084 free CPU cycles

monster_irq.zip

  • Like 3

Share this post


Link to post
Share on other sites

IRQ proper version

 

missing command SKCTL = 3 (wrong colors, if file example loaded with POKEY)

irq_proper.zip

Edited by tebe
  • Like 3

Share this post


Link to post
Share on other sites

Nice! .. so basically IRQ's are the "future"? x)

 

Probably I'm going to look at your source to see if I was doing it right all this time..

 

Edit:

Yep it looks similar. From what I see you have two irq's (IRQ and IRQ2), for odd and even frames, one dli (dli0) at the start of the frame (I suppose), to init stimer and irqen, and one vbi.

Also you use the same trick of one irq every two scanlines (this seems to be the fastest way, but needs to burn some cycles in the middle..is that what you do with "#cycle #13"? .. is that Mads?).

The only differences with my code is that I never use a vbi (I deactivate them and just put a dli there, if I need one at the bottom of the screen), to simplify the NMI handler.

Also I only set stimer one time, at the start of a program (not every frame), but my horizontal sync looks more complex because I need to burn some cycles (after calling two "sta wsync" in a row), so the first irq is always called at the same horizontal position (in the scan line).

Edited by NRV

Share this post


Link to post
Share on other sites

Nice! .. so basically IRQ's are the "future"? x)

 

has potential

 

p.s.

#CYCLE #N its Mads command (generated 6502 empty code, N>1)

Share this post


Link to post
Share on other sites

As a DLI replacement you generally have Pokey in the 16 KHz mode and lose use of a channel so some suffering there.

 

Alternate to that is use a single voice in the 1.79 MHz mode though that means you have an IRQ trigger interval of about 259 cycles at best, though maybe desirable for a time-saving kernal situation like Project-M.

 

Alternate to that is persist with the 64 KHz (default) mode though the suffering there is you have granularity of 28 cycles which doesn't fit in with the 114 cycle scanlines.

 

A possible fix could be to walk through a series of AUDF values - I've not investigated that, possibly there might be some usable series that allows reasonable sync of IRQs to a point on the scanline. The advantage of using 64 KHz mode of course is that most 3 voice music would be unaffected and you have a reasonable range of intervals between IRQs available.

  • Like 1

Share this post


Link to post
Share on other sites

Hi,

 

This is my first post here and I want to wish Happy new year to all.

I really like this Wolf3D project on Atari, but I have problem running it with Atari800 emulator under Raspbian Linux on Raspberry Pi.

Colors are messed up and doesnt looks like on a real machine.

It is interesting that the first version (Project-M1) shows the correct colors.

Does this game works properly only on Altrira emulator and whether it can somehow make it to work properly with Atari800 emulator, which is my only choice on Linux?

Edited by retrofan11

Share this post


Link to post
Share on other sites

Atari800 just isn't accurate enough for Project-M.

 

Altirra works okay under Wine, try it out.

 

I use Raspbian Linux on Raspberry Pi 2 and Wine does not support Arm processor, thats why is Atari800 emulator only choice I have.

I was hoping that Project-M author may be able to make a proper version that on Atari800/Win Plus emulator.
He offered something like this earlier in thread and I hope that such a thing is possible...

Share this post


Link to post
Share on other sites

You can always try Atari++. You have to compile yourself, though.

Edited by JoSch

Share this post


Link to post
Share on other sites

If I remember correctly, version 2 was changed to use timer IRQs to give more available CPU time. This requires a very accurate emulator.

Share this post


Link to post
Share on other sites

No, version 1 already used the IRQ timers.. probably is something small, like the differences with the display list that Miker corrected in his version, so it worked again in Atari800WinPlus.

That version should do it.

  • Like 1

Share this post


Link to post
Share on other sites

The big question is : How to get a coder on the A8 to create the best "3D game" with the A8's capabilities?

 

Project-M is marvellous. But, a Wolf 3D clone is possible.... just with some less colours and unusual opcodes of the CPU.

20fps beats even a 386 PC.... and the A8 has the ability of showing typical visuals....

  • Like 1

Share this post


Link to post
Share on other sites

The big question is : How to get a coder on the A8 to create the best "3D game" with the A8's capabilities?

 

Project-M is marvellous. But, a Wolf 3D clone is possible.... just with some less colours and unusual opcodes of the CPU.

20fps beats even a 386 PC.... and the A8 has the ability of showing typical visuals....

Let's use legitimate 802/816 opcodes.

Share this post


Link to post
Share on other sites

The big question is : How to get a coder on the A8 to create the best "3D game" with the A8's capabilities?

 

Do it like "Kickstarter": Collect money and hope for the best...

Share this post


Link to post
Share on other sites

Would it be great if you can utilize the power of the Veronice cartridge in this project.That would give you much extra speed I guess...

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...