Jump to content
phaeron

Altirra w/VBXE emulation

Recommended Posts

ok... easy game... text mode is "char,color" so actually 0x00,0x08 means space+middle grey... when changing it to 0x01,0x0f we get white "!" filled...

Share this post


Link to post
Share on other sites

phaeron: the presence of "H:" device is dependent on System->Cassette->SIO Patch, when this one is off, the H: device is not present. Why?

 

Besides, as Rybags already pointed out, a write to $d080-$d0ff does not reset VBXE. It has to disable the display, a RESET signal is not enough, because not every reboot is caused by a hardware RESET (one can call the RESETCD $E477 routine in software).

 

Also, the emulator seems to suffer 1-3 sec pauses after any write to a disk image. In this time it seems completely frozen (does not accept keypresses etc., no reaction, no nothing). Windows 7.

Share this post


Link to post
Share on other sites

phaeron: the presence of "H:" device is dependent on System->Cassette->SIO Patch, when this one is off, the H: device is not present. Why?

 

No idea -- they aren't related at all, and H: is put into HATABS on the first call to CIO. Are you using Atari DOS or SpartaDOS to access H:? It's a CIO device, not an SIO device, so it won't work if CIO isn't used.

 

Besides, as Rybags already pointed out, a write to $d080-$d0ff does not reset VBXE. It has to disable the display, a RESET signal is not enough, because not every reboot is caused by a hardware RESET (one can call the RESETCD $E477 routine in software).

 

Implemented in this version:

 

http://www.virtualdub.org/beta/Altirra-1.5-test17.zip

http://www.virtualdub.org/beta/Altirra-1.5-test17-src.zip

 

Also, the emulator seems to suffer 1-3 sec pauses after any write to a disk image. In this time it seems completely frozen (does not accept keypresses etc., no reaction, no nothing). Windows 7.

 

Not sure about this one. If it's completely locking up the emulator and you can't even move the window, then it sounds like something screwing up file I/O, like antivirus gone wild. Altirra re-opens the ATR file every time it does a lazy flush, so that could trigger problems. You'll know if this is the case if switching the write mode to VirtR/W fixes the problem, as that causes all writes to be kept only in memory and never flushed to disk.

 

If only the emulated Atari is locking up, then switch the I/O mode back from Burst to Standard if you have burst mode enabled -- it's possible that the burst is going too fast and SIO is timing out. When burst mode is enabled, Altirra will send data as fast as the I/O routine can take it, up to about 280Kbaud.

Share this post


Link to post
Share on other sites

No idea

 

In version 17 this problem seems to be gone. But the last version I tried was 15 and I am pretty sure that there was a relation, so it seems you have fixed it in meantime.

 

Implemented in this version:

 

It does work.

 

Also, the emulator seems to suffer 1-3 sec pauses after any write to a disk image. In this time it seems completely frozen (does not accept keypresses etc., no reaction, no nothing). Windows 7.

If only the emulated Atari is locking up, then switch the I/O mode back from Burst to Standard if you have burst mode enabled -- it's possible that the burst is going too fast and SIO is timing out. When burst mode is enabled, Altirra will send data as fast as the I/O routine can take it, up to about 280Kbaud.

 

I don't have burst enabled. I use SIO patch and DEVICE SIO /A in CONFIG.SYS under SDX (btw. could you make the I/O sound optional with SIO patch?). It does not freeze the window, only the emulated machine stops (as I said, 1-3 seconds), as it seems, when data is written out to the disk image AFTER the SpartaDOS is done with the transfer; i.e. the freeze occurs not while the write is being done, but 1-2 seconds after it is complete, and then the emulated machine does not react for 1-3 seconds, esp. misses the keypresses. Very unnatural.

 

Couldn't you avoid opening the ATR files and just hold them open all the time? There should be some form of flush() to avoid buffering writen out sectors...

 

Also, I am repeating my request to increase the number of possible SIO devices to 15.

Share this post


Link to post
Share on other sites

Just noticed: copying a VBXE screen to the clipboard results in a streched image if using 80 col text or (presumably) hi res graphics. Perhaps images like those could be streched 200% vertically before being sent to the clipboard.

 

