morelenmir Posted June 19, 2016 Share Posted June 19, 2016 Does Hias' ROM patch for high speed IO work properly if you are running SDX? I ask because I cannot seem to get the keyboard shortcuts to work nor am I seeing much improvement with reading/writing. Sadly I am unable to test the function on real hardware until I get hold of an AT29C256 EEPROM or blank STM27128 EPROM, but using a patched OS ROM image with Altirra seems to ignore the ctrl+shift+... hooks and the transfer rate to an emulated 128kbps 'fastest speed possible' D1: is not accelerated. In fact if anythign it seems slower, I must stress; I appreciate absolutely there is nothing wrong with the code itself. This is entirely me doing something wrong, but I cannot work out what! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 19, 2016 Share Posted June 19, 2016 (edited) SDX has its own SIO driver, so you'll need DEVICE SIO /A in order to force use of the OS SIO code, otherwise SDX just uses its own SIO driver. You can also use the MAP command to toggle the status of individual drives. EDIT: regarding keyboard shortcuts, ensure the SDX keyboard buffer isn't running. Edited June 19, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 19, 2016 Author Share Posted June 19, 2016 SDX has its own SIO driver, so you'll need DEVICE SIO /A in order to force use of the OS SIO code, otherwise SDX just uses its own SIO driver. You can also use the MAP command to toggle the status of individual drives. EDIT: regarding keyboard shortcuts, ensure the SDX keyboard buffer isn't running. Many thanks as always Jon - I'll give that whirl! Interestingly, on real hardware I can boot in to DO2.5, load 'hisio.com' and then get perfect POKEY divisor 0 transfer over an SIO2PC/SD. However so far no such luck even under that environment in Altirra when employing the patched OS ROM image. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 19, 2016 Share Posted June 19, 2016 Check your emulator acceleration patches, etc. They may be deflecting the patched OS code. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 19, 2016 Author Share Posted June 19, 2016 Check your emulator acceleration patches, etc. They may be deflecting the patched OS code. Will do. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 22, 2016 Author Share Posted June 22, 2016 A bit of a progress report for this one. So, after getting hold of another blank STM27128AFI I was able to first patch the stock 130XE OS ROM with Hias' 'patchrom.com' and then write it on to the EPROM (only once for now until my UV bath arrives from Hong Kong!). Next I changed the 'SIO' entry in my config.sys for SDX so that it read 'DEVICE=SIO.COM /A' in order to make sure it was using the underlying patched code. Writing this on to a flash for the SIDE2 was a fiddly as ever, but not difficult. Finally I swapped out the old OS EPROM for the new one and... Success - under both DOS25 and SDX I get a rattling good POKEY divisor 0 transfer when using the SIO2PC. Excellent! In regards the keyboard hooks that also come with Hias' patch - its hard to tell, but I think they are working as well. There is no visual feedback on the S, N, or H hooks but Ctrl+Shift+Delete does indeed reboot the system. However, under SDX it is essential to enter 'KEY OFF' at the command line or add it to the config.sys file to disable the keyboard buffer just as FJC mentioned above. 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 23, 2016 Share Posted June 23, 2016 DEVICE=SIO.COM /A This cannot work. First, the SIO is not "SIO.COM", it is "SIO.SYS". Second, the '=' character is not a valid separator. It should be: DEVICE SIO /A 3 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 23, 2016 Author Share Posted June 23, 2016 This cannot work. First, the SIO is not "SIO.COM", it is "SIO.SYS". Second, the '=' character is not a valid separator. It should be: DEVICE SIO /A Yep - right you are drac030!!! That was careless on my part and annoyingly I cannot edit my original post to rectify the error.. The command I have in my config.sys is 'DEVICE SIO.SYS /A'. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted June 23, 2016 Share Posted June 23, 2016 Another hint: if you use the U1MB version of SDX (either on U1MB or on Freezer) highspeed won't work out of the box. SDX 4.47 in the U1MB version uses the lower stack area ($0110 and up) during bootup (and maybe other stuff), the highspeed patched OS detects the memory conflict and disables hispeed operation. You can work around that by clearing the highspeed table (SHIFT+CONTROL+S) but I'm not sure if that doesn't mess up SDX operation. BTW: I don't understand why SDX is doing that, as a DOS it should play well with every other program/OS/etc and only use $0700 and up for it's code/data. so long, Hias 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 23, 2016 Share Posted June 23, 2016 (edited) SDX 4.47 in the U1MB version uses the lower stack area ($0110 and up) during bootup (and maybe other stuff), the highspeed patched OS detects the memory conflict and disables hispeed operation. You can work around that by clearing the highspeed table (SHIFT+CONTROL+S) but I'm not sure if that doesn't mess up SDX operation. BTW: I don't understand why SDX is doing that, as a DOS it should play well with every other program/OS/etc and only use $0700 and up for it's code/data. I tend to disagree with the latter statement: a DOS (and so also SDX) is a part of the operating system, so, contrary to the application programs' case, it is free to use any system memory, including the areas below the $0600, especially if it is using them temporarily only, at the time of system startup. On the contrary, no software, especially system software, is allowed to claim a part of the stack as a permanently allocated, private area, and expect that no other software would overwrite it, because the very nature of the stack is such that this sort of safety cannot be warranted. That said, I would want you to be assured that I perfectly know the struggle which involves allocating any additional memory for any additional OS functions anyone can imagine. Edited June 23, 2016 by drac030 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted June 23, 2016 Share Posted June 23, 2016 On the contrary, no software, especially system software, is allowed to claim a part of the stack as a permanently allocated, private area, and expect that no other software would overwrite it, because the very nature of the stack is such that this sort of safety cannot be warranted.I absolutely agree with you on that. We all know that such a thing is risky and can fail - be it an OS, a DOS or some other program. But I don't understand why SDX is doing that (there's also the formatter problem, using stack area for it's screen). I think it should be no problem to reserve half a page (or whatever is needed) somewhere at $7xx/$8xx or wherever the fixed address locations of SDX end. That could be at a fixed address as well, whatever is needed. The result would be quite an improvement in compatibility. so long, Hias 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 24, 2016 Share Posted June 24, 2016 (edited) But I don't understand why SDX is doing that Is doing what? The SDX is only using the stack area at early startup, technically it is a hack of course, but inside the reset routine, before even the display gets opened, the stack is not supposed to be heavily used at that time. Quite contrary, a ROM-based operating system cannot store any data at the stack area and rationally expect them to be undisturbed after a call to any external program - and a cartridge is certainly an external program, is not it? (there's also the formatter problem, using stack area for it's screen). That is true. We are planning to move the formatter data from that area in the future. Still, the formatter is not claiming this area permanently, it is using it temporarily only. If anything else (like a TSR program) is claiming that memory permanently, then it is doing it at own risk. I think it should be no problem to reserve half a page (or whatever is needed) somewhere at $7xx/$8xx or wherever the fixed address locations of SDX end. That could be at a fixed address as well, whatever is needed. The result would be quite an improvement in compatibility. Do you really believe that there is 128 bytes or more of free memory ("half of a page of whatever is needed") "somewhere at $7xx/$8xx" under SDX? Edited June 24, 2016 by drac030 1 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted June 24, 2016 Share Posted June 24, 2016 (edited) Do you really believe that there is 128 bytes or more of free memory ("half of a page of whatever is needed") "somewhere at $7xx/$8xx" under SDX?Being a DOS SDX has full control over MEMLO. You have several officially documented absolute addresses/entry points. So if you need some internal buffer at a fixed address (eg for the formatter screen) you should be able to put that behind the officially documented addresses and shift up the dynamically managed memory area behind that and raise memlo a bit. My point being: SDX can create free memory blocks, other (legacy) programs, TSRs etc can't. so long, Hias Edited June 24, 2016 by HiassofT Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 25, 2016 Share Posted June 25, 2016 So if you need some internal buffer at a fixed address (eg for the formatter screen) you should be able to put that behind the officially documented addresses and (...) raise memlo a bit. Technically it is of course true, except that I do not consider 128 bytes "a bit", especially if it has to be a buffer for something used so rarely as the formatter probably is. As I said above, the plan is a bit different: to move the formatter buffer to the actual DOS buffers, and move the display data to the place where the buffer currently is residing. But still, the current solution has some downs, but not so much (in my opinion) as keeping something resident at the stack and expecting it to be undisturbed. 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted September 19, 2018 Author Share Posted September 19, 2018 (edited) I am resurrecting the question asked in this thread, although under a slightly different usage scenario. As things stand I am running an U1MB in a physical 130XE. I have patched the stock 130XE OS using Hias's 'patchrom' and then flashed this to one of the OS slots of the U1MB. I have then selected this patched OS to be the active one. I am of course aware the U1MB has its own mechanism for patching the OS on the fly. However it needs the PBI BIOS to be active to do so and since I also want high-speed SIO when all features of the U1MB are switched off I am now experimenting with the patched OS setup as just described. Plus I rather like the 'Ctrl+Shift DEL' reboot! So, machine boots properly with patched OS. If I now try to copy a large file to test the high-speed OS at POKEY 0 throughput I get only normal--slow--speed SIO traffic. However if I use the 'Ctrl+Shift S' shortcut--which Hias documents as activating the high-speed OS--and try again the SIO transfer now runs at the rattling POKEY 0 rate. My question; is it possible to enable high-speed SIO traffic at boot up/switch-on without having to 'Ctrl+Shift S' each time? Edited September 19, 2018 by morelenmir Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 19, 2018 Share Posted September 19, 2018 (edited) According to the documentation, if you patch using 'HISIORK.COM' and then dump the resulting OS using the provided tool, the resulting ROM lacks the hotkeys, which presumably means HSIO is active by default. The High-Speed OS provided with the original U1MB ROMs is probably suitable for your needs, if you can locate a copy. A patched OS is no doubt useful for any applications (if they exist) which for some reason refuse to work with the U1MB PBI BIOS (whose HSIO driver may be used with cartridges), but the patched OS - since it needs to store the speed index table some place - probably introduces its own set of corner-case incompatibilities. The other thing to remember is that the U1MB BIOS has its own (optional) coldstart hotkey (Select+Reset) which operates completely independently of any other feature. I think this should be the High-Speed OS from the original firmware: hsos.zip Edited September 19, 2018 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted September 19, 2018 Author Share Posted September 19, 2018 According to the documentation, if you patch using 'HISIORK.COM' and then dump the resulting OS using the provided tool, the resulting ROM lacks the hotkeys, which presumably means HSIO is active by default. The High-Speed OS provided with the original U1MB ROMs is probably suitable for your needs, if you can locate a copy. A patched OS is no doubt useful for any applications (if they exist) which for some reason refuse to work with the U1MB PBI BIOS (whose HSIO driver may be used with cartridges), but the patched OS - since it needs to store the speed index table some place - probably introduces its own set of corner-case incompatibilities. The other thing to remember is that the U1MB BIOS has its own (optional) coldstart hotkey (Select+Reset) which operates completely independently of any other feature. Hey Jon! Nice to hear from you! Yeah, I was wondering about patching the stock ROM with 'patchrom.exe' and using the switch to do so without the keyboard shortcut section enabled just to see if that did the trick. A few years ago I had a patched version written to an UV-window EPROM and I seem to think it worked without needing the shortcuts to be toggled. However that was in an all-but stock machine without U1MB or anything else. In regards U1MB--yep, in almost every situation it is easier to use the on-the-fly patching it offers, but sometimes I do just like to switch everything off and type in games from Page 6 as if it were 1989 again. Although admittedly as if it were 1989 with POKEY 0 transfer!!! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 19, 2018 Share Posted September 19, 2018 (edited) I have uploaded the desired ROM in case it's been missed. Note: the uploaded ROM runs high-speed by default and I believe it preserves the coldstart shortcut. Note the U1MB does not patch anything on the fly. It simply implements a PBI SIO driver which the OS runs before resorting to the OS serial IO handler. Edited September 19, 2018 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted September 19, 2018 Author Share Posted September 19, 2018 (edited) I have uploaded the desired ROM in case it's been missed. Note: the uploaded ROM runs high-speed by default and I believe it preserves the coldstart shortcut. Note the U1MB does not patch anything on the fly. It simply implements a PBI SIO driver which the OS runs before resorting to the OS serial IO handler. That is interesting! I thought you basically injected your code each time it was switched on--which led me to be a little puzzled as why it didn't work without the PBI BIOS. However, now you explain it the situation make complete sense! What we need is a mod which expands the size of the PBI BIOS in some way--perhaps banked external memory that swaps out so quickly the A8 is non-the-wiser but that would give you a huge amount of memory to write your PBI stuff in! Anyway--as an aside... yep... My XE is now working again and--every appendage crossed three times!--seems to be doing so properly too! I'll PM you with the gory details! Edited September 19, 2018 by morelenmir Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 19, 2018 Share Posted September 19, 2018 (edited) Glad to hear things are working. Don't forget to download the ROM I added to post #16, since it's exactly what you were trying to accomplish. That is interesting! I thought you basically injected your code each time it was switched on--which led me to be a little puzzled as why it didn't work without the PBI BIOS. On-the-fly patching would certainly require a RAM-based OS (drawback number one), and given the variety of custom operating systems such a patcher might be confronted with, the PBI solution is wholly more elegant and reliable. What we need is a mod which expands the size of the PBI BIOS in some way--perhaps banked external memory that swaps out so quickly the A8 is non-the-wiser but that would give you a huge amount of memory to write your PBI stuff in! More PBI ROM and RAM would be most welcome (enabling - among other things - the loader to exist entirely in PBI-land), but that would basically require a completely new upgrade. Since I'm kept entirely in the dark about second and third revisions of existing devices in which I am supposedly involved at the software level (and not consulted in any way regarding hardware specifications), I will not hold my breath. Edited September 19, 2018 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 19, 2018 Share Posted September 19, 2018 (edited) kind of tough to put into words, If you don't know things and find out all a thing can do, you get awesome things out of something that it might not have been designed to do. If you knew what it was designed to do, you might only do those things. Then we all lose. If you take the first path and then all of the designed paths are revealed after the fact, then you can perfect everything and add all of it together and do even more. Now if they chose to keep you as a mushroom- in the dark and fed bull sh*t or nothing at all- then they do everybody a disservice! They should listen to all you have told them about previous devices to improve the new ones, and if they are hitting a wall as to or about some of those ideas. If you don't know the nuts and bolts, your descriptions can guide them to a solution, you don't need to know everything to help someone do everything. At some point I really do think you need to be brought in on the process, I just wish they did! Edited September 19, 2018 by _The Doctor__ 4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 19, 2018 Share Posted September 19, 2018 I appreciate that sentiment, truly. The impression I get is that replacing a device's firmware does not guarantee friends and influence with anyone but the end-user. Projects take twice as long if the wheel is re-invented each time, but who knows. Let's just wait and see. 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted September 19, 2018 Author Share Posted September 19, 2018 I think I understand the sub text here... Not entirely cheery as I have been looking forward to the release of the afore-alluded projects! ..and ROM downloaded! 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.