Jump to content
IGNORED

Altirra w/VBXE emulation


phaeron

Recommended Posts

Try this version... should fix H: on warm reset and also the VBXE <-> RAMBO mapping:

 

You are a machine, phaeron! How can you crank out these revisions and fixes faster than any of the other A8 emulator maintainers? I think your work is going to become the A8 emulator of choice very soon!!! Keep up the awesome work!

 

Easy: I'm on vacation, I'm ignoring portability and slow CPUs, I have an unnatural affinity for the Atari 8-bit, and my roommate is occupying the PS3.

Link to comment
Share on other sites

Easy: I'm on vacation, I'm ignoring portability and slow CPUs, I have an unnatural affinity for the Atari 8-bit, and my roommate is occupying the PS3.

 

Well ... you better indulge yourself in some Call of Duty: Modern Warfare 2 on the PS3. You've earned it! Enjoy the rest of your holidays, and thank you for all the hard work! :cool:

Edited by dwhyte
Link to comment
Share on other sites

Suggested keymappings for non-alpha characters:

 

Key Mappings.pdf

 

The highlighted areas simply signify changes made to account for the PC keyboard layout, duplicated keys, etc. The codes are the internal codes the emulator should generate whent the given key combo is read from the PC keyboard.

 

Oops - obviously the PC keyboard doesn't have "Help". That should really be "F1".

 

Anyway, can I just echo the sentiments above: the break-neck pace of the updates this past week has been astonishing. I think everyone would agree you've earned a good rest!

Edited by flashjazzcat
Link to comment
Share on other sites

@Phaeron, are there any compatibility disadvantages to always having Vbxe always ticked?

 

Mostly, no -- the ANTIC and GTIA cores are still the same. The main thing that doesn't work is NTSC artifacting, since the NTSC artifact engine can't handle the 14MHz output from the VBXE back-end.

 

You don't want to enable VBXE all the time, though, because the VBXE renderer is much slower than the regular GTIA renderer. It slows down the emulator to about half speed. Without optimizations, this will get worse when attribute map collision is implemented.

 

 

Ok, thanks for that, I did wonder...

Link to comment
Share on other sites

Easy: I'm on vacation, I'm ignoring portability and slow CPUs, I have an unnatural affinity for the Atari 8-bit, and my roommate is occupying the PS3.

 

Well ... you better indulge yourself in some Call of Duty: Modern Warfare 2 on the PS3. You've earned it! Enjoy the rest of your holidays, and thank you for all the hard work! :cool:

 

COD:MF2 over xbox live... ;) not PS3... :)

Link to comment
Share on other sites

Suggested keymappings for non-alpha characters:

 

Key Mappings.pdf

 

The highlighted areas simply signify changes made to account for the PC keyboard layout, duplicated keys, etc. The codes are the internal codes the emulator should generate whent the given key combo is read from the PC keyboard.

 

Oops - obviously the PC keyboard doesn't have "Help". That should really be "F1".

 

Sorry, but I can't agree with these mappings as default. For instance, you have < and > on the PC keyboard mapped to [ and ]. That's accurate from the standpoint that they are Shift+, and Shift+. on both keyboards, but it's confusing if you're actually trying to type a < and >. Similarly, I don't see why it's useful to have the PC arrow keys map to the keycaps on the Atari in a way that they give the non-arrow functions unless you press Ctrl. They're arrow keys -- why not map them as such?

 

The default keyboard layout is designed so that characters that you can type on the PC keyboard map to the same common characters on the Atari keyboard. I could see adding a custom mapping function, but I don't see the reasoning behind changing the default to be more like a raw keyboard mapping. As I mentioned earlier, doing that would also increase the chances of incomprehensible or inaccessible keys on an international keyboard.

Link to comment
Share on other sites

I am having a lot of trouble with the last release of Altirra - when I load an SDX 4.42 car, it will not process keystrokes or recognize drives:

 

post-8623-126213531206_thumb.jpg

 

 

HOwever booting SD3.3 is fine:

 

