vazquezrick Posted July 24, 2015 Share Posted July 24, 2015 I reflashed everything and wala it works now. In addition I turned on HD support. Sent from my iPhone using Tapatalk Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 24, 2015 Author Share Posted July 24, 2015 Great: thanks for confirmation. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted July 27, 2015 Share Posted July 27, 2015 It is not specifically the BIOS at fault, but is directly related to re-flashing it. I create a *.ATR image which holds the newest beta 'uFlash' from your site and a customized ROM for SDX to flash in to the "Ultimate1MB" - attached below. I then mount this as a drive on the "SIO2SD". SDX itself sees this drive along with its contents properly and will write/read them without any problems. However, once inside 'uFlash' if I highlight the SpartaDOS slot and hit return to flash it I am immediately presented with an error which says it cannot read the drive - the drive that is mounted through "SIO2SD" and 'uFlash' has itself been loaded from... It does not seem to be the *.ATR image itself at fault as 'uFlash' behaves properly when it is mounted using 'SIDELoader' or 'MATR'. U1MB SDX.rar Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 28, 2015 Author Share Posted July 28, 2015 Hmmm... problems abound, since my copy of WinRAR cannot even decode the archive you posted. In the absence of anything I can look at, I can only say that uFlash accesses files via DOS and standard CIO calls, so should not discriminate (nor even be able to) between different methods of disk image mounting. If DOS can access certain areas of the ATR when it is mounted by the PBI BIOS which are inaccessible when it is mounted under SIO2SD, the discrepancy would appear to be with the ATR itself or the methods of mounting (rather than DOS or the application), but once I'm able to open the archive, I'll see if I can reproduce the issue. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted July 28, 2015 Share Posted July 28, 2015 Hmmm... problems abound, since my copy of WinRAR cannot even decode the archive you posted. In the absence of anything I can look at, I can only say that uFlash accesses files via DOS and standard CIO calls, so should not discriminate (nor even be able to) between different methods of disk image mounting. If DOS can access certain areas of the ATR when it is mounted by the PBI BIOS which are inaccessible when it is mounted under SIO2SD, the discrepancy would appear to be with the ATR itself or the methods of mounting (rather than DOS or the application), but once I'm able to open the archive, I'll see if I can reproduce the issue. Are you using a WinRAR which supports RAR5 archives? I'll recompress it with the older scheme - it won't make a lot of difference at this size anyway I doubt. What you describe is pretty much how I would have thought it should work; 'uFlash' not having its own routines but using DOS. As I say the archive is properly read when it is mounted through other means, but with the "SIO2SD" I get an error message. However, the same "SIO2SD" mount will work properly with SDX for read, write and copy. Odd. Update: I have experimented a little further. The error messages I get are first of all 'Error Device not responding' and then if I hit return again while still in the 'file open' dialogue box I get 'Error #$8E'. However, if I set the 'SIO2SD' to use the lowest 'HiSpeed' setting of $10 then 'uFlash' ceases to give the error and properly recognized the contents of the mounted image... Yet no other application - including SDX - has any trouble communicating with the "SIO2SD" when in 'HiSpeed' $0. More and more odd. U1MB SDX.rar Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 28, 2015 Share Posted July 28, 2015 I also get an error with WinZip 16.5 Pro. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted July 28, 2015 Share Posted July 28, 2015 2nd one works in winrar 3.60... Quote Link to comment Share on other sites More sharing options...
Muzz73 Posted July 28, 2015 Share Posted July 28, 2015 This looks great! Looking forward to the Incognito version (if I ever get mine installed). Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 28, 2015 Author Share Posted July 28, 2015 Are you using a WinRAR which supports RAR5 archives? I'll recompress it with the older scheme - it won't make a lot of difference at this size anyway I doubt. What you describe is pretty much how I would have thought it should work; 'uFlash' not having its own routines but using DOS. As I say the archive is properly read when it is mounted through other means, but with the "SIO2SD" I get an error message. However, the same "SIO2SD" mount will work properly with SDX for read, write and copy. Odd. Update: I have experimented a little further. The error messages I get are first of all 'Error Device not responding' and then if I hit return again while still in the 'file open' dialogue box I get 'Error #$8E'. However, if I set the 'SIO2SD' to use the lowest 'HiSpeed' setting of $10 then 'uFlash' ceases to give the error and properly recognized the contents of the mounted image... Yet no other application - including SDX - has any trouble communicating with the "SIO2SD" when in 'HiSpeed' $0. More and more odd. ZIP files are preferable anyway, if you must compress the ATR at all. It's helpful that you mention that you're using a low Pokey divisor when the problem crops up. It therefore has nothing at all to do with the application: the problem exists at the SIO driver (DOS) level. Quote Link to comment Share on other sites More sharing options...
Marius Posted July 28, 2015 Share Posted July 28, 2015 I never understood all the fuzz around low pokey divisors at all in the first place. Of course it is great to get high speed through Sio, but the chance that it fails is big too. There are circumstances enough where even happy high speed doesn't work without issues, since custom created VBI routines result in I/O that got stuck all the time (pressing break to get further). I remember BBS software BBS PRO! 5.0b which was not able to run on 3x sio speed with APE, since the entire software did run in some kind of "shell". When it comes to speed I only rely on parallel I/O (like on PBI). Please don't expect your atari or software to work properly in any situation, and with every software, with this high speed sio. 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted July 28, 2015 Share Posted July 28, 2015 Okay. Thanks for looking at it. Incidentally, I am using your HiSpeed patch from the BIOS on drives 1-4, one of which was mounted when this issue appeared. In regards PBI over faster SIO. I agree - even at POKEY divisor 0 there is a noticeable difference in speed to the "SIDE2" doing its thing. However I am trying to do away with reliance on the "SIDE2" and replace it with the "SIO2SD" to leave the slot empty for cartridge uses. Therefore anything which helps improve SIO is a positive thing for me. I guess when flashing I'll just lower the divisor temporarily. ZIP in 2015??? :) I've been a loyal RAR user since 1999 and the ZIP format was already outdated even then! I did briefly try "WinACE" during 2000 but in the end found it an unstable and buggy app. If I didn't have a subscription to RARLabs I would probably use "7Zip" though - but that is a totally different compression algorithm and only maintains the 'zip' tag as a nod to the past. In future I'll package my compressed uploads as a self-extracting archive for ease of distribution. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted July 29, 2015 Share Posted July 29, 2015 ZIP in 2015??? :) Yes, because EVERYTHING supports it pretty much, if it supports ANY compression at all. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 29, 2015 Author Share Posted July 29, 2015 (edited) Incidentally, I am using your HiSpeed patch from the BIOS on drives 1-4, one of which was mounted when this issue appeared. And you have configured the SDX SIO driver to bypass its own high-speed SIO code and instead use that provided via the OS SIO vector? Otherwise you're not using the (Hias) High-Speed PBI code at all when you access the problem drive. I agree - even at POKEY divisor 0 there is a noticeable difference in speed to the "SIDE2" doing its thing. However I am trying to do away with reliance on the "SIDE2" and replace it with the "SIO2SD" to leave the slot empty for cartridge uses. Therefore anything which helps improve SIO is a positive thing for me. The difference in speed isn't really subjective: it's because IDE transmission occurs at c. 65KB/s, and the ATR mounting uses the same mechanism but with buffered transfers. SIO divisor 0 is still slower than buffered IDE transmission. If the issue in question does not lie with the high-speed implementation in the PBI BIOS, the next areas of investigation will presumably be SDX SIO drivers, hardware, and the SIO2SD firmware itself. ZIP in 2015??? :) I've been a loyal RAR user since 1999 and the ZIP format was already outdated even then! I did briefly try "WinACE" during 2000 but in the end found it an unstable and buggy app. If I didn't have a subscription to RARLabs I would probably use "7Zip" though - but that is a totally different compression algorithm and only maintains the 'zip' tag as a nod to the past. In future I'll package my compressed uploads as a self-extracting archive for ease of distribution. Well, uploading recent revision RAR archives already proved to be not the most expedient method of sharing material with your narrator, who is using an old version of WinRAR. As Joey said: ZIP is ubiquitous and usable without third party tools. As for self-extracting archives: I doubt I would even touch a self-extracting archive of an ATR file. ZIP is just fine. Edited July 29, 2015 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 5, 2015 Author Share Posted August 5, 2015 (edited) Small update to allow use of padded versions of 800 OS-A and OS-B with Ultimate: ulbios30.zip Thanks to DrVenkman for testing. Since everything else appears to work, I'll look at finalising both the Ultimate and Incognito BIOS in the next few weeks. Edited August 5, 2015 by flashjazzcat 3 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted August 6, 2015 Share Posted August 6, 2015 Not a bug report, just an observation. I cannot get "The!Cart" and the 'PBI BIOS' to live happily together. In fact, in order to get "The!Cart" to boot at all I must first switch off all the "Ultimate1MB"'s extended memory - which makes sense as I imagine it conflicts with the 512kB "The!Cart" also carries. However I must also disable both the PBI BIOS, internal SDX and the VBXE. If I leave any of these running it will either hang at the point immediately following the 'PBI BIOS 1.3' message appearing on screen or crash altogether to an interesting but unhelpfully smeared display. Once I have effectively disabled much of the "Ultimate1MB"'s features, "The!Cart" then begins to work nicely - however that is a rather limiting situation, especially the lack of the VBXE. In regards the several different MultiCarts available, the "Ultimate1MB" and its attendant BIOS features; are there any combinations which are known to coexist happily? Perhaps Steven Turner's 'MaxFlash' 1mBit and 8mBit entries? Quote Link to comment Share on other sites More sharing options...
HiassofT Posted August 6, 2015 Share Posted August 6, 2015 I cannot get "The!Cart" and the 'PBI BIOS' to live happily together. In fact, in order to get "The!Cart" to boot at all I must first switch off all the "Ultimate1MB"'s extended memory - which makes sense as I imagine it conflicts with the 512kB "The!Cart" also carries. However I must also disable both the PBI BIOS, internal SDX and the VBXE. are known to coexist happily? Perhaps Steven Turner's 'MaxFlash' 1mBit and 8mBit entries?The!Cart is working fine here, regardless of memory configuration in U1MB or if PBI BIOS is on/off. But I don't have a VBXE installed in my 800XL. The VBXE might be the thing that makes the difference. Some time ago I emailed with tfhh, he discovered strange issues in Ataris equipped with U1MB and VBXE. Both The!Cart and MyIDE (IIRC it was the newer version 2) didn't work properly in those machines. Removing either the U1MB or the VBXE fixed things. so long, Hias Quote Link to comment Share on other sites More sharing options...
morelenmir Posted August 6, 2015 Share Posted August 6, 2015 The!Cart is working fine here, regardless of memory configuration in U1MB or if PBI BIOS is on/off. But I don't have a VBXE installed in my 800XL. The VBXE might be the thing that makes the difference. Some time ago I emailed with tfhh, he discovered strange issues in Ataris equipped with U1MB and VBXE. Both The!Cart and MyIDE (IIRC it was the newer version 2) didn't work properly in those machines. Removing either the U1MB or the VBXE fixed things. so long, Hias Fair enough! I think this is one to chalk down to 'live and learn' - a little disappointing but "The!Cart" seems to work properly in itself which is very nice to have. I only mention it here because it seems key that I disable the PBI BIOS to get 'The!Cart' to work. So I wondered if this was a known issue I had not come across myself with a standard workaround I had not thought of yet. I may try re-flashing to the old v1.0 BIOS and see if that makes any difference - as a purely experimental measure. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 6, 2015 Author Share Posted August 6, 2015 (edited) Another update (for Ultimate and Incognito respectively): ulbios31.zip inbios31.zip This fixes a small bug, found and reported by Pasiu, which resulted in a crash if the Return key was hit on a menu with no selectable items (i.e. the System Information page). Pasiu also provided some very interesting information regarding strange issues of a type I only ever previously heard about from one other user, who - by coincidence - was also from Poland. The most obvious issue is menu corruption, typified by this kind of effect: This suggests to me that the NMI responsible for managing the quite complex PMG overlays and colour changes simply did not fire at the appropriate points, or the index to its jump table became hopelessly corrupted. On one occasion I witnessed something similar on a machine of my own, but thought it to be caused by a loose VBXE Antic adapter (which might upset the address bus), and sure enough, securing the adapter seemed to fix the problem. In any case: two reports of similar problems are enough to make me think it's something well worth investigating, and Pasiu has kindly agreed to perform further tests. Pasiu also has a Rapidus accelerator, and reported a couple of issues when the machine is running in 65C816 mode. Unfortunately I have no access to Rapidus (and it's not specifically emulated, although the 65C816 is), so again I'm reliant on Pasiu and anyone else with appropriate hardware to ensure things work properly. One problem reported was the inability to easily set the system clock in 65C816 mode. I'm unable to test this, since Altirra, although it emulates the 65C816, does not accept edits to the emulated DS1305 RTC NVRAM (the clock permanently reflects the system time/date of the host PC). Most of the above issues are likely very simple fixes, and as well as finishing up some of the incomplete BIOS features, I'd like to focus on eliminating these issues. PS: we might also consider issues with the stock 64KB RAM, I guess, since the NMI jump table counter resides in base RAM. PPS: Looking again at that screenshot, it appears that the NMI is simply not running at all. Edited August 6, 2015 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted August 6, 2015 Share Posted August 6, 2015 Jon, If you have an 800 with a 6502 instead of C014806, you may directly plug in a 65c802 chip. Run one jumper on the CPU board, and then you can pop in an 816. Jumper from pin 5 of Z302 74LS74 to pin 36 of A303 CPU. I'd love to help test but, unfortunately, my Atari stuff is boxed up. I'm hoping to be able to set it up soon. Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted August 7, 2015 Share Posted August 7, 2015 Jon, The incognitos Machine type is scrambled characters after putting this newest Bios on, but the return key lock up is fixed.. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 7, 2015 Author Share Posted August 7, 2015 Thanks man. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 7, 2015 Author Share Posted August 7, 2015 The incognitos Machine type is scrambled characters after putting this newest Bios on, but the return key lock up is fixed. Interesting, since looking at the code I can't see how machine type could ever have displayed properly on NTSC machines in prior builds. Incognito uses bit 1 of MachineType to denote NTSC, so the index into the string list is 0-3 (PAL XL/XE, PAL XEGS, NTSC XL/XE, NTSC XEGS). The Incognito string array only has two elements: PAL 800 and NTSC 800, so setting bit 1 should always result in garbage. I've changed it so that the Incognito BIOS simply sets bit 0 for NTSC, so it should work now: inbios32.zip Unfortunately I can't test it here, since I have no NTSC Incognito 800. Let me know if it works. If you have an 800 with a 6502 instead of C014806, you may directly plug in a 65c802 chip. Run one jumper on the CPU board, and then you can pop in an 816. Jumper from pin 5 of Z302 74LS74 to pin 36 of A303 CPU. Interesting idea. But this would still run at stock frequency, and I think the troubles revolved around setting the system clock with a fast CPU - although I'm unable to visualise this issue, since the key delay is tied to the vertical blank and time/data field elements do not refresh while they're being edited. However, Pasiu did also say that the CPU was being misidentified when Rapidus is used, although that's puzzling too, since the BIOS uses a tried and tested CPU identification algorithm which works in emulation. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 7, 2015 Author Share Posted August 7, 2015 Pasiu also provided some very interesting information regarding strange issues of a type I only ever previously heard about from one other user, who - by coincidence - was also from Poland. The most obvious issue is menu corruption... Well, some sort of good news concerning this: the two Polish machines are actually one and the same, so there's only one Atari exhibiting the NMI bug, not two. Quote Link to comment Share on other sites More sharing options...
w1k Posted August 7, 2015 Share Posted August 7, 2015 flashed on real hw and works nice u1mb.. i like it, because my u1mb settings is still saved, no changes:) Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted August 7, 2015 Share Posted August 7, 2015 I've changed it so that the Incognito BIOS simply sets bit 0 for NTSC, so it should work now: inbios32.zip Unfortunately I can't test it here, since I have no NTSC Incognito 800. Let me know if it works. Machine type: 800 (NTSC) No longer scrambled with inbios32.rom Thanks 1 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.