Also, emu is crashing on me if I set up a 1088K machine with VBXE enabled.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Just noticed: copying a VBXE screen to the clipboard results in a streched image if using 80 col text or (presumably) hi res graphics. Perhaps images like those could be streched 200% vertically before being sent to the clipboard.

 

Also, emu is crashing on me if I set up a 1088K machine with VBXE enabled.

 

I've found it crashes on any setup with 1088K

Share this post


Link to post
Share on other sites

Just noticed: copying a VBXE screen to the clipboard results in a streched image if using 80 col text or (presumably) hi res graphics. Perhaps images like those could be streched 200% vertically before being sent to the clipboard.

 

Also, emu is crashing on me if I set up a 1088K machine with VBXE enabled.

 

I've found it crashes on any setup with 1088K

 

Turns out I hadn't implemented 1088K mode properly, as it always disabled the self-test ROM even when extended RAM was not enabled. Fixed in this version:

 

http://www.virtualdub.org/beta/Altirra-1.5-test18.zip

http://www.virtualdub.org/beta/Altirra-1.5-test18-src.zip

Share this post


Link to post
Share on other sites

Also, the emulator seems to suffer 1-3 sec pauses after any write to a disk image. In this time it seems completely frozen (does not accept keypresses etc., no reaction, no nothing). Windows 7.

If only the emulated Atari is locking up, then switch the I/O mode back from Burst to Standard if you have burst mode enabled -- it's possible that the burst is going too fast and SIO is timing out. When burst mode is enabled, Altirra will send data as fast as the I/O routine can take it, up to about 280Kbaud.

 

I don't have burst enabled. I use SIO patch and DEVICE SIO /A in CONFIG.SYS under SDX (btw. could you make the I/O sound optional with SIO patch?). It does not freeze the window, only the emulated machine stops (as I said, 1-3 seconds), as it seems, when data is written out to the disk image AFTER the SpartaDOS is done with the transfer; i.e. the freeze occurs not while the write is being done, but 1-2 seconds after it is complete, and then the emulated machine does not react for 1-3 seconds, esp. misses the keypresses. Very unnatural.

 

Couldn't you avoid opening the ATR files and just hold them open all the time? There should be some form of flush() to avoid buffering writen out sectors...

 

Took me a while to figure out why you were seeing this. It's only happening because your disk images are huge (32MB)... should be fixable by only flushing dirty sectors. For temporary disks, set the disk mode to VirtR/W and it'll run faster.

 

I hate it when emulators hold disk files open -- one of my pet peeves with Atari800WinPlus.

 

The SIO noise occurs whenever the acceleration routine determines that it can't accelerate a disk request, in which case it falls through and a regular SIO transfer occurs. This happens for some extended commands that Altirra doesn't accept, since it mainly emulates an 810/1050. It looks like the status command is the culprit, though, which shouldn't be too hard to handle.

 

Also, I am repeating my request to increase the number of possible SIO devices to 15.

 

Noted... I'll get around to it at some point, but it's lower priority at the moment.

Edited by phaeron

Share this post


Link to post
Share on other sites

Phaeron :)

I don't want to scare You out, but is there any chance You would implement 5200 emulation after all? ;)

(soleyly because of VBXE FX core for 5200 machines)

Share this post


Link to post
Share on other sites

I don't have burst enabled. I use SIO patch and DEVICE SIO /A in CONFIG.SYS under SDX (btw. could you make the I/O sound optional with SIO patch?). It does not freeze the window, only the emulated machine stops (as I said, 1-3 seconds), as it seems, when data is written out to the disk image AFTER the SpartaDOS is done with the transfer; i.e. the freeze occurs not while the write is being done, but 1-2 seconds after it is complete, and then the emulated machine does not react for 1-3 seconds, esp. misses the keypresses. Very unnatural.

 

This version should fix the pausing, and also accelerates the Get Status and Read PERCOM Block commands:

 

http://www.virtualdub.org/beta/Altirra-1.5-test19.zip

http://www.virtualdub.org/beta/Altirra-1.5-test19-src.zip

Share this post


Link to post
Share on other sites

Phaeron :)

I don't want to scare You out, but is there any chance You would implement 5200 emulation after all? ;)

(soleyly because of VBXE FX core for 5200 machines)

 