post-8623-126213535307_thumb.jpg

 

 

When I shut it down it leaves a "remnant" on the screen...

 

post-8623-126213540335_thumb.jpg

 

I wonder what I am doing wrong?

Link to comment
Share on other sites

I am having a lot of trouble with the last release of Altirra - when I load an SDX 4.42 car, it will not process keystrokes or recognize drives:

 

HOwever booting SD3.3 is fine:

 

When I shut it down it leaves a "remnant" on the screen...

 

I wonder what I am doing wrong?

 

You didn't say the last released you used, but....

 

If you used a version between 1.5 test-1 and test-7, it will have mapped keys differently than the way that 1.5 test-8 and above expect. The result is that the A/B/C/D keys on the keyboard will be mapped to the joystick instead of the arrow keys. Use Input > Input Manager > Reset to fix this.

 

For the disk issue, the only thing I can think of is that you need to make sure that you do not have the disk transfer mode set to Burst (standard), which will not work with SpartaDOS X.

Link to comment
Share on other sites

Suggested keymappings for non-alpha characters:

 

Key Mappings.pdf

 

The highlighted areas simply signify changes made to account for the PC keyboard layout, duplicated keys, etc. The codes are the internal codes the emulator should generate whent the given key combo is read from the PC keyboard.

 

Oops - obviously the PC keyboard doesn't have "Help". That should really be "F1".

 

Sorry, but I can't agree with these mappings as default. For instance, you have < and > on the PC keyboard mapped to [ and ]. That's accurate from the standpoint that they are Shift+, and Shift+. on both keyboards, but it's confusing if you're actually trying to type a < and >. Similarly, I don't see why it's useful to have the PC arrow keys map to the keycaps on the Atari in a way that they give the non-arrow functions unless you press Ctrl. They're arrow keys -- why not map them as such?

 

The default keyboard layout is designed so that characters that you can type on the PC keyboard map to the same common characters on the Atari keyboard. I could see adding a custom mapping function, but I don't see the reasoning behind changing the default to be more like a raw keyboard mapping. As I mentioned earlier, doing that would also increase the chances of incomprehensible or inaccessible keys on an international keyboard.

Well, they were a suggestion: I didn't think they'd be perfect. I suppose it depends on what you intend to use the emulator for, but I would think being able to generate all the internal codes somehow - whichever keys you have to press - would be a prerequisite. I think leaving it up to the user to configure (if at all possible) is the best way forward, because it hardly looks as if the few users who are concerned with getting this right will reach a concensus. The simple fact is that while the PC has many more keys than the Atari, there are many codes I simply can't produce in the emulator at this point in time. I'm not complaining at all: your work is absolutely remarkable and I know you'll want to concentrate on VBXE at the moment. We're lucky to see such a great emulator in active devlopment, penned by an author who responds so quickly to user requests and suggestions.

 

I don't really care which keys produce which raw codes, as long as we can produce them all somehow. icon_smile.gif

 

...I think things are getting on top of me at the moment: VBXE is still not syncing properly with my TV...

Edited by flashjazzcat
Link to comment
Share on other sites

I'm using 1.5 test 14....

 

Sometimes 5-10 seconds after I type them in, they get processed and show up on the screen.

 

 

The burst I/O thing solved the disk access under SDX.. now I have to figure out why it is running so SLOW this morning - it was very fast last night.

Link to comment
Share on other sites

I'm using 1.5 test 14....

 

Sometimes 5-10 seconds after I type them in, they get processed and show up on the screen.

 

 

The burst I/O thing solved the disk access under SDX.. now I have to figure out why it is running so SLOW this morning - it was very fast last night.

 

Check if you have the filter mode set to Bicubic, as this may be very slow on some older cards (although 5-10sec. is ridiculous!).

Link to comment
Share on other sites

The simple fact is that while the PC has many more keys than the Atari, there are many codes I simply can't produce in the emulator at this point in time. I'm not complaining at all: your work is absolutely remarkable and I know you'll want to concentrate on VBXE at the moment. We're lucky to see such a great emulator in active devlopment, penned by an author who responds so quickly to user requests and suggestions.

 

