I work in "lowest level" kernel development, and we're certainly operating at that layer. As for those kind of hacky solutions, we do try to avoid them, because they are, well, hacky, and therefore often hard to understand, easy to break, etc... but it does happen. Especially in prototyping, were usually anything goes to make something work initially.
Sweet. What changes to Hercules have you been considering? I have had a long running (and maintained!) MVS instance in Hercules for quite a few years now, just for fun.
I want a telnet port connecting directly to the Hercules console when it runs headless, as that is the way it ends up running in Docker. The Hercules console does a lot of heavy lifting that could be implemented at the terminal (as even Windows now has a proper terminal). It went as far as allowing me to connect and see the console transcript, which is pretty already.
Another thing I want that I haven't figured out is to print to my network printers - they all do lpr and ipp, but Hercules direct to socket approach didn't work for me and I need to do more research on that. Ideally, the line in the config could be a pipe command where I could turn the page into PostScript to be netcat it to the printer. or massage it through a converter that took in an IBM line printer EBCDIC stream and spat out ASCII for a "normal" printer.
Great project! Kudos for figuring out all that stuff on your own. Assuming you are actually reading these comments, a few suggestions:
* C compilers that can target 16 bit x86 usually have support for "far pointers", which are 32 bit wide pointers consisting of both a 16 bit segment and a 16 bit offset. You should be able to use that instead of your assembly wrappers. This allows you to directly access screen memory in C, i.e. letting the compiler do the job of setting up the segment registers, which also has the great benefit of not having to push, write, and pop ES for every byte (if you copy a block into screen memory for example, the compiler only needs to set up the destination register once).
* The IVT is correspondingly also a list of FAR pointers. It's a common 16 bit x86 concept. The CPU knows about them, they are also more generally used for far jumps and far calls.
* As others have said, just pick one of the many, many available text mode font ROMs.
* I'm curious how compatible that AMD Elan is to actual PCs. Probably a lot, since by that time PCs were kind of the x86 standard, though not necessarily. The earlier 80186 with its integrated peripherals (interrupt controller etc.) was very incompatible, for example. Shouldn't impede your project, just dictates how easily you can run DOS programs overall.
No, that was BASIC 2.0, and using any DOS commands was extremely awkward.
With the notable exception of listing the directory, which was pretty easy through a trick from the disk drive’s DOS which meant you could load the disk directory “as a program” with a special name, “$”, and then just LIST it. But you see, the drive’s DOS had to sort of go out of its way to make that simple.
If I recall correctly, for Commodores, the equivalent of the disk operating system was handled by the drive itself. If you wanted to do anything beyond a LOAD or a SAVE, you were effectively opening the device then sending a command to the device. The exception was getting a directory, which used the LOAD command (as described earlier) rather than a dedicated command. In my opinion, it is accurate to describe loading a special file in order to retrieve a directory listing as a trick.
Looking at the Apple II and Commodore 64, I think it is fair to say that while the BASIC environments supported varying degrees of disk command they were quite different from what we think of as command interpreters. With Unix shells, anything you can enter into a shell script can be executed from the command line, and vice versa. If memory serves me correctly, anything that could be done from the MS/PC-DOS command line could be done from a batch file (though I don't recall if the opposite is true).
I did not mean it’s a trick users applied, I meant that the developers of the 1541 DOS implemented this very trick. You load a textual representation of the directory into memory as a BAISC program, that’s pretty funky.
And it was precisely done because the straightforward way, which would have been something like opening a sequential channel with a dedicated directory listing command and reading out from it, would have been immensely awkward under BASIC 2.0. Hence the magic “$” program.
It leads to the catch-22 that when saving a BASIC program you cannot tell which filenames are already in use, since you cannot get a directory listing without losing the current BASIC program in memory. All you can do is guess a filename that is probably free.
Yes that was how it worked due to the limitations of the C64 but also the old BASIC that they were using. If you actually used your C64 as a "power user" you'd probably have ponied up for JiffyDOS which in addition to making the disks like 10x faster, had some QoL features like being able to list the disk contents without blowing away the low line numbers in BASIC. It was also extremely easy and common to make your own wedge (a new BASIC command). If you weren't going to use something like the tape drive for instance, you could even have it (or parts thereof) live in the memory where the tape would normally be. JiffyDOS does this, you can't use the tape drive with it at all.
Impressive, but I always wonder how much stability testing goes into these overclocks.
With just the stock tools, I can push my GeForce pretty far (relatively spoken, absolutely nowhere near what "professional" overclockers can achieve, of course), and it may appear stable for many hours, until suddenly it crashes anyway.
So what's the qualification of a "successful" overclock? Is it just passing a benchmark, and after that for all we care it can go up in flames?
These type of mods are for pushing them beyond the limits of what they are released as. You can do something like a shunt mod and EVC to control your core voltage for daily and get pretty good results as long as your cooler on your GPU can handle it. As far as the External Clock gen, there are bugs being worked out right now. It can become a thing, but how soon I can’t give you a time estimation.
In many cases when chasing numbers, yes. In most claims of the “fastest overclock of $thing” the accepted criteria is completing the benchmark without crashing.
Different context but for what it's worth I've been running a mild overclock (3.3GHz to something like 3.6GHz) for about 15 years on a Xeon X5680. Passed days of burnin/stress testing at assembly, and it's been very stable this whole time. It's on nearly 24/7 and is actively used.
And the emails you sent didn't bounce after that?
reply