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
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
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
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
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
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
Hi, On Wed, May 1, 2019, 5:52 PM ZB wrote: > > > DJGPP builds are much easier to maintain because DJGPP is a mostly > > compatible gcc/GNU environment. > > Not sure why that compatibility is relevant? > 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. 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. > ___ 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 Wed, May 01, 2019 at 09:43:45PM +0200, C. Masloch wrote: > >> (While we still get DJGPP builds, there haven't been any 8086 builds > >> since 2005's 0.98.39.) > > > > Actually, why? Are all of these programs that large - or there are some > > significant advantages in providing them as DJGPP builds? "Ordinary" x86 > > build could work just fine, IMHO > > I believe that there are some tables in more recent NASM that exceed 64 > KiB in size, so they can't be addressed without segmentation arithmetic > any longer. And the compiler that was used (OpenWatcom IIRC) presumably > didn't provide that. This is actually rather strange; not sure about that Watcom - but I'm learning x86 assembly and I did some attempts using NASM as well, and it's definitely able to produce, say, COM files of size 84 bytes, for example. It introduces itself as "NASM 2.13.02 compiled on Nov 29 2017" - therefore 12 years after 2005. > DJGPP builds are much easier to maintain because DJGPP is a mostly > compatible gcc/GNU environment. Not sure why that compatibility is relevant? -- 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 at 2019-05-01 21:11 +0200, ZB wrote: >> (While we still get DJGPP builds, there haven't been any 8086 builds >> since 2005's 0.98.39.) > > Actually, why? Are all of these programs that large - or there are some > significant advantages in providing them as DJGPP builds? "Ordinary" x86 > build could work just fine, IMHO I believe that there are some tables in more recent NASM that exceed 64 KiB in size, so they can't be addressed without segmentation arithmetic any longer. And the compiler that was used (OpenWatcom IIRC) presumably didn't provide that. DJGPP builds are much easier to maintain because DJGPP is a mostly compatible gcc/GNU environment. Regards, ecm ___ 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 Wed, May 01, 2019 at 12:49:16AM -0500, Rugxulo wrote: > Which assembler? > [..] Thanks. > (While we still get DJGPP builds, there haven't been any 8086 builds > since 2005's 0.98.39.) Actually, why? Are all of these programs that large - or there are some significant advantages in providing them as DJGPP builds? "Ordinary" x86 build could work just fine, IMHO -- 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 Sun, Apr 28, 2019 at 4:20 PM ZB wrote: > > On Sun, Apr 28, 2019 at 03:41:22PM -0500, Jim Hall wrote: > > > They support other operating systems, too. > > Which one of both you prefer - and why? Which assembler? NASM does have a small advantage in OMF/OBJ support, if you need that. (Otherwise, YASM is much faster.) NASM is the "preferred" official assembler recommended by FreeDOS. (While we still get DJGPP builds, there haven't been any 8086 builds since 2005's 0.98.39.) FASM also needs 386+ but is self-assembling and thus smaller. (Also, FASMD is a great DOS TUI IDE.) It's more than capable, and you don't need a linker to make an .EXE. But here's the tricky answer: FASMG, which is the "next generation" version of FASM, is better overall. See below for some cool examples of FASMG in action (assembling "legacy" 16-bit code for DOS): * https://board.flatassembler.net/topic.php?t=21062 I don't at all pretend to understand FASMG macros, but it's clear that there is a ton of hidden potential there. (There isn't an official DOS port of that, but you can run the Win32 .EXE under Japheth's HX.) Besides the obvious message board/forum, Tomasz also has a YouTube channel and Twitter: * https://www.youtube.com/channel/UCs_OWSjmFntZqjzSpgJoBhA * https://twitter.com/grysztar ___ 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 Sun, Apr 28, 2019 at 03:41:22PM -0500, Jim Hall wrote: > They support other operating systems, too. Which one of both you prefer - and why? -- 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 Sun, Apr 28, 2019 at 3:12 PM Dale E Sterner wrote: > What OS is required to run this new assemblier. > > In both cases, you can run them on DOS. For example, NASM has a "dos" directory in their download area: https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/dos/ nasm-2.14.02-dos-upx.zip 2018-12-26 05:45 1.2M nasm-2.14.02-dos.zip 2018-12-26 05:45 1.5M And fasm specifically mentions a DOS version on their Downloads page: https://flatassembler.net/download.php flat assembler 1.73.11 for DOS size: 392 kilobytes last update: 19 Apr 2019 15:42:48 UTC This version can be executed from command line of any operating system compatible with DOS and contains few tiny examples of DOS programs. It also contains the documentation in text format using DOS character set. If you want to use flat assembler from the command line of Windows system, you should use the Windows console version instead of this one. They support other operating systems, too. Jim ___ 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
What OS is required to run this new assemblier. cheers DS On Sun, 28 Apr 2019 19:30:46 +0200 Eric Auer writes: > > Hi, forwarding from BTTR forum: > > > https://www.bttr-software.de/forum/forum_entry.php?id=15910 > > On 26 December 2018 the NASM development team released version > 2.14.02. > > Home page: http://www.nasm.us/ > Download: https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/ > Changelog: http://www.nasm.us/doc/nasmdocc.html > > Changes since last announcement (version 2.13.02): > > ... (see BTTR or NASM website) > > > https://www.bttr-software.de/forum/forum_entry.php?id=15911 > > On 19 April 2019 Tomasz Grysztar released version 1.73.11. > > Home page: https://flatassembler.net/ > Download: https://flatassembler.net/download.php > > Changes: > > ... (see BTTR) > > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > ** >From Dale Sterner - MS organic chemistry http://pubs.acs.org/doi/abs/10.1021/jo00975a052 *** Drink 1 Cup Before Bed, Watch Your Body Fat Melt Like Crazy mayserve-magestor.com http://thirdpartyoffers.juno.com/TGL3141/5cc608c2ce8d98c222e8st04duc ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New FASM and NASM versions available
Hi, forwarding from BTTR forum: > https://www.bttr-software.de/forum/forum_entry.php?id=15910 On 26 December 2018 the NASM development team released version 2.14.02. Home page: http://www.nasm.us/ Download: https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/ Changelog: http://www.nasm.us/doc/nasmdocc.html Changes since last announcement (version 2.13.02): ... (see BTTR or NASM website) > https://www.bttr-software.de/forum/forum_entry.php?id=15911 On 19 April 2019 Tomasz Grysztar released version 1.73.11. Home page: https://flatassembler.net/ Download: https://flatassembler.net/download.php Changes: ... (see BTTR) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