I don't really care which keys produce which raw codes, as long as we can produce them all somehow. icon_smile.gif

 

That sounds like a different issue. There should be only 19 scan codes out of the 224 valid that cannot be produced in Altirra:

  • F1-F4 (16 scan codes): I simply don't have a place for these at the moment since F1-F4 are taken. I might stick them on Alt keys.
  • Ctrl+Esc, Ctrl+Shift+Esc: Windows hot keys, can't be used.
  • Ctrl+Shift+Caps: Not passed through by Windows, can't be used.

 

Are you seeing more keys which are not working? I have attached the keyboard mapping chart.

 

One other thing to be aware of is that if your programs are also checking the shift key bit (SKSTAT bit 3), they may act erratically. Altirra sets that to the state of the physical SHIFT key, which may not match the state passed in KBCODE bit 6. This is an inconsistency that I don't think can be solved in a way other than providing a raw keyboard mode.

altirra-keys.pdf

Link to comment
Share on other sites

Now it is flying!!!!!!!!!! Before when it was slow, Windows Task manager was reporting that my System Process was about 50% (who knows why).

 

post-8623-126221753146_thumb.jpg

 

It runs much much MUCH faster in SD3.3a than it does in SDX 4.42.

 

Under 3.3a, My scandisk program will scan a 65 meg ATR sector by sector in about 10 seconds - it takes 45 mins on a real A8 machine and 2-3 minutes in A800WinPlus 3.1 running as fast as possible.

Link to comment
Share on other sites

http://vbxe.atari8.info/download.html

 

the scrolling demo on that side... does not work on Altirra nor in Atari++VBXE?

 

my Blitter examples do not work on Altirra either so I need to adapt them for the new core I guess...

 

does anybody have a simple blitter example which actually work in Altirra?

Link to comment
Share on other sites

http://vbxe.atari8.info/download.html

 

the scrolling demo on that side... does not work on Altirra nor in Atari++VBXE?

 

my Blitter examples do not work on Altirra either so I need to adapt them for the new core I guess...

 

does anybody have a simple blitter example which actually work in Altirra?

 

These are the test programs I used to check scrolling support. They also use the blitter to set up the screen on start.

 

If you are still having trouble getting your blits to work, use the .vbxe command in the debugger to see if the blitter is running, and .vbxe_bl to dump the blit list. Your blit list entries should be 21 bytes apiece and you need to wait until the blitter is complete -- otherwise, you may be aborting it before it completes.

vbxe-scroll.zip

  • Like 1
Link to comment
Share on other sites

Phaeron... I am just going through your text scroll demo... am I right that you are using the blitter to copy the text blit multiple times into memory? the text blit bcb copies one line of 80 chars into the desired vbxe overlay ram?

 

ok... understood...buuuut... what is at $000180? the 0x00,0x08 ?

 

and why are you starting the blitter once? I can not see that you restart the blitter in your fameloop?

 

thanks for letting me know... ;)

Link to comment
Share on other sites

Phaeron... I am just going through your text scroll demo... am I right that you are using the blitter to copy the text blit multiple times into memory? the text blit bcb copies one line of 80 chars into the desired vbxe overlay ram?

 

Yes, this is correct.

 

ok... understood...buuuut... what is at $000180? the 0x00,0x08 ?

 

The program contains an initialization segment that enables the MEMAC A window at $4000-$BFFF, which causes the EXE loader to load the data starting at $4000 into VBXE+$00000. (Looking back, I should have used 16K -- this stomps over the ANTIC display list, which is dangerous.) The $00, $08 data at $4180 is a blank character that is used to initialize the screen memory using a pattern blit.

 

and why are you starting the blitter once? I can not see that you restart the blitter in your fameloop?

 

The blitter is only started once because I only use it for initialization -- the app uses the XDL instead of the blitter to scroll. The frame loop simply computes the overlay address and fine scroll values to poke into the XDL.

Link to comment
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...