I don't know much about the 5200 and don't have much interest in it since anything good on it was long ported to the 800. There's also the issue that I'd be reluctant to add 5200 support if it means significantly slowing down 800/XL emulation. Then there's dealing with the mutant joysticks. For now, I'd say it's a bit unlikely.

Share this post


Link to post
Share on other sites

i'm asking because this is only emulator with vbxe support, and 5200 is the only machine supported by vbxe

not much of a diffrence - basically it just xl/xe system with some chips mapped at diffrent addresses - no big deal hardware wise

you already have hard work done, so it shouldn't be any problem at all..

 

ultimatly - its just you who decides...

Share this post


Link to post
Share on other sites

I fixed the bug where the XDL parser didn't properly handle mode lines with XDLC_OVOFF set or with XDLC_TMON+XDLC_GMON=00 and also improved the XDL dumper:

 

http://www.virtualdub.org/beta/Altirra-1.5-test21.zip

http://www.virtualdub.org/beta/Altirra-1.5-test21-src.zip

 

Looked into the TEXTMODE.COM palette issue, and it turns out that happens because that program loads the laoo palette into the VBXE, which doesn't match the default GTIA palette. The laoo palette has a pretty steep grayscale ramp, which implies that there's a nonlinearity in the VBXE RGB output that I'm not accounting for. Doesn't look trivial to fix.

Share this post


Link to post
Share on other sites

laoo palette is used because here in poland we are used to that palette as "best matching" real machine, DAC output of VBXE is linear

Share this post


Link to post
Share on other sites

laoo palette is used because here in poland we are used to that palette as "best matching" real machine, DAC output of VBXE is linear

Most odd. On real hardware, I find the laoo palette an excellent match for GTIA colours. It's only in Altirra that there is a marked difference on a GR.0 blue screen.

Share this post


Link to post
Share on other sites

laoo palette is used because here in poland we are used to that palette as "best matching" real machine, DAC output of VBXE is linear

Most odd. On real hardware, I find the laoo palette an excellent match for GTIA colours. It's only in Altirra that there is a marked difference on a GR.0 blue screen.

 

TEXTMODE.COM sets no_trans mode and clears the screen with $65 attribute, which causes the character background to be color $80... color $80 is in turn loaded with color $94 from the laoo_r/g/b.s files, which is #146e7e. That's turquoise in sRGB. $94 is the correct color index for the standard gr.0 background, but there's still something missing here.

Share this post


Link to post
Share on other sites

Overlay transparency and priority are now implemented:

 

http://www.virtualdub.org/beta/Altirra-1.5-test22.zip

http://www.virtualdub.org/beta/Altirra-1.5-test22-src.zip

 

This change unfortunately slows down the VBXE renderer even more, but I'm thinking it's probably better to leave the hard core optimization until the full feature set is done, as long as the core can still hold real-time.

 

Also attached is the crazy priority test app I used -- would be interested in someone seeing how close the priority emulation is. The remaining unimplemented VBXE features (besides bugs) are:

  • xcolor ($d640 bit 1) is not fully implemented
  • attribute map based collision
  • attribute map hires/CCR switching

post-16457-126385534499_thumb.png

vbxe-texttrans.zip

Share this post


Link to post
Share on other sites

Are console keys implemented?

 

Start/select/option are F2-F4, warm reset is Ctrl+F5. No bindings for XL/XE F1-F4 as of yet.

Share this post


Link to post
Share on other sites

Start/select/option are F2-F4, warm reset is Ctrl+F5. No bindings for XL/XE F1-F4 as of yet.

Great - thanks. Any chance of sticking Help on F1?

 

F1's already used for turbo... but the Help key is on Page Down.

Share this post


Link to post
Share on other sites

A belated thanks for that! :)

 

I just want to say how great the debugger is in Altirra. I'd never had call to use it much before, but after doing some fairly massive code re-writes, the history and "live" console in the emulator is just superb.

 

 

 

Share this post


Link to post
Share on other sites

Rybags: perhaps TGZ will do for you http://drac030.krap.pl/s2vbxe.tgz

 

(repacked it from ARC to TAR under emu, then gzipped under Total Commander).

 

CON.SYS is not extracting by any method under XP. Half the time it says that a so named file already exists. So far, I'm not having any luck in extracting this at all.

 

In addition, extraction of the ARC package fails on both wintel and A8 (SDX 4.42).

Edited by HiroProX

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.

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