Re: [Freedos-user] New FASM and NASM versions available
On Wed, May 01, 2019 at 09:05:35PM -0500, Rugxulo wrote: > We're talking about the host platform, not the target. Yes, you can still > assemble with NASM (or YASM or FASM) for 8086 target, but none of those > assemblers themselves can (easily) be rebuilt to run hosted on 16-bit > machines anymore. Well my "host platform" obviously is 16 bit - since it's FreeDOS. But yes, I was indeed somewhat amazed at "mammoth size" of NASM binary, compared, as example, to modest 33 KB of A86.COM. > DJGPP is 32-bit pmode, DPMI. Also, NASM has required C99 compiler support > for many years, which almost none of the pre-existing 16-bit compilers > support (even OpenWatcom is incomplete). > > It's not that big a deal. 386 compatibles have been around for decades. I > just wanted to briefly mention that there were 16-bit NASM builds back in > the day since some of us are still sympathetic (at least in theory). > > N.B. The 8088 [sic] turns 40 this year. That's the one the original IBM PC > used. The one "slower than Commodore 64" ;) https://trixter.oldskool.org/2011/06/04/at-a-disadvantage/ #v+ Quick, without doing any research: What early 1980s computer was faster, the IBM PC or the Commodore 64? The IBM PC ran an 8088 at nearly 5MHz, whereas the C64 ran a 6502 variant at 1MHz. The PC cost thousands of dollars, the C64 hundreds. The PC had a 1 megabyte address space; the C64 only 64K. Is this a trick question? It is! The C64 was faster. The original IBM PC, despite appearances and bias on the part of both consumers and marketing, was actually the slowest popular personal computer on the market at the time of its release, even compared to the Apple II and Atari 400. Here's why. [..] What took 6 cycles on the C64 takes 37 cycles on the IBM PC #v- -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New FASM and NASM versions available
On Thu, May 2, 2019 at 8:32 AM ZB wrote: > On Wed, May 01, 2019 at 09:05:35PM -0500, Rugxulo wrote: > > N.B. The 8088 [sic] turns 40 this year. That's the one the original IBM PC > > used. > > The one "slower than Commodore 64" ;) > > https://trixter.oldskool.org/2011/06/04/at-a-disadvantage/ > > #v+ > Quick, without doing any research: What early 1980s computer was faster, > the IBM PC or the Commodore 64? The IBM PC ran an 8088 at nearly 5MHz, > whereas the C64 ran a 6502 variant at 1MHz. The PC cost thousands of > dollars, the C64 hundreds. The PC had a 1 megabyte address space; > the C64 only 64K. Is this a trick question? > > It is! The C64 was faster. The original IBM PC, despite appearances and > bias on the part of both consumers and marketing, was actually the slowest > popular personal computer on the market at the time of its release, even > compared to the Apple II and Atari 400. Here's why. > [..] > What took 6 cycles on the C64 takes 37 cycles on the IBM PC > #v- Did you ever actually *use* a C64? I logged time on both the original IBM PC and the Commodore 64, and that answer is at best misleading. It was popular back in the day but depended on what you were measuring, and what you were trying to do with the machine. The C64 ran the 6510 variant of the 6502, It was designed to be a microprocessor to control things like refrigerators. 8 bit chip, and 64K total address space. There were tricks you could play. For instance, the C64 had 64K RAM and 16KB ROM. You could set bits that controlled what was mapped into the 64K address space. By defaalt, the top 8K was the kernel ROM, then 4K of RAM, and the the 8K Microsoft BASIC interpreter. Below that was RAM, and the bottom 1K was pointers to system routines. One bit of software I ran was a "wedge". Run it, and it flipped the ROMS out of the address space and loaded code and data into the 16K of RAM the ROMs normally appeared in, then mapped the ROMs back in. The usual way to reset the C64 was to press the Run/Stop and Restore keys simultaneously. The Restore key generated a non-maskable interrupt. By default, when you pressed it, the OS looked to see if you also pressed the Run/Stop key and did a warm start if so. If not, it was a no-op. The wedge installed in the 4K of RAM between the ROMs, and changed the standard system routine for dealing with the Restore key. Press the Restore key by itself, and it displayed a menu stashed under the kernel ROM. You could do things like run a machine language monitor that was also stashed under a ROM. You had to be carefully when using it that your programs didn't try to access kernel or BASIC routines while those ROMs were swapped out, but it worked fine, It was also possible to run the C64 at *2* mhz, but there were various limitations on when you could do it and what you could do when you did. The C64 was an interesting architecture hobbled by "design to cost". For instance, the 1541 floppy drive connected to the system over a *1200 baud* serial line.Start to load a big application, like GEOS, and go have coffee. By the time you were done, it might have finished loading. (Though there was a trick you could play there, too. The 1541 had a dedicated 6510 chip as drive controller with 2K local RAM. You could write machine code that could be downloaded and run asynchronously on the drive while the C64 did other things.) The C64 was a neat toy to play with, but there were reasons why 8bit machines based on the Intel 8080 and Zilog Z80 chip running CP/M were the original business productivity machines until the original IBM PC came along. You could do things on the Intel architecture you simply could not do on the C64, regardless of supposed speed advantage. The bit about the limitation imposed by the 8 bit data bus in the 8088 is open to a lot of question. The choice of the 8088 was also "design to cost". The big brother 8086 had a 16 bit bus, but the 8088 variant was cheaper, and in practice, the users never noticed. It was, after all, running at almost five times the clock speed of the 6510. And given that external storage on the C64 was either a tape drive or a floppy hobbled by an arthritic interface, the C64 tended to be a *lot* slower loading data. PCs also encouraged creativity to get around hardware limitations. One was writing directly to video RAM rather than using BIOS routines. A popular compatibility test for early PC clones was running Lotus 123 and MS Flight Simulator. If they ran successfully, the clone had a compatible BIOS. Many early clones did not, and the original Compaq PCs were the other choice besides genuine IBM gear *because* they had a compatible BIOS. The design of the 808X processor also allowed you to play games with the A20 address line, that let you access memory beyond the default 640KB limit by creating a 64K window in the 640K address space you could use to page in code and data stored above the 640K limit. I still
Re: [Freedos-user] New FASM and NASM versions available
Everything you've written in your post is *totally* missing the point presented in the article I gave link to. It's just your private impression "how it was using C-64 IMHO" - thanks for sharing -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New FASM and NASM versions available
No, I simply think the point in the article was wrong, based on experience with the platform, Your mileage obviously varies. __ Dennis On Thu, May 2, 2019 at 9:57 AM ZB wrote: > > Everything you've written in your post is *totally* missing the point > presented in the article I gave link to. > > It's just your private impression "how it was using C-64 IMHO" - thanks for > sharing > -- > regards, > Zbigniew > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user -- ___ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New FASM and NASM versions available
On Thu, May 02, 2019 at 10:16:52AM -0400, dmccunney wrote: > No, I simply think the point in the article was wrong, based on > experience with the platform, > > Your mileage obviously varies. I was using Commodore 64 (then C-128) since May (or June) 1985 - and I don't share your feelings. For example, you wrote: "Start to load a big application, like GEOS, and go have coffee". It is a proof, that you weren't actual C-64 user; because if you were, you surely would remember that *exactly GEOS* has built-in fastloader routines that made it loaded quite fast, even when using floppy without any "floppy-speeder" add-on (very common in use among real C-64 users). Indeed "not boosted" 1541 disk drive was very slow - they had to make it slow because of hardware bug in VIA 6522 discovered too late - but almost immediately there emerged various "fast load" routines (see: https://www.pagetable.com/?p=568 ), utilities (like Vorpal, making floppy even up to 25 times(!) faster purely by software), cartridges (Epyx, Final etc.) and hardware speeders (Speeddos, Prologic DOS, Dolphin DOS). You could also simply replace ROMs of your C-64 - if you had one - and of 1541 with the ones containing "fast" routines (Jiffy DOS, 10x "boost factor"). So there were many ways to cure the problem almost from the very start on -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New FASM and NASM versions available
Hi, On Thu, May 2, 2019, 7:32 AM ZB wrote: > > Well my "host platform" obviously is 16 bit - since it's FreeDOS. > > But yes, I was indeed somewhat amazed at "mammoth size" of NASM binary, > compared, as example, to modest 33 KB of A86.COM. > A86 is well-written, of course, but there are several caveats you must understand before comparing it to NASM. For one, it's self-assembling (according to author), meaning written by hand with no compiler. It's 8086-friendly, meaning it uses 16-bit instructions, which individually are smaller than 32-bit. Also, A86.COM [sic] doesn't support higher than 286, and the only outputs are flat binary (or .COM, close enough) and OMF/.OBJ. Also, I'm vaguely sure that it's compressed! Even A386.COM is only roughly 5 kb bigger, but most of the same caveats apply. (Also, it's one-pass only, meaning simpler but faster.) The 16-bit, UPX-compressed, NASM 0.98.39 from 2005 is 72 kb. It only supports Win32 (PE/COFF), bin, as86/a.out, and OMF/OBJ. But probably up through SSE2 (aka, P4). The 32-bit DJGPP build with all outputs will UPX to 134 kb (but could definitely be smaller with different libc or compiler switches). For comparison, 16-bit NASM 0.97, without -O (automatic size optimizations), only supporting through MMX (late P1), with all output formats, seems to compress to 68 kb. Try also comparing FASM. Clearly all the added AVX and newer stuff bloated it up quite a lot! 1.60 was 65 kb, 1.68 was 77 kb, 1.70.03 was 94 kb, and 1.73.10 is 105 kb. (None of those are compressed, though. Latest compresses to 54 kb.) FASMG has greater flexibility and puts all instructions as external macros, so it's only roughly 53 kb (Win32 console version), uncompressed. There are various other assemblers, often very small, with different features. > ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
