Heaven/TQA Posted January 4, 2010 Share Posted January 4, 2010 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... Quote Link to comment Share on other sites More sharing options...
drac030 Posted January 4, 2010 Share Posted January 4, 2010 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 5, 2010 Author Share Posted January 5, 2010 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. Quote Link to comment Share on other sites More sharing options...
drac030 Posted January 5, 2010 Share Posted January 5, 2010 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. Quote Link to comment Share on other sites More sharing options...
MarcusATR Posted January 6, 2010 Share Posted January 6, 2010 Save in to .CAS file. Not yet? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 7, 2010 Share Posted January 7, 2010 (edited) 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 January 7, 2010 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 7, 2010 Share Posted January 7, 2010 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 8, 2010 Author Share Posted January 8, 2010 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 8, 2010 Author Share Posted January 8, 2010 (edited) 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 January 8, 2010 by phaeron Quote Link to comment Share on other sites More sharing options...
candle Posted January 8, 2010 Share Posted January 8, 2010 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) Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 10, 2010 Author Share Posted January 10, 2010 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 10, 2010 Author Share Posted January 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
candle Posted January 10, 2010 Share Posted January 10, 2010 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... Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 18, 2010 Author Share Posted January 18, 2010 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. Quote Link to comment Share on other sites More sharing options...
candle Posted January 18, 2010 Share Posted January 18, 2010 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 18, 2010 Share Posted January 18, 2010 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 18, 2010 Author Share Posted January 18, 2010 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 18, 2010 Author Share Posted January 18, 2010 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 vbxe-texttrans.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 18, 2010 Share Posted January 18, 2010 great... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 19, 2010 Share Posted January 19, 2010 Are console keys implemented? Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 20, 2010 Author Share Posted January 20, 2010 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 20, 2010 Share Posted January 20, 2010 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? Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 21, 2010 Author Share Posted January 21, 2010 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 31, 2010 Share Posted January 31, 2010 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. Quote Link to comment Share on other sites More sharing options...
HiroProX Posted February 3, 2010 Share Posted February 3, 2010 (edited) 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 February 3, 2010 by HiroProX Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.