152 replies to this topic

[phaeron]

dwhyte, on Mon Dec 28, 2009 6:58 PM, said:

phaeron, on Mon Dec 28, 2009 6:55 PM, said:

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.

[dwhyte]

phaeron, on Tue Dec 29, 2009 4:19 AM, said:

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!

Edited by dwhyte, Tue Dec 29, 2009 4:56 AM.

[flashjazzcat]

Suggested keymappings for non-alpha characters:

 Key Mappings.pdf   185.66K   78 downloads

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, Tue Dec 29, 2009 5:26 AM.

[Mclaneinc]

phaeron, on Mon Dec 28, 2009 3:03 PM, said:

Mclaneinc, on Mon Dec 28, 2009 7:00 AM, said:

@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...

[Heaven/TQA]

dwhyte, on Tue Dec 29, 2009 4:56 AM, said:

phaeron, on Tue Dec 29, 2009 4:19 AM, said:

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!

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

[dwhyte]

Heaven/TQA, on Tue Dec 29, 2009 2:12 PM, said:

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

Naw, I prefer only having to pay for my ISP, rather than dishing out extra money for Microsoft's service. Besides ... the PS3 is clearly the more powerful machine; but that is a debate for another forum.

[Heaven/TQA]

yup... another battle... 360 vs ps3... xbox live! vs nothing or today "home"...

[phaeron]

flashjazzcat, on Tue Dec 29, 2009 5:17 AM, said:

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.

[bf2k+]

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?

[phaeron]

bf2k+, on Tue Dec 29, 2009 7:10 PM, said:

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.

[flashjazzcat]

phaeron, on Tue Dec 29, 2009 5:14 PM, said:

flashjazzcat, on Tue Dec 29, 2009 5:17 AM, said:

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.

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

Edited by flashjazzcat, Wed Dec 30, 2009 4:54 AM.

[bf2k+]

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.

[phaeron]

bf2k+, on Wed Dec 30, 2009 8:34 AM, said:

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!).

[phaeron]

flashjazzcat, on Wed Dec 30, 2009 4:51 AM, said:

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.

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.

Attached Files

•  altirra-keys.pdf   40.25K   34 downloads

[bf2k+]

My filter mode was set to Bilinear. Here's the problem...



Last night I saw 160 fps and it was nice and fast - time to reboot.

[bf2k+]

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



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.

[Heaven/TQA]

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?

[tebe]

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

this examples is for oldest core, oldest PCB, firmware etc.

this site http://vbxe.atari8.info/ is so old, and not actual (2007 year)

[Heaven/TQA]

tebe... where can I find latest examples & demos?

[phaeron]

Heaven/TQA, on Fri Jan 1, 2010 5:33 PM, said:

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.

Attached Files

•  vbxe-scroll.zip   8.22K   24 downloads

[candle]

to all:
You can find newest version of VBXE pack at http://spiflash.org/...bxe/release.zip no matter what
I'm going to get VBXE subpage on spiflash.org, but i'm just one man with limited time resources

Sebastian

[Heaven/TQA]

thx Candle this file I have searched...

Phaeron... your 2 scroll files do not scroll?

[Heaven/TQA]

ah... cursor keys to scroll around...

[Heaven/TQA]

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...

[phaeron]

Heaven/TQA, on Sun Jan 3, 2010 3:20 PM, said:

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.

Quote

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.

Quote

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.